76 lines
2.5 KiB
Markdown
76 lines
2.5 KiB
Markdown
---
|
|
name: boo-refining-ideas
|
|
description: >
|
|
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.
|
|
metadata:
|
|
version: "1.0"
|
|
---
|
|
|
|
# Refining Ideas
|
|
|
|
## Size
|
|
|
|
Always small. One idea fits one session. Accept `$size` override.
|
|
|
|
## Process
|
|
|
|
1. Read the idea. Infer everything answerable from project context. Do NOT ask what the codebase already answers.
|
|
2. 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.
|
|
3. After each round, restate the sharpened idea and ask "Proceed or another round?"
|
|
4. Stop when the sketch passes the test: "Could boo-planning-changes run on this without asking the operator anything?"
|
|
5. 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.
|
|
<!-- standing-rules:core:start -->
|
|
- **No commit**: never commit, push, or stage changes; never `git add -A`. Prove any edits with `git diff --stat`.
|
|
- **No em dashes**: never use em dashes (U+2014) in output or files you write.
|
|
<!-- standing-rules:core:end -->
|
|
|
|
## 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.
|