develop-refactor

Develop Refactor

Announce at start: "Using the develop-refactor skill on 's findings."

Preconditions

• You were dispatched by develop-change with the findings of one review-conformance review against a code or architecture guidelines file, that file, the diff range and your task worktree path.
• Create the task worktree as the prompt says, from the change worktree you start in, and work only there. Commit on the task branch and leave it there. Do not merge it, and do not dispatch again.
• You fix what the findings state. You did not review the diff, and you do not review your own fix: the next review round does.

Steps

1. Read the guidelines file and the findings. Read the one file the prompt names and no other guidelines file. Each finding cites a clause as Heading N and a file:line.
2. Fix each finding at its line, as its clause states. Fix every place the same finding names; leave the rest of the code as it is.
3. Change no behavior. Do not change behavior: the tests you run must stay green. After each fix, run the tests the fix touches: those that verify what it changes, and those it adds or edits. Where the runner cannot select, run verify_commands. Commit each fix unsigned (git -c commit.gpgsign=false commit). Never delete, skip or loosen a test to keep those tests green.
4. Report a finding you cannot fix as not fixed, with the reason: a fix that would change behavior, a finding the code does not bear out, a clause that contradicts the floor, which is a finding against the clause, or a finding that needs an SDD or LLR item changed, or a different structure: you do not edit design items. The floor: every test carries verifies:; every test fails when the behavior it verifies: breaks; class B and C keep abnormal-input tests for every REQ and LLR; class C keeps tests at every touched SDD item's interface; every SDD item traces to a REQ; class C items have LLRs; a mechanism is stated for segregation between items of different classes; every third-party component is in soup.md; a cross-unit dependency is declared in depends_on:, with segregated_from: where the classes differ. The dispatcher decides each one.
5. Return the report below and nothing else: no diffs, no logs.

The report

task: <tag>
worktree: <path to the task worktree>
files touched: <paths>
fixed: <finding-N — what changed, or "not fixed — <reason>">   (one per line)
result: <N passed, N failed>

Red flags

Thought	Reality
"While I'm here, I'll tidy the rest of the file"	Fix the findings. Anything else is the next review's to find.
"This rewrite is cleaner and changes behavior only a little"	No behavior change. Report it as not fixed, with the reason.
"The test is in the way of the fix; I'll loosen it"	Never. The tests you run stay green as they are.
"This finding is wrong; I'll skip it quietly"	Report it as not fixed, with the reason. The dispatcher decides.
"The finding needs a design item reworded; I'll edit it"	Report it as not fixed. A design change goes through design-architecture, and its alternatives are the user's.
"I'll merge my task branch when I am done"	Leave it on the task branch. The dispatcher runs task-worktree.sh merge.

Done when

• Each finding is fixed or reported not fixed with its reason.
• Each fix is committed on the task branch, which is not merged.
• Those tests are green.
• The report is returned.