retro-v2

Use when a branch has finished and the session-metrics card is all that is wanted — writes, commits and renders the card, and stops. The card-only half of `retro`, for sessions running close to their token budget. Where there is room to think, run `retro` instead — this one deliberately produces no findings and changes nothing.

Quality

90%

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

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

A tightly written, fully executable procedure: copy-paste commands, explicit validation checkpoints, and failure paths for every environmental constraint. The only costs are length — rationale-heavy sections inflate the token budget — and the absence of any bundle split for that explanatory material.

Suggestions

Trim the 'When to run this instead of retro' and 'Where this sits' sections to two or three lines each, moving the orchestration context to the existing workflow documentation the body already assumes.

Move the four rules under Step 1 — particularly the `.closingIssuesReferences` and label-policy rationale — into a references/ file, keeping only the rule statements and the one-line 'why' in SKILL.md.

Condense the `transcripts: no` and hook-fallback paragraphs into a short table of condition → consequence, preserving the rules while cutting roughly half the tokens.

Dimension	Reasoning	Score
Conciseness	The body is dense and assumes competence — no basic concepts are explained, and every rule carries non-obvious domain rationale (e.g. why a shell-rolled issue lookup silently reads a stranger's label). It sits at 4 rather than 5 because sections like 'When to run this instead of retro' and the four-rule block carry explanatory context that could be trimmed by a third without losing actionability; not 3, since none of it is padding Claude already knows.	4 / 5
Actionability	Every step is copy-paste-ready bash: the three pre-flight probes, `bun run --cwd tools/pr-metrics card -- --resolve-issue` in both committed and markdown forms, the guarded `git add` of the single card, and the append-to-body sequence with the duplicate-check grep. Fallback commands for missing `gh` and missing network are given explicitly, covering the common failure cases — the 5 anchor.	5 / 5
Workflow Clarity	Sequence is explicit (probe environment → write/commit card → render onto PR → finish report) with real checkpoints: the pre-flight network/gh/transcripts probe, the duplicate-block check before appending (with the correct match pattern explained), and per-step degradation paths ('record which and carry on'). Not 4: validation and error recovery are explicit at every fragile point, matching the 5 anchor's feedback-loop pattern.	5 / 5
Progressive Disclosure	No bundle files exist (references/, scripts/, assets/ are absent) and the body is self-contained with clear section headers, so navigation is unambiguous — but at ~160 lines, explanatory blocks like the four rules and the 'When to run this instead of retro' context could live in a reference file. That puts it at 4 (good structure, minor organization gaps) rather than 5, which is reserved for a lean overview with well-signaled references or a sub-50-line body.	4 / 5
	Total	18 / 20 Passed

Description

92%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 precise, well-disambiguated description: concrete actions, an explicit 'Use when' trigger with a budget-based condition, and deliberate contrast with its parent skill. The only weakness is a slightly narrow trigger vocabulary tied to one project's terminology.

Dimension	Reasoning	Score
Specificity	The description lists multiple concrete actions — "writes, commits and renders the card, and stops" — plus explicit non-goals ("produces no findings and changes nothing"), fully covering the skill's single job. It matches the 5 anchor (multiple specific concrete actions, comprehensive) rather than 4, since no part of the skill's behavior is left unspecified.	5 / 5
Completeness	Both halves are explicit: what it does ("writes, commits and renders the card, and stops") and when to use it ("Use when a branch has finished and the session-metrics card is all that is wanted"... "for sessions running close to their token budget"), with a concrete disambiguating condition. Not 4, because the 'when' is not merely present but given twice with specific triggering circumstances.	5 / 5
Trigger Term Quality	Natural phrases a user would say are present: "a branch has finished", "session-metrics card", "close to their token budget", "retro". It falls short of the 5 anchor because there are no synonyms or variations beyond this fixed vocabulary (e.g. "metrics card", "session summary"), which keeps it at good-but-not-comprehensive coverage.	4 / 5
Distinctiveness Conflict Risk	It carves out a clear niche ("The card-only half of `retro`") and actively prevents mis-triggering against the sibling skill ("Where there is room to think, run `retro` instead"). This is stronger than the 4 anchor's 'minor overlap risk' — the overlap with `retro` is named and resolved by an explicit rule.	5 / 5
	Total	19 / 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: englishstventures/osn
Path: .claude/skills/retro-v2/SKILL.md
Commit: e92e5d1

Reviewed: 4 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.