Slice planning

Write one sufficient executable plan for one understood story, a bounded retrospective correction, or remaining work from an understood instruction as described below. Stay within the triggering human or parent-agent instruction's explicit execution authority. Do not implement product code or invoke execution unless that instruction explicitly also requests execution after planning.

Require understood planning input

Require one user or stakeholder outcome, its value, evaluable key examples, and boundaries from later work. Name the missing field and stop; do not invent a story, seed, or completed plan slices. Use dough-story-refinement when a selected story's goal, scope, or examples are unresolved. Use dough-story-decomposition when the parent problem, candidate selection, or story ordering is unresolved. Never turn a decomposition seed directly into an execution plan. An understood instruction may be the source without a story. When its mission was admitted, plan that admitted story instead: the plan attaches to it, never to another story.

For a correction handed off by dough-execution-retrospective, use its evidenced current findings, one bounded correction outcome, affected concepts, preserved product promises and constraints, and evaluable proof as the planning input. Cite the original story and reviewed commits for provenance; do not invent a feature promise or require the correction to fit the old story's implementation footprint. The retrospective owns current-truth checks, constraint disputes, and whether to amend an unfinished plan or create a follow-up. Missing correction scope or proof stops this planning path.

For a new follow-up, write its minimal story and then its plan as planning scope and lifecycle defines; record preparation on that story. An amended plan or a plan-homed correction keeps its existing home and identity.

Resolve execution context

Before writing, identify from the user's instructions and this project's guidance:

• the selected story and its seed, when one exists, the retrospective correction input, its source execution, and the seed hosting its story, or the understood remaining-work instruction and any retained execution identity;
• the executable-plan root, filename layout, format additions, status vocabulary, and lifecycle;
• any supplied slice target and hard limit, including their permitted exceptions and overrun escalation;
• required verification, refactoring, commit, and review gates;
• relevant code, tests, stack rules, and Accepted ADRs;
• this project's established North Star location, when one exists; and
• any phase or quick-task conventions that own the plan.

Resolve these from this project, not this skill's location. First reuse a plan that is active under this project's status vocabulary and identifies that source. Honor the retrospective's unfinished-plan amendment destination. Otherwise, inspect the established plan entries in the known root: use the number after the highest allocated entry, preserving its numeric padding and path layout rather than filling an old gap. Immediately before writing, recheck the candidate path. If it is occupied, leave it unchanged, advance to the next number, and check again. Do not add allocation or locking tooling.

If the canonical plan root is unavailable, name that missing context and stop before writing; do not ask for a plan number or invent a location. A missing numeric limit alone is not missing context: apply the linked sizing guidance without inventing a timing policy. Do not create a new plan under a deprecated or merely inferred location.

Treat a verification gate as a local requirement only when the user's instructions or this project's guidance require it for local work, and cite that requirement in the plan. Hosted CI configuration shows which checks exist and how to run them. Hosted CI still runs them after publication, where their failures stay owned, but its configuration does not by itself make each check a local gate for every change. Choose local proof for the affected behavior under own executable proof, and state in the plan the reason for any broader local check, such as a changed fixture that distributed consumers load. Execution applies the same distinction when it accepts proof.

Write the plan

Before writing to the plan, establish or reuse the required workspace under preparation workspace, then, for a queued story, announce the preparation assignment; inspecting the story, code, or tests to prepare the plan needs neither on its own. Record the source, goal, included scope, material exclusions, assumptions, and key examples without enlarging that source. Read and apply:

• architectural thinking to carry PFE findings, relevant accepted decisions, and only warranted short-term direction into the plan;
• slice decomposition, including its cumulative design assessment, sizing, and escalation rules; and
• executable-plan decisions, including executable proof ownership.

Inspect only the code and tests needed to find the stable outside-in proof entry point, behavior to extend or preserve, genuine dependencies, decisive premises, and any Structure justified under the linked slice decomposition rules. A decisive premise is a factual claim about this project's current state on which a slice's approach, sizing, or proof depends; settle each one before ready.

During construction, apply those decomposition, cumulative design, and sizing checks: correct obvious defects such as an independent second outcome before assessing readiness, and preserve proof ownership and any supplied sizing constraints on every resulting slice.

After the plan file exists for a work item with a recorded identity, apply record preparation facts for the planned approach (omit assessment on that write).

Resolve fixable plan concerns

When remaining concerns about slice boundaries, cumulative design, proof ownership, or sizing can be resolved within the understood outcome and scope, invoke dough-slice-plan-refinement on the written plan before the readiness assessment. This refinement is part of slice planning and needs no additional instruction; honor an explicit instruction to leave refinement to a later step. A plan without such concerns needs no refinement pass.

Keep unresolved source questions and human-owned decisions outside this handoff. Handle a missing input, disputed constraint, or concern that refinement cannot resolve within scope under the next section; do not repeat refinement without new evidence or widen the outcome. Refinement keeps the same plan, preparation workspace, and assignment. It grants no execution authority.

Record concern evidence and assess readiness

After constructing the plan, record its concern evidence in the plan, then record readiness through the shared procedure:

• In one line, whether refinement ran, was not needed (with the reason), or was left to a later step as instructed.
• Each remaining slice-specific concern with the affected slice, the reason (for example an integration assumption or repeated special-case design), and its consequence (for example uncertain sizing or duplicated domain rules), including concerns spanning successive slices. When this review identified none, the plan says so narrowly.
• Interim behavior that slice decomposition permits is an accepted trade-off, not a remaining concern, once the plan names it and its replacing slice. Relabeling a blocking concern, such as a proof gap, does not settle it.
• Then apply assess readiness at preparation completion: every remaining concern becomes a not-ready reason, and neither refinement nor an accepted trade-off establishes readiness alone. A recorded blocking dependency is not such a concern; its agreement alone blocks the start, so a plan settled apart from waiting on its suppliers records ready. Do not prescribe the next workflow action, Take the item, or start execution from this finding.
• A missing input, disputed constraint, or human-owned decision that refinement cannot resolve needs a response: report the expected response, who can give it when known, and what waits for it. A concern the plan bounds with an authorized early probe slice needs none; the plan and the recorded reasons carry it.

The recipient chooses the next action under the triggering instruction's authority and project policy. The recorded assessment is agent judgment bound to content digests, not authorization to execute. It does not grant, expand, or replace the triggering instruction's execution authority.

Stay within the triggering instruction

After writing the plan and recording its assessment, the next action remains within the triggering human or parent-agent instruction:

• Planning-only request, or a continuation from story refinement: do not implement and do not invoke execution. The plan and the story's record hold the slices, exclusions, refinement decision, concerns, and assessment; the session finishes under the preparation journey's finish with only what needs a response.
• Parent-agent delegation that asks only for slice planning: return the plan path, the refinement decision and concerns, and the recorded readiness assessment to the parent. The parent's broader implementation task is not an explicit execution request to this planner.
• Explicit plan-and-execute request: once the assessment is recorded, the authorized workflow may continue into execution without asking again for the same authorization, subject to this project's gates and any unresolved concerns that still block progress. Prefer the project's established execution path (for example dough-execute-plan) when that path applies.

When this session ends, follow land at the end of preparation, then close or retain the workspace under preparation workspace. An execution instruction for this story that arrives while its preparation is unlanded follows hand off to execution in the same session instead.