Content
77%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The body is highly actionable — exact commands, exact tool parameters, and a complete output template — with a clearly sequenced workflow, explicit validation checkpoints, and fail-open error-recovery loops for critic/lane dispatch. Its weaknesses are density (long run-on rationale and GitNexus-internal digressions that belong in reference files are inlined) and progressive disclosure: the ci-personas/ lane files the Swarm lanes section depends on are not present in the bundle.
Suggestions
Move the GitNexus-internal schema-fingerprint/parser-compatibility guidance in workflow step 8 into a reference file (e.g. references/versioning-invariants.md), keeping a two-line pointer in the main workflow — this simultaneously improves conciseness and progressive disclosure.
Ship the ci-personas/ lane definition files referenced by the Swarm lanes section (they are absent from this bundle), or remove the reference so the skill does not depend on unavailable files.
Tighten the longest multi-clause sentences (the lens-efficiency rationale, the gitnexus-pr-swarm-review distinction parenthetical, the fingerprint derivation sentence) into short directives — the judgment is sound but the density makes the operative rule easy to miss.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body contains essentially no padding about concepts Claude already knows — every sentence is skill-specific (merge-base semantics, worktree rules, PDG indexing) — but it is a dense ~270-line wall with run-on multi-clause sentences and rationale explanations that could be tightened, e.g. 'two lenses reading the same files pay twice for one read's coverage, so give one reviewer both charges' and the long parenthetical distinguishing gitnexus-pr-swarm-review. This fits anchor 3 ('mostly efficient but... could be tightened') better than anchor 4, whose over-explanation would be only minor. | 3 / 5 |
Actionability | Guidance is fully executable throughout: exact commands ('git merge-base <base> <head>', 'node .gitnexus/run.cjs analyze --index-only', 'git status --short'), exact tool invocations with parameters ('detect_changes' with 'scope: "compare"', 'base_ref: <merge-base SHA>', 'worktree'; 'impact' with 'includeTests: true'; 'explain'; 'pdg_query'), and a copy-paste-ready output template covering the PR, range, and local cases. This matches anchor 5; the few unspecified argument shapes (e.g. for 'context') are minor and don't create the gaps of anchor 4. | 5 / 5 |
Workflow Clarity | The workflow is a clearly sequenced numbered list (resolve target → align checkout/index → 8-step review → lenses → findings → output) with explicit validation checkpoints ('If an exact target checkout/index cannot be established, state the limitation and do not claim a complete graph-backed review'; 're-run the exact CI check command against the head instead of trusting the committed value') and genuine error-recovery feedback loops (critic 'DEFECTS → repair and re-dispatch once', 'If subagent dispatch is unavailable or any lane fails, run that lane's charge inline'). The skill is read-only and non-destructive, so the destructive-operation cap does not apply; this is anchor 5. | 5 / 5 |
Progressive Disclosure | Structure exists (clear section headers), but content that clearly belongs in separate reference files is inlined: the ~40-line GitNexus-internal schema-fingerprint and parser-compatibility digression in workflow step 8 and the full swarm-lane dispatch protocol. More importantly, the Swarm lanes section depends on 'ci-personas/' files that are not present in the skill bundle, and the body references no other bundle files — matching anchor 3 ('content that should be separate is inline') rather than anchor 4, where most content would be appropriately placed and references would resolve. | 3 / 5 |
Total | 16 / 20 Passed |