/cycle

allowed-tools: Read, Write, Edit, Glob, Grep, AskUserQuestion, LSP, mcp__ide__getDiagnostics, Bash
description: Draft, critique and merge a plan in one loop, then stop for approval
argument-hint: plan name
disable-model-invocation: true
model: opus
effort: high

You are running the whole planning loop in one pass: research the codebase, draft the plan only when the user has not written one, critique it, merge the findings, repeat, then stop and wait for approval.

This skill never executes the plan. It ends at the approval gate.

Fixed rules:

Read the working agreement at [working-agreement.md](../../working-agreement.md) before step 1 and follow it for the whole run. If that path does not resolve, look for `working-agreement.md` in the project root, then in `.claude/`. If it cannot be found anywhere, tell the user it is missing and apply the rules listed below.

These rules bind this phase and override any step below that conflicts with them:

1. Never execute the plan, and never write, edit or refactor project code during this run. This phase produces a plan folder, a `plan.md`, a `critique.md` and a `cycle-log.md` and nothing else. The user approves before anything is built. 2. The user owns the plan. Draft `plan.md` only when it is empty or still the unedited template. When it holds text the user wrote, never overwrite it, and never drop the user's requirements, wording or constraints while merging. 3. Never assume, ask. Change `plan.md` on your own only when the change a finding asks for is obvious. Stop and ask the user whenever it is not: the finding is ambiguous, it touches a requirement or a constraint the user wrote, it changes the scope or the intent of a chapter, it rewrites more than the finding covers, or two findings pull in different directions. Show the finding, the exact edit you propose and the alternatives, then apply the answer. A doubt is a question, never a guess. 4. Be adversarial in every iteration. Try to refute each finding before you write it down, and report only what survives the attempt. 5. Grade confidence per finding. Report a finding as CONFIRMED only when you verified it against the codebase. Label everything else UNVERIFIED and state what you could not check and why. Prove every finding with a `file:line` reference, a command output, or a failing test. 6. Re-read `plan.md` from disk at the start of every iteration and cite line numbers only from that copy. Merging shifts every line below the merge point, so numbers carried over from an earlier iteration are wrong. 7. Verify what you merge, not only what you find. A suggested solution is a claim like any other: run the command before you write it into a verification section, and check every line reference in it against the file it names. An unverified fix is not merged, it is asked about. A merge that ships a broken command costs the next iteration. Run only commands that read: this phase verifies, it never builds, installs, migrates, commits or writes anywhere outside the plan folder. 8. Merging is automatic for the obvious changes only, and never silent. Record every merged finding, every finding you asked about with the answer you got, and every skipped finding with its reason, in `cycle-log.md`, and print the same summary after each iteration. 9. Stop early when an iteration surfaces no new findings. Respond "No new findings." and go to the approval gate. 10. Be brief. No filler, no preamble, no restating the request. No emojis, no em dashes, no bold or italic text.

To do this, follow these steps precisely:

1. Display the following banner before doing anything else:

   +-------------------------------------------------+
   |  Plan Critique v2.6.1 - Plan cycle              |
   +-------------------------------------------------+

2. Read `.claude/plan-critique-config.json` and get `plansFolder` path from settings. If the file doesn't exist or `plansFolder` is not set or is an empty string:

• Ask the user: "Where would you like to store your plans? Provide a folder path (default `.planning`):".

By default, the user should be presented with the option `.planning`.

• Save the path as `plansFolder` in `.claude/plan-critique-config.json`
• Create the folder if it doesn't exist
• Create an `archived/` subfolder inside it

3. Read the optional `cycleIterations` value from the same config file. It is the maximum number of critique and merge iterations for this run. Default to `3` when it is missing, and clamp any value outside the range 1 to 5. 4. Get the Claude Code process ID by running: `echo $PPID`. Store this as `sessionPID`. 5. Clean up stale sessions: Scan `[plansFolder]/.sessions/` for files. For each file named with a PID, check if that process is still running via `kill -0 [PID] 2>/dev/null`. If the command fails (process not running), delete that session file. This is non-blocking cleanup. 6. Read the current session's plan from `[plansFolder]/.sessions/[sessionPID]` if it exists. Store as `sessionPlan`. 7. Scan `[plansFolder]/` for subdirectories (each subdirectory is a plan). Exclude `archived/` and `.sessions/` folders and any files, only list plan directories. 8. Select the plan for this cycle:

• If `$ARGUMENTS` is a slug that matches an existing plan folder, select that plan.
• Else if `$ARGUMENTS` is not empty, treat it as the name of a new plan and create it by following the plan

naming and folder creation steps of [../create/SKILL.md](../create/SKILL.md): the slug rules, the name collision check, the folder creation and the `plan.md` template from [plan-template.md](../create/plan-template.md). Do not display the create banner.

• Else if `sessionPlan` exists and matches a plan folder, auto-select it and inform the user:

"Using current session plan: [sessionPlan]"

• Else if exactly one plan exists, auto-select it and inform the user.
• Else if plans