fix(skill-review): stop requiring client-specific TodoWrite and Task

[mnovikov-mindbox]

Type of Change

• New plugin
• Update to existing plugin
• Repository tooling / docs

---

What was broken

The skill refused to start on current Claude Code models.

SKILL.md § Preconditions said: "Before Step 0, check Task, TodoWrite, and file access for the skill. If anything is missing — stop and report what is lacking." Both names have since moved: the sub-agent tool was renamed Task → Agent in v2.1.63, TodoWrite was superseded by TaskCreate/TaskGet/TaskUpdate/TaskList in v0.2.82, and in v2.1.268 the whole task-tracking family became model-gated (CLAUDE_CODE_ENABLE_TODO_TOOLS=1 to restore it). Both preflight conditions fail on a current model, so the review stopped at step zero. references/instruction-singlepass.md § Preconditions repeated the same hard gate for the second execution mode.

The rest of the skill was built on top of that assumption: a mandatory "TODO plan", statuses pending/in_progress/completed, delegation "via Task".

Chasing the new names would only reset the clock. The fix removes the dependency instead.

What changed

Planning is one mechanism, described in words. The review plan is a markdown checklist the agent copies into its response and checks off as it goes — the pattern Anthropic's skill authoring guide recommends for complex workflows. Both execution modes ship a ready-made skeleton to copy: SKILL.md § Mandatory Review Plan (by check group) and instruction-singlepass.md § Algorithm (by Part A–G). It works in every client and names no tool, so nothing goes stale the next time one is renamed or gated.

Planning did not get weaker: an explicit completion gate replaces what the tool used to enforce — no final report while plan items are open, in the CRITICAL block and in single-pass Mandatory Rules.

No client tool is named anywhere in the skill. File read is the only hard requirement left. A missing sub-agent tool is not a precondition failure — it only selects the execution mode: single-pass regardless of volume, with the missing delegation recorded in Review Limitations, and a reading strategy for a large skill in one context.

The checklist the skill judges other skills by had the same staleness. WF12 now asks for a planning mechanism that does not depend on a tool being present in a particular client; WF13 is worded in terms of open plan items instead of one tool's status names.

Antipattern Bingo #21 "Client tool lock-in" (stage 3, WF12 + WF15, owner Workflow) — added so the reviewer catches this class in other skills. It is anchored to two checks on purpose: WF12 is gated on "workflow longer than 4 steps", so on its own it would have forced a NONE verdict for a short skill whose preconditions hard-require a tool — a clean verdict for a skill with exactly this defect. WF15 carries no such gate. This is the shape #20 already uses (RF12 gated, RF06 not), and the stage follows the maximum of the anchors as #15 does. The note against #16 Context overfitting splits by signal: a named client tool goes to #21, everything else to #16.

Fixed along the way

With logging on, the results folder is now created right after the user confirms its path (step 3d) instead of on the sub-agent branch only (was step 10b) — single-pass mode had nowhere to write report.md. Pre-existing, unrelated to the tool dependency, two lines.

Versions per CLAUDE.md § Version Policy: plugin.json 1.0.0 → 1.1.0, SKILL.md metadata.version 1.6.0 → 1.7.0, CHANGELOG entry added.

---

Plugin Checklist

• All content in English
• plugin.json has name, description (English), version, author
• SKILL.md frontmatter complete: name (kebab-case, matches folder), description with trigger phrases and "Don't use when", metadata.version
• marketplace.json updated — n/a, no new plugin; the existing entry needs no change
• Root README.md plugin table updated — n/a, no new plugin
• CHANGELOG.md updated in plugin root
• CI (validate.yml) passes

---

Skill Review Results

Run on bbf9afc, in sub-agent mode (1911 lines, 5 sub-agents).

Scope used: Repository (full)

Statistics: FAIL: 2, WARNING: 18, PASS: 45, N/A: 7

That run found three places where the branch had half-landed, all fixed in bbf9afc:
instruction-singlepass.md still claimed it runs only below 500 lines while the new
fallback routes any volume into it; its algorithm never wrote the plan file; and its
copy of WF12 lacked a row its checklist twin had.

9237e76 then replaced the mechanism itself — capability tables out, one copyable
checklist in — and has not been re-reviewed by the skill. The statistics above
predate it. The three issues below were unaffected by either revision.

Top 3 issues (if any): all three predate this branch and are left for separate PRs — this one stays scoped to the tool-dependency fix.

1. RF05 / Bingo #8 — no single source of truth between instruction-singlepass.md and the checklists. The single-pass file carries its own copies of all five checklists, the Bingo table, the report template and the base rules, and the copies have already drifted apart in four places (a Troubleshooting case present only in SKILL.md, a lost word in the base rules, a different RF10 wording, a different report section order). This PR had to edit WF12, WF13 and the Bingo note twice for exactly that reason. Fixing it means designating the checklists as the SSoT and reducing the single-pass file to mode-specific glue.
2. LC01 — no metadata.author in the frontmatter. Ownership is declared only at package level in plugin.json, while the checklist treats metadata.author as a stage-4 gate. Worth fixing together with validate.yml, which today never reads SKILL.md frontmatter and so cannot catch it.
3. WF15 — checklist paths handed to sub-agents are relative. The reviewed skill may itself have a references/ folder with colliding file names, and a sub-agent resolving references/checklist-structure.md against the reviewed folder would read the wrong file. Pass absolute paths, or paths relative to the reviewer's own folder.

🤖 Generated with Claude Code