/plan

name: plan
description: 'Shape a request into one end-to-end slice with observable behavior; review write scope and reversible decisions. Use when: planning, breaking down or scoping a change.'
practices:
- bdd-gherkin
- design-by-contract
- ddd-bounded-context
hexagonal_role: domain
consumes: []
produces: []
output_contract: 'in-place caller intent update or concise proposed amendment; never an AgentOps planning artifact'
context_rel: []
skill_api_version: 1
user-invocable: true
metadata:
  graph_root: true
  tier: execution
  dependencies: []
  capabilities: [shape_intent, define_acceptance, bound_write_scope, resume_discovery]
  effects: [update_intent_source]
  canonical_status: canonical
  disposition: keep
  triggers: ["write scope", "scope boundaries"]

Plan

Shape missing intent into one actionable slice, then stop. A clear change can proceed directly; load a specialist only for the question it answers. Prefer the caller's tracker, if any; otherwise use the conversation or supplied text. Supplied advice, such as an [Idea Genie](../idea-genie/SKILL.md) portfolio or challenge, is evidence to weigh, never a decision.

A plan meets these rules

1. **One slice, not a roadmap.** Shape the narrowest change that produces an observable result end to end, through every layer it touches. No phases, no layer-by-layer breakdown, no backlog: later work stays one coarse line each until new evidence makes it the next slice. When several slices could go first, prefer the smallest observable path that tests the approach's riskiest dependency. Outcomes that are each useful and checkable alone are separate plans, not slices: unless the request, the tracker or Navigate already settles which comes first, ask (rule 3) and keep the rest under Later. Named providers, devices or data sources are coverage of one outcome; separate them only when no shared path can meet a named requirement, and keep parts together when specifying one alone would mean guessing behavior it shares with another. Name any stand-in and what it cannot establish; a demonstration with that stand-in is not proof of the real integration. 2. **An example before any design.** Write at least one Given/When/Then with an observable result. Cover the boundary where a mistake is costly to undo, such as a repeated or external side effect, lost data or widened access, not only the happy path. 3. **Look up facts; ask only for choices.** Read code, docs and the tracker instead of asking. Ask the caller at most one question, only for a choice no source can answer, with your recommendation and its tradeoff. When several choices compete for it (which outcome comes first, a rule 7 conflict, a recorded decision under [Who decides](#who-decides)), ask the one that most changes the slice and list each other under Later with what it would change. If several block acceptance, [Interview](../interview/SKILL.md) settles them one per turn. 4. **The repository's words.** Reuse the term its code, glossary or tracker defines; never coin a parallel name. 5. **Scope by consumer.** Name the owners to edit, every live caller and test of the changed behavior, and generated companions as a class, as repository-relative patterns. Scope is authority, not a predicted file count: a live consumer outside it goes to the caller as an exact-file amendment, while independent in-scope work continues. 6. **A discriminating check:** what fails today and passes after the slice. 7. **Unrequested mechanisms earn their place.** A guard, retry, fallback, option or abstraction nobody asked for joins the slice only when a contract requires it, when without it a traced failure would go unseen by anyone able to fix it in time, or when adding it later is costly: persisted data or formats, interfaces others depend on, payments, security. Use its smallest form and judge each add-on the same way; when unsure, leave it out and name it under Later with the evidence that would require it. If a failure of the slice would reach no one who can act, making it visible is part of the slice. No safeguard narrows requested behavior; a real conflict is the Question.

Output

Write this block into the caller's existing intent when the request or existing authorization covers editing it (the conversation always does); otherwise return it as a proposed amendment. It is the whole plan.

Outcome:  <who observes what, in the repository's terms>
Example:  Given <state>, when <event>, then <observable result>
Slice:    <the one end-to-end change that makes the example true>
Scope:    <owners>; consumers: <live callers and tests>; generated: <class> | none
Check:    <the test or observation that fails now and passes after the slice>
Question: <one caller choice, your recommendation, its tradeoff> | none
Later:    <deferred item and the evidence that would make it next> | none

Add an Example line only for another consequential boundary, an Open line for a fact only a named person holds (with the drafted questions), and a non-goal only where it prevents a plausible scope mistake.

Workflow

1. Read the accepted intent, any existing plan or native handoff, and the relevant source owners and active constraints. Reuse the acceptance already supplied in the conversation or bead; clarify only what prevents action or judgment. To resume, hand a slice on, pair code with a retrospective or snapshot intent, follow [resume and handoff](references/resume-and-handoff.md). 2. Route only the uncertainty that could change the slice (table below). If an interface choice drives that uncertainty, use the conditional [caller-first design comparison](references/ground-truth-routing.md#compare-interfaces-from-the-callers-side) before committing to a boundary. 3. Fill the block. If a behavior-preserving restructuring would make the slice much smaller, name it on the Sl