chore: snapshot main sync

This commit is contained in:
2026-06-17 20:08:31 +00:00
parent b18de2a331
commit 8bd32537cf
354 changed files with 10208 additions and 9230 deletions

View File

@@ -0,0 +1,75 @@
---
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.