Content
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
A highly actionable, well-sequenced protocol specification with strong workflow clarity and executable code throughout. Its weaknesses are length (inline examples and framing that could be trimmed) and the absence of progressive disclosure — everything is packed into one monolithic file with no reference links.
Suggestions
Move the full harness-tasks.json schema, the concurrency/locking script, and the error-handling category table into separate reference files (e.g. references/state-schema.md, references/concurrency.md, references/error-handling.md), keeping SKILL.md a concise overview that links one level deep.
Tighten the inline examples — reduce the three full task objects in the JSON sample and the 10-line progress-log sample to one representative example each to cut tokens without losing clarity.
Condense the 'Design Principles' section, which reads as philosophical framing rather than executable protocol, to reclaim tokens for the operational content.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The ~366-line body avoids basic-concept padding and is mostly operational protocol, but it is lengthy: a full three-task JSON sample, a 10-line progress-log sample, and a philosophical 'Design Principles' section could all be tightened. It sits at 'mostly efficient but could be tightened' rather than 'lean, every token earns its place'. | 2 / 3 |
Actionability | Provides fully executable guidance: a copy-paste-ready atomic mkdir locking script with stale-lock reclamation, concrete git commands ('git reset --hard <started_at_commit>', 'git clean -fd', 'git cat-file -t <hash>'), 'timeout <seconds> <command>' wrappers, a complete JSON schema, and decision matrices with concrete actions. | 3 / 3 |
Workflow Clarity | Multi-step processes are clearly sequenced (Session Start, Task Selection Algorithm, Task Execution Cycle) with an explicit validation checkpoint (run validation.command before declaring completion) and feedback loops (rollback-and-retry, the Context Window Recovery decision matrix, the error-category recovery table). Destructive ops carry validation, so no cap applies. | 3 / 3 |
Progressive Disclosure | There are no bundle/reference files; all detail lives inline in a single 366-line SKILL.md. Sections are well-organized with clear headers, but reference material that could be split out — the full state schema, the locking implementation, the error-handling table — is inline rather than one level deep, matching the 'content that should be separate is inline' anchor. | 2 / 3 |
Total | 10 / 12 Passed |