Plan Phases

/phase-plan

Take an existing flat or unstructured plan and restructure it into phased execution. Add /verify gates after each phase and critical outcome. Add blocking gates before actions whose safety prerequisites must already be true.

Structured execution spec: protocol.yon. Read it for the canonical rules and step sequence; this file is explanation. The two must stay in sync — if you edit one, update the other and refresh the @STAMP date.

Plan Restructuring Protocol — transforms any plan into a gated, phased structure for structural legibility and explicit checkpointing. Restructure, never delete. All original content is preserved.

What is /verify?

/verify is a verification gate — a point where execution stops and the current state is validated before proceeding. When you encounter a /verify gate in a restructured plan:

1. Review what the gate specifies
2. Verify each condition is met
3. Only continue to the next phase/step once the gate passes

If /verify is not a recognized command in your session, replace it with an explicit user confirmation prompt: pause, state what you're verifying, and wait for the user to confirm before continuing.

A /verify gate may sit before or after an action. It must block before mutation when it proves a prerequisite whose absence would make the action unsafe. Examples include authorization, no-follow target resolution, backup or readback readiness, live-data scope, and destructive-target confirmation. Retain a separate gate after the action to verify the intended outcome.

Phase 1 — Locate & Load Existing Plan

1. Find the plan — check implementation_plan.md, PLAN.md, task.md, recent conversation context, or user-provided file. Load the full content. If multiple candidates exist, use the most recently modified file and note the choice.
2. Assess structure — flat (single list)? Partially phased? Missing verification steps? Identify structural gaps.

If no plan is found after checking all locations → stop. Ask the user to provide the plan before continuing.

Phase 2 — Decompose Into Phases

1. Identify natural phase boundaries — group related steps by dependency order, component, or concern. Each phase must be independently verifiable. Mark critical steps that need individual /verify gates.
2. Define phases — each phase needs:
   • Clear name
   • Goal / deliverable
   • Ordered steps
   • Success criteria

Ensure phases flow logically — dependencies before dependents.

Phase 3 — Insert Check Gates

1. Phase-level gates — insert a /verify gate after every phase. Gate focus must be specific to what that phase accomplished and what the next phase depends on.

2. Critical step gates — identify steps within phases that warrant individual /verify gates:

   • Risky operations
   • Breaking changes
   • Schema migrations
   • Cross-package impacts
   • Security-sensitive changes

   For each critical step, place any safety-prerequisite /verify gate before the step, then place an outcome /verify gate immediately after it.

Gate Quality Reference

A gate must validate something observable. If it can't fail, it's ceremonial.

The bad gate has no observable condition. The good gate has three specific pass/fail criteria a different person could verify independently.

Gate Placement Rules

• MUST insert a /verify gate after completing any phase
• MUST insert a blocking pre-action /verify gate when authorization, no-follow target proof, backup or readback readiness, live-data scope, destructive-target confirmation, or another safety prerequisite must be established before mutation
• MUST retain a separate post-action /verify gate for the operation's outcome; a safety prerequisite cannot be validated only after the action
• MUST insert an inline post-action /verify gate after any schema migration, breaking change, or security-sensitive step
• MUST insert an inline /verify gate after any step with cross-package impact
• SHOULD split phases with >5 steps into sub-phases with intermediate /verify gates

Phase 4 — Rewrite & Output

1. Rewrite the plan — in its original format (implementation_plan.md, PLAN.md, or task.md) with the new phased structure. Preserve all original content — restructure, do not delete. Each phase should clearly show: steps, /verify gate, and what the gate validates. If the plan has no source file (existed only in conversation context), output the full restructured plan as a fenced code block in the response instead.
2. Diff report — summarize what changed: how many phases created, how many /verify gates added, any steps reordered or split.

Rules

• MUST preserve ALL original plan content — restructure, never delete
• MUST maintain original intent and goal alignment
• MUST use the same file format as the original plan
• MUST NOT add new scope or features not in the original plan
• MUST NOT create ceremonial /verify gates with vague focus

Next Steps

• /plan-execute — implement the newly phased plan
• /double-check — verify the restructured plan before executing

Human output. This skill's handler-facing output obeys the human-output contract (human-output/SKILL.md).

Next skills. On completion, run the Next Skills protocol (next-skills/SKILL.md): surface the next-skills recommendations from front-matter for the caller to pick. Offer only — never auto-invoke.

Self-improvement. On completion, run the Self-Improvement Protocol (self-improve/SKILL.md): if this run surfaced a concrete, blocking-or-recurring weakness in this skill, propose a specific fix for the handler to approve. Conservative — silent otherwise. Never auto-apply.