sw-review
Use when the user asks for a task's implementation or change to be reviewed, or wants a second pair of eyes on it, without implementing anything, or invokes sw-review with a task id.
SKILL.mdskills/sw-review/SKILL.md
GitHubsw-review
Has one task's change reviewed by the reviewer role, on request and on a task of any status. It changes no file and no status: the review is a report, and what follows it is the user's call. The one file it may write is a follow-up task, on a done task with blocking findings, after the user says yes.
It defines no role and repeats no review rule: the reviewer is reviewer.md, dispatched as sw-implement's review row dispatches it. Run commands from the project root. <skill-dir> is the directory this SKILL.md is in.
Steps
Pick the task. Id given:
node docs/.sw/sw.mjs check <ID>, then readdocs/tasks/<ID>.md. No id: ask which task, offering the tasksin-progressand the most recentlydoneones fromnode docs/.sw/sw.mjs status. Any status is reviewable; a blocked ordonetask is no reason to stop.Find the files. A
donetask: the files its## Summarylists under "Changes". Otherwise the files the user names; without any,git status --porcelainand the files the task file names. Show the list and ask when it is empty: a review with no files reviews nothing.Checks that need the environment. As sw-implement step 4: each
needs:in the plan, if there is one, and any check the user names; ask which may run, unless a standing answer in the user's first message already says. Without a yes a check isnot allowed.Dispatch the reviewer: the review row of sw-implement's "Dispatching", to a fresh reviewer by its "How to dispatch" table, with
<ID>,Files:from step 2 andChecks:from step 3.Recheck:only when the user hands over the findings of an earlier review, word for word. Do not review the change yourself in place of the reviewer, and do not fix anything it finds.Report the verdict, the claims, each finding with its severity and the
Not checked:list as the reviewer gives them, in the user's language, then the next step:- a task
in-progressortodo: the blocking findings are entries for sw-implement's fix round; say so and stop; - a task
donewith blocking findings: offer one follow-up task. Create it only on yes, as sw-plan step 1 creates new work: id fromnode docs/.sw/sw.mjs next-id <AREA>, file fromdocs/.sw/templates/task.mdwith a "Goal" that links[[<ID>]]and the findings as its "Done when" items,## [date] task | <NEW> createdappended todocs/log.md, thennode docs/.sw/sw.mjs index; - a defect worth remembering: offer a
type: lessonpage, as sw-implement step 11 does, and write it only on yes.
Nothing else is written: not the task's status, not its file, not the log, not the task list.
- a task