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 lean, highly actionable operations runbook: exact CLI commands, explicit validation-before-mutation checkpoints, and clear failure/stop conditions for destructive operations. Remaining gaps are minor — some repeated enumerations and a lack of worked examples or expected command output for the judgment-heavy steps.
Suggestions
Deduplicate the recurring startup-input enumeration (provider process, model, base URL, environment, profile, command template, role assets, startup context) into a single defined list referenced by both the recovery flow and Supported Actions.
Add one short worked example of expected command output (e.g., a ccb restart response with restart_status and blockers) to ground the judgment-only steps like 'decide whether agents still use stale startup inputs'.
Consider moving fault-injection handling detail into a reference file to keep the SKILL.md overview shorter and enable one-level-deep progressive disclosure.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body assumes competence — it never explains what tmux or CCB is — but the long startup-input enumerations ('provider process, model, base URL, environment, provider profile, command template, role assets, or startup context') recur across sections and could be tightened, matching the 'efficient with minor trims' anchor. | 4 / 5 |
Actionability | Concrete copy-paste commands with flags throughout ('ccb ps', 'ccb queue --detail <agent|all>', 'ccb config validate', 'ccb reload --dry-run', 'ccb restart <agent>') plus explicit gates and blocker reporting. Falls just short of 5 because a few judgment-only steps ('Gather evidence without reading secrets', 'Decide whether affected running agents still use stale... state') lack a worked example or expected command output. | 4 / 5 |
Workflow Clarity | A numbered 6-step Recovery Gates checklist and a 9-step provider recovery flow with explicit validation checkpoints ('ccb config validate' then 'ccb reload --dry-run' before 'ccb reload'), stop conditions for busy/pending state, and feedback loops ('If ccb restart returns blocked or failed, report the blockers'). Destructive operations are fully gated, matching the 5 anchor. | 5 / 5 |
Progressive Disclosure | Well-organized sections (Recovery Gates, Provider/API Recovery, Supported Actions, Handoffs, Red Lines) with no nested references and everything appropriately inline for a single-file runbook. It misses 5 because at ~98 lines with no bundle files it exceeds the under-50-line simple-skill exception; fault-handling and per-command detail could be split into reference files. | 4 / 5 |
Total | 17 / 20 Passed |