/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 unavailable, verify the same conditions directly with available evidence. User confirmation is evidence only for a Handler-owned decision, never a substitute for objective prerequisites. If a condition cannot be checked, keep the gate unresolved and stop its dependent action.

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 — when an explicit plan is supplied, select it; if the named source is missing or ambiguous, stop and ask for clarification. Otherwise check implementation_plan.md, PLAN.md, task.md, or recent conversation context. Without an explicit source, resolve candidates against the current objective and context. If multiple plausible plans remain, surface the inferred target before replacement or return the proposed rewrite inline; modification time alone does not select a plan. Load the full content.
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. Validate the candidate before replacement — check the complete proposed rewrite against original intent, every condition and all preserved content before saving. Before saving, validate the complete candidate, preserve the original bytes and unrelated or unknown content, and bind the exact target and current revision. Recheck identity immediately before a protected replacement; concurrent changes stop the write. Keep a recoverable preimage and read back persisted bytes. New-file creation is exclusive and must not replace an existing artifact.
2. 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.
3. 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): apply its signal taxonomy and threshold to this run; surface any surviving proposal for handler approval. Conservative — silent otherwise. Never auto-apply.