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 and the workflow is exceptionally well-validated for a destructive batch operation, with the real decision logic correctly delegated to the bundled scan.mjs. It is held back by heavy duplication between the opening paragraph and the numbered steps, extreme run-on density, and a monolithic headerless structure that inlines policy detail a reference file should carry.
Suggestions
Cut or drastically compress the opening paragraph — its mode, patch-saving, and KEEP-rule detail is restated almost verbatim in steps 3 and 4, so the body could lose roughly a third of its tokens with no loss of guidance.
Move the KEEP/SAFE/ASK verdict policy (the step-3 sub-bullets and the run-folder rules) into a references/verdicts.md file and keep a one-line summary per verdict in SKILL.md, since scripts/scan.mjs already makes every verdict.
Add section headers (e.g. ## Modes, ## Workflow, ## Verdict rules, ## Troubleshooting) so the ~1,700-word body is navigable without reading it end to end.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The ~450-word opening paragraph restates the --landed/--remove mode, patch-saving, and KEEP-rule details that steps 3–4 repeat, and the relentless run-on clause chains (e.g. "It keeps a worktree git does not list, a locked one, one outside the folders agents make worktrees in...") could be materially tightened — mostly efficient but with real duplication, fitting anchor 3 rather than 4's minor trimming. | 3 / 5 |
Actionability | Every step carries an executable command — `df -h <checkout>`, `node <this skill>/scripts/scan.mjs --repo . --sessions <file>`, `git worktree remove --force`, `git worktree lock --reason "<why>" <path>`, `next telemetry disable` — and the decision logic is delegated to a real bundled script, with the telemetry edge case given a concrete PID/command diagnostic. | 5 / 5 |
Workflow Clarity | Steps 1–6 are clearly sequenced with explicit validation for this destructive batch operation: the session list is re-saved and items re-judged right before --delete, "a failed removal turns that row into ASK", ASK rows require owner confirmation, and df is recorded before and after to verify the outcome — feedback loops are present, so the destructive-operation cap does not apply. | 5 / 5 |
Progressive Disclosure | The verdict logic is properly externalized to scripts/scan.mjs (a real file, clearly referenced), but the SKILL.md body is a ~1,700-word wall of prose with no section headers, and the ~700 words of KEEP/SAFE/ASK policy in step 3 are reference material that could live in a separate file — matching anchor 3's inlined-should-be-separate content rather than 4's minor organization gaps. | 3 / 5 |
Total | 16 / 20 Passed |