CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

run-parity

Compare React Doctor diagnostics for a GitHub pull request (PR) with Vercel Sandbox. Use when asked to run parity, check a PR for diagnostic regressions, compare a PR with its base, or report added and removed diagnostics.

71

Quality

89%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

SKILL.md
Quality
Evals
Security

Quality

Content

85%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is exceptionally actionable, with executable commands, exact flags, explicit exit codes, thresholds, and validation/feedback loops at every stage of a clearly sequenced workflow. Its main weakness is organization: advanced modes (paired runs, matrix descriptors, caching protocol, performance comparison) are inlined rather than split into reference files, which both lengthens SKILL.md and obscures the simple prepare-run-compare-report path.

Suggestions

Move the advanced material — the paired-sandbox run semantics, the matrix treatment descriptor schema and its workflow, and the baseline-cache provenance protocol — into reference files (e.g., references/paired-runs.md, references/matrix.md, references/baseline-cache.md) and keep a short core path (prepare → run base → validate → run candidate → compare → report) plus brief signed pointers in SKILL.md.

Deduplicate the cache-validity rules: the stamping, verification, and 'never cache unstamped runs' requirements each appear in multiple sections; state them once in the caching reference and refer back to it.

Add a short 'When to use which mode' decision list (simple PR → plain two-run flow; rule-only PR → incremental scoped run; multiple PRs sharing a base → matrix) so readers can locate the relevant branch without reading all variants.

DimensionReasoningScore

Conciseness

The body assumes Claude's competence throughout (e.g., "Require `VERCEL_OIDC_TOKEN` or `VERCEL_TOKEN` with `VERCEL_TEAM_ID`..."; "Run from `packages/evals`. The default corpus contains the 2,000 highest-ranked repositories...") with no explanation of known concepts. Cache-validity invariants are restated across sections ("Never cache an older unstamped run", the provenance/verify paragraphs, and "A cached baseline must still pass the streaming validator before reuse"), which is trimmable redundancy, placing it at anchor 4 rather than the every-token-earns-its-place anchor 5.

4 / 5

Actionability

Fully executable guidance: concrete shell commands with exact flags and paths (e.g., the paired eval command with `--paired-baseline-output`, `--paired-execution sequential`), a complete JSON descriptor schema, enumerated exit codes ("`0`: diagnostics match, `1`: ... `2`: inputs are incomplete or invalid"), and specific thresholds ("flags an individual project only when it is at least 50% and two seconds slower"). Copy-paste ready and covers the common cases, matching the anchor-5 example.

5 / 5

Workflow Clarity

A clear Prepare → Run both revisions → Compare → Report sequence with pervasive explicit validation checkpoints and feedback loops appropriate to this batch operation: "Before the candidate run, stream-validate every baseline record", "If the baseline command exits non-zero or the check fails, inspect its failed records and stop", the 200→50→10 retry ladder, and "Any nonzero paired evaluator run still makes both output artifacts invalid and non-reusable; discard them". This satisfies the destructive/batch validation requirement and matches the anchor-5 feedback-loop example, not anchor 4 which allows minor validation gaps.

5 / 5

Progressive Disclosure

Section headers exist and every referenced script path (baseline-cache-provenance.mjs, verify-matrix-artifact.mjs, compare-parity.mjs, compare-parity-performance.mjs, find-impacted-rules.mjs, build-parity-index.mjs, compare-parity-indexes.mjs, validate-parity-input.jq, and the test files) is real and invoked inline, but roughly 150 lines of advanced material (paired-sandbox internals, the matrix treatment descriptor schema, the baseline-cache provenance protocol, performance-comparator thresholds) is inlined in SKILL.md with no references/ split. This matches anchor 3 (content that should be separate is inline); not 4 because the main path is buried among advanced variants, and not 2 because structure is present and all references are clear and one level deep.

3 / 5

Total

17

/

20

Passed

Description

87%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description: it states a concrete, tool-specific capability and pairs it with an explicit, multi-trigger 'Use when' clause covering the natural ways a user would request this task. The only gaps are a few additional natural phrasings and the fact that most capabilities appear as trigger terms rather than as the primary 'what' statement.

DimensionReasoningScore

Specificity

"Compare React Doctor diagnostics for a GitHub pull request (PR) with Vercel Sandbox" names the domain and toolchain, and the trigger clause enumerates several concrete actions ("check a PR for diagnostic regressions, compare a PR with its base, or report added and removed diagnostics"), matching the several-specific-actions anchor. Not 5 because the core 'what' is a single compare action with the remaining behaviors framed only as triggers; not 3 because more than 1-2 concrete actions are explicitly listed.

4 / 5

Completeness

Explicitly answers both what ("Compare React Doctor diagnostics for a GitHub pull request (PR) with Vercel Sandbox") and when ("Use when asked to run parity, check a PR for diagnostic regressions, compare a PR with its base, or report added and removed diagnostics") with concrete trigger phrases, matching the anchor-5 example structure exactly. Not 4 because the 'when' clause is explicit and multi-trigger rather than merely present.

5 / 5

Trigger Term Quality

Natural phrases a user would actually say are present: "run parity", "check a PR for diagnostic regressions", "compare a PR with its base", "report added and removed diagnostics", plus the "PR"/"pull request" synonym pair. Coverage is good but a few plausible invocations (e.g., a diagnostic diff between base and head commits) are not covered, so it sits at anchor 4 rather than comprehensive coverage.

4 / 5

Distinctiveness Conflict Risk

A clear niche (React Doctor PR parity on Vercel Sandbox) with distinct trigger terms like "run parity" that are unlikely to fire for any other skill. No meaningful overlap with generic comparison or CI skills remains, so it fits the clear-niche anchor rather than the minor-overlap anchor 4.

5 / 5

Total

18

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

millionco/react-doctor

Path

.agents/skills/run-parity/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.