Content
81%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 highly actionable, well-validated operational skill: every route has executable commands, explicit error-recovery loops, and a result contract, with a real one-level-deep reference bundle. The main costs are token weight — repeated guardrails and long inline measured-detail sections (runtime SQL, FTS tokenizer data) that could be tightened or moved to reference files.
Suggestions
Deduplicate the repeated guardrails (zero-row/miss-is-not-absence, no raw corpus scan, exclude-current-session) into the single Guardrails section and reference it from the route sections, trimming roughly 30–50 lines of repetition.
Move the FTS tokenizer measurements and per-index constraint details into a dedicated reference file (e.g., references/fts_lookup.md), keeping only the trigger conditions, the executable query, and the link in the body.
Collect dated/time-sensitive measurements ("Pitfalls measured 2026-10-03", measured row counts and timings) into a clearly labeled measurements section or reference file so they can drift without polluting the core instructions.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body never explains concepts Claude already knows and is dense with domain-specific constraints, but it is ~450 lines with noticeable repetition: the zero-row/miss-is-not-absence and no-raw-corpus-scan guardrails each appear in 3+ sections, and the FTS section carries long measured-statistic prose (e.g., the 闭 vs 闭门 row-count proof). Dated measurements ("Pitfalls measured 2026-10-03") are time-sensitive content placed outside any deprecated/notes section. This fits the mostly-efficient-but-could-be-tightened anchor: more over-explanation than the minor instances of a 4, but domain-specific rather than the padded known-concept explanations of a 2. | 3 / 5 |
Actionability | Every route ships a copy-paste-ready command with full flags (e.g., "read_codex_session.py --session <ID> --tools --contains '<literal clue>' --format json") plus executable SQL blocks and enumerated expected-output fields (identity, records_examined, matched_records, truncated: false). Specific examples cover the common cases exactly as the top anchor requires. | 5 / 5 |
Workflow Clarity | Multi-step processes are explicitly numbered with validation checkpoints and feedback loops: "Treat recent_rows < total as truncation; ... Raise the bounded limit or narrow the cwd/time window", "on ambiguity, show the returned candidates and ask for a longer prefix", "validate every newer candidate; an unreadable ... candidate leaves the affected latest claim unknown", and a 5-item Read-result contract checklist. The skill is read-only, so the destructive-operation cap does not apply, and error-recovery loops are pervasive. | 5 / 5 |
Progressive Disclosure | Six substantive reference files (60–297 lines each) are all real, referenced exactly one level deep, and clearly signaled with read-when conditions ("Read [references/storage_and_portability.md] ... when inventory reports unsupported, missing or ambiguous storage"); all referenced scripts exist. It is not 5 because the main file is not a lean overview — heavy detail is inlined that belongs in references (the ~40-line FTS tokenizer constraint section with measured data, the runtime-log SQL pitfall section, and the 5-step termination-evidence chain), which is more than the minor organization gaps of the 4 anchor but stops short of the should-be-separate-is-inline-with-unclear-signaling pattern of a 3. | 4 / 5 |
Total | 17 / 20 Passed |