2.5 KiB
2.5 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| boo-refining-ideas | Interviews the operator to turn a rough idea into a buildable requirements sketch through targeted questions, for backend and frontend work alike. Use when an idea is fuzzy: "I want something that...", "thinking about adding...", "not sure how to approach...". Do NOT use when requirements are already clear; go straight to boo-planning-changes. Produces input for boo-planning-changes, never a proposal or code. |
|
Refining Ideas
Size
Always small. One idea fits one session. Accept $size override.
Process
- Read the idea. Infer everything answerable from project context. Do NOT ask what the codebase already answers.
- Ask in rounds of MAX 3 questions, highest-leverage first. Question categories: actor/trigger, success criterion, data touched, integration points, explicit non-goals, backend/frontend split.
- After each round, restate the sharpened idea and ask "Proceed or another round?"
- Stop when the sketch passes the test: "Could boo-planning-changes run on this without asking the operator anything?"
- Output the requirements sketch. Do not write a proposal or code.
What NOT to do
- Never propose a design. The output is a requirements sketch, not a solution.
- Never exceed 3 questions per round.
- Never ask anything answerable by reading the repo.
- Never pad with filler ("great idea!").
Gotchas
- Evidence rule: when the operator makes a claim about the system, verify it against the codebase before accepting it.
- Inference boundaries: if the repo does not answer the question, ask. Do not fabricate an answer.
- No commit: never commit, push, or stage changes; never
git add -A. Prove any edits withgit diff --stat. - No em dashes: never use em dashes (U+2014) in output or files you write.
Output format
# Requirements Sketch
## Problem Statement
<2-3 sentences>
## Actors
<list>
## Success Criteria
<testable statements>
## In Scope
<list>
## Out of Scope (explicit)
<list>
## Open Questions
<questions the operator declined to answer>
## Surface Split
<backend vs frontend boundaries>
Failure modes
- Already clear requirements: the idea is specific enough for boo-planning-changes. Hand off directly.
- No project context: the repo is empty or inaccessible. Ask the operator for context directly.
- Operator cannot answer questions: sketch what is known and flag the gaps.