Agile Brainstorm Idea
Table of Contents
When to use this skill
Before creative work — a new feature, component, domain type, service, or architectural change. The skill turns ideas into fully-formed designs through natural collaborative dialogue.
How to use this skill
Phase 1 — understand the idea
Gather context. Read related code, recent commits, relevant skills and knowledge docs before asking. Use the doc tools:
./projects/ores.compass/compass.sh list --regex '<keyword>'- Ask questions one at a time. Multiple choice when possible; open-ended only when the topic genuinely needs it. Focus on purpose, constraints, success criteria, scope.
Phase 2 — explore approaches
- Propose 2–3 alternatives with trade-offs (a small table is usually best). Lead with the recommended option; explain why; invite feedback.
- Apply YAGNI ruthlessly. Defer "nice to have" features. Avoid premature abstractions.
Phase 3 — present the design
- Break the design into 200–300 word sections — overview, architecture, domain model, data flow, API/protocol, error handling, testing strategy, migration. Present one section at a time; ask "does this look right so far?" after each.
Phase 4 — file the design
Pick the right shape for the output. Always scaffold via the codegen — never hand-write.
- If the design is one story's plan → put it in the story's
* Plansection. The story itself is scaffolded via How do I create a new doc? §"New story". - If the design captures durable, cross-cutting rationale → file
as a knowledge doc under
doc/knowledge/<topic>/. Scaffold via How do I create a new doc? §"New knowledge document". - If the design is pre-sprint and not yet committed to a version → file as a capture in the next / deferred bucket via How do I create a new doc? §"New capture".
- If the design is a one-off cross-cutting analysis — e.g. a
migration plan that spans many stories — file as
doc/plans/YYYY-MM-DD-<topic>-design.orgfor historical record. (There is no codegen template for one-off plans yet; when one is added, switch this step to it.) - Commit the new doc and, if the conversation is ready,
proceed to scaffold the implementation stories/tasks via
agile-product-owner.
Key principles
| Principle | Description |
|---|---|
| One question at a time | Don't overwhelm. |
| Multiple choice first | Easier to answer; open-ended only when needed. |
| YAGNI ruthlessly | Trim the design to what is actually required. |
| Explore alternatives | 2–3 approaches before settling. |
| Incremental validation | Present design in sections; validate each. |
| Reference, don't dup | Link existing skills and knowledge; don't restate. |
| Codegen always | Never hand-write doc frontmatter — always scaffold. |
Recipes
- How do I create a new doc? — for every output of the brainstorm (story / plan section / capture / knowledge doc).
- How do I find docs matching a pattern? — gather context before asking the first question.
- How do I show a doc by UUID? — inspect any doc the conversation references.
Reference
- Document types — picks the right shape for the design output.
- Product identity — checks the design against what ORE Studio is and is not.
agile-product-owner— for filing the implementation stories.system-architect— sibling skill for migrations spanning multiple components.