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.
A strong, highly actionable multi-agent investigation workflow with excellent validation and feedback loops, and mostly lean domain-specific content. Its main defects are a missing load-bearing bundle file (templates/forensic-report.md), unspecified evidence-store add syntax, and some redundancy across investigator sections.
Suggestions
Add the missing templates/forensic-report.md to the bundle (or point Phase 0/Phase 6 at an existing file) — as written, `cp SKILL_DIR/templates/forensic-report.md` fails and the whole workflow cannot start.
Show the exact `evidence-store.py add` invocation once (e.g., the flags for type, content, source, and content_sha256) so investigators can record evidence without guessing the CLI.
State each investigator's role boundary once in the guardrails and reference it from the investigator sections, and fold the API rate-limiting numbers into a reference file to trim the main body.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense with genuinely non-obvious domain knowledge (force-push detection via `payload.distinct_size = 0`, the `commits/SHA` vs `git/commits/SHA` 404 trick, CDX query patterns, rate-limit budgets) and avoids explaining concepts Claude already knows. It is not a 5 because of repeated content: role boundaries are stated once in the guardrails and again per investigator, the `evidence-store.py list` invocation appears in Phases 0, 3, and 7, and the rate-limiting and ethical-use sections could be trimmed or moved to a reference. | 4 / 5 |
Actionability | Mostly executable, copy-paste-ready commands: full git forensics pipelines, concrete GitHub REST API curl calls, CDX API URLs with parameters, and BigQuery templates with mandatory dry-run cost rules. It falls short of anchor 5 because `evidence-store.py add` is invoked repeatedly ("add via `python SKILL_DIR/scripts/evidence-store.py add`") without ever showing the actual add syntax (flags for type/content/SHA), and commands use unsubstituted placeholders (OWNER/REPO, YYYYMM, NUM) rather than worked examples. | 4 / 5 |
Workflow Clarity | The 8 phases are explicitly sequenced with strong validation checkpoints and feedback loops: Phase 5 mechanically verifies cited evidence IDs (hard failure on missing IDs), Phase 3 verifies `content_sha256` hashes and requires 2-source verification for `[VERIFIED]`, and rejected hypotheses feed back into Phase 4 for refinement with a max-3-iteration bound. This matches anchor 5 ("Clear sequence with explicit validation steps; feedback loops for error recovery; checklists for complex processes") — the anti-hallucination guardrails function as a checklist, and the destructive/batch cap does not apply since validation is pervasive. | 5 / 5 |
Progressive Disclosure | The body itself is structured as a proper overview — each phase points to one-level-deep, clearly-signaled references ("See [evidence-types.md](./references/evidence-types.md) for IOC taxonomy") with a Reference Materials index — but scoring against the actual bundle reveals that `templates/forensic-report.md`, referenced three times and load-bearing (Phase 0 step 3 copies it; Phase 6 populates it), does not exist in the bundle, so the workflow breaks at initialization. The four references/ files and scripts/evidence-store.py do exist, but a missing referenced file is a real navigation/integrity gap beyond anchor 4's "minor organization gaps". | 3 / 5 |
Total | 16 / 20 Passed |