dough-slice-planning git:20261010.e95c90dA

Immutable. This exact content never changes and is served at /api/v1/blob/efe600907f1b3160.

---
name: dough-slice-planning
description: >-
  Plans one understood, bounded story, retrospective correction, or remaining
  work from an understood instruction as an executable sequence of
  Behavior/Structure slices with outside-in proof and safe stopping points. Use
  when a selected story is ready for implementation planning, an execution
  retrospective has one bounded correction to plan, or authorized remaining
  work from a sufficient instruction needs an ordinary plan. Stays within the
  triggering instruction's execution authority: finish after writing and
  reporting the plan unless that instruction explicitly also requests execution.
  Invokes slice-plan refinement when remaining plan concerns can be resolved
  within the understood outcome, then reports remaining concerns or a limited
  no-concerns finding and records readiness through the shared preparation
  procedure without granting Take or execution.
---

# 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](../dough-story-refinement/SKILL.md) when a selected
story's goal, scope, or examples are unresolved. Use
[dough-story-decomposition](../dough-story-decomposition/SKILL.md) 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](../dough-execute-plan/references/admit-accepted-work.md), plan that
admitted story instead: the plan attaches to it, never to another story.

For a correction handed off by
[dough-execution-retrospective](../dough-execution-retrospective/SKILL.md#reconcile-findings-with-current-truth),
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](../dough-story-refinement/references/planning.md#choose-the-planning-level)
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](../dough-story-refinement/references/executable-proof.md),
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](../dough-execute-plan/references/wrap-up.md#accept-proof).

## Write the plan

Before writing to the plan, establish or reuse the required workspace under
[preparation workspace](../dough-story-refinement/references/preparation-workspace.md),
then, for a queued story,
[announce the preparation assignment](../dough-story-refinement/references/preparation-assignment.md#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](references/architectural-thinking.md) to carry
  PFE findings, relevant accepted decisions, and only warranted short-term
  direction into the plan;
- [slice decomposition](../dough-story-decomposition/references/problem-decomposition.md#decompose-slices),
  including its cumulative design assessment, sizing, and escalation rules; and
- [executable-plan decisions](../dough-story-refinement/references/planning.md#write-an-executable-plan),
  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: code and tests, host or environment state,
fixture content, workload data, or a named proof or measurement command. Inherited
premises such as "works as today" count the same as those you write.

Derive premises from key examples: trace each from trigger to observable result through
existing code. Every step assumed to behave is decisive, written down or not, including
colliding overlays or rules and transformations from fixture inputs to their evaluation.
A premise is settled only when its recorded observation reaches the consuming operation
in the checkout the plan names and records the promised outcome: the example's result,
or a proof's failure without the behavior it claims to prove. "Exists", "found", "callers
listed", "step defined", "server answered", and "no commit to the spec since" are
presence, not settling; leave the premise open and name the unreached operation.
A claimed fix is a premise: reproduce the symptom before dependent work. A remedy spec
that already passes leaves the symptom unexplained. Run an existing fixture when it can
observe the journey cheaply and safely, instead of reading call sites.

Before `ready`, use the smallest safe observation reaching the claim's outcome, wherever it lives.
Reading, searching, listing, and read-only host queries locate it; presence cannot settle it:

- For a behavior-consumer premise (dependents, paths, or effects of a change), follow the
  effect from its state write or server response through every transformation to what
  asserts or relies on it. Search tests and all callers, including scripts, step definitions,
  and specs that drive HTTP sequences, rather than only names or direct imports.
  With a cheap local suite, the smallest complete observation is one scratch application
  of the planned change, one relevant test run, and a revert; failures identify consumers.
  For a moved function reached through a script, run the feature's script steps with a
  scratch failure in the function; record that step's failure. Caller traces or unit imports do not settle it.
- For a proof premise (a named test proves a behavior), observe discrimination: it fails
  with the behavior disabled in a scratch edit and passes with it enabled. If it stays
  green without the behavior, record the premise false and give the slice a discriminating proof.
- For a proof-route premise (an example runs through a route in a named checkout), execute
  its unpaid, side-effect-free prefix there (runner spec selection, tools, token route, or log source),
  stopping at the first paid, credentialed, owner-held, or state-changing step. A refusal or
  missing step makes the route unavailable. Name an available route (CI or the primary checkout
  under this project's rules), or record the missing step and decision owner as an early probe slice or
  pre-Take decision. Reachability without the example's real shape (authenticated write or attached file) is presence.

Scratch observations run only in the preparation's owned workspace, never a default or shared
checkout; revert scratch edits before any record write or commit. For uncertain infrastructure
or storage behavior, use one isolated representative proof against the relevant engine and
version, unless matching evidence exists. Record each premise, its consuming operation, the
literal observation reaching it, and its result in the plan. A false premise changes the plan
before broad implementation. Do not inspect claims the approach does not depend on, and keep
experiments off shared and production systems.

When only a paid, credentialed, owner-held, or state-changing observation can
settle a premise, observe its cheap parts now and make the remainder an early
probe slice whose failure stops dependent slices and changes the plan. Such a
plan can be `ready`; the probe's observation keeps its existing authority
requirements.

During construction, apply those decomposition, cumulative design, and sizing checks: correct
obvious defects such as an independent second outcome before reporting, 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](../dough-product-backlog/references/record-preparation.md)
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](../dough-slice-plan-refinement/SKILL.md)
on the written plan before the final report and 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. Report 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 neither execution nor publication authority.

## Report concern evidence and assess readiness

After constructing the plan, report, 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, say 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](../dough-product-backlog/references/record-preparation.md#assess-readiness-at-preparation-completion):
  every remaining concern becomes a `not-ready` reason, and neither refinement
  nor an accepted trade-off establishes readiness alone. Do not prescribe the
  next workflow action, Take the item, or start execution from this finding.

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 and reporting the plan, the next action remains within the
triggering human or parent-agent instruction:

- Planning-only request: report the plan path, ordered slices,
  considered-but-excluded additions, the refinement decision and concern
  report, and the recorded readiness assessment, then stop. Do
  not implement and do not invoke execution.
- Parent-agent delegation that asks only for slice planning: return the plan,
  the refinement decision and concern report, 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: after reporting, 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](../dough-execute-plan/SKILL.md)) when that path applies.

Apply [preparation workspace](../dough-story-refinement/references/preparation-workspace.md)'s
keep or discard decision, then close or retain the workspace, when this
session ends.

After the matching case above, end with:

`## SLICE PLAN WRITTEN`