/apply-turbo-handoffs

name: apply-turbo-handoffs
description: "Audit the turbo lessons /self-improve wrote to .turbo/handoff/ and apply approved ones. Use when the user asks to \"read .turbo/handoff and let me know what you think\" or \"process the turbo handoffs\"."

Apply Turbo Handoffs

Task Tracking

At the start, use `TaskCreate` to create a task for each step:

1. Audit the handoffs 2. Act on the user's reply 3. Apply the approved changes 4. Close out the handoffs 5. Run `/stage-commit-push` skill

Step 1: Audit the Handoffs

Read every file in `.turbo/handoff/`. Audit the handoffs that propose lessons for turbo files. Name any handoff that instead carries a session's in-flight work, and leave it untouched. When no lesson handoff exists, present "No lesson handoffs in `.turbo/handoff/`." Mark Steps 2 through 5 completed, then use the TaskList tool and proceed to any remaining task.

Take each handoff's evidence as a record of the incident, and audit its remedy against the file it targets before recommending any of it:

• **Gap** — confirm the gap still exists in the current text, is not already handled elsewhere in the skill, its references, or the `SKILL-CONVENTIONS.md` of the edition the target lives in (`claude/` or `codex/`), and was not already rejected by a decision recorded in auto memory or the target's git history.
• **Diagnosis** — ask whether the real finding is that the skill should not have run there, or that nothing was broken, rather than that the skill must handle the case.
• **Remedy** — check the proposed text against the conventions and against what the target skill's other steps depend on. Prefer generalizing an existing rule over adding one more special case to it.
• **Genericity** — strip anything tied to the originating project so the rule states the shared shape alone.
• **Weight** — weigh how often the new rule would fire against how often it would help.

Output a verdict per lesson as text: apply as proposed, apply adjusted (with the adjusted wording or placement), or drop, each with the reasoning that decided it. Name any lesson that should stay in its target's edition alone, as an intentional divergence recorded in both `claude/CLAUDE.md` and `codex/AGENTS.md`. Be willing to conclude that none of it should ship.

Close with how to reply: approve the verdicts as they stand, describe what to change, or hold a lesson back for a later session. Then end the turn.

Step 2: Act on the User's Reply

• **Revise** — apply the user's corrections to the verdicts. When a correction raises a question the audit did not cover, investigate it first. Then re-present the changed verdicts, close with Step 1's reply guidance, and end the turn again.
• **Approve** — the verdicts are settled, and this approval covers the commit in Step 5. Continue to Step 3.

Step 3: Apply the Approved Changes

When any lesson approved to apply edits a skill, run the `/write-skill` skill once for the whole batch of them. Make all of the lessons' edits in their approved form, following the edition-mirroring rules in the target edition's `claude/CLAUDE.md` or `codex/AGENTS.md`, before that skill's review begins. Edit non-skill files such as docs directly.

When the applied edits depart materially from the approved verdicts, such as review findings rewriting an approved rule or a lesson turning out not to fit, present each departure and end the turn. Continue from the user's reply.

Step 4: Close Out the Handoffs

Delete each audited handoff whose lessons were all applied or dropped. For a handoff that still holds a lesson the user held back, remove the resolved lessons from it and keep the file.

When no tracked file changed, present that nothing was committed. Mark Step 5 completed, then use the TaskList tool and proceed to any remaining task.

Step 5: Run `/stage-commit-push` Skill

Run the `/stage-commit-push` skill.

Then use the TaskList tool and proceed to any remaining task.