Content
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The body is a highly actionable, well-sequenced refactoring workflow with strong validation feedback loops, but it is monolithic and verbose, inlining a long compatibility preamble and Team Mode addendum that could be externalized.
Suggestions
Move the Codex/OpenCode tool-compatibility preamble and the REFACTOR_TEAM_MODE_ADDENDUM into separate reference files (e.g. references/harness-compat.md, references/team-mode.md) and link to them from the main body to improve progressive disclosure.
Trim repeated override caveats (e.g. 'If a code block below conflicts with this section, this section wins' appears multiple times) to a single authoritative statement to reduce token cost.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The ~600-line body is operational rather than padded with known concepts, but it is verbose: repeated 'this section wins' caveats, a long tool-surface compatibility preamble, and an inlined Team Mode addendum that re-explains tool usage Claude already knows. | 2 / 3 |
Actionability | It provides concrete, copy-paste-ready examples throughout (LspGotoDefinition, sg --pattern/--rewrite, TodoWrite, git commit, team config JSON) with clearly marked placeholders like [TARGET] and [agent_1_id]. | 3 / 3 |
Workflow Clarity | A clearly sequenced 6-phase workflow with explicit per-phase todo markers and mandatory validate-then-fix-then-retry checkpoints ('Post-Step Verification (MANDATORY)', 'STOP AND FIX', abort conditions). | 3 / 3 |
Progressive Disclosure | No bundle files exist and the entire skill is a monolithic single-file ~600-line document; the Team Mode addendum and harness-compatibility preamble are inline content that would benefit from being split into separate reference files. | 2 / 3 |
Total | 10 / 12 Passed |