Name: code-review
Rating: 74.4 (1 reviews)
Author: mixpanel

code-review

Procedure to review a pull request in mixpanel-headless and check each finding before it is posted. Use for every pull request review in this repository.

Quality

93%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Quality

Content

100%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.

An exemplary instruction-only skill body: concise, fully actionable with concrete commands and paths, a clearly sequenced workflow with explicit verification gates before posting, and clean delegation of detail to existing repo documents. No dimension shows a notable weakness.

Dimension	Reasoning	Score
Conciseness	The body is lean and directive with zero padding: every sentence carries repo-specific information Claude could not infer ('Those tests call the real Mixpanel API, and some of them write data', 'The unit tests run offline with mocks'). It fully assumes Claude's competence, matching anchor 5 ('every token earns its place').	5 / 5
Actionability	Guidance is fully executable for an instruction-only skill: concrete commands ('uv run pytest <file>::<test> -q', 'uv run mp help <Name>', 'uv run python -c "..."') and exact file paths ('src/mixpanel_headless/__init__.py', 'CHANGELOG.md', '.github/instructions/', 'docs/guide/'). This matches anchor 5 (copy-paste ready commands covering the common cases).	5 / 5
Workflow Clarity	A clear four-phase sequence (collect context, check findings, check public API changes, post) with explicit validation gates: 'Where you can, prove the finding', 'If you cannot support the finding with a line or a check, do not post it', plus safety guards ('Never run tests under tests/live/', 'never pass -m live'). The verification this posting workflow requires is present, so the missing-validation cap does not apply; this matches anchor 5.	5 / 5
Progressive Disclosure	The body is under 50 lines with well-organized numbered sections and no need for bundle files, so the simple-skill guideline applies. It appropriately delegates detail to one-level-deep, clearly signaled repo files (REVIEW.md for priorities and severity, .github/instructions/ per changed area, per-folder CLAUDE.md guides), matching anchor 5.	5 / 5
	Total	20 / 20 Passed

Description

82%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 that explicitly states both what the skill does and when to use it, with clear repo-level scoping that minimizes conflict risk. Its only weakness is moderate specificity: it summarizes the procedure at a high level ('review', 'check each finding') rather than naming the concrete stages of the review process.

Suggestions

Name one or two more concrete actions from the procedure (e.g., 'collect context, verify each finding with a focused test or code line, then post with a severity') to lift specificity toward comprehensive coverage.

Add common trigger synonyms such as 'PR' or 'code review' alongside 'pull request review' so users who abbreviate still match naturally.

Dimension	Reasoning	Score
Specificity	Names the domain ('review a pull request in mixpanel-headless') and two concrete actions ('review a pull request', 'check each finding before it is posted'), but does not enumerate the fuller procedure such as context collection, public API checks, or severity assignment. This matches anchor 3 (domain plus 1-2 concrete actions, not comprehensive); anchor 4 requires several listed actions, which is more than the two given.	3 / 5
Completeness	Both parts are explicitly answered: what ('Procedure to review a pull request in mixpanel-headless and check each finding before it is posted') and when ('Use for every pull request review in this repository'). The explicit 'Use for' trigger clause means the completeness cap of 3 does not apply; this matches anchor 5.	5 / 5
Trigger Term Quality	'pull request', 'review', and 'finding' are natural terms a user would say when requesting a PR review ('review this pull request'). Common synonyms such as 'PR' and 'code review' are missing, matching anchor 4 (good keyword coverage, a few natural terms missing) rather than anchor 5.	4 / 5
Distinctiveness Conflict Risk	The description is scoped to a named repository ('mixpanel-headless', 'in this repository') and carries a distinct differentiator ('check each finding before it is posted'), giving it a clear niche with minimal conflict risk against generic review skills. Matches anchor 5.	5 / 5
	Total	17 / 20 Passed

Validation

100%

Warnings & errors only

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: mixpanel/mixpanel-headless
Path: .github/skills/code-review/SKILL.md
Commit: fbed0c5

Reviewed: 5 hours ago

Table of Contents

Discovery Implementation Validation

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.