doughnut: Skill for Claude Code

<input_gate> Use this skill when at least one is true:

• the beneficiary, problem, desired effect, or value is unclear;
• the request prescribes a solution without establishing why it is needed;
• multiple product outcomes or story boundaries must be chosen;
• the highest-value or highest-learning first increment is disputed.

For selected stories, use story-refinement to clarify goal, scope, and key examples; use slice-planning once one story is understood. </input_gate>

<required_human_decisions> Before writing the seed, use an explicit answer the human already gave or ask the human to accept/revise your proposed answer for:

Decision	Required answer
Beneficiary	Who experiences the problem or evaluates the outcome?
Current problem	What happens now, including the workaround?
Desired effect	What observable change would be worth having?
Value now	Why act now rather than defer or do nothing?
Simpler alternative	What is the strongest smaller, manual, or existing-tool option, and why is it insufficient?
Highest learning	Which assumption should the first story test?
Constraints	Which boundaries are problem facts rather than proposed design?

• Do not repeat questions already answered.
• Ask only questions whose answers can change story selection or order.
• Ask at most three closely related questions per turn.
• State the current hypothesis and recommended answer with each question.
• If competing answers materially change the decomposition, stop and wait for the human instead of choosing silently. </required_human_decisions>

For <beneficiary>, <current problem> should change to <desired effect>, within
<genuine constraints>.

Evaluate these options explicitly:

1. Do nothing or defer.
2. Make a smaller behavior change.
3. Use a manual or existing-tool workflow.
4. Pursue the requested direction.

Recommend one. Record the evidence, assumptions, and why the strongest rejected alternative is insufficient.

1. Name one user or stakeholder outcome.
2. Apply the 3V gate in problem-decomposition.mdc; reject failures.
3. State how the beneficiary evaluates the outcome.
4. State its user value or the consequential assumption it tests.
5. Name only genuine product prerequisites.
6. State the value that remains if later stories are cancelled and any safety condition this story must satisfy on its own.

Do not add file-level tasks, technical layers, APIs, or implementation design. Acceptance examples are optional here; include one only when it changes the story boundary.

A seed is a story's home, not a feature boundary. Frame stories as user journeys that achieve a goal across related features when needed. Keep each story's requirements in one home seed and link from related seeds instead of duplicating them. Decompose only enough candidates for the current value or learning question; do not exhaust a feature for completeness.

• Record band, confidence, and assumptions.
• Split a likely larger-than-L candidate using an allowed splitting move.
• Order by user value, then learning value, then genuine prerequisites.
• Move a later story earlier when it delivers more value or tests a more consequential assumption sooner.
• List stories in first-to-drop order for scope reduction.