SCE Change to Plan

Execution contract

Own this workflow from input through its terminal user-visible response. Follow its steps, gates, and stops in order; do not add, skip, reorder, or merge them. Keep intermediate workflow state private and continue immediately until a defined wait or stop. Resume user waits in this same skill and session. Render user-visible output only from the named workflow layouts or reports. Do not expose raw internal state or add text around a rendered layout or report. Non-SCE helpers may assist, but must return to the active step without changing workflow order, gates, waits, writes, validation, stops, or terminal output. Do not invoke another SCE skill, package, or workflow command.

Phase references

Each numbered step below dispatches to a phase whose steps and boundaries live in a reference file. This document holds the control flow — which phase runs, what it receives, and how its result branches — and each reference holds the phase itself.

references/plan-template.md defines the plan file written to disk. The plan authoring phase points to it at the moment a plan is actually written, which never happens on a needs_clarification or blocked result.

Read a step's reference before taking any action for that step, not after. Read only the reference for the step you have reached: a run that stops at the bootstrap gate never authors a plan, which is why they are separate files.

Input

invocation input is the change request, in free-form prose.

• The change request is required.
• It may describe a new plan or a change to an existing plan. Do not resolve which one applies; step 2 owns that decision.

When invocation input is empty, report that a change request is required, state the expected argument, and stop. Do not infer a change request from the repository state or the conversation.

Pass the change request to step 2 unmodified. Do not restate, summarize, or pre-scope it.

Every {plan-path} and {candidate-path} emitted anywhere in this workflow is the path resolved in step 2 (plan.path, or an entry of candidates), so every emitted command is directly runnable.

For example: $sce-change-to-plan "add dark mode to settings".

Workflow

1. Load durable context

Read references/context-load.md, then run the Context load phase with the change request as the focus.

context/ is durable AI-first memory describing current state. Load it before planning so the plan starts from recorded truth. Where context and code disagree, the code is the source of truth.

Branch on status:

bootstrap_required -> context/ does not exist. Do not create it, and do not plan without it. Render the Missing context bootstrap gate layout from references/output.md.

Wait for the user. When they report the command ran, run the Context load phase again and continue in this session. Do not restart planning, and do not ask for the change request again.

loaded -> Continue to the next step.

Do not read context/ yourself. Do not repair drift or stale context; the brief reports it and the plan may schedule the repair.

2. Author the plan

Read references/plan-authoring.md, then run the Plan authoring phase with the change request and the complete loaded brief from the Context load phase.

Pass the brief verbatim. Do not restate, summarize, or reinterpret it.

This phase challenges whether the change is worth building before planning how to build it, and it decides on its own whether to stop at the clarification gate. Both shape what reaches the user, so reach them through the reference rather than acting from this summary.

Do not write or edit the plan file yourself.

Branch on status:

needs_clarification -> No plan was written. Present the result as prose. Do not print the raw result. Render the Clarification gate layout from references/output.md.

Render one ## block per entry in questions, in result order. Use the question's id, category, question, and why_blocking fields exactly as returned.

Do not answer the questions. Do not assume answers. Do not write a plan. Stop and wait.

blocked -> No plan was written. Render the Blocked layout from references/output.md, drawing its issues from issues and, when candidates is present, its candidate paths from candidates. Do not print the raw result. Stop.

plan_ready -> Continue to the next step.

3. Determine the continuation

Render the plan_ready result as the summary defined by the Plan authoring phase in references/output.md. Follow that layout exactly. Do not print the raw result.

Take the next task from next_task. A plan_ready result always names one. Do not evaluate its dependencies; the Plan review phase checks them when the emitted command runs and returns blocked if they are unmet.

The workflow carries one of two explicit continuation shapes across a same-session wait:

• Initial-clarification continuation: original_request, clarification_answers, and loaded_context_brief. original_request is the unchanged request from step 1; preserve it with the answers and never ask the user to provide it again.
• Existing-plan revision continuation: plan_path, correction, and loaded_context_brief. plan_path identifies the plan already written, and correction contains the user's requested revision.

The plan was written from one prose request, so its assumptions are guesses about what the user meant, its scope is one reading of the request, and its task boundaries are the author's judgement. The user has seen none of it until now, and every one of those is cheaper to correct here than after a task has been built on it. A user who does not know revision is on the table will implement a plan they would have changed.

Write task rather than tasks when total_tasks is 1.

Offer revision, but do not gate the handoff on it, do not manufacture concerns, and do not ask the user to confirm the plan. When the summary lists open questions, leave them in the summary only — do not restate them in the continuation, do not answer them, and do not block the handoff on them. Blocking questions belong in needs_clarification (step 2), not here.

Render the Ready continuation layout from references/output.md.

Then stop and wait. Do not implement, and do not run the handoff yourself.

4. Revise the plan on request

When the user answers clarification questions from step 2, resume the Initial-clarification continuation with original_request, clarification_answers, and the current loaded_context_brief. Preserve original_request unchanged and never ask the user for the original change request again. When the user answers open questions listed in the summary or requests changes to an already-written plan, resume the Existing-plan revision continuation with plan_path, correction, and the current loaded_context_brief. Do not ask them to rerun /change-to-plan.

Reuse loaded_context_brief when the revision stays within the focus it covers. If the revision materially expands the plan into an area the brief did not cover, rerun the Context load phase for the expanded focus before running the Plan authoring phase. Do not reload context for revisions already covered by the brief.

An answer that resolves a doubt removes that open question. An answer that does not resolve it leaves the question standing; do not drop it because the user replied to it. If the reply raises a new doubt, the revised plan carries a new open question.

Pass clarification_answers or correction as written. Do not restate, soften, or pre-scope it. The Plan authoring phase owns resolving it against the existing plan, and owns preserving completed tasks and their evidence.

Branch on status exactly as in step 2. A revision may legitimately return needs_clarification or blocked.

On plan_ready, render the summary again and the continuation exactly as in step 3, replacing is ready with revised in the heading.

Revise as many times as the user asks. Each revision is one invocation of the Plan authoring phase against the same plan.

When the user signals the plan is good, or asks to begin, return the handoff without re-authoring the plan. Say so plainly if questions are still open: the user may proceed over an unresolved doubt, and that is their call, but do not record it as resolved.

Stop.

Rules

• Plan at most one change request per invocation. Revisions to the plan that request produced are part of the same invocation, not a second request.
• Read each phase's reference before running that phase.
• Do not gate the handoff on open questions listed in the plan summary. Blocking questions return needs_clarification before any plan is written. Offering revision is not the same as demanding it, and inventing doubts to justify a review gate is not allowed.
• Do not suppress, soften, or answer an open question or clarification question on the user's behalf.
• Do not defer the user's revision to a rerun of /change-to-plan, and do not defer it to the implementation phase. Revise the plan here.
• Do not narrow, expand, or reinterpret a revision the user asked for. Pass it to the Plan authoring phase as written.
• Do not duplicate the internal instructions of embedded phases.
• Do not plan before durable context is loaded.
• Do not bootstrap context/ yourself. sce setup --bootstrap-context owns that.
• Do not modify any file under context/ outside context/plans/.
• Do not implement any part of the plan.
• Do not ask for implementation confirmation.
• Do not run task execution, context synchronization, or full-plan validation.
• Do not emit a /validate command. This workflow always hands off to /next-task.
• Do not answer the skill's clarification questions on the user's behalf.
• Do not execute the continuation returned at the end.
• Do not infer success when the Plan authoring phase returns a non-plan_ready status.