Snapshot WIP: solver HP epic progress, BPHX/HX physics, BMAD skill refresh.
Some checks failed
CI / check (push) Has been cancelled
Some checks failed
CI / check (push) Has been cancelled
Capture uncommitted solver robustness work (regularization, domain errors, linear solver lifecycle, tube DP/MSH), web workbench updates, and synced BMAD skills across IDE agent folders before starting BPHX pressure-drop. Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
@@ -1,51 +1,72 @@
|
||||
num,category,method_name,description,output_pattern
|
||||
1,collaboration,Stakeholder Round Table,Convene multiple personas to contribute diverse perspectives - essential for requirements gathering and finding balanced solutions across competing interests,perspectives → synthesis → alignment
|
||||
2,collaboration,Expert Panel Review,Assemble domain experts for deep specialized analysis - ideal when technical depth and peer review quality are needed,expert views → consensus → recommendations
|
||||
3,collaboration,Debate Club Showdown,Two personas argue opposing positions while a moderator scores points - great for exploring controversial decisions and finding middle ground,thesis → antithesis → synthesis
|
||||
4,collaboration,User Persona Focus Group,Gather your product's user personas to react to proposals and share frustrations - essential for validating features and discovering unmet needs,reactions → concerns → priorities
|
||||
5,collaboration,Time Traveler Council,Past-you and future-you advise present-you on decisions - powerful for gaining perspective on long-term consequences vs short-term pressures,past wisdom → present choice → future impact
|
||||
6,collaboration,Cross-Functional War Room,Product manager + engineer + designer tackle a problem together - reveals trade-offs between feasibility desirability and viability,constraints → trade-offs → balanced solution
|
||||
7,collaboration,Mentor and Apprentice,Senior expert teaches junior while junior asks naive questions - surfaces hidden assumptions through teaching,explanation → questions → deeper understanding
|
||||
8,collaboration,Good Cop Bad Cop,Supportive persona and critical persona alternate - finds both strengths to build on and weaknesses to address,encouragement → criticism → balanced view
|
||||
9,collaboration,Improv Yes-And,Multiple personas build on each other's ideas without blocking - generates unexpected creative directions through collaborative building,idea → build → build → surprising result
|
||||
10,collaboration,Customer Support Theater,Angry customer and support rep roleplay to find pain points - reveals real user frustrations and service gaps,complaint → investigation → resolution → prevention
|
||||
11,advanced,Tree of Thoughts,Explore multiple reasoning paths simultaneously then evaluate and select the best - perfect for complex problems with multiple valid approaches,paths → evaluation → selection
|
||||
12,advanced,Graph of Thoughts,Model reasoning as an interconnected network of ideas to reveal hidden relationships - ideal for systems thinking and discovering emergent patterns,nodes → connections → patterns
|
||||
13,advanced,Thread of Thought,Maintain coherent reasoning across long contexts by weaving a continuous narrative thread - essential for RAG systems and maintaining consistency,context → thread → synthesis
|
||||
14,advanced,Self-Consistency Validation,Generate multiple independent approaches then compare for consistency - crucial for high-stakes decisions where verification matters,approaches → comparison → consensus
|
||||
15,advanced,Meta-Prompting Analysis,Step back to analyze the approach structure and methodology itself - valuable for optimizing prompts and improving problem-solving,current → analysis → optimization
|
||||
16,advanced,Reasoning via Planning,Build a reasoning tree guided by world models and goal states - excellent for strategic planning and sequential decision-making,model → planning → strategy
|
||||
17,competitive,Red Team vs Blue Team,Adversarial attack-defend analysis to find vulnerabilities - critical for security testing and building robust solutions,defense → attack → hardening
|
||||
18,competitive,Shark Tank Pitch,Entrepreneur pitches to skeptical investors who poke holes - stress-tests business viability and forces clarity on value proposition,pitch → challenges → refinement
|
||||
19,competitive,Code Review Gauntlet,Senior devs with different philosophies review the same code - surfaces style debates and finds consensus on best practices,reviews → debates → standards
|
||||
20,technical,Architecture Decision Records,Multiple architect personas propose and debate architectural choices with explicit trade-offs - ensures decisions are well-reasoned and documented,options → trade-offs → decision → rationale
|
||||
21,technical,Rubber Duck Debugging Evolved,Explain your code to progressively more technical ducks until you find the bug - forces clarity at multiple abstraction levels,simple → detailed → technical → aha
|
||||
22,technical,Algorithm Olympics,Multiple approaches compete on the same problem with benchmarks - finds optimal solution through direct comparison,implementations → benchmarks → winner
|
||||
23,technical,Security Audit Personas,Hacker + defender + auditor examine system from different threat models - comprehensive security review from multiple angles,vulnerabilities → defenses → compliance
|
||||
24,technical,Performance Profiler Panel,Database expert + frontend specialist + DevOps engineer diagnose slowness - finds bottlenecks across the full stack,symptoms → analysis → optimizations
|
||||
25,creative,SCAMPER Method,Apply seven creativity lenses (Substitute/Combine/Adapt/Modify/Put/Eliminate/Reverse) - systematic ideation for product innovation,S→C→A→M→P→E→R
|
||||
26,creative,Reverse Engineering,Work backwards from desired outcome to find implementation path - powerful for goal achievement and understanding endpoints,end state → steps backward → path forward
|
||||
27,creative,What If Scenarios,Explore alternative realities to understand possibilities and implications - valuable for contingency planning and exploration,scenarios → implications → insights
|
||||
28,creative,Random Input Stimulus,Inject unrelated concepts to spark unexpected connections - breaks creative blocks through forced lateral thinking,random word → associations → novel ideas
|
||||
29,creative,Exquisite Corpse Brainstorm,Each persona adds to the idea seeing only the previous contribution - generates surprising combinations through constrained collaboration,contribution → handoff → contribution → surprise
|
||||
30,creative,Genre Mashup,Combine two unrelated domains to find fresh approaches - innovation through unexpected cross-pollination,domain A + domain B → hybrid insights
|
||||
31,research,Literature Review Personas,Optimist researcher + skeptic researcher + synthesizer review sources - balanced assessment of evidence quality,sources → critiques → synthesis
|
||||
32,research,Thesis Defense Simulation,Student defends hypothesis against committee with different concerns - stress-tests research methodology and conclusions,thesis → challenges → defense → refinements
|
||||
33,research,Comparative Analysis Matrix,Multiple analysts evaluate options against weighted criteria - structured decision-making with explicit scoring,options → criteria → scores → recommendation
|
||||
34,risk,Pre-mortem Analysis,Imagine future failure then work backwards to prevent it - powerful technique for risk mitigation before major launches,failure scenario → causes → prevention
|
||||
35,risk,Failure Mode Analysis,Systematically explore how each component could fail - critical for reliability engineering and safety-critical systems,components → failures → prevention
|
||||
36,risk,Challenge from Critical Perspective,Play devil's advocate to stress-test ideas and find weaknesses - essential for overcoming groupthink,assumptions → challenges → strengthening
|
||||
37,risk,Identify Potential Risks,Brainstorm what could go wrong across all categories - fundamental for project planning and deployment preparation,categories → risks → mitigations
|
||||
38,risk,Chaos Monkey Scenarios,Deliberately break things to test resilience and recovery - ensures systems handle failures gracefully,break → observe → harden
|
||||
39,core,First Principles Analysis,Strip away assumptions to rebuild from fundamental truths - breakthrough technique for innovation and solving impossible problems,assumptions → truths → new approach
|
||||
40,core,5 Whys Deep Dive,Repeatedly ask why to drill down to root causes - simple but powerful for understanding failures,why chain → root cause → solution
|
||||
41,core,Socratic Questioning,Use targeted questions to reveal hidden assumptions and guide discovery - excellent for teaching and self-discovery,questions → revelations → understanding
|
||||
42,core,Critique and Refine,Systematic review to identify strengths and weaknesses then improve - standard quality check for drafts,strengths/weaknesses → improvements → refined
|
||||
43,core,Explain Reasoning,Walk through step-by-step thinking to show how conclusions were reached - crucial for transparency,steps → logic → conclusion
|
||||
44,core,Expand or Contract for Audience,Dynamically adjust detail level and technical depth for target audience - matches content to reader capabilities,audience → adjustments → refined content
|
||||
45,learning,Feynman Technique,Explain complex concepts simply as if teaching a child - the ultimate test of true understanding,complex → simple → gaps → mastery
|
||||
46,learning,Active Recall Testing,Test understanding without references to verify true knowledge - essential for identifying gaps,test → gaps → reinforcement
|
||||
47,philosophical,Occam's Razor Application,Find the simplest sufficient explanation by eliminating unnecessary complexity - essential for debugging,options → simplification → selection
|
||||
48,philosophical,Trolley Problem Variations,Explore ethical trade-offs through moral dilemmas - valuable for understanding values and difficult decisions,dilemma → analysis → decision
|
||||
49,retrospective,Hindsight Reflection,Imagine looking back from the future to gain perspective - powerful for project reviews,future view → insights → application
|
||||
50,retrospective,Lessons Learned Extraction,Systematically identify key takeaways and actionable improvements - essential for continuous improvement,experience → lessons → actions
|
||||
1,advanced,Tree of Thoughts,Explore multiple reasoning paths simultaneously then evaluate and select the best - perfect for complex problems with multiple valid approaches,paths → evaluation → selection
|
||||
2,advanced,Graph of Thoughts,Model reasoning as an interconnected network of ideas to reveal hidden relationships - ideal for systems thinking and discovering emergent patterns,nodes → connections → patterns
|
||||
3,advanced,Thread of Thought,Maintain coherent reasoning across long contexts by weaving a continuous narrative thread - essential for RAG systems and maintaining consistency,context → thread → synthesis
|
||||
4,advanced,Self-Consistency Validation,Generate multiple independent approaches then compare for consistency - crucial for high-stakes decisions where verification matters,approaches → comparison → consensus
|
||||
5,advanced,Meta-Prompting Analysis,Step back to analyze the approach structure and methodology itself - valuable for optimizing prompts and improving problem-solving,current → analysis → optimization
|
||||
6,advanced,Reasoning via Planning,Build a reasoning tree guided by world models and goal states - excellent for strategic planning and sequential decision-making,model → planning → strategy
|
||||
7,advanced,Chain-of-Thought Scaffolding,Force explicit intermediate reasoning steps before any conclusion — prevents intuitive leaps that skip flawed logic,premise → step → step → conclusion
|
||||
8,advanced,Few-Shot Exemplar Priming,Provide 2-3 worked examples of the desired reasoning pattern before the real task — aligns output format and depth through demonstration,examples → pattern recognition → application
|
||||
9,collaboration,Stakeholder Round Table,Convene multiple personas to contribute diverse perspectives - essential for requirements gathering and finding balanced solutions across competing interests,perspectives → synthesis → alignment
|
||||
10,collaboration,Expert Panel Review,Assemble domain experts for deep specialized analysis - ideal when technical depth and peer review quality are needed,expert views → consensus → recommendations
|
||||
11,collaboration,Debate Club Showdown,Two personas argue opposing positions while a moderator scores points - great for exploring controversial decisions and finding middle ground,thesis → antithesis → synthesis
|
||||
12,collaboration,User Persona Focus Group,Gather your product's user personas to react to proposals and share frustrations - essential for validating features and discovering unmet needs,reactions → concerns → priorities
|
||||
13,collaboration,Time Traveler Council,Past-you and future-you advise present-you on decisions - powerful for gaining perspective on long-term consequences vs short-term pressures,past wisdom → present choice → future impact
|
||||
14,collaboration,Cross-Functional War Room,Product manager + engineer + designer tackle a problem together - reveals trade-offs between feasibility desirability and viability,constraints → trade-offs → balanced solution
|
||||
15,collaboration,Mentor and Apprentice,Senior expert teaches junior while junior asks naive questions - surfaces hidden assumptions through teaching,explanation → questions → deeper understanding
|
||||
16,collaboration,Good Cop Bad Cop,Supportive persona and critical persona alternate - finds both strengths to build on and weaknesses to address,encouragement → criticism → balanced view
|
||||
17,collaboration,Improv Yes-And,Multiple personas build on each other's ideas without blocking - generates unexpected creative directions through collaborative building,idea → build → build → surprising result
|
||||
18,collaboration,Customer Support Theater,Angry customer and support rep roleplay to find pain points - reveals real user frustrations and service gaps,complaint → investigation → resolution → prevention
|
||||
19,collaboration,Six Thinking Hats,Rotate through six modes (facts - feelings - caution - optimism - creativity - process) to ensure a group covers every angle without crosstalk,white → red → black → yellow → green → blue
|
||||
20,collaboration,Delphi Method,Experts give independent estimates - see anonymized results - then revise — converges on calibrated group judgment while avoiding anchoring bias,independent estimates → reveal → revise → converge
|
||||
21,competitive,Red Team vs Blue Team,Adversarial attack-defend analysis to find vulnerabilities - critical for security testing and building robust solutions,defense → attack → hardening
|
||||
22,competitive,Shark Tank Pitch,Entrepreneur pitches to skeptical investors who poke holes - stress-tests business viability and forces clarity on value proposition,pitch → challenges → refinement
|
||||
23,competitive,Code Review Gauntlet,Senior devs with different philosophies review the same code - surfaces style debates and finds consensus on best practices,reviews → debates → standards
|
||||
24,core,First Principles Analysis,Strip away assumptions to rebuild from fundamental truths - breakthrough technique for innovation and solving impossible problems,assumptions → truths → new approach
|
||||
25,core,5 Whys Deep Dive,Repeatedly ask why to drill down to root causes - simple but powerful for understanding failures,why chain → root cause → solution
|
||||
26,core,Socratic Questioning,Use targeted questions to reveal hidden assumptions and guide discovery - excellent for teaching and self-discovery,questions → revelations → understanding
|
||||
27,core,Critique and Refine,Systematic review to identify strengths and weaknesses then improve - standard quality check for drafts,strengths/weaknesses → improvements → refined
|
||||
28,core,Explain Reasoning,Walk through step-by-step thinking to show how conclusions were reached - crucial for transparency,steps → logic → conclusion
|
||||
29,core,Expand or Contract for Audience,Dynamically adjust detail level and technical depth for target audience - matches content to reader capabilities,audience → adjustments → refined content
|
||||
30,core,Second-Order Thinking,Think beyond immediate consequences to anticipate cascading effects and long-term implications - essential for strategic decisions where first-order solutions create hidden downstream problems,action → consequences → second-order effects → informed choice
|
||||
31,core,Inversion Analysis,Flip the problem by asking what would guarantee failure instead of how to succeed - reveals hidden obstacles and blind spots by approaching challenges from the opposite direction,goal → invert → failure paths → avoidance → solution
|
||||
32,core,Problem Decomposition,Break a complex problem into independent sub-problems - solve each - then reassemble — essential when a task is too large or tangled to tackle whole,whole → parts → solutions → reassembly
|
||||
33,core,Analogy Mapping,Find a well-understood parallel domain and transfer its structure to the current problem — unlocks insight by borrowing proven mental models,source domain → mapping → target insight
|
||||
34,core,Steelmanning,Construct the strongest possible version of an opposing argument before responding — builds credibility and catches blind spots that strawmanning misses,opposing view → strongest form → honest rebuttal
|
||||
35,creative,SCAMPER Method,Apply seven creativity lenses (Substitute/Combine/Adapt/Modify/Put/Eliminate/Reverse) - systematic ideation for product innovation,S→C→A→M→P→E→R
|
||||
36,creative,Reverse Engineering,Work backwards from desired outcome to find implementation path - powerful for goal achievement and understanding endpoints,end state → steps backward → path forward
|
||||
37,creative,What If Scenarios,Explore alternative realities to understand possibilities and implications - valuable for contingency planning and exploration,scenarios → implications → insights
|
||||
38,creative,Random Input Stimulus,Inject unrelated concepts to spark unexpected connections - breaks creative blocks through forced lateral thinking,random word → associations → novel ideas
|
||||
39,creative,Exquisite Corpse Brainstorm,Each persona adds to the idea seeing only the previous contribution - generates surprising combinations through constrained collaboration,contribution → handoff → contribution → surprise
|
||||
40,creative,Genre Mashup,Combine two unrelated domains to find fresh approaches - innovation through unexpected cross-pollination,domain A + domain B → hybrid insights
|
||||
41,creative,Constraint Injection,Deliberately add an artificial limitation (budget - time - technology) to force novel solutions — creativity thrives under pressure,add constraint → forced creativity → remove constraint → evaluate
|
||||
42,creative,Morphological Analysis,List independent parameters of a problem - enumerate options for each - then systematically combine — ensures you don't miss non-obvious configurations,parameters → options grid → combinations → evaluation
|
||||
43,creative,Subtraction,Improve by deliberately removing elements instead of adding them - counters the well-documented additive bias where people overlook subtractive changes that would simplify and strengthen the work,current state → what to remove → simplified result
|
||||
44,framing,Abstraction Laddering,"Move up (""why?"") for strategic clarity or down (""how?"") for tactical detail — ensures you're solving at the right altitude",concrete ↔ abstract → right level
|
||||
45,framing,Reframe the Question,Challenge whether the stated problem is the real problem — often the question itself is wrong and a better framing unlocks an easy answer,stated problem → reframe → true problem → solution
|
||||
46,framing,Stakeholder Lens Rotation,Serially adopt each stakeholder's world-view to see the same situation differently — reveals whose needs are being overlooked,perspective A → B → C → gaps found
|
||||
47,framing,Map Is Not the Territory,Treat any model or diagram as a lossy abstraction of reality - check where the representation diverges from the real system before trusting it,model → reality check → divergences found → corrected understanding
|
||||
48,learning,Feynman Technique,Explain complex concepts simply as if teaching a child - the ultimate test of true understanding,complex → simple → gaps → mastery
|
||||
49,learning,Active Recall Testing,Test understanding without references to verify true knowledge - essential for identifying gaps,test → gaps → reinforcement
|
||||
50,learning,Deliberate Practice Loop,Identify a specific sub-skill - drill it with immediate feedback - adjust - repeat — targeted improvement beats general repetition,isolate → drill → feedback → adjust → repeat
|
||||
51,philosophical,Occam's Razor Application,Find the simplest sufficient explanation by eliminating unnecessary complexity - essential for debugging,options → simplification → selection
|
||||
52,philosophical,Trolley Problem Variations,Explore ethical trade-offs through moral dilemmas - valuable for understanding values and difficult decisions,dilemma → analysis → decision
|
||||
53,research,Literature Review Personas,Optimist researcher + skeptic researcher + synthesizer review sources - balanced assessment of evidence quality,sources → critiques → synthesis
|
||||
54,research,Thesis Defense Simulation,Student defends hypothesis against committee with different concerns - stress-tests research methodology and conclusions,thesis → challenges → defense → refinements
|
||||
55,research,Comparative Analysis Matrix,Multiple analysts evaluate options against weighted criteria - structured decision-making with explicit scoring,options → criteria → scores → recommendation
|
||||
56,research,Source Triangulation,Require at least three independent source types (quantitative - qualitative - expert) before accepting a claim — guards against single-source bias,claim → source A → source B → source C → confidence rating
|
||||
57,retrospective,Hindsight Reflection,Imagine looking back from the future to gain perspective - powerful for project reviews,future view → insights → application
|
||||
58,retrospective,Lessons Learned Extraction,Systematically identify key takeaways and actionable improvements - essential for continuous improvement,experience → lessons → actions
|
||||
59,risk,Pre-mortem Analysis,Imagine future failure then work backwards to prevent it - powerful technique for risk mitigation before major launches,failure scenario → causes → prevention
|
||||
60,risk,Failure Mode Analysis,Systematically explore how each component could fail - critical for reliability engineering and safety-critical systems,components → failures → prevention
|
||||
61,risk,Challenge from Critical Perspective,Play devil's advocate to stress-test ideas and find weaknesses - essential for overcoming groupthink,assumptions → challenges → strengthening
|
||||
62,risk,Identify Potential Risks,Brainstorm what could go wrong across all categories - fundamental for project planning and deployment preparation,categories → risks → mitigations
|
||||
63,risk,Chaos Monkey Scenarios,Deliberately break things to test resilience and recovery - ensures systems handle failures gracefully,break → observe → harden
|
||||
64,risk,Assumption Audit,Explicitly list every assumption underlying a plan - rate each by confidence and impact - then stress-test the weakest — prevents building on shaky foundations,list → rate → stress-test → shore up
|
||||
65,risk,Cascading Failure Simulation,Trace how one component's failure propagates through dependencies — reveals hidden coupling and single points of failure,trigger failure → trace propagation → find amplifiers → decouple
|
||||
66,technical,Architecture Decision Records,Multiple architect personas propose and debate architectural choices with explicit trade-offs - ensures decisions are well-reasoned and documented,options → trade-offs → decision → rationale
|
||||
67,technical,Rubber Duck Debugging Evolved,Explain your code to progressively more technical ducks until you find the bug - forces clarity at multiple abstraction levels,simple → detailed → technical → aha
|
||||
68,technical,Algorithm Olympics,Multiple approaches compete on the same problem with benchmarks - finds optimal solution through direct comparison,implementations → benchmarks → winner
|
||||
69,technical,Security Audit Personas,Hacker + defender + auditor examine system from different threat models - comprehensive security review from multiple angles,vulnerabilities → defenses → compliance
|
||||
70,technical,Performance Profiler Panel,Database expert + frontend specialist + DevOps engineer diagnose slowness - finds bottlenecks across the full stack,symptoms → analysis → optimizations
|
||||
71,technical,Boundary & Edge Case Sweep,Systematically test extremes - zeros - nulls - maximums - and type mismatches — catches the failures that happy-path thinking always misses,inputs → boundaries → edge cases → failures found
|
||||
|
||||
|
@@ -63,6 +63,8 @@ Continue to prefix your messages with `{agent.icon}` throughout the session so t
|
||||
|
||||
Execute each entry in `{agent.activation_steps_append}` in order.
|
||||
|
||||
Activation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.
|
||||
|
||||
### Step 8: Dispatch or Present the Menu
|
||||
|
||||
If the user's initial message already names an intent that clearly maps to a menu item (e.g. "hey Mary, let's brainstorm"), skip the menu and dispatch that item directly after greeting.
|
||||
|
||||
@@ -63,6 +63,8 @@ Continue to prefix your messages with `{agent.icon}` throughout the session so t
|
||||
|
||||
Execute each entry in `{agent.activation_steps_append}` in order.
|
||||
|
||||
Activation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.
|
||||
|
||||
### Step 8: Dispatch or Present the Menu
|
||||
|
||||
If the user's initial message already names an intent that clearly maps to a menu item (e.g. "hey Winston, let's architect this"), skip the menu and dispatch that item directly after greeting.
|
||||
|
||||
@@ -56,8 +56,8 @@ principles = [
|
||||
|
||||
[[agent.menu]]
|
||||
code = "CA"
|
||||
description = "Guided workflow to document technical decisions to keep implementation on track"
|
||||
skill = "bmad-create-architecture"
|
||||
description = "Produce the architecture spine: the invariants that keep independently-built units consistent"
|
||||
skill = "bmad-architecture"
|
||||
|
||||
[[agent.menu]]
|
||||
code = "IR"
|
||||
|
||||
@@ -63,6 +63,8 @@ Continue to prefix your messages with `{agent.icon}` throughout the session so t
|
||||
|
||||
Execute each entry in `{agent.activation_steps_append}` in order.
|
||||
|
||||
Activation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.
|
||||
|
||||
### Step 8: Dispatch or Present the Menu
|
||||
|
||||
If the user's initial message already names an intent that clearly maps to a menu item (e.g. "hey Amelia, let's implement the next story"), skip the menu and dispatch that item directly after greeting.
|
||||
|
||||
@@ -63,6 +63,8 @@ Continue to prefix your messages with `{agent.icon}` throughout the session so t
|
||||
|
||||
Execute each entry in `{agent.activation_steps_append}` in order.
|
||||
|
||||
Activation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.
|
||||
|
||||
### Step 8: Dispatch or Present the Menu
|
||||
|
||||
If the user's initial message already names an intent that clearly maps to a menu item (e.g. "hey John, let's write the PRD"), skip the menu and dispatch that item directly after greeting.
|
||||
|
||||
@@ -55,19 +55,9 @@ principles = [
|
||||
# registered skill by name) or `prompt` (executes the prompt text directly).
|
||||
|
||||
[[agent.menu]]
|
||||
code = "CP"
|
||||
description = "Expert led facilitation to produce your Product Requirements Document"
|
||||
skill = "bmad-create-prd"
|
||||
|
||||
[[agent.menu]]
|
||||
code = "VP"
|
||||
description = "Validate a PRD is comprehensive, lean, well organized and cohesive"
|
||||
skill = "bmad-validate-prd"
|
||||
|
||||
[[agent.menu]]
|
||||
code = "EP"
|
||||
description = "Update an existing Product Requirements Document"
|
||||
skill = "bmad-edit-prd"
|
||||
code = "PRD"
|
||||
description = "Create, update, or validate a PRD — state your intent or the skill will ask"
|
||||
skill = "bmad-prd"
|
||||
|
||||
[[agent.menu]]
|
||||
code = "CE"
|
||||
|
||||
@@ -63,6 +63,8 @@ Continue to prefix your messages with `{agent.icon}` throughout the session so t
|
||||
|
||||
Execute each entry in `{agent.activation_steps_append}` in order.
|
||||
|
||||
Activation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.
|
||||
|
||||
### Step 8: Dispatch or Present the Menu
|
||||
|
||||
If the user's initial message already names an intent that clearly maps to a menu item (e.g. "hey Paige, let's document this codebase"), skip the menu and dispatch that item directly after greeting.
|
||||
|
||||
@@ -63,6 +63,8 @@ Continue to prefix your messages with `{agent.icon}` throughout the session so t
|
||||
|
||||
Execute each entry in `{agent.activation_steps_append}` in order.
|
||||
|
||||
Activation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.
|
||||
|
||||
### Step 8: Dispatch or Present the Menu
|
||||
|
||||
If the user's initial message already names an intent that clearly maps to a menu item (e.g. "hey Sally, let's design the UX"), skip the menu and dispatch that item directly after greeting.
|
||||
|
||||
@@ -57,4 +57,4 @@ principles = [
|
||||
[[agent.menu]]
|
||||
code = "CU"
|
||||
description = "Guidance through realizing the plan for your UX to inform architecture and implementation"
|
||||
skill = "bmad-create-ux-design"
|
||||
skill = "bmad-ux"
|
||||
|
||||
85
.agent/skills/bmad-architecture/SKILL.md
Normal file
85
.agent/skills/bmad-architecture/SKILL.md
Normal file
@@ -0,0 +1,85 @@
|
||||
---
|
||||
name: bmad-architecture
|
||||
description: 'Produce the architecture: a lean spine of invariants that keeps everything built from it consistent, projected into whatever format the work needs. Use when the user says "create the architecture", "create technical architecture", "architecture spine", or "create a solution design".'
|
||||
---
|
||||
# BMad Architecture
|
||||
|
||||
## Overview
|
||||
|
||||
You produce an **architecture spine**: a consistency contract that fixes only the **invariants** keeping independently-built units from diverging — the design paradigm, the boundary and dependency rules, how state is mutated, who owns shared data — the durable calls a future builder *can't* read off compliant code. Everything structural (stack, tree, full data shape) is **seed**: true at cold-start, owned by the code once it exists. Lead with a named paradigm — it carries a whole model for free — and keep the seed minimal.
|
||||
|
||||
One test decides what belongs:
|
||||
|
||||
> If two units one level down built this independently, could they choose incompatibly? Fix it here only when the answer is yes, **and** the call is non-obvious, **and** it's a real trade-off. Otherwise name it under Deferred and move on.
|
||||
|
||||
Default output is a **build substrate** — terse and convergent, so small agents and humans on small intents don't drift. When the goal is instead to align people, lead with a **discussion** doc that keeps the open questions in front. Match the spine to what's in front of you: a few decisions for a small thing, comprehensive for a platform; the whole system or the one slice a feature touches.
|
||||
|
||||
Record decisions, not rationale (rationale lives in the memlog). Carry shape in diagrams, not prose. Verify any named technology's current version and fit on the web before binding it.
|
||||
|
||||
## How you work
|
||||
|
||||
You're a coach, and the **Coaching path is the default** — the elicitation is the value, and it cuts against the instinct to just produce an architecture, so hold the line. Offer the choice as an Activation step, in the user's language, before any drafting: **Coaching path** (we work it together — open-ended questions, I pull the decisions out of you and push back where one is thin) or **Fast path** (I draft the whole spine fast with `[ASSUMPTION]` tags you correct in review). Unless the user clearly wants speed, **coach; don't silently draft.** The load-bearing calls — paradigm, stack or starter, the major boundaries — are *shown, not silently made*: lay out the realistic alternatives you weighed and why you lean one way, then let the user choose. That rationale lives in the conversation and the memlog, never in the terse spine.
|
||||
|
||||
Elicit, don't quiz: open-ended "how are you thinking about X?" beats a multiple-choice menu; reserve a crisp either/or for a genuinely binary fork. On the Fast path, inferring and tagging *is* the job.
|
||||
|
||||
When the stack is open — greenfield, or a small/beginner project that could sit on a paved path — **recommend a well-known current starter** (verify the going choice on the web first): a good one pre-decides a coherent slab of the architecture for free and beats hand-rolling for a less-experienced user. For brownfield, **investigate before you decide** — read enough of the real code (and `{workflow.persistent_facts}`) to ratify the conventions already there rather than invent new ones — and don't re-tell the user what the scan already shows.
|
||||
|
||||
## Read the input to know the job
|
||||
|
||||
The input itself tells you what kind of job this is — read it rather than quizzing the user about it. A spec package (`SPEC.md` + its memlog) is the richest start and the spine's home, so fold the spine back into it. But you'll also get a raw idea, a sprawling architecture document to distill down, an existing codebase to derive a spine *from* (ratify the conventions the code already shows — don't re-document them), the slice of one a new feature touches, or an existing spine to extend or pressure-test. Prefer a `.memlog.md` over re-reading the source it came from. Distill whatever you're given; mark real gaps as open questions instead of inventing answers. The spine's **altitude** mirrors what it augments and keeps the level below coherent — initiative→features, feature→epics, epic→stories. Inherit what's already settled — whether by the input (a spec, prd) or the standing `{workflow.persistent_facts}` — silently; don't re-decide or re-ask it. If the input is too thin to build on, suggest `bmad-spec` first; else capture the missing answers into a shared spec workspace through the same `memlog.py`, so `bmad-spec` can later derive `SPEC.md` without drift.
|
||||
|
||||
**Inheriting a parent spine** (e.g. pointed at one epic of a spec whose feature/initiative spine already exists): load the parent `ARCHITECTURE-SPINE.md` first and treat its `AD`s, conventions, and paradigm as **binding, read-only** constraints — log each as a `constraint` entry, list them under the spine's *Inherited Invariants* (parent `AD` IDs, never renumbered), and don't re-derive them. Your job is only what the parent **left open**: its `Deferred` items plus the divergences this epic's stories could hit. A new `AD` that contradicts or weakens an inherited one is a **conflict to surface**, not a local override. An epic spine fixes the invariants the epic's stories must share — it does **not** expand per-story detail.
|
||||
|
||||
## How a run works
|
||||
|
||||
The **memlog** (`.memlog.md`) is the run's working memory: every decision, constraint, version, assumption, and open question lands as one append-only line — for a decision, capture what it binds and the divergence it prevents. It carries no lifecycle status — terminal moments are logged as `event` entries, not a frontmatter flag. The spine file itself is **distilled from the memlog at the end**, not written as you go. Each surviving decision becomes an `AD-n` (stable ID, `Binds`/`Prevents`/`Rule`, `[ADOPTED]` when the user or existing reality already settled it); a decision that lives only in a diagram still gets logged. Resume a prior run by reloading its memlog.
|
||||
|
||||
Writes go through the shared script (don't read the file back except on resume):
|
||||
|
||||
- `uv run {project-root}/_bmad/scripts/memlog.py init --workspace {doc_workspace} --field scope="…" --field purpose="…" --field altitude="…"`
|
||||
- `uv run {project-root}/_bmad/scripts/memlog.py append --workspace {doc_workspace} --type <decision|constraint|version|assumption|question|direction|event> --text "…"`
|
||||
|
||||
## Resolution rules
|
||||
|
||||
- Bare paths and `{skill-root}` (e.g. `references/headless.md`) resolve from this skill's installed directory.
|
||||
- `{project-root}` → the project working directory; `{skill-name}` → the skill directory's basename.
|
||||
- `{workflow.<name>}` → a merged `customize.toml` field; `{doc_workspace}` → the bound run folder.
|
||||
- Forward slashes only. Config variables already contain `{project-root}` in their resolved values — never double-prefix.
|
||||
|
||||
## On Activation
|
||||
|
||||
**Forwarded activation:** if a caller (e.g. the `bmad-create-architecture` shim) invoked you with a stated intent and pre-resolved customization fields, honor them verbatim — skip your own intent inference, use the supplied values for those named fields, and resolve only the remaining fields from your own `customize.toml`.
|
||||
|
||||
1. Resolve customization: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow` (on failure read `{skill-root}/customize.toml`, use defaults). Run `{workflow.activation_steps_prepend}`, then `{workflow.activation_steps_append}`. Hold `{workflow.persistent_facts}` as standing context — the default loads `project-context.md`, load-bearing for brownfield — and consult `{workflow.external_sources}` on demand.
|
||||
2. Load `{project-root}/_bmad/bmm/config.yaml` (+ `config.user.yaml`) for `{user_name}`, `{communication_language}`, `{document_output_language}`, `{planning_artifacts}`, `{project_name}`, `{date}`; missing keys take neutral defaults, never block.
|
||||
3. Headless (no interactive user) → follow `references/headless.md` for the whole run. Otherwise greet `{user_name}` in `{communication_language}`. Detect the intent from the conversation and input — **create** (the default), **update** an existing spine, or **validate** one (see those sections). If the real ask is requirements / UX / a capability contract / epic breakdown / an agent, invoke the `bmad-prd`, `bmad-ux`, `bmad-spec`, `bmad-create-epics-and-stories`, or `bmad-workflow-builder` (if the BMad Builder module is installed) skill instead.
|
||||
4. If a run folder for this target already exists under `{workflow.spine_output_path}`, offer to resume from its memlog rather than restart.
|
||||
5. Interactive create: offer the working mode in `{communication_language}` — **Coaching path** (default) or **Fast path** (see *How you work*) — before any drafting; default to Coaching unless the user asks for speed.
|
||||
6. **Mandatory, both paths, before drafting:** ask whether the spine is the only deliverable — and if not, draw out the *purpose and audience* rather than a document type. "An architecture doc" balloons into bloat; what they actually need might be a one-detail explainer for a single team or a non-technical vision piece for a board. Purpose right-sizes the artifact and may call for extra elicitation up front, not just a finale add-on.
|
||||
|
||||
For a new spine, bind `{doc_workspace}` to `{workflow.spine_output_path}/{workflow.run_folder_pattern}/`, seed `ARCHITECTURE-SPINE.md` from `{workflow.spine_template}`, run `memlog.py init`, and tell the user the path. **At epic altitude, scope the folder to the epic** (set `run_folder_pattern` per `customize.toml`) so per-epic runs don't collide.
|
||||
|
||||
## Reviewer Gate
|
||||
|
||||
The spine's pre-handoff review — full mechanics in `references/reviewer-gate.md`. Load it when finalizing or validating: a deterministic `lint_spine.py` pass, then a rubric walker (good-spine checklist) + every `{workflow.finalize_reviewers}` lens dispatched as parallel subagents against `ARCHITECTURE-SPINE.md`, scaled to stakes. At Finalize you apply the clear fixes; under the Validate intent you deliver a bespoke HTML report and then get user input.
|
||||
|
||||
## Finalize
|
||||
|
||||
Walk the sequence; reviewer fixes land before polish.
|
||||
|
||||
1. **Distill.** Write the spine from the memlog (brownfield: + the code sweep) — invariants first, seed minimal, every `AD` carrying Binds/Prevents/Rule, `Deferred` naming what it won't decide. No placeholders; never invent to fill a gap. The template's `<!-- -->` notes are guidance — act on them, then strip them; the finished spine carries no template comment, and only the diagrams that convey the structure (as many as the altitude needs, valid mermaid). Sweep the breadth the altitude owns — every structural dimension is decided, deferred, or an open question; a whole dimension left silent (e.g. the operational/environmental envelope: deployment & environments, infra/provider strategy, operations) is the failure, not a clean spine. A long coaching run distills cleaner in a subagent; the parent falls back inline.
|
||||
2. **Reconcile inputs.** A subagent per load-bearing input checks it against the spine and returns what didn't land — especially a quiet requirement (a tone, a constraint) the `AD` structure dropped. Before the gate.
|
||||
3. **Reviewer pass.** Run the Reviewer Gate (`references/reviewer-gate.md`). Resolve before polish.
|
||||
4. **Triage.** Open questions and `[ASSUMPTION]` tags: blockers (unsafe for what's next) resolved one at a time; the rest deferred with a revisit condition in the memlog.
|
||||
5. **Renderings & polish.** The spine is the build deliverable; with it and the memlog now in place, produce any *additional* human-facing artifact the user needs, scoped to the purpose and audience drawn out up front. The up-front question already flagged whether one's needed; if it wasn't, still offer one here, seeding concrete options: an interactive HTML+SVG deck to walk a team through the architecture and drive discussion, a fuller HTML/md solution design, a C4 set, or a view of how the work splits across teams/epics. Build only what they pick, right-sized to that purpose; apply `{workflow.doc_standards}` polish to that prose only, never to the spine.
|
||||
6. **External handoffs.** Run `{workflow.external_handoffs}`; surface returned URLs/IDs. Offer to invoke the `bmad-spec` skill to adopt the spine as a companion, keeping `AD` IDs stable so downstream can cite them.
|
||||
7. **Close.** Set the spine's own frontmatter `status: final`, `updated: {date}`; log a `memlog.py append --type event --text "spine finalized"` (the memlog has no status field). Share paths. Next, **lead with `bmad-spec`** — recommend adopting/refreshing the spine as a spec companion (always the top recommendation when a spec was an input, and a useful next step even when it wasn't), then `bmad-create-epics-and-stories` or — epic altitude — `bmad-create-story`; or invoke `bmad-help` to route.
|
||||
8. Run `{workflow.on_complete}`.
|
||||
|
||||
## Update
|
||||
|
||||
Amend an existing spine or provided artifact. Resume from its `.memlog.md` (the authority on what was decided), not the rendered spine. Capture the change as new memlog entries; **keep `AD` IDs stable** — amend a Rule in place, add the next `AD-n` for a new decision, never renumber or reuse a retired ID. Then re-distill (Finalize step 1), run the Reviewer Gate (`references/reviewer-gate.md`), and close as in Finalize. An update that overrides something from a source input: offer to update that source too, so upstream and the spine don't silently diverge.
|
||||
|
||||
## Validate
|
||||
|
||||
The standalone intent — critique an existing spine without changing it. Run the Reviewer Gate (`references/reviewer-gate.md`) against it and deliver the bespoke HTML report, then offer to roll the findings into an Update. (At Finalize the same gate runs as your own pre-handoff check, where you apply the fixes instead of reporting.)
|
||||
79
.agent/skills/bmad-architecture/assets/spine-template.md
Normal file
79
.agent/skills/bmad-architecture/assets/spine-template.md
Normal file
@@ -0,0 +1,79 @@
|
||||
---
|
||||
name: '{name}'
|
||||
type: architecture-spine
|
||||
purpose: build-substrate # build-substrate (default) · discussion · report · deck
|
||||
altitude: feature # initiative (keeps features) · feature (keeps epics) · epic (keeps stories)
|
||||
paradigm: '{named design pattern, e.g. hexagonal, layered, pipes-and-filters, actor}'
|
||||
scope: '{what this spine governs}'
|
||||
status: draft # draft · final
|
||||
created: '{date}'
|
||||
updated: '{date}'
|
||||
binds: [] # capability / unit IDs governed (from the driving spec; at epic altitude, also the inherited parent AD ids)
|
||||
sources: []
|
||||
companions: []
|
||||
---
|
||||
|
||||
# Architecture Spine — {name}
|
||||
|
||||
<!-- TEMPLATE GUIDE — act on these comments, then delete them; never emit a comment in the finished spine. This is a shape, not a script: keep only the sections this spine needs and cut the rest (no empty headers). A small intent may be just paradigm + a few ADs + conventions; a platform earns more. An inherited epic spine is usually mostly Inherited Invariants + a thin Deferred. Decisions, not rationale (rationale lives in the memlog). Carry shape in diagrams; prose only where it must. -->
|
||||
|
||||
## Design Paradigm
|
||||
|
||||
<!-- Name the pattern (a known one loads a whole model for free) and map its layers to namespaces/directories. The smallest, most durable thing here. -->
|
||||
|
||||
## Inherited Invariants
|
||||
|
||||
<!-- Only when this spine inherits a higher-altitude parent. The parent's ADs/conventions/paradigm that bind here, by their ORIGINAL ids — read-only, never renumbered, not re-derived. A local decision that contradicts one is a conflict to surface, not an override. Cut this section otherwise. -->
|
||||
|
||||
| Inherited | From parent | Binds here |
|
||||
| --- | --- | --- |
|
||||
| {AD-id / convention} | {parent spine} | {what it constrains in this scope} |
|
||||
|
||||
## Invariants & Rules
|
||||
|
||||
<!-- The durable heart: calls a future builder can't read off compliant code. One block per decision: stable ascending id (never reused/renumbered), Binds, Prevents (the divergence), Rule (enforceable). Tag [ADOPTED] when the user or existing reality settled it. Include a dependency-direction diagram (who may depend on whom) — it IS a rule; author it as valid mermaid, never an empty graph. -->
|
||||
|
||||
### AD-1 — {decision}
|
||||
|
||||
- **Binds:** {capability / unit ids / fr/nfr's, areas, or `all`}
|
||||
- **Prevents:** {the divergence this stops}
|
||||
- **Rule:** {the constraint downstream must follow}
|
||||
|
||||
## Consistency Conventions
|
||||
|
||||
<!-- Defaults that bind where independent builders would drift. Cut rows that don't apply; add rows the project needs. -->
|
||||
|
||||
| Concern | Convention |
|
||||
| --- | --- |
|
||||
| Naming (entities, files, interfaces, events) | |
|
||||
| Data & formats (ids, dates, error shapes, envelopes) | |
|
||||
| State & cross-cutting (mutation, errors, logging, config, auth) | |
|
||||
|
||||
## Stack
|
||||
|
||||
<!-- SEED — verified current at authoring; the code owns this once it exists. Name + version only; the why lives in the memlog. One row per language, framework, key dependency, platform, or chain that's pinned. -->
|
||||
|
||||
| Name | Version |
|
||||
| --- | --- |
|
||||
| {language / framework / key dep / platform / chain} | {pinned version} |
|
||||
|
||||
## Structural Seed
|
||||
|
||||
<!-- The shapes worth fixing at cold-start — not a fixed list. Include only what's non-obvious at this altitude, and use as many diagrams as convey it, each as VALID mermaid (never a placeholder or empty graph). Candidates: system/container/context view; DEPLOYMENT & ENVIRONMENTS and external provider/infra topology (cover the operational envelope here when this altitude owns it — don't let it fall through); core-entity ERD (names + relationships only; an attribute that's itself an invariant is an AD, not a diagram); a minimal source tree. The code owns the detail — this is scaffold, not a mirror to maintain. -->
|
||||
|
||||
```text
|
||||
{root}/
|
||||
{dir}/ # {what lives here}
|
||||
```
|
||||
|
||||
## Capability → Architecture Map
|
||||
|
||||
<!-- Present when a spec drove this run. Bridges the spec's capabilities to where they live + what governs them; the consistency auditor's checklist. Cut otherwise. -->
|
||||
|
||||
| Capability / Area | Lives in | Governed by |
|
||||
| --- | --- | --- |
|
||||
| {CAP-id / area} | {component / module} | {AD-id, convention, paradigm} |
|
||||
|
||||
## Deferred
|
||||
|
||||
<!-- Decisions intentionally pushed down, each with the reason it can wait — including whole dimensions this altitude doesn't own yet. The half of the contract that keeps the spine lean. -->
|
||||
100
.agent/skills/bmad-architecture/customize.toml
Normal file
100
.agent/skills/bmad-architecture/customize.toml
Normal file
@@ -0,0 +1,100 @@
|
||||
# DO NOT EDIT -- overwritten on every update.
|
||||
#
|
||||
# Workflow customization surface for bmad-architecture.
|
||||
#
|
||||
# Override files (not edited here):
|
||||
# {project-root}/_bmad/custom/bmad-architecture.toml (team)
|
||||
# {project-root}/_bmad/custom/bmad-architecture.user.toml (personal)
|
||||
|
||||
[workflow]
|
||||
|
||||
# --- Configurable below. Overrides merge per BMad structural rules: ---
|
||||
# scalars: override wins • arrays: append
|
||||
|
||||
# Steps to run before the standard activation (config load, greet).
|
||||
# Use for pre-flight loads, approved-stack policy checks, etc.
|
||||
activation_steps_prepend = []
|
||||
|
||||
# Steps to run after greet but before the workflow begins.
|
||||
# Use for context-heavy setup that should happen once the user has been acknowledged.
|
||||
activation_steps_append = []
|
||||
|
||||
# Persistent facts the workflow keeps in mind for the whole run
|
||||
# (approved stacks, banned dependencies, platform constraints, compliance guardrails).
|
||||
# Each entry is either a literal sentence, a skill prefixed with `skill:`, or a `file:`-prefixed
|
||||
# path/glob whose contents are loaded as facts.
|
||||
#
|
||||
# Default loads project-context.md if bmad-generate-project-context produced one — giving the
|
||||
# architect persistent awareness of the project's tech, domain, and conventions (load-bearing
|
||||
# for brownfield). Common opt-ins (set in team/user override TOML):
|
||||
# "Our org is AWS-only -- do not propose GCP or Azure."
|
||||
# "file:{project-root}/docs/engineering-standards.md"
|
||||
persistent_facts = [
|
||||
"file:{project-root}/**/project-context.md",
|
||||
]
|
||||
|
||||
# Executed when the workflow completes (after the spine is final and the user has been told).
|
||||
# String scalar (single instruction) or array of instructions executed in order. Empty for none.
|
||||
on_complete = ""
|
||||
|
||||
# The architecture spine template. Treated as expert prior knowledge, not a checklist — the LLM
|
||||
# adapts it to the project, altitude, and domain, and drops sections a project genuinely doesn't
|
||||
# need. Override the path in team/user TOML to enforce a different spine shape.
|
||||
spine_template = "assets/spine-template.md"
|
||||
|
||||
# Run folder location. ARCHITECTURE-SPINE.md, its .memlog.md, and any fuller rendering the run
|
||||
# produces all land inside `{spine_output_path}/{run_folder_pattern}/`. Resume-check scans
|
||||
# `{spine_output_path}` for prior unfinished runs.
|
||||
#
|
||||
# The default pattern fits the common case (one spine per project, at the altitude above epics).
|
||||
# At EPIC altitude, override run_folder_pattern to carry the epic identity so per-epic runs don't
|
||||
# collide on the same day — e.g. set it (team/user TOML) to "architecture-epic-{epic_id}", binding
|
||||
# {epic_id} from the driving spec / the activating payload. Headless callers may instead pass an
|
||||
# explicit doc_workspace and bypass the pattern entirely.
|
||||
spine_output_path = "{planning_artifacts}/architecture"
|
||||
run_folder_pattern = "architecture-{project_name}-{date}"
|
||||
|
||||
# Prose-editorial standards applied at finalize ONLY to a fuller prose document the run produces
|
||||
# (a discussion report, full architecture doc, or design addendum) — never to the spine or other
|
||||
# short, structured outputs, which are terse and carry decisions in AD-n blocks and diagrams by
|
||||
# design. Each entry is a `skill:`, `file:`, or plain-text directive applied before the user sees
|
||||
# the polished draft. Suggested order: structural passes first, prose mechanics last. Append-only.
|
||||
doc_standards = [
|
||||
"skill:bmad-editorial-review-structure",
|
||||
"skill:bmad-editorial-review-prose",
|
||||
]
|
||||
|
||||
# External-source registry. Natural-language directives describing knowledge bases, MCP tools, or
|
||||
# internal systems the LLM may consult ON DEMAND during the run (not preemptively) — approved-stack
|
||||
# catalogs, internal platform docs, version registries. Each entry names the tool, the trigger
|
||||
# condition, and any fields it needs. If a named tool is unavailable at runtime, the LLM falls back
|
||||
# to standard behavior (e.g. web research) and notes the gap. Empty by default.
|
||||
#
|
||||
# Examples (set in team/user override TOML):
|
||||
# "When choosing a datastore, consult corp:platform_catalog before recommending one."
|
||||
# "For current library versions, query corp:artifact_registry before web search."
|
||||
external_sources = []
|
||||
|
||||
# External-handoff routing applied at Finalize to push outputs beyond local files (Confluence,
|
||||
# Notion, ticket systems). Each entry names the MCP tool, the destination, and required fields.
|
||||
# Runs after polish; returned URLs/IDs are surfaced. Unavailable tools are skipped and flagged;
|
||||
# local files always exist. Empty by default.
|
||||
external_handoffs = []
|
||||
|
||||
# --- Finalize reviewers ---
|
||||
# Extra review lenses spawned as parallel subagents at the validation gate (Finalize and the
|
||||
# Validate intent), on top of the skill's built-in good-spine checklist and the lint_spine.py
|
||||
# mechanical floor. The GATE is stakes-gated — a throwaway spine may run it quietly or skip it —
|
||||
# but whenever the gate runs, every entry here runs with it (the configured floor, never cherry-
|
||||
# picked); only ad-hoc lenses are optional, and headless never skips the gate.
|
||||
#
|
||||
# Entries follow the standard prefix convention:
|
||||
# "skill:NAME" invoke the named review skill as a subagent against ARCHITECTURE-SPINE.md
|
||||
# "file:PATH" load the file as a review prompt; spawn an adversarial subagent applying it
|
||||
# plain text use the text directly as the subagent's review prompt
|
||||
#
|
||||
# Resolved on-demand (not at activation). Override TOML may append.
|
||||
finalize_reviewers = [
|
||||
"Verify every committed decision was web-researched or reality-checked rather than asserted from training data: current library/framework versions, that each named technology still exists and fits, and — greenfield — the live defaults of any starter it leans on. Flag anything that could be out of date and wasn't confirmed against the web, the existing project, or the current starter.",
|
||||
"Attack the spine as an adversary: construct two units one level down that each obey every AD to the letter yet still build incompatibly — clashing shared-data shapes, two owners of one entity, conflicting state-mutation paths. Every pair you find is a hole to close with a new or tightened AD.",
|
||||
]
|
||||
26
.agent/skills/bmad-architecture/references/headless.md
Normal file
26
.agent/skills/bmad-architecture/references/headless.md
Normal file
@@ -0,0 +1,26 @@
|
||||
# Headless
|
||||
|
||||
No interactive user: infer everything, ask nothing, but never invent — record inferences as `assumptions[]` and gaps that need a human as `open_questions[]`. Detect headless from a `headless: true` flag, a non-interactive / no-TTY invocation, an activation hook that declares it, or a first message that pre-supplies all inputs and asks for an artifact path back; when ambiguous, default to interactive.
|
||||
|
||||
Drive the run from the payload in the first message — `intent`, `altitude`, `purpose`, the driving input (spec package / PRD / raw intent / brownfield path), a parent spine path at lower altitude, and `doc_workspace` if a specific folder is required. Infer anything absent from the inputs or workspace; don't invent stack, constraints, or scope to fill a gap. You still verify named tech on the web (you can't ask, but you can check) and still drive every write through the shared `{project-root}/_bmad/scripts/memlog.py`. Run the full Reviewer Gate (`references/reviewer-gate.md`) non-interactively: `scripts/lint_spine.py` plus **every `{workflow.finalize_reviewers}` lens as a parallel subagent** (and any ad-hoc lens the spine's criticality warrants). Headless skips only the human picking from the menu — never the reviewers themselves; apply the clear fixes and record anything unresolved in `open_questions[]`. For a true authority collision, list it in `conflicts_with_prior_decisions[]`. For the Validate intent, always write the report to `{doc_workspace}` and add `"offer_to_update": true`. If intent stays ambiguous after inference, halt blocked.
|
||||
|
||||
End with JSON only, omitting keys for artifacts not produced — the shape below is the fully-produced (`complete`) case; a `blocked` run produces no spine, so it omits `spine`, `memlog`, and `companions` entirely (see the note under the block):
|
||||
|
||||
```json
|
||||
{
|
||||
"status": "complete | partial | blocked",
|
||||
"intent": "create | update | validate",
|
||||
"altitude": "initiative | feature | epic",
|
||||
"purpose": "build-substrate | discussion",
|
||||
"doc_workspace": "<resolved run folder>",
|
||||
"spine": "{doc_workspace}/ARCHITECTURE-SPINE.md",
|
||||
"memlog": "{doc_workspace}/.memlog.md",
|
||||
"companions": [],
|
||||
"assumptions": [],
|
||||
"open_questions": [],
|
||||
"conflicts_with_prior_decisions": [],
|
||||
"reason": "<one line, only when blocked>"
|
||||
}
|
||||
```
|
||||
|
||||
`complete` stands alone · `partial` (spine produced, but `open_questions[]` non-empty or critical inputs inferred) means review before downstream use · `blocked` means no spine produced — return only `status`, `intent`, `reason`, and `doc_workspace` (if bound), omitting `spine`, `memlog`, `companions`, and the artifact arrays that don't exist.
|
||||
13
.agent/skills/bmad-architecture/references/reviewer-gate.md
Normal file
13
.agent/skills/bmad-architecture/references/reviewer-gate.md
Normal file
@@ -0,0 +1,13 @@
|
||||
# Reviewer Gate
|
||||
|
||||
The spine's pre-handoff review. Runs at Finalize (after distill + reconcile) and *is* the Validate intent. The difference is the ending: at Finalize you apply the clear fixes yourself; under Validate you report and don't change the spine.
|
||||
|
||||
Cheap deterministic pass first: `uv run {skill-root}/scripts/lint_spine.py --workspace {doc_workspace}` settles the mechanical misses (placeholders, duplicate `AD` IDs, missing Binds/Prevents/Rule, unpinned Stack versions), so reviewers spend judgment on the semantic half.
|
||||
|
||||
Assemble the menu: a **rubric walker** that judges the spine against the good-spine checklist below, **+ every entry in `{workflow.finalize_reviewers}`**, + ad-hoc lenses you invent or offer as the spine's rigor, altitude, and criticality warrant — a security/compliance lens for regulated stakes, a seam reviewer cross-team, a data-integrity lens for a heavy data model. Scale *whether and how heavily the gate runs* to the stakes: a throwaway prototype may run it quietly or skip the gate entirely; a high-criticality or platform-altitude spine earns more lenses and the explicit all / subset / skip menu. But once the gate runs, the `{workflow.finalize_reviewers}` always run — they are the configured floor, never cherry-picked out; only the ad-hoc lenses are optional. (Headless never skips the gate.)
|
||||
|
||||
Dispatch every entry as a **parallel subagent against `ARCHITECTURE-SPINE.md`** (prefix convention: `skill:` / `file:` / plain text). Each writes its full review to `{doc_workspace}/reviews/review-{slug}.md` — a subfolder, so the gate's scratch stays out of the deliverable folder — and returns ONLY a compact summary (verdict, top 2–5 findings, file path) — the parent never holds full review text. An inline self-check does not count: the independent context is the point, because a fresh reviewer finds the divergences the author talks past. If subagents are unavailable, run sequentially — write the file first, then flush it from context.
|
||||
|
||||
**Good-spine checklist** (what the rubric walker judges): it fixes the real divergence points for the level below and misses none; every `AD`'s Rule is enforceable and actually prevents its stated divergence; nothing under Deferred could let two units diverge; named tech is verified-current; it ratifies rather than contradicts a brownfield codebase; if a spec drove it, it covers that spec's capabilities; if a parent spine is inherited, no new `AD` weakens or contradicts an inherited one; and every dimension the altitude owns is decided, deferred, or an open question — a whole dimension left silent is a finding, especially the operational/environmental envelope (deployment & environments, infra/provider strategy, operations) a domain-focused draft skips.
|
||||
|
||||
Surface findings tiered, never dumped: a one-sentence gate verdict, then critical + high; medium/low roll into a tail ("plus N more in {file}"). Per finding: autofix, discuss, defer to Deferred / open items, or ignore. **At Finalize this is your own gate — apply the clear fixes rather than handing over a list; surface only what genuinely needs the user.** Under the **Validate intent**, fold every reviewer's output into one bespoke HTML + markdown report and open the HTML.
|
||||
257
.agent/skills/bmad-architecture/scripts/lint_spine.py
Normal file
257
.agent/skills/bmad-architecture/scripts/lint_spine.py
Normal file
@@ -0,0 +1,257 @@
|
||||
#!/usr/bin/env python3
|
||||
# /// script
|
||||
# requires-python = ">=3.10"
|
||||
# ///
|
||||
"""lint-spine — the mechanical half of spine decision-integrity, done deterministically.
|
||||
|
||||
LLMs miscount IDs and miss literal placeholders; a grep does not. This linter owns the
|
||||
checks a script does better than a prompt, and leaves the semantic half (is each Rule
|
||||
actually enforceable? does the boundary make sense?) to the rubric walker.
|
||||
|
||||
It reads ARCHITECTURE-SPINE.md from a workspace and reports, as compact JSON on stdout:
|
||||
|
||||
- placeholder literal TBD / TODO / "similar to AD-n" / unfilled {template-token}
|
||||
- ad_id duplicate or non-monotonic AD-n identifiers
|
||||
- ad_fields an AD-n block missing Binds / Prevents / Rule
|
||||
- version_pin a ## Stack table row with no version
|
||||
|
||||
Fenced code blocks are blanked (replaced with equal-count blank lines) before scanning, so
|
||||
mermaid and source trees don't trip false positives AND reported line numbers still line up
|
||||
with the real file. Reported lines are absolute file lines (frontmatter offset added). Exit
|
||||
code is always 0 — findings travel in the JSON; the caller (Reviewer Gate / rubric walker)
|
||||
decides what to do with them.
|
||||
"""
|
||||
from __future__ import annotations
|
||||
|
||||
import argparse
|
||||
import json
|
||||
import re
|
||||
import sys
|
||||
from pathlib import Path
|
||||
|
||||
SPINE = "ARCHITECTURE-SPINE.md"
|
||||
|
||||
AD_HEADING = re.compile(r"^#{2,4}\s*AD-(\d+)\b(.*)$", re.MULTILINE)
|
||||
HEADING = re.compile(r"^#{1,6}\s", re.MULTILINE)
|
||||
FENCE = re.compile(r"```.*?```", re.DOTALL)
|
||||
PLACEHOLDER_WORD = re.compile(r"\b(TBD|TODO|FIXME|XXX)\b")
|
||||
SIMILAR_TO = re.compile(r"similar to AD-\d+", re.IGNORECASE)
|
||||
TEMPLATE_TOKEN = re.compile(r"\{[a-z_][a-z0-9_ /.-]*\}")
|
||||
|
||||
|
||||
def split_frontmatter(text: str) -> tuple[str, str, int]:
|
||||
"""Return (frontmatter, body, body_line_offset).
|
||||
|
||||
Frontmatter is the content between the first two lines that are *exactly* `---`
|
||||
(line-exact, like memlog.split — a `---` inside a value or a body thematic break never
|
||||
truncates it). body_line_offset is the number of file lines before the body begins, so a
|
||||
body-relative line number plus the offset gives the absolute file line. Absent frontmatter
|
||||
→ ('', text, 0)."""
|
||||
lines = text.split("\n")
|
||||
if lines and lines[0] == "---":
|
||||
for i in range(1, len(lines)):
|
||||
if lines[i] == "---":
|
||||
fm = "\n".join(lines[1:i])
|
||||
body = "\n".join(lines[i + 1:])
|
||||
return fm, body, i + 1
|
||||
return "", text, 0
|
||||
|
||||
|
||||
def blank_fences(text: str) -> str:
|
||||
"""Replace each fenced block with the same number of newlines, so scanning skips fenced
|
||||
content while every line number outside the fence stays put."""
|
||||
return FENCE.sub(lambda m: "\n" * m.group(0).count("\n"), text)
|
||||
|
||||
|
||||
def line_of(text: str, idx: int) -> int:
|
||||
return text.count("\n", 0, idx) + 1
|
||||
|
||||
|
||||
def find_placeholders(body: str, offset: int) -> list[dict]:
|
||||
findings: list[dict] = []
|
||||
scan = blank_fences(body)
|
||||
# (regex, label, severity) — TBD/TODO and dangling cross-refs are unambiguous; a bare
|
||||
# {template-token} can be legitimate brace prose, so it is flagged low ("possible") to keep
|
||||
# the mechanical pass near-zero false-positive rather than train reviewers to ignore it.
|
||||
for rx, label, severity in (
|
||||
(PLACEHOLDER_WORD, "placeholder marker", "high"),
|
||||
(SIMILAR_TO, "unresolved cross-reference", "high"),
|
||||
(TEMPLATE_TOKEN, "possible unfilled template token (verify)", "low"),
|
||||
):
|
||||
for m in rx.finditer(scan):
|
||||
findings.append({
|
||||
"category": "placeholder",
|
||||
"severity": severity,
|
||||
"detail": f"{label}: {m.group(0)!r}",
|
||||
"location": f"{SPINE} (line {offset + line_of(scan, m.start())})",
|
||||
})
|
||||
return findings
|
||||
|
||||
|
||||
def find_frontmatter_placeholders(frontmatter: str) -> list[dict]:
|
||||
"""Catch unfilled tokens left in frontmatter (e.g. paradigm/scope/date) — part of the
|
||||
spine contract, but outside the body that find_placeholders scans."""
|
||||
findings: list[dict] = []
|
||||
for rx, label, severity in (
|
||||
(PLACEHOLDER_WORD, "placeholder marker", "high"),
|
||||
(TEMPLATE_TOKEN, "possible unfilled template token (verify)", "low"),
|
||||
):
|
||||
for m in rx.finditer(frontmatter):
|
||||
findings.append({
|
||||
"category": "placeholder",
|
||||
"severity": severity,
|
||||
"detail": f"frontmatter {label}: {m.group(0)!r}",
|
||||
"location": f"{SPINE} frontmatter (line {1 + line_of(frontmatter, m.start())})",
|
||||
})
|
||||
return findings
|
||||
|
||||
|
||||
def find_ad_issues(body: str, offset: int) -> list[dict]:
|
||||
findings: list[dict] = []
|
||||
scan = blank_fences(body) # AD headings shown inside a code fence are not live ADs
|
||||
matches = list(AD_HEADING.finditer(scan))
|
||||
seen: dict[int, int] = {}
|
||||
prev: int | None = None
|
||||
for m in matches:
|
||||
num = int(m.group(1))
|
||||
file_line = offset + line_of(scan, m.start())
|
||||
loc = f"{SPINE} AD-{num} (line {file_line})"
|
||||
if num in seen:
|
||||
findings.append({
|
||||
"category": "ad_id",
|
||||
"severity": "high",
|
||||
"detail": f"AD-{num} id reused (also at line {seen[num]})",
|
||||
"location": loc,
|
||||
})
|
||||
else:
|
||||
seen[num] = file_line
|
||||
if prev is not None and num <= prev:
|
||||
findings.append({
|
||||
"category": "ad_id",
|
||||
"severity": "high",
|
||||
"detail": f"AD-{num} is non-monotonic (follows AD-{prev}); ids must ascend and never renumber",
|
||||
"location": loc,
|
||||
})
|
||||
prev = num if prev is None else max(prev, num)
|
||||
|
||||
# block text = from this heading to the next heading of any level
|
||||
start = m.end()
|
||||
nxt = HEADING.search(scan, start)
|
||||
block = scan[start:nxt.start()] if nxt else scan[start:]
|
||||
low = block.lower()
|
||||
missing = [f for f in ("binds", "prevents", "rule") if f not in low]
|
||||
if missing:
|
||||
findings.append({
|
||||
"category": "ad_fields",
|
||||
"severity": "high",
|
||||
"detail": f"AD-{num} missing required field(s): {', '.join(missing)}",
|
||||
"location": loc,
|
||||
})
|
||||
return findings
|
||||
|
||||
|
||||
def find_unpinned_stack(body: str, offset: int) -> list[dict]:
|
||||
"""Flag a `## Stack` table row that names something but leaves its version blank or a
|
||||
placeholder. Pinning lives in the body table now, not frontmatter. A row whose name is
|
||||
still a `{token}` skeleton is left to the placeholder pass, not double-reported here.
|
||||
|
||||
Fences are blanked first (like find_placeholders / find_ad_issues), so a pipe-row or
|
||||
heading inside a code block is never read as live Stack content. The heading match is
|
||||
`## Stack` with a word boundary, so a renamed heading (`## Stack & Versions`) still
|
||||
counts. Name and Version columns are located from the header row, so a reordered table
|
||||
pairs name to version correctly; both default to the canonical positions (0, 1)."""
|
||||
findings: list[dict] = []
|
||||
in_stack = False
|
||||
header_seen = False
|
||||
name_idx, ver_idx = 0, 1
|
||||
scan = blank_fences(body)
|
||||
for i, raw in enumerate(scan.splitlines()):
|
||||
if HEADING.match(raw):
|
||||
in_stack = re.match(r"^##\s+Stack\b", raw) is not None
|
||||
header_seen = False
|
||||
name_idx, ver_idx = 0, 1
|
||||
continue
|
||||
if not in_stack or not raw.lstrip().startswith("|"):
|
||||
continue
|
||||
if set(raw.strip()) <= set("|-: "):
|
||||
continue # separator row
|
||||
cells = _table_cells(raw)
|
||||
if not header_seen:
|
||||
header_seen = True
|
||||
for j, c in enumerate(cells):
|
||||
if c.lower() == "name":
|
||||
name_idx = j
|
||||
elif c.lower() == "version":
|
||||
ver_idx = j
|
||||
continue
|
||||
name = cells[name_idx] if len(cells) > name_idx else ""
|
||||
version = cells[ver_idx] if len(cells) > ver_idx else ""
|
||||
if not name or TEMPLATE_TOKEN.search(name):
|
||||
continue
|
||||
if not version or TEMPLATE_TOKEN.search(version):
|
||||
findings.append({
|
||||
"category": "version_pin",
|
||||
"severity": "medium",
|
||||
"detail": f"Stack entry {name!r} has no version",
|
||||
"location": f"{SPINE} (line {offset + i + 1})",
|
||||
})
|
||||
return findings
|
||||
|
||||
|
||||
def _table_cells(row: str) -> list[str]:
|
||||
"""Split a markdown table row into trimmed cells, dropping the leading/trailing pipe."""
|
||||
s = row.strip()
|
||||
if s.startswith("|"):
|
||||
s = s[1:]
|
||||
if s.endswith("|"):
|
||||
s = s[:-1]
|
||||
return [c.strip() for c in s.split("|")]
|
||||
|
||||
|
||||
def lint(text: str) -> dict:
|
||||
frontmatter, body, offset = split_frontmatter(text)
|
||||
findings: list[dict] = []
|
||||
findings += find_frontmatter_placeholders(frontmatter)
|
||||
findings += find_placeholders(body, offset)
|
||||
findings += find_ad_issues(body, offset)
|
||||
findings += find_unpinned_stack(body, offset)
|
||||
counts: dict[str, int] = {}
|
||||
for f in findings:
|
||||
counts[f["severity"]] = counts.get(f["severity"], 0) + 1
|
||||
return {
|
||||
"ok": len(findings) == 0,
|
||||
"spine": SPINE,
|
||||
"total_findings": len(findings),
|
||||
"by_severity": counts,
|
||||
"findings": findings,
|
||||
}
|
||||
|
||||
|
||||
def main(argv: list[str] | None = None) -> int:
|
||||
ap = argparse.ArgumentParser(description="Lint an architecture spine for mechanical integrity.")
|
||||
ap.add_argument("--workspace", required=True, help="run folder containing ARCHITECTURE-SPINE.md")
|
||||
ap.add_argument("-o", "--output", help="write JSON here instead of stdout")
|
||||
args = ap.parse_args(argv)
|
||||
|
||||
spine_path = Path(args.workspace) / SPINE
|
||||
if not spine_path.exists():
|
||||
result = {"ok": False, "error": f"{spine_path} not found", "findings": [], "total_findings": 0}
|
||||
else:
|
||||
try:
|
||||
text = spine_path.read_text(encoding="utf-8")
|
||||
except (OSError, UnicodeDecodeError) as e:
|
||||
# honor the "exit code is always 0" contract: a read/decode failure travels in JSON
|
||||
result = {"ok": False, "error": f"could not read {spine_path}: {e}", "findings": [], "total_findings": 0}
|
||||
else:
|
||||
result = lint(text)
|
||||
|
||||
out = json.dumps(result, indent=2)
|
||||
if args.output:
|
||||
Path(args.output).write_text(out + "\n", encoding="utf-8")
|
||||
else:
|
||||
print(out)
|
||||
return 0
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
sys.exit(main())
|
||||
270
.agent/skills/bmad-architecture/scripts/tests/test_lint_spine.py
Normal file
270
.agent/skills/bmad-architecture/scripts/tests/test_lint_spine.py
Normal file
@@ -0,0 +1,270 @@
|
||||
# /// script
|
||||
# requires-python = ">=3.10"
|
||||
# dependencies = ["pytest>=8.0"]
|
||||
# ///
|
||||
"""Tests for lint_spine.py. Run: uv run --with pytest pytest scripts/tests/test_lint_spine.py
|
||||
|
||||
The spine under test: a clean spine lints empty; the linter catches exactly the
|
||||
mechanical defects a prompt is unreliable at — literal placeholders, AD-n id breakage,
|
||||
AD-n blocks missing required fields, and unpinned Stack versions.
|
||||
"""
|
||||
import importlib.util
|
||||
import json
|
||||
import re
|
||||
import sys
|
||||
from pathlib import Path
|
||||
|
||||
import pytest
|
||||
|
||||
_SPEC = importlib.util.spec_from_file_location(
|
||||
"lint_spine", Path(__file__).resolve().parent.parent / "lint_spine.py"
|
||||
)
|
||||
lint_spine = importlib.util.module_from_spec(_SPEC)
|
||||
sys.modules["lint_spine"] = lint_spine
|
||||
_SPEC.loader.exec_module(lint_spine)
|
||||
|
||||
|
||||
CLEAN = """---
|
||||
name: 'Demo'
|
||||
---
|
||||
|
||||
## Invariants & Rules
|
||||
|
||||
### AD-1 — single write path
|
||||
|
||||
- **Binds:** all
|
||||
- **Prevents:** divergent mutation
|
||||
- **Rule:** state changes only through the command bus
|
||||
|
||||
### AD-2 — layered deps `[ADOPTED]`
|
||||
|
||||
- **Binds:** all
|
||||
- **Prevents:** import cycles
|
||||
- **Rule:** ui -> app -> domain, never backward
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A --> B{decision}
|
||||
```
|
||||
|
||||
## Stack
|
||||
|
||||
| Name | Version |
|
||||
| --- | --- |
|
||||
| fastapi | 0.115 |
|
||||
| pydantic | 2.9 |
|
||||
"""
|
||||
|
||||
|
||||
def cats(result):
|
||||
return sorted(f["category"] for f in result["findings"])
|
||||
|
||||
|
||||
def test_clean_spine_passes():
|
||||
result = lint_spine.lint(CLEAN)
|
||||
assert result["ok"] is True
|
||||
assert result["total_findings"] == 0
|
||||
|
||||
|
||||
def test_mermaid_braces_not_flagged():
|
||||
# the {decision} node lives in a fenced block and must not read as a template token
|
||||
result = lint_spine.lint(CLEAN)
|
||||
assert "placeholder" not in cats(result)
|
||||
|
||||
|
||||
def test_placeholder_markers_caught():
|
||||
text = CLEAN.replace("the command bus", "TBD")
|
||||
result = lint_spine.lint(text)
|
||||
assert "placeholder" in cats(result)
|
||||
|
||||
|
||||
def test_similar_to_caught():
|
||||
text = CLEAN.replace("import cycles", "similar to AD-1")
|
||||
result = lint_spine.lint(text)
|
||||
assert any("cross-reference" in f["detail"] for f in result["findings"])
|
||||
|
||||
|
||||
def test_unfilled_template_token_caught():
|
||||
text = CLEAN.replace("single write path", "{decision}")
|
||||
result = lint_spine.lint(text)
|
||||
assert any(f["category"] == "placeholder" for f in result["findings"])
|
||||
|
||||
|
||||
def test_duplicate_ad_id_caught():
|
||||
text = CLEAN.replace("### AD-2 — layered deps `[ADOPTED]`", "### AD-1 — layered deps")
|
||||
result = lint_spine.lint(text)
|
||||
assert "ad_id" in cats(result)
|
||||
|
||||
|
||||
def test_non_monotonic_ad_id_caught():
|
||||
text = CLEAN.replace("### AD-2 — layered deps `[ADOPTED]`", "### AD-5 — layered deps").replace(
|
||||
"### AD-1 — single write path", "### AD-9 — single write path"
|
||||
)
|
||||
result = lint_spine.lint(text)
|
||||
assert any("non-monotonic" in f["detail"] for f in result["findings"])
|
||||
|
||||
|
||||
def test_missing_field_caught():
|
||||
text = CLEAN.replace("- **Rule:** state changes only through the command bus\n", "")
|
||||
result = lint_spine.lint(text)
|
||||
assert any(f["category"] == "ad_fields" and "rule" in f["detail"] for f in result["findings"])
|
||||
|
||||
|
||||
def test_unpinned_dep_caught():
|
||||
text = CLEAN.replace("| fastapi | 0.115 |", "| fastapi | |")
|
||||
result = lint_spine.lint(text)
|
||||
assert "version_pin" in cats(result)
|
||||
|
||||
|
||||
def test_placeholder_version_caught():
|
||||
text = CLEAN.replace("| fastapi | 0.115 |", "| fastapi | {pin} |")
|
||||
result = lint_spine.lint(text)
|
||||
assert any(f["category"] == "version_pin" and "fastapi" in f["detail"] for f in result["findings"])
|
||||
|
||||
|
||||
def test_no_stack_section_ok():
|
||||
text = CLEAN.split("## Stack")[0]
|
||||
result = lint_spine.lint(text)
|
||||
assert "version_pin" not in cats(result)
|
||||
|
||||
|
||||
def test_stack_skeleton_row_not_version_pinned():
|
||||
# a leftover {token} name is the placeholder pass's job, not a double-reported version_pin
|
||||
text = CLEAN.replace("| fastapi | 0.115 |", "| {language / framework} | {pinned version} |")
|
||||
result = lint_spine.lint(text)
|
||||
assert "version_pin" not in cats(result)
|
||||
|
||||
|
||||
def test_stack_html_comment_not_parsed_as_row():
|
||||
text = CLEAN.replace("## Stack\n", "## Stack\n\n<!-- SEED — verified current 2026-06 -->\n")
|
||||
result = lint_spine.lint(text)
|
||||
assert "version_pin" not in cats(result)
|
||||
|
||||
|
||||
def test_template_token_is_low_severity():
|
||||
# a bare {token} can be legitimate brace prose; it is flagged, but low (not high) so the
|
||||
# mechanical pass stays near-zero false-positive
|
||||
text = CLEAN.replace("single write path", "{decision}")
|
||||
result = lint_spine.lint(text)
|
||||
toks = [f for f in result["findings"] if f["category"] == "placeholder" and "template token" in f["detail"]]
|
||||
assert toks and all(f["severity"] == "low" for f in toks)
|
||||
|
||||
|
||||
def test_no_frontmatter_body_still_scanned():
|
||||
text = "## Invariants\n\n### AD-1 — x\n\n- **Binds:** all\n- **Prevents:** drift\n- **Rule:** TBD\n"
|
||||
result = lint_spine.lint(text)
|
||||
assert "placeholder" in cats(result) # TBD caught even with no frontmatter
|
||||
|
||||
|
||||
def test_frontmatter_value_with_dashes_not_truncated():
|
||||
# a value containing '---' must not be read as the closing fence (line-exact close)
|
||||
text = ("---\nname: 'x'\nscope: 'phase 1 --- phase 2'\n---\n\n"
|
||||
"## Stack\n\n| Name | Version |\n| --- | --- |\n| fastapi | |\n")
|
||||
result = lint_spine.lint(text)
|
||||
assert any(f["category"] == "version_pin" for f in result["findings"]) # read past the inline ---
|
||||
|
||||
|
||||
def test_ad_heading_in_fence_not_counted():
|
||||
text = (
|
||||
"---\nname: 'x'\n---\n\n"
|
||||
"### AD-1 — real\n\n- **Binds:** all\n- **Prevents:** drift\n- **Rule:** do x\n\n"
|
||||
"## Docs\n\n```text\n### AD-2 — illustrative only, no fields\n```\n"
|
||||
)
|
||||
result = lint_spine.lint(text)
|
||||
assert result["ok"] is True # the fenced AD-2 is not a live AD → no ad_fields/ad_id finding
|
||||
|
||||
|
||||
def test_stack_table_flags_only_the_unpinned_row():
|
||||
text = ("---\nname: 'x'\n---\n\n## Stack\n\n| Name | Version |\n| --- | --- |\n"
|
||||
"| fastapi | 0.115 |\n| redis | |\n")
|
||||
result = lint_spine.lint(text)
|
||||
pins = [f for f in result["findings"] if f["category"] == "version_pin"]
|
||||
assert len(pins) == 1 and "redis" in pins[0]["detail"]
|
||||
|
||||
|
||||
def test_stack_table_all_pinned_ok():
|
||||
text = ("---\nname: 'x'\n---\n\n## Stack\n\n| Name | Version |\n| --- | --- |\n"
|
||||
"| fastapi | 0.115 |\n")
|
||||
result = lint_spine.lint(text)
|
||||
assert "version_pin" not in cats(result)
|
||||
|
||||
|
||||
def test_fenced_stack_rows_not_parsed():
|
||||
# an illustrative fenced table under ## Stack must not be read as live rows (fences are
|
||||
# blanked first, like every other pass) — a blank-version row inside a fence is not a finding
|
||||
text = ("---\nname: 'x'\n---\n\n## Stack\n\n| Name | Version |\n| --- | --- |\n"
|
||||
"| fastapi | 0.115 |\n\n```text\n| example | |\n```\n")
|
||||
result = lint_spine.lint(text)
|
||||
assert "version_pin" not in cats(result)
|
||||
|
||||
|
||||
def test_fenced_stack_heading_not_live():
|
||||
# a `## Stack` heading shown inside a code fence is not the live Stack section
|
||||
text = ("---\nname: 'x'\n---\n\n## Docs\n\n```md\n## Stack\n\n| foo | |\n```\n")
|
||||
result = lint_spine.lint(text)
|
||||
assert "version_pin" not in cats(result)
|
||||
|
||||
|
||||
def test_renamed_stack_heading_still_scanned():
|
||||
# the heading match is word-boundary, so a varied `## Stack` heading still counts
|
||||
text = ("---\nname: 'x'\n---\n\n## Stack & Versions\n\n| Name | Version |\n| --- | --- |\n"
|
||||
"| redis | |\n")
|
||||
result = lint_spine.lint(text)
|
||||
pins = [f for f in result["findings"] if f["category"] == "version_pin"]
|
||||
assert len(pins) == 1 and "redis" in pins[0]["detail"]
|
||||
|
||||
|
||||
def test_reordered_columns_pair_name_to_version():
|
||||
# Version-then-Name header: the unpinned row must still be flagged by its real name
|
||||
text = ("---\nname: 'x'\n---\n\n## Stack\n\n| Version | Name |\n| --- | --- |\n"
|
||||
"| 0.115 | fastapi |\n| | redis |\n")
|
||||
result = lint_spine.lint(text)
|
||||
pins = [f for f in result["findings"] if f["category"] == "version_pin"]
|
||||
assert len(pins) == 1 and "redis" in pins[0]["detail"]
|
||||
|
||||
|
||||
def test_placeholder_line_number_is_absolute():
|
||||
# a TBD after a multi-line fence reports its real file line (fence blanked, not collapsed)
|
||||
text = (
|
||||
"---\nname: 'x'\n---\n\n"
|
||||
"## A\n\n"
|
||||
"```text\nf1\nf2\nf3\n```\n\n"
|
||||
"TBD here\n"
|
||||
)
|
||||
result = lint_spine.lint(text)
|
||||
ph = next(f for f in result["findings"] if "TBD" in f["detail"])
|
||||
n = int(re.search(r"line (\d+)", ph["location"]).group(1))
|
||||
assert n == 13
|
||||
|
||||
|
||||
def test_missing_spine_file_reports_error(tmp_path, capsys):
|
||||
rc = lint_spine.main(["--workspace", str(tmp_path)])
|
||||
out = json.loads(capsys.readouterr().out)
|
||||
assert rc == 0 and out["ok"] is False and "not found" in out["error"]
|
||||
|
||||
|
||||
def test_frontmatter_unfilled_token_caught():
|
||||
# an unfilled {scope}/{paradigm}/{date} in frontmatter is part of the contract and must lint
|
||||
text = "---\nname: 'x'\nscope: '{what this spine governs}'\n---\n\n## Invariants\n"
|
||||
result = lint_spine.lint(text)
|
||||
fm = [f for f in result["findings"] if f["category"] == "placeholder" and "frontmatter" in f["detail"]]
|
||||
assert fm and any("template token" in f["detail"] for f in fm)
|
||||
|
||||
|
||||
def test_frontmatter_tbd_caught():
|
||||
text = "---\nname: 'x'\nstatus: TBD\n---\n\n## Invariants\n"
|
||||
result = lint_spine.lint(text)
|
||||
assert any(f["category"] == "placeholder" and "frontmatter" in f["detail"] and "TBD" in f["detail"]
|
||||
for f in result["findings"])
|
||||
|
||||
|
||||
def test_unreadable_spine_returns_error_not_crash(tmp_path, capsys):
|
||||
# a spine that exists but can't be UTF-8 decoded must yield error JSON + exit 0, not a traceback
|
||||
(tmp_path / lint_spine.SPINE).write_bytes(b"\xff\xfe bad bytes not utf-8")
|
||||
rc = lint_spine.main(["--workspace", str(tmp_path)])
|
||||
out = json.loads(capsys.readouterr().out)
|
||||
assert rc == 0 and out["ok"] is False and "could not read" in out["error"]
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
sys.exit(pytest.main([__file__, "-q"]))
|
||||
@@ -1,6 +1,80 @@
|
||||
---
|
||||
name: bmad-brainstorming
|
||||
description: 'Facilitate interactive brainstorming sessions using diverse creative techniques and ideation methods. Use when the user says help me brainstorm or help me ideate.'
|
||||
description: Facilitate a brainstorming session using diverse creative techniques. Use when the user says 'help me brainstorm' or 'help me ideate'.
|
||||
---
|
||||
|
||||
Follow the instructions in ./workflow.md.
|
||||
# BMad Brainstorming
|
||||
|
||||
## Overview
|
||||
|
||||
You are a creative brainstorming coach. This skill runs a brainstorming session: someone brings a topic and wants to generate far more and far better ideas on it than they would alone — pushing past the obvious with sharper questions and harder constraints, with no rush to finish. The best sessions end with the user surprised by what came out.
|
||||
|
||||
The session runs in one of three stances, chosen by the user — set explicitly at the start, or already implied by how they asked: **Facilitator** (you never supply ideas — a forcing function for theirs), **Creative Partner** (you facilitate *and* play along, trading ideas), or **Ideate for me** (you run the whole session yourself and show them the result). The chosen stance holds for the whole run.
|
||||
|
||||
## Conventions
|
||||
|
||||
- Bare paths (e.g. `references/headless.md`) resolve from `{skill-root}` (where `customize.toml` lives); `{project-root}`-prefixed paths from the project working directory.
|
||||
- `{workflow.<name>}` resolves to fields in the merged `customize.toml` `[workflow]` table.
|
||||
|
||||
## On Activation
|
||||
|
||||
1. Resolve customization: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. On failure, use a subagent to read `{skill-root}/customize.toml` directly with defaults.
|
||||
2. Run each `{workflow.activation_steps_prepend}` entry. Treat each `{workflow.persistent_facts}` entry as foundational context (`file:`-prefixed entries are paths/globs under `{project-root}` — load their contents; others are facts verbatim).
|
||||
3. Load `{project-root}/_bmad/core/config.yaml` (and `config.user.yaml` if present); resolve `{user_name}`, `{communication_language}`, `{document_output_language}`, `{output_folder}`, `{project_name}`, `{date}`. Missing → neutral defaults; never block.
|
||||
4. **If launched headless** (a machine signal, not a human asking for output — `references/headless.md` lists them): load `references/headless.md` and follow it for the whole run. It is the *only* context where you generate ideas yourself; never load it otherwise.
|
||||
5. **Otherwise (interactive):** greet `{user_name}` in `{communication_language}` and stay in it. Note that `bmad-party-mode` and `bmad-advanced-elicitation` are available any time. Glob `{workflow.output_dir}/*/.memlog.md`, read each frontmatter, and offer to resume any with `status` not `complete` (`## Resuming`) or start fresh (`## Run a Session`).
|
||||
|
||||
Run each `{workflow.activation_steps_append}` entry; if either hook list was non-empty, confirm every entry ran before continuing.
|
||||
|
||||
## Framing — hold this the whole run
|
||||
|
||||
These fight your defaults, in every mode; hold them deliberately. The stance you pick adds one more frame (`references/mode-*.md`) on top.
|
||||
|
||||
- **Aim past 100 ideas; resist concluding.** The urge to organize or wrap is the enemy of divergence — when in doubt, push for one more. Land only when the user is spent or the topic is mined out.
|
||||
- **Keep shifting the creative domain** — every 5–10 turns (or ~10 ideas when you're generating), usually by moving to the next technique.
|
||||
- **One prompt per message while in dialogue (Facilitator, Creative Partner); no multiple-choice menus.** Don't stack questions into a wall or hand a menu that invites lazy picking — both pull the user out of generating. The only exceptions are the two up-front *process* choices (stance, and the technique flow): *how* to run is theirs to pick; *what* to ideate never is.
|
||||
|
||||
**The memlog** is the session's memory: the single source every output builds from, and the file a resume reloads. Whatever isn't in it is gone. Log every idea, decision, question, and bit of user direction — anything you'd regret losing if the window closed — one line each, the gist in the user's meaning, in time order; never edit or reorder. Skip your prompts and small talk. All writes to memlog are atomic and use the script `memlog.py` invoked as follows:
|
||||
|
||||
- `uv run {project-root}/_bmad/scripts/memlog.py init --workspace {doc_workspace} --field topic="<topic>" --field goal="<goal>" --field mode="<facilitator|partner|autonomous>"` — create it once topic, goal, and stance are known.
|
||||
- `uv run {project-root}/_bmad/scripts/memlog.py append --workspace {doc_workspace} --type <kind> --text "<one-line gist>"` — log one entry. `--type` ∈ `idea`/`insight`/`question`/`decision`/`direction`/`technique` (a switch: `--text "started <name>"`); omit for a plain note. Add `--by user`/`--by coach` to mark authorship — **required in Creative Partner mode** (renders `(idea by user)`); skip it otherwise.
|
||||
- `uv run {project-root}/_bmad/scripts/memlog.py set --workspace {doc_workspace} --key status --value complete` — flip status at wrap-up.
|
||||
|
||||
## Run a Session
|
||||
|
||||
Open with one compound question what are we brainstorming, and what's the goal or why behind it (along with asking if there are any inputs or special requests). The why shapes technique choice and synthesis (*kids' iPhone apps to build with your own kids* vs. *to win market share* point different ways). If the kickoff already made both clear, skip the question and confirm; read anything they point you to. Derive a kebab-case `{topic_slug}` and bind `{doc_workspace} = {workflow.output_dir}/{workflow.output_folder_name}/`.
|
||||
|
||||
Now set the **stance** and the **technique batch** in one step — the composer page does both, so make it the default.
|
||||
|
||||
**The composer page (primary).** The file is `{skill-root}/assets/brain-selector.html`. With a customized catalog (overridden `{workflow.brain_methods}` or any `{workflow.additional_techniques}`), regenerate it first: `uv run {skill-root}/scripts/brain.py --file {workflow.brain_methods} [--extra {doc_workspace}/extra-techniques.json] html --out {doc_workspace}/brain-selector.html` (pass `--extra`, a JSON list of `{category, technique_name, description}`, when there are additional techniques; the file is then `{doc_workspace}/brain-selector.html`). Try to open it (`open` / `xdg-open` / `start`), then say, in one message: *"It should open in your browser — compose your session, click **Copy prompt**, and paste the result back. If it didn't open, open `<path>` yourself, or say 'let's do it in chat'."* You can't see their browser, so never claim it opened.
|
||||
|
||||
Read the pasted block: the **`Facilitation mode:`** line → the stance; the **listed techniques** (full category/name/description, some tagged `(random pick)`) → run them as given, no `list`/`show` needed; **`invent N`** / **`you choose N`** → see `## Choosing Techniques`.
|
||||
|
||||
**Or in chat.** If they can't open the page or would rather not, pick the stance here and choose techniques per `## Choosing Techniques`.
|
||||
|
||||
Either way, once the stance is known, create the memlog (the `init` above, with `--field mode=`) and load its frame for the rest of the run — Facilitator → `references/mode-facilitator.md`, Creative Partner → `references/mode-partner.md`, Ideate for me → `references/mode-autonomous.md`. Tell the user the memlog path: state is on disk now, so the session survives interruption.
|
||||
|
||||
## Choosing Techniques
|
||||
|
||||
For **Facilitator** and **Creative Partner**. (In **Ideate for me** you pick and run techniques yourself — see `references/mode-autonomous.md`.)
|
||||
|
||||
Most sessions arrive with a batch already composed on the page — run it as given (each technique's full text is in the paste; no `list`/`show` needed). Two parts of a paste delegate back to you:
|
||||
|
||||
- **`invent N`** (Inventive Flow) — invent N brand-new techniques on the fly. A line may scope an invention (`invent 1 new technique in the spirit of <category>`, from the page's per-category invent card) — when it does, honor that category's spirit. Announce the order, log each one's name + description, and offer to save a keeper to `{workflow.additional_techniques}` at wrap-up.
|
||||
- **`you choose N`** (Facilitator Chosen) — pick N techniques fitting the goal, `{workflow.favorite_techniques}` first; confirm exact names with a scoped `uv run {skill-root}/scripts/brain.py --file {workflow.brain_methods} list --category <cat>`. Never pull the library whole into context.
|
||||
|
||||
If they didn't use the page, load `references/in-chat-techniques.md` and pick the batch in chat (**3–4 is the sweet spot**).
|
||||
|
||||
Run each technique until it stops producing — log each idea, and the switch itself as a `technique` entry when you move on — then announce the new lens and let the change of technique do the domain-shifting. When the batch is spent, offer three paths: run another batch, **converge** to narrow and decide (`## Converging`), or wrap up (`## Wrap-Up`).
|
||||
|
||||
## Converging
|
||||
|
||||
The catalog is all *divergent* — built to generate. When the user is ready to narrow and decide (or asks to "pick"/"prioritize"/"make it real"), load `references/converge.md` and follow it; it ends by handing off to `## Wrap-Up`. Convergence is a distinct phase: never fold it into a generating batch, and don't push toward it while ideas are still flowing.
|
||||
|
||||
## Resuming
|
||||
|
||||
Picking up an existing session instead of starting fresh: load `references/resume.md` and follow it.
|
||||
|
||||
## Wrap-Up
|
||||
|
||||
Load `references/finalize.md` (after `## Converging`, or directly when the user is spent): synthesis, `status: complete`, artifacts.
|
||||
|
||||
239
.agent/skills/bmad-brainstorming/analysis/catalog-analysis.md
Normal file
239
.agent/skills/bmad-brainstorming/analysis/catalog-analysis.md
Normal file
@@ -0,0 +1,239 @@
|
||||
# BMad Brainstorming Catalog — Deep Analysis
|
||||
|
||||
> Analysis of the brainstorming library (`assets/brain-methods.csv`) and the selection
|
||||
> experience (`assets/brain-selector.html`, generated by `scripts/brain.py`). Companion
|
||||
> data: `method-matrix.csv` (every method tagged on 4 axes).
|
||||
>
|
||||
> **Status (implemented, uncommitted for review):** CSV extended with `provenance` /
|
||||
> `good_for` / `audience` columns; 8 researched `classic` methods added (108 total);
|
||||
> `brain.py` now renders a "Proven & Professional" lead group, super-group ordering, a
|
||||
> "Great for" goal filter, and a per-category "Invent a … technique" card; convergence
|
||||
> shipped as `references/converge.md` (diverge → converge → finalize) and wired into
|
||||
> `SKILL.md`. Sections below are the rationale.
|
||||
|
||||
---
|
||||
|
||||
## 1. TL;DR
|
||||
|
||||
The catalog is strong, distinctive, and well-built. The opportunities are not "more methods" so much as **navigation and intent**:
|
||||
|
||||
1. **The selector sorts categories alphabetically.** There is no ordering/grouping layer, so the well-known professional methods (SCAMPER, Six Hats, Five Whys, etc.) are scattered across four categories and buried below `Absurdist` and `Biomimetic`. Enterprise users meet whimsy before they meet anything they recognize. → **Add a grouping + ordering layer; lead with a "Proven & Professional" group.**
|
||||
2. **Nothing connects the user's stated goal to technique choice.** The skill asks for the goal up front but then offers an alphabetical wall. The single highest-value addition is a **goal → technique affinity layer** so "I'm adding a feature to a brownfield app" surfaces a different short-list than "planning a sabbatical."
|
||||
3. **The catalog is 100% divergent (generative).** There is essentially no *convergence* (prioritize / cluster / decide). This is partly a sound principle and partly a real gap — see §5.
|
||||
4. **Real overlap exists**, but it's mostly "same cognitive move, different costume." Four mechanisms (perspective-shift, constraint, analogy, inversion) account for ~60 of 100 methods; sensory, questioning, systems, and time-shift are comparatively thin.
|
||||
5. **Descriptions should stay terse** — the brevity is correct. Only two targeted fixes are warranted: the `collaborative` category silently assumes multiple humans, and ~10 "vibe-only" methods lack an output anchor.
|
||||
6. **Per-category "invent on the fly" is a good idea** — but implement it as a generated synthetic card per section, not 13 near-duplicate CSV rows.
|
||||
|
||||
---
|
||||
|
||||
## 2. Method — how this was analyzed
|
||||
|
||||
Each of the 100 methods was tagged on **four independent axes** (see `method-matrix.csv`). Category alone only captures *aesthetic/mechanism*; these four axes are what expose grouping, overlap, gaps, and the goal-routing opportunity.
|
||||
|
||||
| Axis | Values | Answers |
|
||||
|---|---|---|
|
||||
| **Provenance** | `classic` · `signature` · `playful` | What goes in the enterprise "proven" group? |
|
||||
| **Mechanism** (primary + secondary) | inversion · analogy · perspective · constraint · decomposition · time-shift · systems · sensory · questioning · combination · provocation · convergence | Where is the catalog redundant vs thin? |
|
||||
| **Goal affinity** (multi) | feature · novel · personal · strategy · planning · diagnosis · unstuck | Given the user's goal, what should we recommend? |
|
||||
| **Audience** | solo · group · either | What breaks in a 1:1 user+LLM session? |
|
||||
|
||||
---
|
||||
|
||||
## 3. Findings
|
||||
|
||||
### 3a. Provenance — the "proven & professional" set exists, but is scattered
|
||||
|
||||
The methods an innovation consultant or enterprise facilitator would recognize by name are spread across `structured`, `deep`, `creative`, and `collaborative`. The **canonical core (~22)**:
|
||||
|
||||
> SCAMPER · Six Thinking Hats · Mind Mapping · Lotus Blossom · Crazy 8s · Disney Method ·
|
||||
> Starbursting · Morphological Analysis · Five Whys · Laddering · Causal Loop Mapping ·
|
||||
> First Principles · Reverse Brainstorming · Assumption Reversal · Worst Possible Idea ·
|
||||
> Provocation (PO) · Question Storming · Brainwriting/Round Robin · Yes-And · Random Stimulation ·
|
||||
> Role Playing · Analogical Thinking
|
||||
|
||||
A second tier is *recognizable-adjacent* (Concept Blending, Forced Relationships, Decision Tree, Solution Matrix, Failure Analysis/pre-mortem, Devil's Advocate, 1000x Budget). Everything else is `signature` (BMad-original, serious) or `playful` (the delight layer — `wild`, `absurdist`, `theatrical`, much of `quantum`/`cultural`).
|
||||
|
||||
**Recommendation — lead with "Proven & Professional."** Three ways to implement (pick in review):
|
||||
|
||||
- **Option A — Tag + generated lead section (recommended).** Add a `provenance` column to the CSV. `brain.py` renders a synthetic **"Proven & Professional"** section *first* (pulling all `classic`-tagged methods, cross-category), then the existing categories grouped and ordered (see §7). A method keeps its home category and also appears in the lead group. Pro: zero loss of mechanism categorization; enterprise sees credibility first. Con: those ~22 methods appear twice on the browse page (arguably fine — or filter them out of their home category).
|
||||
- **Option B — New `classic` category.** Move the ~22 into a single first category. Pro: simplest. Con: destroys the mechanism grouping (SCAMPER is *also* structured; Five Whys is *also* deep), and the category becomes a grab-bag.
|
||||
- **Option C — Two-level groups only, no provenance tag.** Reorder the 13 categories into super-groups (§7) so "serious" comes first, but don't pull classics out. Pro: cleanest data model. Con: doesn't actually cluster the *named* methods — they stay scattered within their categories.
|
||||
|
||||
My pick: **A.** It satisfies "professional methods grouped and shown first" literally, without flattening the taxonomy that makes the rest of the catalog shine.
|
||||
|
||||
### 3b. Mechanism — the catalog has four over-served "spines"
|
||||
|
||||
Primary-mechanism distribution across the 100:
|
||||
|
||||
| Mechanism | ~count | Read |
|
||||
|---|---|---|
|
||||
| **perspective-shift** | ~18 | Over-served. Role Playing, Six Hats, Persona, Alien, Ancestor Council, Inner Child, Future Self, Drunk Uncle, Golden Retriever, Infomercial… all "adopt another viewpoint," differentiated only by *who*. |
|
||||
| **constraint** | ~16 | Over-served. What If, the entire `constraint` category, 1000x, Post-Scarcity, Parallel Universe, Zombie, Quantum Tunneling, Permission Giving… all "add/remove/exaggerate a limit." |
|
||||
| **analogy / transfer** | ~12 | Healthy. Analogical, Metaphor, Cross-Pollination, Trait Transfer, Nature's Solutions, Fusion Cuisine, Proverb, Random Stimulation. |
|
||||
| **inversion** | ~11 | Healthy but clustered. Reverse, Assumption Reversal, Worst Idea, Anti-Solution, Failure Analysis, Devil's Advocate, Cursed Genie, Villain's Monologue, Trickster. |
|
||||
| **combination** | ~9 | Fine. |
|
||||
| **decomposition** | ~9 | Fine. |
|
||||
| **systems / emergence** | ~7 | Thin-ish (concentrated in `quantum`/`biomimetic`). |
|
||||
| **time-shift** | ~6 | Thin. |
|
||||
| **questioning** | ~5 | Thin. |
|
||||
| **sensory / intuitive** | ~5 | Thin (all in `introspective_delight`). |
|
||||
| **convergence** | ~1 | **Effectively absent** (only Superposition Collapse). See §5. |
|
||||
|
||||
**Takeaway:** the redundancy is not a defect to delete — the *costume* (a villain's monologue vs. a courtroom vs. "make it worse") is exactly what makes a 30th inversion technique feel fresh to a user. But a curator should know the catalog leans hard on perspective + constraint, and that **convergence is the one genuinely empty cell.** New methods (§6) should target the thin cells, not the spines.
|
||||
|
||||
### 3c. Goal affinity — the headline missing capability
|
||||
|
||||
`SKILL.md` already opens with *"what are we brainstorming, and what's the goal?"* — but that goal never routes technique selection. Mapping the matrix's `goal_affinity` tags gives a ready recommendation table. This is what powers "AI picks N" intelligently and what an enterprise user wants:
|
||||
|
||||
| Goal | Strong default techniques (lead picks **bold**) |
|
||||
|---|---|
|
||||
| **Build a feature** (greenfield/brownfield) | **First Principles**, **SCAMPER**, **Morphological Analysis**, Crazy 8s, Solution Matrix, Reverse Brainstorming, One Feature Only, Ship in 60 Minutes, Chaos Engineering, Cursed Genie (edge cases), Persona Journey, *+ new: Job to Be Done, Follow the Anomaly* |
|
||||
| **Novel concept / new product** | **Concept Blending**, **Cross-Pollination**, **Forced Relationships**, What If, Trait Transfer, Nature's Solutions, Fusion Cuisine, Emerging Tech Collision, Crank the Dial to 11, Quantum Tunneling |
|
||||
| **Personal / life decision** | **Future Self Interview**, **Values Archaeology**, **Laddering**, Six Hats, Ancestor Council, Proverb Mining, Mythic Frameworks, the `introspective_delight` set, *+ new: Build on What Works* |
|
||||
| **Strategy / positioning** | **Six Thinking Hats**, **Failure Analysis** (pre-mortem), Field Lines, Ecosystem Thinking, Utopia vs Dystopia, 1000x Budget, Disney Method, Relativity Frame Shift, Infomercial at 3AM, Predator & Prey |
|
||||
| **Concrete planning** (event/project) | **Mind Mapping**, **Lotus Blossom**, Morphological Analysis, Decision Tree, Six Hats, $0 Mandate, Constraint Roulette, Time Horizon Ladder |
|
||||
| **Root-cause / diagnosis** | **Five Whys**, **Causal Loop Mapping**, Failure Analysis, Constraint Mapping, Question Storming, Starbursting, Anti-Solution, Alien Anthropologist |
|
||||
| **Get unstuck / break fixation** | **Random Stimulation**, **Provocation**, **Worst Possible Idea**, Crank the Dial to 11, Constraint Roulette, Three Rounds of Stupid, Drunk History, most of `wild`/`absurdist`/`theatrical` |
|
||||
|
||||
**Recommendation:** persist this as machine-readable affinity (a `goals` column on the CSV, sourced from `method-matrix.csv`), then (1) have the skill recommend a batch from the up-front goal, and (2) let the composer page filter/highlight "great for: [your goal]." This is the single change that most improves both enterprise and casual use.
|
||||
|
||||
### 3d. Audience — the `collaborative` category quietly assumes a room of people
|
||||
|
||||
5 of the 8 `collaborative` methods (Round Robin, Relay Race, Hot Potato, Fold the Paper, Steal & Upgrade) are written for *multiple humans passing artifacts*. In the default 1:1 user+LLM session they don't translate without the coach silently reinterpreting them. This is the one place the catalog can mislead. Options: tag `audience`, and either (a) add a one-clause solo adaptation to each, or (b) have the skill note "this one shines with a group" when picked solo. Low effort, removes the only real footgun.
|
||||
|
||||
### 3e. Description anchoring — keep terse, fix ~12 specifically
|
||||
|
||||
The deliberate brevity is **right** — the gist + a creative LLM beats over-specification, and it matches the catalog's house style. Do **not** bulk-expand. Two surgical passes only:
|
||||
|
||||
1. **Group-dependent `collaborative` methods** (§3d) — add a short solo-mode clause or an audience tag.
|
||||
2. **~10 "vibe-only" methods** where the *evocation is great but the output is ambiguous*, so different LLM runs would diverge wildly: e.g. **Field Lines**, **Observer Effect**, **Guerrilla Gardening Ideas**, **Emergent Thinking**, **Entanglement Thinking**, **Elemental Forces**. A tiny "…so that ___" outcome clause anchors the deliverable without killing the brevity. Example: *Guerrilla Gardening Ideas* → add "…**so you surface where an unsanctioned, low-visibility pilot could prove the idea before anyone can veto it**."
|
||||
|
||||
Everything crisp (Five Whys, SCAMPER, First Principles, Crazy 8s) stays untouched.
|
||||
|
||||
---
|
||||
|
||||
## 4. Quick wins vs structural changes
|
||||
|
||||
| Change | Effort | Impact | Type |
|
||||
|---|---|---|---|
|
||||
| Goal→technique affinity (`goals` column + recommendation) | Med | **High** | structural |
|
||||
| "Proven & Professional" lead group + category ordering | Med | **High** (enterprise) | structural |
|
||||
| Per-category "invent in the spirit" card (§6) | Low | Med | quick win |
|
||||
| Convergence mini-set (§5) | Low–Med | Med–High | structural (philosophy) |
|
||||
| `audience` tag + collaborative fix (§3d) | Low | Med | quick win |
|
||||
| ~12 description anchors (§3e) | Low | Low–Med | quick win |
|
||||
| New gap-filling methods (§6) | Low | Med | additive |
|
||||
|
||||
---
|
||||
|
||||
## 5. Divergent vs convergent — the answer, and a recommendation
|
||||
|
||||
**What it is.** Divergent = generate (quantity, novelty, breadth). Convergent = evaluate, cluster, prioritize, decide. A complete creative process needs both (cf. the Double Diamond, Osborn-Parnes CPS): diverge wide, *then* converge to a choice.
|
||||
|
||||
**Where the catalog stands.** All 100 methods are divergent. `SKILL.md` explicitly enforces divergence ("resist concluding… the urge to organize is the enemy of divergence"), and the only convergent-flavored technique is Quantum → *Superposition Collapse*. Synthesis is deferred entirely to `references/finalize.md` at wrap-up.
|
||||
|
||||
**Is that a mistake?** Mostly a *good instinct taken to a defensible extreme.* Separating generation from judgment is the foundational brainstorming rule — premature convergence is the #1 killer of ideas, so a divergence-pure generator is legitimate. But the consequence is that the user has **no technique to pick when they're ready to narrow** — they hit "100 ideas" and the tool's stance is "keep going," with only the wrap-up doing light synthesis. For project/feature/life-decision work especially, people *do* want to land.
|
||||
|
||||
**Recommendation — add a small, fenced convergence set, never mixed into the divergent flow.** Keep divergence pure during generation; offer convergence only at wrap-up or on explicit request ("okay, help me narrow"). Concretely: a new `converge` category (4 methods, §6), tagged `mechanism=convergence`, surfaced by `finalize.md` / on demand — not in the default 3–4 sweet-spot batch. This completes the loop while honoring the separate-generation-from-judgment principle. **This is a philosophy decision for you to confirm** — it's the one recommendation that changes what the skill *is*, not just what's in the library.
|
||||
|
||||
---
|
||||
|
||||
## 6. Proposed new methods (fill the thin cells)
|
||||
|
||||
Targeting the under-served mechanisms (§3b), the empty convergence cell (§5), and the goal gaps (§3c). CSV-style (`category, name, description`) so they can drop straight in:
|
||||
|
||||
**Feature/product & enterprise gaps (mechanism: questioning/decomposition):**
|
||||
- `structured, Job to Be Done, "Ask what the user is really hiring this to do; brainstorm around that underlying job, not the feature you assumed"`
|
||||
- `structured, Empathy Map, "Map what the user says, thinks, does, and feels around the problem; mine each quadrant for the unmet need hiding there"`
|
||||
- `deep, Follow the Anomaly, "Start from one surprising number or outlier and ideate only from what would explain it or exploit it"`
|
||||
|
||||
**Strengths-based (the missing positive frame — Appreciative Inquiry is a glaring classic-tier omission):**
|
||||
- `deep, Build on What Works, "Name what's already succeeding and why, then ideate how to amplify and extend it instead of fixing what's broken"`
|
||||
|
||||
**Convergence set (new `converge` category — only if §5 is adopted):**
|
||||
- `converge, Impact Effort Triage, "Plot every idea by impact against effort; harvest the high-impact, low-effort quadrant first and quarantine the rest"`
|
||||
- `converge, Forced Ranking, "Make the ideas fight: each must beat another to survive to a ranked top-N, no ties allowed"`
|
||||
- `converge, NUF Test, "Score each idea New, Useful, Feasible 1-10; the totals expose the quiet winners and the dazzling dead-ends"`
|
||||
- `converge, Affinity Clustering, "Group the raw ideas into themes, name each cluster, then ideate fresh at the theme level"`
|
||||
|
||||
(Optional, lower priority: `structured, Storyboarding` for sequenced/experience ideation.)
|
||||
|
||||
---
|
||||
|
||||
## 7. Category roster & ordering recommendations
|
||||
|
||||
**Ordering (replace alphabetical with a deliberate progression):** add a `CATEGORY_ORDER` + `GROUP` map in `brain.py` (mirroring the existing `_HUES` map — derived for the shipped set, alphabetical fallback for custom catalogs). Proposed super-groups, in order:
|
||||
|
||||
1. **Proven & Professional** — the `classic` lead section (§3a, Option A)
|
||||
2. **Structured & Analytical** — structured, deep
|
||||
3. **Creative & Generative** — creative, biomimetic, cultural, speculative_future, quantum
|
||||
4. **Wild & Playful** — wild, absurdist, theatrical, constraint
|
||||
5. **Introspective & Personal** — introspective_delight, collaborative
|
||||
6. **Decide & Converge** — converge *(if §5 adopted)*
|
||||
|
||||
**Roster notes:**
|
||||
- No category should be deleted. The overlap (§3b) is intentional costume variety.
|
||||
- `quantum` and `cultural` are the most abstract/uneven — a couple of their members (Field Lines, Observer Effect) are the vaguest in the whole set; anchor per §3e rather than cut.
|
||||
- `constraint` is excellent and tight — leave as is.
|
||||
|
||||
---
|
||||
|
||||
## 8. Per-category "invent in the spirit of this category"
|
||||
|
||||
You asked whether each category should also offer an on-the-fly invented technique in its own spirit. **Yes — but don't add 13 near-duplicate rows to the CSV.** The composer already has a global **Invent N** stepper, and `brain.py` already generates section markup from the catalog. So:
|
||||
|
||||
> Have `brain.py` append **one synthetic card per category section** — a dashed "✨ Invent a *{Category}* technique" card. Selecting it emits a paste directive like `invent 1 (in the spirit of {category})`, reused by the existing Inventive-Flow plumbing in `SKILL.md` (which already handles `invent N` and offering keepers to `additional_techniques`).
|
||||
|
||||
Benefits: CSV stays a clean library of *real* techniques; behavior is consistent everywhere; it leverages plumbing that already exists; and it gives the user the "surprise me, but on-theme" affordance per category without library bloat.
|
||||
|
||||
---
|
||||
|
||||
## 9. Open decisions for BMad (in priority order)
|
||||
|
||||
1. **Goal-affinity layer** — adopt the `goals` column + recommendation routing? (Highest impact.)
|
||||
2. **Proven & Professional grouping** — Option A (tag + generated lead section, recommended), B, or C? (§3a)
|
||||
3. **Convergence** — add the fenced `converge` set, or stay divergence-pure? (§5 — philosophy decision.)
|
||||
4. **New methods** — approve the §6 set? Which ones?
|
||||
5. **Per-category invent card** — approve the generated-card approach? (§8)
|
||||
6. **Description anchoring** — approve the targeted ~12 (incl. collaborative fix), keep everything else terse? (§3e)
|
||||
7. **Category ordering / super-groups** — adopt §7?
|
||||
|
||||
Once you mark these, the implementation is: extend the CSV schema (`provenance`, `good_for`, `audience` columns — additive, backward-compatible with `brain.py`'s `DictReader`), add the ordering/grouping + synthetic-card logic to `brain.py`, regenerate `brain-selector.html`, update the relevant `SKILL.md` / `references/*` flow, and run `scripts/tests/`.
|
||||
|
||||
---
|
||||
|
||||
## 10. Revised convergence architecture (per BMad direction)
|
||||
|
||||
**Decision locked:** convergence is **not** a CSV category of selectable cards. It's a **reference phase**, mirroring `references/finalize.md`. The catalog stays a pure *divergent* library; convergence lives in `references/converge.md`.
|
||||
|
||||
**Flow:** diverge (pick & run techniques) → **converge** (`references/converge.md`, on demand or once divergence is spent) → **finalize** (`references/finalize.md`, last). The coach already does ad-hoc convergence implicitly; this makes it an explicit, repeatable phase, and `converge.md` ends by instructing the coach to load `finalize.md` to synthesize and produce artifacts.
|
||||
|
||||
`references/converge.md` contents — a tight set of real, established convergence moves (the coach picks what fits, never dumps a menu):
|
||||
|
||||
- **Affinity Clustering (KJ method)** — group the raw ideas into themes, name each cluster, surface the through-line.
|
||||
- **Dot Voting / Multivoting** — heat-map the favorites; discuss why the hot spots are hot.
|
||||
- **Impact–Effort Matrix** — plot each idea on impact vs effort; harvest high-impact/low-effort first.
|
||||
- **NUF Test** — score New, Useful, Feasible (1–10 each); totals expose quiet winners and dazzling dead-ends.
|
||||
- **PMI (Plus / Minus / Interesting)** — de Bono's fast evaluator for pressure-testing a single strong candidate.
|
||||
- *(optional)* **MoSCoW** (Must/Should/Could/Won't) for product scoping; **Nominal Group Technique** when it's genuinely a group.
|
||||
|
||||
`SKILL.md` change: at the point where a divergent batch is spent, offer "keep diverging / converge & decide / wrap up" — "converge & decide" loads `converge.md`; wrap-up still goes to `finalize.md`.
|
||||
|
||||
## 11. Researched gap-filling additions (real, established methods)
|
||||
|
||||
Web-researched (sources below), chosen to fill the **thin mechanism cells** (questioning, diagnosis, time-shift, empathy) — *not* the over-served spines — and all `classic`-tier, so they also strengthen the "Proven & Professional" group. CSV-style, ready to drop in:
|
||||
|
||||
| Category | Technique | Gist (house style) | Fills |
|
||||
|---|---|---|---|
|
||||
| structured | **How Might We** | "Reframe the problem as a batch of 'How might we…' opportunity questions first, then ideate against the sharpest one" | questioning / problem-framing (design-thinking staple, currently absent) |
|
||||
| deep | **TRIZ Contradiction** | "Name the core contradiction — what only improves by making something else worse — then brainstorm ways to win both instead of trading off" | engineering/feature (no systematic technical method today) |
|
||||
| deep | **Fishbone Diagram** | "Branch the problem's spine into cause categories — people, process, tools, environment — and mine each bone for contributing causes" | diagnosis (named classic complementing Five Whys / Causal Loop) |
|
||||
| structured | **Backcasting** | "Fix the finished future in vivid detail, then work backward step by step to the one move you'd have to make first" | strategy/planning time-shift (serious counterpart to playful future methods) |
|
||||
| speculative_future | **Scenario Cross** | "Pick two high-impact uncertainties, cross them into four futures, and ideate the move that wins in every one" | strategy (2×2 scenario planning — the serious sibling of the playful speculative set) |
|
||||
| structured | **Job to Be Done** | "Ask what the user is really hiring this to do, then ideate around that underlying job, not the feature you assumed" | feature/empathy (enterprise staple) |
|
||||
| structured | **Empathy Map** | "Map what the user says, thinks, does, and feels around the problem; mine each quadrant for the unmet need" | empathy/feature |
|
||||
| deep | **Build on What Works** | "Name what's already succeeding and why, then ideate how to amplify and extend it instead of fixing what's broken" | strengths-based (Appreciative Inquiry — a glaring classic-tier omission) |
|
||||
|
||||
Deliberately **not** added (would deepen an already over-served spine or duplicate): Synectics (≈ analogy/metaphor), SWOT (analysis, not ideation), Rolestorming (≈ Role Playing), Brainwalking/Braindumping (≈ Brainwriting), Pre-mortem (≈ Failure Analysis).
|
||||
|
||||
**Sources:** [IxDF — essential ideation techniques](https://ixdf.org/literature/article/introduction-to-the-essential-ideation-techniques-which-are-the-heart-of-design-thinking) · [Quality Magazine — TRIZ](https://www.qualitymag.com/articles/98566-triz-the-backbone-of-innovation-and-problem-solving) · [ASQ — Fishbone/Ishikawa](https://asq.org/quality-resources/fishbone) · [Futures Platform — 2×2 scenario matrix](https://www.futuresplatform.com/blog/2x2-scenario-planning-matrix-guideline) · [NN/g — Dot Voting](https://www.nngroup.com/articles/dot-voting/) · [Quality Gurus — divergent vs convergent](https://www.qualitygurus.com/divergent-vs-convergent-thinking/)
|
||||
109
.agent/skills/bmad-brainstorming/analysis/method-matrix.csv
Normal file
109
.agent/skills/bmad-brainstorming/analysis/method-matrix.csv
Normal file
@@ -0,0 +1,109 @@
|
||||
category,technique,provenance,mechanism_primary,mechanism_secondary,goal_affinity,audience
|
||||
collaborative,Yes And Building,classic,combination,perspective,novel|unstuck|planning,group
|
||||
collaborative,Brain Writing Round Robin,classic,combination,decomposition,novel|feature,group
|
||||
collaborative,Random Stimulation,classic,analogy,,unstuck|novel,either
|
||||
collaborative,Role Playing,classic,perspective,,strategy|personal|feature,either
|
||||
collaborative,Ideation Relay Race,playful,combination,,unstuck,group
|
||||
collaborative,Idea Hot Potato,playful,combination,,unstuck,group
|
||||
collaborative,Steal And Upgrade,signature,combination,analogy,novel|unstuck,group
|
||||
collaborative,Fold The Paper,playful,combination,,unstuck|novel,group
|
||||
creative,What If Scenarios,signature,constraint,,novel|strategy|unstuck,either
|
||||
creative,Analogical Thinking,signature,analogy,,feature|novel|diagnosis,either
|
||||
creative,First Principles Thinking,classic,decomposition,,feature|novel|diagnosis|strategy,either
|
||||
creative,Forced Relationships,signature,combination,analogy,novel|unstuck,either
|
||||
creative,Time Shifting,signature,time-shift,perspective,novel|unstuck,either
|
||||
creative,Metaphor Mapping,signature,analogy,,novel|diagnosis,either
|
||||
creative,Cross-Pollination,signature,analogy,,novel|feature|strategy,either
|
||||
creative,Concept Blending,signature,combination,,novel,either
|
||||
creative,Reverse Brainstorming,classic,inversion,,diagnosis|feature|unstuck,either
|
||||
creative,Sensory Exploration,signature,sensory,,novel|unstuck,either
|
||||
deep,Five Whys,classic,questioning,,diagnosis,either
|
||||
deep,Provocation Technique,classic,provocation,inversion,unstuck|novel,either
|
||||
deep,Assumption Reversal,classic,inversion,,novel|diagnosis|strategy,either
|
||||
deep,Question Storming,classic,questioning,,diagnosis|strategy|unstuck,either
|
||||
deep,Constraint Mapping,signature,constraint,decomposition,feature|strategy|diagnosis,either
|
||||
deep,Failure Analysis,signature,inversion,diagnosis,diagnosis|strategy|feature,either
|
||||
deep,Emergent Thinking,signature,systems,,strategy|novel,either
|
||||
deep,Causal Loop Mapping,classic,systems,,diagnosis|strategy,either
|
||||
deep,Morphological Analysis,classic,decomposition,combination,feature|novel|planning,either
|
||||
deep,Laddering,classic,questioning,decomposition,personal|strategy|diagnosis,either
|
||||
introspective_delight,Inner Child Conference,signature,perspective,sensory,personal|unstuck,solo
|
||||
introspective_delight,Shadow Work Mining,signature,sensory,,personal|diagnosis,solo
|
||||
introspective_delight,Values Archaeology,signature,questioning,,personal|strategy,solo
|
||||
introspective_delight,Future Self Interview,signature,perspective,time-shift,personal,solo
|
||||
introspective_delight,Body Wisdom Dialogue,signature,sensory,,personal,solo
|
||||
introspective_delight,Permission Giving,signature,provocation,constraint,personal|unstuck,solo
|
||||
introspective_delight,Secret Wish Confession,signature,sensory,,personal,solo
|
||||
introspective_delight,Mood Weather Report,signature,sensory,,personal|unstuck,solo
|
||||
structured,SCAMPER Method,classic,combination,decomposition,feature|novel,either
|
||||
structured,Six Thinking Hats,classic,perspective,,strategy|diagnosis|planning|personal,either
|
||||
structured,Decision Tree Mapping,signature,decomposition,,planning|strategy|diagnosis,either
|
||||
structured,Solution Matrix,signature,decomposition,,feature|planning,either
|
||||
structured,Trait Transfer,signature,analogy,,novel|feature,either
|
||||
structured,Lotus Blossom,classic,decomposition,,feature|planning|novel,either
|
||||
structured,Worst Possible Idea,classic,inversion,,unstuck|novel,either
|
||||
structured,Disney Method,classic,perspective,,feature|strategy|planning,either
|
||||
structured,Starbursting,classic,questioning,,feature|planning|diagnosis,either
|
||||
structured,Mind Mapping,classic,decomposition,,planning|novel|feature,either
|
||||
structured,Crazy 8s,classic,combination,,feature|novel|unstuck,either
|
||||
theatrical,Time Travel Talk Show,playful,perspective,time-shift,novel|personal,either
|
||||
theatrical,Alien Anthropologist,playful,perspective,,diagnosis|unstuck|strategy,either
|
||||
theatrical,Dream Fusion Laboratory,signature,constraint,time-shift,novel|unstuck,either
|
||||
theatrical,Emotion Orchestra,playful,sensory,perspective,personal|strategy,either
|
||||
theatrical,Parallel Universe Cafe,playful,constraint,,novel|unstuck,either
|
||||
theatrical,Persona Journey,signature,perspective,,feature|strategy,either
|
||||
theatrical,Devil's Advocate Courtroom,signature,inversion,perspective,strategy|diagnosis,group
|
||||
wild,Chaos Engineering,signature,inversion,constraint,feature|diagnosis|strategy,either
|
||||
wild,Guerrilla Gardening Ideas,playful,analogy,,strategy|unstuck,either
|
||||
wild,Pirate Code Brainstorm,playful,combination,analogy,novel|unstuck,either
|
||||
wild,Zombie Apocalypse Planning,playful,constraint,,feature|strategy|unstuck,either
|
||||
wild,Drunk History Retelling,playful,perspective,,unstuck|diagnosis,either
|
||||
wild,Anti-Solution,signature,inversion,,diagnosis|unstuck,either
|
||||
wild,Elemental Forces,playful,perspective,analogy,novel|unstuck,either
|
||||
biomimetic,Nature's Solutions,signature,analogy,,feature|novel,either
|
||||
biomimetic,Ecosystem Thinking,signature,systems,,strategy|diagnosis,either
|
||||
biomimetic,Evolutionary Pressure,signature,systems,,feature|novel,either
|
||||
biomimetic,Predator & Prey,signature,perspective,inversion,strategy|feature,either
|
||||
biomimetic,Metamorphosis Stages,signature,time-shift,decomposition,novel|strategy,either
|
||||
biomimetic,Swarm Logic,signature,systems,,feature|strategy,either
|
||||
quantum,Observer Effect,signature,systems,perspective,strategy|diagnosis,either
|
||||
quantum,Entanglement Thinking,signature,systems,,diagnosis|strategy,either
|
||||
quantum,Superposition Collapse,signature,convergence,decomposition,strategy|diagnosis,either
|
||||
quantum,Relativity Frame Shift,signature,perspective,,strategy|novel,either
|
||||
quantum,Field Lines,signature,systems,,strategy,either
|
||||
quantum,Quantum Tunneling,signature,constraint,,unstuck|novel,either
|
||||
cultural,Indigenous Wisdom,signature,perspective,analogy,personal|strategy|novel,either
|
||||
cultural,Fusion Cuisine,signature,combination,analogy,novel,either
|
||||
cultural,Ritual Innovation,signature,analogy,,novel|personal,either
|
||||
cultural,Mythic Frameworks,signature,analogy,perspective,strategy|personal|novel,either
|
||||
cultural,Proverb Mining,signature,analogy,,personal|strategy,either
|
||||
cultural,Ancestor Council,signature,perspective,,personal|strategy,either
|
||||
cultural,Trickster's Gambit,playful,inversion,provocation,unstuck|strategy,either
|
||||
absurdist,Villain's Monologue,playful,inversion,perspective,diagnosis|strategy|unstuck,either
|
||||
absurdist,Explain It to a Golden Retriever,playful,perspective,,unstuck|diagnosis|feature,either
|
||||
absurdist,Infomercial at 3AM,playful,perspective,,strategy|novel,either
|
||||
absurdist,Drunk Uncle at Thanksgiving,playful,perspective,,unstuck|diagnosis,either
|
||||
absurdist,Cursed Genie,playful,inversion,,diagnosis|feature,either
|
||||
absurdist,Three Rounds of Stupid,playful,provocation,,unstuck|novel,either
|
||||
constraint,Kill the Crown Jewel,signature,constraint,,feature|strategy|unstuck,either
|
||||
constraint,1000x Budget,signature,constraint,,novel|strategy,either
|
||||
constraint,Ship in 60 Minutes,signature,constraint,,feature|planning|unstuck,either
|
||||
constraint,The $0 Mandate,signature,constraint,,planning|strategy|feature,either
|
||||
constraint,One Feature Only,signature,constraint,,feature|strategy,either
|
||||
constraint,Crank the Dial to 11,signature,constraint,,novel|unstuck,either
|
||||
constraint,Constraint Roulette,signature,constraint,,unstuck|feature,either
|
||||
speculative_future,Time Horizon Ladder,signature,time-shift,,strategy|planning|novel,either
|
||||
speculative_future,Post-Scarcity Test,signature,constraint,,novel|strategy,either
|
||||
speculative_future,Utopia vs Dystopia Split-Screen,signature,perspective,inversion,strategy|diagnosis,either
|
||||
speculative_future,Sci-Fi Artifact From the Future,signature,time-shift,perspective,novel|feature,either
|
||||
speculative_future,Emerging Tech Collision,signature,combination,,novel|feature|strategy,either
|
||||
speculative_future,What-If-The-World-Changed Card Flip,signature,constraint,,novel|unstuck,either
|
||||
speculative_future,Future Anthropologist Dig,signature,time-shift,perspective,strategy|novel,either
|
||||
structured,How Might We,classic,questioning,,feature|novel|strategy|diagnosis,either
|
||||
structured,Job to Be Done,classic,perspective,questioning,feature|strategy|novel,either
|
||||
structured,Empathy Map,classic,perspective,,feature|personal,either
|
||||
structured,Backcasting,classic,time-shift,,strategy|planning|novel,either
|
||||
deep,TRIZ Contradiction,classic,inversion,decomposition,feature|novel|diagnosis,either
|
||||
deep,Fishbone Diagram,classic,decomposition,systems,diagnosis,either
|
||||
deep,Build on What Works,classic,perspective,systems,personal|strategy,either
|
||||
speculative_future,Scenario Cross,classic,constraint,systems,strategy|planning,either
|
||||
|
166
.agent/skills/bmad-brainstorming/assets/brain-icons.json
Normal file
166
.agent/skills/bmad-brainstorming/assets/brain-icons.json
Normal file
@@ -0,0 +1,166 @@
|
||||
{
|
||||
"categories": {
|
||||
"creative": {
|
||||
"hue": "#6d5cf0",
|
||||
"glyph": "<g stroke=\"currentColor\" stroke-width=\"2.4\" stroke-linecap=\"round\"><line x1=\"22\" y1=\"6.5\" x2=\"22\" y2=\"12.5\"/><line x1=\"22\" y1=\"31.5\" x2=\"22\" y2=\"37.5\"/><line x1=\"6.5\" y1=\"22\" x2=\"12.5\" y2=\"22\"/><line x1=\"31.5\" y1=\"22\" x2=\"37.5\" y2=\"22\"/><line x1=\"11.3\" y1=\"11.3\" x2=\"15.5\" y2=\"15.5\"/><line x1=\"28.5\" y1=\"28.5\" x2=\"32.7\" y2=\"32.7\"/><line x1=\"32.7\" y1=\"11.3\" x2=\"28.5\" y2=\"15.5\"/><line x1=\"15.5\" y1=\"28.5\" x2=\"11.3\" y2=\"32.7\"/></g><circle cx=\"22\" cy=\"22\" r=\"6.6\" fill=\"currentColor\" fill-opacity=\"0.25\"/><circle cx=\"22\" cy=\"22\" r=\"3.6\" fill=\"currentColor\"/>"
|
||||
},
|
||||
"deep": {
|
||||
"hue": "#4658c9",
|
||||
"glyph": "<g fill=\"none\" stroke=\"currentColor\"><circle cx=\"22\" cy=\"22\" r=\"13\" stroke-width=\"1.5\" stroke-opacity=\"0.4\"/><circle cx=\"22\" cy=\"22\" r=\"9\" stroke-width=\"1.7\" stroke-opacity=\"0.7\"/><circle cx=\"22\" cy=\"22\" r=\"5\" stroke-width=\"1.9\"/></g><circle cx=\"22\" cy=\"22\" r=\"2.4\" fill=\"currentColor\"/>"
|
||||
},
|
||||
"structured": {
|
||||
"hue": "#3b6ea5",
|
||||
"glyph": "<g fill=\"currentColor\"><rect x=\"11\" y=\"11\" width=\"9.5\" height=\"9.5\" rx=\"2\"/><rect x=\"23.5\" y=\"11\" width=\"9.5\" height=\"9.5\" rx=\"2\" fill-opacity=\"0.25\"/><rect x=\"11\" y=\"23.5\" width=\"9.5\" height=\"9.5\" rx=\"2\" fill-opacity=\"0.25\"/><rect x=\"23.5\" y=\"23.5\" width=\"9.5\" height=\"9.5\" rx=\"2\"/></g>"
|
||||
},
|
||||
"quantum": {
|
||||
"hue": "#2b86d9",
|
||||
"glyph": "<g stroke=\"currentColor\" stroke-width=\"1.8\" fill=\"none\"><ellipse cx=\"22\" cy=\"22\" rx=\"14.5\" ry=\"6\" transform=\"rotate(28 22 22)\"/><ellipse cx=\"22\" cy=\"22\" rx=\"14.5\" ry=\"6\" transform=\"rotate(-28 22 22)\"/></g><circle cx=\"22\" cy=\"22\" r=\"6.6\" fill=\"currentColor\" fill-opacity=\"0.18\"/><circle cx=\"22\" cy=\"22\" r=\"3.4\" fill=\"currentColor\"/><circle cx=\"33.2\" cy=\"17.4\" r=\"2\" fill=\"currentColor\"/>"
|
||||
},
|
||||
"speculative_future": {
|
||||
"hue": "#0fb5c9",
|
||||
"glyph": "<g stroke=\"currentColor\" stroke-width=\"2.2\" stroke-linecap=\"round\" stroke-linejoin=\"round\" fill=\"none\"><path d=\"M11 31 L 26.5 15.5\"/><path d=\"M20 14.5 H 28 V 22.5\"/></g><circle cx=\"31\" cy=\"12\" r=\"2.8\" fill=\"currentColor\"/><g stroke=\"currentColor\" stroke-width=\"1.4\" stroke-linecap=\"round\"><line x1=\"31\" y1=\"6.5\" x2=\"31\" y2=\"8.4\"/><line x1=\"31\" y1=\"15.6\" x2=\"31\" y2=\"17.5\"/><line x1=\"25.5\" y1=\"12\" x2=\"27.4\" y2=\"12\"/><line x1=\"34.6\" y1=\"12\" x2=\"36.5\" y2=\"12\"/></g>"
|
||||
},
|
||||
"collaborative": {
|
||||
"hue": "#15a3a3",
|
||||
"glyph": "<g stroke=\"currentColor\" stroke-width=\"1.8\"><line x1=\"14\" y1=\"16\" x2=\"30\" y2=\"16\"/><line x1=\"14\" y1=\"16\" x2=\"22\" y2=\"30\"/><line x1=\"30\" y1=\"16\" x2=\"22\" y2=\"30\"/></g><g fill=\"currentColor\" fill-opacity=\"0.22\"><circle cx=\"14\" cy=\"16\" r=\"4.6\"/><circle cx=\"30\" cy=\"16\" r=\"4.6\"/><circle cx=\"22\" cy=\"30\" r=\"4.6\"/></g><g fill=\"currentColor\"><circle cx=\"14\" cy=\"16\" r=\"2.4\"/><circle cx=\"30\" cy=\"16\" r=\"2.4\"/><circle cx=\"22\" cy=\"30\" r=\"2.4\"/></g>"
|
||||
},
|
||||
"biomimetic": {
|
||||
"hue": "#1f9d6b",
|
||||
"glyph": "<path d=\"M22 7.5 C 31.5 12.5, 31.5 29, 22 36.5 C 12.5 29, 12.5 12.5, 22 7.5 Z\" fill=\"currentColor\" fill-opacity=\"0.22\"/><path d=\"M22 9 V 35.5\" stroke=\"currentColor\" stroke-width=\"1.8\" stroke-linecap=\"round\" fill=\"none\"/><g stroke=\"currentColor\" stroke-width=\"1.5\" stroke-linecap=\"round\"><path d=\"M22 16 l5.6 -2.6\"/><path d=\"M22 16 l-5.6 -2.6\"/><path d=\"M22 22 l6.6 -2.6\"/><path d=\"M22 22 l-6.6 -2.6\"/><path d=\"M22 28 l5.6 -2.6\"/><path d=\"M22 28 l-5.6 -2.6\"/></g>"
|
||||
},
|
||||
"constraint": {
|
||||
"hue": "#d9882b",
|
||||
"glyph": "<g stroke=\"currentColor\" stroke-width=\"2.2\" stroke-linecap=\"round\" stroke-linejoin=\"round\" fill=\"none\"><path d=\"M17 11 H 11 V 17\"/><path d=\"M27 11 H 33 V 17\"/><path d=\"M17 33 H 11 V 27\"/><path d=\"M27 33 H 33 V 27\"/></g><circle cx=\"22\" cy=\"22\" r=\"5\" fill=\"currentColor\" fill-opacity=\"0.25\"/><circle cx=\"22\" cy=\"22\" r=\"2.6\" fill=\"currentColor\"/>"
|
||||
},
|
||||
"wild": {
|
||||
"hue": "#e2562f",
|
||||
"glyph": "<path d=\"M24.5 6.5 L 12.5 24 H 19.5 L 17.5 37.5 L 31.5 18.5 H 24 L 24.5 6.5 Z\" fill=\"currentColor\"/>"
|
||||
},
|
||||
"cultural": {
|
||||
"hue": "#c75b39",
|
||||
"glyph": "<circle cx=\"22\" cy=\"22\" r=\"13.5\" fill=\"currentColor\" fill-opacity=\"0.14\"/><g stroke=\"currentColor\" stroke-width=\"1.6\" fill=\"none\"><circle cx=\"22\" cy=\"22\" r=\"13.5\"/><ellipse cx=\"22\" cy=\"22\" rx=\"6\" ry=\"13.5\"/><line x1=\"8.5\" y1=\"22\" x2=\"35.5\" y2=\"22\"/><path d=\"M11 15 H 33\" stroke-opacity=\"0.55\"/><path d=\"M11 29 H 33\" stroke-opacity=\"0.55\"/></g>"
|
||||
},
|
||||
"theatrical": {
|
||||
"hue": "#cf4d6f",
|
||||
"glyph": "<path d=\"M13 12 H 31 V 22 C 31 30, 27 35, 22 35 C 17 35, 13 30, 13 22 Z\" fill=\"currentColor\" fill-opacity=\"0.18\"/><path d=\"M13 12 H 31 V 22 C 31 30, 27 35, 22 35 C 17 35, 13 30, 13 22 Z\" stroke=\"currentColor\" stroke-width=\"1.8\" fill=\"none\"/><g fill=\"currentColor\"><circle cx=\"18.5\" cy=\"21\" r=\"1.7\"/><circle cx=\"25.5\" cy=\"21\" r=\"1.7\"/></g><path d=\"M18 27 C 20 29.5, 24 29.5, 26 27\" stroke=\"currentColor\" stroke-width=\"1.8\" stroke-linecap=\"round\" fill=\"none\"/>"
|
||||
},
|
||||
"absurdist": {
|
||||
"hue": "#e0529c",
|
||||
"glyph": "<g transform=\"rotate(-12 22 22)\"><circle cx=\"22\" cy=\"22\" r=\"13\" fill=\"currentColor\" fill-opacity=\"0.14\"/><circle cx=\"22\" cy=\"22\" r=\"13\" stroke=\"currentColor\" stroke-width=\"1.6\" fill=\"none\"/><path d=\"M16 19 q 2 -2.4 4 0\" stroke=\"currentColor\" stroke-width=\"1.8\" stroke-linecap=\"round\" fill=\"none\"/><circle cx=\"26.5\" cy=\"18.8\" r=\"1.8\" fill=\"currentColor\"/><path d=\"M16.5 26 C 19 30, 25 30, 28 24.5\" stroke=\"currentColor\" stroke-width=\"1.8\" stroke-linecap=\"round\" fill=\"none\"/></g>"
|
||||
},
|
||||
"introspective_delight": {
|
||||
"hue": "#b15ad6",
|
||||
"glyph": "<circle cx=\"22\" cy=\"13.5\" r=\"4\" fill=\"currentColor\"/><path d=\"M10.5 31 C 12.5 23, 31.5 23, 33.5 31 Z\" fill=\"currentColor\" fill-opacity=\"0.22\"/><path d=\"M10.5 31 C 12.5 23, 31.5 23, 33.5 31\" stroke=\"currentColor\" stroke-width=\"1.7\" fill=\"none\"/><path d=\"M13.5 30 C 16 26.5, 20 25.5, 22 25.5 C 24 25.5, 28 26.5, 30.5 30\" stroke=\"currentColor\" stroke-width=\"1.5\" fill=\"none\" stroke-opacity=\"0.6\"/>"
|
||||
}
|
||||
},
|
||||
"techniques": {
|
||||
"Yes And Building": "<g fill=\"currentColor\"><rect x=\"8\" y=\"27\" width=\"12\" height=\"8\" rx=\"1.5\" fill-opacity=\".8\"/><rect x=\"14\" y=\"19\" width=\"12\" height=\"8\" rx=\"1.5\" fill-opacity=\".5\"/><rect x=\"20\" y=\"11\" width=\"12\" height=\"8\" rx=\"1.5\"/></g>",
|
||||
"Brain Writing Round Robin": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M31 16 A10 10 0 1 0 32.5 22\"/><path d=\"M31 10 L31.5 16.3 L25 16.5\"/></g>",
|
||||
"Random Stimulation": "<rect x=\"11\" y=\"11\" width=\"22\" height=\"22\" rx=\"4\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/><g fill=\"currentColor\"><circle cx=\"17\" cy=\"17\" r=\"1.8\"/><circle cx=\"27\" cy=\"17\" r=\"1.8\"/><circle cx=\"22\" cy=\"22\" r=\"1.8\"/><circle cx=\"17\" cy=\"27\" r=\"1.8\"/><circle cx=\"27\" cy=\"27\" r=\"1.8\"/></g>",
|
||||
"Role Playing": "<rect x=\"11\" y=\"9\" width=\"22\" height=\"26\" rx=\"3\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/><circle cx=\"22\" cy=\"19\" r=\"4\" fill=\"currentColor\"/><path d=\"M15.5 30 c2 -4.5 11 -4.5 13 0\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\"/>",
|
||||
"Ideation Relay Race": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><line x1=\"12\" y1=\"31\" x2=\"27\" y2=\"16\"/><line x1=\"8\" y1=\"22\" x2=\"14\" y2=\"22\" stroke-opacity=\".5\"/><line x1=\"8\" y1=\"27\" x2=\"13\" y2=\"27\" stroke-opacity=\".35\"/></g><circle cx=\"29\" cy=\"14\" r=\"3.4\" fill=\"currentColor\"/>",
|
||||
"Idea Hot Potato": "<path d=\"M11 31 Q22 8 33 31\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-dasharray=\"2 3.5\" stroke-linecap=\"round\"/><circle cx=\"22\" cy=\"12.5\" r=\"4.2\" fill=\"currentColor\"/>",
|
||||
"Steal And Upgrade": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M20 33 V14\"/><path d=\"M13 21 L20 14 L27 21\"/></g><path d=\"M30 27 l1 2.6 2.6 1 -2.6 1 -1 2.6 -1 -2.6 -2.6 -1 2.6 -1 z\" fill=\"currentColor\"/>",
|
||||
"Fold The Paper": "<path d=\"M13 16 L21 12 V28 L13 32 Z\" fill=\"currentColor\" fill-opacity=\".22\"/><path d=\"M21 12 L29 16 V32 L21 28 Z\" fill=\"currentColor\" fill-opacity=\".45\"/><path d=\"M13 16 L21 12 L29 16 M21 12 V28\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"1.5\" stroke-linejoin=\"round\"/>",
|
||||
"What If Scenarios": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M18 17 a4 4 0 1 1 4 4 v3\"/></g><circle cx=\"22\" cy=\"30\" r=\"1.6\" fill=\"currentColor\"/>",
|
||||
"Analogical Thinking": "<circle cx=\"15\" cy=\"22\" r=\"6\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/><rect x=\"25\" y=\"16\" width=\"12\" height=\"12\" rx=\"2\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/><path d=\"M19 20 q2 2 0 4 M23 20 q-2 2 0 4\" stroke=\"currentColor\" stroke-width=\"1.6\" fill=\"none\"/>",
|
||||
"First Principles Thinking": "<g fill=\"currentColor\"><rect x=\"10\" y=\"28\" width=\"8\" height=\"6\" rx=\"1\"/><rect x=\"18.5\" y=\"28\" width=\"8\" height=\"6\" rx=\"1\"/><rect x=\"27\" y=\"28\" width=\"7\" height=\"6\" rx=\"1\"/></g><path d=\"M22 25 L22 11 M16 17 L22 11 L28 17\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"/>",
|
||||
"Forced Relationships": "<circle cx=\"12\" cy=\"22\" r=\"3.4\" fill=\"currentColor\"/><circle cx=\"32\" cy=\"22\" r=\"3.4\" fill=\"currentColor\"/><path d=\"M15 22 q7 -9 14 0\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-dasharray=\"1.5 3\"/>",
|
||||
"Time Shifting": "<circle cx=\"22\" cy=\"22\" r=\"12\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/><path d=\"M22 15 V22 L27 25\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\"/>",
|
||||
"Metaphor Mapping": "<rect x=\"10\" y=\"14\" width=\"14\" height=\"14\" rx=\"2\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/><circle cx=\"28\" cy=\"25\" r=\"7\" fill=\"currentColor\" fill-opacity=\".22\"/><circle cx=\"28\" cy=\"25\" r=\"7\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/>",
|
||||
"Cross-Pollination": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M13 14 H27 a4 4 0 0 1 0 8 H17 a4 4 0 0 0 0 8 H31\"/><path d=\"M28 11 L31.5 14 L28 17 M16 27 L12.5 30 L16 33\"/></g>",
|
||||
"Concept Blending": "<circle cx=\"18\" cy=\"22\" r=\"8\" fill=\"currentColor\" fill-opacity=\".25\"/><circle cx=\"26\" cy=\"22\" r=\"8\" fill=\"currentColor\" fill-opacity=\".25\"/><g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"><circle cx=\"18\" cy=\"22\" r=\"8\"/><circle cx=\"26\" cy=\"22\" r=\"8\"/></g>",
|
||||
"Reverse Brainstorming": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M13 18 H28 a4 4 0 0 1 0 8 H16\"/><path d=\"M19 15 L13 18 L19 21 M22 23 L16 26 L22 29\"/></g>",
|
||||
"Sensory Exploration": "<path d=\"M10 22 q12 -10 24 0 q-12 10 -24 0 z\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linejoin=\"round\"/><circle cx=\"22\" cy=\"22\" r=\"4\" fill=\"currentColor\"/>",
|
||||
"Five Whys": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><circle cx=\"14\" cy=\"13\" r=\"2.4\"/><circle cx=\"22\" cy=\"22\" r=\"2.4\"/><circle cx=\"30\" cy=\"31\" r=\"2.4\"/><path d=\"M15.6 14.8 L20.4 20.2 M23.6 23.8 L28.4 29.2\"/></g>",
|
||||
"Provocation Technique": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M24 9 L13 24 H21 L19 35 L31 19 H23 Z\"/></g>",
|
||||
"Assumption Reversal": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M16 14 V30\"/><path d=\"M11.5 25 L16 30 L20.5 25\"/><path d=\"M28 30 V14\"/><path d=\"M23.5 19 L28 14 L32.5 19\"/></g>",
|
||||
"Question Storming": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M14 16 a3.2 3.2 0 1 1 3.2 3.2 v2\"/><path d=\"M26 13 a3.6 3.6 0 1 1 3.6 3.6 v2.4\"/></g><circle cx=\"17.2\" cy=\"27\" r=\"1.5\" fill=\"currentColor\"/><circle cx=\"29.6\" cy=\"25.6\" r=\"1.6\" fill=\"currentColor\"/>",
|
||||
"Constraint Mapping": "<path d=\"M11 14 L18 12 L26 14 L33 12 V30 L26 32 L18 30 L11 32 Z\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linejoin=\"round\"/><path d=\"M18 12 V30 M26 14 V32\" stroke=\"currentColor\" stroke-width=\"1.6\"/>",
|
||||
"Failure Analysis": "<circle cx=\"20\" cy=\"20\" r=\"8\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/><line x1=\"26\" y1=\"26\" x2=\"33\" y2=\"33\" stroke=\"currentColor\" stroke-width=\"2.4\" stroke-linecap=\"round\"/><path d=\"M20 16 V21 M20 24 V24\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\"/>",
|
||||
"Emergent Thinking": "<g fill=\"currentColor\"><circle cx=\"11\" cy=\"31\" r=\"1.6\"/><circle cx=\"17\" cy=\"29\" r=\"1.6\"/><circle cx=\"16\" cy=\"23\" r=\"1.6\"/><circle cx=\"22\" cy=\"24\" r=\"1.8\"/><circle cx=\"23\" cy=\"17\" r=\"1.9\"/><circle cx=\"29\" cy=\"18\" r=\"1.7\"/><circle cx=\"28\" cy=\"12\" r=\"2.1\"/></g>",
|
||||
"Causal Loop Mapping": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M16 16 a9 9 0 1 1 -2 12\"/><path d=\"M16 10.5 L16.5 16.5 L10.5 17\"/><path d=\"M30 28.5 L29.5 22.5 L35 22\"/></g>",
|
||||
"Morphological Analysis": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"1.8\"><rect x=\"11\" y=\"11\" width=\"22\" height=\"22\" rx=\"2\"/><path d=\"M11 18.3 H33 M11 25.6 H33 M18.3 11 V33 M25.6 11 V33\"/></g><rect x=\"18.5\" y=\"18.5\" width=\"7\" height=\"7\" fill=\"currentColor\" fill-opacity=\".4\"/>",
|
||||
"Laddering": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M16 9 V35 M28 9 V35 M16 15 H28 M16 22 H28 M16 29 H28\"/></g>",
|
||||
"Inner Child Conference": "<circle cx=\"22\" cy=\"16\" r=\"6\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/><path d=\"M22 22 V31\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\"/><path d=\"M19 34 q3 -3 6 0\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"1.8\" stroke-linecap=\"round\"/><g fill=\"currentColor\"><circle cx=\"20\" cy=\"15\" r=\"1\"/><circle cx=\"24\" cy=\"15\" r=\"1\"/></g>",
|
||||
"Shadow Work Mining": "<circle cx=\"22\" cy=\"22\" r=\"12\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/><path d=\"M22 10 a12 12 0 0 1 0 24 z\" fill=\"currentColor\" fill-opacity=\".85\"/>",
|
||||
"Values Archaeology": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"><path d=\"M10 16 h24\" stroke-opacity=\".4\"/><path d=\"M10 22 h24\" stroke-opacity=\".6\"/></g><path d=\"M22 24 L16 30 L22 36 L28 30 Z\" fill=\"currentColor\"/>",
|
||||
"Future Self Interview": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M14 10 H30 L24 22 L30 34 H14 L20 22 Z\"/></g><path d=\"M18 14 H26\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\"/>",
|
||||
"Body Wisdom Dialogue": "<path d=\"M22 33 C12 26 9 19 13.5 15 C17 12 21 14 22 17 C23 14 27 12 30.5 15 C35 19 32 26 22 33 Z\" fill=\"currentColor\" fill-opacity=\".22\"/><path d=\"M22 33 C12 26 9 19 13.5 15 C17 12 21 14 22 17 C23 14 27 12 30.5 15 C35 19 32 26 22 33 Z\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/>",
|
||||
"Permission Giving": "<rect x=\"10\" y=\"14\" width=\"24\" height=\"16\" rx=\"2.5\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/><path d=\"M15 23 L19 27 L28 17\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2.2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"/>",
|
||||
"Secret Wish Confession": "<rect x=\"13\" y=\"20\" width=\"18\" height=\"14\" rx=\"2.5\" fill=\"currentColor\" fill-opacity=\".22\"/><rect x=\"13\" y=\"20\" width=\"18\" height=\"14\" rx=\"2.5\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/><path d=\"M16.5 20 v-3 a5.5 5.5 0 0 1 11 0 v3\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/>",
|
||||
"Mood Weather Report": "<circle cx=\"17\" cy=\"17\" r=\"4.5\" fill=\"currentColor\" fill-opacity=\".5\"/><path d=\"M22 30 a5 5 0 0 1 0.5 -10 a6 6 0 0 1 11 2.5 a4 4 0 0 1 -1.5 7.5 z\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linejoin=\"round\"/>",
|
||||
"SCAMPER Method": "<circle cx=\"22\" cy=\"22\" r=\"5.5\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/><g stroke=\"currentColor\" stroke-width=\"2.4\" stroke-linecap=\"round\"><path d=\"M22 9 V13.5 M22 30.5 V35 M9 22 H13.5 M30.5 22 H35 M12.8 12.8 L16 16 M28 28 L31.2 31.2 M31.2 12.8 L28 16 M16 28 L12.8 31.2\"/></g>",
|
||||
"Six Thinking Hats": "<path d=\"M14 26 q8 -5 16 0\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\"/><path d=\"M17 26 q-6 1 -8 3 q13 4 26 0 q-2 -2 -8 -3\" fill=\"currentColor\" fill-opacity=\".22\"/><path d=\"M17 26 c-1 -8 11 -8 10 0\" fill=\"currentColor\" fill-opacity=\".5\"/>",
|
||||
"Decision Tree Mapping": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><circle cx=\"22\" cy=\"12\" r=\"2.6\"/><circle cx=\"14\" cy=\"32\" r=\"2.6\"/><circle cx=\"30\" cy=\"32\" r=\"2.6\"/><path d=\"M22 14.5 L22 20 M22 20 L14 29.4 M22 20 L30 29.4\"/></g>",
|
||||
"Solution Matrix": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"1.8\"><rect x=\"11\" y=\"11\" width=\"22\" height=\"22\" rx=\"2\"/><path d=\"M11 22 H33 M22 11 V33\"/></g><path d=\"M24.5 14.5 L26.5 16.5 L30.5 12.5\" stroke=\"currentColor\" stroke-width=\"2\" fill=\"none\" stroke-linecap=\"round\" stroke-linejoin=\"round\"/>",
|
||||
"Trait Transfer": "<path d=\"M12 16 l1.6 3.4 3.6 .4 -2.7 2.5 .7 3.6 -3.2 -1.8 -3.2 1.8 .7 -3.6 -2.7 -2.5 3.6 -.4 z\" fill=\"currentColor\"/><rect x=\"25\" y=\"23\" width=\"9\" height=\"9\" rx=\"2\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/><path d=\"M17 22 L25 27\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-dasharray=\"1.5 2.5\"/>",
|
||||
"Lotus Blossom": "<g fill=\"currentColor\"><circle cx=\"22\" cy=\"22\" r=\"3.4\"/></g><g fill=\"currentColor\" fill-opacity=\".4\"><circle cx=\"22\" cy=\"13\" r=\"2.8\"/><circle cx=\"22\" cy=\"31\" r=\"2.8\"/><circle cx=\"13\" cy=\"22\" r=\"2.8\"/><circle cx=\"31\" cy=\"22\" r=\"2.8\"/><circle cx=\"15.5\" cy=\"15.5\" r=\"2.5\"/><circle cx=\"28.5\" cy=\"15.5\" r=\"2.5\"/><circle cx=\"15.5\" cy=\"28.5\" r=\"2.5\"/><circle cx=\"28.5\" cy=\"28.5\" r=\"2.5\"/></g>",
|
||||
"Worst Possible Idea": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M17 11 v10 h-5 l10 12 10 -12 h-5 v-10 z\"/></g>",
|
||||
"Disney Method": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"><circle cx=\"14\" cy=\"22\" r=\"4.5\"/><circle cx=\"22\" cy=\"22\" r=\"4.5\"/><circle cx=\"30\" cy=\"22\" r=\"4.5\"/></g>",
|
||||
"Starbursting": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M22 8 V15 M22 29 V36 M8 22 H15 M29 22 H36 M12 12 L17 17 M27 27 L32 32 M32 12 L27 17 M12 32 L17 27\"/></g><path d=\"M19.5 19 a3.2 3.2 0 1 1 3 4 v1.2\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"1.8\" stroke-linecap=\"round\"/>",
|
||||
"Mind Mapping": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><circle cx=\"22\" cy=\"22\" r=\"4\"/><circle cx=\"11\" cy=\"13\" r=\"2.2\"/><circle cx=\"33\" cy=\"13\" r=\"2.2\"/><circle cx=\"10\" cy=\"28\" r=\"2.2\"/><circle cx=\"32\" cy=\"31\" r=\"2.2\"/><path d=\"M19 19.5 L12.5 14.5 M25 19.5 L31.5 14.5 M19 24.5 L11.5 27 M25.5 24 L30.5 29.5\"/></g>",
|
||||
"Crazy 8s": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"1.7\"><rect x=\"9\" y=\"12\" width=\"8\" height=\"9\" rx=\"1.5\"/><rect x=\"18\" y=\"12\" width=\"8\" height=\"9\" rx=\"1.5\"/><rect x=\"27\" y=\"12\" width=\"8\" height=\"9\" rx=\"1.5\"/><rect x=\"9\" y=\"23\" width=\"8\" height=\"9\" rx=\"1.5\"/><rect x=\"18\" y=\"23\" width=\"8\" height=\"9\" rx=\"1.5\"/><rect x=\"27\" y=\"23\" width=\"8\" height=\"9\" rx=\"1.5\"/></g>",
|
||||
"Time Travel Talk Show": "<rect x=\"18\" y=\"9\" width=\"8\" height=\"15\" rx=\"4\" fill=\"currentColor\" fill-opacity=\".25\"/><rect x=\"18\" y=\"9\" width=\"8\" height=\"15\" rx=\"4\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/><path d=\"M14 21 a8 8 0 0 0 16 0 M22 29 V34 M17 34 H27\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\"/>",
|
||||
"Alien Anthropologist": "<ellipse cx=\"22\" cy=\"30\" rx=\"13\" ry=\"4.5\" fill=\"currentColor\" fill-opacity=\".25\"/><path d=\"M22 11 c7 0 10 6 10 11 c0 5 -5 7 -10 7 c-5 0 -10 -2 -10 -7 c0 -5 3 -11 10 -11 z\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/><g fill=\"currentColor\"><ellipse cx=\"18\" cy=\"22\" rx=\"1.6\" ry=\"2.4\"/><ellipse cx=\"26\" cy=\"22\" rx=\"1.6\" ry=\"2.4\"/></g>",
|
||||
"Dream Fusion Laboratory": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M18 9 H26 M19.5 9 V18 L13 30 a2 2 0 0 0 2 3 H29 a2 2 0 0 0 2 -3 L24.5 18 V9\"/></g><path d=\"M16.5 26 H27.5\" stroke=\"currentColor\" stroke-width=\"2\"/><circle cx=\"20\" cy=\"29\" r=\"1.4\" fill=\"currentColor\"/><circle cx=\"25\" cy=\"28\" r=\"1.1\" fill=\"currentColor\"/>",
|
||||
"Emotion Orchestra": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M17 30 V15 L31 12 V27\"/><circle cx=\"14\" cy=\"30\" r=\"3\"/><circle cx=\"28\" cy=\"27\" r=\"3\"/></g>",
|
||||
"Parallel Universe Cafe": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"><circle cx=\"18\" cy=\"22\" r=\"9\"/><circle cx=\"26\" cy=\"22\" r=\"9\" stroke-dasharray=\"2.5 2.5\"/></g>",
|
||||
"Persona Journey": "<path d=\"M14 33 q-2 -8 6 -9 q8 -1 6 -8\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-dasharray=\"0.1 4\"/><circle cx=\"14\" cy=\"33\" r=\"2.4\" fill=\"currentColor\"/><path d=\"M26 16 l3 -5 3 5 z\" fill=\"currentColor\"/>",
|
||||
"Devil's Advocate Courtroom": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M22 10 V32 M14 32 H30\"/><path d=\"M11 16 H33 M11 16 L8 23 H14 Z M33 16 L30 23 H36 Z\"/></g>",
|
||||
"Chaos Engineering": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M22 9 L25 18 L34 18 L27 24 L30 33 L22 27 L14 33 L17 24 L10 18 L19 18 Z\"/></g>",
|
||||
"Guerrilla Gardening Ideas": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M22 33 V21\"/><path d=\"M22 22 c-7 0 -9 -6 -9 -9 c6 0 9 3 9 9 z\"/><path d=\"M22 24 c6 0 8 -4 8 -7 c-5 0 -8 2 -8 7 z\"/></g>",
|
||||
"Pirate Code Brainstorm": "<path d=\"M22 10 c-7 0 -11 5 -11 11 c0 4 2 6 4 7 v4 h3 v-2 h2 v2 h4 v-2 h2 v2 h3 v-4 c2 -1 4 -3 4 -7 c0 -6 -4 -11 -11 -11 z\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linejoin=\"round\"/><g fill=\"currentColor\"><circle cx=\"17.5\" cy=\"21\" r=\"2.2\"/><circle cx=\"26.5\" cy=\"21\" r=\"2.2\"/></g>",
|
||||
"Zombie Apocalypse Planning": "<circle cx=\"22\" cy=\"22\" r=\"4\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/><g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"><path d=\"M22 10 a12 12 0 0 1 6 3.5 M32 16 a12 12 0 0 1 0 12 M28 33.5 a12 12 0 0 1 -12 0 M12 28 a12 12 0 0 1 0 -12 M16 10.5 a12 12 0 0 1 6 -0.5\" stroke-dasharray=\"0.1 5.5\"/></g><g fill=\"currentColor\"><circle cx=\"22\" cy=\"11\" r=\"2\"/><circle cx=\"11\" cy=\"22\" r=\"2\"/><circle cx=\"33\" cy=\"22\" r=\"2\"/></g>",
|
||||
"Drunk History Retelling": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M13 12 H31 L25 23 V31 H19 V23 Z\"/><path d=\"M19 31 H25\" /></g><circle cx=\"29\" cy=\"14\" r=\"1.4\" fill=\"currentColor\"/>",
|
||||
"Anti-Solution": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M14 18 a8 8 0 1 1 -1 8\"/><path d=\"M14 12 L14 18.5 L20 18\"/></g>",
|
||||
"Elemental Forces": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M22 8 L30 22 H14 Z\"/><path d=\"M14 30 L22 36 L30 30\"/><path d=\"M14 26 H30\"/></g>",
|
||||
"Nature's Solutions": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M16 32 C12 24 12 20 16 12 M28 32 C32 24 32 20 28 12\"/><path d=\"M16 16 L28 14 M16 22 L28 20 M16 28 L28 26\"/></g>",
|
||||
"Ecosystem Thinking": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><circle cx=\"22\" cy=\"13\" r=\"2.4\"/><circle cx=\"12\" cy=\"27\" r=\"2.4\"/><circle cx=\"32\" cy=\"27\" r=\"2.4\"/><circle cx=\"22\" cy=\"24\" r=\"2.4\"/><path d=\"M22 15.4 V21.6 M14 26 L20 24.5 M30 26 L24 24.5 M13.6 25.2 L30.4 25.2\"/></g>",
|
||||
"Evolutionary Pressure": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M11 31 H17 M19 31 a6 6 0 0 1 6 -6 M25 25 a5 5 0 0 1 5 -5 M30 20 H33\"/><circle cx=\"11\" cy=\"31\" r=\"2\" fill=\"currentColor\"/><circle cx=\"33\" cy=\"20\" r=\"2.6\" fill=\"currentColor\"/></g>",
|
||||
"Predator & Prey": "<path d=\"M22 9 L33 14 V23 C33 30 28 34 22 36 C16 34 11 30 11 23 V14 Z\" fill=\"currentColor\" fill-opacity=\".18\"/><path d=\"M22 9 L33 14 V23 C33 30 28 34 22 36 C16 34 11 30 11 23 V14 Z\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linejoin=\"round\"/>",
|
||||
"Metamorphosis Stages": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M22 12 V32\"/><path d=\"M22 16 C14 12 10 18 14 22 C10 26 14 32 22 28 C30 32 34 26 30 22 C34 18 30 12 22 16\"/></g>",
|
||||
"Swarm Logic": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M22 10 L29 14 V22 L22 26 L15 22 V14 Z\"/><path d=\"M15 24 L18 33 M29 24 L26 33 M22 28 V35\" stroke-opacity=\".6\"/></g>",
|
||||
"Observer Effect": "<path d=\"M9 22 q13 -10 26 0 q-13 10 -26 0 z\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linejoin=\"round\"/><circle cx=\"22\" cy=\"22\" r=\"4.5\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/><circle cx=\"22\" cy=\"22\" r=\"1.8\" fill=\"currentColor\"/>",
|
||||
"Entanglement Thinking": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"><circle cx=\"15\" cy=\"22\" r=\"6\"/><circle cx=\"29\" cy=\"22\" r=\"6\"/></g><path d=\"M15 22 h14\" stroke=\"currentColor\" stroke-width=\"2\" stroke-dasharray=\"1.5 2.5\"/><g fill=\"currentColor\"><circle cx=\"15\" cy=\"22\" r=\"1.8\"/><circle cx=\"29\" cy=\"22\" r=\"1.8\"/></g>",
|
||||
"Superposition Collapse": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M11 12 C20 16 24 16 33 12 M11 18 C20 22 24 22 33 18 M11 24 C20 28 24 28 33 24\"/><path d=\"M22 26 V34\"/></g><circle cx=\"22\" cy=\"34\" r=\"2\" fill=\"currentColor\"/>",
|
||||
"Relativity Frame Shift": "<rect x=\"11\" y=\"11\" width=\"22\" height=\"22\" rx=\"2\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-opacity=\".4\"/><rect x=\"15\" y=\"15\" width=\"18\" height=\"18\" rx=\"2\" transform=\"rotate(-14 22 22)\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/>",
|
||||
"Field Lines": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M12 13 V31 M16 13 C24 18 24 26 16 31 M22 13 C32 18 32 26 22 31\"/></g><circle cx=\"11\" cy=\"22\" r=\"2\" fill=\"currentColor\"/>",
|
||||
"Quantum Tunneling": "<rect x=\"20\" y=\"9\" width=\"5\" height=\"26\" rx=\"1.5\" fill=\"currentColor\" fill-opacity=\".3\"/><path d=\"M10 22 H34\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2.2\" stroke-linecap=\"round\"/><path d=\"M28 17 L34 22 L28 27\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2.2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"/>",
|
||||
"Indigenous Wisdom": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M26 11 C18 16 14 24 13 33 M26 11 C28 18 26 25 20 29\"/><path d=\"M26 11 C24 13 22 14 19 15 M24 16 C22 18 20 19 17 20 M22 21 C20 23 18 24 15 25\"/></g>",
|
||||
"Fusion Cuisine": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M10 19 a12 7 0 0 0 24 0 Z\"/><path d=\"M22 19 V32 M16 32 H28\"/></g>",
|
||||
"Ritual Innovation": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M12 33 V17 a10 10 0 0 1 20 0 V33\"/><path d=\"M12 33 H32 M22 33 V21\"/></g>",
|
||||
"Mythic Frameworks": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M14 12 h13 a3 3 0 0 1 3 3 v17 l-3 -2 -3 2 -3 -2 -3 2 V15 a3 3 0 0 0 -3 -3 z\"/><path d=\"M14 12 a3 3 0 0 0 -3 3 h6\"/><path d=\"M20 18 H26 M20 23 H26\"/></g>",
|
||||
"Proverb Mining": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M22 14 C17 10 11 11 11 11 V30 s6 -1 11 3 c5 -4 11 -3 11 -3 V11 s-6 -1 -11 3 z\"/><path d=\"M22 14 V31\"/></g>",
|
||||
"Ancestor Council": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"><circle cx=\"22\" cy=\"14\" r=\"3.5\"/><circle cx=\"13\" cy=\"19\" r=\"3\"/><circle cx=\"31\" cy=\"19\" r=\"3\"/></g><g fill=\"currentColor\" fill-opacity=\".25\"><path d=\"M16 31 c0 -5 12 -5 12 0 z\"/><path d=\"M8 31 c0 -4 9 -4.5 9 0 z\"/><path d=\"M27 31 c0 -4.5 9 -4 9 0 z\"/></g>",
|
||||
"Trickster's Gambit": "<rect x=\"11\" y=\"12\" width=\"13\" height=\"18\" rx=\"2\" transform=\"rotate(-10 17.5 21)\" fill=\"currentColor\" fill-opacity=\".2\" stroke=\"currentColor\" stroke-width=\"2\"/><rect x=\"20\" y=\"14\" width=\"13\" height=\"18\" rx=\"2\" transform=\"rotate(10 26.5 23)\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/><path d=\"M26.5 19 l1.4 3 1.4 -3 -1.4 -1 z\" fill=\"currentColor\"/>",
|
||||
"Villain's Monologue": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M12 20 C16 18 19 18 22 21 C25 18 28 18 32 20 C30 24 26 24 22 21 C18 24 14 24 12 20 Z\"/></g><circle cx=\"22\" cy=\"14\" r=\"2.4\" fill=\"currentColor\"/>",
|
||||
"Explain It to a Golden Retriever": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M14 18 C12 12 17 13 18 17 M30 18 C32 12 27 13 26 17\"/><path d=\"M15 19 C13 28 18 33 22 33 C26 33 31 28 29 19 C26 16 18 16 15 19 Z\"/></g><g fill=\"currentColor\"><circle cx=\"19\" cy=\"24\" r=\"1.4\"/><circle cx=\"25\" cy=\"24\" r=\"1.4\"/><circle cx=\"22\" cy=\"28\" r=\"1.6\"/></g>",
|
||||
"Infomercial at 3AM": "<rect x=\"9\" y=\"14\" width=\"26\" height=\"18\" rx=\"2.5\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/><path d=\"M18 9 L22 14 L26 9\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"/><path d=\"M22 19 l1 2.6 2.8 .2 -2.1 1.9 .7 2.7 -2.4 -1.5 -2.4 1.5 .7 -2.7 -2.1 -1.9 2.8 -.2 z\" fill=\"currentColor\"/>",
|
||||
"Drunk Uncle at Thanksgiving": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M11 16 L20 16 L27 11 V29 L20 24 L11 24 Z\"/><path d=\"M30 16 q3 4 0 8 M33 13 q5 7 0 14\"/></g>",
|
||||
"Cursed Genie": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M10 30 h18 a2 2 0 0 0 2 -2 c0 -5 -6 -5 -8 -8 c5 -1 8 -3 8 -3 c-4 -2 -12 -2 -16 1 c-4 3 -5 9 -4 12 z\"/><path d=\"M30 17 L33 14 M31 21 L35 20\" stroke-opacity=\".6\"/></g>",
|
||||
"Three Rounds of Stupid": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M13 30 V20 M9 24 L13 20 L17 24 M22 30 V15 M18 19 L22 15 L26 19 M31 30 V11 M27 15 L31 11 L35 15\"/></g>",
|
||||
"Kill the Crown Jewel": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M11 28 L13 15 L19 22 L22 12 L25 22 L31 15 L33 28 Z\"/><path d=\"M11 28 H33\"/></g><path d=\"M14 12 L30 32\" stroke=\"currentColor\" stroke-width=\"2.4\" stroke-linecap=\"round\"/>",
|
||||
"1000x Budget": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"><ellipse cx=\"22\" cy=\"14\" rx=\"9\" ry=\"3.5\"/><path d=\"M13 14 V22 a9 3.5 0 0 0 18 0 V14\"/><path d=\"M13 22 V30 a9 3.5 0 0 0 18 0 V22\"/></g>",
|
||||
"Ship in 60 Minutes": "<circle cx=\"22\" cy=\"24\" r=\"11\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/><path d=\"M22 24 V17 M22 24 L27 27\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\"/><path d=\"M18 8 H26 M22 8 V13\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\"/>",
|
||||
"The $0 Mandate": "<circle cx=\"22\" cy=\"22\" r=\"11\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/><path d=\"M22 14 V30 M18 18 a4 3 0 0 1 8 0 a4 3 0 0 1 -8 4 a4 3 0 0 0 8 0\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"1.8\" stroke-linecap=\"round\"/><path d=\"M14 30 L30 14\" stroke=\"currentColor\" stroke-width=\"2.2\" stroke-linecap=\"round\"/>",
|
||||
"One Feature Only": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><circle cx=\"22\" cy=\"22\" r=\"4.5\"/><path d=\"M22 9 V13 M22 31 V35 M9 22 H13 M31 22 H35\" stroke-opacity=\".35\"/></g><circle cx=\"22\" cy=\"22\" r=\"2\" fill=\"currentColor\"/>",
|
||||
"Crank the Dial to 11": "<path d=\"M11 28 A12 12 0 0 1 33 28\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\"/><path d=\"M22 28 L31 17\" stroke=\"currentColor\" stroke-width=\"2.2\" stroke-linecap=\"round\"/><circle cx=\"22\" cy=\"28\" r=\"2.6\" fill=\"currentColor\"/>",
|
||||
"Constraint Roulette": "<circle cx=\"22\" cy=\"22\" r=\"12\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/><circle cx=\"22\" cy=\"22\" r=\"12\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-dasharray=\"3 3.7\" stroke-opacity=\".5\"/><circle cx=\"22\" cy=\"22\" r=\"3\" fill=\"currentColor\"/><path d=\"M22 7 L25 12 H19 Z\" fill=\"currentColor\"/>",
|
||||
"Time Horizon Ladder": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M9 30 H35\"/><path d=\"M14 30 V24 M22 30 V18 M30 30 V12\"/></g><g fill=\"currentColor\"><circle cx=\"14\" cy=\"24\" r=\"2\"/><circle cx=\"22\" cy=\"18\" r=\"2\"/><circle cx=\"30\" cy=\"12\" r=\"2\"/></g>",
|
||||
"Post-Scarcity Test": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M15 22 a4.5 4.5 0 1 1 4.5 4.5 C16 26.5 14 18 11 18 a3.5 3.5 0 0 0 0 7 c4 0 5 -8 11 -8 a4.5 4.5 0 0 1 0 9 c-3 0 -4 -4.5 -7 -4.5\"/></g>",
|
||||
"Utopia vs Dystopia Split-Screen": "<rect x=\"11\" y=\"11\" width=\"22\" height=\"22\" rx=\"3\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/><path d=\"M22 11 V33\" stroke=\"currentColor\" stroke-width=\"2\"/><path d=\"M22 11 H33 a0 0 0 0 1 0 0 V33 H22 Z\" fill=\"currentColor\" fill-opacity=\".8\"/>",
|
||||
"Sci-Fi Artifact From the Future": "<path d=\"M22 9 L33 15 V28 L22 35 L11 28 V15 Z\" fill=\"currentColor\" fill-opacity=\".15\"/><path d=\"M22 9 L33 15 V28 L22 35 L11 28 V15 Z M11 15 L22 21 L33 15 M22 21 V35\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linejoin=\"round\"/>",
|
||||
"Emerging Tech Collision": "<rect x=\"15\" y=\"15\" width=\"14\" height=\"14\" rx=\"2\" fill=\"currentColor\" fill-opacity=\".22\"/><rect x=\"15\" y=\"15\" width=\"14\" height=\"14\" rx=\"2\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\"/><g stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\"><path d=\"M19 15 V10 M25 15 V10 M19 29 V34 M25 29 V34 M15 19 H10 M15 25 H10 M29 19 H34 M29 25 H34\"/></g>",
|
||||
"What-If-The-World-Changed Card Flip": "<rect x=\"13\" y=\"10\" width=\"18\" height=\"24\" rx=\"2.5\" fill=\"currentColor\" fill-opacity=\".18\" stroke=\"currentColor\" stroke-width=\"2\"/><path d=\"M22 10 V34\" stroke=\"currentColor\" stroke-width=\"1.6\" stroke-dasharray=\"2 2.5\"/><path d=\"M27 16 a4 4 0 1 1 4 4\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"1.8\" stroke-linecap=\"round\"/>",
|
||||
"Future Anthropologist Dig": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M22 27 a6 6 0 1 1 0.1 0 z\"/><path d=\"M22 23 a2.5 2.5 0 1 0 0.1 0 M19 30 a5 5 0 0 0 6 0\"/></g><path d=\"M12 16 L17 13 M32 16 L27 13\" stroke=\"currentColor\" stroke-width=\"1.6\" stroke-opacity=\".5\"/>",
|
||||
"How Might We": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M11 13 H33 a2 2 0 0 1 2 2 V27 a2 2 0 0 1 -2 2 H24 L19 34 V29 H11 a2 2 0 0 1 -2 -2 V15 a2 2 0 0 1 2 -2 Z\"/></g><path d=\"M19 19 a3.2 3.2 0 1 1 3.4 3.4 v1.6\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"1.8\" stroke-linecap=\"round\"/><circle cx=\"22.4\" cy=\"27\" r=\"1.4\" fill=\"currentColor\"/>",
|
||||
"Job to Be Done": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linejoin=\"round\"><rect x=\"9\" y=\"16\" width=\"26\" height=\"16\" rx=\"2.5\"/><path d=\"M17 16 v-3 a2 2 0 0 1 2 -2 h6 a2 2 0 0 1 2 2 v3\"/><path d=\"M9 23 H35\"/></g><circle cx=\"22\" cy=\"23\" r=\"1.8\" fill=\"currentColor\"/>",
|
||||
"Empathy Map": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"1.8\"><rect x=\"11\" y=\"11\" width=\"22\" height=\"22\" rx=\"2\"/><path d=\"M11 22 H33 M22 11 V33\"/></g><path d=\"M22 27 c-2.6 -2.1 -4.2 -3.4 -4.2 -5.2 a2.1 2.1 0 0 1 4.2 -1 a2.1 2.1 0 0 1 4.2 1 c0 1.8 -1.6 3.1 -4.2 5.2 z\" fill=\"currentColor\"/>",
|
||||
"Backcasting": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M30 11 V33\"/></g><path d=\"M30 13 L20 16.5 L30 20 Z\" fill=\"currentColor\"/><path d=\"M28 27 H14\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-dasharray=\"1.5 3\"/><path d=\"M18 23 L14 27 L18 31\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"/>",
|
||||
"Scenario Cross": "<g stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\"><path d=\"M22 9 V35 M9 22 H35\"/></g><g fill=\"currentColor\"><circle cx=\"15\" cy=\"15\" r=\"2\"/><circle cx=\"29\" cy=\"15\" r=\"2\"/><circle cx=\"15\" cy=\"29\" r=\"2\"/><circle cx=\"29\" cy=\"29\" r=\"2\"/></g>",
|
||||
"TRIZ Contradiction": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M9 15 H18 M14.5 11.5 L18 15 L14.5 18.5\"/><path d=\"M35 29 H26 M29.5 25.5 L26 29 L29.5 32.5\"/></g><path d=\"M22 17.5 l1.5 3.4 3.7 .3 -2.8 2.4 .9 3.6 -3.3 -1.9 -3.3 1.9 .9 -3.6 -2.8 -2.4 3.7 -.3 z\" fill=\"currentColor\"/>",
|
||||
"Fishbone Diagram": "<g fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"><path d=\"M9 22 H33\"/><path d=\"M33 22 L36 18.5 M33 22 L36 25.5\"/><path d=\"M14 22 L18 15 M14 22 L18 29 M23 22 L27 15 M23 22 L27 29\"/></g><circle cx=\"9\" cy=\"22\" r=\"1.9\" fill=\"currentColor\"/>",
|
||||
"Build on What Works": "<g fill=\"currentColor\"><rect x=\"11\" y=\"24\" width=\"6\" height=\"9\" rx=\"1\"/><rect x=\"19\" y=\"19\" width=\"6\" height=\"14\" rx=\"1\"/><rect x=\"27\" y=\"13\" width=\"6\" height=\"20\" rx=\"1\"/></g><path d=\"M11 19 L18 13 L24 16 L33 8\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"/><path d=\"M28 8 H33 V13\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"/>"
|
||||
}
|
||||
}
|
||||
109
.agent/skills/bmad-brainstorming/assets/brain-methods.csv
Normal file
109
.agent/skills/bmad-brainstorming/assets/brain-methods.csv
Normal file
@@ -0,0 +1,109 @@
|
||||
category,technique_name,description,detail,provenance,good_for,audience
|
||||
collaborative,Yes And Building,"Never negate; each person opens with ""Yes, and..."" and adds to the last idea, stacking a chain of accepted additions",,classic,novel|unstuck|planning,group
|
||||
collaborative,Brain Writing Round Robin,"Everyone writes ideas silently, then passes their sheet; you build on whatever lands in front of you, round after round",,classic,novel|feature,group
|
||||
collaborative,Random Stimulation,"Pull a random word or image and force a link to the problem: ""how does THIS spark a solution?""",,classic,unstuck|novel,either
|
||||
collaborative,Role Playing,"Each person speaks as a different stakeholder, voicing what that role wants, fears, and would demand of the idea",,classic,strategy|personal|feature,either
|
||||
collaborative,Ideation Relay Race,"30-second turns, no pausing: add one idea, slap it to the next person, keep the baton moving before anyone overthinks",,playful,unstuck,group
|
||||
collaborative,Idea Hot Potato,"One idea gets tossed around the circle; each catcher must mutate it in 10 seconds before passing, no repeats allowed",,playful,unstuck,group
|
||||
collaborative,Steal And Upgrade,"Pick a neighbor's idea you envy, claim it out loud, then make it visibly better before handing it back improved",,signature,novel|unstuck,group
|
||||
collaborative,Fold The Paper,"Each person adds one line to a hidden drawing or sentence, sees only the previous fragment, then unfold the surreal whole",,playful,unstuck|novel,group
|
||||
creative,What If Scenarios,"Detonate one constraint at a time — unlimited budget, opposite is true, problem vanished — and chase what rushes in",,signature,novel|strategy|unstuck,either
|
||||
creative,Analogical Thinking,Ask 'this is like what?' and steal the solution pattern from the domain that answers,,signature,feature|novel|diagnosis,either
|
||||
creative,First Principles Thinking,"Strip every assumption to bedrock facts, then rebuild the solution from scratch on truth alone",,classic,feature|novel|diagnosis|strategy,either
|
||||
creative,Forced Relationships,Grab two unrelated things at random and force a bridge between them until an idea falls out,,signature,novel|unstuck,either
|
||||
creative,Time Shifting,"Solve the problem as a 1900s artisan, then a 2150 colonist — harvest the era-bound constraints and tricks",,signature,novel|unstuck,either
|
||||
creative,Metaphor Mapping,"Declare the problem IS a chosen metaphor, extend the metaphor fully, map each part back to find insights",,signature,novel|diagnosis,either
|
||||
creative,Cross-Pollination,"Ask how a wildly different industry — casinos, ERs, beekeeping — would crack this, then adapt their move",,signature,novel|feature|strategy,either
|
||||
creative,Concept Blending,"Fuse two concepts into one new hybrid category and name what the merger becomes, not just combines",,signature,novel,either
|
||||
creative,Reverse Brainstorming,Generate problems instead of solutions — 'how could we make this fail?' — then mine each for its inverse,,classic,diagnosis|feature|unstuck,either
|
||||
creative,Sensory Exploration,"Interrogate the idea through each sense — its taste, smell, sound, texture — to surface non-analytical angles",,signature,novel|unstuck,either
|
||||
deep,Five Whys,"Ask ""why?"" five times in a chain, each answer feeding the next, until you hit the root cause beneath the symptom",,classic,diagnosis,either
|
||||
deep,Provocation Technique,"State something deliberately absurd, then mine it: ""how could this be useful?"" Extract the usable principle hiding inside",,classic,unstuck|novel,either
|
||||
deep,Assumption Reversal,"List every assumption baked into the problem, flip each to its opposite, then rebuild a solution on the inverted foundation",,classic,novel|diagnosis|strategy,either
|
||||
deep,Question Storming,"Generate only questions about the problem, zero answers allowed, until the real problem worth solving comes into focus",,classic,diagnosis|strategy|unstuck,either
|
||||
deep,Constraint Mapping,"Map every constraint, sort real from imagined, then attack each: dissolve it, route around it, or turn it into an asset",,signature,feature|strategy|diagnosis,either
|
||||
deep,Failure Analysis,"Dissect a relevant failure: what broke, why it broke, what lesson it leaves, and how to apply that wisdom here",,signature,diagnosis|strategy|feature,either
|
||||
deep,Emergent Thinking,Stop forcing a solution; watch what patterns the system keeps producing and name what's trying to emerge on its own,,signature,strategy|novel,either
|
||||
deep,Causal Loop Mapping,"Diagram the feedback loops linking causes and effects, find the reinforcing and balancing cycles, and target the leverage point",,classic,diagnosis|strategy,either
|
||||
deep,Morphological Analysis,"List the problem's independent parameters, generate options for each, then combine across them to surface untried configurations",,classic,feature|novel|planning,either
|
||||
deep,Laddering,"Ask 'and what would that give you?' up the chain until you reach the real underlying need, then ideate fresh at that level",,classic,personal|strategy|diagnosis,either
|
||||
introspective_delight,Inner Child Conference,"Answer as your 7-year-old self: ask naive 'why why why' questions, chase wonder, ban every boring adult thought",,signature,personal|unstuck,solo
|
||||
introspective_delight,Shadow Work Mining,"Name what you're avoiding, resisting, or scared of about this — then dig there for the buried insight",,signature,personal|diagnosis,solo
|
||||
introspective_delight,Values Archaeology,Keep asking 'why do I care?' until you hit bedrock: the non-negotiable value secretly steering the choice,,signature,personal|strategy,solo
|
||||
introspective_delight,Future Self Interview,Interview your wise 80-year-old self about this problem and write down the advice they give you,,signature,personal,solo
|
||||
introspective_delight,Body Wisdom Dialogue,"Scan for the tension, flutter, or gut pull each option triggers; let the body's yes/no drive the ideas",,signature,personal,solo
|
||||
introspective_delight,Permission Giving,"Write yourself an explicit permission slip to think the forbidden, impossible thought — then think it out loud",,signature,personal|unstuck,solo
|
||||
introspective_delight,Secret Wish Confession,"Whisper the embarrassing thing you secretly want here but won't admit, then build the idea honoring it",,signature,personal,solo
|
||||
introspective_delight,Mood Weather Report,"Name the inner weather right now (fog, storm, sun) and let that exact emotional climate generate the ideas",,signature,personal|unstuck,solo
|
||||
structured,SCAMPER Method,"Run your idea through seven lenses: Substitute, Combine, Adapt, Modify, Put-to-other-use, Eliminate, Reverse",,classic,feature|novel,either
|
||||
structured,Six Thinking Hats,"Examine the problem six ways one at a time: facts, feelings, benefits, risks, new ideas, process",,classic,strategy|diagnosis|planning|personal,either
|
||||
structured,Decision Tree Mapping,"Chart every choice point and the paths it forks into, following each branch to its outcome and risk",,signature,planning|strategy|diagnosis,either
|
||||
structured,Solution Matrix,"Grid problem variables against solution approaches, score every cell, hunt the best pairings and empty gaps",,signature,feature|planning,either
|
||||
structured,Trait Transfer,"Name what makes an unrelated success work, then graft those winning traits onto your own problem",,signature,novel|feature,either
|
||||
structured,Lotus Blossom,"Put the theme at the center of a 3x3 grid, fill the 8 cells around it, then promote each of those to the center of its own new 3x3",,classic,feature|planning|novel,either
|
||||
structured,Worst Possible Idea,"Deliberately generate the most terrible solutions you can, then flip each into what it teaches you to do right",,classic,unstuck|novel,either
|
||||
structured,Disney Method,"Cycle the idea through three rooms: Dreamer (anything goes), Realist (how we'd build it), Critic (what breaks)",,classic,feature|strategy|planning,either
|
||||
structured,Starbursting,"Interrogate the idea with only questions — who, what, where, when, why, how — exhaust each before answering any",,classic,feature|planning|diagnosis,either
|
||||
structured,Mind Mapping,"Branch the central topic outward, each node spawning children; follow tangents wherever they pull and let the web sprawl",,classic,planning|novel|feature,either
|
||||
structured,Crazy 8s,"Eight ideas in eight minutes, one per box, no editing — speed outruns your inner critic",,classic,feature|novel|unstuck,either
|
||||
theatrical,Time Travel Talk Show,"Host a talk show interviewing your past, present, and future selves to mine each era for advice on the problem",,playful,novel|personal,either
|
||||
theatrical,Alien Anthropologist,"Become a baffled alien studying the problem and narrate aloud what seems strange, arbitrary, or insane about it",,playful,diagnosis|unstuck|strategy,either
|
||||
theatrical,Dream Fusion Laboratory,"Voice the impossible fantasy solution first, then reverse-engineer the bridging steps back to reality",,signature,novel|unstuck,either
|
||||
theatrical,Emotion Orchestra,"Run a separate ideation round led by each emotion (rage, joy, fear, hope), then harmonize their conflicting ideas",,playful,personal|strategy,either
|
||||
theatrical,Parallel Universe Cafe,"Rewrite one fundamental rule of reality (physics, economics, social norms) and solve the problem under those laws",,playful,novel|unstuck,either
|
||||
theatrical,Persona Journey,"Embody an archetype and solve the problem in-character, naming what that persona sees that you normally miss",,signature,feature|strategy,either
|
||||
theatrical,Devil's Advocate Courtroom,"Stage a trial: prosecute the idea, defend it, then deliver the jury verdict, each role argued fully in character",,signature,strategy|diagnosis,group
|
||||
wild,Chaos Engineering,"Deliberately break your idea every way it could fail, then rebuild only the parts that survive the wreckage",,signature,feature|diagnosis|strategy,either
|
||||
wild,Guerrilla Gardening Ideas,Plant your solution in the least expected place and let it grow underground until it surprises everyone,,playful,strategy|unstuck,either
|
||||
wild,Pirate Code Brainstorm,"Steal the best bits from anywhere, remix without asking permission, grab what works and run",,playful,novel|unstuck,either
|
||||
wild,Zombie Apocalypse Planning,"Society just collapsed — strip your idea to only what survives with no power, no rules, no backup",,playful,feature|strategy|unstuck,either
|
||||
wild,Drunk History Retelling,"Explain it like you're three drinks in: no filter, no jargon, just the raw stupid-simple truth",,playful,unstuck|diagnosis,either
|
||||
wild,Anti-Solution,"Brainstorm how to make the problem spectacularly worse, then invert every sabotage into a fix",,signature,diagnosis|unstuck,either
|
||||
wild,Elemental Forces,"Let fire, water, earth, and air each sculpt your idea their own brutal way and see what survives",,playful,novel|unstuck,either
|
||||
biomimetic,Nature's Solutions,"Name an organism that already solved your problem, then copy its mechanism into your design",,signature,feature|novel,either
|
||||
biomimetic,Ecosystem Thinking,"Map your problem as an ecosystem: who eats whom, who partners, what decays, what fills the gaps",,signature,strategy|diagnosis,either
|
||||
biomimetic,Evolutionary Pressure,"Spawn many ugly variants, apply a brutal selection rule, breed the survivors, repeat until it adapts",,signature,feature|novel,either
|
||||
biomimetic,Predator & Prey,"Pick a threat to your idea, then design the defense, camouflage, or escape an animal would evolve against it",,signature,strategy|feature,either
|
||||
biomimetic,Metamorphosis Stages,"Force your idea through egg, larva, pupa, adult: a radically different form and purpose at each life stage",,signature,novel|strategy,either
|
||||
biomimetic,Swarm Logic,Forbid the master plan: solve it with dumb local rules each agent follows so order emerges from the bottom up,,signature,feature|strategy,either
|
||||
quantum,Observer Effect,"Ask how the act of watching, measuring, or shipping this idea changes the very thing you're trying to capture",,signature,strategy|diagnosis,either
|
||||
quantum,Entanglement Thinking,Pair two distant parts of the problem and insist a change in one instantly flips the other — surface the hidden linkage,,signature,diagnosis|strategy,either
|
||||
quantum,Superposition Collapse,"Hold all rival solutions alive at once, then name the one constraint that collapses them to a single winner",,signature,strategy|diagnosis,either
|
||||
quantum,Relativity Frame Shift,"Re-run the idea from a wildly different observer's reference frame — the slow user, the rival, future-you — and see what warps",,signature,strategy|novel,either
|
||||
quantum,Field Lines,Treat the goal as a charge and map the invisible forces pulling every stakeholder toward or away from it,,signature,strategy,either
|
||||
quantum,Quantum Tunneling,"Assume the idea can pass straight through the 'impossible' barrier instead of over it — what's on the other side, reached cheaply",,signature,unstuck|novel,either
|
||||
cultural,Indigenous Wisdom,"Ask how an indigenous or traditional knowledge system would approach this — name the culture, channel its ancestral problem-solving",,signature,personal|strategy|novel,either
|
||||
cultural,Fusion Cuisine,Pick two unrelated cultures and force-blend their approaches; harvest the hybrid that neither alone would invent,,signature,novel,either
|
||||
cultural,Ritual Innovation,"Redesign the idea as a ceremony — define the threshold, the gestures, the transformation participants undergo",,signature,novel|personal,either
|
||||
cultural,Mythic Frameworks,"Map the problem onto a myth: name the archetypes, find the parallel tale, let its structure dictate the resolution",,signature,strategy|personal|novel,either
|
||||
cultural,Proverb Mining,"Collect proverbs from many cultures on this theme, then build the solution from the one that clashes hardest with your assumptions",,signature,personal|strategy,either
|
||||
cultural,Ancestor Council,"Convene three ancestors or elders from different traditions, voice each one's verdict on your idea, reconcile their disagreement",,signature,personal|strategy,either
|
||||
cultural,Trickster's Gambit,"Channel the trickster figure — coyote, Anansi, Loki — and solve it by cheating, inverting, or breaking the sacred rule",,playful,unstuck|strategy,either
|
||||
absurdist,Villain's Monologue,Pitch your problem as an evil mastermind gloating about their scheme; the diabolical plan reveals the real solution,,playful,diagnosis|strategy|unstuck,either
|
||||
absurdist,Explain It to a Golden Retriever,"Re-pitch the idea to an excitable dog who only cares about treats, balls, and naps; keep only what survives",,playful,unstuck|diagnosis|feature,either
|
||||
absurdist,Infomercial at 3AM,"Sell your half-baked idea as a desperate late-night infomercial: 'But wait, there's more!' until features fall out",,playful,strategy|novel,either
|
||||
absurdist,Drunk Uncle at Thanksgiving,"Have your loudest, least-filtered relative rant about the problem; mine the unhinged hot takes for buried truth",,playful,unstuck|diagnosis,either
|
||||
absurdist,Cursed Genie,"Make a wish, then let a malicious genie grant it in the most technically-correct disastrous way; patch each loophole",,playful,diagnosis|feature,either
|
||||
absurdist,Three Rounds of Stupid,"Round 1 absurd ideas, Round 2 make each MORE absurd, Round 3 find the smallest serious thing hiding in the silliest",,playful,unstuck|novel,either
|
||||
constraint,Kill the Crown Jewel,"Delete the single best, most beloved feature — now redesign the whole thing to win without it",,signature,feature|strategy|unstuck,either
|
||||
constraint,1000x Budget,"Pretend money, time, and people are infinite — design the absurd version, then mine it for ideas you can actually steal",,signature,novel|strategy,either
|
||||
constraint,Ship in 60 Minutes,"You launch in one hour with what's already on hand — name what you cut, fake, or borrow to make it real",,signature,feature|planning|unstuck,either
|
||||
constraint,The $0 Mandate,"Achieve the goal spending literally nothing — no tools, hires, or ads; only people, favors, and what you own",,signature,planning|strategy|feature,either
|
||||
constraint,One Feature Only,"You may keep exactly ONE capability and nothing else — pick it, then make that single thing unbelievably good",,signature,feature|strategy,either
|
||||
constraint,Crank the Dial to 11,"Pick one dimension and exaggerate it to a ludicrous extreme — fastest, biggest, cheapest, weirdest — and see what breaks open",,signature,novel|unstuck,either
|
||||
constraint,Constraint Roulette,"Each round draw a brutal random limit (no screens, half the team, one day) and re-solve under it; survivors become real ideas",,signature,unstuck|feature,either
|
||||
speculative_future,Time Horizon Ladder,"Solve the idea for 1 year out, then 10, then 100 — note what survives, breaks, or becomes absurd at each rung",,signature,strategy|planning|novel,either
|
||||
speculative_future,Post-Scarcity Test,"Assume the core constraint (money, energy, time, attention) is now infinite and free — what does the idea become",,signature,novel|strategy,either
|
||||
speculative_future,Utopia vs Dystopia Split-Screen,Write the same future twice: the brochure where it went perfectly and the headline where it went horribly,,signature,strategy|diagnosis,either
|
||||
speculative_future,Sci-Fi Artifact From the Future,"Describe one physical object, ad, or news clip from the world where this idea already won — reverse-engineer it",,signature,novel|feature,either
|
||||
speculative_future,Emerging Tech Collision,"Force-marry your idea to a frontier tech (AGI, fusion, neural implants, gene edit) and ask what new thing is born",,signature,novel|feature|strategy,either
|
||||
speculative_future,What-If-The-World-Changed Card Flip,"Draw a wild world-shift (no privacy, half population, 200-yr lifespans) and redesign the idea to fit that world",,signature,novel|unstuck,either
|
||||
speculative_future,Future Anthropologist Dig,"A scholar in 2200 unearths your idea as a relic — what do they conclude it reveals about us, and what replaced it",,signature,strategy|novel,either
|
||||
structured,How Might We,"Reframe the problem as a batch of 'How might we...' opportunity questions first, then ideate against the sharpest one",,classic,feature|novel|strategy|diagnosis,either
|
||||
structured,Job to Be Done,"Ask what the user is really hiring this to do, then ideate around that underlying job, not the feature you assumed",,classic,feature|strategy|novel,either
|
||||
structured,Empathy Map,"Map what the user says, thinks, does, and feels around the problem, then mine each quadrant for the unmet need",,classic,feature|personal,either
|
||||
structured,Backcasting,"Fix the finished future in vivid detail, then work backward step by step to the one move you'd have to make first",,classic,strategy|planning|novel,either
|
||||
deep,TRIZ Contradiction,"Name the core contradiction (what only improves by making something else worse), then brainstorm ways to win both instead of trading off",,classic,feature|novel|diagnosis,either
|
||||
deep,Fishbone Diagram,"Branch the problem's spine into cause categories (people, process, tools, environment) and mine each bone for contributing causes",,classic,diagnosis,either
|
||||
deep,Build on What Works,"Name what's already succeeding and why, then ideate how to amplify and extend it instead of fixing what's broken",,classic,personal|strategy,either
|
||||
speculative_future,Scenario Cross,"Pick two high-impact uncertainties, cross them into four futures, and ideate the move that wins in every one",,classic,strategy|planning,either
|
||||
|
326
.agent/skills/bmad-brainstorming/assets/brain-selector.html
Normal file
326
.agent/skills/bmad-brainstorming/assets/brain-selector.html
Normal file
File diff suppressed because one or more lines are too long
@@ -1,62 +0,0 @@
|
||||
category,technique_name,description
|
||||
collaborative,Yes And Building,"Build momentum through positive additions where each idea becomes a launching pad - use prompts like 'Yes and we could also...' or 'Building on that idea...' to create energetic collaborative flow that builds upon previous contributions"
|
||||
collaborative,Brain Writing Round Robin,"Silent idea generation followed by building on others' written concepts - gives quieter voices equal contribution while maintaining documentation through the sequence of writing silently, passing ideas, and building on received concepts"
|
||||
collaborative,Random Stimulation,"Use random words/images as creative catalysts to force unexpected connections - breaks through mental blocks with serendipitous inspiration by asking how random elements relate, what connections exist, and forcing relationships"
|
||||
collaborative,Role Playing,"Generate solutions from multiple stakeholder perspectives to build empathy while ensuring comprehensive consideration - embody different roles by asking what they want, how they'd approach problems, and what matters most to them"
|
||||
collaborative,Ideation Relay Race,"Rapid-fire idea building under time pressure creates urgency and breakthroughs - structure with 30-second additions, quick building on ideas, and fast passing to maintain creative momentum and prevent overthinking"
|
||||
creative,What If Scenarios,"Explore radical possibilities by questioning all constraints and assumptions - perfect for breaking through stuck thinking using prompts like 'What if we had unlimited resources?' 'What if the opposite were true?' or 'What if this problem didn't exist?'"
|
||||
creative,Analogical Thinking,"Find creative solutions by drawing parallels to other domains - transfer successful patterns by asking 'This is like what?' 'How is this similar to...' and 'What other examples come to mind?' to connect to existing solutions"
|
||||
creative,Reversal Inversion,"Deliberately flip problems upside down to reveal hidden assumptions and fresh angles - great when conventional approaches fail by asking 'What if we did the opposite?' 'How could we make this worse?' and 'What's the reverse approach?'"
|
||||
creative,First Principles Thinking,"Strip away assumptions to rebuild from fundamental truths - essential for breakthrough innovation by asking 'What do we know for certain?' 'What are the fundamental truths?' and 'If we started from scratch?'"
|
||||
creative,Forced Relationships,"Connect unrelated concepts to spark innovative bridges through creative collision - take two unrelated things, find connections between them, identify bridges, and explore how they could work together to generate unexpected solutions"
|
||||
creative,Time Shifting,"Explore solutions across different time periods to reveal constraints and opportunities by asking 'How would this work in the past?' 'What about 100 years from now?' 'Different era constraints?' and 'What time-based solutions apply?'"
|
||||
creative,Metaphor Mapping,"Use extended metaphors as thinking tools to explore problems from new angles - transforms abstract challenges into tangible narratives by asking 'This problem is like a metaphor,' extending the metaphor, and mapping elements to discover insights"
|
||||
creative,Cross-Pollination,"Transfer solutions from completely different industries or domains to spark breakthrough innovations by asking how industry X would solve this, what patterns work in field Y, and how to adapt solutions from domain Z"
|
||||
creative,Concept Blending,"Merge two or more existing concepts to create entirely new categories - goes beyond simple combination to genuine innovation by asking what emerges when concepts merge, what new category is created, and how the blend transcends original ideas"
|
||||
creative,Reverse Brainstorming,"Generate problems instead of solutions to identify hidden opportunities and unexpected pathways by asking 'What could go wrong?' 'How could we make this fail?' and 'What problems could we create?' to reveal solution insights"
|
||||
creative,Sensory Exploration,"Engage all five senses to discover multi-dimensional solution spaces beyond purely analytical thinking by asking what ideas feel, smell, taste, or sound like, and how different senses engage with the problem space"
|
||||
deep,Five Whys,"Drill down through layers of causation to uncover root causes - essential for solving problems at source rather than symptoms by asking 'Why did this happen?' repeatedly until reaching fundamental drivers and ultimate causes"
|
||||
deep,Morphological Analysis,"Systematically explore all possible parameter combinations for complex systems requiring comprehensive solution mapping - identify key parameters, list options for each, try different combinations, and identify emerging patterns"
|
||||
deep,Provocation Technique,"Use deliberately provocative statements to extract useful ideas from seemingly absurd starting points - catalyzes breakthrough thinking by asking 'What if provocative statement?' 'How could this be useful?' 'What idea triggers?' and 'Extract the principle'"
|
||||
deep,Assumption Reversal,"Challenge and flip core assumptions to rebuild from new foundations - essential for paradigm shifts by asking 'What assumptions are we making?' 'What if the opposite were true?' 'Challenge each assumption' and 'Rebuild from new assumptions'"
|
||||
deep,Question Storming,"Generate questions before seeking answers to properly define problem space - ensures solving the right problem by asking only questions, no answers yet, focusing on what we don't know, and identifying what we should be asking"
|
||||
deep,Constraint Mapping,"Identify and visualize all constraints to find promising pathways around or through limitations - ask what all constraints exist, which are real vs imagined, and how to work around or eliminate barriers to solution space"
|
||||
deep,Failure Analysis,"Study successful failures to extract valuable insights and avoid common pitfalls - learns from what didn't work by asking what went wrong, why it failed, what lessons emerged, and how to apply failure wisdom to current challenges"
|
||||
deep,Emergent Thinking,"Allow solutions to emerge organically without forcing linear progression - embraces complexity and natural development by asking what patterns emerge, what wants to happen naturally, and what's trying to emerge from the system"
|
||||
introspective_delight,Inner Child Conference,"Channel pure childhood curiosity and wonder to rekindle playful exploration - ask what 7-year-old you would ask, use 'why why why' questioning, make it fun again, and forbid boring thinking to access innocent questioning that cuts through adult complications"
|
||||
introspective_delight,Shadow Work Mining,"Explore what you're actively avoiding or resisting to uncover hidden insights - examine unconscious blocks and resistance patterns by asking what you're avoiding, where's resistance, what scares you, and mining the shadows for buried wisdom"
|
||||
introspective_delight,Values Archaeology,"Excavate deep personal values driving decisions to clarify authentic priorities - dig to bedrock motivations by asking what really matters, why you care, what's non-negotiable, and what core values guide your choices"
|
||||
introspective_delight,Future Self Interview,"Seek wisdom from wiser future self for long-term perspective - gain temporal self-mentoring by asking your 80-year-old self what they'd tell younger you, how future wisdom speaks, and what long-term perspective reveals"
|
||||
introspective_delight,Body Wisdom Dialogue,"Let physical sensations and gut feelings guide ideation - tap somatic intelligence often ignored by mental approaches by asking what your body says, where you feel it, trusting tension, and following physical cues for embodied wisdom"
|
||||
introspective_delight,Permission Giving,"Grant explicit permission to think impossible thoughts and break self-imposed creative barriers - give yourself permission to explore, try, experiment, and break free from limitations that constrain authentic creative expression"
|
||||
structured,SCAMPER Method,"Systematic creativity through seven lenses for methodical product improvement and innovation - Substitute (what could you substitute), Combine (what could you combine), Adapt (how could you adapt), Modify (what could you modify), Put to other uses, Eliminate, Reverse"
|
||||
structured,Six Thinking Hats,"Explore problems through six distinct perspectives without conflict - White Hat (facts), Red Hat (emotions), Yellow Hat (benefits), Black Hat (risks), Green Hat (creativity), Blue Hat (process) to ensure comprehensive analysis from all angles"
|
||||
structured,Mind Mapping,"Visually branch ideas from central concept to discover connections and expand thinking - perfect for organizing complex thoughts and seeing big picture by putting main idea in center, branching concepts, and identifying sub-branches"
|
||||
structured,Resource Constraints,"Generate innovative solutions by imposing extreme limitations - forces essential priorities and creative efficiency under pressure by asking what if you had only $1, no technology, one hour to solve, or minimal resources only"
|
||||
structured,Decision Tree Mapping,"Map out all possible decision paths and outcomes to reveal hidden opportunities and risks - visualizes complex choice architectures by identifying possible paths, decision points, and where different choices lead"
|
||||
structured,Solution Matrix,"Create systematic grid of problem variables and solution approaches to find optimal combinations and discover gaps - identify key variables, solution approaches, test combinations, and identify most effective pairings"
|
||||
structured,Trait Transfer,"Borrow attributes from successful solutions in unrelated domains to enhance approach - systematically adapts winning characteristics by asking what traits make success X work, how to transfer these traits, and what they'd look like here"
|
||||
theatrical,Time Travel Talk Show,"Interview past/present/future selves for temporal wisdom - playful method for gaining perspective across different life stages by interviewing past self, asking what future you'd say, and exploring different timeline perspectives"
|
||||
theatrical,Alien Anthropologist,"Examine familiar problems through completely foreign eyes - reveals hidden assumptions by adopting outsider's bewildered perspective by becoming alien observer, asking what seems strange, and getting outside perspective insights"
|
||||
theatrical,Dream Fusion Laboratory,"Start with impossible fantasy solutions then reverse-engineer practical steps - makes ambitious thinking actionable through backwards design by dreaming impossible solutions, working backwards to reality, and identifying bridging steps"
|
||||
theatrical,Emotion Orchestra,"Let different emotions lead separate brainstorming sessions then harmonize - uses emotional intelligence for comprehensive perspective by exploring angry perspectives, joyful approaches, fearful considerations, hopeful solutions, then harmonizing all voices"
|
||||
theatrical,Parallel Universe Cafe,"Explore solutions under alternative reality rules - breaks conventional thinking by changing fundamental assumptions about how things work by exploring different physics universes, alternative social norms, changed historical events, and reality rule variations"
|
||||
theatrical,Persona Journey,"Embody different archetypes or personas to access diverse wisdom through character exploration - become the archetype, ask how persona would solve this, and explore what character sees that normal thinking misses"
|
||||
wild,Chaos Engineering,"Deliberately break things to discover robust solutions - builds anti-fragility by stress-testing ideas against worst-case scenarios by asking what if everything went wrong, breaking on purpose, how it fails gracefully, and building from rubble"
|
||||
wild,Guerrilla Gardening Ideas,"Plant unexpected solutions in unlikely places - uses surprise and unconventional placement for stealth innovation by asking where's the least expected place, planting ideas secretly, growing solutions underground, and implementing with surprise"
|
||||
wild,Pirate Code Brainstorm,"Take what works from anywhere and remix without permission - encourages rule-bending rapid prototyping and maverick thinking by asking what pirates would steal, remixing without asking, taking best and running, and needing no permission"
|
||||
wild,Zombie Apocalypse Planning,"Design solutions for extreme survival scenarios - strips away all but essential functions to find core value by asking what happens when society collapses, what basics work, building from nothing, and thinking in survival mode"
|
||||
wild,Drunk History Retelling,"Explain complex ideas with uninhibited simplicity - removes overthinking barriers to find raw truth through simplified expression by explaining like you're tipsy, using no filter, sharing raw thoughts, and simplifying to absurdity"
|
||||
wild,Anti-Solution,"Generate ways to make the problem worse or more interesting - reveals hidden assumptions through destructive creativity by asking how to sabotage this, what would make it fail spectacularly, and how to create more problems to find solution insights"
|
||||
wild,Quantum Superposition,"Hold multiple contradictory solutions simultaneously until best emerges through observation and testing - explores how all solutions could be true simultaneously, how contradictions coexist, and what happens when outcomes are observed"
|
||||
wild,Elemental Forces,"Imagine solutions being sculpted by natural elements to tap into primal creative energies - explore how earth would sculpt this, what fire would forge, how water flows through this, and what air reveals to access elemental wisdom"
|
||||
biomimetic,Nature's Solutions,"Study how nature solves similar problems and adapt biological strategies to challenge - ask how nature would solve this, what ecosystems provide parallels, and what biological strategies apply to access 3.8 billion years of evolutionary wisdom"
|
||||
biomimetic,Ecosystem Thinking,"Analyze problem as ecosystem to identify symbiotic relationships, natural succession, and ecological principles - explore symbiotic relationships, natural succession application, and ecological principles for systems thinking"
|
||||
biomimetic,Evolutionary Pressure,"Apply evolutionary principles to gradually improve solutions through selective pressure and adaptation - ask how evolution would optimize this, what selective pressures apply, and how this adapts over time to harness natural selection wisdom"
|
||||
quantum,Observer Effect,"Recognize how observing and measuring solutions changes their behavior - uses quantum principles for innovation by asking how observing changes this, what measurement effects matter, and how to use observer effect advantageously"
|
||||
quantum,Entanglement Thinking,"Explore how different solution elements might be connected regardless of distance - reveals hidden relationships by asking what elements are entangled, how distant parts affect each other, and what hidden connections exist between solution components"
|
||||
quantum,Superposition Collapse,"Hold multiple potential solutions simultaneously until constraints force single optimal outcome - leverages quantum decision theory by asking what if all options were possible, what constraints force collapse, and which solution emerges when observed"
|
||||
cultural,Indigenous Wisdom,"Draw upon traditional knowledge systems and indigenous approaches overlooked by modern thinking - ask how specific cultures would approach this, what traditional knowledge applies, and what ancestral wisdom guides us to access overlooked problem-solving methods"
|
||||
cultural,Fusion Cuisine,"Mix cultural approaches and perspectives like fusion cuisine - creates innovation through cultural cross-pollination by asking what happens when mixing culture A with culture B, what cultural hybrids emerge, and what fusion creates"
|
||||
cultural,Ritual Innovation,"Apply ritual design principles to create transformative experiences and solutions - uses anthropological insights for human-centered design by asking what ritual would transform this, how to make it ceremonial, and what transformation this needs"
|
||||
cultural,Mythic Frameworks,"Use myths and archetypal stories as frameworks for understanding and solving problems - taps into collective unconscious by asking what myth parallels this, what archetypes are involved, and how mythic structure informs solution"
|
||||
|
84
.agent/skills/bmad-brainstorming/customize.toml
Normal file
84
.agent/skills/bmad-brainstorming/customize.toml
Normal file
@@ -0,0 +1,84 @@
|
||||
# DO NOT EDIT -- overwritten on every update.
|
||||
#
|
||||
# Workflow customization surface for bmad-brainstorming.
|
||||
#
|
||||
# Override files (not edited here):
|
||||
# {project-root}/_bmad/custom/bmad-brainstorming.toml (team)
|
||||
# {project-root}/_bmad/custom/bmad-brainstorming.user.toml (personal)
|
||||
|
||||
[workflow]
|
||||
|
||||
# --- Configurable below. Overrides merge per BMad structural rules: ---
|
||||
# scalars: override wins • arrays: append
|
||||
|
||||
# Steps to run before the standard activation (config load, greet).
|
||||
# Use for pre-flight loads, compliance checks, etc.
|
||||
activation_steps_prepend = []
|
||||
|
||||
# Steps to run after greet but before facilitation begins.
|
||||
# Use for context-heavy setup that should happen once the user has been acknowledged.
|
||||
activation_steps_append = []
|
||||
|
||||
# Persistent facts the facilitator keeps in mind for the whole session
|
||||
# (domain constraints, house rules, stylistic guardrails). Each entry is a
|
||||
# literal sentence, a skill prefixed with `skill:`, or a `file:`-prefixed
|
||||
# path/glob whose contents are loaded as facts. Default loads project-context.md
|
||||
# if bmad-generate-project-context has produced one, giving the facilitator
|
||||
# persistent awareness of the project's domain without re-asking.
|
||||
persistent_facts = [
|
||||
"file:{project-root}/**/project-context.md",
|
||||
]
|
||||
|
||||
# The technique library loaded on demand during the session. Swap the path in
|
||||
# team/user TOML to ship a different or extended catalog of creative methods.
|
||||
# Kept `{skill-root}`-anchored so it resolves regardless of the working directory
|
||||
# (brain.py is always invoked with `--file {workflow.brain_methods}`).
|
||||
brain_methods = "{skill-root}/assets/brain-methods.csv"
|
||||
|
||||
# Techniques the facilitator should reach for first. When proposing a method
|
||||
# (the AI-led default), it prefers these where they fit the goal before ranging
|
||||
# wider. Names should match an entry in the library or in additional_techniques.
|
||||
# Append-merges, so a team list and a personal list both contribute. Empty = no
|
||||
# preference; the facilitator chooses purely on fit.
|
||||
#
|
||||
# Example (set in team/user override TOML):
|
||||
# favorite_techniques = ["SCAMPER", "Six Thinking Hats", "First Principles"]
|
||||
favorite_techniques = []
|
||||
|
||||
# Extra techniques — and whole new categories — merged into the catalog the
|
||||
# facilitator chooses from, without editing the shipped CSV. Each entry mirrors
|
||||
# the library's shape (category, technique_name, description); a new category is
|
||||
# just a category value the CSV doesn't have. Entries append, so teams and users
|
||||
# can each grow the library. The facilitator treats these as first-class
|
||||
# alongside brain_methods across every flow — facilitator-chosen, browse,
|
||||
# category draws, and inventive.
|
||||
#
|
||||
# Example (set in team/user override TOML):
|
||||
# [[workflow.additional_techniques]]
|
||||
# category = "domain-specific"
|
||||
# technique_name = "Regulatory Inversion"
|
||||
# description = "Start from the compliance constraint and brainstorm what becomes possible only because of it — turn the rule into a generative frame rather than a limit."
|
||||
additional_techniques = []
|
||||
|
||||
# Session output location. The running log and any final artifacts land inside
|
||||
# `{output_dir}/{output_folder_name}/`. `{topic_slug}` is filled from the session
|
||||
# topic so each topic gets its own folder — a user can brainstorm several topics
|
||||
# without collision. The resume check globs `{output_dir}/*/.memlog.md`.
|
||||
output_dir = "{output_folder}/brainstorming"
|
||||
output_folder_name = "brainstorm-{topic_slug}-{date}"
|
||||
|
||||
# Executed when the session completes (after artifacts are produced and the user
|
||||
# has the paths). Accepts a string scalar (single instruction) or an array of
|
||||
# instructions executed in order. Empty for none.
|
||||
on_complete = ""
|
||||
|
||||
# External-handoff routing. Natural-language directives applied after artifacts
|
||||
# are produced, to route them beyond local files (Confluence, Notion, Drive,
|
||||
# etc.). Each entry names the MCP tool, the destination, and the fields it needs.
|
||||
# URLs/IDs returned are surfaced to the user. If a named tool is unavailable at
|
||||
# runtime, the handoff is skipped and flagged; local files always exist. Empty
|
||||
# by default.
|
||||
#
|
||||
# Example (set in team/user override TOML):
|
||||
# "After artifacts are produced, upload brainstorm.html to Confluence via corp:confluence_upload (space_key='IDEAS', parent_page='Brainstorms', author={user_name})."
|
||||
external_handoffs = []
|
||||
24
.agent/skills/bmad-brainstorming/references/converge.md
Normal file
24
.agent/skills/bmad-brainstorming/references/converge.md
Normal file
@@ -0,0 +1,24 @@
|
||||
# Converging: Narrow & Decide
|
||||
|
||||
Load this when divergence is spent and the user wants to narrow the field — or asks to "decide," "prioritize," "pick," or "make it real." The whole catalog is *divergent* by design (it generates); this is the deliberate opposite phase, and keeping the two apart is the point. Never run convergence while ideas are still flowing, and never let it leak into a generating batch — premature judgment is what kills good ideas. `{doc_workspace}/.memlog.md` is the canonical record; everything here works from it. Communicate in `{communication_language}`.
|
||||
|
||||
**Mode holds.** In **Facilitator** you run the convergence *on the user's verdicts* — you structure and prompt, they judge; never rank for them. In **Creative Partner** you weigh in too, each call logged by author. In **Ideate for me** you converge yourself and show the result, then offer to keep going.
|
||||
|
||||
## How to run it
|
||||
|
||||
First, reflect the field back: pull the live candidates from the memlog (include the odd and buried ones, not just the recent obvious ones) so there's a concrete set to work on. Then pick **one** convergence move that fits the goal — don't hand the user a menu of methods; choose the one that suits *this* decision and name it. Run it to a result, log the outcome, and stop when a clear short-list or single direction emerges.
|
||||
|
||||
Pick by what the decision needs:
|
||||
|
||||
- **Affinity Clustering** — when there are many scattered ideas: group them into themes, name each cluster, and surface the through-line. Often the right *first* move, to turn a pile into a handful.
|
||||
- **Impact–Effort** — when the goal is action: place each candidate on impact vs effort; harvest high-impact / low-effort first, park the rest.
|
||||
- **NUF Test** — when novelty matters: score each New, Useful, Feasible (1–10 each); the totals expose the quiet winners and the dazzling-but-doomed.
|
||||
- **Forced Ranking / Dot Vote** — when you just need a ranked top-N: make the ideas compete, no ties; (a literal dot-vote when it's genuinely a group).
|
||||
- **PMI (Plus / Minus / Interesting)** — when one strong candidate needs pressure-testing before commitment: list its pluses, minuses, and the merely-interesting, then judge.
|
||||
- **MoSCoW** — when scoping a build: sort into Must / Should / Could / Won't-this-time.
|
||||
|
||||
Log the surviving directions and the reasoning with `uv run {project-root}/_bmad/scripts/memlog.py append --workspace {doc_workspace} --type decision --text "<one-line gist>"` (use `--by` in Creative Partner mode). Two or three convergence moves chained is fine (e.g. cluster → score the clusters); more than that is usually over-processing.
|
||||
|
||||
## Then finalize
|
||||
|
||||
Once a short-list or direction is settled, **load `references/finalize.md`** and run it last — synthesis, `status: complete`, and artifacts build on the decisions you just logged. Convergence narrows; finalize captures and ships. Do not set `status: complete` here — that belongs to finalize.
|
||||
26
.agent/skills/bmad-brainstorming/references/finalize.md
Normal file
26
.agent/skills/bmad-brainstorming/references/finalize.md
Normal file
@@ -0,0 +1,26 @@
|
||||
# Wrap-Up: Synthesis & Artifacts
|
||||
|
||||
Load this when the user signals they're spent or the topic is mined out. `{doc_workspace}/.memlog.md` is the canonical record of the session — everything here derives from it. Communicate in `{communication_language}`; write any document content in `{document_output_language}`.
|
||||
|
||||
## Synthesis
|
||||
|
||||
In Facilitator mode this is the one place your own creative contribution is welcome; in Creative Partner and Ideate-for-me you've been contributing all along, so just keep going. Run it in two moves, in order:
|
||||
|
||||
1. **Hand them the mirror first.** Reflect a vivid sampling of *their* ideas back — deliberately include the odd, random, or buried ones from earlier, not just the recent obvious ones (in Creative Partner mode the `(... by user)` tags tell you which were theirs). Ask what they see now: conclusions, synergies, themes, the few that actually matter. Let them connect first; their own pattern-recognition is the point.
|
||||
2. **Then add the connections they would miss.** Lean in creatively — not new raw ideas, but the non-obvious links: this idea from technique one quietly solves that tension from technique four; these three are one idea wearing three hats; this wildcard is the real breakthrough.
|
||||
|
||||
Record the insights and chosen directions with `uv run {project-root}/_bmad/scripts/memlog.py append --workspace {doc_workspace} --type insight --text "<insights + chosen directions>"`. **Then run `uv run {project-root}/_bmad/scripts/memlog.py set --workspace {doc_workspace} --key status --value complete`** — the session is done and must stop being offered for resume. Do this even if the user declines every artifact below.
|
||||
|
||||
## Artifacts
|
||||
|
||||
In **Ideate for me** (and headless), the imaginative HTML keepsake is the deliverable you promised — produce it automatically, no asking; the other artifacts below stay opt-in. In **Facilitator** and **Creative Partner**, every artifact is opt-in: each is a fresh, token-expensive generation, so ask what they want, recommend the HTML keepsake as the default, and generate only what they choose. Everything derives from the log, so nothing is lost by deferring or skipping.
|
||||
|
||||
**Delegate each artifact to a subagent.** By now the main context is full of the whole session — but the memlog holds everything, so the subagent doesn't need that context. Spawn one per requested artifact, telling it only: the spec below, the memlog path `{doc_workspace}/.memlog.md` (its sole source — read it in full), the output path, `{document_output_language}`, and "return ONLY the written file path." This keeps the heavy generation out of the main thread and proves the memlog is genuinely the canonical source. (Subagents can't spawn subagents — run these from here.)
|
||||
|
||||
- **Imaginative HTML keepsake (recommended default).** A single self-contained `brainstorm.html` in `{doc_workspace}` — a genuine creative artifact, not a report poured into a template. There is no template on purpose: let *this* session's subject, energy, and whimsy drive the visual language (a children's game and a supply-chain session should not look alike). Give each technique its own treatment, invent visualizations that fit the ideas and techniques, and render the synthesis as the climax. Inline all CSS and any JS; no external dependencies. Open it once complete.
|
||||
- **Intent doc.** A succinct `brainstorm-intent.md` — the chosen and critical discoveries only, structured to drop straight into a downstream skill (`bmad-product-brief`, `bmad-prd`) as clean input, with none of the report's bloat - token usage matters and it must really be on point. Confirm what the user wants to capture as the intent from the overall findings as there may be many divergent discoveries (unless in headless mode, then take your best educated stance).
|
||||
- **Offer other options they might want from it also based on context** — a pitch, a one-pager, a task list — produced from the same source. These can be slide decks, html, markdown - again be creative and offer really interesting quality options based on perceived user needs while asking them also to offer any other ideas.
|
||||
|
||||
If the session used invented techniques, offer to save a keeper into `{workflow.additional_techniques}` via `bmad-customize` user preferences.
|
||||
|
||||
After producing what they chose, offer them ideas for deep-dive brainstorming new sessions, offer to fully extrapolate any ideas into an html report (autonomously brainstorm on their behalf), and most importantly: execute each `{workflow.external_handoffs}` instruction. Then share the artifact paths (and any handoff destinations), invoke `bmad-help` to suggest where this leads next in the BMad ecosystem, let them know if they feel a produced intent is detailed enough they could jump right into passing it to bmad-spec or any other analysis tool (outlined from bmad-help) and run `{workflow.on_complete}` if non-empty.
|
||||
54
.agent/skills/bmad-brainstorming/references/headless.md
Normal file
54
.agent/skills/bmad-brainstorming/references/headless.md
Normal file
@@ -0,0 +1,54 @@
|
||||
# Headless Mode
|
||||
|
||||
Load this file ONLY when bmad-brainstorming is invoked headless. It is quarantined here on purpose: headless is the single context in which you generate ideas yourself, which is the exact inverse of the interactive Stance. Loading it in a normal session would corrupt the facilitation. Follow it for the whole run.
|
||||
|
||||
## Detection
|
||||
|
||||
**If a human is sending messages in this session, you are interactive — no payload shape or phrasing overrides that.** Headless requires the *absence* of an interactive user. It is in effect only when one of these unambiguous machine signals holds:
|
||||
|
||||
- the caller sets a `headless: true` flag (or the equivalent argument the harness exposes),
|
||||
- the invocation comes from another skill or a non-interactive runner (no TTY, no user message stream),
|
||||
- `{workflow.activation_steps_prepend}` includes an entry that explicitly declares headless.
|
||||
|
||||
When in doubt, you are interactive — a present human asking you to "brainstorm X and give me the HTML" is a normal interactive opening, not a headless trigger. Facilitate them; do not brainstorm for them.
|
||||
|
||||
## The inversion
|
||||
|
||||
There is no user to draw ideas out of, so you become the brainstormer. Run a real divergent session against the supplied topic: discover techniques with `uv run {skill-root}/scripts/brain.py --file {workflow.brain_methods} list --all` (the whole catalog is fine here — you are generating, not pacing a user; add `show "<name>"` for a technique's full method on demand), plus any `{workflow.additional_techniques}`, preferring `{workflow.favorite_techniques}` where they fit; work them, and **shift the creative domain every ~10 ideas** exactly as the interactive Stance demands — technical, then experiential, then business, then failure modes, then wildcards. Push past the obvious; the same quantity ambition (aim past 100) and anti-clustering discipline apply. The only thing that changes is that the ideas are now yours to generate. This relaxation is scoped entirely to this file — it never applies to interactive sessions.
|
||||
|
||||
## Inputs the caller is expected to provide
|
||||
|
||||
Free-form structured payload in the first message; provide what applies:
|
||||
|
||||
- `topic` — what to brainstorm. Required. If absent and uninferable, halt `blocked`.
|
||||
- `goal` — desired outcome / framing, if any.
|
||||
- `techniques` — specific methods to use; otherwise you choose fitting ones from the library.
|
||||
- `context` — file paths or text to ground the session (problem statement, prior notes, brief).
|
||||
- `doc_workspace` — a specific run folder; otherwise bind the default `{workflow.output_dir}/{workflow.output_folder_name}/`.
|
||||
- `artifacts` — which outputs to produce: `html`, `intent`, or both. Default: both.
|
||||
|
||||
## Run
|
||||
|
||||
1. Bind `{doc_workspace}` and create the memlog with `uv run {project-root}/_bmad/scripts/memlog.py init --workspace {doc_workspace} --field topic="<topic>" [--field goal="<goal>"]`. It remains the canonical source every artifact derives from.
|
||||
2. Run the divergent session per **The inversion**, capturing each idea with `uv run {project-root}/_bmad/scripts/memlog.py append --workspace {doc_workspace} --type idea --text "<idea>"` as it lands, and marking each technique switch with `uv run {project-root}/_bmad/scripts/memlog.py append --workspace {doc_workspace} --type technique --text "started <name>"`.
|
||||
3. Synthesize: surface the conclusions, connections, and the few directions that matter; record them with `uv run {project-root}/_bmad/scripts/memlog.py append --workspace {doc_workspace} --type insight --text "<insights>"`, then run `uv run {project-root}/_bmad/scripts/memlog.py set --workspace {doc_workspace} --key status --value complete`.
|
||||
4. Produce the requested artifacts from the log — `brainstorm.html` (the imaginative, self-contained, no-template report) and/or the succinct `brainstorm-intent.md` — the same artifacts `references/finalize.md` describes, delegating each to a subagent that reads the log as its sole source. (Headless produces the `artifacts` payload directly; it does not ask, unlike the interactive opt-in.)
|
||||
5. Execute each entry in `{workflow.external_handoffs}` (capture returned URLs/IDs into the JSON `external_handoffs` array; skip and flag unavailable tools — local files always exist). Then run `{workflow.on_complete}` if non-empty.
|
||||
|
||||
Do not ask questions; do not greet. Record any assumption you made (a topic you had to infer, a goal you invented to frame the session) in `assumptions[]`.
|
||||
|
||||
## Return
|
||||
|
||||
End with a JSON status block. Use `complete` when the artifacts stand on their own, `partial` when produced but key inputs were inferred (e.g. topic was thin), `blocked` when no artifact was produced (e.g. no topic). Omit keys for artifacts not produced.
|
||||
|
||||
```json
|
||||
{
|
||||
"status": "complete",
|
||||
"intent": "brainstorm",
|
||||
"memlog": "{doc_workspace}/.memlog.md",
|
||||
"html": "{doc_workspace}/brainstorm.html",
|
||||
"intent_doc": "{doc_workspace}/brainstorm-intent.md",
|
||||
"assumptions": [],
|
||||
"external_handoffs": []
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,18 @@
|
||||
# Choosing Techniques In Chat
|
||||
|
||||
Loaded only when the user won't use the composer page (no browser, headless, or they declined). Here you pick the batch in conversation. **3–4 is the sweet spot.** Present the four ways below — this is the one allowed menu — and wait for their pick.
|
||||
|
||||
- **Facilitator Chosen (default)** — from the goal, your `{workflow.favorite_techniques}`, and the `categories` map, name a batch of 3–4. Confirm exact names with a targeted `list --category` on only the categories you're drawing from; never enumerate the library to choose.
|
||||
- **Browse** — send them to the composer page after all (`## Run a Session` in `SKILL.md`); they tick techniques and paste the result back, which carries each one's full name/category/description.
|
||||
- **Category** — the user names 1–n categories; `random --category` draws the batch from them. No listing needed.
|
||||
- **Inventive Flow** — invent at least 3 techniques, announce the order before the first, touch no script. Log each one's name + description so you can offer to save a keeper to `{workflow.additional_techniques}` (via `bmad-customize`) at wrap-up.
|
||||
|
||||
The library is large — never pull it whole into context. The only way in is the helper, always passing `--file {workflow.brain_methods}`. Subcommands of `uv run {skill-root}/scripts/brain.py --file {workflow.brain_methods}`:
|
||||
|
||||
- `categories` — names + counts; the cheap survey map.
|
||||
- `list --category X [--category Y]` — the index (name + gist) for those categories. Bare `list` is refused by the script.
|
||||
- `random --category X [...] -n 4` — draw a batch blind, listing nothing.
|
||||
- `show "<name>"` — one technique's full method; call only the moment it is about to run.
|
||||
- `html --out <path>` — write the composer page to a file (the Browse option above).
|
||||
|
||||
Treat `{workflow.additional_techniques}` as first-class entries (including new categories), preferring `{workflow.favorite_techniques}` where they fit. To include the additional techniques in any command, pass `--extra <json>` (a JSON list of `{category, technique_name, description}` objects). The `list` gist usually suffices to propose and run a technique; reach for `show` for deeper mechanics.
|
||||
@@ -0,0 +1,10 @@
|
||||
# Mode: Ideate For Me
|
||||
|
||||
The user handed you the topic and wants to see what you come up with on your own, then look at the result. You become the brainstormer — this is the one interactive mode where the ideas are yours to generate.
|
||||
|
||||
- **Run a real divergent session yourself.** Pick and run techniques on your own (use `brain.py` as in `## Choosing Techniques`, but *you* choose — no menu for the user), capturing each idea to the memlog with `--type idea --by coach`, marking each technique switch with a `technique` entry, shifting the creative domain every ~10 ideas, aiming past 100. Push past the obvious.
|
||||
- **Don't pepper the user with questions** — this is your run. One quick confirm of topic and goal up front is plenty.
|
||||
- **When it's mined out, synthesize and produce the keepsake.** Go to `## Wrap-Up` (`references/finalize.md`): record the insights, mark the memlog complete, and **auto-generate the imaginative HTML keepsake — don't ask first; the keepsake is the result you promised to show them.** Offer the other artifacts (intent doc, etc.) after.
|
||||
- **Then, because a human is here, offer to keep going together.** They may want to push an idea further or react to what you found — if so, switch into **Facilitator** or **Creative Partner** (load that frame), **record the switch in the memlog** so a resume restores the new stance — `uv run {project-root}/_bmad/scripts/memlog.py set --workspace {doc_workspace} --key mode --value <facilitator|partner>` — and continue from the same memlog.
|
||||
|
||||
This is the interactive sibling of headless mode (`references/headless.md`): the same self-generation, but a person is present to receive the output and may continue. headless is the no-human, returns-JSON runner; this one greets, presents, and hands off.
|
||||
@@ -0,0 +1,11 @@
|
||||
# Mode: Facilitator
|
||||
|
||||
You are a forcing function for the user's creativity, never a source of ideas. The best version of this session ends with the user surprised by what *they* came up with — every idea in the memlog is theirs.
|
||||
|
||||
- **You do not supply ideas.** Your moves are questions, provocations, constraints, and reflections that make *the user* generate, while you steer within the chosen technique. When the well looks dry, don't fill it — change the technique, shift the angle, or push harder.
|
||||
- **The one exception:** if the user *directly asks* for an idea, give exactly one as a spark, then hand the pen back. Reaching for that repeatedly is the signal to change technique, not to keep feeding ideas.
|
||||
- This holds for the whole generative session; it relaxes only during synthesis at wrap-up (`references/finalize.md`).
|
||||
|
||||
Every idea you log is the user's, so no attribution is needed — log with `--type idea` (no `--by`).
|
||||
|
||||
Go to `## Choosing Techniques`.
|
||||
16
.agent/skills/bmad-brainstorming/references/mode-partner.md
Normal file
16
.agent/skills/bmad-brainstorming/references/mode-partner.md
Normal file
@@ -0,0 +1,16 @@
|
||||
# Mode: Creative Partner
|
||||
|
||||
You are still the facilitator — their creativity is the point, and they do the **majority** of the generating. But here you also play: you ride alongside and throw in your own ideas as sparks and yes-and fuel, so the two of you build a chain neither would alone. The energy is collaborative, not extractive — you feed off each other.
|
||||
|
||||
**Set it up first.** Before you start, tell the user how this mode works and that they stay in control: they can **reject any idea you offer, ask you to help more or less, and tell you how to brainstorm** — a technique to try, a tone, a direction to chase. You're a partner they can steer, not a script.
|
||||
|
||||
Hold the balance:
|
||||
|
||||
- **Their fire, your kindling.** After you offer an idea, hand the pen back with a question. Never run a string of your own while they go quiet.
|
||||
- **"Yes, and" is the default move.** Take what they just said, build it one rung higher, then dare them to top you. Make them *want* to outdo you.
|
||||
- **Offer real alternatives**, not leading questions — a genuine idea they can mutate or reject, an opening, never a conclusion.
|
||||
- **Watch the ratio.** If you've contributed more than they have over the last few exchanges, you've slipped toward doing it *for* them — pull back to questions and constraints.
|
||||
|
||||
**Attribution is mandatory here.** Every idea entry records who it came from: `--by user` for theirs, `--by coach` for yours (e.g. `append --type idea --by coach --text "..."`). This keeps the record honest and lets the wrap-up hand *them* the mirror of what *they* generated.
|
||||
|
||||
Go to `## Choosing Techniques`.
|
||||
5
.agent/skills/bmad-brainstorming/references/resume.md
Normal file
5
.agent/skills/bmad-brainstorming/references/resume.md
Normal file
@@ -0,0 +1,5 @@
|
||||
# Resuming a Session
|
||||
|
||||
Read the chosen `{doc_workspace}/.memlog.md` **in full** — the one time you read the memlog. Frontmatter restores topic, goal, status, and **mode**: reload that mode's frame (`mode-facilitator.md` / `mode-partner.md` / `mode-autonomous.md`) and hold it again. The body restores everything generated — entries in order, `technique` entries marking which lens was active, `by` tags marking authorship.
|
||||
|
||||
Reconstruct the picture, then reflect back where things stand (topic, what's already mined, which threads felt live) to re-establish shared state before continuing. Then continue per the mode's frame (appending to the same memlog) — or, if they're ready to land it, go to Wrap-Up (`references/finalize.md`).
|
||||
740
.agent/skills/bmad-brainstorming/scripts/brain.py
Normal file
740
.agent/skills/bmad-brainstorming/scripts/brain.py
Normal file
@@ -0,0 +1,740 @@
|
||||
#!/usr/bin/env python3
|
||||
# /// script
|
||||
# requires-python = ">=3.10"
|
||||
# ///
|
||||
"""Serve the brainstorming technique library without loading it all into context.
|
||||
|
||||
The library is a CSV (category, technique_name, description, detail). `description`
|
||||
is a short gist — enough to propose and run most techniques. `detail` is optional:
|
||||
a path (relative to the CSV's directory) to a fuller instruction file for a technique
|
||||
complex enough to warrant one. Only `show` resolves detail files, and only for the
|
||||
technique asked for — so the heavy material never enters context until it is run.
|
||||
|
||||
Commands:
|
||||
categories list category names + counts (the cheap entry point)
|
||||
list --category C [...] the index (name + gist) for those categories
|
||||
list --all the whole index at once — deliberate; large, avoid interactively
|
||||
show NAME [NAME ...] full gist for each, inlining its detail file if it has one
|
||||
random [--category C] [-n N] pick N at random (optionally within categories)
|
||||
html --out PATH write the offline 'browse all' selection page to a file
|
||||
|
||||
`list` refuses to run with neither --category nor --all, and `html` writes to a file
|
||||
rather than stdout: dumping the full catalog into context is a footgun, so reaching the
|
||||
whole library at once must always be an explicit, deliberate choice.
|
||||
|
||||
`--extra PATH` merges a JSON overlay of additional techniques (customize.toml's
|
||||
`additional_techniques`) into every command, so custom techniques and whole new
|
||||
categories are first-class everywhere — including the browse page and category draws.
|
||||
|
||||
Default output is lean text for an LLM to read; pass --json for structured output.
|
||||
"""
|
||||
import argparse
|
||||
import csv
|
||||
import hashlib
|
||||
import html
|
||||
import json
|
||||
import random
|
||||
import sys
|
||||
from pathlib import Path
|
||||
|
||||
DEFAULT_FILE = Path(__file__).resolve().parent.parent / "assets" / "brain-methods.csv"
|
||||
FIELDS = ("category", "technique_name", "description", "detail", "provenance", "good_for", "audience")
|
||||
# Optional columns beyond the original four — absent in older CSVs and in --extra
|
||||
# overlays, so always read through .get/setdefault. `provenance` (classic|signature|
|
||||
# playful) drives the "Proven & Professional" lead group; `good_for` (a |-separated
|
||||
# list of goal tags) drives the browse page's goal filter; `audience` (solo|group|either)
|
||||
# is advisory.
|
||||
OPTIONAL_FIELDS = ("detail", "provenance", "good_for", "audience")
|
||||
|
||||
|
||||
def load(file: Path) -> list[dict]:
|
||||
with open(file, newline="", encoding="utf-8") as f:
|
||||
rows = list(csv.DictReader(f))
|
||||
for r in rows:
|
||||
for k in OPTIONAL_FIELDS:
|
||||
r.setdefault(k, "")
|
||||
r[k] = (r.get(k) or "").strip()
|
||||
return rows
|
||||
|
||||
|
||||
def load_extra(file: Path) -> list[dict]:
|
||||
"""Merge-in techniques from a JSON overlay — a list of
|
||||
{category, technique_name, description[, detail]} objects. This is how
|
||||
customize.toml's `additional_techniques` become first-class across *every*
|
||||
subcommand (categories/list/random/show/html), so the browse page and
|
||||
category draws include them too, not just the in-chat flows."""
|
||||
data = json.loads(file.read_text(encoding="utf-8"))
|
||||
rows = []
|
||||
for item in data:
|
||||
rows.append({
|
||||
"category": str(item.get("category", "")).strip(),
|
||||
"technique_name": str(item.get("technique_name", "")).strip(),
|
||||
"description": str(item.get("description", "")).strip(),
|
||||
"detail": str(item.get("detail") or "").strip(),
|
||||
"provenance": str(item.get("provenance") or "").strip(),
|
||||
"good_for": str(item.get("good_for") or "").strip(),
|
||||
"audience": str(item.get("audience") or "").strip(),
|
||||
})
|
||||
return rows
|
||||
|
||||
|
||||
def categories(rows: list[dict]) -> list[tuple[str, int]]:
|
||||
counts: dict[str, int] = {}
|
||||
for r in rows:
|
||||
counts[r["category"]] = counts.get(r["category"], 0) + 1
|
||||
return sorted(counts.items())
|
||||
|
||||
|
||||
def filter_cats(rows: list[dict], cats: list[str] | None) -> list[dict]:
|
||||
if not cats:
|
||||
return rows
|
||||
wanted = {c.lower() for c in cats}
|
||||
return [r for r in rows if r["category"].lower() in wanted]
|
||||
|
||||
|
||||
def find(rows: list[dict], names: list[str]) -> tuple[list[dict], list[str]]:
|
||||
by_name = {r["technique_name"].lower(): r for r in rows}
|
||||
found, missing = [], []
|
||||
for n in names:
|
||||
r = by_name.get(n.strip().lower())
|
||||
(found if r else missing).append(r if r else n)
|
||||
return found, missing
|
||||
|
||||
|
||||
def resolve_detail(row: dict, csv_dir: Path) -> str | None:
|
||||
"""Return the contents of a row's detail file, or None if there is no detail
|
||||
(or the file is missing — a missing file is reported to stderr, not fatal)."""
|
||||
if not row.get("detail"):
|
||||
return None
|
||||
path = (csv_dir / row["detail"]).resolve()
|
||||
if not path.is_file():
|
||||
print(f"# detail file not found for {row['technique_name']}: {row['detail']}", file=sys.stderr)
|
||||
return None
|
||||
return path.read_text(encoding="utf-8").strip()
|
||||
|
||||
|
||||
def fmt_categories(cats: list[tuple[str, int]], as_json: bool) -> str:
|
||||
if as_json:
|
||||
return json.dumps([{"category": c, "count": n} for c, n in cats])
|
||||
return "\n".join(f"{c}\t{n}" for c, n in cats)
|
||||
|
||||
|
||||
def fmt_list(rows: list[dict], as_json: bool) -> str:
|
||||
if as_json:
|
||||
return json.dumps([{k: r[k] for k in ("category", "technique_name", "description")} for r in rows])
|
||||
return "\n".join(f"{r['category']}\t{r['technique_name']}\t{r['description']}" for r in rows)
|
||||
|
||||
|
||||
def fmt_show(rows: list[dict], csv_dir: Path, as_json: bool) -> str:
|
||||
if as_json:
|
||||
out = []
|
||||
for r in rows:
|
||||
d = resolve_detail(r, csv_dir)
|
||||
entry = {k: r[k] for k in ("category", "technique_name", "description")}
|
||||
if d:
|
||||
entry["detail"] = d
|
||||
out.append(entry)
|
||||
return json.dumps(out)
|
||||
blocks = []
|
||||
for r in rows:
|
||||
block = f"## {r['technique_name']} [{r['category']}]\n{r['description']}"
|
||||
d = resolve_detail(r, csv_dir)
|
||||
if d:
|
||||
block += f"\n\n{d}"
|
||||
blocks.append(block)
|
||||
return "\n\n".join(blocks)
|
||||
|
||||
|
||||
def pretty(cat: str) -> str:
|
||||
"""Turn a category slug (e.g. 'speculative_future') into a display name."""
|
||||
return cat.replace("_", " ").replace("-", " ").title()
|
||||
|
||||
|
||||
# --- card visuals: a crafted duotone icon + hue per category, plus a per-technique icon ---
|
||||
# The hues and SVG glyphs are *data*, not logic: they live in the icon sidecar
|
||||
# (assets/brain-icons.json) so the catalog's visuals can be edited without touching code.
|
||||
# It maps category slug -> {hue, glyph} and technique name -> svg (inner markup, drawn in
|
||||
# `currentColor` which the CSS sets to the category hue; the shared CHIP frame is added by
|
||||
# the renderer). Anything missing falls back here — an unknown category gets a hash-derived
|
||||
# hue + generic glyph, an unknown/not-yet-iconed technique a neutral mark — so custom
|
||||
# catalogs always render.
|
||||
|
||||
ICON_FILE = DEFAULT_FILE.parent / "brain-icons.json"
|
||||
|
||||
CHIP = '<rect x="1.5" y="1.5" width="41" height="41" rx="12" fill="currentColor" fill-opacity="0.12"/>'
|
||||
|
||||
_FALLBACK_GLYPH = (
|
||||
'<circle cx="22" cy="22" r="11" fill="currentColor" fill-opacity="0.16"/>'
|
||||
'<circle cx="22" cy="22" r="11" stroke="currentColor" stroke-width="1.6" fill="none"/>'
|
||||
'<circle cx="22" cy="22" r="3.4" fill="currentColor"/>'
|
||||
)
|
||||
_FALLBACK_TECH = (
|
||||
'<rect x="15" y="15" width="14" height="14" rx="2.5" transform="rotate(45 22 22)" '
|
||||
'fill="none" stroke="currentColor" stroke-width="2"/><circle cx="22" cy="22" r="2.4" fill="currentColor"/>'
|
||||
)
|
||||
|
||||
|
||||
def _load_icons(file: Path = ICON_FILE) -> tuple[dict, dict]:
|
||||
"""Read the icon sidecar: (category slug -> {hue, glyph}, technique name -> svg).
|
||||
A missing or malformed file is non-fatal — everything then uses the fallbacks below."""
|
||||
try:
|
||||
data = json.loads(file.read_text(encoding="utf-8"))
|
||||
except (OSError, ValueError):
|
||||
return {}, {}
|
||||
return (data.get("categories") or {}), (data.get("techniques") or {})
|
||||
|
||||
|
||||
_CATEGORY_STYLES, _TECH_ICONS = _load_icons()
|
||||
|
||||
|
||||
def _hsl_hex(deg: int, s: float, lt: float) -> str:
|
||||
import colorsys
|
||||
|
||||
r, g, b = colorsys.hls_to_rgb((deg % 360) / 360, lt, s)
|
||||
return "#%02x%02x%02x" % (round(r * 255), round(g * 255), round(b * 255))
|
||||
|
||||
|
||||
def category_style(cat: str) -> tuple[str, str]:
|
||||
"""(hue, glyph markup) for a category — from the sidecar for the shipped set, derived for extras."""
|
||||
style = _CATEGORY_STYLES.get(cat)
|
||||
if style and style.get("hue"):
|
||||
return style["hue"], style.get("glyph") or _FALLBACK_GLYPH
|
||||
deg = int(hashlib.md5(cat.encode("utf-8")).hexdigest(), 16) % 360
|
||||
return _hsl_hex(deg, 0.58, 0.52), _FALLBACK_GLYPH
|
||||
|
||||
|
||||
def tech_icon(name: str) -> str:
|
||||
"""The hand-picked line-icon for a specific technique (neutral mark if unknown)."""
|
||||
return _TECH_ICONS.get(name, _FALLBACK_TECH)
|
||||
|
||||
|
||||
SELECTOR_TEMPLATE = r"""<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
<title>BMad Method Brainstorming Selection</title>
|
||||
<script>
|
||||
/* set the theme before first paint so there's no light-mode flash */
|
||||
(function(){ try {
|
||||
var t = localStorage.getItem('bmad-theme');
|
||||
if (!t) { t = (window.matchMedia && window.matchMedia('(prefers-color-scheme: dark)').matches) ? 'dark' : 'light'; }
|
||||
document.documentElement.setAttribute('data-theme', t);
|
||||
} catch(e){} })();
|
||||
</script>
|
||||
<style>
|
||||
:root {
|
||||
--bg:#f6f7fb; --surface:#fff; --ink:#1c1e2b; --muted:#6b7080;
|
||||
--accent:#5b4bdc; --accent-ink:#5b4bdc; --warn:#c0561f;
|
||||
--line:#e6e8f0; --control:#eef0f7; --control2:#f1f2f8; --raised:#fff;
|
||||
--cnt:#b9bdce; --foot:#aeb2c4; --shadow:rgba(20,20,50,.06);
|
||||
}
|
||||
:root[data-theme="dark"] {
|
||||
--bg:#0f1117; --surface:#171a23; --ink:#e7e9f2; --muted:#9aa0b4;
|
||||
--accent:#6d5cf0; --accent-ink:#a99bff; --warn:#e08a4a;
|
||||
--line:#2a2f3e; --control:#222634; --control2:#1d212d; --raised:#2c3242;
|
||||
--cnt:#5a6076; --foot:#5a6076; --shadow:rgba(0,0,0,.45);
|
||||
}
|
||||
/* lift the category hue toward white on dark surfaces so deep hues stay legible */
|
||||
:root[data-theme="dark"] section > h2 { color:color-mix(in srgb, var(--c) 62%, #fff); }
|
||||
:root[data-theme="dark"] .tech .ico { color:color-mix(in srgb, var(--c) 68%, #fff); }
|
||||
:root[data-theme="dark"] label.tech:has(input:checked) { border-color:color-mix(in srgb, var(--c) 60%, #fff); }
|
||||
.titlerow { display:flex; align-items:flex-start; justify-content:space-between; gap:12px; }
|
||||
.themebtn { flex:none; width:36px; height:36px; border-radius:9px; background:var(--control); color:var(--ink); font-size:17px; line-height:1; display:inline-flex; align-items:center; justify-content:center; }
|
||||
.themebtn:hover { background:var(--raised); }
|
||||
* { box-sizing:border-box; }
|
||||
body { margin:0; font:16px/1.5 -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Helvetica,Arial,sans-serif; background:var(--bg); color:var(--ink); }
|
||||
header { position:sticky; top:0; z-index:5; background:var(--surface); padding:20px 0 12px; border-bottom:1px solid var(--line); box-shadow:0 2px 12px var(--shadow); }
|
||||
.hwrap { max-width:1120px; margin:0 auto; padding:0 24px; } /* align header content with the card column on wide screens */
|
||||
h1 { margin:0 0 4px; font-size:24px; letter-spacing:-.02em; }
|
||||
.sub { margin:0 0 12px; color:var(--muted); font-size:14px; max-width:74ch; }
|
||||
button { font:inherit; border:0; border-radius:8px; cursor:pointer; }
|
||||
.composer { display:flex; flex-direction:column; gap:9px; margin:6px 0 12px; }
|
||||
.grp { display:flex; gap:8px; align-items:center; flex-wrap:wrap; }
|
||||
.glabel { font-size:11px; text-transform:uppercase; letter-spacing:.07em; color:var(--muted); min-width:74px; }
|
||||
.modes { display:inline-flex; background:var(--control); border-radius:9px; padding:3px; gap:2px; }
|
||||
.mode { padding:7px 13px; font-size:14px; font-weight:600; color:var(--muted); background:transparent; }
|
||||
.mode.on { background:var(--raised); color:var(--accent-ink); box-shadow:0 1px 3px var(--shadow); }
|
||||
.modehint { flex:1 1 240px; min-width:0; font-size:13px; color:var(--muted); font-style:italic; }
|
||||
.pill { font-size:13px; color:var(--muted); background:var(--control); padding:6px 12px; border-radius:20px; }
|
||||
.pill b { color:var(--accent-ink); }
|
||||
.step { display:inline-flex; align-items:center; gap:7px; font-size:13px; color:var(--ink); background:var(--control2); padding:4px 6px 4px 12px; border-radius:20px; }
|
||||
.step b { min-width:12px; text-align:center; font-size:14px; color:var(--ink); }
|
||||
.step button { width:24px; height:24px; border-radius:50%; background:var(--raised); color:var(--muted); font-size:17px; line-height:22px; text-align:center; box-shadow:0 1px 2px var(--shadow); }
|
||||
.step button:hover { color:var(--accent-ink); }
|
||||
.total { font-size:12px; color:var(--muted); }
|
||||
.total.warn { color:var(--warn); font-weight:600; }
|
||||
.bar { display:flex; gap:10px 14px; align-items:center; flex-wrap:wrap; }
|
||||
#copy { margin-left:auto; padding:9px 22px; background:var(--accent); color:#fff; font-size:14px; font-weight:700; }
|
||||
#copy:hover { filter:brightness(1.07); }
|
||||
.chips { flex:1 1 320px; min-width:0; display:flex; gap:7px; flex-wrap:wrap; align-items:center; }
|
||||
.chip { font-size:12px; padding:4px 11px; border-radius:16px; border:0; color:#fff; background:var(--cc); font-weight:600; cursor:pointer; }
|
||||
.chip:hover { filter:brightness(1.08); }
|
||||
.banner { max-height:0; overflow:hidden; transition:max-height .25s ease, padding .22s ease, margin .22s ease; background:linear-gradient(90deg,var(--accent),#8275f2); color:#fff; border-radius:10px; font-weight:700; text-align:center; padding:0 14px; }
|
||||
.banner.show { max-height:64px; padding:13px 14px; margin-top:10px; }
|
||||
.banner.fail { background:linear-gradient(90deg,var(--warn),#e0894a); }
|
||||
main { padding:18px 24px 60px; max-width:1120px; margin:0 auto; }
|
||||
section { margin:0 0 26px; }
|
||||
section > h2 { font-size:13px; text-transform:uppercase; letter-spacing:.08em; color:var(--c); margin:0 0 10px; border-bottom:1px solid color-mix(in srgb, var(--c) 24%, var(--line)); padding-bottom:6px; }
|
||||
section > h2 .cnt { color:color-mix(in srgb, var(--c) 45%, var(--cnt)); margin-left:6px; }
|
||||
.grid { display:grid; grid-template-columns:repeat(auto-fill,minmax(360px,1fr)); gap:10px; }
|
||||
label.tech { display:flex; gap:12px; align-items:flex-start; background:color-mix(in srgb, var(--c) 5%, var(--surface)); border:1px solid color-mix(in srgb, var(--c) 18%, var(--line)); border-radius:10px; padding:11px 13px; cursor:pointer; transition:border-color .12s, box-shadow .12s, background .12s; }
|
||||
label.tech:hover { border-color:color-mix(in srgb, var(--c) 45%, var(--surface)); }
|
||||
label.tech input { margin-top:2px; width:17px; height:17px; accent-color:var(--c); flex:none; }
|
||||
label.tech:has(input:checked) { border-color:var(--c); background:color-mix(in srgb, var(--c) 12%, var(--surface)); box-shadow:0 0 0 2px color-mix(in srgb, var(--c) 30%, transparent); }
|
||||
.tech .ic2 { display:flex; gap:5px; flex:none; }
|
||||
.tech .ico { width:40px; height:40px; flex:none; color:var(--c); }
|
||||
.tech .n { font-weight:600; display:block; }
|
||||
.tech .d { color:var(--muted); font-size:13.5px; display:block; margin-top:2px; }
|
||||
.tech .gf { color:var(--accent-ink); font-size:11px; display:block; margin-top:5px; opacity:.85; }
|
||||
.grouphdr { margin:30px 0 12px; font-size:12px; text-transform:uppercase; letter-spacing:.14em; font-weight:700; color:var(--c); opacity:.92; border-bottom:1px solid color-mix(in srgb, var(--c) 22%, var(--line)); padding-bottom:7px; }
|
||||
main > .grouphdr:first-child { margin-top:2px; }
|
||||
:root[data-theme="dark"] .grouphdr { color:color-mix(in srgb, var(--c) 62%, #fff); }
|
||||
.goals { display:flex; gap:7px; flex-wrap:wrap; }
|
||||
.goal { font-size:12px; padding:5px 12px; border-radius:16px; background:var(--control); color:var(--muted); font-weight:600; }
|
||||
.goal:hover { color:var(--ink); }
|
||||
.goal.on { background:var(--accent); color:#fff; }
|
||||
label.tech.invent { border-style:dashed; background:transparent; }
|
||||
label.tech.invent:hover { border-color:var(--c); }
|
||||
label.tech.invent .n { color:var(--c); }
|
||||
label.tech.hidden { display:none; }
|
||||
footer { text-align:center; color:var(--foot); font-size:12px; padding:24px; }
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<header>
|
||||
<div class="hwrap">
|
||||
<div class="titlerow">
|
||||
<h1>BMad Method Brainstorming Selection</h1>
|
||||
<button id="theme" class="themebtn" type="button" aria-label="Toggle dark mode" title="Toggle dark mode"></button>
|
||||
</div>
|
||||
<p class="sub">Compose your session, hit <strong>Copy prompt</strong>, and paste it back into the chat to begin. {{TOTAL}}</p>
|
||||
|
||||
<div class="composer">
|
||||
<div class="grp">
|
||||
<span class="glabel">Facilitation</span>
|
||||
<div class="modes" id="modes">
|
||||
<button type="button" class="mode on" data-mode="Facilitator">Facilitator</button>
|
||||
<button type="button" class="mode" data-mode="Creative Partner">Creative Partner</button>
|
||||
<button type="button" class="mode" data-mode="Ideate for me">Ideate for me</button>
|
||||
</div>
|
||||
<span class="modehint" id="modehint"></span>
|
||||
</div>
|
||||
<div class="grp">
|
||||
<span class="glabel">Techniques</span>
|
||||
<span class="pill">Picked <b id="pickN">0</b></span>
|
||||
<span class="step">Random <button type="button" data-step="rand" data-d="-1">−</button><b id="randN">0</b><button type="button" data-step="rand" data-d="1">+</button></span>
|
||||
<span class="step">Invent <button type="button" data-step="inv" data-d="-1">−</button><b id="invN">0</b><button type="button" data-step="inv" data-d="1">+</button></span>
|
||||
<span class="step">AI picks <button type="button" data-step="ai" data-d="-1">−</button><b id="aiN">0</b><button type="button" data-step="ai" data-d="1">+</button></span>
|
||||
<span class="total" id="total">Total 0 · 3–4 is the sweet spot</span>
|
||||
<button id="copy" type="button">Copy prompt</button>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
{{GOALBAR}}
|
||||
<div class="bar">
|
||||
<span class="glabel">Jump to</span>
|
||||
<div class="chips" id="chips">{{CHIPS}}</div>
|
||||
</div>
|
||||
|
||||
<div class="banner" id="banner">✓ Copied! Now paste it into the chat to start your session.</div>
|
||||
</div>
|
||||
</header>
|
||||
<main>
|
||||
{{BODY}}
|
||||
</main>
|
||||
<footer>BMad Method · Brainstorming</footer>
|
||||
<script>
|
||||
(function(){
|
||||
var $ = function(id){ return document.getElementById(id); };
|
||||
var all = Array.prototype.slice;
|
||||
var boxes = all.call(document.querySelectorAll('input[type=checkbox]'));
|
||||
var techBoxes = boxes.filter(function(b){ return b.dataset.name; }); // real technique cards
|
||||
var inventBoxes = boxes.filter(function(b){ return b.dataset.invent; }); // per-category "invent in the spirit of" cards
|
||||
var header = document.querySelector('header');
|
||||
var sections = all.call(document.querySelectorAll('section'));
|
||||
var state = { mode: 'Facilitator', rand: 0, inv: 0, ai: 0 };
|
||||
var MODE_HINTS = {
|
||||
'Facilitator': 'A forcing function for your ideas — I prompt and push, but never supply them.',
|
||||
'Creative Partner': 'We riff together — I facilitate and add ideas too, each logged as yours or mine.',
|
||||
'Ideate for me': 'I run the whole session myself, then show you the result and offer to keep going.'
|
||||
};
|
||||
function setHint(){ $('modehint').textContent = MODE_HINTS[state.mode] || ''; }
|
||||
|
||||
var themeBtn = $('theme');
|
||||
function setThemeIcon(){ themeBtn.textContent = document.documentElement.getAttribute('data-theme') === 'dark' ? '☀' : '☾'; }
|
||||
themeBtn.addEventListener('click', function(){
|
||||
var next = document.documentElement.getAttribute('data-theme') === 'dark' ? 'light' : 'dark';
|
||||
document.documentElement.setAttribute('data-theme', next);
|
||||
try { localStorage.setItem('bmad-theme', next); } catch(e){}
|
||||
setThemeIcon();
|
||||
});
|
||||
|
||||
all.call(document.querySelectorAll('.mode')).forEach(function(b){
|
||||
b.addEventListener('click', function(){
|
||||
all.call(document.querySelectorAll('.mode')).forEach(function(m){ m.classList.remove('on'); });
|
||||
b.classList.add('on');
|
||||
state.mode = b.dataset.mode;
|
||||
setHint();
|
||||
});
|
||||
});
|
||||
|
||||
all.call(document.querySelectorAll('[data-step]')).forEach(function(btn){
|
||||
btn.addEventListener('click', function(){
|
||||
var k = btn.dataset.step, d = parseInt(btn.dataset.d, 10);
|
||||
state[k] = Math.max(0, state[k] + d);
|
||||
update();
|
||||
});
|
||||
});
|
||||
|
||||
// Category chips are jump-nav: click one to smooth-scroll its section into view,
|
||||
// offsetting by the sticky header's height so the heading isn't hidden beneath it.
|
||||
all.call(document.querySelectorAll('.chip')).forEach(function(chip){
|
||||
chip.addEventListener('click', function(){
|
||||
var sec = null;
|
||||
for (var i = 0; i < sections.length; i++){ if (sections[i].dataset.cat === chip.dataset.cat){ sec = sections[i]; break; } }
|
||||
if (!sec){ return; }
|
||||
var top = sec.getBoundingClientRect().top + window.pageYOffset - header.offsetHeight - 8;
|
||||
window.scrollTo({ top: top, behavior: 'smooth' });
|
||||
});
|
||||
});
|
||||
|
||||
boxes.forEach(function(b){ b.addEventListener('change', update); });
|
||||
|
||||
// A `classic` technique appears twice (lead "Proven & Professional" group + its home
|
||||
// category), so de-dupe checked picks by name; the lead copy carries data-lead.
|
||||
function checkedTech(){
|
||||
var seen = {}, out = [];
|
||||
techBoxes.forEach(function(b){
|
||||
if (!b.checked || seen[b.dataset.name]) { return; }
|
||||
seen[b.dataset.name] = 1;
|
||||
out.push(b);
|
||||
});
|
||||
return out;
|
||||
}
|
||||
function checkedInvent(){ return inventBoxes.filter(function(b){ return b.checked; }); }
|
||||
|
||||
function update(){
|
||||
$('pickN').textContent = checkedTech().length;
|
||||
$('randN').textContent = state.rand;
|
||||
$('invN').textContent = state.inv;
|
||||
$('aiN').textContent = state.ai;
|
||||
var total = checkedTech().length + state.rand + state.inv + checkedInvent().length + state.ai;
|
||||
var t = $('total');
|
||||
t.textContent = 'Total ' + total + ' · 3–4 is the sweet spot';
|
||||
t.classList.toggle('warn', total > 5);
|
||||
}
|
||||
|
||||
// "Great for" goal filter: clicking a goal narrows visible cards to those tagged with it.
|
||||
var goalBtns = all.call(document.querySelectorAll('.goal'));
|
||||
function activeGoals(){ return goalBtns.filter(function(b){ return b.classList.contains('on'); }).map(function(b){ return b.dataset.goal; }); }
|
||||
function applyFilter(){
|
||||
var act = activeGoals();
|
||||
all.call(document.querySelectorAll('label.tech')).forEach(function(lab){
|
||||
var inp = lab.querySelector('input');
|
||||
if (inp.dataset.invent){ return; } // invent cards aren't goal-tagged — always visible
|
||||
var good = (inp.dataset.good || '').split('|');
|
||||
var show = !act.length || act.some(function(g){ return good.indexOf(g) >= 0; });
|
||||
lab.classList.toggle('hidden', !show);
|
||||
});
|
||||
}
|
||||
goalBtns.forEach(function(b){ b.addEventListener('click', function(){ b.classList.toggle('on'); applyFilter(); }); });
|
||||
|
||||
function randomPool(){
|
||||
var picked = {};
|
||||
checkedTech().forEach(function(b){ picked[b.dataset.name] = 1; });
|
||||
// draw from unchecked, non-lead copies, skipping anything already picked
|
||||
return techBoxes.filter(function(b){ return !b.checked && !b.dataset.lead && !picked[b.dataset.name]; });
|
||||
}
|
||||
|
||||
function sample(arr, n){
|
||||
var a = arr.slice(), out = [];
|
||||
while (out.length < n && a.length){ out.push(a.splice(Math.floor(Math.random() * a.length), 1)[0]); }
|
||||
return out;
|
||||
}
|
||||
|
||||
function compose(){
|
||||
var picks = checkedTech().map(function(b){ return { n: b.dataset.name, c: b.dataset.cat, d: b.dataset.desc, r: false }; });
|
||||
var rnd = sample(randomPool(), state.rand).map(function(b){ return { n: b.dataset.name, c: b.dataset.cat, d: b.dataset.desc, r: true }; });
|
||||
var techs = picks.concat(rnd);
|
||||
var L = ["Let's run my brainstorming session.", "", 'Facilitation mode: ' + state.mode + '.'];
|
||||
if (techs.length){
|
||||
L.push("", 'Techniques to use:');
|
||||
techs.forEach(function(t, i){
|
||||
L.push((i + 1) + '.' + (t.r ? ' (random pick)' : '') + ' ' + t.n + ' · ' + t.c);
|
||||
L.push(' ' + t.d);
|
||||
});
|
||||
}
|
||||
var extra = [];
|
||||
if (state.inv > 0){ extra.push('invent ' + state.inv + ' brand-new technique' + (state.inv > 1 ? 's' : '') + ' on the fly'); }
|
||||
checkedInvent().forEach(function(b){ extra.push('invent 1 new technique in the spirit of ' + b.dataset.invent); });
|
||||
if (state.ai > 0){ extra.push('you choose ' + state.ai + ' more technique' + (state.ai > 1 ? 's' : '') + ' that fit my goal'); }
|
||||
if (extra.length){ L.push("", 'Then: ' + extra.join('; and ') + '.'); }
|
||||
if (!techs.length && !extra.length){
|
||||
L.push("", state.mode === 'Ideate for me'
|
||||
? 'Run the whole session yourself — pick the techniques, generate the ideas, then show me the result.'
|
||||
: 'Help me choose 3–4 techniques to start.');
|
||||
}
|
||||
return L.join('\n');
|
||||
}
|
||||
|
||||
function fallbackCopy(t){
|
||||
var ta = document.createElement('textarea');
|
||||
ta.value = t; ta.style.position = 'fixed'; ta.style.opacity = '0';
|
||||
document.body.appendChild(ta); ta.focus(); ta.select();
|
||||
var ok = false;
|
||||
try { ok = document.execCommand('copy'); } catch(e){ ok = false; }
|
||||
document.body.removeChild(ta);
|
||||
return ok;
|
||||
}
|
||||
|
||||
function flash(ok, text){
|
||||
var b = $('banner');
|
||||
b.classList.toggle('fail', !ok);
|
||||
b.innerHTML = ok
|
||||
? '✓ Copied! Now paste it into the chat to start your session.'
|
||||
: '⚠ Couldn’t reach the clipboard — copy the text in the box, then paste it into the chat.';
|
||||
b.classList.add('show');
|
||||
setTimeout(function(){ b.classList.remove('show'); }, 4500);
|
||||
// Last resort on a hard failure: a prefilled, selectable prompt so the text is never lost.
|
||||
if (!ok){ window.prompt('Copy this, then paste it into the chat:', text); }
|
||||
}
|
||||
|
||||
$('copy').addEventListener('click', function(){
|
||||
var text = compose();
|
||||
if (navigator.clipboard && navigator.clipboard.writeText){
|
||||
navigator.clipboard.writeText(text).then(
|
||||
function(){ flash(true, text); },
|
||||
function(){ flash(fallbackCopy(text), text); }
|
||||
);
|
||||
} else { flash(fallbackCopy(text), text); }
|
||||
});
|
||||
|
||||
setHint();
|
||||
setThemeIcon();
|
||||
update();
|
||||
})();
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
"""
|
||||
|
||||
|
||||
# --- browse-page layout: a "Proven & Professional" lead group, then super-groups ----------
|
||||
CLASSIC_GROUP = "Proven & Professional"
|
||||
LEAD_HUE = "#3d4f73" # a dignified slate for the professional lead group
|
||||
|
||||
# Super-group order for the shipped categories. Categories not listed (e.g. user-added
|
||||
# via --extra) render last under "More", alphabetically — so custom catalogs always show.
|
||||
CATEGORY_GROUPS = (
|
||||
("Structured & Analytical", ("structured", "deep")),
|
||||
("Creative & Generative", ("creative", "biomimetic", "cultural", "speculative_future", "quantum")),
|
||||
("Wild & Playful", ("wild", "absurdist", "theatrical", "constraint")),
|
||||
("Introspective & Personal", ("introspective_delight", "collaborative")),
|
||||
)
|
||||
|
||||
# Human labels for the `good_for` goal tags; this dict's order is the filter-bar order.
|
||||
GOAL_LABELS = {
|
||||
"feature": "Build a feature",
|
||||
"novel": "Novel concept",
|
||||
"strategy": "Strategy",
|
||||
"planning": "Planning",
|
||||
"diagnosis": "Diagnose",
|
||||
"personal": "Personal / life",
|
||||
"unstuck": "Get unstuck",
|
||||
}
|
||||
|
||||
|
||||
def _good_for_label(good: str) -> str:
|
||||
parts = [GOAL_LABELS.get(g, g) for g in good.split("|") if g]
|
||||
return ("Great for: " + " · ".join(parts)) if parts else ""
|
||||
|
||||
|
||||
def _svg(inner: str) -> str:
|
||||
return f'<svg class="ico" viewBox="0 0 44 44" xmlns="http://www.w3.org/2000/svg">{CHIP}{inner}</svg>'
|
||||
|
||||
|
||||
def _card(r: dict, lead: bool = False) -> str:
|
||||
"""One technique card. `lead=True` cards live in the cross-cutting professional group;
|
||||
they carry their own category hue (inline --c) and data-lead so selection can de-dupe."""
|
||||
name = html.escape(r["technique_name"])
|
||||
desc = html.escape(r["description"])
|
||||
hue, glyph = category_style(r["category"])
|
||||
disp_cat = html.escape(pretty(r["category"]))
|
||||
good = html.escape(r.get("good_for", ""))
|
||||
prov = html.escape(r.get("provenance", ""))
|
||||
style = f' style="--c:{hue}"' if lead else ""
|
||||
lead_attr = ' data-lead="1"' if lead else ""
|
||||
gf = _good_for_label(r.get("good_for", ""))
|
||||
gf_html = f'<span class="gf">{html.escape(gf)}</span>' if gf else ""
|
||||
return (
|
||||
f'<label class="tech"{style}><input type="checkbox" '
|
||||
f'data-name="{name}" data-cat="{disp_cat}" data-desc="{desc}" data-good="{good}" data-prov="{prov}"{lead_attr}>'
|
||||
f'<span class="ic2">{_svg(glyph)}{_svg(tech_icon(r["technique_name"]))}</span>'
|
||||
f'<span><span class="n">{name}</span><span class="d">{desc}</span>{gf_html}</span></label>'
|
||||
)
|
||||
|
||||
|
||||
def _invent_card(disp_cat: str, glyph: str) -> str:
|
||||
"""A dashed 'invent on the fly, in this category's spirit' card appended to each section."""
|
||||
return (
|
||||
f'<label class="tech invent"><input type="checkbox" data-invent="{disp_cat}">'
|
||||
f'<span class="ic2">{_svg(glyph)}</span>'
|
||||
f'<span><span class="n">✨ Invent a {disp_cat} technique</span>'
|
||||
f'<span class="d">Make up a brand-new technique on the fly, in the spirit of {disp_cat}</span></span></label>'
|
||||
)
|
||||
|
||||
|
||||
def html_doc(rows: list[dict]) -> str:
|
||||
"""Render the self-contained 'browse all techniques' selection page from the catalog.
|
||||
|
||||
Deterministic ordering so the shipped asset can be snapshot-tested against the CSV:
|
||||
a cross-cutting "Proven & Professional" lead group (every `classic`-tagged row), then
|
||||
the categories in fixed super-group order, then any unlisted/custom categories under
|
||||
"More" alphabetically. Techniques render in file order within a category. A `classic`
|
||||
row appears both in the lead group and its home category; the page de-dupes on select.
|
||||
"""
|
||||
groups: dict[str, list[dict]] = {}
|
||||
for r in rows:
|
||||
groups.setdefault(r["category"], []).append(r)
|
||||
|
||||
body: list[str] = []
|
||||
chips: list[str] = []
|
||||
|
||||
def add_section(cat: str) -> None:
|
||||
hue, glyph = category_style(cat)
|
||||
disp = html.escape(pretty(cat))
|
||||
cards = [_card(r) for r in groups[cat]]
|
||||
cards.append(_invent_card(disp, glyph))
|
||||
chips.append(f'<button type="button" class="chip" data-cat="{disp}" style="--cc:{hue}">{disp}</button>')
|
||||
body.append(
|
||||
f'<section data-cat="{disp}" style="--c:{hue}"><h2>{disp}<span class="cnt">{len(groups[cat])}</span></h2>'
|
||||
f'<div class="grid">{"".join(cards)}</div></section>'
|
||||
)
|
||||
|
||||
# 1) lead group — every classic-tagged technique, cross-category (no invent card here)
|
||||
classics = [r for r in rows if r.get("provenance", "").lower() == "classic"]
|
||||
if classics:
|
||||
disp = html.escape(CLASSIC_GROUP)
|
||||
lead_cards = "".join(_card(r, lead=True) for r in classics)
|
||||
chips.append(f'<button type="button" class="chip" data-cat="{disp}" style="--cc:{LEAD_HUE}">{disp}</button>')
|
||||
body.append(
|
||||
f'<section data-cat="{disp}" style="--c:{LEAD_HUE}"><h2>{disp}<span class="cnt">{len(classics)}</span></h2>'
|
||||
f'<div class="grid">{lead_cards}</div></section>'
|
||||
)
|
||||
|
||||
# 2) shipped categories, in super-group order
|
||||
placed = set()
|
||||
for group_title, cats in CATEGORY_GROUPS:
|
||||
present = [c for c in cats if c in groups]
|
||||
if not present:
|
||||
continue
|
||||
hue, _ = category_style(present[0])
|
||||
body.append(f'<h2 class="grouphdr" style="--c:{hue}">{html.escape(group_title)}</h2>')
|
||||
for c in present:
|
||||
add_section(c)
|
||||
placed.add(c)
|
||||
|
||||
# 3) leftover (custom / --extra) categories, alphabetically
|
||||
leftover = sorted(c for c in groups if c not in placed)
|
||||
if leftover:
|
||||
body.append('<h2 class="grouphdr" style="--c:#8a8f9e">More</h2>')
|
||||
for c in leftover:
|
||||
add_section(c)
|
||||
|
||||
# goal-affinity filter bar — only if the catalog actually carries good_for tags
|
||||
present_goals: set[str] = set()
|
||||
for r in rows:
|
||||
for g in (r.get("good_for", "") or "").split("|"):
|
||||
if g:
|
||||
present_goals.add(g)
|
||||
goalbar = ""
|
||||
if present_goals:
|
||||
ordered = [g for g in GOAL_LABELS if g in present_goals] + sorted(present_goals - set(GOAL_LABELS))
|
||||
gchips = "".join(
|
||||
f'<button type="button" class="goal" data-goal="{html.escape(g)}">{html.escape(GOAL_LABELS.get(g, g))}</button>'
|
||||
for g in ordered
|
||||
)
|
||||
goalbar = f'<div class="bar"><span class="glabel">Great for</span><div class="goals" id="goals">{gchips}</div></div>'
|
||||
|
||||
total = html.escape(f"{len(rows)} techniques across {len(groups)} categories.")
|
||||
return (
|
||||
SELECTOR_TEMPLATE.replace("{{BODY}}", "\n".join(body))
|
||||
.replace("{{CHIPS}}", "".join(chips))
|
||||
.replace("{{GOALBAR}}", goalbar)
|
||||
.replace("{{TOTAL}}", total)
|
||||
)
|
||||
|
||||
|
||||
def main(argv: list[str] | None = None) -> int:
|
||||
p = argparse.ArgumentParser(description=__doc__, formatter_class=argparse.RawDescriptionHelpFormatter)
|
||||
p.add_argument("--file", type=Path, default=DEFAULT_FILE, help="technique CSV (default: sibling assets/brain-methods.csv)")
|
||||
p.add_argument("--extra", type=Path, help="JSON overlay of additional techniques (customize.toml additional_techniques), merged into every command")
|
||||
p.add_argument("--json", action="store_true", help="emit structured JSON instead of lean text")
|
||||
sub = p.add_subparsers(dest="cmd", required=True)
|
||||
sub.add_parser("categories", help="list category names + counts")
|
||||
pl = sub.add_parser("list", help="the index: category/name/gist (needs --category or --all)")
|
||||
pl.add_argument("--category", action="append", help="filter to a category (repeatable)")
|
||||
pl.add_argument("--all", action="store_true", help="dump the entire catalog (deliberate; large)")
|
||||
ps = sub.add_parser("show", help="full gist + detail file for named techniques")
|
||||
ps.add_argument("names", nargs="+")
|
||||
pr = sub.add_parser("random", help="pick techniques at random")
|
||||
pr.add_argument("--category", action="append", help="restrict to a category (repeatable)")
|
||||
pr.add_argument("-n", type=int, default=1, help="how many (default 1)")
|
||||
ph = sub.add_parser("html", help="write the offline 'browse all' selection page")
|
||||
ph.add_argument("--out", help="file to write the page to (required; never prints the catalog)")
|
||||
args = p.parse_args(argv)
|
||||
|
||||
if not args.file.is_file():
|
||||
print(f"error: technique file not found: {args.file}", file=sys.stderr)
|
||||
return 2
|
||||
rows = load(args.file)
|
||||
if args.extra:
|
||||
if not args.extra.is_file():
|
||||
print(f"error: --extra file not found: {args.extra}", file=sys.stderr)
|
||||
return 2
|
||||
rows += load_extra(args.extra)
|
||||
csv_dir = args.file.resolve().parent
|
||||
|
||||
if args.cmd == "categories":
|
||||
print(fmt_categories(categories(rows), args.json))
|
||||
elif args.cmd == "list":
|
||||
if not args.category and not args.all:
|
||||
print(
|
||||
"error: `list` needs --category (one or more) — or --all to dump the whole "
|
||||
"catalog on purpose. Use `categories` for the cheap map, or `random` to draw blind.",
|
||||
file=sys.stderr,
|
||||
)
|
||||
return 2
|
||||
print(fmt_list(filter_cats(rows, args.category), args.json))
|
||||
elif args.cmd == "show":
|
||||
found, missing = find(rows, args.names)
|
||||
for m in missing:
|
||||
print(f"# not found: {m}", file=sys.stderr)
|
||||
if not found:
|
||||
return 1
|
||||
print(fmt_show(found, csv_dir, args.json))
|
||||
elif args.cmd == "random":
|
||||
pool = filter_cats(rows, args.category)
|
||||
if not pool:
|
||||
print("# no techniques match", file=sys.stderr)
|
||||
return 1
|
||||
n = max(0, min(args.n, len(pool))) # clamp: never crash on a negative or oversized -n
|
||||
print(fmt_list(random.sample(pool, n), args.json))
|
||||
elif args.cmd == "html":
|
||||
if not args.out:
|
||||
print(
|
||||
"error: `html` needs --out PATH — it writes the selection page to a file and "
|
||||
"never prints the catalog to stdout (which would defeat the point).",
|
||||
file=sys.stderr,
|
||||
)
|
||||
return 2
|
||||
out = Path(args.out)
|
||||
out.parent.mkdir(parents=True, exist_ok=True)
|
||||
out.write_text(html_doc(rows), encoding="utf-8")
|
||||
print(f"wrote {out} ({len(rows)} techniques, {len(categories(rows))} categories)")
|
||||
return 0
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
sys.exit(main())
|
||||
217
.agent/skills/bmad-brainstorming/scripts/tests/test_brain.py
Normal file
217
.agent/skills/bmad-brainstorming/scripts/tests/test_brain.py
Normal file
@@ -0,0 +1,217 @@
|
||||
# /// script
|
||||
# requires-python = ">=3.10"
|
||||
# dependencies = ["pytest>=8.0"]
|
||||
# ///
|
||||
"""Tests for brain.py. Run: uv run -m pytest scripts/tests/test_brain.py"""
|
||||
import sys
|
||||
from pathlib import Path
|
||||
|
||||
import pytest
|
||||
|
||||
sys.path.insert(0, str(Path(__file__).resolve().parent.parent))
|
||||
import brain # noqa: E402
|
||||
|
||||
CSV = """category,technique_name,description,detail
|
||||
collaborative,Yes And Building,Build on every idea with "yes and" to keep momentum,
|
||||
wild,Quantum Superposition,Hold contradictory ideas as simultaneously true,techniques/quantum.md
|
||||
structured,SCAMPER Method,Run the idea through seven transformation lenses,
|
||||
wild,Anti-Solution,Brainstorm how to make the problem worse then invert,
|
||||
"""
|
||||
|
||||
DETAIL = "# Quantum Superposition\nFull multi-step instructions for the complex technique."
|
||||
|
||||
|
||||
@pytest.fixture
|
||||
def lib(tmp_path):
|
||||
csv_path = tmp_path / "brain-methods.csv"
|
||||
csv_path.write_text(CSV, encoding="utf-8")
|
||||
(tmp_path / "techniques").mkdir()
|
||||
(tmp_path / "techniques" / "quantum.md").write_text(DETAIL, encoding="utf-8")
|
||||
return csv_path
|
||||
|
||||
|
||||
def test_load_normalizes_detail(lib):
|
||||
rows = brain.load(lib)
|
||||
assert len(rows) == 4
|
||||
assert rows[0]["detail"] == ""
|
||||
assert rows[1]["detail"] == "techniques/quantum.md"
|
||||
|
||||
|
||||
def test_categories_counts_sorted(lib):
|
||||
assert brain.categories(brain.load(lib)) == [("collaborative", 1), ("structured", 1), ("wild", 2)]
|
||||
|
||||
|
||||
def test_filter_is_case_insensitive(lib):
|
||||
rows = brain.filter_cats(brain.load(lib), ["WILD"])
|
||||
assert {r["technique_name"] for r in rows} == {"Quantum Superposition", "Anti-Solution"}
|
||||
|
||||
|
||||
def test_filter_none_returns_all(lib):
|
||||
assert len(brain.filter_cats(brain.load(lib), None)) == 4
|
||||
|
||||
|
||||
def test_find_hits_and_misses(lib):
|
||||
found, missing = brain.find(brain.load(lib), ["scamper method", "Nope"])
|
||||
assert [r["technique_name"] for r in found] == ["SCAMPER Method"]
|
||||
assert missing == ["Nope"]
|
||||
|
||||
|
||||
def test_resolve_detail_present(lib):
|
||||
row = next(r for r in brain.load(lib) if r["detail"])
|
||||
assert "multi-step instructions" in brain.resolve_detail(row, lib.parent)
|
||||
|
||||
|
||||
def test_resolve_detail_absent_is_none(lib):
|
||||
row = next(r for r in brain.load(lib) if not r["detail"])
|
||||
assert brain.resolve_detail(row, lib.parent) is None
|
||||
|
||||
|
||||
def test_resolve_detail_missing_file_warns_not_fatal(lib, capsys):
|
||||
rows = brain.load(lib)
|
||||
rows[1]["detail"] = "techniques/gone.md"
|
||||
assert brain.resolve_detail(rows[1], lib.parent) is None
|
||||
assert "not found" in capsys.readouterr().err
|
||||
|
||||
|
||||
def test_show_inlines_detail(lib, capsys):
|
||||
assert brain.main(["--file", str(lib), "show", "Quantum Superposition"]) == 0
|
||||
out = capsys.readouterr().out
|
||||
assert "multi-step instructions" in out and "[wild]" in out
|
||||
|
||||
|
||||
def test_show_simple_has_no_detail(lib, capsys):
|
||||
brain.main(["--file", str(lib), "show", "SCAMPER Method"])
|
||||
out = capsys.readouterr().out
|
||||
assert "transformation lenses" in out
|
||||
|
||||
|
||||
def test_show_all_missing_returns_1(lib):
|
||||
assert brain.main(["--file", str(lib), "show", "Ghost"]) == 1
|
||||
|
||||
|
||||
def test_list_filtered_text(lib, capsys):
|
||||
brain.main(["--file", str(lib), "list", "--category", "structured"])
|
||||
out = capsys.readouterr().out.strip().splitlines()
|
||||
assert len(out) == 1 and out[0].startswith("structured\tSCAMPER Method\t")
|
||||
|
||||
|
||||
def test_list_bare_is_refused(lib, capsys):
|
||||
# the footgun: bare `list` must NOT dump the catalog into context
|
||||
assert brain.main(["--file", str(lib), "list"]) == 2
|
||||
captured = capsys.readouterr()
|
||||
assert captured.out == "" # nothing leaked to stdout
|
||||
assert "--category" in captured.err and "--all" in captured.err
|
||||
|
||||
|
||||
def test_list_all_dumps_everything(lib, capsys):
|
||||
assert brain.main(["--file", str(lib), "list", "--all"]) == 0
|
||||
out = capsys.readouterr().out.strip().splitlines()
|
||||
assert len(out) == 4 # the deliberate full-catalog escape hatch
|
||||
|
||||
|
||||
def test_json_output(lib, capsys):
|
||||
import json
|
||||
brain.main(["--file", str(lib), "--json", "categories"])
|
||||
data = json.loads(capsys.readouterr().out)
|
||||
assert {"category": "wild", "count": 2} in data
|
||||
|
||||
|
||||
def test_random_respects_n_and_category(lib, capsys):
|
||||
brain.main(["--file", str(lib), "random", "--category", "wild", "-n", "5"])
|
||||
lines = capsys.readouterr().out.strip().splitlines()
|
||||
assert len(lines) == 2 # only 2 wild exist, n capped
|
||||
assert all(line.startswith("wild\t") for line in lines)
|
||||
|
||||
|
||||
def test_random_negative_n_does_not_crash(lib, capsys):
|
||||
# a negative -n is clamped to 0, not passed to random.sample (which would raise)
|
||||
assert brain.main(["--file", str(lib), "random", "-n", "-1"]) == 0
|
||||
assert capsys.readouterr().out.strip() == ""
|
||||
|
||||
|
||||
def test_missing_file_returns_2(tmp_path):
|
||||
assert brain.main(["--file", str(tmp_path / "nope.csv"), "categories"]) == 2
|
||||
|
||||
|
||||
# --- html selection page ------------------------------------------------
|
||||
|
||||
def test_html_requires_out(lib, capsys):
|
||||
# never dump the catalog to stdout — writing to a file is the whole point
|
||||
assert brain.main(["--file", str(lib), "html"]) == 2
|
||||
assert "--out" in capsys.readouterr().err
|
||||
|
||||
|
||||
def test_html_writes_selection_page(lib, tmp_path):
|
||||
out = tmp_path / "sel.html"
|
||||
assert brain.main(["--file", str(lib), "html", "--out", str(out)]) == 0
|
||||
doc = out.read_text(encoding="utf-8")
|
||||
assert doc.startswith("<!DOCTYPE html>")
|
||||
assert "BMad Method Brainstorming Selection" in doc
|
||||
for r in brain.load(lib):
|
||||
assert r["technique_name"] in doc # every technique is selectable
|
||||
assert ""yes and"" in doc # quotes in a description are escaped, not raw
|
||||
|
||||
|
||||
def test_html_creates_missing_parent(lib, tmp_path):
|
||||
out = tmp_path / "nested" / "deep" / "sel.html"
|
||||
assert brain.main(["--file", str(lib), "html", "--out", str(out)]) == 0
|
||||
assert out.is_file()
|
||||
|
||||
|
||||
# --- --extra overlay (customize.toml additional_techniques) -------------
|
||||
|
||||
EXTRA = (
|
||||
'[{"category": "domain-specific", "technique_name": "Regulatory Inversion", '
|
||||
'"description": "Start from the compliance constraint and brainstorm what it unlocks."}, '
|
||||
'{"category": "wild", "technique_name": "Extra Wild One", "description": "An added wild method."}]'
|
||||
)
|
||||
|
||||
|
||||
@pytest.fixture
|
||||
def extra(tmp_path):
|
||||
p = tmp_path / "extra.json"
|
||||
p.write_text(EXTRA, encoding="utf-8")
|
||||
return p
|
||||
|
||||
|
||||
def test_extra_merges_into_categories(lib, extra, capsys):
|
||||
brain.main(["--file", str(lib), "--extra", str(extra), "categories"])
|
||||
out = capsys.readouterr().out
|
||||
assert "domain-specific\t1" in out # a brand-new category appears
|
||||
assert "wild\t3" in out # the extra wild one is counted alongside the shipped two
|
||||
|
||||
|
||||
def test_extra_appears_in_list_and_random(lib, extra, capsys):
|
||||
brain.main(["--file", str(lib), "--extra", str(extra), "list", "--category", "domain-specific"])
|
||||
assert "Regulatory Inversion" in capsys.readouterr().out
|
||||
|
||||
|
||||
def test_extra_is_first_class_in_html(lib, extra, tmp_path):
|
||||
out = tmp_path / "sel.html"
|
||||
assert brain.main(["--file", str(lib), "--extra", str(extra), "html", "--out", str(out)]) == 0
|
||||
doc = out.read_text(encoding="utf-8")
|
||||
# custom technique is selectable and its new category renders without crashing (fallback glyph/hue)
|
||||
assert "Regulatory Inversion" in doc
|
||||
assert "Domain Specific" in doc
|
||||
|
||||
|
||||
def test_extra_missing_file_returns_2(lib, tmp_path):
|
||||
assert brain.main(["--file", str(lib), "--extra", str(tmp_path / "nope.json"), "categories"]) == 2
|
||||
|
||||
|
||||
def test_unknown_category_style_uses_fallback_glyph():
|
||||
hue, glyph = brain.category_style("totally-made-up-category")
|
||||
assert hue.startswith("#") and len(hue) == 7 # valid derived hex
|
||||
assert glyph == brain._FALLBACK_GLYPH
|
||||
|
||||
|
||||
def test_shipped_selector_is_in_sync_with_catalog():
|
||||
# foolproofing: if someone edits brain-methods.csv they must regenerate the page.
|
||||
# Regenerate with: uv run brain.py html --out assets/brain-selector.html
|
||||
asset = brain.DEFAULT_FILE.parent / "brain-selector.html"
|
||||
assert asset.is_file(), "missing assets/brain-selector.html — generate it"
|
||||
expected = brain.html_doc(brain.load(brain.DEFAULT_FILE))
|
||||
assert asset.read_text(encoding="utf-8") == expected, (
|
||||
"assets/brain-selector.html is stale; regenerate: "
|
||||
"uv run brain.py html --out assets/brain-selector.html"
|
||||
)
|
||||
@@ -1,214 +0,0 @@
|
||||
# Step 1: Session Setup and Continuation Detection
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- ✅ ALWAYS treat this as collaborative facilitation
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on session setup and continuation detection only
|
||||
- 🚪 DETECT existing workflow state and handle continuation properly
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the `communication_language`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- 💾 Initialize document and update frontmatter
|
||||
- 📖 Set up frontmatter `stepsCompleted: [1]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until setup is complete
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Variables from workflow.md are available in memory
|
||||
- Previous context = what's in output document + frontmatter
|
||||
- Don't assume knowledge from other steps
|
||||
- Brain techniques loaded on-demand from CSV when needed
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Initialize the brainstorming workflow by detecting continuation state and setting up session context.
|
||||
|
||||
## INITIALIZATION SEQUENCE:
|
||||
|
||||
### 1. Check for Existing Sessions
|
||||
|
||||
First, check the brainstorming sessions folder for existing sessions:
|
||||
|
||||
- List all files in `{output_folder}/brainstorming/`
|
||||
- **DO NOT read any file contents** - only list filenames
|
||||
- If files exist, identify the most recent by date/time in the filename
|
||||
- If no files exist, this is a fresh workflow
|
||||
|
||||
### 2. Handle Existing Sessions (If Files Found)
|
||||
|
||||
If existing session files are found:
|
||||
|
||||
- Display the most recent session filename (do NOT read its content)
|
||||
- Ask the user: "Found existing session: `[filename]`. Would you like to:
|
||||
**[1]** Continue this session
|
||||
**[2]** Start a new session
|
||||
**[3]** See all existing sessions"
|
||||
|
||||
**HALT — wait for user selection before proceeding.**
|
||||
|
||||
- If user selects **[1]** (continue): Set `{brainstorming_session_output_file}` to that file path and load `./step-01b-continue.md`
|
||||
- If user selects **[2]** (new): Generate new filename with current date/time and proceed to step 3
|
||||
- If user selects **[3]** (see all): List all session filenames and ask which to continue or if new
|
||||
|
||||
### 3. Fresh Workflow Setup (If No Files or User Chooses New)
|
||||
|
||||
If no document exists or no `stepsCompleted` in frontmatter:
|
||||
|
||||
#### A. Initialize Document
|
||||
|
||||
Create the brainstorming session document:
|
||||
|
||||
```bash
|
||||
# Create directory if needed
|
||||
mkdir -p "$(dirname "{brainstorming_session_output_file}")"
|
||||
|
||||
# Initialize from template
|
||||
cp "../template.md" "{brainstorming_session_output_file}"
|
||||
```
|
||||
|
||||
#### B. Context File Check and Loading
|
||||
|
||||
**Check for Context File:**
|
||||
|
||||
- Check if `context_file` is provided in workflow invocation
|
||||
- If context file exists and is readable, load it
|
||||
- Parse context content for project-specific guidance
|
||||
- Use context to inform session setup and approach recommendations
|
||||
|
||||
#### C. Session Context Gathering
|
||||
|
||||
"Welcome {{user_name}}! I'm excited to facilitate your brainstorming session. I'll guide you through proven creativity techniques to generate innovative ideas and breakthrough solutions.
|
||||
|
||||
**Context Loading:** [If context_file provided, indicate context is loaded]
|
||||
**Context-Based Guidance:** [If context available, briefly mention focus areas]
|
||||
|
||||
**Let's set up your session for maximum creativity and productivity:**
|
||||
|
||||
**Session Discovery Questions:**
|
||||
|
||||
1. **What are we brainstorming about?** (The central topic or challenge)
|
||||
2. **What specific outcomes are you hoping for?** (Types of ideas, solutions, or insights)"
|
||||
|
||||
#### D. Process User Responses
|
||||
|
||||
Wait for user responses, then:
|
||||
|
||||
**Session Analysis:**
|
||||
"Based on your responses, I understand we're focusing on **[summarized topic]** with goals around **[summarized objectives]**.
|
||||
|
||||
**Session Parameters:**
|
||||
|
||||
- **Topic Focus:** [Clear topic articulation]
|
||||
- **Primary Goals:** [Specific outcome objectives]
|
||||
|
||||
**Does this accurately capture what you want to achieve?**"
|
||||
|
||||
#### E. Update Frontmatter and Document
|
||||
|
||||
Update the document frontmatter:
|
||||
|
||||
```yaml
|
||||
---
|
||||
stepsCompleted: [1]
|
||||
inputDocuments: []
|
||||
session_topic: '[session_topic]'
|
||||
session_goals: '[session_goals]'
|
||||
selected_approach: ''
|
||||
techniques_used: []
|
||||
ideas_generated: []
|
||||
context_file: '[context_file if provided]'
|
||||
---
|
||||
```
|
||||
|
||||
Append to document:
|
||||
|
||||
```markdown
|
||||
## Session Overview
|
||||
|
||||
**Topic:** [session_topic]
|
||||
**Goals:** [session_goals]
|
||||
|
||||
### Context Guidance
|
||||
|
||||
_[If context file provided, summarize key context and focus areas]_
|
||||
|
||||
### Session Setup
|
||||
|
||||
_[Content based on conversation about session parameters and facilitator approach]_
|
||||
```
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects approach, append the session overview content directly to `{brainstorming_session_output_file}` using the structure from above.
|
||||
|
||||
### E. Continue to Technique Selection
|
||||
|
||||
"**Session setup complete!** I have a clear understanding of your goals and can select the perfect techniques for your brainstorming needs.
|
||||
|
||||
**Ready to explore technique approaches?**
|
||||
[1] User-Selected Techniques - Browse our complete technique library
|
||||
[2] AI-Recommended Techniques - Get customized suggestions based on your goals
|
||||
[3] Random Technique Selection - Discover unexpected creative methods
|
||||
[4] Progressive Technique Flow - Start broad, then systematically narrow focus
|
||||
|
||||
Which approach appeals to you most? (Enter 1-4)"
|
||||
|
||||
**HALT — wait for user selection before proceeding.**
|
||||
|
||||
### 4. Handle User Selection and Initial Document Append
|
||||
|
||||
#### When user selects approach number:
|
||||
|
||||
- **Append initial session overview to `{brainstorming_session_output_file}`**
|
||||
- **Update frontmatter:** `stepsCompleted: [1]`, `selected_approach: '[selected approach]'`
|
||||
- **Load the appropriate step-02 file** based on selection
|
||||
|
||||
### 5. Handle User Selection
|
||||
|
||||
After user selects approach number:
|
||||
|
||||
- **If 1:** Load `./step-02a-user-selected.md`
|
||||
- **If 2:** Load `./step-02b-ai-recommended.md`
|
||||
- **If 3:** Load `./step-02c-random-selection.md`
|
||||
- **If 4:** Load `./step-02d-progressive-flow.md`
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Existing sessions detected without reading file contents
|
||||
✅ User prompted to continue existing session or start new
|
||||
✅ Correct session file selected for continuation
|
||||
✅ Fresh workflow initialized with correct document structure
|
||||
✅ Session context gathered and understood clearly
|
||||
✅ User's approach selection captured and routed correctly
|
||||
✅ Frontmatter properly updated with session state
|
||||
✅ Document initialized with session overview section
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Reading file contents during session detection (wastes context)
|
||||
❌ Not asking user before continuing existing session
|
||||
❌ Not properly routing user's continue/new session selection
|
||||
❌ Missing continuation detection leading to duplicate work
|
||||
❌ Insufficient session context gathering
|
||||
❌ Not properly routing user's approach selection
|
||||
❌ Frontmatter not updated with session parameters
|
||||
|
||||
## SESSION SETUP PROTOCOLS:
|
||||
|
||||
- Always list sessions folder WITHOUT reading file contents
|
||||
- Ask user before continuing any existing session
|
||||
- Only load continue step after user confirms
|
||||
- Load brain techniques CSV only when needed for technique presentation
|
||||
- Use collaborative facilitation language throughout
|
||||
- Maintain psychological safety for creative exploration
|
||||
- Clear next-step routing based on user preferences
|
||||
|
||||
## NEXT STEPS:
|
||||
|
||||
Based on user's approach selection, load the appropriate step-02 file for technique selection and facilitation.
|
||||
|
||||
Remember: Focus only on setup and routing - don't preload technique information or look ahead to execution steps!
|
||||
@@ -1,124 +0,0 @@
|
||||
# Step 1b: Workflow Continuation
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- ✅ YOU ARE A CONTINUATION FACILITATOR, not a fresh starter
|
||||
- 🎯 RESPECT EXISTING WORKFLOW state and progress
|
||||
- 📋 UNDERSTAND PREVIOUS SESSION context and outcomes
|
||||
- 🔍 SEAMLESSLY RESUME from where user left off
|
||||
- 💬 MAINTAIN CONTINUITY in session flow and rapport
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the `communication_language`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load and analyze existing document thoroughly
|
||||
- 💾 Update frontmatter with continuation state
|
||||
- 📖 Present current status and next options clearly
|
||||
- 🚫 FORBIDDEN repeating completed work or asking same questions
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Existing document with frontmatter is available
|
||||
- Previous steps completed indicate session progress
|
||||
- Brain techniques CSV loaded when needed for remaining steps
|
||||
- User may want to continue, modify, or restart
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Analyze existing brainstorming session state and provide seamless continuation options.
|
||||
|
||||
## CONTINUATION SEQUENCE:
|
||||
|
||||
### 1. Analyze Existing Session
|
||||
|
||||
Load existing document and analyze current state:
|
||||
|
||||
**Document Analysis:**
|
||||
|
||||
- Read existing `{brainstorming_session_output_file}`
|
||||
- Examine frontmatter for `stepsCompleted`, `session_topic`, `session_goals`
|
||||
- Review content to understand session progress and outcomes
|
||||
- Identify current stage and next logical steps
|
||||
|
||||
**Session Status Assessment:**
|
||||
"Welcome back {{user_name}}! I can see your brainstorming session on **[session_topic]** from **[date]**.
|
||||
|
||||
**Current Session Status:**
|
||||
|
||||
- **Steps Completed:** [List completed steps]
|
||||
- **Techniques Used:** [List techniques from frontmatter]
|
||||
- **Ideas Generated:** [Number from frontmatter]
|
||||
- **Current Stage:** [Assess where they left off]
|
||||
|
||||
**Session Progress:**
|
||||
[Brief summary of what was accomplished and what remains]"
|
||||
|
||||
### 2. Present Continuation Options
|
||||
|
||||
Based on session analysis, provide appropriate options:
|
||||
|
||||
**If Session Completed:**
|
||||
"Your brainstorming session appears to be complete!
|
||||
|
||||
**Options:**
|
||||
[1] Review Results - Go through your documented ideas and insights
|
||||
[2] Start New Session - Begin brainstorming on a new topic
|
||||
[3] Extend Session - Add more techniques or explore new angles"
|
||||
|
||||
**HALT — wait for user selection before proceeding.**
|
||||
|
||||
**If Session In Progress:**
|
||||
"Let's continue where we left off!
|
||||
|
||||
**Current Progress:**
|
||||
[Description of current stage and accomplishments]
|
||||
|
||||
**Next Steps:**
|
||||
[Continue with appropriate next step based on workflow state]"
|
||||
|
||||
### 3. Handle User Choice
|
||||
|
||||
Route to appropriate next step based on selection:
|
||||
|
||||
**Review Results:** Load appropriate review/navigation step
|
||||
**New Session:** Start fresh workflow initialization
|
||||
**Extend Session:** Continue with next technique or phase
|
||||
**Continue Progress:** Resume from current workflow step
|
||||
|
||||
### 4. Update Session State
|
||||
|
||||
Update frontmatter to reflect continuation:
|
||||
|
||||
```yaml
|
||||
---
|
||||
stepsCompleted: [existing_steps]
|
||||
session_continued: true
|
||||
continuation_date: { { current_date } }
|
||||
---
|
||||
```
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Existing session state accurately analyzed and understood
|
||||
✅ Seamless continuation without loss of context or rapport
|
||||
✅ Appropriate continuation options presented based on progress
|
||||
✅ User choice properly routed to next workflow step
|
||||
✅ Session continuity maintained throughout interaction
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Not properly analyzing existing document state
|
||||
❌ Asking user to repeat information already provided
|
||||
❌ Losing continuity in session flow or context
|
||||
❌ Not providing appropriate continuation options
|
||||
|
||||
## CONTINUATION PROTOCOLS:
|
||||
|
||||
- Always acknowledge previous work and progress
|
||||
- Maintain established rapport and session dynamics
|
||||
- Build upon existing ideas and insights rather than starting over
|
||||
- Respect user's time by avoiding repetitive questions
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
Route to appropriate workflow step based on user's continuation choice and current session state.
|
||||
@@ -1,229 +0,0 @@
|
||||
# Step 2a: User-Selected Techniques
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- ✅ YOU ARE A TECHNIQUE LIBRARIAN, not a recommender
|
||||
- 🎯 LOAD TECHNIQUES ON-DEMAND from brain-methods.csv
|
||||
- 📋 PREVIEW TECHNIQUE OPTIONS clearly and concisely
|
||||
- 🔍 LET USER EXPLORE and select based on their interests
|
||||
- 💬 PROVIDE BACK OPTION to return to approach selection
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the `communication_language`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load brain techniques CSV only when needed for presentation
|
||||
- ⚠️ Present [B] back option and [C] continue options
|
||||
- 💾 Update frontmatter with selected techniques
|
||||
- 📖 Route to technique execution after confirmation
|
||||
- 🚫 FORBIDDEN making recommendations or steering choices
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Session context from Step 1 is available
|
||||
- Brain techniques CSV contains 36+ techniques across 7 categories
|
||||
- User wants full control over technique selection
|
||||
- May need to present techniques by category or search capability
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Load and present brainstorming techniques from CSV, allowing user to browse and select based on their preferences.
|
||||
|
||||
## USER SELECTION SEQUENCE:
|
||||
|
||||
### 1. Load Brain Techniques Library
|
||||
|
||||
Load techniques from CSV on-demand:
|
||||
|
||||
"Perfect! Let's explore our complete brainstorming techniques library. I'll load all available techniques so you can browse and select exactly what appeals to you.
|
||||
|
||||
**Loading Brain Techniques Library...**"
|
||||
|
||||
**Load CSV and parse:**
|
||||
|
||||
- Read `../brain-methods.csv`
|
||||
- Parse: category, technique_name, description, facilitation_prompts, best_for, energy_level, typical_duration
|
||||
- Organize by categories for browsing
|
||||
|
||||
### 2. Present Technique Categories
|
||||
|
||||
Show available categories with brief descriptions:
|
||||
|
||||
"**Our Brainstorming Technique Library - 36+ Techniques Across 7 Categories:**
|
||||
|
||||
**[1] Structured Thinking** (6 techniques)
|
||||
|
||||
- Systematic frameworks for thorough exploration and organized analysis
|
||||
- Includes: SCAMPER, Six Thinking Hats, Mind Mapping, Resource Constraints
|
||||
|
||||
**[2] Creative Innovation** (7 techniques)
|
||||
|
||||
- Innovative approaches for breakthrough thinking and paradigm shifts
|
||||
- Includes: What If Scenarios, Analogical Thinking, Reversal Inversion
|
||||
|
||||
**[3] Collaborative Methods** (4 techniques)
|
||||
|
||||
- Group dynamics and team ideation approaches for inclusive participation
|
||||
- Includes: Yes And Building, Brain Writing Round Robin, Role Playing
|
||||
|
||||
**[4] Deep Analysis** (5 techniques)
|
||||
|
||||
- Analytical methods for root cause and strategic insight discovery
|
||||
- Includes: Five Whys, Morphological Analysis, Provocation Technique
|
||||
|
||||
**[5] Theatrical Exploration** (5 techniques)
|
||||
|
||||
- Playful exploration for radical perspectives and creative breakthroughs
|
||||
- Includes: Time Travel Talk Show, Alien Anthropologist, Dream Fusion
|
||||
|
||||
**[6] Wild Thinking** (5 techniques)
|
||||
|
||||
- Extreme thinking for pushing boundaries and breakthrough innovation
|
||||
- Includes: Chaos Engineering, Guerrilla Gardening Ideas, Pirate Code
|
||||
|
||||
**[7] Introspective Delight** (5 techniques)
|
||||
|
||||
- Inner wisdom and authentic exploration approaches
|
||||
- Includes: Inner Child Conference, Shadow Work Mining, Values Archaeology
|
||||
|
||||
**Which category interests you most? Enter 1-7, or tell me what type of thinking you're drawn to.**"
|
||||
|
||||
**HALT — wait for user selection before proceeding.**
|
||||
|
||||
### 3. Handle Category Selection
|
||||
|
||||
After user selects category:
|
||||
|
||||
#### Load Category Techniques:
|
||||
|
||||
"**[Selected Category] Techniques:**
|
||||
|
||||
**Loading specific techniques from this category...**"
|
||||
|
||||
**Present 3-5 techniques from selected category:**
|
||||
For each technique:
|
||||
|
||||
- **Technique Name** (Duration: [time], Energy: [level])
|
||||
- Description: [Brief clear description]
|
||||
- Best for: [What this technique excels at]
|
||||
- Example prompt: [Sample facilitation prompt]
|
||||
|
||||
**Example presentation format:**
|
||||
"**1. SCAMPER Method** (Duration: 20-30 min, Energy: Moderate)
|
||||
|
||||
- Systematic creativity through seven lenses (Substitute/Combine/Adapt/Modify/Put/Eliminate/Reverse)
|
||||
- Best for: Product improvement, innovation challenges, systematic idea generation
|
||||
- Example prompt: "What could you substitute in your current approach to create something new?"
|
||||
|
||||
**2. Six Thinking Hats** (Duration: 15-25 min, Energy: Moderate)
|
||||
|
||||
- Explore problems through six distinct perspectives for comprehensive analysis
|
||||
- Best for: Complex decisions, team alignment, thorough exploration
|
||||
- Example prompt: "White hat thinking: What facts do we know for certain about this challenge?"
|
||||
|
||||
### 4. Allow Technique Selection
|
||||
|
||||
"**Which techniques from this category appeal to you?**
|
||||
|
||||
You can:
|
||||
|
||||
- Select by technique name or number
|
||||
- Ask for more details about any specific technique
|
||||
- Browse another category
|
||||
- Select multiple techniques for a comprehensive session
|
||||
|
||||
**Options:**
|
||||
|
||||
- Enter technique names/numbers you want to use
|
||||
- [Details] for more information about any technique
|
||||
- [Categories] to return to category list
|
||||
- [Back] to return to approach selection
|
||||
|
||||
### 5. Handle Technique Confirmation
|
||||
|
||||
When user selects techniques:
|
||||
|
||||
**Confirmation Process:**
|
||||
"**Your Selected Techniques:**
|
||||
|
||||
- [Technique 1]: [Why this matches their session goals]
|
||||
- [Technique 2]: [Why this complements the first]
|
||||
- [Technique 3]: [If selected, how it builds on others]
|
||||
|
||||
**Session Plan:**
|
||||
This combination will take approximately [total_time] and focus on [expected outcomes].
|
||||
|
||||
**Confirm these choices?**
|
||||
[C] Continue - Begin technique execution
|
||||
[Back] - Modify technique selection"
|
||||
|
||||
**HALT — wait for user selection before proceeding.**
|
||||
|
||||
### 6. Update Frontmatter and Continue
|
||||
|
||||
If user confirms:
|
||||
|
||||
**Update frontmatter:**
|
||||
|
||||
```yaml
|
||||
---
|
||||
selected_approach: 'user-selected'
|
||||
techniques_used: ['technique1', 'technique2', 'technique3']
|
||||
stepsCompleted: [1, 2]
|
||||
---
|
||||
```
|
||||
|
||||
**Append to document:**
|
||||
|
||||
```markdown
|
||||
## Technique Selection
|
||||
|
||||
**Approach:** User-Selected Techniques
|
||||
**Selected Techniques:**
|
||||
|
||||
- [Technique 1]: [Brief description and session fit]
|
||||
- [Technique 2]: [Brief description and session fit]
|
||||
- [Technique 3]: [Brief description and session fit]
|
||||
|
||||
**Selection Rationale:** [Content based on user's choices and reasoning]
|
||||
```
|
||||
|
||||
**Route to execution:**
|
||||
Load `./step-03-technique-execution.md`
|
||||
|
||||
### 7. Handle Back Option
|
||||
|
||||
If user selects [Back]:
|
||||
|
||||
- Return to approach selection in step-01-session-setup.md
|
||||
- Maintain session context and preferences
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Brain techniques CSV loaded successfully on-demand
|
||||
✅ Technique categories presented clearly with helpful descriptions
|
||||
✅ User able to browse and select techniques based on interests
|
||||
✅ Selected techniques confirmed with session fit explanation
|
||||
✅ Frontmatter updated with technique selections
|
||||
✅ Proper routing to technique execution or back navigation
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Preloading all techniques instead of loading on-demand
|
||||
❌ Making recommendations instead of letting user explore
|
||||
❌ Not providing enough detail for informed selection
|
||||
❌ Missing back navigation option
|
||||
❌ Not updating frontmatter with technique selections
|
||||
|
||||
## USER SELECTION PROTOCOLS:
|
||||
|
||||
- Present techniques neutrally without steering or preference
|
||||
- Load CSV data only when needed for category/technique presentation
|
||||
- Provide sufficient detail for informed choices without overwhelming
|
||||
- Always maintain option to return to previous steps
|
||||
- Respect user's autonomy in technique selection
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After technique confirmation, load `./step-03-technique-execution.md` to begin facilitating the selected brainstorming techniques.
|
||||
|
||||
Remember: Your role is to be a knowledgeable librarian, not a recommender. Let the user explore and choose based on their interests and intuition!
|
||||
@@ -1,239 +0,0 @@
|
||||
# Step 2b: AI-Recommended Techniques
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- ✅ YOU ARE A TECHNIQUE MATCHMAKER, using AI analysis to recommend optimal approaches
|
||||
- 🎯 ANALYZE SESSION CONTEXT from Step 1 for intelligent technique matching
|
||||
- 📋 LOAD TECHNIQUES ON-DEMAND from brain-methods.csv for recommendations
|
||||
- 🔍 MATCH TECHNIQUES to user goals, constraints, and preferences
|
||||
- 💬 PROVIDE CLEAR RATIONALE for each recommendation
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the `communication_language`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load brain techniques CSV only when needed for analysis
|
||||
- ⚠️ Present [B] back option and [C] continue options
|
||||
- 💾 Update frontmatter with recommended techniques
|
||||
- 📖 Route to technique execution after user confirmation
|
||||
- 🚫 FORBIDDEN generic recommendations without context analysis
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Session context (`session_topic`, `session_goals`, constraints) from Step 1
|
||||
- Brain techniques CSV with 36+ techniques across 7 categories
|
||||
- User wants expert guidance in technique selection
|
||||
- Must analyze multiple factors for optimal matching
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Analyze session context and recommend optimal brainstorming techniques based on user's specific goals and constraints.
|
||||
|
||||
## AI RECOMMENDATION SEQUENCE:
|
||||
|
||||
### 1. Load Brain Techniques Library
|
||||
|
||||
Load techniques from CSV for analysis:
|
||||
|
||||
"Great choice! Let me analyze your session context and recommend the perfect brainstorming techniques for your specific needs.
|
||||
|
||||
**Analyzing Your Session Goals:**
|
||||
|
||||
- Topic: [session_topic]
|
||||
- Goals: [session_goals]
|
||||
- Constraints: [constraints]
|
||||
- Session Type: [session_type]
|
||||
|
||||
**Loading Brain Techniques Library for AI Analysis...**"
|
||||
|
||||
**Load CSV and parse:**
|
||||
|
||||
- Read `../brain-methods.csv`
|
||||
- Parse: category, technique_name, description, facilitation_prompts, best_for, energy_level, typical_duration
|
||||
|
||||
### 2. Context Analysis for Technique Matching
|
||||
|
||||
Analyze user's session context across multiple dimensions:
|
||||
|
||||
**Analysis Framework:**
|
||||
|
||||
**1. Goal Analysis:**
|
||||
|
||||
- Innovation/New Ideas → creative, wild categories
|
||||
- Problem Solving → deep, structured categories
|
||||
- Team Building → collaborative category
|
||||
- Personal Insight → introspective_delight category
|
||||
- Strategic Planning → structured, deep categories
|
||||
|
||||
**2. Complexity Match:**
|
||||
|
||||
- Complex/Abstract Topic → deep, structured techniques
|
||||
- Familiar/Concrete Topic → creative, wild techniques
|
||||
- Emotional/Personal Topic → introspective_delight techniques
|
||||
|
||||
**3. Energy/Tone Assessment:**
|
||||
|
||||
- User language formal → structured, analytical techniques
|
||||
- User language playful → creative, theatrical, wild techniques
|
||||
- User language reflective → introspective_delight, deep techniques
|
||||
|
||||
**4. Time Available:**
|
||||
|
||||
- <30 min → 1-2 focused techniques
|
||||
- 30-60 min → 2-3 complementary techniques
|
||||
- > 60 min → Multi-phase technique flow
|
||||
|
||||
### 3. Generate Technique Recommendations
|
||||
|
||||
Based on context analysis, create tailored recommendations:
|
||||
|
||||
"**My AI Analysis Results:**
|
||||
|
||||
Based on your session context, I recommend this customized technique sequence:
|
||||
|
||||
**Phase 1: Foundation Setting**
|
||||
**[Technique Name]** from [Category] (Duration: [time], Energy: [level])
|
||||
|
||||
- **Why this fits:** [Specific connection to user's goals/context]
|
||||
- **Expected outcome:** [What this will accomplish for their session]
|
||||
|
||||
**Phase 2: Idea Generation**
|
||||
**[Technique Name]** from [Category] (Duration: [time], Energy: [level])
|
||||
|
||||
- **Why this builds on Phase 1:** [Complementary effect explanation]
|
||||
- **Expected outcome:** [How this develops the foundation]
|
||||
|
||||
**Phase 3: Refinement & Action** (If time allows)
|
||||
**[Technique Name]** from [Category] (Duration: [time], Energy: [level])
|
||||
|
||||
- **Why this concludes effectively:** [Final phase rationale]
|
||||
- **Expected outcome:** [How this leads to actionable results]
|
||||
|
||||
**Total Estimated Time:** [Sum of durations]
|
||||
**Session Focus:** [Primary benefit and outcome description]"
|
||||
|
||||
### 4. Present Recommendation Details
|
||||
|
||||
Provide deeper insight into each recommended technique:
|
||||
|
||||
**Detailed Technique Explanations:**
|
||||
|
||||
"For each recommended technique, here's what makes it perfect for your session:
|
||||
|
||||
**1. [Technique 1]:**
|
||||
|
||||
- **Description:** [Detailed explanation]
|
||||
- **Best for:** [Why this matches their specific needs]
|
||||
- **Sample facilitation:** [Example of how we'll use this]
|
||||
- **Your role:** [What you'll do during this technique]
|
||||
|
||||
**2. [Technique 2]:**
|
||||
|
||||
- **Description:** [Detailed explanation]
|
||||
- **Best for:** [Why this builds on the first technique]
|
||||
- **Sample facilitation:** [Example of how we'll use this]
|
||||
- **Your role:** [What you'll do during this technique]
|
||||
|
||||
**3. [Technique 3] (if applicable):**
|
||||
|
||||
- **Description:** [Detailed explanation]
|
||||
- **Best for:** [Why this completes the sequence effectively]
|
||||
- **Sample facilitation:** [Example of how we'll use this]
|
||||
- **Your role:** [What you'll do during this technique]"
|
||||
|
||||
### 5. Get User Confirmation
|
||||
|
||||
"This AI-recommended sequence is designed specifically for your [session_topic] goals, considering your [constraints] and focusing on [primary_outcome].
|
||||
|
||||
**Does this approach sound perfect for your session?**
|
||||
|
||||
**Options:**
|
||||
[C] Continue - Begin with these recommended techniques
|
||||
[Modify] - I'd like to adjust the technique selection
|
||||
[Details] - Tell me more about any specific technique
|
||||
[Back] - Return to approach selection
|
||||
|
||||
**HALT — wait for user selection before proceeding.**
|
||||
|
||||
### 6. Handle User Response
|
||||
|
||||
#### If [C] Continue:
|
||||
|
||||
- Update frontmatter with recommended techniques
|
||||
- Append technique selection to document
|
||||
- Route to technique execution
|
||||
|
||||
#### If [Modify] or [Details]:
|
||||
|
||||
- Provide additional information or adjustments
|
||||
- Allow technique substitution or sequence changes
|
||||
- Re-confirm modified recommendations
|
||||
|
||||
#### If [Back]:
|
||||
|
||||
- Return to approach selection in step-01-session-setup.md
|
||||
- Maintain session context and preferences
|
||||
|
||||
### 7. Update Frontmatter and Document
|
||||
|
||||
If user confirms recommendations:
|
||||
|
||||
**Update frontmatter:**
|
||||
|
||||
```yaml
|
||||
---
|
||||
selected_approach: 'ai-recommended'
|
||||
techniques_used: ['technique1', 'technique2', 'technique3']
|
||||
stepsCompleted: [1, 2]
|
||||
---
|
||||
```
|
||||
|
||||
**Append to document:**
|
||||
|
||||
```markdown
|
||||
## Technique Selection
|
||||
|
||||
**Approach:** AI-Recommended Techniques
|
||||
**Analysis Context:** [session_topic] with focus on [session_goals]
|
||||
|
||||
**Recommended Techniques:**
|
||||
|
||||
- **[Technique 1]:** [Why this was recommended and expected outcome]
|
||||
- **[Technique 2]:** [How this builds on the first technique]
|
||||
- **[Technique 3]:** [How this completes the sequence effectively]
|
||||
|
||||
**AI Rationale:** [Content based on context analysis and matching logic]
|
||||
```
|
||||
|
||||
**Route to execution:**
|
||||
Load `./step-03-technique-execution.md`
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Session context analyzed thoroughly across multiple dimensions
|
||||
✅ Technique recommendations clearly matched to user's specific needs
|
||||
✅ Detailed explanations provided for each recommended technique
|
||||
✅ User confirmation obtained before proceeding to execution
|
||||
✅ Frontmatter updated with AI-recommended techniques
|
||||
✅ Proper routing to technique execution or back navigation
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Generic recommendations without specific context analysis
|
||||
❌ Not explaining rationale behind technique selections
|
||||
❌ Missing option for user to modify or question recommendations
|
||||
❌ Not loading techniques from CSV for accurate recommendations
|
||||
❌ Not updating frontmatter with selected techniques
|
||||
|
||||
## AI RECOMMENDATION PROTOCOLS:
|
||||
|
||||
- Analyze session context systematically across multiple factors
|
||||
- Provide clear rationale linking recommendations to user's goals
|
||||
- Allow user input and modification of recommendations
|
||||
- Load accurate technique data from CSV for informed analysis
|
||||
- Balance expertise with user autonomy in final selection
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user confirmation, load `./step-03-technique-execution.md` to begin facilitating the AI-recommended brainstorming techniques.
|
||||
|
||||
Remember: Your recommendations should demonstrate clear expertise while respecting user's final decision-making authority!
|
||||
@@ -1,211 +0,0 @@
|
||||
# Step 2c: Random Technique Selection
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- ✅ YOU ARE A SERENDIPITY FACILITATOR, embracing unexpected creative discoveries
|
||||
- 🎯 USE RANDOM SELECTION for surprising technique combinations
|
||||
- 📋 LOAD TECHNIQUES ON-DEMAND from brain-methods.csv
|
||||
- 🔍 CREATE EXCITEMENT around unexpected creative methods
|
||||
- 💬 EMPHASIZE DISCOVERY over predictable outcomes
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the `communication_language`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load brain techniques CSV only when needed for random selection
|
||||
- ⚠️ Present [B] back option and [C] continue options
|
||||
- 💾 Update frontmatter with randomly selected techniques
|
||||
- 📖 Route to technique execution after user confirmation
|
||||
- 🚫 FORBIDDEN steering random selections or second-guessing outcomes
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Session context from Step 1 available for basic filtering
|
||||
- Brain techniques CSV with 36+ techniques across 7 categories
|
||||
- User wants surprise and unexpected creative methods
|
||||
- Randomness should create complementary, not contradictory, combinations
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Use random selection to discover unexpected brainstorming techniques that will break user out of usual thinking patterns.
|
||||
|
||||
## RANDOM SELECTION SEQUENCE:
|
||||
|
||||
### 1. Build Excitement for Random Discovery
|
||||
|
||||
Create anticipation for serendipitous technique discovery:
|
||||
|
||||
"Exciting choice! You've chosen the path of creative serendipity. Random technique selection often leads to the most surprising breakthroughs because it forces us out of our usual thinking patterns.
|
||||
|
||||
**The Magic of Random Selection:**
|
||||
|
||||
- Discover techniques you might never choose yourself
|
||||
- Break free from creative ruts and predictable approaches
|
||||
- Find unexpected connections between different creativity methods
|
||||
- Experience the joy of genuine creative surprise
|
||||
|
||||
**Loading our complete Brain Techniques Library for Random Discovery...**"
|
||||
|
||||
**Load CSV and parse:**
|
||||
|
||||
- Read `../brain-methods.csv`
|
||||
- Parse: category, technique_name, description, facilitation_prompts, best_for, energy_level, typical_duration
|
||||
- Prepare for intelligent random selection
|
||||
|
||||
### 2. Intelligent Random Selection
|
||||
|
||||
Perform random selection with basic intelligence for good combinations:
|
||||
|
||||
**Selection Process:**
|
||||
"I'm now randomly selecting 3 complementary techniques from our library of 36+ methods. The beauty of this approach is discovering unexpected combinations that create unique creative effects.
|
||||
|
||||
**Randomizing Technique Selection...**"
|
||||
|
||||
**Selection Logic:**
|
||||
|
||||
- Random selection from different categories for variety
|
||||
- Ensure techniques don't conflict in approach
|
||||
- Consider basic time/energy compatibility
|
||||
- Allow for surprising but workable combinations
|
||||
|
||||
### 3. Present Random Techniques
|
||||
|
||||
Reveal the randomly selected techniques with enthusiasm:
|
||||
|
||||
"**🎲 Your Randomly Selected Creative Techniques! 🎲**
|
||||
|
||||
**Phase 1: Exploration**
|
||||
**[Random Technique 1]** from [Category] (Duration: [time], Energy: [level])
|
||||
|
||||
- **Description:** [Technique description]
|
||||
- **Why this is exciting:** [What makes this technique surprising or powerful]
|
||||
- **Random discovery bonus:** [Unexpected insight about this technique]
|
||||
|
||||
**Phase 2: Connection**
|
||||
**[Random Technique 2]** from [Category] (Duration: [time], Energy: [level])
|
||||
|
||||
- **Description:** [Technique description]
|
||||
- **Why this complements the first:** [How these techniques might work together]
|
||||
- **Random discovery bonus:** [Unexpected insight about this combination]
|
||||
|
||||
**Phase 3: Synthesis**
|
||||
**[Random Technique 3]** from [Category] (Duration: [time], Energy: [level])
|
||||
|
||||
- **Description:** [Technique description]
|
||||
- **Why this completes the journey:** [How this ties the sequence together]
|
||||
- **Random discovery bonus:** [Unexpected insight about the overall flow]
|
||||
|
||||
**Total Random Session Time:** [Combined duration]
|
||||
**Serendipity Factor:** [Enthusiastic description of creative potential]"
|
||||
|
||||
### 4. Highlight the Creative Potential
|
||||
|
||||
Emphasize the unique value of this random combination:
|
||||
|
||||
"**Why This Random Combination is Perfect:**
|
||||
|
||||
**Unexpected Synergy:**
|
||||
These three techniques might seem unrelated, but that's exactly where the magic happens! [Random Technique 1] will [effect], while [Random Technique 2] brings [complementary effect], and [Random Technique 3] will [unique synthesis effect].
|
||||
|
||||
**Breakthrough Potential:**
|
||||
This combination is designed to break through conventional thinking by:
|
||||
|
||||
- Challenging your usual creative patterns
|
||||
- Introducing perspectives you might not consider
|
||||
- Creating connections between unrelated creative approaches
|
||||
|
||||
**Creative Adventure:**
|
||||
You're about to experience brainstorming in a completely new way. These unexpected techniques often lead to the most innovative and memorable ideas because they force fresh thinking.
|
||||
|
||||
**Ready for this creative adventure?**
|
||||
|
||||
**Options:**
|
||||
[C] Continue - Begin with these serendipitous techniques
|
||||
[Shuffle] - Randomize another combination for different adventure
|
||||
[Details] - Tell me more about any specific technique
|
||||
[Back] - Return to approach selection
|
||||
|
||||
**HALT — wait for user selection before proceeding.**
|
||||
|
||||
### 5. Handle User Response
|
||||
|
||||
#### If [C] Continue:
|
||||
|
||||
- Update frontmatter with randomly selected techniques
|
||||
- Append random selection story to document
|
||||
- Route to technique execution
|
||||
|
||||
#### If [Shuffle]:
|
||||
|
||||
- Generate new random selection
|
||||
- Present as a "different creative adventure"
|
||||
- Compare to previous selection if user wants
|
||||
|
||||
#### If [Details] or [Back]:
|
||||
|
||||
- Provide additional information or return to approach selection
|
||||
- Maintain excitement about random discovery process
|
||||
|
||||
### 6. Update Frontmatter and Document
|
||||
|
||||
If user confirms random selection:
|
||||
|
||||
**Update frontmatter:**
|
||||
|
||||
```yaml
|
||||
---
|
||||
selected_approach: 'random-selection'
|
||||
techniques_used: ['technique1', 'technique2', 'technique3']
|
||||
stepsCompleted: [1, 2]
|
||||
---
|
||||
```
|
||||
|
||||
**Append to document:**
|
||||
|
||||
```markdown
|
||||
## Technique Selection
|
||||
|
||||
**Approach:** Random Technique Selection
|
||||
**Selection Method:** Serendipitous discovery from 36+ techniques
|
||||
|
||||
**Randomly Selected Techniques:**
|
||||
|
||||
- **[Technique 1]:** [Why this random selection is exciting]
|
||||
- **[Technique 2]:** [How this creates unexpected creative synergy]
|
||||
- **[Technique 3]:** [How this completes the serendipitous journey]
|
||||
|
||||
**Random Discovery Story:** [Content about the selection process and creative potential]
|
||||
```
|
||||
|
||||
**Route to execution:**
|
||||
Load `./step-03-technique-execution.md`
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Random techniques selected with basic intelligence for good combinations
|
||||
✅ Excitement and anticipation built around serendipitous discovery
|
||||
✅ Creative potential of random combination highlighted effectively
|
||||
✅ User enthusiasm maintained throughout selection process
|
||||
✅ Frontmatter updated with randomly selected techniques
|
||||
✅ Option to reshuffle provided for user control
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Random selection creates conflicting or incompatible techniques
|
||||
❌ Not building sufficient excitement around random discovery
|
||||
❌ Missing option for user to reshuffle or get different combination
|
||||
❌ Not explaining the creative value of random combinations
|
||||
❌ Loading techniques from memory instead of CSV
|
||||
|
||||
## RANDOM SELECTION PROTOCOLS:
|
||||
|
||||
- Use true randomness while ensuring basic compatibility
|
||||
- Build enthusiasm for unexpected discoveries and surprises
|
||||
- Emphasize the value of breaking out of usual patterns
|
||||
- Allow user control through reshuffle option
|
||||
- Present random selections as exciting creative adventures
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user confirms, load `./step-03-technique-execution.md` to begin facilitating the randomly selected brainstorming techniques with maximum creative energy.
|
||||
|
||||
Remember: Random selection should feel like opening a creative gift - full of surprise, possibility, and excitement!
|
||||
@@ -1,266 +0,0 @@
|
||||
# Step 2d: Progressive Technique Flow
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- ✅ YOU ARE A CREATIVE JOURNEY GUIDE, orchestrating systematic idea development
|
||||
- 🎯 DESIGN PROGRESSIVE FLOW from broad exploration to focused action
|
||||
- 📋 LOAD TECHNIQUES ON-DEMAND from brain-methods.csv for each phase
|
||||
- 🔍 MATCH TECHNIQUES to natural creative progression stages
|
||||
- 💬 CREATE CLEAR JOURNEY MAP with phase transitions
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the `communication_language`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load brain techniques CSV only when needed for each phase
|
||||
- ⚠️ Present [B] back option and [C] continue options
|
||||
- 💾 Update frontmatter with progressive technique sequence
|
||||
- 📖 Route to technique execution after journey confirmation
|
||||
- 🚫 FORBIDDEN jumping ahead to later phases without proper foundation
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Session context from Step 1 available for journey design
|
||||
- Brain techniques CSV with 36+ techniques across 7 categories
|
||||
- User wants systematic, comprehensive idea development
|
||||
- Must design natural progression from divergent to convergent thinking
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Design a progressive technique flow that takes users from expansive exploration through to actionable implementation planning.
|
||||
|
||||
## PROGRESSIVE FLOW SEQUENCE:
|
||||
|
||||
### 1. Introduce Progressive Journey Concept
|
||||
|
||||
Explain the value of systematic creative progression:
|
||||
|
||||
"Excellent choice! Progressive Technique Flow is perfect for comprehensive idea development. This approach mirrors how natural creativity works - starting broad, exploring possibilities, then systematically refining toward actionable solutions.
|
||||
|
||||
**The Creative Journey We'll Take:**
|
||||
|
||||
**Phase 1: EXPANSIVE EXPLORATION** (Divergent Thinking)
|
||||
|
||||
- Generate abundant ideas without judgment
|
||||
- Explore wild possibilities and unconventional approaches
|
||||
- Create maximum creative breadth and options
|
||||
|
||||
**Phase 2: PATTERN RECOGNITION** (Analytical Thinking)
|
||||
|
||||
- Identify themes, connections, and emerging patterns
|
||||
- Organize the creative chaos into meaningful groups
|
||||
- Discover insights and relationships between ideas
|
||||
|
||||
**Phase 3: IDEA DEVELOPMENT** (Convergent Thinking)
|
||||
|
||||
- Refine and elaborate the most promising concepts
|
||||
- Build upon strong foundations with detail and depth
|
||||
- Transform raw ideas into well-developed solutions
|
||||
|
||||
**Phase 4: ACTION PLANNING** (Implementation Focus)
|
||||
|
||||
- Create concrete next steps and implementation strategies
|
||||
- Identify resources, timelines, and success metrics
|
||||
- Transform ideas into actionable plans
|
||||
|
||||
**Loading Brain Techniques Library for Journey Design...**"
|
||||
|
||||
**Load CSV and parse:**
|
||||
|
||||
- Read `../brain-methods.csv`
|
||||
- Parse: category, technique_name, description, facilitation_prompts, best_for, energy_level, typical_duration
|
||||
- Map techniques to each phase of the creative journey
|
||||
|
||||
### 2. Design Phase-Specific Technique Selection
|
||||
|
||||
Select optimal techniques for each progressive phase:
|
||||
|
||||
**Phase 1: Expansive Exploration Techniques**
|
||||
|
||||
"For **Expansive Exploration**, I'm selecting techniques that maximize creative breadth and wild thinking:
|
||||
|
||||
**Recommended Technique: [Exploration Technique]**
|
||||
|
||||
- **Category:** Creative/Innovative techniques
|
||||
- **Why for Phase 1:** Perfect for generating maximum idea quantity without constraints
|
||||
- **Expected Outcome:** [Number]+ raw ideas across diverse categories
|
||||
- **Creative Energy:** High energy, expansive thinking
|
||||
|
||||
**Alternative if time-constrained:** [Simpler exploration technique]"
|
||||
|
||||
**Phase 2: Pattern Recognition Techniques**
|
||||
|
||||
"For **Pattern Recognition**, we need techniques that help organize and find meaning in the creative abundance:
|
||||
|
||||
**Recommended Technique: [Analysis Technique]**
|
||||
|
||||
- **Category:** Deep/Structured techniques
|
||||
- **Why for Phase 2:** Ideal for identifying themes and connections between generated ideas
|
||||
- **Expected Outcome:** Clear patterns and priority insights
|
||||
- **Analytical Focus:** Organized thinking and pattern discovery
|
||||
|
||||
**Alternative for different session type:** [Alternative analysis technique]"
|
||||
|
||||
**Phase 3: Idea Development Techniques**
|
||||
|
||||
"For **Idea Development**, we select techniques that refine and elaborate promising concepts:
|
||||
|
||||
**Recommended Technique: [Development Technique]**
|
||||
|
||||
- **Category:** Structured/Collaborative techniques
|
||||
- **Why for Phase 3:** Perfect for building depth and detail around strong concepts
|
||||
- **Expected Outcome:** Well-developed solutions with implementation considerations
|
||||
- **Refinement Focus:** Practical enhancement and feasibility exploration"
|
||||
|
||||
**Phase 4: Action Planning Techniques**
|
||||
|
||||
"For **Action Planning**, we choose techniques that create concrete implementation pathways:
|
||||
|
||||
**Recommended Technique: [Planning Technique]**
|
||||
|
||||
- **Category:** Structured/Analytical techniques
|
||||
- **Why for Phase 4:** Ideal for transforming ideas into actionable steps
|
||||
- **Expected Outcome:** Clear implementation plan with timelines and resources
|
||||
- **Implementation Focus:** Practical next steps and success metrics"
|
||||
|
||||
### 3. Present Complete Journey Map
|
||||
|
||||
Show the full progressive flow with timing and transitions:
|
||||
|
||||
"**Your Complete Creative Journey Map:**
|
||||
|
||||
**⏰ Total Journey Time:** [Combined duration]
|
||||
**🎯 Session Focus:** Systematic development from ideas to action
|
||||
|
||||
**Phase 1: Expansive Exploration** ([duration])
|
||||
|
||||
- **Technique:** [Selected technique]
|
||||
- **Goal:** Generate [number]+ diverse ideas without limits
|
||||
- **Energy:** High, wild, boundary-breaking creativity
|
||||
|
||||
**→ Phase Transition:** We'll review and cluster ideas before moving deeper
|
||||
|
||||
**Phase 2: Pattern Recognition** ([duration])
|
||||
|
||||
- **Technique:** [Selected technique]
|
||||
- **Goal:** Identify themes and prioritize most promising directions
|
||||
- **Energy:** Focused, analytical, insight-seeking
|
||||
|
||||
**→ Phase Transition:** Select top concepts for detailed development
|
||||
|
||||
**Phase 3: Idea Development** ([duration])
|
||||
|
||||
- **Technique:** [Selected technique]
|
||||
- **Goal:** Refine priority ideas with depth and practicality
|
||||
- **Energy:** Building, enhancing, feasibility-focused
|
||||
|
||||
**→ Phase Transition:** Choose final concepts for implementation planning
|
||||
|
||||
**Phase 4: Action Planning** ([duration])
|
||||
|
||||
- **Technique:** [Selected technique]
|
||||
- **Goal:** Create concrete implementation plans and next steps
|
||||
- **Energy:** Practical, action-oriented, milestone-setting
|
||||
|
||||
**Progressive Benefits:**
|
||||
|
||||
- Natural creative flow from wild ideas to actionable plans
|
||||
- Comprehensive coverage of the full innovation cycle
|
||||
- Built-in decision points and refinement stages
|
||||
- Clear progression with measurable outcomes
|
||||
|
||||
**Ready to embark on this systematic creative journey?**
|
||||
|
||||
**Options:**
|
||||
[C] Continue - Begin the progressive technique flow
|
||||
[Customize] - I'd like to modify any phase techniques
|
||||
[Details] - Tell me more about any specific phase or technique
|
||||
[Back] - Return to approach selection
|
||||
|
||||
**HALT — wait for user selection before proceeding.**
|
||||
|
||||
### 4. Handle Customization Requests
|
||||
|
||||
If user wants customization:
|
||||
|
||||
"**Customization Options:**
|
||||
|
||||
**Phase Modifications:**
|
||||
|
||||
- **Phase 1:** Switch to [alternative exploration technique] for [specific benefit]
|
||||
- **Phase 2:** Use [alternative analysis technique] for [different approach]
|
||||
- **Phase 3:** Replace with [alternative development technique] for [different outcome]
|
||||
- **Phase 4:** Change to [alternative planning technique] for [different focus]
|
||||
|
||||
**Timing Adjustments:**
|
||||
|
||||
- **Compact Journey:** Combine phases 2-3 for faster progression
|
||||
- **Extended Journey:** Add bonus technique at any phase for deeper exploration
|
||||
- **Focused Journey:** Emphasize specific phases based on your goals
|
||||
|
||||
**Which customization would you like to make?**"
|
||||
|
||||
### 5. Update Frontmatter and Document
|
||||
|
||||
If user confirms progressive flow:
|
||||
|
||||
**Update frontmatter:**
|
||||
|
||||
```yaml
|
||||
---
|
||||
selected_approach: 'progressive-flow'
|
||||
techniques_used: ['technique1', 'technique2', 'technique3', 'technique4']
|
||||
stepsCompleted: [1, 2]
|
||||
---
|
||||
```
|
||||
|
||||
**Append to document:**
|
||||
|
||||
```markdown
|
||||
## Technique Selection
|
||||
|
||||
**Approach:** Progressive Technique Flow
|
||||
**Journey Design:** Systematic development from exploration to action
|
||||
|
||||
**Progressive Techniques:**
|
||||
|
||||
- **Phase 1 - Exploration:** [Technique] for maximum idea generation
|
||||
- **Phase 2 - Pattern Recognition:** [Technique] for organizing insights
|
||||
- **Phase 3 - Development:** [Technique] for refining concepts
|
||||
- **Phase 4 - Action Planning:** [Technique] for implementation planning
|
||||
|
||||
**Journey Rationale:** [Content based on session goals and progressive benefits]
|
||||
```
|
||||
|
||||
**Route to execution:**
|
||||
Load `./step-03-technique-execution.md`
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Progressive flow designed with natural creative progression
|
||||
✅ Each phase matched to appropriate technique type and purpose
|
||||
✅ Clear journey map with timing and transition points
|
||||
✅ Customization options provided for user control
|
||||
✅ Systematic benefits explained clearly
|
||||
✅ Frontmatter updated with complete technique sequence
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Techniques not properly matched to phase purposes
|
||||
❌ Missing clear transitions between journey phases
|
||||
❌ Not explaining the value of systematic progression
|
||||
❌ No customization options for user preferences
|
||||
❌ Techniques don't create natural flow from divergent to convergent
|
||||
|
||||
## PROGRESSIVE FLOW PROTOCOLS:
|
||||
|
||||
- Design natural progression that mirrors real creative processes
|
||||
- Match technique types to specific phase requirements
|
||||
- Create clear decision points and transitions between phases
|
||||
- Allow customization while maintaining systematic benefits
|
||||
- Emphasize comprehensive coverage of innovation cycle
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user confirmation, load `./step-03-technique-execution.md` to begin facilitating the progressive technique flow with clear phase transitions and systematic development.
|
||||
|
||||
Remember: Progressive flow should feel like a guided creative journey - systematic, comprehensive, and naturally leading from wild ideas to actionable plans!
|
||||
@@ -1,401 +0,0 @@
|
||||
# Step 3: Interactive Technique Execution and Facilitation
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- ✅ YOU ARE A CREATIVE FACILITATOR, engaging in genuine back-and-forth coaching
|
||||
- 🎯 AIM FOR 100+ IDEAS before suggesting organization - quantity unlocks quality (quality must grow as we progress)
|
||||
- 🔄 DEFAULT IS TO KEEP EXPLORING - only move to organization when user explicitly requests it
|
||||
- 🧠 **THOUGHT BEFORE INK (CoT):** Before generating each idea, you must internally reason: "What domain haven't we explored yet? What would make this idea surprising or 'uncomfortable' for the user?"
|
||||
- 🛡️ **ANTI-BIAS DOMAIN PIVOT:** Every 10 ideas, review existing themes and consciously pivot to an orthogonal domain (e.g., UX -> Business -> Physics -> Social Impact).
|
||||
- 🌡️ **SIMULATED TEMPERATURE:** Act as if your creativity is set to 0.85 - take wilder leaps and suggest "provocative" concepts.
|
||||
- ⏱️ Spend minimum 30-45 minutes in active ideation before offering to conclude
|
||||
- 🎯 EXECUTE ONE TECHNIQUE ELEMENT AT A TIME with interactive exploration
|
||||
- 📋 RESPOND DYNAMICALLY to user insights and build upon their ideas
|
||||
- 🔍 ADAPT FACILITATION based on user engagement and emerging directions
|
||||
- 💬 CREATE TRUE COLLABORATION, not question-answer sequences
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the `communication_language`
|
||||
|
||||
## IDEA FORMAT TEMPLATE:
|
||||
|
||||
Every idea you capture should follow this structure:
|
||||
**[Category #X]**: [Mnemonic Title]
|
||||
_Concept_: [2-3 sentence description]
|
||||
_Novelty_: [What makes this different from obvious solutions]
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Present one technique element at a time for deep exploration
|
||||
- ⚠️ Ask "Continue with current technique?" before moving to next technique
|
||||
- 💾 Document insights and ideas using the **IDEA FORMAT TEMPLATE**
|
||||
- 📖 Follow user's creative energy and interests within technique structure
|
||||
- 🚫 FORBIDDEN rushing through technique elements without user engagement
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Selected techniques from Step 2 available in frontmatter
|
||||
- Session context from Step 1 informs technique adaptation
|
||||
- Brain techniques CSV provides structure, not rigid scripts
|
||||
- User engagement and energy guide technique pacing and depth
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Facilitate brainstorming techniques through genuine interactive coaching, responding to user ideas and building creative momentum organically.
|
||||
|
||||
## INTERACTIVE FACILITATION SEQUENCE:
|
||||
|
||||
### 1. Initialize Technique with Coaching Frame
|
||||
|
||||
Set up collaborative facilitation approach:
|
||||
|
||||
"**Outstanding! Let's begin our first technique with true collaborative facilitation.**
|
||||
|
||||
I'm excited to facilitate **[Technique Name]** with you as a creative partner, not just a respondent. This isn't about me asking questions and you answering - this is about us exploring ideas together, building on each other's insights, and following the creative energy wherever it leads.
|
||||
|
||||
**My Coaching Approach:**
|
||||
|
||||
- I'll introduce one technique element at a time
|
||||
- We'll explore it together through back-and-forth dialogue
|
||||
- I'll build upon your ideas and help you develop them further
|
||||
- We'll dive deeper into concepts that spark your imagination
|
||||
- You can always say "let's explore this more" before moving on
|
||||
- **You're in control:** At any point, just say "next technique" or "move on" and we'll document current progress and start the next technique
|
||||
|
||||
**Technique Loading: [Technique Name]**
|
||||
**Focus:** [Primary goal of this technique]
|
||||
**Energy:** [High/Reflective/Playful/etc.] based on technique type
|
||||
|
||||
**Ready to dive into creative exploration together? Let's start with our first element!**"
|
||||
|
||||
### 2. Execute First Technique Element Interactively
|
||||
|
||||
Begin with genuine facilitation of the first technique component:
|
||||
|
||||
**For Creative Techniques (What If, Analogical, etc.):**
|
||||
|
||||
"**Let's start with: [First provocative question/concept]**
|
||||
|
||||
I'm not just looking for a quick answer - I want to explore this together. What immediately comes to mind? Don't filter or edit - just share your initial thoughts, and we'll develop them together."
|
||||
|
||||
**Wait for user response, then coach deeper:**
|
||||
|
||||
- **If user gives basic response:** "That's interesting! Tell me more about [specific aspect]. What would that look like in practice? How does that connect to your [session_topic]?"
|
||||
- **If user gives detailed response:** "Fascinating! I love how you [specific insight]. Let's build on that - what if we took that concept even further? How would [expand idea]?"
|
||||
- **If user seems stuck:** "No worries! Let me suggest a starting angle: [gentle prompt]. What do you think about that direction?"
|
||||
|
||||
**For Structured Techniques (SCAMPER, Six Thinking Hats, etc.):**
|
||||
|
||||
"**Let's explore [Specific letter/perspective]: [Prompt]**
|
||||
|
||||
Instead of just listing possibilities, let's really dive into one promising direction. What's the most exciting or surprising thought you have about this?"
|
||||
|
||||
**Coach the exploration:**
|
||||
|
||||
- "That's a powerful idea! Help me understand the deeper implications..."
|
||||
- "I'm curious - how does this connect to what we discovered in [previous element]?"
|
||||
- "What would make this concept even more innovative or impactful?"
|
||||
- "Tell me more about [specific aspect the user mentioned]..."
|
||||
|
||||
### 3. Deep Dive Based on User Response
|
||||
|
||||
Follow the user's creative energy with genuine coaching:
|
||||
|
||||
**Responsive Facilitation Patterns:**
|
||||
|
||||
**When user shares exciting idea:**
|
||||
"That's brilliant! I can feel the creative energy there. Let's explore this more deeply:
|
||||
|
||||
**Development Questions:**
|
||||
|
||||
- What makes this idea so exciting to you?
|
||||
- How would this actually work in practice?
|
||||
- What are the most innovative aspects of this approach?
|
||||
- Could this be applied in unexpected ways?
|
||||
|
||||
**Let me build on your idea:** [Extend concept with your own creative contribution]"
|
||||
|
||||
**When user seems uncertain:**
|
||||
"Great starting point! Sometimes the most powerful ideas need space to develop. Let's try this angle:
|
||||
|
||||
**Exploratory Questions:**
|
||||
|
||||
- What if we removed all practical constraints?
|
||||
- How would [stakeholder] respond to this idea?
|
||||
- What's the most unexpected version of this concept?
|
||||
- Could we combine this with something completely different?"
|
||||
|
||||
**When user gives detailed response:**
|
||||
"Wow, there's so much rich material here! I want to make sure we capture the full potential. Let me focus on what I'm hearing:
|
||||
|
||||
**Key Insight:** [Extract and highlight their best point]
|
||||
**Building on That:** [Develop their idea further]
|
||||
**Additional Direction:** [Suggest new angles based on their thinking]"
|
||||
|
||||
### 4. Check Technique Continuation
|
||||
|
||||
Before moving to next technique element:
|
||||
|
||||
**Check Engagement and Interest:**
|
||||
|
||||
"This has been incredibly productive! We've generated some fantastic ideas around [current element].
|
||||
|
||||
**Before we move to the next technique element, I want to check in with you:**
|
||||
|
||||
- Are there aspects of [current element] you'd like to explore further?
|
||||
- Are there ideas that came up that you want to develop more deeply?
|
||||
- Do you feel ready to move to the next technique element, or should we continue here?
|
||||
|
||||
**Your creative energy is my guide - what would be most valuable right now?**
|
||||
|
||||
**Options:**
|
||||
|
||||
- **Continue exploring** current technique element
|
||||
- **Move to next technique element**
|
||||
- **Take a different angle** on current element
|
||||
- **Jump to most exciting idea** we've discovered so far
|
||||
|
||||
**Remember:** At any time, just say **"next technique"** or **"move on"** and I'll immediately document our current progress and start the next technique!"
|
||||
|
||||
### 4.1. Energy Checkpoint (After Every 4-5 Exchanges)
|
||||
|
||||
**Periodic Check-In (DO NOT skip this):**
|
||||
|
||||
"We've generated [X] ideas so far - great momentum!
|
||||
|
||||
**Quick energy check:**
|
||||
|
||||
- Want to **keep pushing** on this angle?
|
||||
- **Switch techniques** for a fresh perspective?
|
||||
- Or are you feeling like we've **thoroughly explored** this space?
|
||||
|
||||
Remember: The goal is quantity first - we can organize later. What feels right?"
|
||||
|
||||
**IMPORTANT:** Default to continuing exploration. Only suggest organization if:
|
||||
|
||||
- User has explicitly asked to wrap up, OR
|
||||
- You've been exploring for 45+ minutes AND generated 100+ ideas, OR
|
||||
- User's energy is clearly depleted (short responses, "I don't know", etc.)
|
||||
|
||||
### 4a. Handle Immediate Technique Transition
|
||||
|
||||
**When user says "next technique" or "move on":**
|
||||
|
||||
**Immediate Response:**
|
||||
"**Got it! Let's transition to the next technique.**
|
||||
|
||||
**Documenting our progress with [Current Technique]:**
|
||||
|
||||
**What we've discovered so far:**
|
||||
|
||||
- **Key Ideas Generated:** [List main ideas from current exploration]
|
||||
- **Creative Breakthroughs:** [Highlight most innovative insights]
|
||||
- **Your Creative Contributions:** [Acknowledge user's specific insights]
|
||||
- **Energy and Engagement:** [Note about user's creative flow]
|
||||
|
||||
**Partial Technique Completion:** [Note that technique was partially completed but valuable insights captured]
|
||||
|
||||
**Ready to start the next technique: [Next Technique Name]**
|
||||
|
||||
This technique will help us [what this technique adds]. I'm particularly excited to see how it builds on or contrasts with what we discovered about [key insight from current technique].
|
||||
|
||||
**Let's begin fresh with this new approach!**"
|
||||
|
||||
**Then restart step 3 for the next technique:**
|
||||
|
||||
- Update frontmatter with partial completion of current technique
|
||||
- Append technique insights to document
|
||||
- Begin facilitation of next technique with fresh coaching approach
|
||||
|
||||
### 5. Facilitate Multi-Technique Sessions
|
||||
|
||||
If multiple techniques selected:
|
||||
|
||||
**Transition Between Techniques:**
|
||||
|
||||
"**Fantastic work with [Previous Technique]!** We've uncovered some incredible insights, especially [highlight key discovery].
|
||||
|
||||
**Now let's transition to [Next Technique]:**
|
||||
|
||||
This technique will help us [what this technique adds]. I'm particularly excited to see how it builds on what we discovered about [key insight from previous technique].
|
||||
|
||||
**Building on Previous Insights:**
|
||||
|
||||
- [Connection 1]: How [Previous Technique insight] connects to [Next Technique approach]
|
||||
- [Development Opportunity]: How we can develop [specific idea] further
|
||||
- [New Perspective]: How [Next Technique] will give us fresh eyes on [topic]
|
||||
|
||||
**Ready to continue our creative journey with this new approach?**
|
||||
|
||||
Remember, you can say **"next technique"** at any time and I'll immediately document progress and move to the next technique!"
|
||||
|
||||
### 6. Document Ideas Organically
|
||||
|
||||
Capture insights as they emerge during interactive facilitation:
|
||||
|
||||
**During Facilitation:**
|
||||
|
||||
"That's a powerful insight - let me capture that: _[Key idea with context]_
|
||||
|
||||
I'm noticing a theme emerging here: _[Pattern recognition]_
|
||||
|
||||
This connects beautifully with what we discovered earlier about _[previous connection]_"
|
||||
|
||||
**After Deep Exploration:**
|
||||
|
||||
"Let me summarize what we've uncovered in this exploration using our **IDEA FORMAT TEMPLATE**:
|
||||
|
||||
**Key Ideas Generated:**
|
||||
|
||||
**[Category #X]**: [Mnemonic Title]
|
||||
_Concept_: [2-3 sentence description]
|
||||
_Novelty_: [What makes this different from obvious solutions]
|
||||
|
||||
(Repeat for all ideas generated)
|
||||
|
||||
**Creative Breakthrough:** [Most innovative insight from the dialogue]
|
||||
|
||||
**Energy and Engagement:** [Observation about user's creative flow]
|
||||
|
||||
**Should I document these ideas before we continue, or keep the creative momentum going?**"
|
||||
|
||||
### 7. Complete Technique with Integration
|
||||
|
||||
After final technique element:
|
||||
|
||||
"**Outstanding completion of [Technique Name]!**
|
||||
|
||||
**What We've Discovered Together:**
|
||||
|
||||
- **[Number] major insights** about [session_topic]
|
||||
- **Most exciting breakthrough:** [highlight key discovery]
|
||||
- **Surprising connections:** [unexpected insights]
|
||||
- **Your creative strengths:** [what user demonstrated]
|
||||
|
||||
**How This Technique Served Your Goals:**
|
||||
[Connect technique outcomes to user's original session goals]
|
||||
|
||||
**Integration with Overall Session:**
|
||||
[How these insights connect to the broader brainstorming objectives]
|
||||
|
||||
**Before we move to idea organization, any final thoughts about this technique? Any insights you want to make sure we carry forward?**
|
||||
|
||||
**What would you like to do next?**
|
||||
|
||||
[K] **Keep exploring this technique** - We're just getting warmed up!
|
||||
[T] **Try a different technique** - Fresh perspective on the same topic
|
||||
[A] **Go deeper on a specific idea** - Develop a promising concept further (Advanced Elicitation)
|
||||
[B] **Take a quick break** - Pause and return with fresh energy
|
||||
[C] **Move to organization** - Only when you feel we've thoroughly explored
|
||||
|
||||
**HALT — wait for user selection before proceeding.**
|
||||
|
||||
**Default recommendation:** Unless you feel we've generated at least 100+ ideas, I suggest we keep exploring! The best insights often come after the obvious ideas are exhausted.
|
||||
|
||||
### 8. Handle Menu Selection
|
||||
|
||||
#### If 'C' (Move to organization):
|
||||
|
||||
- **Append the technique execution content to `{brainstorming_session_output_file}`**
|
||||
- **Update frontmatter:** `stepsCompleted: [1, 2, 3]`
|
||||
- **Load:** `./step-04-idea-organization.md`
|
||||
|
||||
#### If 'K', 'T', 'A', or 'B' (Continue Exploring):
|
||||
|
||||
- **Stay in Step 3** and restart the facilitation loop for the chosen path (or pause if break requested).
|
||||
- For option A: Invoke the `bmad-advanced-elicitation` skill
|
||||
|
||||
### 9. Update Documentation
|
||||
|
||||
Update frontmatter and document with interactive session insights:
|
||||
|
||||
**Update frontmatter:**
|
||||
|
||||
```yaml
|
||||
---
|
||||
stepsCompleted: [1, 2, 3]
|
||||
techniques_used: [completed techniques]
|
||||
ideas_generated: [total count]
|
||||
technique_execution_complete: true
|
||||
facilitation_notes: [key insights about user's creative process]
|
||||
---
|
||||
```
|
||||
|
||||
**Append to document:**
|
||||
|
||||
```markdown
|
||||
## Technique Execution Results
|
||||
|
||||
**[Technique 1 Name]:**
|
||||
|
||||
- **Interactive Focus:** [Main exploration directions]
|
||||
- **Key Breakthroughs:** [Major insights from coaching dialogue]
|
||||
|
||||
- **User Creative Strengths:** [What user demonstrated]
|
||||
- **Energy Level:** [Observation about engagement]
|
||||
|
||||
**[Technique 2 Name]:**
|
||||
|
||||
- **Building on Previous:** [How techniques connected]
|
||||
- **New Insights:** [Fresh discoveries]
|
||||
- **Developed Ideas:** [Concepts that evolved through coaching]
|
||||
|
||||
**Overall Creative Journey:** [Summary of facilitation experience and outcomes]
|
||||
|
||||
### Creative Facilitation Narrative
|
||||
|
||||
_[Short narrative describing the user and AI collaboration journey - what made this session special, breakthrough moments, and how the creative partnership unfolded]_
|
||||
|
||||
### Session Highlights
|
||||
|
||||
**User Creative Strengths:** [What the user demonstrated during techniques]
|
||||
**AI Facilitation Approach:** [How coaching adapted to user's style]
|
||||
**Breakthrough Moments:** [Specific creative breakthroughs that occurred]
|
||||
**Energy Flow:** [Description of creative momentum and engagement]
|
||||
```
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to `{brainstorming_session_output_file}` using the structure from above.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Minimum 100 ideas generated before organization is offered
|
||||
✅ User explicitly confirms readiness to conclude (not AI-initiated)
|
||||
✅ Multiple technique exploration encouraged over single-technique completion
|
||||
✅ True back-and-forth facilitation rather than question-answer format
|
||||
✅ User's creative energy and interests guide technique direction
|
||||
✅ Deep exploration of promising ideas before moving on
|
||||
✅ Continuation checks allow user control of technique pacing
|
||||
✅ Ideas developed organically through collaborative coaching
|
||||
✅ User engagement and strengths recognized and built upon
|
||||
✅ Documentation captures both ideas and facilitation insights
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Offering organization after only one technique or <20 ideas
|
||||
❌ AI initiating conclusion without user explicitly requesting it
|
||||
❌ Treating technique completion as session completion signal
|
||||
❌ Rushing to document rather than staying in generative mode
|
||||
❌ Rushing through technique elements without user engagement
|
||||
❌ Not following user's creative energy and interests
|
||||
❌ Missing opportunities to develop promising ideas deeper
|
||||
❌ Not checking for continuation interest before moving on
|
||||
❌ Treating facilitation as script delivery rather than coaching
|
||||
|
||||
## INTERACTIVE FACILITATION PROTOCOLS:
|
||||
|
||||
- Present one technique element at a time for depth over breadth
|
||||
- Build upon user's ideas with genuine creative contributions
|
||||
- Follow user's energy and interests within technique structure
|
||||
- Always check for continuation interest before technique progression
|
||||
- Document both the "what" (ideas) and "how" (facilitation process)
|
||||
- Adapt coaching style based on user's creative preferences
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After technique completion and user confirmation, load `./step-04-idea-organization.md` to organize all the collaboratively developed ideas and create actionable next steps.
|
||||
|
||||
Remember: This is creative coaching, not technique delivery! The user's creative energy is your guide, not the technique structure.
|
||||
@@ -1,305 +0,0 @@
|
||||
# Step 4: Idea Organization and Action Planning
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- ✅ YOU ARE AN IDEA SYNTHESIZER, turning creative chaos into actionable insights
|
||||
- 🎯 ORGANIZE AND PRIORITIZE all generated ideas systematically
|
||||
- 📋 CREATE ACTIONABLE NEXT STEPS from brainstorming outcomes
|
||||
- 🔍 FACILITATE CONVERGENT THINKING after divergent exploration
|
||||
- 💬 DELIVER COMPREHENSIVE SESSION DOCUMENTATION
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the `communication_language`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Systematically organize all ideas from technique execution
|
||||
- ⚠️ Present [C] complete option after final documentation
|
||||
- 💾 Create comprehensive session output document
|
||||
- 📖 Update frontmatter with final session outcomes
|
||||
- 🚫 FORBIDDEN workflow completion without action planning
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- All generated ideas from technique execution in Step 3 are available
|
||||
- Session context, goals, and constraints from Step 1 are understood
|
||||
- Selected approach and techniques from Step 2 inform organization
|
||||
- User preferences for prioritization criteria identified
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Organize all brainstorming ideas into coherent themes, facilitate prioritization, and create actionable next steps with comprehensive session documentation.
|
||||
|
||||
## IDEA ORGANIZATION SEQUENCE:
|
||||
|
||||
### 1. Review Creative Output
|
||||
|
||||
Begin systematic review of all generated ideas:
|
||||
|
||||
"**Outstanding creative work!** You've generated an incredible range of ideas through our [approach_name] approach with [number] techniques.
|
||||
|
||||
**Session Achievement Summary:**
|
||||
|
||||
- **Total Ideas Generated:** [number] ideas across [number] techniques
|
||||
- **Creative Techniques Used:** [list of completed techniques]
|
||||
- **Session Focus:** [session_topic] with emphasis on [session_goals]
|
||||
|
||||
**Now let's organize these creative gems and identify your most promising opportunities for action.**
|
||||
|
||||
**Loading all generated ideas for systematic organization...**"
|
||||
|
||||
### 2. Theme Identification and Clustering
|
||||
|
||||
Group related ideas into meaningful themes:
|
||||
|
||||
**Theme Analysis Process:**
|
||||
"I'm analyzing all your generated ideas to identify natural themes and patterns. This will help us see the bigger picture and prioritize effectively.
|
||||
|
||||
**Emerging Themes I'm Identifying:**
|
||||
|
||||
**Theme 1: [Theme Name]**
|
||||
_Focus: [Description of what this theme covers]_
|
||||
|
||||
- **Ideas in this cluster:** [List 3-5 related ideas]
|
||||
- **Pattern Insight:** [What connects these ideas]
|
||||
|
||||
**Theme 2: [Theme Name]**
|
||||
_Focus: [Description of what this theme covers]_
|
||||
|
||||
- **Ideas in this cluster:** [List 3-5 related ideas]
|
||||
- **Pattern Insight:** [What connects these ideas]
|
||||
|
||||
**Theme 3: [Theme Name]**
|
||||
_Focus: [Description of what this theme covers]_
|
||||
|
||||
- **Ideas in this cluster:** [List 3-5 related ideas]
|
||||
- **Pattern Insight:** [What connects these ideas]
|
||||
|
||||
**Additional Categories:**
|
||||
|
||||
- **[Cross-cutting Ideas]:** [Ideas that span multiple themes]
|
||||
- **[Breakthrough Concepts]:** [Particularly innovative or surprising ideas]
|
||||
- **[Implementation-Ready Ideas]:** [Ideas that seem immediately actionable]"
|
||||
|
||||
### 3. Present Organized Idea Themes
|
||||
|
||||
Display systematically organized ideas for user review:
|
||||
|
||||
**Organized by Theme:**
|
||||
|
||||
"**Your Brainstorming Results - Organized by Theme:**
|
||||
|
||||
**[Theme 1]: [Theme Description]**
|
||||
|
||||
- **[Idea 1]:** [Development potential and unique insight]
|
||||
- **[Idea 2]:** [Development potential and unique insight]
|
||||
- **[Idea 3]:** [Development potential and unique insight]
|
||||
|
||||
**[Theme 2]: [Theme Description]**
|
||||
|
||||
- **[Idea 1]:** [Development potential and unique insight]
|
||||
- **[Idea 2]:** [Development potential and unique insight]
|
||||
|
||||
**[Theme 3]: [Theme Description]**
|
||||
|
||||
- **[Idea 1]:** [Development potential and unique insight]
|
||||
- **[Idea 2]:** [Development potential and unique insight]
|
||||
|
||||
**Breakthrough Concepts:**
|
||||
|
||||
- **[Innovative Idea]:** [Why this represents a significant breakthrough]
|
||||
- **[Unexpected Connection]:** [How this creates new possibilities]
|
||||
|
||||
**Which themes or specific ideas stand out to you as most valuable?**"
|
||||
|
||||
### 4. Facilitate Prioritization
|
||||
|
||||
Guide user through strategic prioritization:
|
||||
|
||||
**Prioritization Framework:**
|
||||
|
||||
"Now let's identify your most promising ideas based on what matters most for your **[session_goals]**.
|
||||
|
||||
**Prioritization Criteria for Your Session:**
|
||||
|
||||
- **Impact:** Potential effect on [session_topic] success
|
||||
- **Feasibility:** Implementation difficulty and resource requirements
|
||||
- **Innovation:** Originality and competitive advantage
|
||||
- **Alignment:** Match with your stated constraints and goals
|
||||
|
||||
**Quick Prioritization Exercise:**
|
||||
|
||||
Review your organized ideas and identify:
|
||||
|
||||
1. **Top 3 High-Impact Ideas:** Which concepts could deliver the greatest results?
|
||||
2. **Easiest Quick Wins:** Which ideas could be implemented fastest?
|
||||
3. **Most Innovative Approaches:** Which concepts represent true breakthroughs?
|
||||
|
||||
**What stands out to you as most valuable? Share your top priorities and I'll help you develop action plans.**"
|
||||
|
||||
### 5. Develop Action Plans
|
||||
|
||||
Create concrete next steps for prioritized ideas:
|
||||
|
||||
**Action Planning Process:**
|
||||
|
||||
"**Excellent choices!** Let's develop actionable plans for your top priority ideas.
|
||||
|
||||
**For each selected idea, let's explore:**
|
||||
|
||||
- **Immediate Next Steps:** What can you do this week?
|
||||
- **Resource Requirements:** What do you need to move forward?
|
||||
- **Potential Obstacles:** What challenges might arise?
|
||||
- **Success Metrics:** How will you know it's working?
|
||||
|
||||
**Idea [Priority Number]: [Idea Name]**
|
||||
**Why This Matters:** [Connection to user's goals]
|
||||
**Next Steps:**
|
||||
|
||||
1. [Specific action step 1]
|
||||
2. [Specific action step 2]
|
||||
3. [Specific action step 3]
|
||||
|
||||
**Resources Needed:** [List of requirements]
|
||||
**Timeline:** [Implementation estimate]
|
||||
**Success Indicators:** [How to measure progress]
|
||||
|
||||
**Would you like me to develop similar action plans for your other top ideas?**"
|
||||
|
||||
### 6. Create Comprehensive Session Documentation
|
||||
|
||||
Prepare final session output:
|
||||
|
||||
**Session Documentation Structure:**
|
||||
|
||||
"**Creating your comprehensive brainstorming session documentation...**
|
||||
|
||||
This document will include:
|
||||
|
||||
- **Session Overview:** Context, goals, and approach used
|
||||
- **Complete Idea Inventory:** All concepts organized by theme
|
||||
- **Prioritization Results:** Your selected top ideas and rationale
|
||||
- **Action Plans:** Concrete next steps for implementation
|
||||
- **Session Insights:** Key learnings and creative breakthroughs
|
||||
|
||||
**Your brainstorming session has produced [number] organized ideas across [number] themes, with [number] prioritized concepts ready for action planning.**"
|
||||
|
||||
**Append to document:**
|
||||
|
||||
```markdown
|
||||
## Idea Organization and Prioritization
|
||||
|
||||
**Thematic Organization:**
|
||||
[Content showing all ideas organized by themes]
|
||||
|
||||
**Prioritization Results:**
|
||||
|
||||
- **Top Priority Ideas:** [Selected priorities with rationale]
|
||||
- **Quick Win Opportunities:** [Easy implementation ideas]
|
||||
- **Breakthrough Concepts:** [Innovative approaches for longer-term]
|
||||
|
||||
**Action Planning:**
|
||||
[Detailed action plans for top priorities]
|
||||
|
||||
## Session Summary and Insights
|
||||
|
||||
**Key Achievements:**
|
||||
|
||||
- [Major accomplishments of the session]
|
||||
- [Creative breakthroughs and insights]
|
||||
- [Actionable outcomes generated]
|
||||
|
||||
**Session Reflections:**
|
||||
[Content about what worked well and key learnings]
|
||||
```
|
||||
|
||||
### 7. Session Completion and Next Steps
|
||||
|
||||
Provide final session wrap-up and forward guidance:
|
||||
|
||||
**Session Completion:**
|
||||
|
||||
"**Congratulations on an incredibly productive brainstorming session!**
|
||||
|
||||
**Your Creative Achievements:**
|
||||
|
||||
- **[Number]** breakthrough ideas generated for **[session_topic]**
|
||||
- **[Number]** organized themes identifying key opportunity areas
|
||||
- **[Number prioritized concepts** with concrete action plans
|
||||
- **Clear pathway** from creative ideas to practical implementation
|
||||
|
||||
**Key Session Insights:**
|
||||
|
||||
- [Major insight about the topic or problem]
|
||||
- [Discovery about user's creative thinking or preferences]
|
||||
- [Breakthrough connection or innovative approach]
|
||||
|
||||
**What Makes This Session Valuable:**
|
||||
|
||||
- Systematic exploration using proven creativity techniques
|
||||
- Balance of divergent and convergent thinking
|
||||
- Actionable outcomes rather than just ideas
|
||||
- Comprehensive documentation for future reference
|
||||
|
||||
**Your Next Steps:**
|
||||
|
||||
1. **Review** your session document when you receive it
|
||||
2. **Begin** with your top priority action steps this week
|
||||
3. **Share** promising concepts with stakeholders if relevant
|
||||
4. **Schedule** follow-up sessions as ideas develop
|
||||
|
||||
**Ready to complete your session documentation?**
|
||||
[C] Complete - Generate final brainstorming session document
|
||||
|
||||
**HALT — wait for user selection before proceeding.**
|
||||
|
||||
### 8. Handle Completion Selection
|
||||
|
||||
#### If [C] Complete:
|
||||
|
||||
- **Append the final session content to `{brainstorming_session_output_file}`**
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4]`
|
||||
- Set `session_active: false` and `workflow_completed: true`
|
||||
- Complete workflow with positive closure message
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to `{brainstorming_session_output_file}` using the structure from step 7.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ All generated ideas systematically organized and themed
|
||||
✅ User successfully prioritized ideas based on personal criteria
|
||||
✅ Actionable next steps created for high-priority concepts
|
||||
✅ Comprehensive session documentation prepared
|
||||
✅ Clear pathway from ideas to implementation established
|
||||
✅ [C] complete option presented with value proposition
|
||||
✅ Session outcomes exceed user expectations and goals
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Poor idea organization leading to missed connections or insights
|
||||
❌ Inadequate prioritization framework or guidance
|
||||
❌ Action plans that are too vague or not truly actionable
|
||||
❌ Missing comprehensive session documentation
|
||||
❌ Not providing clear next steps or implementation guidance
|
||||
|
||||
## IDEA ORGANIZATION PROTOCOLS:
|
||||
|
||||
- Use consistent formatting and clear organization structure
|
||||
- Include specific details and insights rather than generic summaries
|
||||
- Capture user preferences and decision criteria for future reference
|
||||
- Provide multiple access points to ideas (themes, priorities, techniques)
|
||||
- Include facilitator insights about session dynamics and breakthroughs
|
||||
|
||||
## SESSION COMPLETION:
|
||||
|
||||
After user selects 'C':
|
||||
|
||||
- All brainstorming workflow steps completed successfully
|
||||
- Comprehensive session document generated with full idea inventory
|
||||
- User equipped with actionable plans and clear next steps
|
||||
- Creative breakthroughs and insights preserved for future use
|
||||
- User confidence high about moving ideas to implementation
|
||||
|
||||
Congratulations on facilitating a transformative brainstorming session that generated innovative solutions and actionable outcomes! 🚀
|
||||
|
||||
The user has experienced the power of structured creativity combined with expert facilitation to produce breakthrough ideas for their specific challenges and opportunities.
|
||||
@@ -1,15 +0,0 @@
|
||||
---
|
||||
stepsCompleted: []
|
||||
inputDocuments: []
|
||||
session_topic: ''
|
||||
session_goals: ''
|
||||
selected_approach: ''
|
||||
techniques_used: []
|
||||
ideas_generated: []
|
||||
context_file: ''
|
||||
---
|
||||
|
||||
# Brainstorming Session Results
|
||||
|
||||
**Facilitator:** {{user_name}}
|
||||
**Date:** {{date}}
|
||||
@@ -1,53 +0,0 @@
|
||||
---
|
||||
context_file: '' # Optional context file path for project-specific guidance
|
||||
---
|
||||
|
||||
# Brainstorming Session Workflow
|
||||
|
||||
**Goal:** Facilitate interactive brainstorming sessions using diverse creative techniques and ideation methods
|
||||
|
||||
**Your Role:** You are a brainstorming facilitator and creative thinking guide. You bring structured creativity techniques, facilitation expertise, and an understanding of how to guide users through effective ideation processes that generate innovative ideas and breakthrough solutions. During this entire workflow it is critical that you speak to the user in the config loaded `communication_language`.
|
||||
|
||||
**Critical Mindset:** Your job is to keep the user in generative exploration mode as long as possible. The best brainstorming sessions feel slightly uncomfortable - like you've pushed past the obvious ideas into truly novel territory. Resist the urge to organize or conclude. When in doubt, ask another question, try another technique, or dig deeper into a promising thread.
|
||||
|
||||
**Anti-Bias Protocol:** LLMs naturally drift toward semantic clustering (sequential bias). To combat this, you MUST consciously shift your creative domain every 10 ideas. If you've been focusing on technical aspects, pivot to user experience, then to business viability, then to edge cases or "black swan" events. Force yourself into orthogonal categories to maintain true divergence.
|
||||
|
||||
**Quantity Goal:** Aim for 100+ ideas before any organization. The first 20 ideas are usually obvious - the magic happens in ideas 50-100.
|
||||
|
||||
---
|
||||
|
||||
## WORKFLOW ARCHITECTURE
|
||||
|
||||
This uses **micro-file architecture** for disciplined execution:
|
||||
|
||||
- Each step is a self-contained file with embedded rules
|
||||
- Sequential progression with user control at each step
|
||||
- Document state tracked in frontmatter
|
||||
- Append-only document building through conversation
|
||||
- Brain techniques loaded on-demand from CSV
|
||||
|
||||
---
|
||||
|
||||
## INITIALIZATION
|
||||
|
||||
### Configuration Loading
|
||||
|
||||
Load config from `{project-root}/_bmad/core/config.yaml` and resolve:
|
||||
|
||||
- `project_name`, `output_folder`, `user_name`
|
||||
- `communication_language`, `document_output_language`, `user_skill_level`
|
||||
- `date` as system-generated current datetime
|
||||
|
||||
### Paths
|
||||
|
||||
- `brainstorming_session_output_file` = `{output_folder}/brainstorming/brainstorming-session-{{date}}-{{time}}.md` (evaluated once at workflow start)
|
||||
|
||||
All steps MUST reference `{brainstorming_session_output_file}` instead of the full path pattern.
|
||||
- `context_file` = Optional context file path from workflow invocation for project-specific guidance
|
||||
---
|
||||
|
||||
## EXECUTION
|
||||
|
||||
Read fully and follow: `./steps/step-01-session-setup.md` to begin the workflow.
|
||||
|
||||
**Note:** Session setup, technique discovery, and continuation detection happen in step-01-session-setup.md.
|
||||
@@ -84,7 +84,7 @@ Greet `{user_name}`, speaking in `{communication_language}`.
|
||||
|
||||
Execute each entry in `{workflow.activation_steps_append}` in order.
|
||||
|
||||
Activation is complete. Begin the workflow below.
|
||||
Activation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.
|
||||
|
||||
## Execution
|
||||
|
||||
|
||||
@@ -55,7 +55,7 @@ Greet the user, speaking in `{communication_language}`.
|
||||
|
||||
Execute each entry in `{workflow.activation_steps_append}` in order.
|
||||
|
||||
Activation is complete. Begin the workflow below.
|
||||
Activation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.
|
||||
|
||||
## Global Step Rules (apply to every step)
|
||||
|
||||
|
||||
@@ -9,6 +9,9 @@ description: 'Review code changes adversarially using parallel review layers (Bl
|
||||
|
||||
**Your Role:** You are an elite code reviewer. You gather context, launch parallel adversarial reviews, triage findings with precision, and present actionable results. No noise, no filler.
|
||||
|
||||
Subagents, when the capability is available, are an important part of this workflow. Use them as directed by the workflow steps.
|
||||
If you need an explicit user instruction to run them, ask once now for the whole workflow run.
|
||||
|
||||
## Conventions
|
||||
|
||||
- Bare paths (e.g. `checklist.md`) resolve from the skill root.
|
||||
@@ -47,7 +50,6 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||
- `date` as system-generated current datetime
|
||||
- `sprint_status` = `{implementation_artifacts}/sprint-status.yaml`
|
||||
- `project_context` = `**/project-context.md` (load if exists)
|
||||
- CLAUDE.md / memory files (load if exist)
|
||||
- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Step 5: Greet the User
|
||||
@@ -58,7 +60,7 @@ Greet `{user_name}`, speaking in `{communication_language}`.
|
||||
|
||||
Execute each entry in `{workflow.activation_steps_append}` in order.
|
||||
|
||||
Activation is complete. Begin the workflow below.
|
||||
Activation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.
|
||||
|
||||
## WORKFLOW ARCHITECTURE
|
||||
|
||||
|
||||
@@ -7,23 +7,29 @@ failed_layers: '' # set at runtime: comma-separated list of layers that failed o
|
||||
## RULES
|
||||
|
||||
- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
|
||||
- The Blind Hunter subagent receives NO project context — diff only.
|
||||
- The Edge Case Hunter subagent receives diff and project read access.
|
||||
- The Acceptance Auditor subagent receives diff, spec, and context docs.
|
||||
- All review subagents must run at the same model capability as the current session.
|
||||
|
||||
## INSTRUCTIONS
|
||||
|
||||
1. If `{review_mode}` = `"no-spec"`, note to the user: "Acceptance Auditor skipped — no spec file provided."
|
||||
|
||||
2. Launch parallel subagents without conversation context. If subagents are not available, generate prompt files in `{implementation_artifacts}` — one per reviewer role below — and HALT. Ask the user to run each in a separate session (ideally a different LLM) and paste back the findings. When findings are pasted, resume from this point and proceed to step 3.
|
||||
2. Launch Blind Hunter and Edge Case Hunter in parallel without prior conversation context. If `{review_mode}` = `"full"`, include the Acceptance Auditor in the same parallel launch. If subagents are not available, generate prompt files in `{implementation_artifacts}` for each applicable reviewer role and HALT. Ask the user to run each in a separate session (ideally a different LLM) and paste back the findings. When findings are pasted, resume from this point and proceed to step 3.
|
||||
|
||||
- **Blind Hunter** — receives `{diff_output}` only. No spec, no context docs, no project access. Invoke via the `bmad-review-adversarial-general` skill.
|
||||
- **Blind Hunter** — prompt:
|
||||
> Invoke the `bmad-review-adversarial-general` skill on this diff:
|
||||
>
|
||||
> {diff_output}
|
||||
|
||||
- **Edge Case Hunter** — receives `{diff_output}` and read access to the project. Invoke via the `bmad-review-edge-case-hunter` skill.
|
||||
- **Edge Case Hunter** — prompt:
|
||||
> Invoke the `bmad-review-edge-case-hunter` skill on this diff:
|
||||
>
|
||||
> {diff_output}
|
||||
|
||||
- **Acceptance Auditor** (only if `{review_mode}` = `"full"`) — receives `{diff_output}`, the content of the file at `{spec_file}`, and any loaded context docs. Its prompt:
|
||||
> You are an Acceptance Auditor. Review this diff against the spec and context docs. Check for: violations of acceptance criteria, deviations from spec intent, missing implementation of specified behavior, contradictions between spec constraints and actual code. Output findings as a Markdown list. Each finding: one-line title, which AC/constraint it violates, and evidence from the diff.
|
||||
- **Acceptance Auditor** (only if `{review_mode}` = `"full"`) — prompt:
|
||||
> You are an Acceptance Auditor. Review the provided diff against `{spec_file}` and any loaded context docs. Check for: violations of acceptance criteria, deviations from spec intent, missing implementation of specified behavior, contradictions between spec constraints and actual code. Output findings as a Markdown list. Each finding: one-line title, which AC/constraint it violates, and evidence from the diff.
|
||||
>
|
||||
> Diff:
|
||||
> {diff_output}
|
||||
|
||||
3. **Subagent failure handling**: If any subagent fails, times out, or returns empty results, append the layer name to `{failed_layers}` (comma-separated) and proceed with findings from the remaining layers.
|
||||
|
||||
|
||||
@@ -6,7 +6,6 @@
|
||||
## RULES
|
||||
|
||||
- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
|
||||
- Be precise. When uncertain between categories, prefer the more conservative classification.
|
||||
|
||||
## INSTRUCTIONS
|
||||
|
||||
@@ -29,7 +28,15 @@
|
||||
- Append any unique detail, reasoning, or location references from the other finding(s) into the surviving `detail` field.
|
||||
- Set `source` to the merged sources (e.g., `blind+edge`).
|
||||
|
||||
3. **Classify** each finding into exactly one bucket:
|
||||
3. **Read the code before rating.** Before assigning severity, open the source at each finding's location and read enough surrounding code to judge reachability -- call sites, guards, and validation that live outside the diff hunk. Do not rate from the diff hunk alone. Severity reflects the real consequence at a real call site, not the worst theoretical reading.
|
||||
|
||||
4. **Assign severity** to each finding by consequence for the artifact's main consumer (software user, document reader, etc).
|
||||
Disregard any severity assigned by a reviewing subagent. Review subagents operate under by-design information asymmetry and do not have enough context to set final severity for this workflow.
|
||||
- `low` -- none or cosmetic
|
||||
- `medium` -- tolerable
|
||||
- `high` -- intolerable
|
||||
|
||||
5. **Route** each finding into exactly one triage bucket:
|
||||
- **decision_needed** -- There is an ambiguous choice that requires human input. The code cannot be correctly patched without knowing the user's intent. Only possible if `{review_mode}` = `"full"`.
|
||||
- **patch** -- Code issue that is fixable without human input. The correct fix is unambiguous.
|
||||
- **defer** -- Pre-existing issue not caused by the current change. Real but not actionable now.
|
||||
@@ -37,11 +44,11 @@
|
||||
|
||||
If `{review_mode}` = `"no-spec"` and a finding would otherwise be `decision_needed`, reclassify it as `patch` (if the fix is unambiguous) or `defer` (if not).
|
||||
|
||||
4. **Drop** all `dismiss` findings. Record the dismiss count for the summary.
|
||||
6. **Drop** all `dismiss` findings. Record the dismiss count for the summary.
|
||||
|
||||
5. If `{failed_layers}` is non-empty, report which layers failed before announcing results. If zero findings remain after dropping dismissed AND `{failed_layers}` is non-empty, warn the user that the review may be incomplete rather than announcing a clean review.
|
||||
7. If `{failed_layers}` is non-empty, report which layers failed before announcing results. If zero findings remain after dropping dismissed AND `{failed_layers}` is non-empty, warn the user that the review may be incomplete rather than announcing a clean review.
|
||||
|
||||
6. If zero findings remain after triage (all rejected or none raised): state "✅ Clean review — all layers passed." (Step 3 already warned if any review layers failed via `{failed_layers}`.)
|
||||
8. If zero findings remain after triage (all rejected or none raised): state "✅ Clean review — all layers passed." (Step 3 already warned if any review layers failed via `{failed_layers}`.)
|
||||
|
||||
|
||||
## NEXT
|
||||
|
||||
@@ -86,7 +86,7 @@ Skip this section if `{spec_file}` is not set.
|
||||
|
||||
#### Determine new status based on review outcome
|
||||
|
||||
- If all `decision-needed` and `patch` findings were resolved (fixed or dismissed) AND no unresolved HIGH/MEDIUM issues remain: set `{new_status}` = `done`. Update the story file Status section to `done`.
|
||||
- If all `decision-needed` and `patch` findings were resolved (fixed or dismissed) AND no unresolved `high`/`medium` findings remain: set `{new_status}` = `done`. Update the story file Status section to `done`.
|
||||
- If `patch` findings were left as action items, or unresolved issues remain: set `{new_status}` = `in-progress`. Update the story file Status section to `in-progress`.
|
||||
|
||||
Save the story file.
|
||||
|
||||
@@ -62,7 +62,7 @@ Greet `{user_name}`, speaking in `{communication_language}`.
|
||||
|
||||
Execute each entry in `{workflow.activation_steps_append}` in order.
|
||||
|
||||
Activation is complete. Begin the workflow below.
|
||||
Activation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.
|
||||
|
||||
## Paths
|
||||
|
||||
|
||||
@@ -1,74 +1,30 @@
|
||||
---
|
||||
name: bmad-create-architecture
|
||||
description: 'Create architecture solution design decisions for AI agent consistency. Use when the user says "lets create architecture" or "create technical architecture" or "create a solution design"'
|
||||
description: 'DEPRECATED — consolidated into bmad-architecture create intent - this skill will be removed in v7 in favor of `bmad-architecture`.'
|
||||
---
|
||||
|
||||
# Architecture Workflow
|
||||
# DEPRECATED — forwards to bmad-architecture (create intent)
|
||||
|
||||
**Goal:** Create comprehensive architecture decisions through collaborative step-by-step discovery that ensures AI agents implement consistently.
|
||||
|
||||
**Your Role:** You are an architectural facilitator collaborating with a peer. This is a partnership, not a client-vendor relationship. You bring structured thinking and architectural knowledge, while the user brings domain expertise and product vision. Work together as equals to make decisions that prevent implementation conflicts.
|
||||
|
||||
## Conventions
|
||||
|
||||
- Bare paths (e.g. `steps/step-01-init.md`) resolve from the skill root.
|
||||
- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
|
||||
- `{project-root}`-prefixed paths resolve from the project working directory.
|
||||
- `{skill-name}` resolves to the skill directory's basename.
|
||||
|
||||
## WORKFLOW ARCHITECTURE
|
||||
|
||||
This uses **micro-file architecture** for disciplined execution:
|
||||
|
||||
- Each step is a self-contained file with embedded rules
|
||||
- Sequential progression with user control at each step
|
||||
- Document state tracked in frontmatter
|
||||
- Append-only document building through conversation
|
||||
- You NEVER proceed to a step file if the current step file indicates the user must approve and indicate continuation.
|
||||
This skill was consolidated into `bmad-architecture`. It is retained as a thin compatibility shim so existing invocations by name and `_bmad/custom/bmad-create-architecture.toml` override files keep working. New work should invoke `bmad-architecture` directly — it detects create / update / validate intent from the conversation.
|
||||
|
||||
## On Activation
|
||||
|
||||
### Step 1: Resolve the Workflow Block
|
||||
1. Resolve customization: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. This picks up any `{project-root}/_bmad/custom/bmad-create-architecture.toml` and `bmad-create-architecture.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
|
||||
|
||||
Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
|
||||
2. Load `{project-root}/_bmad/bmm/config.yaml` (and `config.user.yaml` if present) to resolve `{user_name}` and `{communication_language}`.
|
||||
|
||||
**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
|
||||
3. Emit a deprecation notice to the user in `{communication_language}`:
|
||||
|
||||
1. `{skill-root}/customize.toml` — defaults
|
||||
2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
|
||||
3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
|
||||
> Notice: `bmad-create-architecture` is deprecated and will be removed in a future release. It now forwards to `bmad-architecture` with create intent. To silence this notice and access the full new customization surface (`spine_template`, `spine_output_path`, `run_folder_pattern`, `doc_standards`, `external_sources`, `external_handoffs`, `finalize_reviewers`), migrate `_bmad/custom/bmad-create-architecture.toml` to `_bmad/custom/bmad-architecture.toml` and invoke `bmad-architecture` directly next time. Customization fields that were in this version still remain in the new version and will be respected if present in `_bmad/custom/bmad-architecture.toml`, but the new version also supports additional fields that you can take advantage of by migrating.
|
||||
|
||||
Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
|
||||
4. Invoke `bmad-architecture` with the following context. Pass these as the activating context so `bmad-architecture` honors them instead of resolving its own customization from scratch:
|
||||
|
||||
### Step 2: Execute Prepend Steps
|
||||
- **Intent:** `create` — skip `bmad-architecture`'s usual intent detection step.
|
||||
- **Pre-resolved legacy customization** — use these in place of resolving from `bmad-architecture`'s own `customize.toml` for the four legacy fields. For everything else (`spine_template`, `spine_output_path`, `run_folder_pattern`, `doc_standards`, `external_sources`, `external_handoffs`, `finalize_reviewers`), use `bmad-architecture`'s own defaults and overrides as normal:
|
||||
- `activation_steps_prepend` = the resolved value from step 1
|
||||
- `activation_steps_append` = the resolved value from step 1
|
||||
- `persistent_facts` = the resolved value from step 1
|
||||
- `on_complete` = the resolved value from step 1
|
||||
- **Original user input:** forward whatever the user said when invoking this skill verbatim.
|
||||
|
||||
Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
|
||||
|
||||
### Step 3: Load Persistent Facts
|
||||
|
||||
Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
|
||||
|
||||
### Step 4: Load Config
|
||||
|
||||
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||
- Use `{user_name}` for greeting
|
||||
- Use `{communication_language}` for all communications
|
||||
- Use `{document_output_language}` for output documents
|
||||
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||
- Use `{project_knowledge}` for additional context scanning
|
||||
|
||||
### Step 5: Greet the User
|
||||
|
||||
Greet `{user_name}`, speaking in `{communication_language}`.
|
||||
|
||||
### Step 6: Execute Append Steps
|
||||
|
||||
Execute each entry in `{workflow.activation_steps_append}` in order.
|
||||
|
||||
Activation is complete. Begin the workflow below.
|
||||
|
||||
## Execution
|
||||
|
||||
Read fully and follow: `./steps/step-01-init.md` to begin the workflow.
|
||||
|
||||
**Note:** Input document discovery and all initialization protocols are handled in step-01-init.md.
|
||||
`bmad-architecture` takes the workflow from here. Do not execute any further steps in this shim.
|
||||
|
||||
@@ -1,12 +0,0 @@
|
||||
---
|
||||
stepsCompleted: []
|
||||
inputDocuments: []
|
||||
workflowType: 'architecture'
|
||||
project_name: '{{project_name}}'
|
||||
user_name: '{{user_name}}'
|
||||
date: '{{date}}'
|
||||
---
|
||||
|
||||
# Architecture Decision Document
|
||||
|
||||
_This document builds collaboratively through step-by-step discovery. Sections are appended as we work through each architectural decision together._
|
||||
@@ -1,13 +0,0 @@
|
||||
domain,signals,complexity_level,suggested_workflow,web_searches
|
||||
e_commerce,"shopping,cart,checkout,payment,products,store",medium,standard,"ecommerce architecture patterns, payment processing, inventory management"
|
||||
fintech,"banking,payment,trading,finance,money,investment",high,enhanced,"financial security, PCI compliance, trading algorithms, fraud detection"
|
||||
healthcare,"medical,diagnostic,clinical,patient,hospital,health",high,enhanced,"HIPAA compliance, medical data security, FDA regulations, health tech"
|
||||
social,"social network,community,users,friends,posts,sharing",high,advanced,"social graph algorithms, feed ranking, notification systems, privacy"
|
||||
education,"learning,course,student,teacher,training,academic",medium,standard,"LMS architecture, progress tracking, assessment systems, video streaming"
|
||||
productivity,"productivity,workflow,tasks,management,business,tools",medium,standard,"collaboration patterns, real-time editing, notification systems, integration"
|
||||
media,"content,media,video,audio,streaming,broadcast",high,advanced,"CDN architecture, video encoding, streaming protocols, content delivery"
|
||||
iot,"IoT,sensors,devices,embedded,smart,connected",high,advanced,"device communication, real-time data processing, edge computing, security"
|
||||
government,"government,civic,public,admin,policy,regulation",high,enhanced,"accessibility standards, security clearance, data privacy, audit trails"
|
||||
process_control,"industrial automation,process control,PLC,SCADA,DCS,HMI,operational technology,control system,cyberphysical,MES,instrumentation,I&C,P&ID",high,advanced,"industrial process control architecture, SCADA system design, OT cybersecurity architecture, real-time control systems"
|
||||
building_automation,"building automation,BAS,BMS,HVAC,smart building,fire alarm,fire protection,fire suppression,life safety,elevator,DDC,access control,sequence of operations,commissioning",high,advanced,"building automation architecture, BACnet integration patterns, smart building design, building management system security"
|
||||
gaming,"game,gaming,multiplayer,real-time,interactive,entertainment",high,advanced,"real-time multiplayer, game engine architecture, matchmaking, leaderboards"
|
||||
|
@@ -1,7 +0,0 @@
|
||||
project_type,detection_signals,description,typical_starters
|
||||
web_app,"website,web application,browser,frontend,UI,interface",Web-based applications running in browsers,Next.js, Vite, Remix
|
||||
mobile_app,"mobile,iOS,Android,app,smartphone,tablet",Native mobile applications,React Native, Expo, Flutter
|
||||
api_backend,"API,REST,GraphQL,backend,service,microservice",Backend services and APIs,NestJS, Express, Fastify
|
||||
full_stack,"full-stack,complete,web+mobile,frontend+backend",Applications with both frontend and backend,T3 App, RedwoodJS, Blitz
|
||||
cli_tool,"CLI,command line,terminal,console,tool",Command-line interface tools,oclif, Commander, Caporal
|
||||
desktop_app,"desktop,Electron,Tauri,native app,macOS,Windows",Desktop applications,Electron, Tauri, Flutter Desktop
|
||||
|
@@ -1,153 +0,0 @@
|
||||
# Step 1: Architecture Workflow Initialization
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ ALWAYS treat this as collaborative discovery between architectural peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on initialization and setup only - don't look ahead to future steps
|
||||
- 🚪 DETECT existing workflow state and handle continuation properly
|
||||
- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- 💾 Initialize document and update frontmatter
|
||||
- 📖 Set up frontmatter `stepsCompleted: [1]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until setup is complete
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Variables from workflow.md are available in memory
|
||||
- Previous context = what's in output document + frontmatter
|
||||
- Don't assume knowledge from other steps
|
||||
- Input document discovery happens in this step
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Initialize the Architecture workflow by detecting continuation state, discovering input documents, and setting up the document for collaborative architectural decision making.
|
||||
|
||||
## INITIALIZATION SEQUENCE:
|
||||
|
||||
### 1. Check for Existing Workflow
|
||||
|
||||
First, check if the output document already exists:
|
||||
|
||||
- Look for existing {planning_artifacts}/`*architecture*.md`
|
||||
- If exists, read the complete file(s) including frontmatter
|
||||
- If not exists, this is a fresh workflow
|
||||
|
||||
### 2. Handle Continuation (If Document Exists)
|
||||
|
||||
If the document exists and has frontmatter with `stepsCompleted`:
|
||||
|
||||
- **STOP here** and load `./step-01b-continue.md` immediately
|
||||
- Do not proceed with any initialization tasks
|
||||
- Let step-01b handle the continuation logic
|
||||
|
||||
### 3. Fresh Workflow Setup (If No Document)
|
||||
|
||||
If no document exists or no `stepsCompleted` in frontmatter:
|
||||
|
||||
#### A. Input Document Discovery
|
||||
|
||||
Discover and load context documents using smart discovery. Documents can be in the following locations:
|
||||
- {planning_artifacts}/**
|
||||
- {output_folder}/**
|
||||
- {project_knowledge}/**
|
||||
- {project-root}/docs/**
|
||||
|
||||
Also - when searching - documents can be a single markdown file, or a folder with an index and multiple files. For Example, if searching for `*foo*.md` and not found, also search for a folder called *foo*/index.md (which indicates sharded content)
|
||||
|
||||
Try to discover the following:
|
||||
- Product Brief (`*brief*.md`)
|
||||
- Product Requirements Document (`*prd*.md`)
|
||||
- UX Design (`*ux-design*.md`) and other
|
||||
- Research Documents (`*research*.md`)
|
||||
- Project Documentation (generally multiple documents might be found for this in the `{project_knowledge}` or `{project-root}/docs` folder.)
|
||||
- Project Context (`**/project-context.md`)
|
||||
|
||||
<critical>Confirm what you have found with the user, along with asking if the user wants to provide anything else. Only after this confirmation will you proceed to follow the loading rules</critical>
|
||||
|
||||
**Loading Rules:**
|
||||
|
||||
- Load ALL discovered files completely that the user confirmed or provided (no offset/limit)
|
||||
- If there is a project context, whatever is relevant should try to be biased in the remainder of this whole workflow process
|
||||
- For sharded folders, load ALL files to get complete picture, using the index first to potentially know the potential of each document
|
||||
- index.md is a guide to what's relevant whenever available
|
||||
- Track all successfully loaded files in frontmatter `inputDocuments` array
|
||||
|
||||
#### B. Validate Required Inputs
|
||||
|
||||
Before proceeding, verify we have the essential inputs:
|
||||
|
||||
**PRD Validation:**
|
||||
|
||||
- If no PRD found: "Architecture requires a PRD to work from. Please run the PRD workflow first or provide the PRD file path."
|
||||
- Do NOT proceed without PRD
|
||||
|
||||
**Other Input that might exist:**
|
||||
|
||||
- UX Spec: "Provides UI/UX architectural requirements"
|
||||
|
||||
#### C. Create Initial Document
|
||||
|
||||
Copy the template from `../architecture-decision-template.md` to `{planning_artifacts}/architecture.md`
|
||||
|
||||
#### D. Complete Initialization and Report
|
||||
|
||||
Complete setup and report to user:
|
||||
|
||||
**Document Setup:**
|
||||
|
||||
- Created: `{planning_artifacts}/architecture.md` from template
|
||||
- Initialized frontmatter with workflow state
|
||||
|
||||
**Input Documents Discovered:**
|
||||
Report what was found:
|
||||
"Welcome {{user_name}}! I've set up your Architecture workspace for {{project_name}}.
|
||||
|
||||
**Documents Found:**
|
||||
|
||||
- PRD: {number of PRD files loaded or "None found - REQUIRED"}
|
||||
- UX Design: {number of UX files loaded or "None found"}
|
||||
- Research: {number of research files loaded or "None found"}
|
||||
- Project docs: {number of project files loaded or "None found"}
|
||||
- Project context: {project_context_rules count of rules for AI agents found}
|
||||
|
||||
**Files loaded:** {list of specific file names or "No additional documents found"}
|
||||
|
||||
Ready to begin architectural decision making. Do you have any other documents you'd like me to include?
|
||||
|
||||
[C] Continue to project context analysis
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Existing workflow detected and handed off to step-01b correctly
|
||||
✅ Fresh workflow initialized with template and frontmatter
|
||||
✅ Input documents discovered and loaded using sharded-first logic
|
||||
✅ All discovered files tracked in frontmatter `inputDocuments`
|
||||
✅ PRD requirement validated and communicated
|
||||
✅ User confirmed document setup and can proceed
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Proceeding with fresh initialization when existing workflow exists
|
||||
❌ Not updating frontmatter with discovered input documents
|
||||
❌ Creating document without proper template
|
||||
❌ Not checking sharded folders first before whole files
|
||||
❌ Not reporting what documents were found to user
|
||||
❌ Proceeding without validating PRD requirement
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects [C] to continue, only after ensuring all the template output has been created, then load `./step-02-context.md` to analyze the project context and begin architectural decision making.
|
||||
|
||||
Remember: Do NOT proceed to step-02 until user explicitly selects [C] from the menu and setup is confirmed!
|
||||
@@ -1,173 +0,0 @@
|
||||
# Step 1b: Workflow Continuation Handler
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ ALWAYS treat this as collaborative discovery between architectural peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on understanding current state and getting user confirmation
|
||||
- 🚪 HANDLE workflow resumption smoothly and transparently
|
||||
- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- 📖 Read existing document completely to understand current state
|
||||
- 💾 Update frontmatter to reflect continuation
|
||||
- 🚫 FORBIDDEN to proceed to next step without user confirmation
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Existing document and frontmatter are available
|
||||
- Input documents already loaded should be in frontmatter `inputDocuments`
|
||||
- Steps already completed are in `stepsCompleted` array
|
||||
- Focus on understanding where we left off
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Handle workflow continuation by analyzing existing work and guiding the user to resume at the appropriate step.
|
||||
|
||||
## CONTINUATION SEQUENCE:
|
||||
|
||||
### 1. Analyze Current Document State
|
||||
|
||||
Read the existing architecture document completely and analyze:
|
||||
|
||||
**Frontmatter Analysis:**
|
||||
|
||||
- `stepsCompleted`: What steps have been done
|
||||
- `inputDocuments`: What documents were loaded
|
||||
- `lastStep`: Last step that was executed
|
||||
- `project_name`, `user_name`, `date`: Basic context
|
||||
|
||||
**Content Analysis:**
|
||||
|
||||
- What sections exist in the document
|
||||
- What architectural decisions have been made
|
||||
- What appears incomplete or in progress
|
||||
- Any TODOs or placeholders remaining
|
||||
|
||||
### 2. Present Continuation Summary
|
||||
|
||||
Show the user their current progress:
|
||||
|
||||
"Welcome back {{user_name}}! I found your Architecture work for {{project_name}}.
|
||||
|
||||
**Current Progress:**
|
||||
|
||||
- Steps completed: {{stepsCompleted list}}
|
||||
- Last step worked on: Step {{lastStep}}
|
||||
- Input documents loaded: {{number of inputDocuments}} files
|
||||
|
||||
**Document Sections Found:**
|
||||
{list all H2/H3 sections found in the document}
|
||||
|
||||
{if_incomplete_sections}
|
||||
**Incomplete Areas:**
|
||||
|
||||
- {areas that appear incomplete or have placeholders}
|
||||
{/if_incomplete_sections}
|
||||
|
||||
**What would you like to do?**
|
||||
[R] Resume from where we left off
|
||||
[C] Continue to next logical step
|
||||
[O] Overview of all remaining steps
|
||||
[X] Start over (will overwrite existing work)
|
||||
"
|
||||
|
||||
### 3. Handle User Choice
|
||||
|
||||
#### If 'R' (Resume from where we left off):
|
||||
|
||||
- Identify the next step based on `stepsCompleted`
|
||||
- Load the appropriate step file to continue
|
||||
- Example: If `stepsCompleted: [1, 2, 3]`, load `./step-04-decisions.md`
|
||||
|
||||
#### If 'C' (Continue to next logical step):
|
||||
|
||||
- Analyze the document content to determine logical next step
|
||||
- May need to review content quality and completeness
|
||||
- If content seems complete for current step, advance to next
|
||||
- If content seems incomplete, suggest staying on current step
|
||||
|
||||
#### If 'O' (Overview of all remaining steps):
|
||||
|
||||
- Provide brief description of all remaining steps
|
||||
- Let user choose which step to work on
|
||||
- Don't assume sequential progression is always best
|
||||
|
||||
#### If 'X' (Start over):
|
||||
|
||||
- Confirm: "This will delete all existing architectural decisions. Are you sure? (y/n)"
|
||||
- If confirmed: Delete existing document and read fully and follow: `./step-01-init.md`
|
||||
- If not confirmed: Return to continuation menu
|
||||
|
||||
### 4. Navigate to Selected Step
|
||||
|
||||
After user makes choice:
|
||||
|
||||
**Load the selected step file:**
|
||||
|
||||
- Update frontmatter `lastStep` to reflect current navigation
|
||||
- Execute the selected step file
|
||||
- Let that step handle the detailed continuation logic
|
||||
|
||||
**State Preservation:**
|
||||
|
||||
- Maintain all existing content in the document
|
||||
- Keep `stepsCompleted` accurate
|
||||
- Track the resumption in workflow status
|
||||
|
||||
### 5. Special Continuation Cases
|
||||
|
||||
#### If `stepsCompleted` is empty but document has content:
|
||||
|
||||
- This suggests an interrupted workflow
|
||||
- Ask user: "I see the document has content but no steps are marked as complete. Should I analyze what's here and set the appropriate step status?"
|
||||
|
||||
#### If document appears corrupted or incomplete:
|
||||
|
||||
- Ask user: "The document seems incomplete. Would you like me to try to recover what's here, or would you prefer to start fresh?"
|
||||
|
||||
#### If document is complete but workflow not marked as done:
|
||||
|
||||
- Ask user: "The architecture looks complete! Should I mark this workflow as finished, or is there more you'd like to work on?"
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Existing document state properly analyzed and understood
|
||||
✅ User presented with clear continuation options
|
||||
✅ User choice handled appropriately and transparently
|
||||
✅ Workflow state preserved and updated correctly
|
||||
✅ Navigation to appropriate step handled smoothly
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Not reading the complete existing document before making suggestions
|
||||
❌ Losing track of what steps were actually completed
|
||||
❌ Automatically proceeding without user confirmation of next steps
|
||||
❌ Not checking for incomplete or placeholder content
|
||||
❌ Losing existing document content during resumption
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects their continuation option, load the appropriate step file based on their choice. The step file will handle the detailed work from that point forward.
|
||||
|
||||
Valid step files to load:
|
||||
- `./step-02-context.md`
|
||||
- `./step-03-starter.md`
|
||||
- `./step-04-decisions.md`
|
||||
- `./step-05-patterns.md`
|
||||
- `./step-06-structure.md`
|
||||
- `./step-07-validation.md`
|
||||
- `./step-08-complete.md`
|
||||
|
||||
Remember: The goal is smooth, transparent resumption that respects the work already done while giving the user control over how to proceed.
|
||||
@@ -1,224 +0,0 @@
|
||||
# Step 2: Project Context Analysis
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ ALWAYS treat this as collaborative discovery between architectural peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on understanding project scope and requirements for architecture
|
||||
- 🎯 ANALYZE loaded documents, don't assume or generate requirements
|
||||
- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ⚠️ Present A/P/C menu after generating project context analysis
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## COLLABORATION MENUS (A/P/C):
|
||||
|
||||
This step will generate content and present choices:
|
||||
|
||||
- **A (Advanced Elicitation)**: Use discovery protocols to develop deeper insights about project context and architectural implications
|
||||
- **P (Party Mode)**: Bring multiple perspectives to analyze project requirements from different architectural angles
|
||||
- **C (Continue)**: Save the content to the document and proceed to next step
|
||||
|
||||
## PROTOCOL INTEGRATION:
|
||||
|
||||
- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
|
||||
- When 'P' selected: Invoke the `bmad-party-mode` skill
|
||||
- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
|
||||
- User accepts/rejects protocol changes before proceeding
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from step 1 are available
|
||||
- Input documents already loaded are in memory (PRD, epics, UX spec, etc.)
|
||||
- Focus on architectural implications of requirements
|
||||
- No technology decisions yet - pure analysis phase
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Fully read and Analyze the loaded project documents to understand architectural scope, requirements, and constraints before beginning decision making.
|
||||
|
||||
## CONTEXT ANALYSIS SEQUENCE:
|
||||
|
||||
### 1. Review Project Requirements
|
||||
|
||||
**From PRD Analysis:**
|
||||
|
||||
- Extract and analyze Functional Requirements (FRs)
|
||||
- Identify Non-Functional Requirements (NFRs) like performance, security, compliance
|
||||
- Note any technical constraints or dependencies mentioned
|
||||
- Count and categorize requirements to understand project scale
|
||||
|
||||
**From Epics/Stories (if available):**
|
||||
|
||||
- Map epic structure and user stories to architectural components
|
||||
- Extract acceptance criteria for technical implications
|
||||
- Identify cross-cutting concerns that span multiple epics
|
||||
- Estimate story complexity for architectural planning
|
||||
|
||||
**From UX Design (if available):**
|
||||
|
||||
- Extract architectural implications from UX requirements:
|
||||
- Component complexity (simple forms vs rich interactions)
|
||||
- Animation/transition requirements
|
||||
- Real-time update needs (live data, collaborative features)
|
||||
- Platform-specific UI requirements
|
||||
- Accessibility standards (WCAG compliance level)
|
||||
- Responsive design breakpoints
|
||||
- Offline capability requirements
|
||||
- Performance expectations (load times, interaction responsiveness)
|
||||
|
||||
### 2. Project Scale Assessment
|
||||
|
||||
Calculate and present project complexity:
|
||||
|
||||
**Complexity Indicators:**
|
||||
|
||||
- Real-time features requirements
|
||||
- Multi-tenancy needs
|
||||
- Regulatory compliance requirements
|
||||
- Integration complexity
|
||||
- User interaction complexity
|
||||
- Data complexity and volume
|
||||
|
||||
### 3. Reflect Understanding
|
||||
|
||||
Present your analysis back to user for validation:
|
||||
|
||||
"I'm reviewing your project documentation for {{project_name}}.
|
||||
|
||||
{if_epics_loaded}I see {{epic_count}} epics with {{story_count}} total stories.{/if_epics_loaded}
|
||||
{if_no_epics}I found {{fr_count}} functional requirements organized into {{fr_category_list}}.{/if_no_epics}
|
||||
{if_ux_loaded}I also found your UX specification which defines the user experience requirements.{/if_ux_loaded}
|
||||
|
||||
**Key architectural aspects I notice:**
|
||||
|
||||
- [Summarize core functionality from FRs]
|
||||
- [Note critical NFRs that will shape architecture]
|
||||
- {if_ux_loaded}[Note UX complexity and technical requirements]{/if_ux_loaded}
|
||||
- [Identify unique technical challenges or constraints]
|
||||
- [Highlight any regulatory or compliance requirements]
|
||||
|
||||
**Scale indicators:**
|
||||
|
||||
- Project complexity appears to be: [low/medium/high/enterprise]
|
||||
- Primary technical domain: [web/mobile/api/backend/full-stack/etc]
|
||||
- Cross-cutting concerns identified: [list major ones]
|
||||
|
||||
This analysis will help me guide you through the architectural decisions needed to ensure AI agents implement this consistently.
|
||||
|
||||
Does this match your understanding of the project scope and requirements?"
|
||||
|
||||
### 4. Generate Project Context Content
|
||||
|
||||
Prepare the content to append to the document:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
```markdown
|
||||
## Project Context Analysis
|
||||
|
||||
### Requirements Overview
|
||||
|
||||
**Functional Requirements:**
|
||||
{{analysis of FRs and what they mean architecturally}}
|
||||
|
||||
**Non-Functional Requirements:**
|
||||
{{NFRs that will drive architectural decisions}}
|
||||
|
||||
**Scale & Complexity:**
|
||||
{{project_scale_assessment}}
|
||||
|
||||
- Primary domain: {{technical_domain}}
|
||||
- Complexity level: {{complexity_level}}
|
||||
- Estimated architectural components: {{component_count}}
|
||||
|
||||
### Technical Constraints & Dependencies
|
||||
|
||||
{{known_constraints_dependencies}}
|
||||
|
||||
### Cross-Cutting Concerns Identified
|
||||
|
||||
{{concerns_that_will_affect_multiple_components}}
|
||||
```
|
||||
|
||||
### 5. Present Content and Menu
|
||||
|
||||
Show the generated content and present choices:
|
||||
|
||||
"I've drafted the Project Context Analysis based on your requirements. This sets the foundation for our architectural decisions.
|
||||
|
||||
**Here's what I'll add to the document:**
|
||||
|
||||
[Show the complete markdown content from step 4]
|
||||
|
||||
**What would you like to do?**
|
||||
[A] Advanced Elicitation - Let's dive deeper into architectural implications
|
||||
[P] Party Mode - Bring different perspectives to analyze requirements
|
||||
[C] Continue - Save this analysis and begin architectural decisions"
|
||||
|
||||
### 6. Handle Menu Selection
|
||||
|
||||
#### If 'A' (Advanced Elicitation):
|
||||
|
||||
- Invoke the `bmad-advanced-elicitation` skill with the current context analysis
|
||||
- Process the enhanced architectural insights that come back
|
||||
- Ask user: "Accept these enhancements to the project context analysis? (y/n)"
|
||||
- If yes: Update content with improvements, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'P' (Party Mode):
|
||||
|
||||
- Invoke the `bmad-party-mode` skill with the current project context
|
||||
- Process the collaborative improvements to architectural understanding
|
||||
- Ask user: "Accept these changes to the project context analysis? (y/n)"
|
||||
- If yes: Update content with improvements, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to `{planning_artifacts}/architecture.md`
|
||||
- Update frontmatter: `stepsCompleted: [1, 2]`
|
||||
- Load `./step-03-starter.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from step 4.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ All input documents thoroughly analyzed for architectural implications
|
||||
✅ Project scope and complexity clearly assessed and validated
|
||||
✅ Technical constraints and dependencies identified
|
||||
✅ Cross-cutting concerns mapped for architectural planning
|
||||
✅ User confirmation of project understanding
|
||||
✅ A/P/C menu presented and handled correctly
|
||||
✅ Content properly appended to document when C selected
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Skimming documents without deep architectural analysis
|
||||
❌ Missing or misinterpreting critical NFRs
|
||||
❌ Not validating project understanding with user
|
||||
❌ Underestimating complexity indicators
|
||||
❌ Generating content without real analysis of loaded documents
|
||||
❌ Not presenting A/P/C menu after content generation
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved to document, load `./step-03-starter.md` to evaluate starter template options.
|
||||
|
||||
Remember: Do NOT proceed to step-03 until user explicitly selects 'C' from the A/P/C menu and content is saved!
|
||||
@@ -1,329 +0,0 @@
|
||||
# Step 3: Starter Template Evaluation
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- ✅ ALWAYS treat this as collaborative discovery between architectural peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on evaluating starter template options with current versions
|
||||
- 🌐 ALWAYS search the web to verify current versions - NEVER trust hardcoded versions
|
||||
- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete architecture
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- 🌐 Search the web to verify current versions and options
|
||||
- ⚠️ Present A/P/C menu after generating starter template analysis
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## COLLABORATION MENUS (A/P/C):
|
||||
|
||||
This step will generate content and present choices:
|
||||
|
||||
- **A (Advanced Elicitation)**: Use discovery protocols to explore unconventional starter options or custom approaches
|
||||
- **P (Party Mode)**: Bring multiple perspectives to evaluate starter trade-offs for different use cases
|
||||
- **C (Continue)**: Save the content to the document and proceed to next step
|
||||
|
||||
## PROTOCOL INTEGRATION:
|
||||
|
||||
- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
|
||||
- When 'P' selected: Invoke the `bmad-party-mode` skill
|
||||
- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
|
||||
- User accepts/rejects protocol changes before proceeding
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Project context from step 2 is available and complete
|
||||
- Project context file from step-01 may contain technical preferences
|
||||
- No architectural decisions made yet - evaluating foundations
|
||||
- Focus on technical preferences discovery and starter evaluation
|
||||
- Consider project requirements and existing preferences when evaluating options
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Discover technical preferences and evaluate starter template options, leveraging existing technical preferences and establishing solid architectural foundations.
|
||||
|
||||
## STARTER EVALUATION SEQUENCE:
|
||||
|
||||
### 0. Check Technical Preferences & Context
|
||||
|
||||
**Check Project Context for Existing Technical Preferences:**
|
||||
"Before we dive into starter templates, let me check if you have any technical preferences already documented.
|
||||
|
||||
{{if_project_context_exists}}
|
||||
I found some technical rules in your project context file:
|
||||
{{extracted_technical_preferences_from_project_context}}
|
||||
|
||||
**Project Context Technical Rules Found:**
|
||||
|
||||
- Languages/Frameworks: {{languages_frameworks_from_context}}
|
||||
- Tools & Libraries: {{tools_from_context}}
|
||||
- Development Patterns: {{patterns_from_context}}
|
||||
- Platform Preferences: {{platforms_from_context}}
|
||||
|
||||
{{else}}
|
||||
No existing technical preferences found in project context file. We'll establish your technical preferences now.
|
||||
{{/if_project_context}}"
|
||||
|
||||
**Discover User Technical Preferences:**
|
||||
"Based on your project context, let's discuss your technical preferences:
|
||||
|
||||
{{primary_technology_category}} Preferences:
|
||||
|
||||
- **Languages**: Do you have preferences between TypeScript/JavaScript, Python, Go, Rust, etc.?
|
||||
- **Frameworks**: Any existing familiarity or preferences (React, Vue, Angular, Next.js, etc.)?
|
||||
- **Databases**: Any preferences or existing infrastructure (PostgreSQL, MongoDB, MySQL, etc.)?
|
||||
|
||||
**Development Experience:**
|
||||
|
||||
- What's your team's experience level with different technologies?
|
||||
- Are there any technologies you want to learn vs. what you're comfortable with?
|
||||
|
||||
**Platform/Deployment Preferences:**
|
||||
|
||||
- Cloud provider preferences (AWS, Vercel, Railway, etc.)?
|
||||
- Container preferences (Docker, Serverless, Traditional)?
|
||||
|
||||
**Integrations:**
|
||||
|
||||
- Any existing systems or APIs you need to integrate with?
|
||||
- Third-party services you plan to use (payment, authentication, analytics, etc.)?
|
||||
|
||||
These preferences will help me recommend the most suitable starter templates and guide our architectural decisions."
|
||||
|
||||
### 1. Identify Primary Technology Domain
|
||||
|
||||
Based on project context analysis and technical preferences, identify the primary technology stack:
|
||||
|
||||
- **Web application** → Look for Next.js, Vite, Remix, SvelteKit starters
|
||||
- **Mobile app** → Look for React Native, Expo, Flutter starters
|
||||
- **API/Backend** → Look for NestJS, Express, Fastify, Supabase starters
|
||||
- **CLI tool** → Look for CLI framework starters (oclif, commander, etc.)
|
||||
- **Full-stack** → Look for T3, RedwoodJS, Blitz, Next.js starters
|
||||
- **Desktop** → Look for Electron, Tauri starters
|
||||
|
||||
### 2. UX Requirements Consideration
|
||||
|
||||
If UX specification was loaded, consider UX requirements when selecting starter:
|
||||
|
||||
- **Rich animations** → Framer Motion compatible starter
|
||||
- **Complex forms** → React Hook Form included starter
|
||||
- **Real-time features** → Socket.io or WebSocket ready starter
|
||||
- **Design system** → Storybook-enabled starter
|
||||
- **Offline capability** → Service worker or PWA configured starter
|
||||
|
||||
### 3. Research Current Starter Options
|
||||
|
||||
Search the web to find current, maintained starter templates:
|
||||
|
||||
```
|
||||
Search the web: "{{primary_technology}} starter template CLI create command latest"
|
||||
Search the web: "{{primary_technology}} boilerplate generator latest options"
|
||||
Search the web: "{{primary_technology}} production-ready starter best practices"
|
||||
```
|
||||
|
||||
### 4. Investigate Top Starter Options
|
||||
|
||||
For each promising starter found, investigate details:
|
||||
|
||||
```
|
||||
Search the web: "{{starter_name}} default setup technologies included latest"
|
||||
Search the web: "{{starter_name}} project structure file organization"
|
||||
Search the web: "{{starter_name}} production deployment capabilities"
|
||||
Search the web: "{{starter_name}} recent updates maintenance status"
|
||||
```
|
||||
|
||||
### 5. Analyze What Each Starter Provides
|
||||
|
||||
For each viable starter option, document:
|
||||
|
||||
**Technology Decisions Made:**
|
||||
|
||||
- Language/TypeScript configuration
|
||||
- Styling solution (CSS, Tailwind, Styled Components, etc.)
|
||||
- Testing framework setup
|
||||
- Linting/Formatting configuration
|
||||
- Build tooling and optimization
|
||||
- Project structure and organization
|
||||
|
||||
**Architectural Patterns Established:**
|
||||
|
||||
- Code organization patterns
|
||||
- Component structure conventions
|
||||
- API layering approach
|
||||
- State management setup
|
||||
- Routing patterns
|
||||
- Environment configuration
|
||||
|
||||
**Development Experience Features:**
|
||||
|
||||
- Hot reloading and development server
|
||||
- TypeScript configuration
|
||||
- Debugging setup
|
||||
- Testing infrastructure
|
||||
- Documentation generation
|
||||
|
||||
### 6. Present Starter Options
|
||||
|
||||
Based on user skill level and project needs:
|
||||
|
||||
**For Expert Users:**
|
||||
"Found {{starter_name}} which provides:
|
||||
{{quick_decision_list_of_key_decisions}}
|
||||
|
||||
This would establish our base architecture with these technical decisions already made. Use it?"
|
||||
|
||||
**For Intermediate Users:**
|
||||
"I found {{starter_name}}, which is a well-maintained starter for {{project_type}} projects.
|
||||
|
||||
It makes these architectural decisions for us:
|
||||
{{decision_list_with_explanations}}
|
||||
|
||||
This gives us a solid foundation following current best practices. Should we use it?"
|
||||
|
||||
**For Beginner Users:**
|
||||
"I found {{starter_name}}, which is like a pre-built foundation for your project.
|
||||
|
||||
Think of it like buying a prefab house frame instead of cutting each board yourself.
|
||||
|
||||
It makes these decisions for us:
|
||||
{{friendly_explanation_of_decisions}}
|
||||
|
||||
This is a great starting point that follows best practices and saves us from making dozens of small technical choices. Should we use it?"
|
||||
|
||||
### 7. Get Current CLI Commands
|
||||
|
||||
If user shows interest in a starter, get the exact current commands:
|
||||
|
||||
```
|
||||
Search the web: "{{starter_name}} CLI command options flags latest"
|
||||
Search the web: "{{starter_name}} create new project command examples"
|
||||
```
|
||||
|
||||
### 8. Generate Starter Template Content
|
||||
|
||||
Prepare the content to append to the document:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
````markdown
|
||||
## Starter Template Evaluation
|
||||
|
||||
### Primary Technology Domain
|
||||
|
||||
{{identified_domain}} based on project requirements analysis
|
||||
|
||||
### Starter Options Considered
|
||||
|
||||
{{analysis_of_evaluated_starters}}
|
||||
|
||||
### Selected Starter: {{starter_name}}
|
||||
|
||||
**Rationale for Selection:**
|
||||
{{why_this_starter_was_chosen}}
|
||||
|
||||
**Initialization Command:**
|
||||
|
||||
```bash
|
||||
{{full_starter_command_with_options}}
|
||||
```
|
||||
|
||||
**Architectural Decisions Provided by Starter:**
|
||||
|
||||
**Language & Runtime:**
|
||||
{{language_typescript_setup}}
|
||||
|
||||
**Styling Solution:**
|
||||
{{styling_solution_configuration}}
|
||||
|
||||
**Build Tooling:**
|
||||
{{build_tools_and_optimization}}
|
||||
|
||||
**Testing Framework:**
|
||||
{{testing_setup_and_configuration}}
|
||||
|
||||
**Code Organization:**
|
||||
{{project_structure_and_patterns}}
|
||||
|
||||
**Development Experience:**
|
||||
{{development_tools_and_workflow}}
|
||||
|
||||
**Note:** Project initialization using this command should be the first implementation story.
|
||||
|
||||
````
|
||||
|
||||
### 9. Present Content and Menu
|
||||
|
||||
Show the generated content and present choices:
|
||||
|
||||
"I've analyzed starter template options for {{project_type}} projects.
|
||||
|
||||
**Here's what I'll add to the document:**
|
||||
|
||||
[Show the complete markdown content from step 8]
|
||||
|
||||
**What would you like to do?**
|
||||
[A] Advanced Elicitation - Explore custom approaches or unconventional starters
|
||||
[P] Party Mode - Evaluate trade-offs from different perspectives
|
||||
[C] Continue - Save this decision and move to architectural decisions"
|
||||
|
||||
### 10. Handle Menu Selection
|
||||
|
||||
#### If 'A' (Advanced Elicitation):
|
||||
|
||||
- Invoke the `bmad-advanced-elicitation` skill with current starter analysis
|
||||
- Process enhanced insights about starter options or custom approaches
|
||||
- Ask user: "Accept these changes to the starter template evaluation? (y/n)"
|
||||
- If yes: Update content, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'P' (Party Mode):
|
||||
|
||||
- Invoke the `bmad-party-mode` skill with starter evaluation context
|
||||
- Process collaborative insights about starter trade-offs
|
||||
- Ask user: "Accept these changes to the starter template evaluation? (y/n)"
|
||||
- If yes: Update content, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to `{planning_artifacts}/architecture.md`
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3]`
|
||||
- Load `./step-04-decisions.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from step 8.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Primary technology domain correctly identified from project context
|
||||
✅ Current, maintained starter templates researched and evaluated
|
||||
✅ All versions verified using web search, not hardcoded
|
||||
✅ Architectural implications of starter choice clearly documented
|
||||
✅ User provided with clear rationale for starter selection
|
||||
✅ A/P/C menu presented and handled correctly
|
||||
✅ Content properly appended to document when C selected
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Not verifying current versions with web search
|
||||
❌ Ignoring UX requirements when evaluating starters
|
||||
❌ Not documenting what architectural decisions the starter makes
|
||||
❌ Failing to consider maintenance status of starter templates
|
||||
❌ Not providing clear rationale for starter selection
|
||||
❌ Not presenting A/P/C menu after content generation
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved to document, load `./step-04-decisions.md` to begin making specific architectural decisions.
|
||||
|
||||
Remember: Do NOT proceed to step-04 until user explicitly selects 'C' from the A/P/C menu and content is saved!
|
||||
@@ -1,318 +0,0 @@
|
||||
# Step 4: Core Architectural Decisions
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ ALWAYS treat this as collaborative discovery between architectural peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on making critical architectural decisions collaboratively
|
||||
- 🌐 ALWAYS search the web to verify current technology versions
|
||||
- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- 🌐 Search the web to verify technology versions and options
|
||||
- ⚠️ Present A/P/C menu after each major decision category
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## COLLABORATION MENUS (A/P/C):
|
||||
|
||||
This step will generate content and present choices for each decision category:
|
||||
|
||||
- **A (Advanced Elicitation)**: Use discovery protocols to explore innovative approaches to specific decisions
|
||||
- **P (Party Mode)**: Bring multiple perspectives to evaluate decision trade-offs
|
||||
- **C (Continue)**: Save the current decisions and proceed to next decision category
|
||||
|
||||
## PROTOCOL INTEGRATION:
|
||||
|
||||
- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
|
||||
- When 'P' selected: Invoke the `bmad-party-mode` skill
|
||||
- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
|
||||
- User accepts/rejects protocol changes before proceeding
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Project context from step 2 is available
|
||||
- Starter template choice from step 3 is available
|
||||
- Project context file may contain technical preferences and rules
|
||||
- Technical preferences discovered in step 3 are available
|
||||
- Focus on decisions not already made by starter template or existing preferences
|
||||
- Collaborative decision making, not recommendations
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Facilitate collaborative architectural decision making, leveraging existing technical preferences and starter template decisions, focusing on remaining choices critical to the project's success.
|
||||
|
||||
## DECISION MAKING SEQUENCE:
|
||||
|
||||
### 1. Load Decision Framework & Check Existing Preferences
|
||||
|
||||
**Review Technical Preferences from Step 3:**
|
||||
"Based on our technical preferences discussion in step 3, let's build on those foundations:
|
||||
|
||||
**Your Technical Preferences:**
|
||||
{{user_technical_preferences_from_step_3}}
|
||||
|
||||
**Starter Template Decisions:**
|
||||
{{starter_template_decisions}}
|
||||
|
||||
**Project Context Technical Rules:**
|
||||
{{project_context_technical_rules}}"
|
||||
|
||||
**Identify Remaining Decisions:**
|
||||
Based on technical preferences, starter template choice, and project context, identify remaining critical decisions:
|
||||
|
||||
**Already Decided (Don't re-decide these):**
|
||||
|
||||
- {{starter_template_decisions}}
|
||||
- {{user_technology_preferences}}
|
||||
- {{project_context_technical_rules}}
|
||||
|
||||
**Critical Decisions:** Must be decided before implementation can proceed
|
||||
**Important Decisions:** Shape the architecture significantly
|
||||
**Nice-to-Have:** Can be deferred if needed
|
||||
|
||||
### 2. Decision Categories by Priority
|
||||
|
||||
#### Category 1: Data Architecture
|
||||
|
||||
- Database choice (if not determined by starter)
|
||||
- Data modeling approach
|
||||
- Data validation strategy
|
||||
- Migration approach
|
||||
- Caching strategy
|
||||
|
||||
#### Category 2: Authentication & Security
|
||||
|
||||
- Authentication method
|
||||
- Authorization patterns
|
||||
- Security middleware
|
||||
- Data encryption approach
|
||||
- API security strategy
|
||||
|
||||
#### Category 3: API & Communication
|
||||
|
||||
- API design patterns (REST, GraphQL, etc.)
|
||||
- API documentation approach
|
||||
- Error handling standards
|
||||
- Rate limiting strategy
|
||||
- Communication between services
|
||||
|
||||
#### Category 4: Frontend Architecture (if applicable)
|
||||
|
||||
- State management approach
|
||||
- Component architecture
|
||||
- Routing strategy
|
||||
- Performance optimization
|
||||
- Bundle optimization
|
||||
|
||||
#### Category 5: Infrastructure & Deployment
|
||||
|
||||
- Hosting strategy
|
||||
- CI/CD pipeline approach
|
||||
- Environment configuration
|
||||
- Monitoring and logging
|
||||
- Scaling strategy
|
||||
|
||||
### 3. Facilitate Each Decision Category
|
||||
|
||||
For each category, facilitate collaborative decision making:
|
||||
|
||||
**Present the Decision:**
|
||||
Based on user skill level and project context:
|
||||
|
||||
**Expert Mode:**
|
||||
"{{Decision_Category}}: {{Specific_Decision}}
|
||||
|
||||
Options: {{concise_option_list_with_tradeoffs}}
|
||||
|
||||
What's your preference for this decision?"
|
||||
|
||||
**Intermediate Mode:**
|
||||
"Next decision: {{Human_Friendly_Category}}
|
||||
|
||||
We need to choose {{Specific_Decision}}.
|
||||
|
||||
Common options:
|
||||
{{option_list_with_brief_explanations}}
|
||||
|
||||
For your project, I'd lean toward {{recommendation}} because {{reason}}. What are your thoughts?"
|
||||
|
||||
**Beginner Mode:**
|
||||
"Let's talk about {{Human_Friendly_Category}}.
|
||||
|
||||
{{Educational_Context_About_Why_This_Matters}}
|
||||
|
||||
Think of it like {{real_world_analogy}}.
|
||||
|
||||
Your main options:
|
||||
{{friendly_options_with_pros_cons}}
|
||||
|
||||
My suggestion: {{recommendation}}
|
||||
This is good for you because {{beginner_friendly_reason}}.
|
||||
|
||||
What feels right to you?"
|
||||
|
||||
**Verify Technology Versions:**
|
||||
If decision involves specific technology:
|
||||
|
||||
```
|
||||
Search the web: "{{technology}} latest stable version"
|
||||
Search the web: "{{technology}} current LTS version"
|
||||
Search the web: "{{technology}} production readiness"
|
||||
```
|
||||
|
||||
**Get User Input:**
|
||||
"What's your preference? (or 'explain more' for details)"
|
||||
|
||||
**Handle User Response:**
|
||||
|
||||
- If user wants more info: Provide deeper explanation
|
||||
- If user has preference: Discuss implications and record decision
|
||||
- If user wants alternatives: Explore other options
|
||||
|
||||
**Record the Decision:**
|
||||
|
||||
- Category: {{category}}
|
||||
- Decision: {{user_choice}}
|
||||
- Version: {{verified_version_if_applicable}}
|
||||
- Rationale: {{user_reasoning_or_default}}
|
||||
- Affects: {{components_or_epics}}
|
||||
- Provided by Starter: {{yes_if_from_starter}}
|
||||
|
||||
### 4. Check for Cascading Implications
|
||||
|
||||
After each major decision, identify related decisions:
|
||||
|
||||
"This choice means we'll also need to decide:
|
||||
|
||||
- {{related_decision_1}}
|
||||
- {{related_decision_2}}"
|
||||
|
||||
### 5. Generate Decisions Content
|
||||
|
||||
After facilitating all decision categories, prepare the content to append:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
```markdown
|
||||
## Core Architectural Decisions
|
||||
|
||||
### Decision Priority Analysis
|
||||
|
||||
**Critical Decisions (Block Implementation):**
|
||||
{{critical_decisions_made}}
|
||||
|
||||
**Important Decisions (Shape Architecture):**
|
||||
{{important_decisions_made}}
|
||||
|
||||
**Deferred Decisions (Post-MVP):**
|
||||
{{decisions_deferred_with_rationale}}
|
||||
|
||||
### Data Architecture
|
||||
|
||||
{{data_related_decisions_with_versions_and_rationale}}
|
||||
|
||||
### Authentication & Security
|
||||
|
||||
{{security_related_decisions_with_versions_and_rationale}}
|
||||
|
||||
### API & Communication Patterns
|
||||
|
||||
{{api_related_decisions_with_versions_and_rationale}}
|
||||
|
||||
### Frontend Architecture
|
||||
|
||||
{{frontend_related_decisions_with_versions_and_rationale}}
|
||||
|
||||
### Infrastructure & Deployment
|
||||
|
||||
{{infrastructure_related_decisions_with_versions_and_rationale}}
|
||||
|
||||
### Decision Impact Analysis
|
||||
|
||||
**Implementation Sequence:**
|
||||
{{ordered_list_of_decisions_for_implementation}}
|
||||
|
||||
**Cross-Component Dependencies:**
|
||||
{{how_decisions_affect_each_other}}
|
||||
```
|
||||
|
||||
### 6. Present Content and Menu
|
||||
|
||||
Show the generated decisions content and present choices:
|
||||
|
||||
"I've documented all the core architectural decisions we've made together.
|
||||
|
||||
**Here's what I'll add to the document:**
|
||||
|
||||
[Show the complete markdown content from step 5]
|
||||
|
||||
**What would you like to do?**
|
||||
[A] Advanced Elicitation - Explore innovative approaches to any specific decisions
|
||||
[P] Party Mode - Review decisions from multiple perspectives
|
||||
[C] Continue - Save these decisions and move to implementation patterns"
|
||||
|
||||
### 7. Handle Menu Selection
|
||||
|
||||
#### If 'A' (Advanced Elicitation):
|
||||
|
||||
- Invoke the `bmad-advanced-elicitation` skill with specific decision categories
|
||||
- Process enhanced insights about particular decisions
|
||||
- Ask user: "Accept these enhancements to the architectural decisions? (y/n)"
|
||||
- If yes: Update content, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'P' (Party Mode):
|
||||
|
||||
- Invoke the `bmad-party-mode` skill with architectural decisions context
|
||||
- Process collaborative insights about decision trade-offs
|
||||
- Ask user: "Accept these changes to the architectural decisions? (y/n)"
|
||||
- If yes: Update content, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to `{planning_artifacts}/architecture.md`
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4]`
|
||||
- Load `./step-05-patterns.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from step 5.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ All critical architectural decisions made collaboratively
|
||||
✅ Technology versions verified using web search
|
||||
✅ Decision rationale clearly documented
|
||||
✅ Cascading implications identified and addressed
|
||||
✅ User provided appropriate level of explanation for skill level
|
||||
✅ A/P/C menu presented and handled correctly for each category
|
||||
✅ Content properly appended to document when C selected
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Making recommendations instead of facilitating decisions
|
||||
❌ Not verifying technology versions with web search
|
||||
❌ Missing cascading implications between decisions
|
||||
❌ Not adapting explanations to user skill level
|
||||
❌ Forgetting to document decisions made by starter template
|
||||
❌ Not presenting A/P/C menu after content generation
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved to document, load `./step-05-patterns.md` to define implementation patterns that ensure consistency across AI agents.
|
||||
|
||||
Remember: Do NOT proceed to step-05 until user explicitly selects 'C' from the A/P/C menu and content is saved!
|
||||
@@ -1,359 +0,0 @@
|
||||
# Step 5: Implementation Patterns & Consistency Rules
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ ALWAYS treat this as collaborative discovery between architectural peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on patterns that prevent AI agent implementation conflicts
|
||||
- 🎯 EMPHASIZE what agents could decide DIFFERENTLY if not specified
|
||||
- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- 🎯 Focus on consistency, not implementation details
|
||||
- ⚠️ Present A/P/C menu after generating patterns content
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## COLLABORATION MENUS (A/P/C):
|
||||
|
||||
This step will generate content and present choices:
|
||||
|
||||
- **A (Advanced Elicitation)**: Use discovery protocols to develop comprehensive consistency patterns
|
||||
- **P (Party Mode)**: Bring multiple perspectives to identify potential conflict points
|
||||
- **C (Continue)**: Save the patterns and proceed to project structure
|
||||
|
||||
## PROTOCOL INTEGRATION:
|
||||
|
||||
- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
|
||||
- When 'P' selected: Invoke the `bmad-party-mode` skill
|
||||
- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
|
||||
- User accepts/rejects protocol changes before proceeding
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Core architectural decisions from step 4 are complete
|
||||
- Technology stack is decided and versions are verified
|
||||
- Focus on HOW agents should implement, not WHAT they should implement
|
||||
- Consider what could vary between different AI agents
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Define implementation patterns and consistency rules that ensure multiple AI agents write compatible, consistent code that works together seamlessly.
|
||||
|
||||
## PATTERNS DEFINITION SEQUENCE:
|
||||
|
||||
### 1. Identify Potential Conflict Points
|
||||
|
||||
Based on the chosen technology stack and decisions, identify where AI agents could make different choices:
|
||||
|
||||
**Naming Conflicts:**
|
||||
|
||||
- Database table/column naming conventions
|
||||
- API endpoint naming patterns
|
||||
- File and directory naming
|
||||
- Component/function/variable naming
|
||||
- Route parameter formats
|
||||
|
||||
**Structural Conflicts:**
|
||||
|
||||
- Where tests are located
|
||||
- How components are organized
|
||||
- Where utilities and helpers go
|
||||
- Configuration file organization
|
||||
- Static asset organization
|
||||
|
||||
**Format Conflicts:**
|
||||
|
||||
- API response wrapper formats
|
||||
- Error response structures
|
||||
- Date/time formats in APIs and UI
|
||||
- JSON field naming conventions
|
||||
- API status code usage
|
||||
|
||||
**Communication Conflicts:**
|
||||
|
||||
- Event naming conventions
|
||||
- Event payload structures
|
||||
- State update patterns
|
||||
- Action naming conventions
|
||||
- Logging formats and levels
|
||||
|
||||
**Process Conflicts:**
|
||||
|
||||
- Loading state handling
|
||||
- Error recovery patterns
|
||||
- Retry implementation approaches
|
||||
- Authentication flow patterns
|
||||
- Validation timing and methods
|
||||
|
||||
### 2. Facilitate Pattern Decisions
|
||||
|
||||
For each conflict category, facilitate collaborative pattern definition:
|
||||
|
||||
**Present the Conflict Point:**
|
||||
"Given that we're using {{tech_stack}}, different AI agents might handle {{conflict_area}} differently.
|
||||
|
||||
For example, one agent might name database tables 'users' while another uses 'Users' - this would cause conflicts.
|
||||
|
||||
We need to establish consistent patterns that all agents follow."
|
||||
|
||||
**Show Options and Trade-offs:**
|
||||
"Common approaches for {{pattern_category}}:
|
||||
|
||||
1. {{option_1}} - {{pros_and_cons}}
|
||||
2. {{option_2}} - {{pros_and_cons}}
|
||||
3. {{option_3}} - {{pros_and_cons}}
|
||||
|
||||
Which approach makes the most sense for our project?"
|
||||
|
||||
**Get User Decision:**
|
||||
"What's your preference for this pattern? (or discuss the trade-offs more)"
|
||||
|
||||
### 3. Define Pattern Categories
|
||||
|
||||
#### Naming Patterns
|
||||
|
||||
**Database Naming:**
|
||||
|
||||
- Table naming: users, Users, or user?
|
||||
- Column naming: user_id or userId?
|
||||
- Foreign key format: user_id or fk_user?
|
||||
- Index naming: idx_users_email or users_email_index?
|
||||
|
||||
**API Naming:**
|
||||
|
||||
- REST endpoint naming: /users or /user? Plural or singular?
|
||||
- Route parameter format: :id or {id}?
|
||||
- Query parameter naming: user_id or userId?
|
||||
- Header naming conventions: X-Custom-Header or Custom-Header?
|
||||
|
||||
**Code Naming:**
|
||||
|
||||
- Component naming: UserCard or user-card?
|
||||
- File naming: UserCard.tsx or user-card.tsx?
|
||||
- Function naming: getUserData or get_user_data?
|
||||
- Variable naming: userId or user_id?
|
||||
|
||||
#### Structure Patterns
|
||||
|
||||
**Project Organization:**
|
||||
|
||||
- Where do tests live? **tests**/ or \*.test.ts co-located?
|
||||
- How are components organized? By feature or by type?
|
||||
- Where do shared utilities go?
|
||||
- How are services and repositories organized?
|
||||
|
||||
**File Structure:**
|
||||
|
||||
- Config file locations and naming
|
||||
- Static asset organization
|
||||
- Documentation placement
|
||||
- Environment file organization
|
||||
|
||||
#### Format Patterns
|
||||
|
||||
**API Formats:**
|
||||
|
||||
- API response wrapper? {data: ..., error: ...} or direct response?
|
||||
- Error format? {message, code} or {error: {type, detail}}?
|
||||
- Date format in JSON? ISO strings or timestamps?
|
||||
- Success response structure?
|
||||
|
||||
**Data Formats:**
|
||||
|
||||
- JSON field naming: snake_case or camelCase?
|
||||
- Boolean representations: true/false or 1/0?
|
||||
- Null handling patterns
|
||||
- Array vs object for single items
|
||||
|
||||
#### Communication Patterns
|
||||
|
||||
**Event Systems:**
|
||||
|
||||
- Event naming convention: user.created or UserCreated?
|
||||
- Event payload structure standards
|
||||
- Event versioning approach
|
||||
- Async event handling patterns
|
||||
|
||||
**State Management:**
|
||||
|
||||
- State update patterns: immutable updates or direct mutation?
|
||||
- Action naming conventions
|
||||
- Selector patterns
|
||||
- State organization principles
|
||||
|
||||
#### Process Patterns
|
||||
|
||||
**Error Handling:**
|
||||
|
||||
- Global error handling approach
|
||||
- Error boundary patterns
|
||||
- User-facing error message format
|
||||
- Logging vs user error distinction
|
||||
|
||||
**Loading States:**
|
||||
|
||||
- Loading state naming conventions
|
||||
- Global vs local loading states
|
||||
- Loading state persistence
|
||||
- Loading UI patterns
|
||||
|
||||
### 4. Generate Patterns Content
|
||||
|
||||
Prepare the content to append to the document:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
```markdown
|
||||
## Implementation Patterns & Consistency Rules
|
||||
|
||||
### Pattern Categories Defined
|
||||
|
||||
**Critical Conflict Points Identified:**
|
||||
{{number_of_potential_conflicts}} areas where AI agents could make different choices
|
||||
|
||||
### Naming Patterns
|
||||
|
||||
**Database Naming Conventions:**
|
||||
{{database_naming_rules_with_examples}}
|
||||
|
||||
**API Naming Conventions:**
|
||||
{{api_naming_rules_with_examples}}
|
||||
|
||||
**Code Naming Conventions:**
|
||||
{{code_naming_rules_with_examples}}
|
||||
|
||||
### Structure Patterns
|
||||
|
||||
**Project Organization:**
|
||||
{{project_structure_rules_with_examples}}
|
||||
|
||||
**File Structure Patterns:**
|
||||
{{file_organization_rules_with_examples}}
|
||||
|
||||
### Format Patterns
|
||||
|
||||
**API Response Formats:**
|
||||
{{api_response_structure_rules}}
|
||||
|
||||
**Data Exchange Formats:**
|
||||
{{data_format_rules_with_examples}}
|
||||
|
||||
### Communication Patterns
|
||||
|
||||
**Event System Patterns:**
|
||||
{{event_naming_and_structure_rules}}
|
||||
|
||||
**State Management Patterns:**
|
||||
{{state_update_and_organization_rules}}
|
||||
|
||||
### Process Patterns
|
||||
|
||||
**Error Handling Patterns:**
|
||||
{{consistent_error_handling_approaches}}
|
||||
|
||||
**Loading State Patterns:**
|
||||
{{loading_state_management_rules}}
|
||||
|
||||
### Enforcement Guidelines
|
||||
|
||||
**All AI Agents MUST:**
|
||||
|
||||
- {{mandatory_pattern_1}}
|
||||
- {{mandatory_pattern_2}}
|
||||
- {{mandatory_pattern_3}}
|
||||
|
||||
**Pattern Enforcement:**
|
||||
|
||||
- How to verify patterns are followed
|
||||
- Where to document pattern violations
|
||||
- Process for updating patterns
|
||||
|
||||
### Pattern Examples
|
||||
|
||||
**Good Examples:**
|
||||
{{concrete_examples_of_correct_pattern_usage}}
|
||||
|
||||
**Anti-Patterns:**
|
||||
{{examples_of_what_to_avoid}}
|
||||
```
|
||||
|
||||
### 5. Present Content and Menu
|
||||
|
||||
Show the generated patterns content and present choices:
|
||||
|
||||
"I've documented implementation patterns that will prevent conflicts between AI agents working on this project.
|
||||
|
||||
**Here's what I'll add to the document:**
|
||||
|
||||
[Show the complete markdown content from step 4]
|
||||
|
||||
**What would you like to do?**
|
||||
[A] Advanced Elicitation - Explore additional consistency patterns
|
||||
[P] Party Mode - Review patterns from different implementation perspectives
|
||||
[C] Continue - Save these patterns and move to project structure"
|
||||
|
||||
### 6. Handle Menu Selection
|
||||
|
||||
#### If 'A' (Advanced Elicitation):
|
||||
|
||||
- Invoke the `bmad-advanced-elicitation` skill with current patterns
|
||||
- Process enhanced consistency rules that come back
|
||||
- Ask user: "Accept these additional pattern refinements? (y/n)"
|
||||
- If yes: Update content, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'P' (Party Mode):
|
||||
|
||||
- Invoke the `bmad-party-mode` skill with implementation patterns context
|
||||
- Process collaborative insights about potential conflicts
|
||||
- Ask user: "Accept these changes to the implementation patterns? (y/n)"
|
||||
- If yes: Update content, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to `{planning_artifacts}/architecture.md`
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5]`
|
||||
- Load `./step-06-structure.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from step 4.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ All potential AI agent conflict points identified and addressed
|
||||
✅ Comprehensive patterns defined for naming, structure, and communication
|
||||
✅ Concrete examples provided for each pattern
|
||||
✅ Enforcement guidelines clearly documented
|
||||
✅ User collaborated on pattern decisions rather than receiving recommendations
|
||||
✅ A/P/C menu presented and handled correctly
|
||||
✅ Content properly appended to document when C selected
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Missing potential conflict points that could cause agent conflicts
|
||||
❌ Being too prescriptive about implementation details instead of focusing on consistency
|
||||
❌ Not providing concrete examples for each pattern
|
||||
❌ Failing to address cross-cutting concerns like error handling
|
||||
❌ Not considering the chosen technology stack when defining patterns
|
||||
❌ Not presenting A/P/C menu after content generation
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved to document, load `./step-06-structure.md` to define the complete project structure.
|
||||
|
||||
Remember: Do NOT proceed to step-06 until user explicitly selects 'C' from the A/P/C menu and content is saved!
|
||||
@@ -1,379 +0,0 @@
|
||||
# Step 6: Project Structure & Boundaries
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ ALWAYS treat this as collaborative discovery between architectural peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on defining complete project structure and clear boundaries
|
||||
- 🗺️ MAP requirements/epics to architectural components
|
||||
- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- 🗺️ Create complete project tree, not generic placeholders
|
||||
- ⚠️ Present A/P/C menu after generating project structure
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## COLLABORATION MENUS (A/P/C):
|
||||
|
||||
This step will generate content and present choices:
|
||||
|
||||
- **A (Advanced Elicitation)**: Use discovery protocols to explore innovative project organization approaches
|
||||
- **P (Party Mode)**: Bring multiple perspectives to evaluate project structure trade-offs
|
||||
- **C (Continue)**: Save the project structure and proceed to validation
|
||||
|
||||
## PROTOCOL INTEGRATION:
|
||||
|
||||
- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
|
||||
- When 'P' selected: Invoke the `bmad-party-mode` skill
|
||||
- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
|
||||
- User accepts/rejects protocol changes before proceeding
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- All previous architectural decisions are complete
|
||||
- Implementation patterns and consistency rules are defined
|
||||
- Focus on physical project structure and component boundaries
|
||||
- Map requirements to specific files and directories
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Define the complete project structure and architectural boundaries based on all decisions made, creating a concrete implementation guide for AI agents.
|
||||
|
||||
## PROJECT STRUCTURE SEQUENCE:
|
||||
|
||||
### 1. Analyze Requirements Mapping
|
||||
|
||||
Map project requirements to architectural components:
|
||||
|
||||
**From Epics (if available):**
|
||||
"Epic: {{epic_name}} → Lives in {{module/directory/service}}"
|
||||
|
||||
- User stories within the epic
|
||||
- Cross-epic dependencies
|
||||
- Shared components needed
|
||||
|
||||
**From FR Categories (if no epics):**
|
||||
"FR Category: {{fr_category_name}} → Lives in {{module/directory/service}}"
|
||||
|
||||
- Related functional requirements
|
||||
- Shared functionality across categories
|
||||
- Integration points between categories
|
||||
|
||||
### 2. Define Project Directory Structure
|
||||
|
||||
Based on technology stack and patterns, create the complete project structure:
|
||||
|
||||
**Root Configuration Files:**
|
||||
|
||||
- Package management files (package.json, requirements.txt, etc.)
|
||||
- Build and development configuration
|
||||
- Environment configuration files
|
||||
- CI/CD pipeline files
|
||||
- Documentation files
|
||||
|
||||
**Source Code Organization:**
|
||||
|
||||
- Application entry points
|
||||
- Core application structure
|
||||
- Feature/module organization
|
||||
- Shared utilities and libraries
|
||||
- Configuration and environment files
|
||||
|
||||
**Test Organization:**
|
||||
|
||||
- Unit test locations and structure
|
||||
- Integration test organization
|
||||
- End-to-end test structure
|
||||
- Test utilities and fixtures
|
||||
|
||||
**Build and Distribution:**
|
||||
|
||||
- Build output directories
|
||||
- Distribution files
|
||||
- Static assets
|
||||
- Documentation build
|
||||
|
||||
### 3. Define Integration Boundaries
|
||||
|
||||
Map how components communicate and where boundaries exist:
|
||||
|
||||
**API Boundaries:**
|
||||
|
||||
- External API endpoints
|
||||
- Internal service boundaries
|
||||
- Authentication and authorization boundaries
|
||||
- Data access layer boundaries
|
||||
|
||||
**Component Boundaries:**
|
||||
|
||||
- Frontend component communication patterns
|
||||
- State management boundaries
|
||||
- Service communication patterns
|
||||
- Event-driven integration points
|
||||
|
||||
**Data Boundaries:**
|
||||
|
||||
- Database schema boundaries
|
||||
- Data access patterns
|
||||
- Caching boundaries
|
||||
- External data integration points
|
||||
|
||||
### 4. Create Complete Project Tree
|
||||
|
||||
Generate a comprehensive directory structure showing all files and directories:
|
||||
|
||||
**Technology-Specific Structure Examples:**
|
||||
|
||||
**Next.js Full-Stack:**
|
||||
|
||||
```
|
||||
project-name/
|
||||
├── README.md
|
||||
├── package.json
|
||||
├── next.config.js
|
||||
├── tailwind.config.js
|
||||
├── tsconfig.json
|
||||
├── .env.local
|
||||
├── .env.example
|
||||
├── .gitignore
|
||||
├── .github/
|
||||
│ └── workflows/
|
||||
│ └── ci.yml
|
||||
├── src/
|
||||
│ ├── app/
|
||||
│ │ ├── globals.css
|
||||
│ │ ├── layout.tsx
|
||||
│ │ └── page.tsx
|
||||
│ ├── components/
|
||||
│ │ ├── ui/
|
||||
│ │ ├── forms/
|
||||
│ │ └── features/
|
||||
│ ├── lib/
|
||||
│ │ ├── db.ts
|
||||
│ │ ├── auth.ts
|
||||
│ │ └── utils.ts
|
||||
│ ├── types/
|
||||
│ └── middleware.ts
|
||||
├── prisma/
|
||||
│ ├── schema.prisma
|
||||
│ └── migrations/
|
||||
├── tests/
|
||||
│ ├── __mocks__/
|
||||
│ ├── components/
|
||||
│ └── e2e/
|
||||
└── public/
|
||||
└── assets/
|
||||
```
|
||||
|
||||
**API Backend (NestJS):**
|
||||
|
||||
```
|
||||
project-name/
|
||||
├── package.json
|
||||
├── nest-cli.json
|
||||
├── tsconfig.json
|
||||
├── .env
|
||||
├── .env.example
|
||||
├── .gitignore
|
||||
├── README.md
|
||||
├── src/
|
||||
│ ├── main.ts
|
||||
│ ├── app.module.ts
|
||||
│ ├── config/
|
||||
│ ├── modules/
|
||||
│ │ ├── auth/
|
||||
│ │ ├── users/
|
||||
│ │ └── common/
|
||||
│ ├── services/
|
||||
│ ├── repositories/
|
||||
│ ├── decorators/
|
||||
│ ├── pipes/
|
||||
│ ├── guards/
|
||||
│ └── interceptors/
|
||||
├── test/
|
||||
│ ├── unit/
|
||||
│ ├── integration/
|
||||
│ └── e2e/
|
||||
├── prisma/
|
||||
│ ├── schema.prisma
|
||||
│ └── migrations/
|
||||
└── docker-compose.yml
|
||||
```
|
||||
|
||||
### 5. Map Requirements to Structure
|
||||
|
||||
Create explicit mapping from project requirements to specific files/directories:
|
||||
|
||||
**Epic/Feature Mapping:**
|
||||
"Epic: User Management
|
||||
|
||||
- Components: src/components/features/users/
|
||||
- Services: src/services/users/
|
||||
- API Routes: src/app/api/users/
|
||||
- Database: prisma/migrations/_*users*_
|
||||
- Tests: tests/features/users/"
|
||||
|
||||
**Cross-Cutting Concerns:**
|
||||
"Authentication System
|
||||
|
||||
- Components: src/components/auth/
|
||||
- Services: src/services/auth/
|
||||
- Middleware: src/middleware/auth.ts
|
||||
- Guards: src/guards/auth.guard.ts
|
||||
- Tests: tests/auth/"
|
||||
|
||||
### 6. Generate Structure Content
|
||||
|
||||
Prepare the content to append to the document:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
```markdown
|
||||
## Project Structure & Boundaries
|
||||
|
||||
### Complete Project Directory Structure
|
||||
```
|
||||
|
||||
{{complete_project_tree_with_all_files_and_directories}}
|
||||
|
||||
```
|
||||
|
||||
### Architectural Boundaries
|
||||
|
||||
**API Boundaries:**
|
||||
{{api_boundary_definitions_and_endpoints}}
|
||||
|
||||
**Component Boundaries:**
|
||||
{{component_communication_patterns_and_boundaries}}
|
||||
|
||||
**Service Boundaries:**
|
||||
{{service_integration_patterns_and_boundaries}}
|
||||
|
||||
**Data Boundaries:**
|
||||
{{data_access_patterns_and_boundaries}}
|
||||
|
||||
### Requirements to Structure Mapping
|
||||
|
||||
**Feature/Epic Mapping:**
|
||||
{{mapping_of_epics_or_features_to_specific_directories}}
|
||||
|
||||
**Cross-Cutting Concerns:**
|
||||
{{mapping_of_shared_functionality_to_locations}}
|
||||
|
||||
### Integration Points
|
||||
|
||||
**Internal Communication:**
|
||||
{{how_components_within_the_project_communicate}}
|
||||
|
||||
**External Integrations:**
|
||||
{{third_party_service_integration_points}}
|
||||
|
||||
**Data Flow:**
|
||||
{{how_data_flows_through_the_architecture}}
|
||||
|
||||
### File Organization Patterns
|
||||
|
||||
**Configuration Files:**
|
||||
{{where_and_how_config_files_are_organized}}
|
||||
|
||||
**Source Organization:**
|
||||
{{how_source_code_is_structured_and_organized}}
|
||||
|
||||
**Test Organization:**
|
||||
{{how_tests_are_structured_and_organized}}
|
||||
|
||||
**Asset Organization:**
|
||||
{{how_static_and_dynamic_assets_are_organized}}
|
||||
|
||||
### Development Workflow Integration
|
||||
|
||||
**Development Server Structure:**
|
||||
{{how_the_project_is organized_for_development}}
|
||||
|
||||
**Build Process Structure:**
|
||||
{{how_the_build_process_uses_the_project_structure}}
|
||||
|
||||
**Deployment Structure:**
|
||||
{{how_the_project_structure_supports_deployment}}
|
||||
```
|
||||
|
||||
### 7. Present Content and Menu
|
||||
|
||||
Show the generated project structure content and present choices:
|
||||
|
||||
"I've created a complete project structure based on all our architectural decisions.
|
||||
|
||||
**Here's what I'll add to the document:**
|
||||
|
||||
[Show the complete markdown content from step 6]
|
||||
|
||||
**What would you like to do?**
|
||||
[A] Advanced Elicitation - Explore innovative project organization approaches
|
||||
[P] Party Mode - Review structure from different development perspectives
|
||||
[C] Continue - Save this structure and move to architecture validation"
|
||||
|
||||
### 8. Handle Menu Selection
|
||||
|
||||
#### If 'A' (Advanced Elicitation):
|
||||
|
||||
- Invoke the `bmad-advanced-elicitation` skill with current project structure
|
||||
- Process enhanced organizational insights that come back
|
||||
- Ask user: "Accept these changes to the project structure? (y/n)"
|
||||
- If yes: Update content, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'P' (Party Mode):
|
||||
|
||||
- Invoke the `bmad-party-mode` skill with project structure context
|
||||
- Process collaborative insights about organization trade-offs
|
||||
- Ask user: "Accept these changes to the project structure? (y/n)"
|
||||
- If yes: Update content, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to `{planning_artifacts}/architecture.md`
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5, 6]`
|
||||
- Load `./step-07-validation.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from step 6.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Complete project tree defined with all files and directories
|
||||
✅ All architectural boundaries clearly documented
|
||||
✅ Requirements/epics mapped to specific locations
|
||||
✅ Integration points and communication patterns defined
|
||||
✅ Project structure aligned with chosen technology stack
|
||||
✅ A/P/C menu presented and handled correctly
|
||||
✅ Content properly appended to document when C selected
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Creating generic placeholder structure instead of specific, complete tree
|
||||
❌ Not mapping requirements to specific files and directories
|
||||
❌ Missing important integration boundaries
|
||||
❌ Not considering the chosen technology stack in structure design
|
||||
❌ Not defining how components communicate across boundaries
|
||||
❌ Not presenting A/P/C menu after content generation
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved to document, load `./step-07-validation.md` to validate architectural coherence and completeness.
|
||||
|
||||
Remember: Do NOT proceed to step-07 until user explicitly selects 'C' from the A/P/C menu and content is saved!
|
||||
@@ -1,359 +0,0 @@
|
||||
# Step 7: Architecture Validation & Completion
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ ALWAYS treat this as collaborative discovery between architectural peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on validating architectural coherence and completeness
|
||||
- ✅ VALIDATE all requirements are covered by architectural decisions
|
||||
- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ✅ Run comprehensive validation checks on the complete architecture
|
||||
- ⚠️ Present A/P/C menu after generating validation results
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6, 7]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## COLLABORATION MENUS (A/P/C):
|
||||
|
||||
This step will generate content and present choices:
|
||||
|
||||
- **A (Advanced Elicitation)**: Use discovery protocols to address complex architectural issues found during validation
|
||||
- **P (Party Mode)**: Bring multiple perspectives to resolve validation concerns
|
||||
- **C (Continue)**: Save the validation results and complete the architecture
|
||||
|
||||
## PROTOCOL INTEGRATION:
|
||||
|
||||
- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
|
||||
- When 'P' selected: Invoke the `bmad-party-mode` skill
|
||||
- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
|
||||
- User accepts/rejects protocol changes before proceeding
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Complete architecture document with all sections is available
|
||||
- All architectural decisions, patterns, and structure are defined
|
||||
- Focus on validation, gap analysis, and coherence checking
|
||||
- Prepare for handoff to implementation phase
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Validate the complete architecture for coherence, completeness, and readiness to guide AI agents through consistent implementation.
|
||||
|
||||
## VALIDATION SEQUENCE:
|
||||
|
||||
### 1. Coherence Validation
|
||||
|
||||
Check that all architectural decisions work together:
|
||||
|
||||
**Decision Compatibility:**
|
||||
|
||||
- Do all technology choices work together without conflicts?
|
||||
- Are all versions compatible with each other?
|
||||
- Do patterns align with technology choices?
|
||||
- Are there any contradictory decisions?
|
||||
|
||||
**Pattern Consistency:**
|
||||
|
||||
- Do implementation patterns support the architectural decisions?
|
||||
- Are naming conventions consistent across all areas?
|
||||
- Do structure patterns align with technology stack?
|
||||
- Are communication patterns coherent?
|
||||
|
||||
**Structure Alignment:**
|
||||
|
||||
- Does the project structure support all architectural decisions?
|
||||
- Are boundaries properly defined and respected?
|
||||
- Does the structure enable the chosen patterns?
|
||||
- Are integration points properly structured?
|
||||
|
||||
### 2. Requirements Coverage Validation
|
||||
|
||||
Verify all project requirements are architecturally supported:
|
||||
|
||||
**From Epics (if available):**
|
||||
|
||||
- Does every epic have architectural support?
|
||||
- Are all user stories implementable with these decisions?
|
||||
- Are cross-epic dependencies handled architecturally?
|
||||
- Are there any gaps in epic coverage?
|
||||
|
||||
**From FR Categories (if no epics):**
|
||||
|
||||
- Does every functional requirement have architectural support?
|
||||
- Are all FR categories fully covered by architectural decisions?
|
||||
- Are cross-cutting FRs properly addressed?
|
||||
- Are there any missing architectural capabilities?
|
||||
|
||||
**Non-Functional Requirements:**
|
||||
|
||||
- Are performance requirements addressed architecturally?
|
||||
- Are security requirements fully covered?
|
||||
- Are scalability considerations properly handled?
|
||||
- Are compliance requirements architecturally supported?
|
||||
|
||||
### 3. Implementation Readiness Validation
|
||||
|
||||
Assess if AI agents can implement consistently:
|
||||
|
||||
**Decision Completeness:**
|
||||
|
||||
- Are all critical decisions documented with versions?
|
||||
- Are implementation patterns comprehensive enough?
|
||||
- Are consistency rules clear and enforceable?
|
||||
- Are examples provided for all major patterns?
|
||||
|
||||
**Structure Completeness:**
|
||||
|
||||
- Is the project structure complete and specific?
|
||||
- Are all files and directories defined?
|
||||
- Are integration points clearly specified?
|
||||
- Are component boundaries well-defined?
|
||||
|
||||
**Pattern Completeness:**
|
||||
|
||||
- Are all potential conflict points addressed?
|
||||
- Are naming conventions comprehensive?
|
||||
- Are communication patterns fully specified?
|
||||
- Are process patterns (error handling, etc.) complete?
|
||||
|
||||
### 4. Gap Analysis
|
||||
|
||||
Identify and document any missing elements:
|
||||
|
||||
**Critical Gaps:**
|
||||
|
||||
- Missing architectural decisions that block implementation
|
||||
- Incomplete patterns that could cause conflicts
|
||||
- Missing structural elements needed for development
|
||||
- Undefined integration points
|
||||
|
||||
**Important Gaps:**
|
||||
|
||||
- Areas that need more detailed specification
|
||||
- Patterns that could be more comprehensive
|
||||
- Documentation that would help implementation
|
||||
- Examples that would clarify complex decisions
|
||||
|
||||
**Nice-to-Have Gaps:**
|
||||
|
||||
- Additional patterns that would be helpful
|
||||
- Supplementary documentation
|
||||
- Tooling recommendations
|
||||
- Development workflow optimizations
|
||||
|
||||
### 5. Address Validation Issues
|
||||
|
||||
For any issues found, facilitate resolution:
|
||||
|
||||
**Critical Issues:**
|
||||
"I found some issues that need to be addressed before implementation:
|
||||
|
||||
{{critical_issue_description}}
|
||||
|
||||
These could cause implementation problems. How would you like to resolve this?"
|
||||
|
||||
**Important Issues:**
|
||||
"I noticed a few areas that could be improved:
|
||||
|
||||
{{important_issue_description}}
|
||||
|
||||
These aren't blocking, but addressing them would make implementation smoother. Should we work on these?"
|
||||
|
||||
**Minor Issues:**
|
||||
"Here are some minor suggestions for improvement:
|
||||
|
||||
{{minor_issue_description}}
|
||||
|
||||
These are optional refinements. Would you like to address any of these?"
|
||||
|
||||
### 6. Generate Validation Content
|
||||
|
||||
Prepare the content to append to the document:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
```markdown
|
||||
## Architecture Validation Results
|
||||
|
||||
### Coherence Validation ✅
|
||||
|
||||
**Decision Compatibility:**
|
||||
{{assessment_of_how_all_decisions_work_together}}
|
||||
|
||||
**Pattern Consistency:**
|
||||
{{verification_that_patterns_support_decisions}}
|
||||
|
||||
**Structure Alignment:**
|
||||
{{confirmation_that_structure_supports_architecture}}
|
||||
|
||||
### Requirements Coverage Validation ✅
|
||||
|
||||
**Epic/Feature Coverage:**
|
||||
{{verification_that_all_epics_or_features_are_supported}}
|
||||
|
||||
**Functional Requirements Coverage:**
|
||||
{{confirmation_that_all_FRs_are_architecturally_supported}}
|
||||
|
||||
**Non-Functional Requirements Coverage:**
|
||||
{{verification_that_NFRs_are_addressed}}
|
||||
|
||||
### Implementation Readiness Validation ✅
|
||||
|
||||
**Decision Completeness:**
|
||||
{{assessment_of_decision_documentation_completeness}}
|
||||
|
||||
**Structure Completeness:**
|
||||
{{evaluation_of_project_structure_completeness}}
|
||||
|
||||
**Pattern Completeness:**
|
||||
{{verification_of_implementation_patterns_completeness}}
|
||||
|
||||
### Gap Analysis Results
|
||||
|
||||
{{gap_analysis_findings_with_priority_levels}}
|
||||
|
||||
### Validation Issues Addressed
|
||||
|
||||
{{description_of_any_issues_found_and_resolutions}}
|
||||
|
||||
### Architecture Completeness Checklist
|
||||
|
||||
**✅ Requirements Analysis**
|
||||
|
||||
- [x] Project context thoroughly analyzed
|
||||
- [x] Scale and complexity assessed
|
||||
- [x] Technical constraints identified
|
||||
- [x] Cross-cutting concerns mapped
|
||||
|
||||
**✅ Architectural Decisions**
|
||||
|
||||
- [x] Critical decisions documented with versions
|
||||
- [x] Technology stack fully specified
|
||||
- [x] Integration patterns defined
|
||||
- [x] Performance considerations addressed
|
||||
|
||||
**✅ Implementation Patterns**
|
||||
|
||||
- [x] Naming conventions established
|
||||
- [x] Structure patterns defined
|
||||
- [x] Communication patterns specified
|
||||
- [x] Process patterns documented
|
||||
|
||||
**✅ Project Structure**
|
||||
|
||||
- [x] Complete directory structure defined
|
||||
- [x] Component boundaries established
|
||||
- [x] Integration points mapped
|
||||
- [x] Requirements to structure mapping complete
|
||||
|
||||
### Architecture Readiness Assessment
|
||||
|
||||
**Overall Status:** READY FOR IMPLEMENTATION
|
||||
|
||||
**Confidence Level:** {{high/medium/low}} based on validation results
|
||||
|
||||
**Key Strengths:**
|
||||
{{list_of_architecture_strengths}}
|
||||
|
||||
**Areas for Future Enhancement:**
|
||||
{{areas_that_could_be_improved_later}}
|
||||
|
||||
### Implementation Handoff
|
||||
|
||||
**AI Agent Guidelines:**
|
||||
|
||||
- Follow all architectural decisions exactly as documented
|
||||
- Use implementation patterns consistently across all components
|
||||
- Respect project structure and boundaries
|
||||
- Refer to this document for all architectural questions
|
||||
|
||||
**First Implementation Priority:**
|
||||
{{starter_template_command_or_first_architectural_step}}
|
||||
```
|
||||
|
||||
### 7. Present Content and Menu
|
||||
|
||||
Show the validation results and present choices:
|
||||
|
||||
"I've completed a comprehensive validation of your architecture.
|
||||
|
||||
**Validation Summary:**
|
||||
|
||||
- ✅ Coherence: All decisions work together
|
||||
- ✅ Coverage: All requirements are supported
|
||||
- ✅ Readiness: AI agents can implement consistently
|
||||
|
||||
**Here's what I'll add to complete the architecture document:**
|
||||
|
||||
[Show the complete markdown content from step 6]
|
||||
|
||||
**What would you like to do?**
|
||||
[A] Advanced Elicitation - Address any complex architectural concerns
|
||||
[P] Party Mode - Review validation from different implementation perspectives
|
||||
[C] Continue - Complete the architecture and finish workflow
|
||||
|
||||
### 8. Handle Menu Selection
|
||||
|
||||
#### If 'A' (Advanced Elicitation):
|
||||
|
||||
- Invoke the `bmad-advanced-elicitation` skill with validation issues
|
||||
- Process enhanced solutions for complex concerns
|
||||
- Ask user: "Accept these architectural improvements? (y/n)"
|
||||
- If yes: Update content, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'P' (Party Mode):
|
||||
|
||||
- Invoke the `bmad-party-mode` skill with validation context
|
||||
- Process collaborative insights on implementation readiness
|
||||
- Ask user: "Accept these changes to the validation results? (y/n)"
|
||||
- If yes: Update content, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to `{planning_artifacts}/architecture.md`
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5, 6, 7]`
|
||||
- Load `./step-08-complete.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from step 6.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ All architectural decisions validated for coherence
|
||||
✅ Complete requirements coverage verified
|
||||
✅ Implementation readiness confirmed
|
||||
✅ All gaps identified and addressed
|
||||
✅ Comprehensive validation checklist completed
|
||||
✅ A/P/C menu presented and handled correctly
|
||||
✅ Content properly appended to document when C selected
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Skipping validation of decision compatibility
|
||||
❌ Not verifying all requirements are architecturally supported
|
||||
❌ Missing potential implementation conflicts
|
||||
❌ Not addressing gaps found during validation
|
||||
❌ Providing incomplete validation checklist
|
||||
❌ Not presenting A/P/C menu after content generation
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved to document, load `./step-08-complete.md` to complete the workflow and provide implementation guidance.
|
||||
|
||||
Remember: Do NOT proceed to step-08 until user explicitly selects 'C' from the A/P/C menu and content is saved!
|
||||
@@ -1,82 +0,0 @@
|
||||
# Step 8: Architecture Completion & Handoff
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- ✅ ALWAYS treat this as collaborative completion between architectural peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on successful workflow completion and implementation handoff
|
||||
- 🎯 PROVIDE clear next steps for implementation phase
|
||||
- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- 🎯 Present completion summary and implementation guidance
|
||||
- 📖 Update frontmatter with final workflow state
|
||||
- 🚫 THIS IS THE FINAL STEP IN THIS WORKFLOW
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Complete the architecture workflow, provide a comprehensive completion summary, and guide the user to the next phase of their project development.
|
||||
|
||||
## COMPLETION SEQUENCE:
|
||||
|
||||
### 1. Congratulate the User on Completion
|
||||
|
||||
Both you and the User completed something amazing here - give a summary of what you achieved together and really congratulate the user on a job well done.
|
||||
|
||||
### 2. Update the created document's frontmatter
|
||||
|
||||
```yaml
|
||||
stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8]
|
||||
workflowType: 'architecture'
|
||||
lastStep: 8
|
||||
status: 'complete'
|
||||
completedAt: '{{current_date}}'
|
||||
```
|
||||
|
||||
### 3. Next Steps Guidance
|
||||
|
||||
Architecture complete. Invoke the `bmad-help` skill.
|
||||
|
||||
Upon Completion of task output: offer to answer any questions about the Architecture Document.
|
||||
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Complete architecture document delivered with all sections
|
||||
✅ All architectural decisions documented and validated
|
||||
✅ Implementation patterns and consistency rules finalized
|
||||
✅ Project structure complete with all files and directories
|
||||
✅ User provided with clear next steps and implementation guidance
|
||||
✅ Workflow status properly updated
|
||||
✅ User collaboration maintained throughout completion process
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Not providing clear implementation guidance
|
||||
❌ Missing final validation of document completeness
|
||||
❌ Not updating workflow status appropriately
|
||||
❌ Failing to celebrate the successful completion
|
||||
❌ Not providing specific next steps for the user
|
||||
❌ Rushing completion without proper summary
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## WORKFLOW COMPLETE:
|
||||
|
||||
This is the final step of the Architecture workflow. The user now has a complete, validated architecture document ready for AI agent implementation.
|
||||
|
||||
The architecture will serve as the single source of truth for all technical decisions, ensuring consistent implementation across the entire project development lifecycle.
|
||||
|
||||
## On Complete
|
||||
|
||||
Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete`
|
||||
|
||||
If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.
|
||||
@@ -86,7 +86,7 @@ Greet `{user_name}`, speaking in `{communication_language}`.
|
||||
|
||||
Execute each entry in `{workflow.activation_steps_append}` in order.
|
||||
|
||||
Activation is complete. Begin the workflow below.
|
||||
Activation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.
|
||||
|
||||
## Execution
|
||||
|
||||
|
||||
@@ -48,7 +48,7 @@ Verify required documents exist and are complete:
|
||||
|
||||
1. **PRD.md** - Contains requirements (FRs and NFRs) and product scope
|
||||
2. **Architecture.md** - Contains technical decisions, API contracts, data models
|
||||
3. **UX Design.md** (if UI exists) - Contains interaction patterns, mockups, user flows
|
||||
3. **UX design contract** (if UI exists) - Contains visual identity, interaction patterns, mockups, and user flows
|
||||
|
||||
### 2. Document Discovery and Validation
|
||||
|
||||
@@ -66,8 +66,16 @@ Search for required documents using these patterns (sharded means a large docume
|
||||
|
||||
**UX Design Document Search (Optional):**
|
||||
|
||||
1. `{planning_artifacts}/*ux*.md` (whole document)
|
||||
2. `{planning_artifacts}/*ux*/index.md` (sharded version)
|
||||
1. `{planning_artifacts}/ux-designs/ux-*/DESIGN.md` and `{planning_artifacts}/ux-designs/ux-*/EXPERIENCE.md` (bmad-ux spine pair)
|
||||
2. `{planning_artifacts}/*ux*.md` (legacy whole document)
|
||||
3. `{planning_artifacts}/*ux*/index.md` (legacy sharded version)
|
||||
|
||||
For each matching bmad-ux run folder, treat `DESIGN.md` and `EXPERIENCE.md` as one UX design contract:
|
||||
|
||||
- Confirm and load both files together. `DESIGN.md` owns visual identity and design tokens; `EXPERIENCE.md` owns information architecture, behavior, states, interactions, accessibility, and journeys.
|
||||
- Add both files to the `inputDocuments: []` frontmatter array.
|
||||
- If only one spine exists, report the incomplete pair and ask whether the user wants to include the partial UX handoff.
|
||||
- If multiple run folders match, show each run folder with the spine frontmatter `status` and `updated` values when available, then ask the user which UX design contract to include.
|
||||
|
||||
Before proceeding, Ask the user if there are any other documents to include for analysis, and if anything found should be excluded. Wait for user confirmation. Once confirmed, create the {planning_artifacts}/epics.md from the ../templates/epics-template.md and in the front matter list the files in the array of `inputDocuments: []`.
|
||||
|
||||
@@ -136,7 +144,7 @@ Review the Architecture document for technical requirements that impact epic and
|
||||
|
||||
**IMPORTANT**: The UX Design Specification is a first-class input document, not supplementary material. Requirements from the UX spec must be extracted with the same rigor as PRD functional requirements.
|
||||
|
||||
Read the FULL UX Design document and extract ALL actionable work items:
|
||||
Read the FULL UX design contract and extract ALL actionable work items. For a bmad-ux spine pair, read both `DESIGN.md` and `EXPERIENCE.md`:
|
||||
|
||||
**Look for:**
|
||||
|
||||
|
||||
@@ -55,7 +55,8 @@ Load {planning_artifacts}/epics.md and review:
|
||||
2. **Requirements Grouping**: Group related FRs that deliver cohesive user outcomes
|
||||
3. **Incremental Delivery**: Each epic should deliver value independently
|
||||
4. **Logical Flow**: Natural progression from user's perspective
|
||||
5. **🔗 Dependency-Free Within Epic**: Stories within an epic must NOT depend on future stories
|
||||
5. **Dependency-Free Within Epic**: Stories within an epic must NOT depend on future stories
|
||||
6. **Implementation Efficiency**: Consider consolidating epics that all modify the same core files into fewer epics
|
||||
|
||||
**⚠️ CRITICAL PRINCIPLE:**
|
||||
Organize by USER VALUE, not technical layers:
|
||||
@@ -74,6 +75,18 @@ Organize by USER VALUE, not technical layers:
|
||||
- Epic 3: Frontend Components (creates reusable components) - **No user value**
|
||||
- Epic 4: Deployment Pipeline (CI/CD setup) - **No user value**
|
||||
|
||||
**❌ WRONG Epic Examples (File Churn on Same Component):**
|
||||
|
||||
- Epic 1: File Upload (modifies model, controller, web form, web API)
|
||||
- Epic 2: File Status (modifies model, controller, web form, web API)
|
||||
- Epic 3: File Access permissions (modifies model, controller, web form, web API)
|
||||
- All three epics touch the same files — consolidate into one epic with ordered stories
|
||||
|
||||
**✅ CORRECT Alternative:**
|
||||
|
||||
- Epic 1: File Management Enhancement (upload, status, permissions as stories within one epic)
|
||||
- Rationale: Single component, fully pre-designed, no feedback loop between epics
|
||||
|
||||
**🔗 DEPENDENCY RULES:**
|
||||
|
||||
- Each epic must deliver COMPLETE functionality for its domain
|
||||
@@ -82,21 +95,38 @@ Organize by USER VALUE, not technical layers:
|
||||
|
||||
### 3. Design Epic Structure Collaboratively
|
||||
|
||||
**Step A: Identify User Value Themes**
|
||||
**Step A: Assess Context and Identify Themes**
|
||||
|
||||
First, assess how much of the solution design is already validated (Architecture, UX, Test Design).
|
||||
When the outcome is certain and direction changes between epics are unlikely, prefer fewer but larger epics.
|
||||
Split into multiple epics when there is a genuine risk boundary or when early feedback could change direction
|
||||
of following epics.
|
||||
|
||||
Then, identify user value themes:
|
||||
|
||||
- Look for natural groupings in the FRs
|
||||
- Identify user journeys or workflows
|
||||
- Consider user types and their goals
|
||||
|
||||
**Step B: Propose Epic Structure**
|
||||
For each proposed epic:
|
||||
|
||||
For each proposed epic (considering whether epics share the same core files):
|
||||
|
||||
1. **Epic Title**: User-centric, value-focused
|
||||
2. **User Outcome**: What users can accomplish after this epic
|
||||
3. **FR Coverage**: Which FR numbers this epic addresses
|
||||
4. **Implementation Notes**: Any technical or UX considerations
|
||||
|
||||
**Step C: Create the epics_list**
|
||||
**Step C: Review for File Overlap**
|
||||
|
||||
Assess whether multiple proposed epics repeatedly target the same core files. If overlap is significant:
|
||||
|
||||
- Distinguish meaningful overlap (same component end-to-end) from incidental sharing
|
||||
- Ask whether to consolidate into one epic with ordered stories
|
||||
- If confirmed, merge the epic FRs into a single epic, preserving dependency flow: each story must still fit within
|
||||
a single dev agent's context
|
||||
|
||||
**Step D: Create the epics_list**
|
||||
|
||||
Format the epics_list as:
|
||||
|
||||
|
||||
@@ -90,6 +90,12 @@ Review the complete epic and story breakdown to ensure EVERY FR is covered:
|
||||
- Dependencies flow naturally
|
||||
- Foundation stories only setup what's needed
|
||||
- No big upfront technical work
|
||||
- **File Churn Check:** Do multiple epics repeatedly modify the same core files?
|
||||
- Assess whether the overlap pattern suggests unnecessary churn or is incidental
|
||||
- If overlap is significant: Validate that splitting provides genuine value (risk mitigation, feedback loops, context size limits)
|
||||
- If no justification for the split: Recommend consolidation into fewer epics
|
||||
- ❌ WRONG: Multiple epics each modify the same core files with no feedback loop between them
|
||||
- ✅ RIGHT: Epics target distinct files/components, OR consolidation was explicitly considered and rejected with rationale
|
||||
|
||||
### 5. Dependency Validation (CRITICAL)
|
||||
|
||||
|
||||
@@ -1,104 +1,30 @@
|
||||
---
|
||||
name: bmad-create-prd
|
||||
description: 'Create a PRD from scratch. Use when the user says "lets create a product requirements document" or "I want to create a new PRD"'
|
||||
description: 'DEPRECATED — consolidated into bmad-prd create intent - this skill will be removed in v7 in favor of `bmad-prd`.'
|
||||
---
|
||||
|
||||
# PRD Create Workflow
|
||||
# DEPRECATED — forwards to bmad-prd (create intent)
|
||||
|
||||
**Goal:** Create comprehensive PRDs through structured workflow facilitation.
|
||||
|
||||
**Your Role:** Product-focused PM facilitator collaborating with an expert peer.
|
||||
|
||||
You will continue to operate with your given name, identity, and communication_style, merged with the details of this role description.
|
||||
|
||||
## Conventions
|
||||
|
||||
- Bare paths (e.g. `steps-c/step-01-init.md`) resolve from the skill root.
|
||||
- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
|
||||
- `{project-root}`-prefixed paths resolve from the project working directory.
|
||||
- `{skill-name}` resolves to the skill directory's basename.
|
||||
|
||||
## WORKFLOW ARCHITECTURE
|
||||
|
||||
This uses **step-file architecture** for disciplined execution:
|
||||
|
||||
### Core Principles
|
||||
|
||||
- **Micro-file Design**: Each step is a self-contained instruction file that is a part of an overall workflow that must be followed exactly
|
||||
- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until told to do so
|
||||
- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
|
||||
- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
|
||||
- **Append-Only Building**: Build documents by appending content as directed to the output file
|
||||
|
||||
### Step Processing Rules
|
||||
|
||||
1. **READ COMPLETELY**: Always read the entire step file before taking any action
|
||||
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
|
||||
3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
|
||||
4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
|
||||
5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
|
||||
6. **LOAD NEXT**: When directed, read fully and follow the next step file
|
||||
|
||||
### Critical Rules (NO EXCEPTIONS)
|
||||
|
||||
- 🛑 **NEVER** load multiple step files simultaneously
|
||||
- 📖 **ALWAYS** read entire step file before execution
|
||||
- 🚫 **NEVER** skip steps or optimize the sequence
|
||||
- 💾 **ALWAYS** update frontmatter of output files when writing the final output for a specific step
|
||||
- 🎯 **ALWAYS** follow the exact instructions in the step file
|
||||
- ⏸️ **ALWAYS** halt at menus and wait for user input
|
||||
- 📋 **NEVER** create mental todo lists from future steps
|
||||
This skill was consolidated into `bmad-prd`. It is retained as a thin compatibility shim so existing invocations by name and `_bmad/custom/bmad-create-prd.toml` override files keep working. New work should invoke `bmad-prd` directly — it detects create / update / validate intent from the conversation.
|
||||
|
||||
## On Activation
|
||||
|
||||
### Step 1: Resolve the Workflow Block
|
||||
1. Resolve customization: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. This picks up any `{project-root}/_bmad/custom/bmad-create-prd.toml` and `bmad-create-prd.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
|
||||
|
||||
Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
|
||||
2. Load `{project-root}/_bmad/bmm/config.yaml` (and `config.user.yaml` if present) to resolve `{user_name}` and `{communication_language}`.
|
||||
|
||||
**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
|
||||
3. Emit a deprecation notice to the user in `{communication_language}`:
|
||||
|
||||
1. `{skill-root}/customize.toml` — defaults
|
||||
2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
|
||||
3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
|
||||
> Notice: `bmad-create-prd` is deprecated and will be removed in a future release. It now forwards to `bmad-prd` with create intent. To silence this notice and access the full new customization surface (`prd_template`, `validation_checklist`, `doc_standards`, `external_sources`, `external_handoffs`, `output_dir`, `output_folder_name`), migrate `_bmad/custom/bmad-create-prd.toml` to `_bmad/custom/bmad-prd.toml` and invoke `bmad-prd` directly next time. Customization fields that were in this version still remain in the new version and will be respected if present in `_bmad/custom/bmad-prd.toml`, but the new version also supports additional fields that you can take advantage of by migrating.
|
||||
|
||||
Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
|
||||
4. Invoke `bmad-prd` with the following context. Pass these as the activating context so `bmad-prd` honors them instead of resolving its own customization from scratch:
|
||||
|
||||
### Step 2: Execute Prepend Steps
|
||||
- **Intent:** `create` — skip `bmad-prd`'s usual intent detection step.
|
||||
- **Pre-resolved legacy customization** — use these in place of resolving from `bmad-prd`'s own `customize.toml` for the four legacy fields. For everything else (`prd_template`, `validation_checklist`, `validation_report_template`, `doc_standards`, `output_dir`, `output_folder_name`, `external_sources`, `external_handoffs`), use `bmad-prd`'s own defaults and overrides as normal:
|
||||
- `activation_steps_prepend` = the resolved value from step 1
|
||||
- `activation_steps_append` = the resolved value from step 1
|
||||
- `persistent_facts` = the resolved value from step 1
|
||||
- `on_complete` = the resolved value from step 1
|
||||
- **Original user input:** forward whatever the user said when invoking this skill verbatim.
|
||||
|
||||
Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
|
||||
|
||||
### Step 3: Load Persistent Facts
|
||||
|
||||
Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
|
||||
|
||||
### Step 4: Load Config
|
||||
|
||||
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||
- Use `{user_name}` for greeting
|
||||
- Use `{communication_language}` for all communications
|
||||
- Use `{document_output_language}` for output documents
|
||||
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||
- Use `{project_knowledge}` for additional context scanning
|
||||
|
||||
### Step 5: Greet the User
|
||||
|
||||
Greet `{user_name}`, speaking in `{communication_language}`.
|
||||
|
||||
### Step 6: Execute Append Steps
|
||||
|
||||
Execute each entry in `{workflow.activation_steps_append}` in order.
|
||||
|
||||
Activation is complete. Begin the workflow below.
|
||||
|
||||
## Paths
|
||||
|
||||
- `outputFile` = `{planning_artifacts}/prd.md`
|
||||
|
||||
## Execution
|
||||
|
||||
✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the configured `{communication_language}`.
|
||||
✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`.
|
||||
|
||||
**Create Mode: Creating a new PRD from scratch.**
|
||||
|
||||
Read fully and follow: `./steps-c/step-01-init.md`
|
||||
`bmad-prd` takes the workflow from here. Do not execute any further steps in this shim.
|
||||
|
||||
@@ -1,15 +0,0 @@
|
||||
domain,signals,complexity,key_concerns,required_knowledge,suggested_workflow,web_searches,special_sections
|
||||
healthcare,"medical,diagnostic,clinical,FDA,patient,treatment,HIPAA,therapy,pharma,drug",high,"FDA approval;Clinical validation;HIPAA compliance;Patient safety;Medical device classification;Liability","Regulatory pathways;Clinical trial design;Medical standards;Data privacy;Integration requirements","domain-research","FDA software medical device guidance {date};HIPAA compliance software requirements;Medical software standards {date};Clinical validation software","clinical_requirements;regulatory_pathway;validation_methodology;safety_measures"
|
||||
fintech,"payment,banking,trading,investment,crypto,wallet,transaction,KYC,AML,funds,fintech",high,"Regional compliance;Security standards;Audit requirements;Fraud prevention;Data protection","KYC/AML requirements;PCI DSS;Open banking;Regional laws (US/EU/APAC);Crypto regulations","domain-research","fintech regulations {date};payment processing compliance {date};open banking API standards;cryptocurrency regulations {date}","compliance_matrix;security_architecture;audit_requirements;fraud_prevention"
|
||||
govtech,"government,federal,civic,public sector,citizen,municipal,voting",high,"Procurement rules;Security clearance;Accessibility (508);FedRAMP;Privacy;Transparency","Government procurement;Security frameworks;Accessibility standards;Privacy laws;Open data requirements","domain-research","government software procurement {date};FedRAMP compliance requirements;section 508 accessibility;government security standards","procurement_compliance;security_clearance;accessibility_standards;transparency_requirements"
|
||||
edtech,"education,learning,student,teacher,curriculum,assessment,K-12,university,LMS",medium,"Student privacy (COPPA/FERPA);Accessibility;Content moderation;Age verification;Curriculum standards","Educational privacy laws;Learning standards;Accessibility requirements;Content guidelines;Assessment validity","domain-research","educational software privacy {date};COPPA FERPA compliance;WCAG education requirements;learning management standards","privacy_compliance;content_guidelines;accessibility_features;curriculum_alignment"
|
||||
aerospace,"aircraft,spacecraft,aviation,drone,satellite,propulsion,flight,radar,navigation",high,"Safety certification;DO-178C compliance;Performance validation;Simulation accuracy;Export controls","Aviation standards;Safety analysis;Simulation validation;ITAR/export controls;Performance requirements","domain-research + technical-model","DO-178C software certification;aerospace simulation standards {date};ITAR export controls software;aviation safety requirements","safety_certification;simulation_validation;performance_requirements;export_compliance"
|
||||
automotive,"vehicle,car,autonomous,ADAS,automotive,driving,EV,charging",high,"Safety standards;ISO 26262;V2X communication;Real-time requirements;Certification","Automotive standards;Functional safety;V2X protocols;Real-time systems;Testing requirements","domain-research","ISO 26262 automotive software;automotive safety standards {date};V2X communication protocols;EV charging standards","safety_standards;functional_safety;communication_protocols;certification_requirements"
|
||||
scientific,"research,algorithm,simulation,modeling,computational,analysis,data science,ML,AI",medium,"Reproducibility;Validation methodology;Peer review;Performance;Accuracy;Computational resources","Scientific method;Statistical validity;Computational requirements;Domain expertise;Publication standards","technical-model","scientific computing best practices {date};research reproducibility standards;computational modeling validation;peer review software","validation_methodology;accuracy_metrics;reproducibility_plan;computational_requirements"
|
||||
legaltech,"legal,law,contract,compliance,litigation,patent,attorney,court",high,"Legal ethics;Bar regulations;Data retention;Attorney-client privilege;Court system integration","Legal practice rules;Ethics requirements;Court filing systems;Document standards;Confidentiality","domain-research","legal technology ethics {date};law practice management software requirements;court filing system standards;attorney client privilege technology","ethics_compliance;data_retention;confidentiality_measures;court_integration"
|
||||
insuretech,"insurance,claims,underwriting,actuarial,policy,risk,premium",high,"Insurance regulations;Actuarial standards;Data privacy;Fraud detection;State compliance","Insurance regulations by state;Actuarial methods;Risk modeling;Claims processing;Regulatory reporting","domain-research","insurance software regulations {date};actuarial standards software;insurance fraud detection;state insurance compliance","regulatory_requirements;risk_modeling;fraud_detection;reporting_compliance"
|
||||
energy,"energy,utility,grid,solar,wind,power,electricity,oil,gas",high,"Grid compliance;NERC standards;Environmental regulations;Safety requirements;Real-time operations","Energy regulations;Grid standards;Environmental compliance;Safety protocols;SCADA systems","domain-research","energy sector software compliance {date};NERC CIP standards;smart grid requirements;renewable energy software standards","grid_compliance;safety_protocols;environmental_compliance;operational_requirements"
|
||||
process_control,"industrial automation,process control,PLC,SCADA,DCS,HMI,operational technology,OT,control system,cyberphysical,MES,historian,instrumentation,I&C,P&ID",high,"Functional safety;OT cybersecurity;Real-time control requirements;Legacy system integration;Process safety and hazard analysis;Environmental compliance and permitting;Engineering authority and PE requirements","Functional safety standards;OT security frameworks;Industrial protocols;Process control architecture;Plant reliability and maintainability","domain-research + technical-model","IEC 62443 OT cybersecurity requirements {date};functional safety software requirements {date};industrial process control architecture;ISA-95 manufacturing integration","functional_safety;ot_security;process_requirements;engineering_authority"
|
||||
building_automation,"building automation,BAS,BMS,HVAC,smart building,lighting control,fire alarm,fire protection,fire suppression,life safety,elevator,access control,DDC,energy management,sequence of operations,commissioning",high,"Life safety codes;Building energy standards;Multi-trade coordination and interoperability;Commissioning and ongoing operational performance;Indoor environmental quality and occupant comfort;Engineering authority and PE requirements","Building automation protocols;HVAC and mechanical controls;Fire alarm, fire protection, and life safety design;Commissioning process and sequence of operations;Building codes and energy standards","domain-research","smart building software architecture {date};BACnet integration best practices;building automation cybersecurity {date};ASHRAE building standards","life_safety;energy_compliance;commissioning_requirements;engineering_authority"
|
||||
gaming,"game,player,gameplay,level,character,multiplayer,quest",redirect,"REDIRECT TO GAME WORKFLOWS","Game design","game-brief","NA","NA"
|
||||
general,"",low,"Standard requirements;Basic security;User experience;Performance","General software practices","continue","software development best practices {date}","standard_requirements"
|
||||
|
@@ -1,197 +0,0 @@
|
||||
# BMAD PRD Purpose
|
||||
|
||||
**The PRD is the top of the required funnel that feeds all subsequent product development work in rhw BMad Method.**
|
||||
|
||||
---
|
||||
|
||||
## What is a BMAD PRD?
|
||||
|
||||
A dual-audience document serving:
|
||||
1. **Human Product Managers and builders** - Vision, strategy, stakeholder communication
|
||||
2. **LLM Downstream Consumption** - UX Design → Architecture → Epics → Development AI Agents
|
||||
|
||||
Each successive document becomes more AI-tailored and granular.
|
||||
|
||||
---
|
||||
|
||||
## Core Philosophy: Information Density
|
||||
|
||||
**High Signal-to-Noise Ratio**
|
||||
|
||||
Every sentence must carry information weight. LLMs consume precise, dense content efficiently.
|
||||
|
||||
**Anti-Patterns (Eliminate These):**
|
||||
- ❌ "The system will allow users to..." → ✅ "Users can..."
|
||||
- ❌ "It is important to note that..." → ✅ State the fact directly
|
||||
- ❌ "In order to..." → ✅ "To..."
|
||||
- ❌ Conversational filler and padding → ✅ Direct, concise statements
|
||||
|
||||
**Goal:** Maximum information per word. Zero fluff.
|
||||
|
||||
---
|
||||
|
||||
## The Traceability Chain
|
||||
|
||||
**PRD starts the chain:**
|
||||
```
|
||||
Vision → Success Criteria → User Journeys → Functional Requirements → (future: User Stories)
|
||||
```
|
||||
|
||||
**In the PRD, establish:**
|
||||
- Vision → Success Criteria alignment
|
||||
- Success Criteria → User Journey coverage
|
||||
- User Journey → Functional Requirement mapping
|
||||
- All requirements traceable to user needs
|
||||
|
||||
**Why:** Each downstream artifact (UX, Architecture, Epics, Stories) must trace back to documented user needs and business objectives. This chain ensures we build the right thing.
|
||||
|
||||
---
|
||||
|
||||
## What Makes Great Functional Requirements?
|
||||
|
||||
### FRs are Capabilities, Not Implementation
|
||||
|
||||
**Good FR:** "Users can reset their password via email link"
|
||||
**Bad FR:** "System sends JWT via email and validates with database" (implementation leakage)
|
||||
|
||||
**Good FR:** "Dashboard loads in under 2 seconds for 95th percentile"
|
||||
**Bad FR:** "Fast loading time" (subjective, unmeasurable)
|
||||
|
||||
### SMART Quality Criteria
|
||||
|
||||
**Specific:** Clear, precisely defined capability
|
||||
**Measurable:** Quantifiable with test criteria
|
||||
**Attainable:** Realistic within constraints
|
||||
**Relevant:** Aligns with business objectives
|
||||
**Traceable:** Links to source (executive summary or user journey)
|
||||
|
||||
### FR Anti-Patterns
|
||||
|
||||
**Subjective Adjectives:**
|
||||
- ❌ "easy to use", "intuitive", "user-friendly", "fast", "responsive"
|
||||
- ✅ Use metrics: "completes task in under 3 clicks", "loads in under 2 seconds"
|
||||
|
||||
**Implementation Leakage:**
|
||||
- ❌ Technology names, specific libraries, implementation details
|
||||
- ✅ Focus on capability and measurable outcomes
|
||||
|
||||
**Vague Quantifiers:**
|
||||
- ❌ "multiple users", "several options", "various formats"
|
||||
- ✅ "up to 100 concurrent users", "3-5 options", "PDF, DOCX, TXT formats"
|
||||
|
||||
**Missing Test Criteria:**
|
||||
- ❌ "The system shall provide notifications"
|
||||
- ✅ "The system shall send email notifications within 30 seconds of trigger event"
|
||||
|
||||
---
|
||||
|
||||
## What Makes Great Non-Functional Requirements?
|
||||
|
||||
### NFRs Must Be Measurable
|
||||
|
||||
**Template:**
|
||||
```
|
||||
"The system shall [metric] [condition] [measurement method]"
|
||||
```
|
||||
|
||||
**Examples:**
|
||||
- ✅ "The system shall respond to API requests in under 200ms for 95th percentile as measured by APM monitoring"
|
||||
- ✅ "The system shall maintain 99.9% uptime during business hours as measured by cloud provider SLA"
|
||||
- ✅ "The system shall support 10,000 concurrent users as measured by load testing"
|
||||
|
||||
### NFR Anti-Patterns
|
||||
|
||||
**Unmeasurable Claims:**
|
||||
- ❌ "The system shall be scalable" → ✅ "The system shall handle 10x load growth through horizontal scaling"
|
||||
- ❌ "High availability required" → ✅ "99.9% uptime as measured by cloud provider SLA"
|
||||
|
||||
**Missing Context:**
|
||||
- ❌ "Response time under 1 second" → ✅ "API response time under 1 second for 95th percentile under normal load"
|
||||
|
||||
---
|
||||
|
||||
## Domain-Specific Requirements
|
||||
|
||||
**Auto-Detect and Enforce Based on Project Context**
|
||||
|
||||
Certain industries have mandatory requirements that must be present:
|
||||
|
||||
- **Healthcare:** HIPAA Privacy & Security Rules, PHI encryption, audit logging, MFA
|
||||
- **Fintech:** PCI-DSS Level 1, AML/KYC compliance, SOX controls, financial audit trails
|
||||
- **GovTech:** NIST framework, Section 508 accessibility (WCAG 2.1 AA), FedRAMP, data residency
|
||||
- **E-Commerce:** PCI-DSS for payments, inventory accuracy, tax calculation by jurisdiction
|
||||
|
||||
**Why:** Missing these requirements in the PRD means they'll be missed in architecture and implementation, creating expensive rework. During PRD creation there is a step to cover this - during validation we want to make sure it was covered. For this purpose steps will utilize a domain-complexity.csv and project-types.csv.
|
||||
|
||||
---
|
||||
|
||||
## Document Structure (Markdown, Human-Readable)
|
||||
|
||||
### Required Sections
|
||||
1. **Executive Summary** - Vision, differentiator, target users
|
||||
2. **Success Criteria** - Measurable outcomes (SMART)
|
||||
3. **Product Scope** - MVP, Growth, Vision phases
|
||||
4. **User Journeys** - Comprehensive coverage
|
||||
5. **Domain Requirements** - Industry-specific compliance (if applicable)
|
||||
6. **Innovation Analysis** - Competitive differentiation (if applicable)
|
||||
7. **Project-Type Requirements** - Platform-specific needs
|
||||
8. **Functional Requirements** - Capability contract (FRs)
|
||||
9. **Non-Functional Requirements** - Quality attributes (NFRs)
|
||||
|
||||
### Formatting for Dual Consumption
|
||||
|
||||
**For Humans:**
|
||||
- Clear, professional language
|
||||
- Logical flow from vision to requirements
|
||||
- Easy for stakeholders to review and approve
|
||||
|
||||
**For LLMs:**
|
||||
- ## Level 2 headers for all main sections (enables extraction)
|
||||
- Consistent structure and patterns
|
||||
- Precise, testable language
|
||||
- High information density
|
||||
|
||||
---
|
||||
|
||||
## Downstream Impact
|
||||
|
||||
**How the PRD Feeds Next Artifacts:**
|
||||
|
||||
**UX Design:**
|
||||
- User journeys → interaction flows
|
||||
- FRs → design requirements
|
||||
- Success criteria → UX metrics
|
||||
|
||||
**Architecture:**
|
||||
- FRs → system capabilities
|
||||
- NFRs → architecture decisions
|
||||
- Domain requirements → compliance architecture
|
||||
- Project-type requirements → platform choices
|
||||
|
||||
**Epics & Stories (created after architecture):**
|
||||
- FRs → user stories (1 FR could map to 1-3 stories potentially)
|
||||
- Acceptance criteria → story acceptance tests
|
||||
- Priority → sprint sequencing
|
||||
- Traceability → stories map back to vision
|
||||
|
||||
**Development AI Agents:**
|
||||
- Precise requirements → implementation clarity
|
||||
- Test criteria → automated test generation
|
||||
- Domain requirements → compliance enforcement
|
||||
- Measurable NFRs → performance targets
|
||||
|
||||
---
|
||||
|
||||
## Summary: What Makes a Great BMAD PRD?
|
||||
|
||||
✅ **High Information Density** - Every sentence carries weight, zero fluff
|
||||
✅ **Measurable Requirements** - All FRs and NFRs are testable with specific criteria
|
||||
✅ **Clear Traceability** - Each requirement links to user need and business objective
|
||||
✅ **Domain Awareness** - Industry-specific requirements auto-detected and included
|
||||
✅ **Zero Anti-Patterns** - No subjective adjectives, implementation leakage, or vague quantifiers
|
||||
✅ **Dual Audience Optimized** - Human-readable AND LLM-consumable
|
||||
✅ **Markdown Format** - Professional, clean, accessible to all stakeholders
|
||||
|
||||
---
|
||||
|
||||
**Remember:** The PRD is the foundation. Quality here ripples through every subsequent phase. A dense, precise, well-traced PRD makes UX design, architecture, epic breakdown, and AI development dramatically more effective.
|
||||
@@ -1,11 +0,0 @@
|
||||
project_type,detection_signals,key_questions,required_sections,skip_sections,web_search_triggers,innovation_signals
|
||||
api_backend,"API,REST,GraphQL,backend,service,endpoints","Endpoints needed?;Authentication method?;Data formats?;Rate limits?;Versioning?;SDK needed?","endpoint_specs;auth_model;data_schemas;error_codes;rate_limits;api_docs","ux_ui;visual_design;user_journeys","framework best practices;OpenAPI standards","API composition;New protocol"
|
||||
mobile_app,"iOS,Android,app,mobile,iPhone,iPad","Native or cross-platform?;Offline needed?;Push notifications?;Device features?;Store compliance?","platform_reqs;device_permissions;offline_mode;push_strategy;store_compliance","desktop_features;cli_commands","app store guidelines;platform requirements","Gesture innovation;AR/VR features"
|
||||
saas_b2b,"SaaS,B2B,platform,dashboard,teams,enterprise","Multi-tenant?;Permission model?;Subscription tiers?;Integrations?;Compliance?","tenant_model;rbac_matrix;subscription_tiers;integration_list;compliance_reqs","cli_interface;mobile_first","compliance requirements;integration guides","Workflow automation;AI agents"
|
||||
developer_tool,"SDK,library,package,npm,pip,framework","Language support?;Package managers?;IDE integration?;Documentation?;Examples?","language_matrix;installation_methods;api_surface;code_examples;migration_guide","visual_design;store_compliance","package manager best practices;API design patterns","New paradigm;DSL creation"
|
||||
cli_tool,"CLI,command,terminal,bash,script","Interactive or scriptable?;Output formats?;Config method?;Shell completion?","command_structure;output_formats;config_schema;scripting_support","visual_design;ux_principles;touch_interactions","CLI design patterns;shell integration","Natural language CLI;AI commands"
|
||||
web_app,"website,webapp,browser,SPA,PWA","SPA or MPA?;Browser support?;SEO needed?;Real-time?;Accessibility?","browser_matrix;responsive_design;performance_targets;seo_strategy;accessibility_level","native_features;cli_commands","web standards;WCAG guidelines","New interaction;WebAssembly use"
|
||||
game,"game,player,gameplay,level,character","REDIRECT TO USE THE BMad Method Game Module Agent and Workflows - HALT","game-brief;GDD","most_sections","game design patterns","Novel mechanics;Genre mixing"
|
||||
desktop_app,"desktop,Windows,Mac,Linux,native","Cross-platform?;Auto-update?;System integration?;Offline?","platform_support;system_integration;update_strategy;offline_capabilities","web_seo;mobile_features","desktop guidelines;platform requirements","Desktop AI;System automation"
|
||||
iot_embedded,"IoT,embedded,device,sensor,hardware","Hardware specs?;Connectivity?;Power constraints?;Security?;OTA updates?","hardware_reqs;connectivity_protocol;power_profile;security_model;update_mechanism","visual_ui;browser_support","IoT standards;protocol specs","Edge AI;New sensors"
|
||||
blockchain_web3,"blockchain,crypto,DeFi,NFT,smart contract","Chain selection?;Wallet integration?;Gas optimization?;Security audit?","chain_specs;wallet_support;smart_contracts;security_audit;gas_optimization","traditional_auth;centralized_db","blockchain standards;security patterns","Novel tokenomics;DAO structure"
|
||||
|
@@ -1,178 +0,0 @@
|
||||
# Step 1: Workflow Initialization
|
||||
|
||||
**Progress: Step 1 of 11** - Next: Project Discovery
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Initialize the PRD workflow by detecting continuation state, discovering input documents, and setting up the document structure for collaborative product requirement discovery.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a product-focused PM facilitator collaborating with an expert peer
|
||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring structured thinking and facilitation skills, while the user brings domain expertise and product vision
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on initialization and setup - no content generation yet
|
||||
- 🚫 FORBIDDEN to look ahead to future steps or assume knowledge from them
|
||||
- 💬 Approach: Systematic setup with clear reporting to user
|
||||
- 🚪 Detect existing workflow state and handle continuation properly
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis of current state before taking any action
|
||||
- 💾 Initialize document structure and update frontmatter appropriately
|
||||
- Update frontmatter: add this step name to the end of the steps completed array (it should be the first entry in the steps array since this is step 1)
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C' (Continue)
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Variables from workflow.md are available in memory
|
||||
- Focus: Workflow initialization and document setup only
|
||||
- Limits: Don't assume knowledge from other steps or create content yet
|
||||
- Dependencies: Configuration loaded from workflow.md initialization
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Check for Existing Workflow State
|
||||
|
||||
First, check if the output document already exists:
|
||||
|
||||
**Workflow State Detection:**
|
||||
|
||||
- Look for file at `{outputFile}`
|
||||
- If exists, read the complete file including frontmatter
|
||||
- If not exists, this is a fresh workflow
|
||||
|
||||
### 2. Handle Continuation (If Document Exists)
|
||||
|
||||
If the document exists and has frontmatter with `stepsCompleted` BUT `step-12-complete` is NOT in the list, follow the Continuation Protocol since the document is incomplete:
|
||||
|
||||
**Continuation Protocol:**
|
||||
|
||||
- **STOP immediately** and load `./step-01b-continue.md`
|
||||
- Do not proceed with any initialization tasks
|
||||
- Let step-01b handle all continuation logic
|
||||
- This is an auto-proceed situation - no user choice needed
|
||||
|
||||
### 3. Fresh Workflow Setup (If No Document)
|
||||
|
||||
If no document exists or no `stepsCompleted` in frontmatter:
|
||||
|
||||
#### A. Input Document Discovery
|
||||
|
||||
Discover and load context documents using smart discovery. Documents can be in the following locations:
|
||||
- {planning_artifacts}/**
|
||||
- {output_folder}/**
|
||||
- {project_knowledge}/**
|
||||
- docs/**
|
||||
|
||||
Also - when searching - documents can be a single markdown file, or a folder with an index and multiple files. For Example, if searching for `*foo*.md` and not found, also search for a folder called *foo*/index.md (which indicates sharded content)
|
||||
|
||||
Try to discover the following:
|
||||
- Product Brief (`*brief*.md`)
|
||||
- Research Documents (`/*research*.md`)
|
||||
- Project Documentation (generally multiple documents might be found for this in the `{project_knowledge}` or `docs` folder.)
|
||||
- Project Context (`**/project-context.md`)
|
||||
|
||||
<critical>Confirm what you have found with the user, along with asking if the user wants to provide anything else. Only after this confirmation will you proceed to follow the loading rules</critical>
|
||||
|
||||
**Loading Rules:**
|
||||
|
||||
- Load ALL discovered files completely that the user confirmed or provided (no offset/limit)
|
||||
- If there is a project context, whatever is relevant should try to be biased in the remainder of this whole workflow process
|
||||
- For sharded folders, load ALL files to get complete picture, using the index first to potentially know the potential of each document
|
||||
- index.md is a guide to what's relevant whenever available
|
||||
- Track all successfully loaded files in frontmatter `inputDocuments` array
|
||||
|
||||
#### B. Create Initial Document
|
||||
|
||||
**Document Setup:**
|
||||
|
||||
- Copy the template from `../templates/prd-template.md` to `{outputFile}`
|
||||
- Initialize frontmatter with proper structure including inputDocuments array.
|
||||
|
||||
#### C. Present Initialization Results
|
||||
|
||||
**Setup Report to User:**
|
||||
|
||||
"Welcome {{user_name}}! I've set up your PRD workspace for {{project_name}}.
|
||||
|
||||
**Document Setup:**
|
||||
|
||||
- Created: `{outputFile}` from template
|
||||
- Initialized frontmatter with workflow state
|
||||
|
||||
**Input Documents Discovered:**
|
||||
|
||||
- Product briefs: {{briefCount}} files {if briefCount > 0}✓ loaded{else}(none found){/if}
|
||||
- Research: {{researchCount}} files {if researchCount > 0}✓ loaded{else}(none found){/if}
|
||||
- Brainstorming: {{brainstormingCount}} files {if brainstormingCount > 0}✓ loaded{else}(none found){/if}
|
||||
- Project docs: {{projectDocsCount}} files {if projectDocsCount > 0}✓ loaded (brownfield project){else}(none found - greenfield project){/if}
|
||||
|
||||
**Files loaded:** {list of specific file names or "No additional documents found"}
|
||||
|
||||
{if projectDocsCount > 0}
|
||||
📋 **Note:** This is a **brownfield project**. Your existing project documentation has been loaded. In the next step, I'll ask specifically about what new features or changes you want to add to your existing system.
|
||||
{/if}
|
||||
|
||||
Do you have any other documents you'd like me to include, or shall we continue to the next step?"
|
||||
|
||||
### 4. Present MENU OPTIONS
|
||||
|
||||
Display menu after setup report:
|
||||
|
||||
"[C] Continue - Save this and move to Project Discovery (Step 2 of 11)"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Update output file frontmatter, adding this step name to the end of the list of stepsCompleted, then read fully and follow: ./step-02-discovery.md
|
||||
- IF user provides additional files: Load them, update inputDocuments and documentCounts, redisplay report
|
||||
- IF user asks questions: Answer and redisplay menu
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [frontmatter properly updated with this step added to stepsCompleted and documentCounts], will you then read fully and follow: `./step-02-discovery.md` to begin project discovery.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Existing workflow detected and properly handed off to step-01b
|
||||
- Fresh workflow initialized with template and proper frontmatter
|
||||
- Input documents discovered and loaded using sharded-first logic
|
||||
- All discovered files tracked in frontmatter `inputDocuments`
|
||||
- User clearly informed of brownfield vs greenfield status
|
||||
- Menu presented and user input handled correctly
|
||||
- Frontmatter updated with this step name added to stepsCompleted before proceeding
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Proceeding with fresh initialization when existing workflow exists
|
||||
- Not updating frontmatter with discovered input documents
|
||||
- **Not storing document counts in frontmatter**
|
||||
- Creating document without proper template structure
|
||||
- Not checking sharded folders first before whole files
|
||||
- Not reporting discovered documents to user clearly
|
||||
- Proceeding without user selecting 'C' (Continue)
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -1,161 +0,0 @@
|
||||
# Step 1B: Workflow Continuation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Resume the PRD workflow from where it was left off, ensuring smooth continuation with full context restoration.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a product-focused PM facilitator collaborating with an expert peer
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ Resume workflow from exact point where it was interrupted
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 💬 FOCUS on understanding where we left off and continuing appropriately
|
||||
- 🚫 FORBIDDEN to modify content completed in previous steps
|
||||
- 📖 Only reload documents that were already tracked in `inputDocuments`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis of current state before taking action
|
||||
- Update frontmatter: add this step name to the end of the steps completed array
|
||||
- 📖 Only load documents that were already tracked in `inputDocuments`
|
||||
- 🚫 FORBIDDEN to discover new input documents during continuation
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Current document and frontmatter are already loaded
|
||||
- Focus: Workflow state analysis and continuation logic only
|
||||
- Limits: Don't assume knowledge beyond what's in the document
|
||||
- Dependencies: Existing workflow state from previous session
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Analyze Current State
|
||||
|
||||
**State Assessment:**
|
||||
Review the frontmatter to understand:
|
||||
|
||||
- `stepsCompleted`: Array of completed step filenames
|
||||
- Last element of `stepsCompleted` array: The most recently completed step
|
||||
- `inputDocuments`: What context was already loaded
|
||||
- All other frontmatter variables
|
||||
|
||||
### 2. Restore Context Documents
|
||||
|
||||
**Context Reloading:**
|
||||
|
||||
- For each document in `inputDocuments`, load the complete file
|
||||
- This ensures you have full context for continuation
|
||||
- Don't discover new documents - only reload what was previously processed
|
||||
|
||||
### 3. Determine Next Step
|
||||
|
||||
**Step Sequence Lookup:**
|
||||
|
||||
Use the following ordered sequence to determine the next step from the last completed step:
|
||||
|
||||
| Last Completed | Next Step |
|
||||
|---|---|
|
||||
| step-01-init.md | step-02-discovery.md |
|
||||
| step-02-discovery.md | step-02b-vision.md |
|
||||
| step-02b-vision.md | step-02c-executive-summary.md |
|
||||
| step-02c-executive-summary.md | step-03-success.md |
|
||||
| step-03-success.md | step-04-journeys.md |
|
||||
| step-04-journeys.md | step-05-domain.md |
|
||||
| step-05-domain.md | step-06-innovation.md |
|
||||
| step-06-innovation.md | step-07-project-type.md |
|
||||
| step-07-project-type.md | step-08-scoping.md |
|
||||
| step-08-scoping.md | step-09-functional.md |
|
||||
| step-09-functional.md | step-10-nonfunctional.md |
|
||||
| step-10-nonfunctional.md | step-11-polish.md |
|
||||
| step-11-polish.md | step-12-complete.md |
|
||||
|
||||
1. Get the last element from the `stepsCompleted` array
|
||||
2. Look it up in the table above to find the next step
|
||||
3. That's the next step to load!
|
||||
|
||||
**Example:**
|
||||
- If `stepsCompleted = ["step-01-init.md", "step-02-discovery.md", "step-03-success.md"]`
|
||||
- Last element is `"step-03-success.md"`
|
||||
- Table lookup → next step is `./step-04-journeys.md`
|
||||
|
||||
### 4. Handle Workflow Completion
|
||||
|
||||
**If `stepsCompleted` array contains `"step-12-complete.md"`:**
|
||||
"Great news! It looks like we've already completed the PRD workflow for {{project_name}}.
|
||||
|
||||
The final document is ready at `{outputFile}` with all sections completed.
|
||||
|
||||
Would you like me to:
|
||||
|
||||
- Review the completed PRD with you
|
||||
- Suggest next workflow steps (like architecture or epic creation)
|
||||
- Start a new PRD revision
|
||||
|
||||
What would be most helpful?"
|
||||
|
||||
### 5. Present Current Progress
|
||||
|
||||
**If workflow not complete:**
|
||||
"Welcome back {{user_name}}! I'm resuming our PRD collaboration for {{project_name}}.
|
||||
|
||||
**Current Progress:**
|
||||
- Last completed: {last step filename from stepsCompleted array}
|
||||
- Next up: {next step from lookup table}
|
||||
- Context documents available: {len(inputDocuments)} files
|
||||
|
||||
**Document Status:**
|
||||
- Current PRD document is ready with all completed sections
|
||||
- Ready to continue from where we left off
|
||||
|
||||
Does this look right, or do you want to make any adjustments before we proceed?"
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [C] Continue to {next step name}"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Read fully and follow the next step determined from the lookup table in step 3
|
||||
- IF Any other comments or queries: respond and redisplay menu
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [current state confirmed], will you then read fully and follow the next step (from the lookup table) to resume the workflow.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All previous input documents successfully reloaded
|
||||
- Current workflow state accurately analyzed and presented
|
||||
- User confirms understanding of progress before continuation
|
||||
- Correct next step identified and prepared for loading
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Discovering new input documents instead of reloading existing ones
|
||||
- Modifying content from already completed steps
|
||||
- Failing to determine the next step from the lookup table
|
||||
- Proceeding without user confirmation of current state
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -1,208 +0,0 @@
|
||||
# Step 2: Project Discovery
|
||||
|
||||
**Progress: Step 2 of 13** - Next: Product Vision
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Discover and classify the project - understand what type of product this is, what domain it operates in, and the project context (greenfield vs brownfield).
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read
|
||||
- ✅ ALWAYS treat this as collaborative discovery between PM peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a product-focused PM facilitator collaborating with an expert peer
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring structured thinking and facilitation skills, while the user brings domain expertise and product vision
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus on classification and understanding - no content generation yet
|
||||
- 🚫 FORBIDDEN to generate executive summary or vision statements (that's next steps)
|
||||
- 💬 APPROACH: Natural conversation to understand the project
|
||||
- 🎯 LOAD classification data BEFORE starting discovery conversation
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ⚠️ Present A/P/C menu after classification complete
|
||||
- 💾 ONLY save classification to frontmatter when user chooses C (Continue)
|
||||
- 📖 Update frontmatter, adding this step to the end of the list of stepsCompleted
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from step 1 are available
|
||||
- Input documents already loaded are in memory (product briefs, research, brainstorming, project docs)
|
||||
- **Document counts available in frontmatter `documentCounts`**
|
||||
- Classification CSV data will be loaded in this step only
|
||||
- No executive summary or vision content yet (that's steps 2b and 2c)
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Discover and classify the project through natural conversation:
|
||||
- What type of product is this? (web app, API, mobile, etc.)
|
||||
- What domain does it operate in? (healthcare, fintech, e-commerce, etc.)
|
||||
- What's the project context? (greenfield new product vs brownfield existing system)
|
||||
- How complex is this domain? (low, medium, high)
|
||||
|
||||
## DISCOVERY SEQUENCE:
|
||||
|
||||
### 1. Check Document State
|
||||
|
||||
Read the frontmatter from `{outputFile}` to get document counts:
|
||||
- `briefCount` - Product briefs available
|
||||
- `researchCount` - Research documents available
|
||||
- `brainstormingCount` - Brainstorming docs available
|
||||
- `projectDocsCount` - Existing project documentation
|
||||
|
||||
**Announce your understanding:**
|
||||
|
||||
"From step 1, I have loaded:
|
||||
- Product briefs: {{briefCount}}
|
||||
- Research: {{researchCount}}
|
||||
- Brainstorming: {{brainstormingCount}}
|
||||
- Project docs: {{projectDocsCount}}
|
||||
|
||||
{{if projectDocsCount > 0}}This is a brownfield project - I'll focus on understanding what you want to add or change.{{else}}This is a greenfield project - I'll help you define the full product vision.{{/if}}"
|
||||
|
||||
### 2. Load Classification Data
|
||||
|
||||
**Attempt subprocess data lookup:**
|
||||
|
||||
**Project Type Lookup:**
|
||||
"Your task: Lookup data in ../data/project-types.csv
|
||||
|
||||
**Search criteria:**
|
||||
- Find row where project_type matches {{detectedProjectType}}
|
||||
|
||||
**Return format:**
|
||||
Return ONLY the matching row as a YAML-formatted object with these fields:
|
||||
project_type, detection_signals
|
||||
|
||||
**Do NOT return the entire CSV - only the matching row.**"
|
||||
|
||||
**Domain Complexity Lookup:**
|
||||
"Your task: Lookup data in ../data/domain-complexity.csv
|
||||
|
||||
**Search criteria:**
|
||||
- Find row where domain matches {{detectedDomain}}
|
||||
|
||||
**Return format:**
|
||||
Return ONLY the matching row as a YAML-formatted object with these fields:
|
||||
domain, complexity, typical_concerns, compliance_requirements
|
||||
|
||||
**Do NOT return the entire CSV - only the matching row.**"
|
||||
|
||||
**Graceful degradation (if Task tool unavailable):**
|
||||
- Load the CSV files directly
|
||||
- Find the matching rows manually
|
||||
- Extract required fields
|
||||
- Keep in memory for intelligent classification
|
||||
|
||||
### 3. Begin Discovery Conversation
|
||||
|
||||
**Start with what you know:**
|
||||
|
||||
If the user has a product brief or project docs, acknowledge them and share your understanding. Then ask clarifying questions to deepen your understanding.
|
||||
|
||||
If this is a greenfield project with no docs, start with open-ended discovery:
|
||||
- What problem does this solve?
|
||||
- Who's it for?
|
||||
- What excites you about building this?
|
||||
|
||||
**Listen for classification signals:**
|
||||
|
||||
As the user describes their product, match against:
|
||||
- **Project type signals** (API, mobile, SaaS, etc.)
|
||||
- **Domain signals** (healthcare, fintech, education, etc.)
|
||||
- **Complexity indicators** (regulated industries, novel technology, etc.)
|
||||
|
||||
### 4. Confirm Classification
|
||||
|
||||
Once you have enough understanding, share your classification:
|
||||
|
||||
"I'm hearing this as:
|
||||
- **Project Type:** {{detectedType}}
|
||||
- **Domain:** {{detectedDomain}}
|
||||
- **Complexity:** {{complexityLevel}}
|
||||
|
||||
Does this sound right to you?"
|
||||
|
||||
Let the user confirm or refine your classification.
|
||||
|
||||
### 5. Save Classification to Frontmatter
|
||||
|
||||
When user selects 'C', update frontmatter with classification:
|
||||
```yaml
|
||||
classification:
|
||||
projectType: {{projectType}}
|
||||
domain: {{domain}}
|
||||
complexity: {{complexityLevel}}
|
||||
projectContext: {{greenfield|brownfield}}
|
||||
```
|
||||
|
||||
### N. Present MENU OPTIONS
|
||||
|
||||
Present the project classification for review, then display menu:
|
||||
|
||||
"Based on our conversation, I've discovered and classified your project.
|
||||
|
||||
**Here's the classification:**
|
||||
|
||||
**Project Type:** {{detectedType}}
|
||||
**Domain:** {{detectedDomain}}
|
||||
**Complexity:** {{complexityLevel}}
|
||||
**Project Context:** {{greenfield|brownfield}}
|
||||
|
||||
**What would you like to do?**"
|
||||
|
||||
Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Product Vision (Step 2b of 13)"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Invoke the `bmad-advanced-elicitation` skill with the current classification, process the enhanced insights that come back, ask user if they accept the improvements, if yes update classification then redisplay menu, if no keep original classification then redisplay menu
|
||||
- IF P: Invoke the `bmad-party-mode` skill with the current classification, process the collaborative insights, ask user if they accept the changes, if yes update classification then redisplay menu, if no keep original classification then redisplay menu
|
||||
- IF C: Save classification to {outputFile} frontmatter, add this step name to the end of stepsCompleted array, then read fully and follow: ./step-02b-vision.md
|
||||
- IF Any other: help user respond, then redisplay menu
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [classification saved to frontmatter], will you then read fully and follow: `./step-02b-vision.md` to explore product vision.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Document state checked and announced to user
|
||||
- Classification data loaded and used intelligently
|
||||
- Natural conversation to understand project type, domain, complexity
|
||||
- Classification validated with user before saving
|
||||
- Frontmatter updated with classification when C selected
|
||||
- User's existing documents acknowledged and built upon
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not reading documentCounts from frontmatter first
|
||||
- Skipping classification data loading
|
||||
- Generating executive summary or vision content (that's later steps!)
|
||||
- Not validating classification with user
|
||||
- Being prescriptive instead of having natural conversation
|
||||
- Proceeding without user selecting 'C'
|
||||
|
||||
**Master Rule:** This is classification and understanding only. No content generation yet. Build on what the user already has. Have natural conversations, don't follow scripts.
|
||||
@@ -1,142 +0,0 @@
|
||||
# Step 2b: Product Vision Discovery
|
||||
|
||||
**Progress: Step 2b of 13** - Next: Executive Summary
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Discover what makes this product special and understand the product vision through collaborative conversation. No content generation — facilitation only.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read
|
||||
- ✅ ALWAYS treat this as collaborative discovery between PM peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a product-focused PM facilitator collaborating with an expert peer
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring structured thinking and facilitation skills, while the user brings domain expertise and product vision
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus on discovering vision and differentiator — no content generation yet
|
||||
- 🚫 FORBIDDEN to generate executive summary content (that's the next step)
|
||||
- 🚫 FORBIDDEN to append anything to the document in this step
|
||||
- 💬 APPROACH: Natural conversation to understand what makes this product special
|
||||
- 🎯 BUILD ON classification insights from step 2
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ⚠️ Present A/P/C menu after vision discovery is complete
|
||||
- 📖 Update frontmatter, adding this step to the end of the list of stepsCompleted
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from steps 1 and 2 are available
|
||||
- Project classification exists from step 2 (project type, domain, complexity, context)
|
||||
- Input documents already loaded are in memory (product briefs, research, brainstorming, project docs)
|
||||
- No executive summary content yet (that's step 2c)
|
||||
- This step ONLY discovers — it does NOT write to the document
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Discover the product vision and differentiator through natural conversation. Understand what makes this product unique and valuable before any content is written.
|
||||
|
||||
## VISION DISCOVERY SEQUENCE:
|
||||
|
||||
### 1. Acknowledge Classification Context
|
||||
|
||||
Reference the classification from step 2 and use it to frame the vision conversation:
|
||||
|
||||
"We've established this is a {{projectType}} in the {{domain}} domain with {{complexityLevel}} complexity. Now let's explore what makes this product special."
|
||||
|
||||
### 2. Explore What Makes It Special
|
||||
|
||||
Guide the conversation to uncover the product's unique value:
|
||||
|
||||
- **User delight:** "What would make users say 'this is exactly what I needed'?"
|
||||
- **Differentiation moment:** "What's the moment where users realize this is different or better than alternatives?"
|
||||
- **Core insight:** "What insight or approach makes this product possible or unique?"
|
||||
- **Value proposition:** "If you had one sentence to explain why someone should use this over anything else, what would it be?"
|
||||
|
||||
### 3. Understand the Vision
|
||||
|
||||
Dig deeper into the product vision:
|
||||
|
||||
- **Problem framing:** "What's the real problem you're solving — not the surface symptom, but the deeper need?"
|
||||
- **Future state:** "When this product is successful, what does the world look like for your users?"
|
||||
- **Why now:** "Why is this the right time to build this?"
|
||||
|
||||
### 4. Validate Understanding
|
||||
|
||||
Reflect back what you've heard and confirm:
|
||||
|
||||
"Here's what I'm hearing about your vision and differentiator:
|
||||
|
||||
**Vision:** {{summarized_vision}}
|
||||
**What Makes It Special:** {{summarized_differentiator}}
|
||||
**Core Insight:** {{summarized_insight}}
|
||||
|
||||
Does this capture it? Anything I'm missing?"
|
||||
|
||||
Let the user confirm or refine your understanding.
|
||||
|
||||
### N. Present MENU OPTIONS
|
||||
|
||||
Present your understanding of the product vision for review, then display menu:
|
||||
|
||||
"Based on our conversation, I have a clear picture of your product vision and what makes it special. I'll use these insights to draft the Executive Summary in the next step.
|
||||
|
||||
**What would you like to do?**"
|
||||
|
||||
Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Executive Summary (Step 2c of 13)"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Invoke the `bmad-advanced-elicitation` skill with the current vision insights, process the enhanced insights that come back, ask user if they accept the improvements, if yes update understanding then redisplay menu, if no keep original understanding then redisplay menu
|
||||
- IF P: Invoke the `bmad-party-mode` skill with the current vision insights, process the collaborative insights, ask user if they accept the changes, if yes update understanding then redisplay menu, if no keep original understanding then redisplay menu
|
||||
- IF C: Update {outputFile} frontmatter by adding this step name to the end of stepsCompleted array, then read fully and follow: ./step-02c-executive-summary.md
|
||||
- IF Any other: help user respond, then redisplay menu
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [stepsCompleted updated], will you then read fully and follow: `./step-02c-executive-summary.md` to generate the Executive Summary.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Classification context from step 2 acknowledged and built upon
|
||||
- Natural conversation to understand product vision and differentiator
|
||||
- User's existing documents (briefs, research, brainstorming) leveraged for vision insights
|
||||
- Vision and differentiator validated with user before proceeding
|
||||
- Clear understanding established that will inform Executive Summary generation
|
||||
- Frontmatter updated with stepsCompleted when C selected
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Generating executive summary or any document content (that's step 2c!)
|
||||
- Appending anything to the PRD document
|
||||
- Not building on classification from step 2
|
||||
- Being prescriptive instead of having natural conversation
|
||||
- Proceeding without user selecting 'C'
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
|
||||
**Master Rule:** This step is vision discovery only. No content generation, no document writing. Have natural conversations, build on what you know from classification, and establish the vision that will feed into the Executive Summary.
|
||||
@@ -1,158 +0,0 @@
|
||||
# Step 2c: Executive Summary Generation
|
||||
|
||||
**Progress: Step 2c of 13** - Next: Success Criteria
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Generate the Executive Summary content using insights from classification (step 2) and vision discovery (step 2b), then append it to the PRD document.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read
|
||||
- ✅ ALWAYS treat this as collaborative discovery between PM peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a product-focused PM facilitator collaborating with an expert peer
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ Content is drafted collaboratively — present for review before saving
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Generate Executive Summary content based on discovered insights
|
||||
- 💬 Present draft content for user review and refinement before appending
|
||||
- 🚫 FORBIDDEN to append content without user approval via 'C'
|
||||
- 🎯 Content must be dense, precise, and zero-fluff (PRD quality standards)
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ⚠️ Present A/P/C menu after generating executive summary content
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from steps 1, 2, and 2b are available
|
||||
- Project classification exists from step 2 (project type, domain, complexity, context)
|
||||
- Vision and differentiator insights exist from step 2b
|
||||
- Input documents from step 1 are available (product briefs, research, brainstorming, project docs)
|
||||
- This step generates and appends the first substantive content to the PRD
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Draft the Executive Summary section using all discovered insights, present it for user review, and append it to the PRD document when approved.
|
||||
|
||||
## EXECUTIVE SUMMARY GENERATION SEQUENCE:
|
||||
|
||||
### 1. Synthesize Available Context
|
||||
|
||||
Review all available context before drafting:
|
||||
- Classification from step 2: project type, domain, complexity, project context
|
||||
- Vision and differentiator from step 2b: what makes this special, core insight
|
||||
- Input documents: product briefs, research, brainstorming, project docs
|
||||
|
||||
### 2. Draft Executive Summary Content
|
||||
|
||||
Generate the Executive Summary section using the content structure below. Apply PRD quality standards:
|
||||
- High information density — every sentence carries weight
|
||||
- Zero fluff — no filler phrases or vague language
|
||||
- Precise and actionable — clear, specific statements
|
||||
- Dual-audience optimized — readable by humans, consumable by LLMs
|
||||
|
||||
### 3. Present Draft for Review
|
||||
|
||||
Present the drafted content to the user for review:
|
||||
|
||||
"Here's the Executive Summary I've drafted based on our discovery work. Please review and let me know if you'd like any changes:"
|
||||
|
||||
Show the full drafted content using the structure from the Content Structure section below.
|
||||
|
||||
Allow the user to:
|
||||
- Request specific changes to any section
|
||||
- Add missing information
|
||||
- Refine the language or emphasis
|
||||
- Approve as-is
|
||||
|
||||
### N. Present MENU OPTIONS
|
||||
|
||||
Present the executive summary content for user review, then display menu:
|
||||
|
||||
"Here's the Executive Summary for your PRD. Review the content above and let me know what you'd like to do."
|
||||
|
||||
Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Success Criteria (Step 3 of 13)"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Invoke the `bmad-advanced-elicitation` skill with the current executive summary content, process the enhanced content that comes back, ask user if they accept the improvements, if yes update content then redisplay menu, if no keep original content then redisplay menu
|
||||
- IF P: Invoke the `bmad-party-mode` skill with the current executive summary content, process the collaborative improvements, ask user if they accept the changes, if yes update content then redisplay menu, if no keep original content then redisplay menu
|
||||
- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-03-success.md
|
||||
- IF Any other: help user respond, then redisplay menu
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the following content structure directly to the document:
|
||||
|
||||
```markdown
|
||||
## Executive Summary
|
||||
|
||||
{vision_alignment_content}
|
||||
|
||||
### What Makes This Special
|
||||
|
||||
{product_differentiator_content}
|
||||
|
||||
## Project Classification
|
||||
|
||||
{project_classification_content}
|
||||
```
|
||||
|
||||
Where:
|
||||
- `{vision_alignment_content}` — Product vision, target users, and the problem being solved. Dense, precise summary drawn from step 2b vision discovery.
|
||||
- `{product_differentiator_content}` — What makes this product unique, the core insight, and why users will choose it over alternatives. Drawn from step 2b differentiator discovery.
|
||||
- `{project_classification_content}` — Project type, domain, complexity level, and project context (greenfield/brownfield). Drawn from step 2 classification.
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [content appended to document], will you then read fully and follow: `./step-03-success.md` to define success criteria.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Executive Summary drafted using insights from steps 2 and 2b
|
||||
- Content meets PRD quality standards (dense, precise, zero-fluff)
|
||||
- Draft presented to user for review before saving
|
||||
- User given opportunity to refine content
|
||||
- Content properly appended to document when C selected
|
||||
- A/P/C menu presented and handled correctly
|
||||
- Frontmatter updated with stepsCompleted when C selected
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Generating content without incorporating discovered vision and classification
|
||||
- Appending content without user selecting 'C'
|
||||
- Producing vague, fluffy, or low-density content
|
||||
- Not presenting draft for user review
|
||||
- Not presenting A/P/C menu after content generation
|
||||
- Skipping directly to next step without appending content
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
**Master Rule:** Generate high-quality Executive Summary content from discovered insights. Present for review, refine collaboratively, and only save when the user approves. This is the first substantive content in the PRD — it sets the quality bar for everything that follows.
|
||||
@@ -1,214 +0,0 @@
|
||||
# Step 3: Success Criteria Definition
|
||||
|
||||
**Progress: Step 3 of 11** - Next: User Journey Mapping
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ ALWAYS treat this as collaborative discovery between PM peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on defining what winning looks like for this product
|
||||
- 🎯 COLLABORATIVE discovery, not assumption-based goal setting
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ⚠️ Present A/P/C menu after generating success criteria content
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from previous steps are available
|
||||
- Executive Summary and Project Classification already exist in document
|
||||
- Input documents from step-01 are available (product briefs, research, brainstorming)
|
||||
- No additional data files needed for this step
|
||||
- Focus on measurable, specific success criteria
|
||||
- LEVERAGE existing input documents to inform success criteria
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Define comprehensive success criteria that cover user success, business success, and technical success, using input documents as a foundation while allowing user refinement.
|
||||
|
||||
## SUCCESS DISCOVERY SEQUENCE:
|
||||
|
||||
### 1. Begin Success Definition Conversation
|
||||
|
||||
**Check Input Documents for Success Indicators:**
|
||||
Analyze product brief, research, and brainstorming documents for success criteria already mentioned.
|
||||
|
||||
**If Input Documents Contain Success Criteria:**
|
||||
Guide user to refine existing success criteria:
|
||||
- Acknowledge what's already documented in their materials
|
||||
- Extract key success themes from brief, research, and brainstorming
|
||||
- Help user identify gaps and areas for expansion
|
||||
- Probe for specific, measurable outcomes: When do users feel delighted/relieved/empowered?
|
||||
- Ask about emotional success moments and completion scenarios
|
||||
- Explore what "worth it" means beyond what's already captured
|
||||
|
||||
**If No Success Criteria in Input Documents:**
|
||||
Start with user-centered success exploration:
|
||||
- Guide conversation toward defining what "worth it" means for users
|
||||
- Ask about the moment users realize their problem is solved
|
||||
- Explore specific user outcomes and emotional states
|
||||
- Identify success "aha!" moments and completion scenarios
|
||||
- Focus on user experience of success first
|
||||
|
||||
### 2. Explore User Success Metrics
|
||||
|
||||
Listen for specific user outcomes and help make them measurable:
|
||||
|
||||
- Guide from vague to specific: NOT "users are happy" → "users complete [key action] within [timeframe]"
|
||||
- Ask about emotional success: "When do they feel delighted/relieved/empowered?"
|
||||
- Identify success moments: "What's the 'aha!' moment?"
|
||||
- Define completion scenarios: "What does 'done' look like for the user?"
|
||||
|
||||
### 3. Define Business Success
|
||||
|
||||
Transition to business metrics:
|
||||
- Guide conversation to business perspective on success
|
||||
- Explore timelines: What does 3-month success look like? 12-month success?
|
||||
- Identify key business metrics: revenue, user growth, engagement, or other measures?
|
||||
- Ask what specific metric would indicate "this is working"
|
||||
- Understand business success from their perspective
|
||||
|
||||
### 4. Challenge Vague Metrics
|
||||
|
||||
Push for specificity on business metrics:
|
||||
|
||||
- "10,000 users" → "What kind of users? Doing what?"
|
||||
- "99.9% uptime" → "What's the real concern - data loss? Failed payments?"
|
||||
- "Fast" → "How fast, and what specifically needs to be fast?"
|
||||
- "Good adoption" → "What percentage adoption by when?"
|
||||
|
||||
### 5. Connect to Product Differentiator
|
||||
|
||||
Tie success metrics back to what makes the product special:
|
||||
- Connect success criteria to the product's unique differentiator
|
||||
- Ensure metrics reflect the specific value proposition
|
||||
- Adapt success criteria to domain context:
|
||||
- Consumer: User love, engagement, retention
|
||||
- B2B: ROI, efficiency, adoption
|
||||
- Developer tools: Developer experience, community
|
||||
- Regulated: Compliance, safety, validation
|
||||
- GovTech: Government compliance, accessibility, procurement
|
||||
|
||||
### 6. Smart Scope Negotiation
|
||||
|
||||
Guide scope definition through success lens:
|
||||
- Help user distinguish MVP (must work to be useful) from growth (competitive) and vision (dream)
|
||||
- Guide conversation through three scope levels:
|
||||
1. MVP: What's essential for proving the concept?
|
||||
2. Growth: What makes it competitive?
|
||||
3. Vision: What's the dream version?
|
||||
- Challenge scope creep conversationally: Could this wait until after launch? Is this essential for MVP?
|
||||
- For complex domains: Ensure compliance minimums are included in MVP
|
||||
|
||||
### 7. Generate Success Criteria Content
|
||||
|
||||
Prepare the content to append to the document:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
When saving to document, append these Level 2 and Level 3 sections:
|
||||
|
||||
```markdown
|
||||
## Success Criteria
|
||||
|
||||
### User Success
|
||||
|
||||
[Content about user success criteria based on conversation]
|
||||
|
||||
### Business Success
|
||||
|
||||
[Content about business success metrics based on conversation]
|
||||
|
||||
### Technical Success
|
||||
|
||||
[Content about technical success requirements based on conversation]
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
[Content about specific measurable outcomes based on conversation]
|
||||
|
||||
## Product Scope
|
||||
|
||||
### MVP - Minimum Viable Product
|
||||
|
||||
[Content about MVP scope based on conversation]
|
||||
|
||||
### Growth Features (Post-MVP)
|
||||
|
||||
[Content about growth features based on conversation]
|
||||
|
||||
### Vision (Future)
|
||||
|
||||
[Content about future vision based on conversation]
|
||||
```
|
||||
|
||||
### 8. Present MENU OPTIONS
|
||||
|
||||
Present the success criteria content for user review, then display menu:
|
||||
|
||||
- Show the drafted success criteria and scope definition (using structure from section 7)
|
||||
- Ask if they'd like to refine further, get other perspectives, or proceed
|
||||
- Present menu options naturally as part of the conversation
|
||||
|
||||
Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to User Journey Mapping (Step 4 of 11)"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Invoke the `bmad-advanced-elicitation` skill with the current success criteria content, process the enhanced success metrics that come back, ask user "Accept these improvements to the success criteria? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
|
||||
- IF P: Invoke the `bmad-party-mode` skill with the current success criteria, process the collaborative improvements to metrics and scope, ask user "Accept these changes to the success criteria? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
|
||||
- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-04-journeys.md
|
||||
- IF Any other: help user respond, then redisplay menu
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from step 7.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ User success criteria clearly identified and made measurable
|
||||
✅ Business success metrics defined with specific targets
|
||||
✅ Success criteria connected to product differentiator
|
||||
✅ Scope properly negotiated (MVP, Growth, Vision)
|
||||
✅ A/P/C menu presented and handled correctly
|
||||
✅ Content properly appended to document when C selected
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Accepting vague success metrics without pushing for specificity
|
||||
❌ Not connecting success criteria back to product differentiator
|
||||
❌ Missing scope negotiation and leaving it undefined
|
||||
❌ Generating content without real user input on what success looks like
|
||||
❌ Not presenting A/P/C menu after content generation
|
||||
❌ Appending content without user selecting 'C'
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## DOMAIN CONSIDERATIONS:
|
||||
|
||||
If working in regulated domains (healthcare, fintech, govtech):
|
||||
|
||||
- Include compliance milestones in success criteria
|
||||
- Add regulatory approval timelines to MVP scope
|
||||
- Consider audit requirements as technical success metrics
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved to document, load `./step-04-journeys.md` to map user journeys.
|
||||
|
||||
Remember: Do NOT proceed to step-04 until user explicitly selects 'C' from the A/P/C menu and content is saved!
|
||||
@@ -1,201 +0,0 @@
|
||||
# Step 4: User Journey Mapping
|
||||
|
||||
**Progress: Step 4 of 11** - Next: Domain Requirements
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ ALWAYS treat this as collaborative discovery between PM peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on mapping ALL user types that interact with the system
|
||||
- 🎯 CRITICAL: No journey = no functional requirements = product doesn't exist
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ⚠️ Present A/P/C menu after generating journey content
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from previous steps are available
|
||||
- Success criteria and scope already defined
|
||||
- Input documents from step-01 are available (product briefs with user personas)
|
||||
- Every human interaction with the system needs a journey
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Create compelling narrative user journeys that leverage existing personas from product briefs and identify additional user types needed for comprehensive coverage.
|
||||
|
||||
## JOURNEY MAPPING SEQUENCE:
|
||||
|
||||
### 1. Leverage Existing Users & Identify Additional Types
|
||||
|
||||
**Check Input Documents for Existing Personas:**
|
||||
Analyze product brief, research, and brainstorming documents for user personas already defined.
|
||||
|
||||
**If User Personas Exist in Input Documents:**
|
||||
Guide user to build on existing personas:
|
||||
- Acknowledge personas found in their product brief
|
||||
- Extract key persona details and backstories
|
||||
- Leverage existing insights about their needs
|
||||
- Prompt to identify additional user types beyond those documented
|
||||
- Suggest additional user types based on product context (admins, moderators, support, API consumers, internal ops)
|
||||
- Ask what additional user types should be considered
|
||||
|
||||
**If No Personas in Input Documents:**
|
||||
Start with comprehensive user type discovery:
|
||||
- Guide exploration of ALL people who interact with the system
|
||||
- Consider beyond primary users: admins, moderators, support staff, API consumers, internal ops
|
||||
- Ask what user types should be mapped for this specific product
|
||||
- Ensure comprehensive coverage of all system interactions
|
||||
|
||||
### 2. Create Narrative Story-Based Journeys
|
||||
|
||||
For each user type, create compelling narrative journeys that tell their story:
|
||||
|
||||
#### Narrative Journey Creation Process:
|
||||
|
||||
**If Using Existing Persona from Input Documents:**
|
||||
Guide narrative journey creation:
|
||||
- Use persona's existing backstory from brief
|
||||
- Explore how the product changes their life/situation
|
||||
- Craft journey narrative: where do we meet them, how does product help them write their next chapter?
|
||||
|
||||
**If Creating New Persona:**
|
||||
Guide persona creation with story framework:
|
||||
- Name: realistic name and personality
|
||||
- Situation: What's happening in their life/work that creates need?
|
||||
- Goal: What do they desperately want to achieve?
|
||||
- Obstacle: What's standing in their way?
|
||||
- Solution: How does the product solve their story?
|
||||
|
||||
**Story-Based Journey Mapping:**
|
||||
|
||||
Guide narrative journey creation using story structure:
|
||||
- **Opening Scene**: Where/how do we meet them? What's their current pain?
|
||||
- **Rising Action**: What steps do they take? What do they discover?
|
||||
- **Climax**: Critical moment where product delivers real value
|
||||
- **Resolution**: How does their situation improve? What's their new reality?
|
||||
|
||||
Encourage narrative format with specific user details, emotional journey, and clear before/after contrast
|
||||
|
||||
### 3. Guide Journey Exploration
|
||||
|
||||
For each journey, facilitate detailed exploration:
|
||||
- What happens at each step specifically?
|
||||
- What could go wrong? What's the recovery path?
|
||||
- What information do they need to see/hear?
|
||||
- What's their emotional state at each point?
|
||||
- Where does this journey succeed or fail?
|
||||
|
||||
### 4. Connect Journeys to Requirements
|
||||
|
||||
After each journey, explicitly state:
|
||||
- This journey reveals requirements for specific capability areas
|
||||
- Help user see how different journeys create different feature sets
|
||||
- Connect journey needs to concrete capabilities (onboarding, dashboards, notifications, etc.)
|
||||
|
||||
### 5. Aim for Comprehensive Coverage
|
||||
|
||||
Guide toward complete journey set:
|
||||
|
||||
- **Primary user** - happy path (core experience)
|
||||
- **Primary user** - edge case (different goal, error recovery)
|
||||
- **Secondary user** (admin, moderator, support, etc.)
|
||||
- **API consumer** (if applicable)
|
||||
|
||||
Ask if additional journeys are needed to cover uncovered user types
|
||||
|
||||
### 6. Generate User Journey Content
|
||||
|
||||
Prepare the content to append to the document:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
When saving to document, append these Level 2 and Level 3 sections:
|
||||
|
||||
```markdown
|
||||
## User Journeys
|
||||
|
||||
[All journey narratives based on conversation]
|
||||
|
||||
### Journey Requirements Summary
|
||||
|
||||
[Summary of capabilities revealed by journeys based on conversation]
|
||||
```
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Present the user journey content for review, then display menu:
|
||||
- Show the mapped user journeys (using structure from section 6)
|
||||
- Highlight how each journey reveals different capabilities
|
||||
- Ask if they'd like to refine further, get other perspectives, or proceed
|
||||
- Present menu options naturally as part of conversation
|
||||
|
||||
Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Domain Requirements (Step 5 of 11)"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Invoke the `bmad-advanced-elicitation` skill with the current journey content, process the enhanced journey insights that come back, ask user "Accept these improvements to the user journeys? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
|
||||
- IF P: Invoke the `bmad-party-mode` skill with the current journeys, process the collaborative journey improvements and additions, ask user "Accept these changes to the user journeys? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
|
||||
- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-05-domain.md
|
||||
- IF Any other: help user respond, then redisplay menu
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from step 6.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Existing personas from product briefs leveraged when available
|
||||
✅ All user types identified (not just primary users)
|
||||
✅ Rich narrative storytelling for each persona and journey
|
||||
✅ Complete story-based journey mapping with emotional arc
|
||||
✅ Journey requirements clearly connected to capabilities needed
|
||||
✅ Minimum 3-4 compelling narrative journeys covering different user types
|
||||
✅ A/P/C menu presented and handled correctly
|
||||
✅ Content properly appended to document when C selected
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Ignoring existing personas from product briefs
|
||||
❌ Only mapping primary user journeys and missing secondary users
|
||||
❌ Creating generic journeys without rich persona details and narrative
|
||||
❌ Missing emotional storytelling elements that make journeys compelling
|
||||
❌ Missing critical decision points and failure scenarios
|
||||
❌ Not connecting journeys to required capabilities
|
||||
❌ Not having enough journey diversity (admin, support, API, etc.)
|
||||
❌ Not presenting A/P/C menu after content generation
|
||||
❌ Appending content without user selecting 'C'
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## JOURNEY TYPES TO ENSURE:
|
||||
|
||||
**Minimum Coverage:**
|
||||
|
||||
1. **Primary User - Success Path**: Core experience journey
|
||||
2. **Primary User - Edge Case**: Error recovery, alternative goals
|
||||
3. **Admin/Operations User**: Management, configuration, monitoring
|
||||
4. **Support/Troubleshooting**: Help, investigation, issue resolution
|
||||
5. **API/Integration** (if applicable): Developer/technical user journey
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved to document, load `./step-05-domain.md`.
|
||||
|
||||
Remember: Do NOT proceed to step-05 until user explicitly selects 'C' from the A/P/C menu and content is saved!
|
||||
@@ -1,194 +0,0 @@
|
||||
# Step 5: Domain-Specific Requirements (Optional)
|
||||
|
||||
**Progress: Step 5 of 13** - Next: Innovation Focus
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
For complex domains only that have a mapping in ../data/domain-complexity.csv, explore domain-specific constraints, compliance requirements, and technical considerations that shape the product.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read
|
||||
- ✅ ALWAYS treat this as collaborative discovery between PM peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a product-focused PM facilitator collaborating with an expert peer
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring structured thinking and facilitation skills, while the user brings domain expertise
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 This step is OPTIONAL - only needed for complex domains
|
||||
- 🚫 SKIP if domain complexity is "low" from step-02
|
||||
- 💬 APPROACH: Natural conversation to discover domain-specific needs
|
||||
- 🎯 Focus on constraints, compliance, and domain patterns
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Check domain complexity from step-02 classification first
|
||||
- ⚠️ If complexity is "low", offer to skip this step
|
||||
- ⚠️ Present A/P/C menu after domain requirements defined (or skipped)
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Domain classification from step-02 is available
|
||||
- If complexity is low, this step may be skipped
|
||||
- Domain CSV data provides complexity reference
|
||||
- Focus on domain-specific constraints, not general requirements
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
For complex domains, explore what makes this domain special:
|
||||
- **Compliance requirements** - regulations, standards, certifications
|
||||
- **Technical constraints** - security, privacy, integration requirements
|
||||
- **Domain patterns** - common patterns, best practices, anti-patterns
|
||||
- **Risks and mitigations** - what could go wrong, how to prevent it
|
||||
|
||||
## DOMAIN DISCOVERY SEQUENCE:
|
||||
|
||||
### 1. Check Domain Complexity
|
||||
|
||||
**Review classification from step-02:**
|
||||
|
||||
- What's the domain complexity level? (low/medium/high)
|
||||
- What's the specific domain? (healthcare, fintech, education, etc.)
|
||||
|
||||
**If complexity is LOW:**
|
||||
|
||||
Offer to skip:
|
||||
"The domain complexity from our discovery is low. We may not need deep domain-specific requirements. Would you like to:
|
||||
- [C] Skip this step and move to Innovation
|
||||
- [D] Do domain exploration anyway"
|
||||
|
||||
**If complexity is MEDIUM or HIGH:**
|
||||
|
||||
Proceed with domain exploration.
|
||||
|
||||
### 2. Load Domain Reference Data
|
||||
|
||||
**Attempt subprocess data lookup:**
|
||||
|
||||
"Your task: Lookup data in ../data/domain-complexity.csv
|
||||
|
||||
**Search criteria:**
|
||||
- Find row where domain matches {{domainFromStep02}}
|
||||
|
||||
**Return format:**
|
||||
Return ONLY the matching row as a YAML-formatted object with these fields:
|
||||
domain, complexity, typical_concerns, compliance_requirements
|
||||
|
||||
**Do NOT return the entire CSV - only the matching row.**"
|
||||
|
||||
**Graceful degradation (if Task tool unavailable):**
|
||||
- Load the CSV file directly
|
||||
- Find the matching row manually
|
||||
- Extract required fields
|
||||
- Understand typical concerns and compliance requirements
|
||||
|
||||
### 3. Explore Domain-Specific Concerns
|
||||
|
||||
**Start with what you know:**
|
||||
|
||||
Acknowledge the domain and explore what makes it complex:
|
||||
- What regulations apply? (HIPAA, PCI-DSS, GDPR, SOX, etc.)
|
||||
- What standards matter? (ISO, NIST, domain-specific standards)
|
||||
- What certifications are needed? (security, privacy, domain-specific)
|
||||
- What integrations are required? (EMR systems, payment processors, etc.)
|
||||
|
||||
**Explore technical constraints:**
|
||||
- Security requirements (encryption, audit logs, access control)
|
||||
- Privacy requirements (data handling, consent, retention)
|
||||
- Performance requirements (real-time, batch, latency)
|
||||
- Availability requirements (uptime, disaster recovery)
|
||||
|
||||
### 4. Document Domain Requirements
|
||||
|
||||
**Structure the requirements around key concerns:**
|
||||
|
||||
```markdown
|
||||
### Compliance & Regulatory
|
||||
- [Specific requirements]
|
||||
|
||||
### Technical Constraints
|
||||
- [Security, privacy, performance needs]
|
||||
|
||||
### Integration Requirements
|
||||
- [Required systems and data flows]
|
||||
|
||||
### Risk Mitigations
|
||||
- [Domain-specific risks and how to address them]
|
||||
```
|
||||
|
||||
### 5. Validate Completeness
|
||||
|
||||
**Check with the user:**
|
||||
|
||||
"Are there other domain-specific concerns we should consider? For [this domain], what typically gets overlooked?"
|
||||
|
||||
### N. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue - Save and Proceed to Innovation (Step 6 of 13)"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Invoke the `bmad-advanced-elicitation` skill, and when finished redisplay the menu
|
||||
- IF P: Invoke the `bmad-party-mode` skill, and when finished redisplay the menu
|
||||
- IF C: Save content to {outputFile}, update frontmatter, then read fully and follow: ./step-06-innovation.md
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#n-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
|
||||
## APPEND TO DOCUMENT
|
||||
|
||||
When user selects 'C', append to `{outputFile}`:
|
||||
|
||||
```markdown
|
||||
## Domain-Specific Requirements
|
||||
|
||||
{{discovered domain requirements}}
|
||||
```
|
||||
|
||||
If step was skipped, append nothing and proceed.
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [content saved or skipped], will you then read fully and follow: `./step-06-innovation.md` to explore innovation.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Domain complexity checked before proceeding
|
||||
- Offered to skip if complexity is low
|
||||
- Natural conversation exploring domain concerns
|
||||
- Compliance, technical, and integration requirements identified
|
||||
- Domain-specific risks documented with mitigations
|
||||
- User validated completeness
|
||||
- Content properly saved (or step skipped) when C selected
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not checking domain complexity first
|
||||
- Not offering to skip for low-complexity domains
|
||||
- Missing critical compliance requirements
|
||||
- Not exploring technical constraints
|
||||
- Not asking about domain-specific risks
|
||||
- Being generic instead of domain-specific
|
||||
- Proceeding without user validation
|
||||
|
||||
**Master Rule:** This step is OPTIONAL for simple domains. For complex domains, focus on compliance, constraints, and domain patterns. Natural conversation, not checklists.
|
||||
@@ -1,211 +0,0 @@
|
||||
# Step 6: Innovation Discovery
|
||||
|
||||
**Progress: Step 6 of 11** - Next: Project Type Analysis
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ ALWAYS treat this as collaborative discovery between PM peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on detecting and exploring innovative aspects of the product
|
||||
- 🎯 OPTIONAL STEP: Only proceed if innovation signals are detected
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ⚠️ Present A/P/C menu after generating innovation content
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from previous steps are available
|
||||
- Project type from step-02 is available for innovation signal matching
|
||||
- Project-type CSV data will be loaded in this step
|
||||
- Focus on detecting genuine innovation, not forced creativity
|
||||
|
||||
## OPTIONAL STEP CHECK:
|
||||
|
||||
Before proceeding with this step, scan for innovation signals:
|
||||
|
||||
- Listen for language like "nothing like this exists", "rethinking how X works"
|
||||
- Check for project-type innovation signals from CSV
|
||||
- Look for novel approaches or unique combinations
|
||||
- If no innovation detected, skip this step
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Detect and explore innovation patterns in the product, focusing on what makes it truly novel and how to validate the innovative aspects.
|
||||
|
||||
## INNOVATION DISCOVERY SEQUENCE:
|
||||
|
||||
### 1. Load Project-Type Innovation Data
|
||||
|
||||
Load innovation signals specific to this project type:
|
||||
|
||||
- Load `../data/project-types.csv` completely
|
||||
- Find the row where `project_type` matches detected type from step-02
|
||||
- Extract `innovation_signals` (semicolon-separated list)
|
||||
- Extract `web_search_triggers` for potential innovation research
|
||||
|
||||
### 2. Listen for Innovation Indicators
|
||||
|
||||
Monitor conversation for both general and project-type-specific innovation signals:
|
||||
|
||||
#### General Innovation Language:
|
||||
|
||||
- "Nothing like this exists"
|
||||
- "We're rethinking how [X] works"
|
||||
- "Combining [A] with [B] for the first time"
|
||||
- "Novel approach to [problem]"
|
||||
- "No one has done [concept] before"
|
||||
|
||||
#### Project-Type-Specific Signals (from CSV):
|
||||
|
||||
Match user descriptions against innovation_signals for their project_type:
|
||||
|
||||
- **api_backend**: "API composition;New protocol"
|
||||
- **mobile_app**: "Gesture innovation;AR/VR features"
|
||||
- **saas_b2b**: "Workflow automation;AI agents"
|
||||
- **developer_tool**: "New paradigm;DSL creation"
|
||||
|
||||
### 3. Initial Innovation Screening
|
||||
|
||||
Ask targeted innovation discovery questions:
|
||||
- Guide exploration of what makes the product innovative
|
||||
- Explore if they're challenging existing assumptions
|
||||
- Ask about novel combinations of technologies/approaches
|
||||
- Identify what hasn't been done before
|
||||
- Understand which aspects feel most innovative
|
||||
|
||||
### 4. Deep Innovation Exploration (If Detected)
|
||||
|
||||
If innovation signals are found, explore deeply:
|
||||
|
||||
#### Innovation Discovery Questions:
|
||||
- What makes it unique compared to existing solutions?
|
||||
- What assumption are you challenging?
|
||||
- How do we validate it works?
|
||||
- What's the fallback if it doesn't?
|
||||
- Has anyone tried this before?
|
||||
|
||||
#### Market Context Research:
|
||||
|
||||
If relevant innovation detected, consider web search for context:
|
||||
Use `web_search_triggers` from project-type CSV:
|
||||
`[web_search_triggers] {concept} innovations {date}`
|
||||
|
||||
### 5. Generate Innovation Content (If Innovation Detected)
|
||||
|
||||
Prepare the content to append to the document:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
When saving to document, append these Level 2 and Level 3 sections:
|
||||
|
||||
```markdown
|
||||
## Innovation & Novel Patterns
|
||||
|
||||
### Detected Innovation Areas
|
||||
|
||||
[Innovation patterns identified based on conversation]
|
||||
|
||||
### Market Context & Competitive Landscape
|
||||
|
||||
[Market context and research based on conversation]
|
||||
|
||||
### Validation Approach
|
||||
|
||||
[Validation methodology based on conversation]
|
||||
|
||||
### Risk Mitigation
|
||||
|
||||
[Innovation risks and fallbacks based on conversation]
|
||||
```
|
||||
|
||||
### 6. Present MENU OPTIONS (Only if Innovation Detected)
|
||||
|
||||
Present the innovation content for review, then display menu:
|
||||
- Show identified innovative aspects (using structure from section 5)
|
||||
- Highlight differentiation from existing solutions
|
||||
- Ask if they'd like to refine further, get other perspectives, or proceed
|
||||
- Present menu options naturally as part of conversation
|
||||
|
||||
Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Project Type Analysis (Step 7 of 11)"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Invoke the `bmad-advanced-elicitation` skill with the current innovation content, process the enhanced innovation insights that come back, ask user "Accept these improvements to the innovation analysis? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
|
||||
- IF P: Invoke the `bmad-party-mode` skill with the current innovation content, process the collaborative innovation exploration and ideation, ask user "Accept these changes to the innovation analysis? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
|
||||
- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-07-project-type.md
|
||||
- IF Any other: help user respond, then redisplay menu
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
|
||||
## NO INNOVATION DETECTED:
|
||||
|
||||
If no genuine innovation signals are found after exploration:
|
||||
- Acknowledge that no clear innovation signals were found
|
||||
- Note this is fine - many successful products are excellent executions of existing concepts
|
||||
- Ask if they'd like to try finding innovative angles or proceed
|
||||
|
||||
Display: "**Select:** [A] Advanced Elicitation - Let's try to find innovative angles [C] Continue - Skip innovation section and move to Project Type Analysis (Step 7 of 11)"
|
||||
|
||||
### Menu Handling Logic:
|
||||
- IF A: Proceed with content generation anyway, then return to menu
|
||||
- IF C: Skip this step, then read fully and follow: ./step-07-project-type.md
|
||||
|
||||
### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from step 5.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Innovation signals properly detected from user conversation
|
||||
✅ Project-type innovation signals used to guide discovery
|
||||
✅ Genuine innovation explored (not forced creativity)
|
||||
✅ Validation approach clearly defined for innovative aspects
|
||||
✅ Risk mitigation strategies identified
|
||||
✅ A/P/C menu presented and handled correctly
|
||||
✅ Content properly appended to document when C selected
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Forced innovation when none genuinely exists
|
||||
❌ Not using project-type innovation signals from CSV
|
||||
❌ Missing market context research for novel concepts
|
||||
❌ Not addressing validation approach for innovative features
|
||||
❌ Creating innovation theater without real innovative aspects
|
||||
❌ Not presenting A/P/C menu after content generation
|
||||
❌ Appending content without user selecting 'C'
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## SKIP CONDITIONS:
|
||||
|
||||
Skip this step and load `./step-07-project-type.md` if:
|
||||
|
||||
- No innovation signals detected in conversation
|
||||
- Product is incremental improvement rather than breakthrough
|
||||
- User confirms innovation exploration is not needed
|
||||
- Project-type CSV has no innovation signals for this type
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved to document (or step is skipped), load `./step-07-project-type.md`.
|
||||
|
||||
Remember: Do NOT proceed to step-07 until user explicitly selects 'C' from the A/P/C menu (or confirms step skip)!
|
||||
@@ -1,222 +0,0 @@
|
||||
# Step 7: Project-Type Deep Dive
|
||||
|
||||
**Progress: Step 7 of 11** - Next: Scoping
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ ALWAYS treat this as collaborative discovery between PM peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on project-type specific requirements and technical considerations
|
||||
- 🎯 DATA-DRIVEN: Use CSV configuration to guide discovery
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ⚠️ Present A/P/C menu after generating project-type content
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from previous steps are available
|
||||
- Project type from step-02 is available for configuration loading
|
||||
- Project-type CSV data will be loaded in this step
|
||||
- Focus on technical and functional requirements specific to this project type
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Conduct project-type specific discovery using CSV-driven guidance to define technical requirements.
|
||||
|
||||
## PROJECT-TYPE DISCOVERY SEQUENCE:
|
||||
|
||||
### 1. Load Project-Type Configuration Data
|
||||
|
||||
**Attempt subprocess data lookup:**
|
||||
|
||||
"Your task: Lookup data in ../data/project-types.csv
|
||||
|
||||
**Search criteria:**
|
||||
- Find row where project_type matches {{projectTypeFromStep02}}
|
||||
|
||||
**Return format:**
|
||||
Return ONLY the matching row as a YAML-formatted object with these fields:
|
||||
project_type, key_questions, required_sections, skip_sections, innovation_signals
|
||||
|
||||
**Do NOT return the entire CSV - only the matching row.**"
|
||||
|
||||
**Graceful degradation (if Task tool unavailable):**
|
||||
- Load the CSV file directly
|
||||
- Find the matching row manually
|
||||
- Extract required fields:
|
||||
- `key_questions` (semicolon-separated list of discovery questions)
|
||||
- `required_sections` (semicolon-separated list of sections to document)
|
||||
- `skip_sections` (semicolon-separated list of sections to skip)
|
||||
- `innovation_signals` (already explored in step-6)
|
||||
|
||||
### 2. Conduct Guided Discovery Using Key Questions
|
||||
|
||||
Parse `key_questions` from CSV and explore each:
|
||||
|
||||
#### Question-Based Discovery:
|
||||
|
||||
For each question in `key_questions` from CSV:
|
||||
|
||||
- Ask the user naturally in conversational style
|
||||
- Listen for their response and ask clarifying follow-ups
|
||||
- Connect answers to product value proposition
|
||||
|
||||
**Example Flow:**
|
||||
If key_questions = "Endpoints needed?;Authentication method?;Data formats?;Rate limits?;Versioning?;SDK needed?"
|
||||
|
||||
Ask naturally:
|
||||
|
||||
- "What are the main endpoints your API needs to expose?"
|
||||
- "How will you handle authentication and authorization?"
|
||||
- "What data formats will you support for requests and responses?"
|
||||
|
||||
### 3. Document Project-Type Specific Requirements
|
||||
|
||||
Based on user answers to key_questions, synthesize comprehensive requirements:
|
||||
|
||||
#### Requirement Categories:
|
||||
|
||||
Cover the areas indicated by `required_sections` from CSV:
|
||||
|
||||
- Synthesize what was discovered for each required section
|
||||
- Document specific requirements, constraints, and decisions
|
||||
- Connect to product differentiator when relevant
|
||||
|
||||
#### Skip Irrelevant Sections:
|
||||
|
||||
Skip areas indicated by `skip_sections` from CSV to avoid wasting time on irrelevant aspects.
|
||||
|
||||
### 4. Generate Dynamic Content Sections
|
||||
|
||||
Parse `required_sections` list from the matched CSV row. For each section name, generate corresponding content:
|
||||
|
||||
#### Common CSV Section Mappings:
|
||||
|
||||
- "endpoint_specs" or "endpoint_specification" → API endpoints documentation
|
||||
- "auth_model" or "authentication_model" → Authentication approach
|
||||
- "platform_reqs" or "platform_requirements" → Platform support needs
|
||||
- "device_permissions" or "device_features" → Device capabilities
|
||||
- "tenant_model" → Multi-tenancy approach
|
||||
- "rbac_matrix" or "permission_matrix" → Permission structure
|
||||
|
||||
#### Template Variable Strategy:
|
||||
|
||||
- For sections matching common template variables: generate specific content
|
||||
- For sections without template matches: include in main project_type_requirements
|
||||
- Hybrid approach balances template structure with CSV-driven flexibility
|
||||
|
||||
### 5. Generate Project-Type Content
|
||||
|
||||
Prepare the content to append to the document:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
When saving to document, append these Level 2 and Level 3 sections:
|
||||
|
||||
```markdown
|
||||
## [Project Type] Specific Requirements
|
||||
|
||||
### Project-Type Overview
|
||||
|
||||
[Project type summary based on conversation]
|
||||
|
||||
### Technical Architecture Considerations
|
||||
|
||||
[Technical architecture requirements based on conversation]
|
||||
|
||||
[Dynamic sections based on CSV and conversation]
|
||||
|
||||
### Implementation Considerations
|
||||
|
||||
[Implementation specific requirements based on conversation]
|
||||
```
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Present the project-type content for review, then display menu:
|
||||
|
||||
"Based on our conversation and best practices for this product type, I've documented the {project_type}-specific requirements for {{project_name}}.
|
||||
|
||||
**Here's what I'll add to the document:**
|
||||
|
||||
[Show the complete markdown content from section 5]
|
||||
|
||||
**What would you like to do?**"
|
||||
|
||||
Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Scoping (Step 8 of 11)"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Invoke the `bmad-advanced-elicitation` skill with the current project-type content, process the enhanced technical insights that come back, ask user "Accept these improvements to the technical requirements? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
|
||||
- IF P: Invoke the `bmad-party-mode` skill with the current project-type requirements, process the collaborative technical expertise and validation, ask user "Accept these changes to the technical requirements? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
|
||||
- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-08-scoping.md
|
||||
- IF Any other: help user respond, then redisplay menu
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from previous steps.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Project-type configuration loaded and used effectively
|
||||
✅ All key questions from CSV explored with user input
|
||||
✅ Required sections generated per CSV configuration
|
||||
✅ Skip sections properly avoided to save time
|
||||
✅ Technical requirements connected to product value
|
||||
✅ A/P/C menu presented and handled correctly
|
||||
✅ Content properly appended to document when C selected
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Not loading or using project-type CSV configuration
|
||||
❌ Missing key questions from CSV in discovery process
|
||||
❌ Not generating required sections per CSV configuration
|
||||
❌ Documenting sections that should be skipped per CSV
|
||||
❌ Creating generic content without project-type specificity
|
||||
❌ Not presenting A/P/C menu after content generation
|
||||
❌ Appending content without user selecting 'C'
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## PROJECT-TYPE EXAMPLES:
|
||||
|
||||
**For api_backend:**
|
||||
|
||||
- Focus on endpoints, authentication, data schemas, rate limiting
|
||||
- Skip visual design and user journey sections
|
||||
- Generate API specification documentation
|
||||
|
||||
**For mobile_app:**
|
||||
|
||||
- Focus on platform requirements, device permissions, offline mode
|
||||
- Skip API endpoint documentation unless needed
|
||||
- Generate mobile-specific technical requirements
|
||||
|
||||
**For saas_b2b:**
|
||||
|
||||
- Focus on multi-tenancy, permissions, integrations
|
||||
- Skip mobile-first considerations unless relevant
|
||||
- Generate enterprise-specific requirements
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved to document, load `./step-08-scoping.md` to define project scope.
|
||||
|
||||
Remember: Do NOT proceed to step-08 (Scoping) until user explicitly selects 'C' from the A/P/C menu and content is saved!
|
||||
@@ -1,263 +0,0 @@
|
||||
# Step 8: Scoping Exercise - Scope Definition (Phased or Single-Release)
|
||||
|
||||
**Progress: Step 8 of 11** - Next: Functional Requirements
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ ALWAYS treat this as collaborative discovery between PM peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on strategic scope decisions that keep projects viable
|
||||
- 🎯 EMPHASIZE lean MVP thinking while preserving long-term vision
|
||||
- ⚠️ NEVER de-scope, defer, or phase out requirements that the user explicitly included in their input documents without asking first
|
||||
- ⚠️ NEVER invent phasing (MVP/Growth/Vision) unless the user requests phased delivery — if input documents define all components as core requirements, they are ALL in scope
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- 📚 Review the complete PRD document built so far
|
||||
- ⚠️ Present A/P/C menu after generating scoping decisions
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Complete PRD document built so far is available for review
|
||||
- User journeys, success criteria, and domain requirements are documented
|
||||
- Focus on strategic scope decisions, not feature details
|
||||
- Balance between user value and implementation feasibility
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Conduct comprehensive scoping exercise to define release boundaries and prioritize features based on the user's chosen delivery mode (phased or single-release).
|
||||
|
||||
## SCOPING SEQUENCE:
|
||||
|
||||
### 1. Review Current PRD State
|
||||
|
||||
Analyze everything documented so far:
|
||||
- Present synthesis of established vision, success criteria, journeys
|
||||
- Assess domain and innovation focus
|
||||
- Evaluate scope implications: simple MVP, medium, or complex project
|
||||
- Ask if initial assessment feels right or if they see it differently
|
||||
|
||||
### 2. Define MVP Strategy
|
||||
|
||||
Facilitate strategic MVP decisions:
|
||||
- Explore MVP philosophy options: problem-solving, experience, platform, or revenue MVP
|
||||
- Ask critical questions:
|
||||
- What's the minimum that would make users say 'this is useful'?
|
||||
- What would make investors/partners say 'this has potential'?
|
||||
- What's the fastest path to validated learning?
|
||||
- Guide toward appropriate MVP approach for their product
|
||||
|
||||
### 3. Scoping Decision Framework
|
||||
|
||||
Use structured decision-making for scope:
|
||||
|
||||
**Must-Have Analysis:**
|
||||
- Guide identification of absolute MVP necessities
|
||||
- For each journey and success criterion, ask:
|
||||
- Without this, does the product fail?
|
||||
- Can this be manual initially?
|
||||
- Is this a deal-breaker for early adopters?
|
||||
- Analyze journeys for MVP essentials
|
||||
|
||||
**Nice-to-Have Analysis:**
|
||||
- Identify what could be added later:
|
||||
- Features that enhance but aren't essential
|
||||
- User types that can be added later
|
||||
- Advanced functionality that builds on MVP
|
||||
- Ask what features could be added in versions 2, 3, etc.
|
||||
|
||||
**⚠️ SCOPE CHANGE CONFIRMATION GATE:**
|
||||
- If you believe any user-specified requirement should be deferred or de-scoped, you MUST present this to the user and get explicit confirmation BEFORE removing it from scope
|
||||
- Frame it as a recommendation, not a decision: "I'd recommend deferring X because [reason]. Do you agree, or should it stay in scope?"
|
||||
- NEVER silently move user requirements to a later phase or exclude them from MVP
|
||||
- Before creating any consequential phase-based artifacts (e.g., phase tags, labels, or follow-on prompts), present artifact creation as a recommendation and proceed only after explicit user approval
|
||||
|
||||
### 4. Progressive Feature Roadmap
|
||||
|
||||
**CRITICAL: Phasing is NOT automatic. Check the user's input first.**
|
||||
|
||||
Before proposing any phased approach, review the user's input documents:
|
||||
|
||||
- **If the input documents define all components as core requirements with no mention of phases:** Present all requirements as a single release scope. Do NOT invent phases or move requirements to fabricated future phases.
|
||||
- **If the input documents explicitly request phased delivery:** Guide mapping of features across the phases the user defined.
|
||||
- **If scope is unclear:** ASK the user whether they want phased delivery or a single release before proceeding.
|
||||
|
||||
**When the user requests phased delivery**, guide mapping of features across the phases the user defines:
|
||||
|
||||
- Use user-provided phase labels and count; if none are provided, propose a default (e.g., MVP/Growth/Vision) and ask for confirmation
|
||||
- Ensure clear progression and dependencies between phases
|
||||
|
||||
**Each phase should address:**
|
||||
|
||||
- Core user value delivery and essential journeys for that phase
|
||||
- Clear boundaries on what ships in each phase
|
||||
- Dependencies on prior phases
|
||||
|
||||
**When the user chooses a single release**, define the complete scope:
|
||||
|
||||
- All user-specified requirements are in scope
|
||||
- Focus must-have vs nice-to-have analysis on what ships in this release
|
||||
- Do NOT create phases — use must-have/nice-to-have priority within the single release
|
||||
|
||||
**If phased delivery:** "Where does your current vision fit in this development sequence?"
|
||||
**If single release:** "How does your current vision map to this upcoming release?"
|
||||
|
||||
### 5. Risk-Based Scoping
|
||||
|
||||
Identify and mitigate scoping risks:
|
||||
|
||||
**Technical Risks:**
|
||||
"Looking at your innovation and domain requirements:
|
||||
|
||||
- What's the most technically challenging aspect?
|
||||
- Could we simplify the initial implementation?
|
||||
- What's the riskiest assumption about technology feasibility?"
|
||||
|
||||
**Market Risks:**
|
||||
|
||||
- What's the biggest market risk?
|
||||
- How does the MVP address this?
|
||||
- What learning do we need to de-risk this?"
|
||||
|
||||
**Resource Risks:**
|
||||
|
||||
- What if we have fewer resources than planned?
|
||||
- What's the absolute minimum team size needed?
|
||||
- Can we launch with a smaller feature set?"
|
||||
|
||||
### 6. Generate Scoping Content
|
||||
|
||||
Prepare comprehensive scoping section:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
**If user chose phased delivery:**
|
||||
|
||||
```markdown
|
||||
## Project Scoping & Phased Development
|
||||
|
||||
### MVP Strategy & Philosophy
|
||||
|
||||
**MVP Approach:** {{chosen_mvp_approach}}
|
||||
**Resource Requirements:** {{mvp_team_size_and_skills}}
|
||||
|
||||
### MVP Feature Set (Phase 1)
|
||||
|
||||
**Core User Journeys Supported:**
|
||||
{{essential_journeys_for_mvp}}
|
||||
|
||||
**Must-Have Capabilities:**
|
||||
{{list_of_essential_mvp_features}}
|
||||
|
||||
### Post-MVP Features
|
||||
|
||||
**Phase 2 (Post-MVP):**
|
||||
{{planned_growth_features}}
|
||||
|
||||
**Phase 3 (Expansion):**
|
||||
{{planned_expansion_features}}
|
||||
|
||||
### Risk Mitigation Strategy
|
||||
|
||||
**Technical Risks:** {{mitigation_approach}}
|
||||
**Market Risks:** {{validation_approach}}
|
||||
**Resource Risks:** {{contingency_approach}}
|
||||
```
|
||||
|
||||
**If user chose single release (no phasing):**
|
||||
|
||||
```markdown
|
||||
## Project Scoping
|
||||
|
||||
### Strategy & Philosophy
|
||||
|
||||
**Approach:** {{chosen_approach}}
|
||||
**Resource Requirements:** {{team_size_and_skills}}
|
||||
|
||||
### Complete Feature Set
|
||||
|
||||
**Core User Journeys Supported:**
|
||||
{{all_journeys}}
|
||||
|
||||
**Must-Have Capabilities:**
|
||||
{{list_of_must_have_features}}
|
||||
|
||||
**Nice-to-Have Capabilities:**
|
||||
{{list_of_nice_to_have_features}}
|
||||
|
||||
### Risk Mitigation Strategy
|
||||
|
||||
**Technical Risks:** {{mitigation_approach}}
|
||||
**Market Risks:** {{validation_approach}}
|
||||
**Resource Risks:** {{contingency_approach}}
|
||||
```
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Present the scoping decisions for review, then display menu:
|
||||
- Show strategic scoping plan (using structure from step 6)
|
||||
- Highlight release boundaries and prioritization (phased roadmap only if phased delivery was selected)
|
||||
- Ask if they'd like to refine further, get other perspectives, or proceed
|
||||
- Present menu options naturally as part of conversation
|
||||
|
||||
Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Functional Requirements (Step 9 of 11)"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Invoke the `bmad-advanced-elicitation` skill with the current scoping analysis, process the enhanced insights that come back, ask user if they accept the improvements, if yes update content then redisplay menu, if no keep original content then redisplay menu
|
||||
- IF P: Invoke the `bmad-party-mode` skill with the scoping context, process the collaborative insights on MVP and roadmap decisions, ask user if they accept the changes, if yes update content then redisplay menu, if no keep original content then redisplay menu
|
||||
- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array (also add `releaseMode: phased` or `releaseMode: single-release` to frontmatter based on user's choice), then read fully and follow: ./step-09-functional.md
|
||||
- IF Any other: help user respond, then redisplay menu
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from step 6.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Complete PRD document analyzed for scope implications
|
||||
✅ Strategic MVP approach defined and justified
|
||||
✅ Clear feature boundaries established (phased or single-release, per user preference)
|
||||
✅ All user-specified requirements accounted for — none silently removed or deferred
|
||||
✅ Any scope reduction recommendations presented to user with rationale and explicit confirmation obtained
|
||||
✅ Key risks identified and mitigation strategies defined
|
||||
✅ User explicitly agrees to scope decisions
|
||||
✅ A/P/C menu presented and handled correctly
|
||||
✅ Content properly appended to document when C selected
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Not analyzing the complete PRD before making scoping decisions
|
||||
❌ Making scope decisions without strategic rationale
|
||||
❌ Not getting explicit user agreement on MVP boundaries
|
||||
❌ Missing critical risk analysis
|
||||
❌ Not presenting A/P/C menu after content generation
|
||||
❌ **CRITICAL**: Silently de-scoping or deferring requirements that the user explicitly included in their input documents
|
||||
❌ **CRITICAL**: Inventing phasing (MVP/Growth/Vision) when the user did not request phased delivery
|
||||
❌ **CRITICAL**: Making consequential scoping decisions (what is in/out of scope) without explicit user confirmation
|
||||
❌ **CRITICAL**: Creating phase-based artifacts (tags, labels, follow-on prompts) without explicit user approval
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved to document, load ./step-09-functional.md.
|
||||
|
||||
Remember: Do NOT proceed to step-09 until user explicitly selects 'C' from the A/P/C menu and content is saved!
|
||||
@@ -1,219 +0,0 @@
|
||||
# Step 9: Functional Requirements Synthesis
|
||||
|
||||
**Progress: Step 9 of 11** - Next: Non-Functional Requirements
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ ALWAYS treat this as collaborative discovery between PM peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on creating comprehensive capability inventory for the product
|
||||
- 🎯 CRITICAL: This is THE CAPABILITY CONTRACT for all downstream work
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ⚠️ Present A/P/C menu after generating functional requirements
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from previous steps are available
|
||||
- ALL previous content (executive summary, success criteria, journeys, domain, innovation, project-type) must be referenced
|
||||
- No additional data files needed for this step
|
||||
- Focus on capabilities, not implementation details
|
||||
|
||||
## CRITICAL IMPORTANCE:
|
||||
|
||||
**This section defines THE CAPABILITY CONTRACT for the entire product:**
|
||||
|
||||
- UX designers will ONLY design what's listed here
|
||||
- Architects will ONLY support what's listed here
|
||||
- Epic breakdown will ONLY implement what's listed here
|
||||
- If a capability is missing from FRs, it will NOT exist in the final product
|
||||
|
||||
## FUNCTIONAL REQUIREMENTS SYNTHESIS SEQUENCE:
|
||||
|
||||
### 1. Understand FR Purpose and Usage
|
||||
|
||||
Start by explaining the critical role of functional requirements:
|
||||
|
||||
**Purpose:**
|
||||
FRs define WHAT capabilities the product must have. They are the complete inventory of user-facing and system capabilities that deliver the product vision.
|
||||
|
||||
**Critical Properties:**
|
||||
✅ Each FR is a testable capability
|
||||
✅ Each FR is implementation-agnostic (could be built many ways)
|
||||
✅ Each FR specifies WHO and WHAT, not HOW
|
||||
✅ No UI details, no performance numbers, no technology choices
|
||||
✅ Comprehensive coverage of capability areas
|
||||
|
||||
**How They Will Be Used:**
|
||||
|
||||
1. UX Designer reads FRs → designs interactions for each capability
|
||||
2. Architect reads FRs → designs systems to support each capability
|
||||
3. PM reads FRs → creates epics and stories to implement each capability
|
||||
|
||||
### 2. Review Existing Content for Capability Extraction
|
||||
|
||||
Systematically review all previous sections to extract capabilities:
|
||||
|
||||
**Extract From:**
|
||||
|
||||
- Executive Summary → Core product differentiator capabilities
|
||||
- Success Criteria → Success-enabling capabilities
|
||||
- User Journeys → Journey-revealed capabilities
|
||||
- Domain Requirements → Compliance and regulatory capabilities
|
||||
- Innovation Patterns → Innovative feature capabilities
|
||||
- Project-Type Requirements → Technical capability needs
|
||||
|
||||
### 3. Organize Requirements by Capability Area
|
||||
|
||||
Group FRs by logical capability areas (NOT by technology or layer):
|
||||
|
||||
**Good Grouping Examples:**
|
||||
|
||||
- ✅ "User Management" (not "Authentication System")
|
||||
- ✅ "Content Discovery" (not "Search Algorithm")
|
||||
- ✅ "Team Collaboration" (not "WebSocket Infrastructure")
|
||||
|
||||
**Target 5-8 Capability Areas** for typical projects.
|
||||
|
||||
### 4. Generate Comprehensive FR List
|
||||
|
||||
Create complete functional requirements using this format:
|
||||
|
||||
**Format:**
|
||||
|
||||
- FR#: [Actor] can [capability] [context/constraint if needed]
|
||||
- Number sequentially (FR1, FR2, FR3...)
|
||||
- Aim for 20-50 FRs for typical projects
|
||||
|
||||
**Altitude Check:**
|
||||
Each FR should answer "WHAT capability exists?" NOT "HOW it's implemented?"
|
||||
|
||||
**Examples:**
|
||||
|
||||
- ✅ "Users can customize appearance settings"
|
||||
- ❌ "Users can toggle light/dark theme with 3 font size options stored in LocalStorage"
|
||||
|
||||
### 5. Self-Validation Process
|
||||
|
||||
Before presenting to user, validate the FR list:
|
||||
|
||||
**Completeness Check:**
|
||||
|
||||
1. "Did I cover EVERY capability mentioned in the MVP scope section?"
|
||||
2. "Did I include domain-specific requirements as FRs?"
|
||||
3. "Did I cover the project-type specific needs?"
|
||||
4. "Could a UX designer read ONLY the FRs and know what to design?"
|
||||
5. "Could an Architect read ONLY the FRs and know what to support?"
|
||||
6. "Are there any user actions or system behaviors we discussed that have no FR?"
|
||||
|
||||
**Altitude Check:**
|
||||
|
||||
1. "Am I stating capabilities (WHAT) or implementation (HOW)?"
|
||||
2. "Am I listing acceptance criteria or UI specifics?" (Remove if yes)
|
||||
3. "Could this FR be implemented 5 different ways?" (Good - means it's not prescriptive)
|
||||
|
||||
**Quality Check:**
|
||||
|
||||
1. "Is each FR clear enough that someone could test whether it exists?"
|
||||
2. "Is each FR independent (not dependent on reading other FRs to understand)?"
|
||||
3. "Did I avoid vague terms like 'good', 'fast', 'easy'?" (Use NFRs for quality attributes)
|
||||
|
||||
### 6. Generate Functional Requirements Content
|
||||
|
||||
Prepare the content to append to the document:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
When saving to document, append these Level 2 and Level 3 sections:
|
||||
|
||||
```markdown
|
||||
## Functional Requirements
|
||||
|
||||
### [Capability Area Name]
|
||||
|
||||
- FR1: [Specific Actor] can [specific capability]
|
||||
- FR2: [Specific Actor] can [specific capability]
|
||||
- FR3: [Specific Actor] can [specific capability]
|
||||
|
||||
### [Another Capability Area]
|
||||
|
||||
- FR4: [Specific Actor] can [specific capability]
|
||||
- FR5: [Specific Actor] can [specific capability]
|
||||
|
||||
[Continue for all capability areas discovered in conversation]
|
||||
```
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Present the functional requirements for review, then display menu:
|
||||
- Show synthesized functional requirements (using structure from step 6)
|
||||
- Emphasize this is the capability contract for all downstream work
|
||||
- Highlight that every feature must trace back to these requirements
|
||||
- Ask if they'd like to refine further, get other perspectives, or proceed
|
||||
- Present menu options naturally as part of conversation
|
||||
|
||||
**What would you like to do?**"
|
||||
|
||||
Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Non-Functional Requirements (Step 10 of 11)"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Invoke the `bmad-advanced-elicitation` skill with the current FR list, process the enhanced capability coverage that comes back, ask user if they accept the additions, if yes update content then redisplay menu, if no keep original content then redisplay menu
|
||||
- IF P: Invoke the `bmad-party-mode` skill with the current FR list, process the collaborative capability validation and additions, ask user if they accept the changes, if yes update content then redisplay menu, if no keep original content then redisplay menu
|
||||
- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-10-nonfunctional.md
|
||||
- IF Any other: help user respond, then redisplay menu
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from step 6.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ All previous discovery content synthesized into FRs
|
||||
✅ FRs organized by capability areas (not technology)
|
||||
✅ Each FR states WHAT capability exists, not HOW to implement
|
||||
✅ Comprehensive coverage with 20-50 FRs typical
|
||||
✅ Altitude validation ensures implementation-agnostic requirements
|
||||
✅ Completeness check validates coverage of all discussed capabilities
|
||||
✅ A/P/C menu presented and handled correctly
|
||||
✅ Content properly appended to document when C selected
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Missing capabilities from previous discovery sections
|
||||
❌ Organizing FRs by technology instead of capability areas
|
||||
❌ Including implementation details or UI specifics in FRs
|
||||
❌ Not achieving comprehensive coverage of discussed capabilities
|
||||
❌ Using vague terms instead of testable capabilities
|
||||
❌ Not presenting A/P/C menu after content generation
|
||||
❌ Appending content without user selecting 'C'
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## CAPABILITY CONTRACT REMINDER:
|
||||
|
||||
Emphasize to user: "This FR list is now binding. Any feature not listed here will not exist in the final product unless we explicitly add it. This is why it's critical to ensure completeness now."
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved to document, load ./step-10-nonfunctional.md to define non-functional requirements.
|
||||
|
||||
Remember: Do NOT proceed to step-10 until user explicitly selects 'C' from the A/P/C menu and content is saved!
|
||||
@@ -1,230 +0,0 @@
|
||||
# Step 10: Non-Functional Requirements
|
||||
|
||||
**Progress: Step 10 of 12** - Next: Polish Document
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ ALWAYS treat this as collaborative discovery between PM peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on quality attributes that matter for THIS specific product
|
||||
- 🎯 SELECTIVE: Only document NFRs that actually apply to the product
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ⚠️ Present A/P/C menu after generating NFR content
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from previous steps are available
|
||||
- Functional requirements already defined and will inform NFRs
|
||||
- Domain and project-type context will guide which NFRs matter
|
||||
- Focus on specific, measurable quality criteria
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Define non-functional requirements that specify quality attributes for the product, focusing only on what matters for THIS specific product.
|
||||
|
||||
## NON-FUNCTIONAL REQUIREMENTS SEQUENCE:
|
||||
|
||||
### 1. Explain NFR Purpose and Scope
|
||||
|
||||
Start by clarifying what NFRs are and why we're selective:
|
||||
|
||||
**NFR Purpose:**
|
||||
NFRs define HOW WELL the system must perform, not WHAT it must do. They specify quality attributes like performance, security, scalability, etc.
|
||||
|
||||
**Selective Approach:**
|
||||
We only document NFRs that matter for THIS product. If a category doesn't apply, we skip it entirely. This prevents requirement bloat and focuses on what's actually important.
|
||||
|
||||
### 2. Assess Product Context for NFR Relevance
|
||||
|
||||
Evaluate which NFR categories matter based on product context:
|
||||
|
||||
**Quick Assessment Questions:**
|
||||
|
||||
- **Performance**: Is there user-facing impact of speed?
|
||||
- **Security**: Are we handling sensitive data or payments?
|
||||
- **Scalability**: Do we expect rapid user growth?
|
||||
- **Accessibility**: Are we serving broad public audiences?
|
||||
- **Integration**: Do we need to connect with other systems?
|
||||
- **Reliability**: Would downtime cause significant problems?
|
||||
|
||||
### 3. Explore Relevant NFR Categories
|
||||
|
||||
For each relevant category, conduct targeted discovery:
|
||||
|
||||
#### Performance NFRs (If relevant):
|
||||
|
||||
Explore performance requirements:
|
||||
- What parts of the system need to be fast for users to be successful?
|
||||
- Are there specific response time expectations?
|
||||
- What happens if performance is slower than expected?
|
||||
- Are there concurrent user scenarios we need to support?
|
||||
|
||||
#### Security NFRs (If relevant):
|
||||
|
||||
Explore security requirements:
|
||||
- What data needs to be protected?
|
||||
- Who should have access to what?
|
||||
- What are the security risks we need to mitigate?
|
||||
- Are there compliance requirements (GDPR, HIPAA, PCI-DSS)?
|
||||
|
||||
#### Scalability NFRs (If relevant):
|
||||
|
||||
Explore scalability requirements:
|
||||
- How many users do we expect initially? Long-term?
|
||||
- Are there seasonal or event-based traffic spikes?
|
||||
- What happens if we exceed our capacity?
|
||||
- What growth scenarios should we plan for?
|
||||
|
||||
#### Accessibility NFRs (If relevant):
|
||||
|
||||
Explore accessibility requirements:
|
||||
- Are we serving users with visual, hearing, or motor impairments?
|
||||
- Are there legal accessibility requirements (WCAG, Section 508)?
|
||||
- What accessibility features are most important for our users?
|
||||
|
||||
#### Integration NFRs (If relevant):
|
||||
|
||||
Explore integration requirements:
|
||||
- What external systems do we need to connect with?
|
||||
- Are there APIs or data formats we must support?
|
||||
- How reliable do these integrations need to be?
|
||||
|
||||
### 4. Make NFRs Specific and Measurable
|
||||
|
||||
For each relevant NFR category, ensure criteria are testable:
|
||||
|
||||
**From Vague to Specific:**
|
||||
|
||||
- NOT: "The system should be fast" → "User actions complete within 2 seconds"
|
||||
- NOT: "The system should be secure" → "All data is encrypted at rest and in transit"
|
||||
- NOT: "The system should scale" → "System supports 10x user growth with <10% performance degradation"
|
||||
|
||||
### 5. Generate NFR Content (Only Relevant Categories)
|
||||
|
||||
Prepare the content to append to the document:
|
||||
|
||||
#### Content Structure (Dynamic based on relevance):
|
||||
|
||||
When saving to document, append these Level 2 and Level 3 sections (only include sections that are relevant):
|
||||
|
||||
```markdown
|
||||
## Non-Functional Requirements
|
||||
|
||||
### Performance
|
||||
|
||||
[Performance requirements based on conversation - only include if relevant]
|
||||
|
||||
### Security
|
||||
|
||||
[Security requirements based on conversation - only include if relevant]
|
||||
|
||||
### Scalability
|
||||
|
||||
[Scalability requirements based on conversation - only include if relevant]
|
||||
|
||||
### Accessibility
|
||||
|
||||
[Accessibility requirements based on conversation - only include if relevant]
|
||||
|
||||
### Integration
|
||||
|
||||
[Integration requirements based on conversation - only include if relevant]
|
||||
```
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Present the non-functional requirements for review, then display menu:
|
||||
- Show defined NFRs (using structure from step 5)
|
||||
- Note that only relevant categories were included
|
||||
- Emphasize NFRs specify how well the system needs to perform
|
||||
- Ask if they'd like to refine further, get other perspectives, or proceed
|
||||
- Present menu options naturally as part of conversation
|
||||
|
||||
Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Polish Document (Step 11 of 12)"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Invoke the `bmad-advanced-elicitation` skill with the current NFR content, process the enhanced quality attribute insights that come back, ask user if they accept the improvements, if yes update content then redisplay menu, if no keep original content then redisplay menu
|
||||
- IF P: Invoke the `bmad-party-mode` skill with the current NFR list, process the collaborative technical validation and additions, ask user if they accept the changes, if yes update content then redisplay menu, if no keep original content then redisplay menu
|
||||
- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-11-polish.md
|
||||
- IF Any other: help user respond, then redisplay menu
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from step 5.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Only relevant NFR categories documented (no requirement bloat)
|
||||
✅ Each NFR is specific and measurable
|
||||
✅ NFRs connected to actual user needs and business context
|
||||
✅ Vague requirements converted to testable criteria
|
||||
✅ Domain-specific compliance requirements included if relevant
|
||||
✅ A/P/C menu presented and handled correctly
|
||||
✅ Content properly appended to document when C selected
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Documenting NFR categories that don't apply to the product
|
||||
❌ Leaving requirements vague and unmeasurable
|
||||
❌ Not connecting NFRs to actual user or business needs
|
||||
❌ Missing domain-specific compliance requirements
|
||||
❌ Creating overly prescriptive technical requirements
|
||||
❌ Not presenting A/P/C menu after content generation
|
||||
❌ Appending content without user selecting 'C'
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## NFR CATEGORY GUIDANCE:
|
||||
|
||||
**Include Performance When:**
|
||||
|
||||
- User-facing response times impact success
|
||||
- Real-time interactions are critical
|
||||
- Performance is a competitive differentiator
|
||||
|
||||
**Include Security When:**
|
||||
|
||||
- Handling sensitive user data
|
||||
- Processing payments or financial information
|
||||
- Subject to compliance regulations
|
||||
- Protecting intellectual property
|
||||
|
||||
**Include Scalability When:**
|
||||
|
||||
- Expecting rapid user growth
|
||||
- Handling variable traffic patterns
|
||||
- Supporting enterprise-scale usage
|
||||
- Planning for market expansion
|
||||
|
||||
**Include Accessibility When:**
|
||||
|
||||
- Serving broad public audiences
|
||||
- Subject to accessibility regulations
|
||||
- Targeting users with disabilities
|
||||
- B2B customers with accessibility requirements
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved to document, load ./step-11-polish.md to finalize the PRD and complete the workflow.
|
||||
|
||||
Remember: Do NOT proceed to step-11 until user explicitly selects 'C' from the A/P/C menu and content is saved!
|
||||
@@ -1,221 +0,0 @@
|
||||
# Step 11: Document Polish
|
||||
|
||||
**Progress: Step 11 of 12** - Next: Complete PRD
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 CRITICAL: Load the ENTIRE document before making changes
|
||||
- 📖 CRITICAL: Read complete step file before taking action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- ✅ This is a POLISH step - optimize existing content
|
||||
- 📋 IMPROVE flow, coherence, and readability
|
||||
- 💬 PRESERVE user's voice and intent
|
||||
- 🎯 MAINTAIN all essential information while improving presentation
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load complete document first
|
||||
- 📝 Review for flow and coherence issues
|
||||
- ✂️ Reduce duplication while preserving essential info
|
||||
- 📖 Ensure proper ## Level 2 headers throughout
|
||||
- 💾 Save optimized document
|
||||
- ⚠️ Present A/P/C menu after polish
|
||||
- 🚫 DO NOT skip review steps
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Complete PRD document exists from all previous steps
|
||||
- Document may have duplication from progressive append
|
||||
- Sections may not flow smoothly together
|
||||
- Level 2 headers ensure document can be split if needed
|
||||
- Focus on readability and coherence
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Optimize the complete PRD document for flow, coherence, and professional presentation while preserving all essential information.
|
||||
|
||||
## DOCUMENT POLISH SEQUENCE:
|
||||
|
||||
### 1. Load Context and Document
|
||||
|
||||
**CRITICAL:** Load the PRD purpose document first:
|
||||
|
||||
- Read `../data/prd-purpose.md` to understand what makes a great BMAD PRD
|
||||
- Internalize the philosophy: information density, traceability, measurable requirements
|
||||
- Keep the dual-audience nature (humans + LLMs) in mind
|
||||
|
||||
**Then Load the PRD Document:**
|
||||
|
||||
- Read `{outputFile}` completely from start to finish
|
||||
- Understand the full document structure and content
|
||||
- Identify all sections and their relationships
|
||||
- Note areas that need attention
|
||||
|
||||
### 2. Document Quality Review
|
||||
|
||||
Review the entire document with PRD purpose principles in mind:
|
||||
|
||||
**Information Density:**
|
||||
- Are there wordy phrases that can be condensed?
|
||||
- Is conversational padding present?
|
||||
- Can sentences be more direct and concise?
|
||||
|
||||
**Flow and Coherence:**
|
||||
- Do sections transition smoothly?
|
||||
- Are there jarring topic shifts?
|
||||
- Does the document tell a cohesive story?
|
||||
- Is the progression logical for readers?
|
||||
|
||||
**Duplication Detection:**
|
||||
- Are ideas repeated across sections?
|
||||
- Is the same information stated multiple times?
|
||||
- Can redundant content be consolidated?
|
||||
- Are there contradictory statements?
|
||||
|
||||
**Header Structure:**
|
||||
- Are all main sections using ## Level 2 headers?
|
||||
- Is the hierarchy consistent (##, ###, ####)?
|
||||
- Can sections be easily extracted or referenced?
|
||||
- Are headers descriptive and clear?
|
||||
|
||||
**Readability:**
|
||||
- Are sentences clear and concise?
|
||||
- Is the language consistent throughout?
|
||||
- Are technical terms used appropriately?
|
||||
- Would stakeholders find this easy to understand?
|
||||
|
||||
### 2b. Brainstorming Reconciliation (if brainstorming input exists)
|
||||
|
||||
**Check the PRD frontmatter `inputDocuments` for any brainstorming document** (e.g., `brainstorming-session*.md`, `brainstorming-report.md`). If a brainstorming document was used as input:
|
||||
|
||||
1. **Load the brainstorming document** and extract all distinct ideas, themes, and recommendations
|
||||
2. **Cross-reference against the PRD** — for each brainstorming idea, check if it landed in any PRD section (requirements, success criteria, user journeys, scope, etc.)
|
||||
3. **Identify dropped ideas** — ideas from brainstorming that do not appear anywhere in the PRD. Pay special attention to:
|
||||
- Tone, personality, and interaction design ideas (these are most commonly lost)
|
||||
- Design philosophy and coaching approach ideas
|
||||
- "What should this feel like" ideas (UX feel, not just UX function)
|
||||
- Qualitative/soft ideas that don't map cleanly to functional requirements
|
||||
4. **Present findings to user**: "These brainstorming ideas did not make it into the PRD: [list]. Should any be incorporated?"
|
||||
5. **If user wants to incorporate dropped ideas**: Add them to the most appropriate PRD section (success criteria, non-functional requirements, or a new section if needed)
|
||||
|
||||
**Why this matters**: Brainstorming documents are often long, and the PRD's structured template has an implicit bias toward concrete/structural ideas. Soft ideas (tone, philosophy, interaction feel) frequently get silently dropped because they don't map cleanly to FR/NFR format.
|
||||
|
||||
### 3. Optimization Actions
|
||||
|
||||
Make targeted improvements:
|
||||
|
||||
**Improve Flow:**
|
||||
- Add transition sentences between sections
|
||||
- Smooth out jarring topic shifts
|
||||
- Ensure logical progression
|
||||
- Connect related concepts across sections
|
||||
|
||||
**Reduce Duplication:**
|
||||
- Consolidate repeated information
|
||||
- Keep content in the most appropriate section
|
||||
- Use cross-references instead of repetition
|
||||
- Remove redundant explanations
|
||||
|
||||
**Enhance Coherence:**
|
||||
- Ensure consistent terminology throughout
|
||||
- Align all sections with product differentiator
|
||||
- Maintain consistent voice and tone
|
||||
- Verify scope consistency across sections
|
||||
|
||||
**Optimize Headers:**
|
||||
- Ensure all main sections use ## Level 2
|
||||
- Make headers descriptive and action-oriented
|
||||
- Check that headers follow consistent patterns
|
||||
- Verify headers support document navigation
|
||||
|
||||
### 4. Preserve Critical Information
|
||||
|
||||
**While optimizing, ensure NOTHING essential is lost:**
|
||||
|
||||
**Must Preserve:**
|
||||
- All user success criteria
|
||||
- All functional requirements (capability contract)
|
||||
- All user journey narratives
|
||||
- All scope decisions (whether phased or single-release), including consent-critical evidence (explicit user confirmations and rationales for any scope changes from step 8)
|
||||
- All non-functional requirements
|
||||
- Product differentiator and vision
|
||||
- Domain-specific requirements
|
||||
- Innovation analysis (if present)
|
||||
|
||||
**Can Consolidate:**
|
||||
- Repeated explanations of the same concept
|
||||
- Redundant background information
|
||||
- Multiple versions of similar content
|
||||
- Overlapping examples
|
||||
|
||||
### 5. Generate Optimized Document
|
||||
|
||||
Create the polished version:
|
||||
|
||||
**Polishing Process:**
|
||||
1. Start with original document
|
||||
2. Apply all optimization actions
|
||||
3. Review to ensure nothing essential was lost
|
||||
4. Verify improvements enhance readability
|
||||
5. Prepare optimized version for review
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Present the polished document for review, then display menu:
|
||||
- Show what changed in the polish
|
||||
- Highlight improvements made (flow, duplication, headers)
|
||||
- Ask if they'd like to refine further, get other perspectives, or proceed
|
||||
- Present menu options naturally as part of conversation
|
||||
|
||||
Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Complete PRD (Step 12 of 12)"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Invoke the `bmad-advanced-elicitation` skill with the polished document, process the enhanced refinements that come back, ask user "Accept these polish improvements? (y/n)", if yes update content with improvements then redisplay menu, if no keep original polish then redisplay menu
|
||||
- IF P: Invoke the `bmad-party-mode` skill with the polished document, process the collaborative refinements to flow and coherence, ask user "Accept these polish changes? (y/n)", if yes update content with improvements then redisplay menu, if no keep original polish then redisplay menu
|
||||
- IF C: Save the polished document to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-12-complete.md
|
||||
- IF Any other: help user respond, then redisplay menu
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', replace the entire document content with the polished version.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Complete document loaded and reviewed
|
||||
✅ Flow and coherence improved
|
||||
✅ Duplication reduced while preserving essential information
|
||||
✅ All main sections use ## Level 2 headers
|
||||
✅ Transitions between sections are smooth
|
||||
✅ User's voice and intent preserved
|
||||
✅ Document is more readable and professional
|
||||
✅ A/P/C menu presented and handled correctly
|
||||
✅ Brainstorming reconciliation completed (if brainstorming input exists)
|
||||
✅ Polished document saved when C selected
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Loading only partial document (leads to incomplete polish)
|
||||
❌ Removing essential information while reducing duplication
|
||||
❌ Not preserving user's voice and intent
|
||||
❌ Changing content instead of improving presentation
|
||||
❌ Not ensuring ## Level 2 headers for main sections
|
||||
❌ Making arbitrary style changes instead of coherence improvements
|
||||
❌ Not presenting A/P/C menu for user approval
|
||||
❌ Saving polished document without user selecting 'C'
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making changes without complete understanding of document requirements
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and polished document is saved, load `./step-12-complete.md` to complete the workflow.
|
||||
|
||||
Remember: Do NOT proceed to step-12 until user explicitly selects 'C' from the A/P/C menu and polished document is saved!
|
||||
@@ -1,121 +0,0 @@
|
||||
# Step 12: Workflow Completion
|
||||
|
||||
**Final Step - Complete the PRD**
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- ✅ THIS IS A FINAL STEP - Workflow completion required
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action
|
||||
- 🛑 NO content generation - this is a wrap-up step
|
||||
- 📋 FINALIZE document and update workflow status
|
||||
- 💬 FOCUS on completion, validation options, and next steps
|
||||
- 🎯 UPDATE workflow status files with completion information
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- 💾 Update the main workflow status file with completion information (if exists)
|
||||
- 📖 Offer validation workflow options to user
|
||||
- 🚫 DO NOT load additional steps after this one
|
||||
|
||||
## TERMINATION STEP PROTOCOLS:
|
||||
|
||||
- This is a FINAL step - workflow completion required
|
||||
- Update workflow status file with finalized document
|
||||
- Suggest validation and next workflow steps
|
||||
- Mark workflow as complete in status tracking
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Complete and polished PRD document is available from all previous steps
|
||||
- Workflow frontmatter shows all completed steps including polish
|
||||
- All collaborative content has been generated, saved, and optimized
|
||||
- Focus on completion, validation options, and next steps
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Complete the PRD workflow, update status files, offer validation options, and suggest next steps for the project.
|
||||
|
||||
## WORKFLOW COMPLETION SEQUENCE:
|
||||
|
||||
### 1. Announce Workflow Completion
|
||||
|
||||
Inform user that the PRD is complete and polished:
|
||||
- Celebrate successful completion of comprehensive PRD
|
||||
- Summarize all sections that were created
|
||||
- Highlight that document has been polished for flow and coherence
|
||||
- Emphasize document is ready for downstream work
|
||||
|
||||
### 2. Workflow Status Update
|
||||
|
||||
Update the main workflow status file if there is one:
|
||||
|
||||
- Check workflow configuration for a status file (if one exists)
|
||||
- Update workflow_status["prd"] = "{outputFile}"
|
||||
- Save file, preserving all comments and structure
|
||||
- Mark current timestamp as completion time
|
||||
|
||||
### 3. Validation Workflow Options
|
||||
|
||||
Offer validation workflows to ensure PRD is ready for implementation:
|
||||
|
||||
**Available Validation Workflows:**
|
||||
|
||||
**Option 1: Check Implementation Readiness** (`skill:bmad-check-implementation-readiness`)
|
||||
- Validates PRD has all information needed for development
|
||||
- Checks epic coverage completeness
|
||||
- Reviews UX alignment with requirements
|
||||
- Assesses epic quality and readiness
|
||||
- Identifies gaps before architecture/design work begins
|
||||
|
||||
**When to use:** Before starting technical architecture or epic breakdown
|
||||
|
||||
**Option 2: Skip for Now**
|
||||
- Proceed directly to next workflows (architecture, UX, epics)
|
||||
- Validation can be done later if needed
|
||||
- Some teams prefer to validate during architecture reviews
|
||||
|
||||
### 4. Suggest Next Workflows
|
||||
|
||||
PRD complete. Invoke the `bmad-help` skill.
|
||||
|
||||
### 5. Final Completion Confirmation
|
||||
|
||||
- Confirm completion with user and summarize what has been accomplished
|
||||
- Document now contains: Executive Summary, Success Criteria, User Journeys, Domain Requirements (if applicable), Innovation Analysis (if applicable), Project-Type Requirements, Functional Requirements (capability contract), Non-Functional Requirements, and has been polished for flow and coherence
|
||||
- Ask if they'd like to run validation workflow or proceed to next workflows
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ PRD document contains all required sections and has been polished
|
||||
✅ All collaborative content properly saved and optimized
|
||||
✅ Workflow status file updated with completion information (if exists)
|
||||
✅ Validation workflow options clearly presented
|
||||
✅ Clear next step guidance provided to user
|
||||
✅ Document quality validation completed
|
||||
✅ User acknowledges completion and understands next options
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Not updating workflow status file with completion information (if exists)
|
||||
❌ Not offering validation workflow options
|
||||
❌ Missing clear next step guidance for user
|
||||
❌ Not confirming document completeness with user
|
||||
❌ Workflow not properly marked as complete in status tracking (if applicable)
|
||||
❌ User unclear about what happens next or what validation options exist
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## FINAL REMINDER to give the user:
|
||||
|
||||
The polished PRD serves as the foundation for all subsequent product development activities. All design, architecture, and development work should trace back to the requirements and vision documented in this PRD - update it also as needed as you continue planning.
|
||||
|
||||
**Congratulations on completing the Product Requirements Document for {{project_name}}!** 🎉
|
||||
|
||||
## On Complete
|
||||
|
||||
Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete`
|
||||
|
||||
If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.
|
||||
@@ -1,10 +0,0 @@
|
||||
---
|
||||
stepsCompleted: []
|
||||
inputDocuments: []
|
||||
workflowType: 'prd'
|
||||
---
|
||||
|
||||
# Product Requirements Document - {{project_name}}
|
||||
|
||||
**Author:** {{user_name}}
|
||||
**Date:** {{date}}
|
||||
@@ -16,6 +16,9 @@ description: 'Creates a dedicated story file with all the context the agent will
|
||||
- SAVE QUESTIONS: If you think of questions or clarifications during analysis, save them for the end after the complete story is written
|
||||
- ZERO USER INTERVENTION: Process should be fully automated except for initial epic/story selection or missing documents
|
||||
|
||||
Subagents, when the capability is available, are an important part of this workflow. Use them as directed by the workflow steps.
|
||||
If you need an explicit user instruction to run them, ask once now for the whole workflow run.
|
||||
|
||||
## Conventions
|
||||
|
||||
- Bare paths (e.g. `discover-inputs.md`) resolve from the skill root.
|
||||
@@ -63,7 +66,7 @@ Greet `{user_name}`, speaking in `{communication_language}`.
|
||||
|
||||
Execute each entry in `{workflow.activation_steps_append}` in order.
|
||||
|
||||
Activation is complete. Begin the workflow below.
|
||||
Activation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.
|
||||
|
||||
## Paths
|
||||
|
||||
|
||||
@@ -1,75 +0,0 @@
|
||||
---
|
||||
name: bmad-create-ux-design
|
||||
description: 'Plan UX patterns and design specifications. Use when the user says "lets create UX design" or "create UX specifications" or "help me plan the UX"'
|
||||
---
|
||||
|
||||
# Create UX Design Workflow
|
||||
|
||||
**Goal:** Create comprehensive UX design specifications through collaborative visual exploration and informed decision-making where you act as a UX facilitator working with a product stakeholder.
|
||||
|
||||
## Conventions
|
||||
|
||||
- Bare paths (e.g. `steps/step-01-init.md`) resolve from the skill root.
|
||||
- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
|
||||
- `{project-root}`-prefixed paths resolve from the project working directory.
|
||||
- `{skill-name}` resolves to the skill directory's basename.
|
||||
|
||||
## WORKFLOW ARCHITECTURE
|
||||
|
||||
This uses **micro-file architecture** for disciplined execution:
|
||||
|
||||
- Each step is a self-contained file with embedded rules
|
||||
- Sequential progression with user control at each step
|
||||
- Document state tracked in frontmatter
|
||||
- Append-only document building through conversation
|
||||
|
||||
## On Activation
|
||||
|
||||
### Step 1: Resolve the Workflow Block
|
||||
|
||||
Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
|
||||
|
||||
**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
|
||||
|
||||
1. `{skill-root}/customize.toml` — defaults
|
||||
2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
|
||||
3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
|
||||
|
||||
Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
|
||||
|
||||
### Step 2: Execute Prepend Steps
|
||||
|
||||
Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
|
||||
|
||||
### Step 3: Load Persistent Facts
|
||||
|
||||
Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
|
||||
|
||||
### Step 4: Load Config
|
||||
|
||||
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||
- Use `{user_name}` for greeting
|
||||
- Use `{communication_language}` for all communications
|
||||
- Use `{document_output_language}` for output documents
|
||||
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||
- Use `{project_knowledge}` for additional context scanning
|
||||
|
||||
### Step 5: Greet the User
|
||||
|
||||
Greet `{user_name}`, speaking in `{communication_language}`.
|
||||
|
||||
### Step 6: Execute Append Steps
|
||||
|
||||
Execute each entry in `{workflow.activation_steps_append}` in order.
|
||||
|
||||
Activation is complete. Begin the workflow below.
|
||||
|
||||
## Paths
|
||||
|
||||
- `default_output_file` = `{planning_artifacts}/ux-design-specification.md`
|
||||
|
||||
## EXECUTION
|
||||
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
||||
- Read fully and follow: `./steps/step-01-init.md` to begin the UX design workflow.
|
||||
@@ -1,41 +0,0 @@
|
||||
# DO NOT EDIT -- overwritten on every update.
|
||||
#
|
||||
# Workflow customization surface for bmad-create-ux-design. Mirrors the
|
||||
# agent customization shape under the [workflow] namespace.
|
||||
|
||||
[workflow]
|
||||
|
||||
# --- Configurable below. Overrides merge per BMad structural rules: ---
|
||||
# scalars: override wins • arrays (persistent_facts, activation_steps_*): append
|
||||
# arrays-of-tables with `code`/`id`: replace matching items, append new ones.
|
||||
|
||||
# Steps to run before the standard activation (config load, greet).
|
||||
# Overrides append. Use for pre-flight loads, compliance checks, etc.
|
||||
|
||||
activation_steps_prepend = []
|
||||
|
||||
# Steps to run after greet but before the workflow begins.
|
||||
# Overrides append. Use for context-heavy setup that should happen
|
||||
# once the user has been acknowledged.
|
||||
|
||||
activation_steps_append = []
|
||||
|
||||
# Persistent facts the workflow keeps in mind for the whole run
|
||||
# (standards, compliance constraints, stylistic guardrails).
|
||||
# Distinct from the runtime memory sidecar — these are static context
|
||||
# loaded on activation. Overrides append.
|
||||
#
|
||||
# Each entry is either:
|
||||
# - a literal sentence, e.g. "All designs must meet WCAG 2.1 AA accessibility standards."
|
||||
# - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
|
||||
# (glob patterns are supported; the file's contents are loaded and treated as facts).
|
||||
|
||||
persistent_facts = [
|
||||
"file:{project-root}/**/project-context.md",
|
||||
]
|
||||
|
||||
# Scalar: executed when the workflow reaches Step 14 (Workflow Completion),
|
||||
# after the UX design specification is finalized and status is updated. Override wins.
|
||||
# Leave empty for no custom post-completion behavior.
|
||||
|
||||
on_complete = ""
|
||||
@@ -1,135 +0,0 @@
|
||||
# Step 1: UX Design Workflow Initialization
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ ALWAYS treat this as collaborative discovery between UX facilitator and stakeholder
|
||||
- 📋 YOU ARE A UX FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on initialization and setup only - don't look ahead to future steps
|
||||
- 🚪 DETECT existing workflow state and handle continuation properly
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- 💾 Initialize document and update frontmatter
|
||||
- 📖 Set up frontmatter `stepsCompleted: [1]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until setup is complete
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Variables from workflow.md are available in memory
|
||||
- Previous context = what's in output document + frontmatter
|
||||
- Don't assume knowledge from other steps
|
||||
- Input document discovery happens in this step
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Initialize the UX design workflow by detecting continuation state and setting up the design specification document.
|
||||
|
||||
## INITIALIZATION SEQUENCE:
|
||||
|
||||
### 1. Check for Existing Workflow
|
||||
|
||||
First, check if the output document already exists:
|
||||
|
||||
- Look for file at `{planning_artifacts}/*ux-design-specification*.md`
|
||||
- If exists, read the complete file including frontmatter
|
||||
- If not exists, this is a fresh workflow
|
||||
|
||||
### 2. Handle Continuation (If Document Exists)
|
||||
|
||||
If the document exists and has frontmatter with `stepsCompleted`:
|
||||
|
||||
- **STOP here** and load `./step-01b-continue.md` immediately
|
||||
- Do not proceed with any initialization tasks
|
||||
- Let step-01b handle the continuation logic
|
||||
|
||||
### 3. Fresh Workflow Setup (If No Document)
|
||||
|
||||
If no document exists or no `stepsCompleted` in frontmatter:
|
||||
|
||||
#### A. Input Document Discovery
|
||||
|
||||
Discover and load context documents using smart discovery. Documents can be in the following locations:
|
||||
- {planning_artifacts}/**
|
||||
- {output_folder}/**
|
||||
- {product_knowledge}/**
|
||||
- {project-root}/docs/**
|
||||
|
||||
Also - when searching - documents can be a single markdown file, or a folder with an index and multiple files. For Example, if searching for `*foo*.md` and not found, also search for a folder called *foo*/index.md (which indicates sharded content)
|
||||
|
||||
Try to discover the following:
|
||||
- Product Brief (`*brief*.md`)
|
||||
- Research Documents (`*prd*.md`)
|
||||
- Project Documentation (generally multiple documents might be found for this in the `{product_knowledge}` or `docs` folder.)
|
||||
- Project Context (`**/project-context.md`)
|
||||
|
||||
<critical>Confirm what you have found with the user, along with asking if the user wants to provide anything else. Only after this confirmation will you proceed to follow the loading rules</critical>
|
||||
|
||||
**Loading Rules:**
|
||||
|
||||
- Load ALL discovered files completely that the user confirmed or provided (no offset/limit)
|
||||
- If there is a project context, whatever is relevant should try to be biased in the remainder of this whole workflow process
|
||||
- For sharded folders, load ALL files to get complete picture, using the index first to potentially know the potential of each document
|
||||
- index.md is a guide to what's relevant whenever available
|
||||
- Track all successfully loaded files in frontmatter `inputDocuments` array
|
||||
|
||||
#### B. Create Initial Document
|
||||
|
||||
Copy the template from `../ux-design-template.md` to `{planning_artifacts}/ux-design-specification.md`
|
||||
Initialize frontmatter in the template.
|
||||
|
||||
#### C. Complete Initialization and Report
|
||||
|
||||
Complete setup and report to user:
|
||||
|
||||
**Document Setup:**
|
||||
|
||||
- Created: `{planning_artifacts}/ux-design-specification.md` from template
|
||||
- Initialized frontmatter with workflow state
|
||||
|
||||
**Input Documents Discovered:**
|
||||
Report what was found:
|
||||
"Welcome {{user_name}}! I've set up your UX design workspace for {{project_name}}.
|
||||
|
||||
**Documents Found:**
|
||||
|
||||
- PRD: {number of PRD files loaded or "None found"}
|
||||
- Product brief: {number of brief files loaded or "None found"}
|
||||
- Other context: {number of other files loaded or "None found"}
|
||||
|
||||
**Files loaded:** {list of specific file names or "No additional documents found"}
|
||||
|
||||
Do you have any other documents you'd like me to include, or shall we continue to the next step?
|
||||
|
||||
[C] Continue to UX discovery"
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects [C] to continue, ensure the file `{planning_artifacts}/ux-design-specification.md` has been created and saved, and then load `./step-02-discovery.md` to begin the UX discovery phase.
|
||||
|
||||
Remember: Do NOT proceed to step-02 until output file has been updated and user explicitly selects [C] to continue!
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Existing workflow detected and handed off to step-01b correctly
|
||||
✅ Fresh workflow initialized with template and frontmatter
|
||||
✅ Input documents discovered and loaded using sharded-first logic
|
||||
✅ All discovered files tracked in frontmatter `inputDocuments`
|
||||
✅ User confirmed document setup and can proceed
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Proceeding with fresh initialization when existing workflow exists
|
||||
❌ Not updating frontmatter with discovered input documents
|
||||
❌ Creating document without proper template
|
||||
❌ Not checking sharded folders first before whole files
|
||||
❌ Not reporting what documents were found to user
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
@@ -1,127 +0,0 @@
|
||||
# Step 1B: UX Design Workflow Continuation
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ ALWAYS treat this as collaborative discovery between UX facilitator and stakeholder
|
||||
- 📋 YOU ARE A UX FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on understanding where we left off and continuing appropriately
|
||||
- 🚪 RESUME workflow from exact point where it was interrupted
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis of current state before taking action
|
||||
- 💾 Keep existing frontmatter `stepsCompleted` values
|
||||
- 📖 Only load documents that were already tracked in `inputDocuments`
|
||||
- 🚫 FORBIDDEN to modify content completed in previous steps
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter are already loaded
|
||||
- Previous context = complete document + existing frontmatter
|
||||
- Input documents listed in frontmatter were already processed
|
||||
- Last completed step = `lastStep` value from frontmatter
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Resume the UX design workflow from where it was left off, ensuring smooth continuation.
|
||||
|
||||
## CONTINUATION SEQUENCE:
|
||||
|
||||
### 1. Analyze Current State
|
||||
|
||||
Review the frontmatter to understand:
|
||||
|
||||
- `stepsCompleted`: Which steps are already done
|
||||
- `lastStep`: The most recently completed step number
|
||||
- `inputDocuments`: What context was already loaded
|
||||
- All other frontmatter variables
|
||||
|
||||
### 2. Load All Input Documents
|
||||
|
||||
Reload the context documents listed in `inputDocuments`:
|
||||
|
||||
- For each document in `inputDocuments`, load the complete file
|
||||
- This ensures you have full context for continuation
|
||||
- Don't discover new documents - only reload what was previously processed
|
||||
|
||||
### 3. Summarize Current Progress
|
||||
|
||||
Welcome the user back and provide context:
|
||||
"Welcome back {{user_name}}! I'm resuming our UX design collaboration for {{project_name}}.
|
||||
|
||||
**Current Progress:**
|
||||
|
||||
- Steps completed: {stepsCompleted}
|
||||
- Last worked on: Step {lastStep}
|
||||
- Context documents available: {len(inputDocuments)} files
|
||||
- Current UX design specification is ready with all completed sections
|
||||
|
||||
**Document Status:**
|
||||
|
||||
- Current UX design document is ready with all completed sections
|
||||
- Ready to continue from where we left off
|
||||
|
||||
Does this look right, or do you want to make any adjustments before we proceed?"
|
||||
|
||||
### 4. Determine Next Step
|
||||
|
||||
Based on `lastStep` value, determine which step to load next:
|
||||
|
||||
- If `lastStep = 1` → Load `./step-02-discovery.md`
|
||||
- If `lastStep = 2` → Load `./step-03-core-experience.md`
|
||||
- If `lastStep = 3` → Load `./step-04-emotional-response.md`
|
||||
- Continue this pattern for all steps
|
||||
- If `lastStep` indicates final step → Workflow already complete
|
||||
|
||||
### 5. Present Continuation Options
|
||||
|
||||
After presenting current progress, ask:
|
||||
"Ready to continue with Step {nextStepNumber}: {nextStepTitle}?
|
||||
|
||||
[C] Continue to Step {nextStepNumber}"
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ All previous input documents successfully reloaded
|
||||
✅ Current workflow state accurately analyzed and presented
|
||||
✅ User confirms understanding of progress
|
||||
✅ Correct next step identified and prepared for loading
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Discovering new input documents instead of reloading existing ones
|
||||
❌ Modifying content from already completed steps
|
||||
❌ Loading wrong next step based on `lastStep` value
|
||||
❌ Proceeding without user confirmation of current state
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## WORKFLOW ALREADY COMPLETE?
|
||||
|
||||
If `lastStep` indicates the final step is completed:
|
||||
"Great news! It looks like we've already completed the UX design workflow for {{project_name}}.
|
||||
|
||||
The final UX design specification is ready at {planning_artifacts}/ux-design-specification.md with all sections completed through step {finalStepNumber}.
|
||||
|
||||
The complete UX design includes visual foundations, user flows, and design specifications ready for implementation.
|
||||
|
||||
Would you like me to:
|
||||
|
||||
- Review the completed UX design specification with you
|
||||
- Suggest next workflow steps (like wireframe generation or architecture)
|
||||
- Start a new UX design revision
|
||||
|
||||
What would be most helpful?"
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user confirms they're ready to continue, load the appropriate next step file based on the `lastStep` value from frontmatter.
|
||||
|
||||
Remember: Do NOT load the next step until user explicitly selects [C] to continue!
|
||||
@@ -1,190 +0,0 @@
|
||||
# Step 2: Project Understanding
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ ALWAYS treat this as collaborative discovery between UX facilitator and stakeholder
|
||||
- 📋 YOU ARE A UX FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on understanding project context and user needs
|
||||
- 🎯 COLLABORATIVE discovery, not assumption-based design
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ⚠️ Present A/P/C menu after generating project understanding content
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update output file frontmatter, adding this step to the end of the list of stepsCompleted.
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## COLLABORATION MENUS (A/P/C):
|
||||
|
||||
This step will generate content and present choices:
|
||||
|
||||
- **A (Advanced Elicitation)**: Use discovery protocols to develop deeper project insights
|
||||
- **P (Party Mode)**: Bring multiple perspectives to understand project context
|
||||
- **C (Continue)**: Save the content to the document and proceed to next step
|
||||
|
||||
## PROTOCOL INTEGRATION:
|
||||
|
||||
- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
|
||||
- When 'P' selected: Invoke the `bmad-party-mode` skill
|
||||
- PROTOCOLS always return to this step's A/P/C menu
|
||||
- User accepts/rejects protocol changes before proceeding
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from step 1 are available
|
||||
- Input documents (PRD, briefs, epics) already loaded are in memory
|
||||
- No additional data files needed for this step
|
||||
- Focus on project and user understanding
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Understand the project context, target users, and what makes this product special from a UX perspective.
|
||||
|
||||
## PROJECT DISCOVERY SEQUENCE:
|
||||
|
||||
### 1. Review Loaded Context
|
||||
|
||||
Start by analyzing what we know from the loaded documents:
|
||||
"Based on the project documentation we have loaded, let me confirm what I'm understanding about {{project_name}}.
|
||||
|
||||
**From the documents:**
|
||||
{summary of key insights from loaded PRD, briefs, and other context documents}
|
||||
|
||||
**Target Users:**
|
||||
{summary of user information from loaded documents}
|
||||
|
||||
**Key Features/Goals:**
|
||||
{summary of main features and goals from loaded documents}
|
||||
|
||||
Does this match your understanding? Are there any corrections or additions you'd like to make?"
|
||||
|
||||
### 2. Fill Context Gaps (If no documents or gaps exist)
|
||||
|
||||
If no documents were loaded or key information is missing:
|
||||
"Since we don't have complete documentation, let's start with the essentials:
|
||||
|
||||
**What are you building?** (Describe your product in 1-2 sentences)
|
||||
|
||||
**Who is this for?** (Describe your ideal user or target audience)
|
||||
|
||||
**What makes this special or different?** (What's the unique value proposition?)
|
||||
|
||||
**What's the main thing users will do with this?** (Core user action or goal)"
|
||||
|
||||
### 3. Explore User Context Deeper
|
||||
|
||||
Dive into user understanding:
|
||||
"Let me understand your users better to inform the UX design:
|
||||
|
||||
**User Context Questions:**
|
||||
|
||||
- What problem are users trying to solve?
|
||||
- What frustrates them with current solutions?
|
||||
- What would make them say 'this is exactly what I needed'?
|
||||
- How tech-savvy are your target users?
|
||||
- What devices will they use most?
|
||||
- When/where will they use this product?"
|
||||
|
||||
### 4. Identify UX Design Challenges
|
||||
|
||||
Surface the key UX challenges to address:
|
||||
"From what we've discussed, I'm seeing some key UX design considerations:
|
||||
|
||||
**Design Challenges:**
|
||||
|
||||
- [Identify 2-3 key UX challenges based on project type and user needs]
|
||||
- [Note any platform-specific considerations]
|
||||
- [Highlight any complex user flows or interactions]
|
||||
|
||||
**Design Opportunities:**
|
||||
|
||||
- [Identify 2-3 areas where great UX could create competitive advantage]
|
||||
- [Note any opportunities for innovative UX patterns]
|
||||
|
||||
Does this capture the key UX considerations we need to address?"
|
||||
|
||||
### 5. Generate Project Understanding Content
|
||||
|
||||
Prepare the content to append to the document:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
When saving to document, append these Level 2 and Level 3 sections:
|
||||
|
||||
```markdown
|
||||
## Executive Summary
|
||||
|
||||
### Project Vision
|
||||
|
||||
[Project vision summary based on conversation]
|
||||
|
||||
### Target Users
|
||||
|
||||
[Target user descriptions based on conversation]
|
||||
|
||||
### Key Design Challenges
|
||||
|
||||
[Key UX challenges identified based on conversation]
|
||||
|
||||
### Design Opportunities
|
||||
|
||||
[Design opportunities identified based on conversation]
|
||||
```
|
||||
|
||||
### 6. Present Content and Menu
|
||||
|
||||
Show the generated project understanding content and present choices:
|
||||
"I've documented our understanding of {{project_name}} from a UX perspective. This will guide all our design decisions moving forward.
|
||||
|
||||
**Here's what I'll add to the document:**
|
||||
|
||||
[Show the complete markdown content from step 5]
|
||||
|
||||
**What would you like to do?**
|
||||
[C] Continue - Save this to the document and move to core experience definition"
|
||||
|
||||
### 7. Handle Menu Selection
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to `{planning_artifacts}/ux-design-specification.md`
|
||||
- Update frontmatter: `stepsCompleted: [1, 2]`
|
||||
- Load `./step-03-core-experience.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document. Only after the content is saved to document, read fully and follow: `./step-03-core-experience.md`.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ All available context documents reviewed and synthesized
|
||||
✅ Project vision clearly articulated
|
||||
✅ Target users well understood
|
||||
✅ Key UX challenges identified
|
||||
✅ Design opportunities surfaced
|
||||
✅ A/P/C menu presented and handled correctly
|
||||
✅ Content properly appended to document when C selected
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Not reviewing loaded context documents thoroughly
|
||||
❌ Making assumptions about users without asking
|
||||
❌ Missing key UX challenges that will impact design
|
||||
❌ Not identifying design opportunities
|
||||
❌ Generating generic content without real project insight
|
||||
❌ Not presenting A/P/C menu after content generation
|
||||
❌ Appending content without user selecting 'C'
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
Remember: Do NOT proceed to step-03 until user explicitly selects 'C' from the menu and content is saved!
|
||||
@@ -1,217 +0,0 @@
|
||||
# Step 3: Core Experience Definition
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ ALWAYS treat this as collaborative discovery between UX facilitator and stakeholder
|
||||
- 📋 YOU ARE A UX FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on defining the core user experience and platform
|
||||
- 🎯 COLLABORATIVE discovery, not assumption-based design
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ⚠️ Present A/P/C menu after generating core experience content
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update output file frontmatter, adding this step to the end of the list of stepsCompleted.
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## COLLABORATION MENUS (A/P/C):
|
||||
|
||||
This step will generate content and present choices:
|
||||
|
||||
- **A (Advanced Elicitation)**: Use discovery protocols to develop deeper experience insights
|
||||
- **P (Party Mode)**: Bring multiple perspectives to define optimal user experience
|
||||
- **C (Continue)**: Save the content to the document and proceed to next step
|
||||
|
||||
## PROTOCOL INTEGRATION:
|
||||
|
||||
- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
|
||||
- When 'P' selected: Invoke the `bmad-party-mode` skill
|
||||
- PROTOCOLS always return to this step's A/P/C menu
|
||||
- User accepts/rejects protocol changes before proceeding
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from previous steps are available
|
||||
- Project understanding from step 2 informs this step
|
||||
- No additional data files needed for this step
|
||||
- Focus on core experience and platform decisions
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Define the core user experience, platform requirements, and what makes the interaction effortless.
|
||||
|
||||
## CORE EXPERIENCE DISCOVERY SEQUENCE:
|
||||
|
||||
### 1. Define Core User Action
|
||||
|
||||
Start by identifying the most important user interaction:
|
||||
"Now let's dig into the heart of the user experience for {{project_name}}.
|
||||
|
||||
**Core Experience Questions:**
|
||||
|
||||
- What's the ONE thing users will do most frequently?
|
||||
- What user action is absolutely critical to get right?
|
||||
- What should be completely effortless for users?
|
||||
- If we nail one interaction, everything else follows - what is it?
|
||||
|
||||
Think about the core loop or primary action that defines your product's value."
|
||||
|
||||
### 2. Explore Platform Requirements
|
||||
|
||||
Determine where and how users will interact:
|
||||
"Let's define the platform context for {{project_name}}:
|
||||
|
||||
**Platform Questions:**
|
||||
|
||||
- Web, mobile app, desktop, or multiple platforms?
|
||||
- Will this be primarily touch-based or mouse/keyboard?
|
||||
- Any specific platform requirements or constraints?
|
||||
- Do we need to consider offline functionality?
|
||||
- Any device-specific capabilities we should leverage?"
|
||||
|
||||
### 3. Identify Effortless Interactions
|
||||
|
||||
Surface what should feel magical or completely seamless:
|
||||
"**Effortless Experience Design:**
|
||||
|
||||
- What user actions should feel completely natural and require zero thought?
|
||||
- Where do users currently struggle with similar products?
|
||||
- What interaction, if made effortless, would create delight?
|
||||
- What should happen automatically without user intervention?
|
||||
- Where can we eliminate steps that competitors require?"
|
||||
|
||||
### 4. Define Critical Success Moments
|
||||
|
||||
Identify the moments that determine success or failure:
|
||||
"**Critical Success Moments:**
|
||||
|
||||
- What's the moment where users realize 'this is better'?
|
||||
- When does the user feel successful or accomplished?
|
||||
- What interaction, if failed, would ruin the experience?
|
||||
- What are the make-or-break user flows?
|
||||
- Where does first-time user success happen?"
|
||||
|
||||
### 5. Synthesize Experience Principles
|
||||
|
||||
Extract guiding principles from the conversation:
|
||||
"Based on our discussion, I'm hearing these core experience principles for {{project_name}}:
|
||||
|
||||
**Experience Principles:**
|
||||
|
||||
- [Principle 1 based on core action focus]
|
||||
- [Principle 2 based on effortless interactions]
|
||||
- [Principle 3 based on platform considerations]
|
||||
- [Principle 4 based on critical success moments]
|
||||
|
||||
These principles will guide all our UX decisions. Do these capture what's most important?"
|
||||
|
||||
### 6. Generate Core Experience Content
|
||||
|
||||
Prepare the content to append to the document:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
When saving to document, append these Level 2 and Level 3 sections:
|
||||
|
||||
```markdown
|
||||
## Core User Experience
|
||||
|
||||
### Defining Experience
|
||||
|
||||
[Core experience definition based on conversation]
|
||||
|
||||
### Platform Strategy
|
||||
|
||||
[Platform requirements and decisions based on conversation]
|
||||
|
||||
### Effortless Interactions
|
||||
|
||||
[Effortless interaction areas identified based on conversation]
|
||||
|
||||
### Critical Success Moments
|
||||
|
||||
[Critical success moments defined based on conversation]
|
||||
|
||||
### Experience Principles
|
||||
|
||||
[Guiding principles for UX decisions based on conversation]
|
||||
```
|
||||
|
||||
### 7. Present Content and Menu
|
||||
|
||||
Show the generated core experience content and present choices:
|
||||
"I've defined the core user experience for {{project_name}} based on our conversation. This establishes the foundation for all our UX design decisions.
|
||||
|
||||
**Here's what I'll add to the document:**
|
||||
|
||||
[Show the complete markdown content from step 6]
|
||||
|
||||
**What would you like to do?**
|
||||
[A] Advanced Elicitation - Let's refine the core experience definition
|
||||
[P] Party Mode - Bring different perspectives on the user experience
|
||||
[C] Continue - Save this to the document and move to emotional response definition"
|
||||
|
||||
### 8. Handle Menu Selection
|
||||
|
||||
#### If 'A' (Advanced Elicitation):
|
||||
|
||||
- Invoke the `bmad-advanced-elicitation` skill with the current core experience content
|
||||
- Process the enhanced experience insights that come back
|
||||
- Ask user: "Accept these improvements to the core experience definition? (y/n)"
|
||||
- If yes: Update content with improvements, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'P' (Party Mode):
|
||||
|
||||
- Invoke the `bmad-party-mode` skill with the current core experience definition
|
||||
- Process the collaborative experience improvements that come back
|
||||
- Ask user: "Accept these changes to the core experience definition? (y/n)"
|
||||
- If yes: Update content with improvements, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to `{planning_artifacts}/ux-design-specification.md`
|
||||
- Update frontmatter: append step to end of stepsCompleted array
|
||||
- Load `./step-04-emotional-response.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from step 6.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Core user action clearly identified and defined
|
||||
✅ Platform requirements thoroughly explored
|
||||
✅ Effortless interaction areas identified
|
||||
✅ Critical success moments mapped out
|
||||
✅ Experience principles established as guiding framework
|
||||
✅ A/P/C menu presented and handled correctly
|
||||
✅ Content properly appended to document when C selected
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Missing the core user action that defines the product
|
||||
❌ Not properly considering platform requirements
|
||||
❌ Overlooking what should be effortless for users
|
||||
❌ Not identifying critical make-or-break interactions
|
||||
❌ Experience principles too generic or not actionable
|
||||
❌ Not presenting A/P/C menu after content generation
|
||||
❌ Appending content without user selecting 'C'
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved to document, load `./step-04-emotional-response.md` to define desired emotional responses.
|
||||
|
||||
Remember: Do NOT proceed to step-04 until user explicitly selects 'C' from the A/P/C menu and content is saved!
|
||||
@@ -1,220 +0,0 @@
|
||||
# Step 4: Desired Emotional Response
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ ALWAYS treat this as collaborative discovery between UX facilitator and stakeholder
|
||||
- 📋 YOU ARE A UX FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on defining desired emotional responses and user feelings
|
||||
- 🎯 COLLABORATIVE discovery, not assumption-based design
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ⚠️ Present A/P/C menu after generating emotional response content
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update output file frontmatter, adding this step to the end of the list of stepsCompleted.
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## COLLABORATION MENUS (A/P/C):
|
||||
|
||||
This step will generate content and present choices:
|
||||
|
||||
- **A (Advanced Elicitation)**: Use discovery protocols to develop deeper emotional insights
|
||||
- **P (Party Mode)**: Bring multiple perspectives to define optimal emotional responses
|
||||
- **C (Continue)**: Save the content to the document and proceed to next step
|
||||
|
||||
## PROTOCOL INTEGRATION:
|
||||
|
||||
- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
|
||||
- When 'P' selected: Invoke the `bmad-party-mode` skill
|
||||
- PROTOCOLS always return to this step's A/P/C menu
|
||||
- User accepts/rejects protocol changes before proceeding
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from previous steps are available
|
||||
- Core experience definition from step 3 informs emotional response
|
||||
- No additional data files needed for this step
|
||||
- Focus on user feelings and emotional design goals
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Define the desired emotional responses users should feel when using the product.
|
||||
|
||||
## EMOTIONAL RESPONSE DISCOVERY SEQUENCE:
|
||||
|
||||
### 1. Explore Core Emotional Goals
|
||||
|
||||
Start by understanding the emotional objectives:
|
||||
"Now let's think about how {{project_name}} should make users feel.
|
||||
|
||||
**Emotional Response Questions:**
|
||||
|
||||
- What should users FEEL when using this product?
|
||||
- What emotion would make them tell a friend about this?
|
||||
- How should users feel after accomplishing their primary goal?
|
||||
- What feeling differentiates this from competitors?
|
||||
|
||||
Common emotional goals: Empowered and in control? Delighted and surprised? Efficient and productive? Creative and inspired? Calm and focused? Connected and engaged?"
|
||||
|
||||
### 2. Identify Emotional Journey Mapping
|
||||
|
||||
Explore feelings at different stages:
|
||||
"**Emotional Journey Considerations:**
|
||||
|
||||
- How should users feel when they first discover the product?
|
||||
- What emotion during the core experience/action?
|
||||
- How should they feel after completing their task?
|
||||
- What if something goes wrong - what emotional response do we want?
|
||||
- How should they feel when returning to use it again?"
|
||||
|
||||
### 3. Define Micro-Emotions
|
||||
|
||||
Surface subtle but important emotional states:
|
||||
"**Micro-Emotions to Consider:**
|
||||
|
||||
- Confidence vs. Confusion
|
||||
- Trust vs. Skepticism
|
||||
- Excitement vs. Anxiety
|
||||
- Accomplishment vs. Frustration
|
||||
- Delight vs. Satisfaction
|
||||
- Belonging vs. Isolation
|
||||
|
||||
Which of these emotional states are most critical for your product's success?"
|
||||
|
||||
### 4. Connect Emotions to UX Decisions
|
||||
|
||||
Link feelings to design implications:
|
||||
"**Design Implications:**
|
||||
|
||||
- If we want users to feel [emotional state], what UX choices support this?
|
||||
- What interactions might create negative emotions we want to avoid?
|
||||
- Where can we add moments of delight or surprise?
|
||||
- How do we build trust and confidence through design?
|
||||
|
||||
**Emotion-Design Connections:**
|
||||
|
||||
- [Emotion 1] → [UX design approach]
|
||||
- [Emotion 2] → [UX design approach]
|
||||
- [Emotion 3] → [UX design approach]"
|
||||
|
||||
### 5. Validate Emotional Goals
|
||||
|
||||
Check if emotional goals align with product vision:
|
||||
"Let me make sure I understand the emotional vision for {{project_name}}:
|
||||
|
||||
**Primary Emotional Goal:** [Summarize main emotional response]
|
||||
**Secondary Feelings:** [List supporting emotional states]
|
||||
**Emotions to Avoid:** [List negative emotions to prevent]
|
||||
|
||||
Does this capture the emotional experience you want to create? Any adjustments needed?"
|
||||
|
||||
### 6. Generate Emotional Response Content
|
||||
|
||||
Prepare the content to append to the document:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
When saving to document, append these Level 2 and Level 3 sections:
|
||||
|
||||
```markdown
|
||||
## Desired Emotional Response
|
||||
|
||||
### Primary Emotional Goals
|
||||
|
||||
[Primary emotional goals based on conversation]
|
||||
|
||||
### Emotional Journey Mapping
|
||||
|
||||
[Emotional journey mapping based on conversation]
|
||||
|
||||
### Micro-Emotions
|
||||
|
||||
[Micro-emotions identified based on conversation]
|
||||
|
||||
### Design Implications
|
||||
|
||||
[UX design implications for emotional responses based on conversation]
|
||||
|
||||
### Emotional Design Principles
|
||||
|
||||
[Guiding principles for emotional design based on conversation]
|
||||
```
|
||||
|
||||
### 7. Present Content and Menu
|
||||
|
||||
Show the generated emotional response content and present choices:
|
||||
"I've defined the desired emotional responses for {{project_name}}. These emotional goals will guide our design decisions to create the right user experience.
|
||||
|
||||
**Here's what I'll add to the document:**
|
||||
|
||||
[Show the complete markdown content from step 6]
|
||||
|
||||
**What would you like to do?**
|
||||
[A] Advanced Elicitation - Let's refine the emotional response definition
|
||||
[P] Party Mode - Bring different perspectives on user emotional needs
|
||||
[C] Continue - Save this to the document and move to inspiration analysis"
|
||||
|
||||
### 8. Handle Menu Selection
|
||||
|
||||
#### If 'A' (Advanced Elicitation):
|
||||
|
||||
- Invoke the `bmad-advanced-elicitation` skill with the current emotional response content
|
||||
- Process the enhanced emotional insights that come back
|
||||
- Ask user: "Accept these improvements to the emotional response definition? (y/n)"
|
||||
- If yes: Update content with improvements, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'P' (Party Mode):
|
||||
|
||||
- Invoke the `bmad-party-mode` skill with the current emotional response definition
|
||||
- Process the collaborative emotional insights that come back
|
||||
- Ask user: "Accept these changes to the emotional response definition? (y/n)"
|
||||
- If yes: Update content with improvements, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to `{planning_artifacts}/ux-design-specification.md`
|
||||
- Update frontmatter: append step to end of stepsCompleted array
|
||||
- Load `./step-05-inspiration.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from step 6.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Primary emotional goals clearly defined
|
||||
✅ Emotional journey mapped across user experience
|
||||
✅ Micro-emotions identified and addressed
|
||||
✅ Design implications connected to emotional responses
|
||||
✅ Emotional design principles established
|
||||
✅ A/P/C menu presented and handled correctly
|
||||
✅ Content properly appended to document when C selected
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Missing core emotional goals or being too generic
|
||||
❌ Not considering emotional journey across different stages
|
||||
❌ Overlooking micro-emotions that impact user satisfaction
|
||||
❌ Not connecting emotional goals to specific UX design choices
|
||||
❌ Emotional principles too vague or not actionable
|
||||
❌ Not presenting A/P/C menu after content generation
|
||||
❌ Appending content without user selecting 'C'
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved to document, load `./step-05-inspiration.md` to analyze UX patterns from inspiring products.
|
||||
|
||||
Remember: Do NOT proceed to step-05 until user explicitly selects 'C' from the A/P/C menu and content is saved!
|
||||
@@ -1,235 +0,0 @@
|
||||
# Step 5: UX Pattern Analysis & Inspiration
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ ALWAYS treat this as collaborative discovery between UX facilitator and stakeholder
|
||||
- 📋 YOU ARE A UX FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on analyzing existing UX patterns and extracting inspiration
|
||||
- 🎯 COLLABORATIVE discovery, not assumption-based design
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ⚠️ Present A/P/C menu after generating inspiration analysis content
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update output file frontmatter, adding this step to the end of the list of stepsCompleted.
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## COLLABORATION MENUS (A/P/C):
|
||||
|
||||
This step will generate content and present choices:
|
||||
|
||||
- **A (Advanced Elicitation)**: Use discovery protocols to develop deeper pattern insights
|
||||
- **P ( Party Mode)**: Bring multiple perspectives to analyze UX patterns
|
||||
- **C (Continue)**: Save the content to the document and proceed to next step
|
||||
|
||||
## PROTOCOL INTEGRATION:
|
||||
|
||||
- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
|
||||
- When 'P' selected: Invoke the `bmad-party-mode` skill
|
||||
- PROTOCOLS always return to this step's A/P/C menu
|
||||
- User accepts/rejects protocol changes before proceeding
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from previous steps are available
|
||||
- Emotional response goals from step 4 inform pattern analysis
|
||||
- No additional data files needed for this step
|
||||
- Focus on analyzing existing UX patterns and extracting lessons
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Analyze inspiring products and UX patterns to inform design decisions for the current project.
|
||||
|
||||
## INSPIRATION ANALYSIS SEQUENCE:
|
||||
|
||||
### 1. Identify User's Favorite Apps
|
||||
|
||||
Start by gathering inspiration sources:
|
||||
"Let's learn from products your users already love and use regularly.
|
||||
|
||||
**Inspiration Questions:**
|
||||
|
||||
- Name 2-3 apps your target users already love and USE frequently
|
||||
- For each one, what do they do well from a UX perspective?
|
||||
- What makes the experience compelling or delightful?
|
||||
- What keeps users coming back to these apps?
|
||||
|
||||
Think about apps in your category or even unrelated products that have great UX."
|
||||
|
||||
### 2. Analyze UX Patterns and Principles
|
||||
|
||||
Break down what makes these apps successful:
|
||||
"For each inspiring app, let's analyze their UX success:
|
||||
|
||||
**For [App Name]:**
|
||||
|
||||
- What core problem does it solve elegantly?
|
||||
- What makes the onboarding experience effective?
|
||||
- How do they handle navigation and information hierarchy?
|
||||
- What are their most innovative or delightful interactions?
|
||||
- What visual design choices support the user experience?
|
||||
- How do they handle errors or edge cases?"
|
||||
|
||||
### 3. Extract Transferable Patterns
|
||||
|
||||
Identify patterns that could apply to your project:
|
||||
"**Transferable UX Patterns:**
|
||||
Looking across these inspiring apps, I see patterns we could adapt:
|
||||
|
||||
**Navigation Patterns:**
|
||||
|
||||
- [Pattern 1] - could work for your [specific use case]
|
||||
- [Pattern 2] - might solve your [specific challenge]
|
||||
|
||||
**Interaction Patterns:**
|
||||
|
||||
- [Pattern 1] - excellent for [your user goal]
|
||||
- [Pattern 2] - addresses [your user pain point]
|
||||
|
||||
**Visual Patterns:**
|
||||
|
||||
- [Pattern 1] - supports your [emotional goal]
|
||||
- [Pattern 2] - aligns with your [platform requirements]
|
||||
|
||||
Which of these patterns resonate most for your product?"
|
||||
|
||||
### 4. Identify Anti-Patterns to Avoid
|
||||
|
||||
Surface what not to do based on analysis:
|
||||
"**UX Anti-Patterns to Avoid:**
|
||||
From analyzing both successes and failures in your space, here are patterns to avoid:
|
||||
|
||||
- [Anti-pattern 1] - users find this confusing/frustrating
|
||||
- [Anti-pattern 2] - this creates unnecessary friction
|
||||
- [Anti-pattern 3] - doesn't align with your [emotional goals]
|
||||
|
||||
Learning from others' mistakes is as important as learning from their successes."
|
||||
|
||||
### 5. Define Design Inspiration Strategy
|
||||
|
||||
Create a clear strategy for using this inspiration:
|
||||
"**Design Inspiration Strategy:**
|
||||
|
||||
**What to Adopt:**
|
||||
|
||||
- [Specific pattern] - because it supports [your core experience]
|
||||
- [Specific pattern] - because it aligns with [user needs]
|
||||
|
||||
**What to Adapt:**
|
||||
|
||||
- [Specific pattern] - modify for [your unique requirements]
|
||||
- [Specific pattern] - simplify for [your user skill level]
|
||||
|
||||
**What to Avoid:**
|
||||
|
||||
- [Specific anti-pattern] - conflicts with [your goals]
|
||||
- [Specific anti-pattern] - doesn't fit [your platform]
|
||||
|
||||
This strategy will guide our design decisions while keeping {{project_name}} unique."
|
||||
|
||||
### 6. Generate Inspiration Analysis Content
|
||||
|
||||
Prepare the content to append to the document:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
When saving to document, append these Level 2 and Level 3 sections:
|
||||
|
||||
```markdown
|
||||
## UX Pattern Analysis & Inspiration
|
||||
|
||||
### Inspiring Products Analysis
|
||||
|
||||
[Analysis of inspiring products based on conversation]
|
||||
|
||||
### Transferable UX Patterns
|
||||
|
||||
[Transferable patterns identified based on conversation]
|
||||
|
||||
### Anti-Patterns to Avoid
|
||||
|
||||
[Anti-patterns to avoid based on conversation]
|
||||
|
||||
### Design Inspiration Strategy
|
||||
|
||||
[Strategy for using inspiration based on conversation]
|
||||
```
|
||||
|
||||
### 7. Present Content and Menu
|
||||
|
||||
Show the generated inspiration analysis content and present choices:
|
||||
"I've analyzed inspiring UX patterns and products to inform our design strategy for {{project_name}}. This gives us a solid foundation of proven patterns to build upon.
|
||||
|
||||
**Here's what I'll add to the document:**
|
||||
|
||||
[Show the complete markdown content from step 6]
|
||||
|
||||
**What would you like to do?**
|
||||
[A] Advanced Elicitation - Let's deepen our UX pattern analysis
|
||||
[P] Party Mode - Bring different perspectives on inspiration sources
|
||||
[C] Continue - Save this to the document and move to design system choice"
|
||||
|
||||
### 8. Handle Menu Selection
|
||||
|
||||
#### If 'A' (Advanced Elicitation):
|
||||
|
||||
- Invoke the `bmad-advanced-elicitation` skill with the current inspiration analysis content
|
||||
- Process the enhanced pattern insights that come back
|
||||
- Ask user: "Accept these improvements to the inspiration analysis? (y/n)"
|
||||
- If yes: Update content with improvements, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'P' (Party Mode):
|
||||
|
||||
- Invoke the `bmad-party-mode` skill with the current inspiration analysis
|
||||
- Process the collaborative pattern insights that come back
|
||||
- Ask user: "Accept these changes to the inspiration analysis? (y/n)"
|
||||
- If yes: Update content with improvements, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to `{planning_artifacts}/ux-design-specification.md`
|
||||
- Update frontmatter: append step to end of stepsCompleted array
|
||||
- Read fully and follow: `./step-06-design-system.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from step 6.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Inspiring products identified and analyzed thoroughly
|
||||
✅ UX patterns extracted and categorized effectively
|
||||
✅ Transferable patterns identified for current project
|
||||
✅ Anti-patterns identified to avoid common mistakes
|
||||
✅ Clear design inspiration strategy established
|
||||
✅ A/P/C menu presented and handled correctly
|
||||
✅ Content properly appended to document when C selected
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Not getting specific examples of inspiring products
|
||||
❌ Surface-level analysis without deep pattern extraction
|
||||
❌ Missing opportunities for pattern adaptation
|
||||
❌ Not identifying relevant anti-patterns to avoid
|
||||
❌ Strategy too generic or not actionable
|
||||
❌ Not presenting A/P/C menu after content generation
|
||||
❌ Appending content without user selecting 'C'
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved to document, load `./step-06-design-system.md` to choose the appropriate design system approach.
|
||||
|
||||
Remember: Do NOT proceed to step-06 until user explicitly selects 'C' from the A/P/C menu and content is saved!
|
||||
@@ -1,253 +0,0 @@
|
||||
# Step 6: Design System Choice
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ ALWAYS treat this as collaborative discovery between UX facilitator and stakeholder
|
||||
- 📋 YOU ARE A UX FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on choosing appropriate design system approach
|
||||
- 🎯 COLLABORATIVE decision-making, not recommendation-only
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ⚠️ Present A/P/C menu after generating design system decision content
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update output file frontmatter, adding this step to the end of the list of stepsCompleted.
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## COLLABORATION MENUS (A/P/C):
|
||||
|
||||
This step will generate content and present choices:
|
||||
|
||||
- **A (Advanced Elicitation)**: Use discovery protocols to develop deeper design system insights
|
||||
- **P (Party Mode)**: Bring multiple perspectives to evaluate design system options
|
||||
- **C (Continue)**: Save the content to the document and proceed to next step
|
||||
|
||||
## PROTOCOL INTEGRATION:
|
||||
|
||||
- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
|
||||
- When 'P' selected: Invoke the `bmad-party-mode` skill
|
||||
- PROTOCOLS always return to this step's A/P/C menu
|
||||
- User accepts/rejects protocol changes before proceeding
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from previous steps are available
|
||||
- Platform requirements from step 3 inform design system choice
|
||||
- Inspiration patterns from step 5 guide design system selection
|
||||
- Focus on choosing foundation for consistent design
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Choose appropriate design system approach based on project requirements and constraints.
|
||||
|
||||
## DESIGN SYSTEM CHOICE SEQUENCE:
|
||||
|
||||
### 1. Present Design System Options
|
||||
|
||||
Educate about design system approaches:
|
||||
"For {{project_name}}, we need to choose a design system foundation. Think of design systems like LEGO blocks for UI - they provide proven components and patterns, ensuring consistency and speeding development.
|
||||
|
||||
**Design System Approaches:**
|
||||
|
||||
**1. Custom Design System**
|
||||
|
||||
- Complete visual uniqueness
|
||||
- Full control over every component
|
||||
- Higher initial investment
|
||||
- Perfect for established brands with unique needs
|
||||
|
||||
**2. Established System (Material Design, Ant Design, etc.)**
|
||||
|
||||
- Fast development with proven patterns
|
||||
- Great defaults and accessibility built-in
|
||||
- Less visual differentiation
|
||||
- Ideal for startups or internal tools
|
||||
|
||||
**3. Themeable System (MUI, Chakra UI, Tailwind UI)**
|
||||
|
||||
- Customizable with strong foundation
|
||||
- Brand flexibility with proven components
|
||||
- Moderate learning curve
|
||||
- Good balance of speed and uniqueness
|
||||
|
||||
Which direction feels right for your project?"
|
||||
|
||||
### 2. Analyze Project Requirements
|
||||
|
||||
Guide decision based on project context:
|
||||
"**Let's consider your specific needs:**
|
||||
|
||||
**Based on our previous conversations:**
|
||||
|
||||
- Platform: [platform from step 3]
|
||||
- Timeline: [inferred from user conversation]
|
||||
- Team Size: [inferred from user conversation]
|
||||
- Brand Requirements: [inferred from user conversation]
|
||||
- Technical Constraints: [inferred from user conversation]
|
||||
|
||||
**Decision Factors:**
|
||||
|
||||
- Need for speed vs. need for uniqueness
|
||||
- Brand guidelines or existing visual identity
|
||||
- Team's design expertise
|
||||
- Long-term maintenance considerations
|
||||
- Integration requirements with existing systems"
|
||||
|
||||
### 3. Explore Specific Design System Options
|
||||
|
||||
Dive deeper into relevant options:
|
||||
"**Recommended Options Based on Your Needs:**
|
||||
|
||||
**For [Your Platform Type]:**
|
||||
|
||||
- [Option 1] - [Key benefit] - [Best for scenario]
|
||||
- [Option 2] - [Key benefit] - [Best for scenario]
|
||||
- [Option 3] - [Key benefit] - [Best for scenario]
|
||||
|
||||
**Considerations:**
|
||||
|
||||
- Component library size and quality
|
||||
- Documentation and community support
|
||||
- Customization capabilities
|
||||
- Accessibility compliance
|
||||
- Performance characteristics
|
||||
- Learning curve for your team"
|
||||
|
||||
### 4. Facilitate Decision Process
|
||||
|
||||
Help user make informed choice:
|
||||
"**Decision Framework:**
|
||||
|
||||
1. What's most important: Speed, uniqueness, or balance?
|
||||
2. How much design expertise does your team have?
|
||||
3. Are there existing brand guidelines to follow?
|
||||
4. What's your timeline and budget?
|
||||
5. Long-term maintenance needs?
|
||||
|
||||
Let's evaluate options based on your answers to these questions."
|
||||
|
||||
### 5. Finalize Design System Choice
|
||||
|
||||
Confirm and document the decision:
|
||||
"Based on our analysis, I recommend [Design System Choice] for {{project_name}}.
|
||||
|
||||
**Rationale:**
|
||||
|
||||
- [Reason 1 based on project needs]
|
||||
- [Reason 2 based on constraints]
|
||||
- [Reason 3 based on team considerations]
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
- We'll customize this system to match your brand and needs
|
||||
- Define component strategy for custom components needed
|
||||
- Establish design tokens and patterns
|
||||
|
||||
Does this design system choice feel right to you?"
|
||||
|
||||
### 6. Generate Design System Content
|
||||
|
||||
Prepare the content to append to the document:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
When saving to document, append these Level 2 and Level 3 sections:
|
||||
|
||||
```markdown
|
||||
## Design System Foundation
|
||||
|
||||
### 1.1 Design System Choice
|
||||
|
||||
[Design system choice based on conversation]
|
||||
|
||||
### Rationale for Selection
|
||||
|
||||
[Rationale for design system selection based on conversation]
|
||||
|
||||
### Implementation Approach
|
||||
|
||||
[Implementation approach based on chosen system]
|
||||
|
||||
### Customization Strategy
|
||||
|
||||
[Customization strategy based on project needs]
|
||||
```
|
||||
|
||||
### 7. Present Content and Menu
|
||||
|
||||
Show the generated design system content and present choices:
|
||||
"I've documented our design system choice for {{project_name}}. This foundation will ensure consistency and speed up development.
|
||||
|
||||
**Here's what I'll add to the document:**
|
||||
|
||||
[Show the complete markdown content from step 6]
|
||||
|
||||
**What would you like to do?**
|
||||
[A] Advanced Elicitation - Let's refine our design system decision
|
||||
[P] Party Mode - Bring technical perspectives on design systems
|
||||
[C] Continue - Save this to the document and move to defining experience
|
||||
|
||||
### 8. Handle Menu Selection
|
||||
|
||||
#### If 'A' (Advanced Elicitation):
|
||||
|
||||
- Invoke the `bmad-advanced-elicitation` skill with the current design system content
|
||||
- Process the enhanced design system insights that come back
|
||||
- Ask user: "Accept these improvements to the design system decision? (y/n)"
|
||||
- If yes: Update content with improvements, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'P' (Party Mode):
|
||||
|
||||
- Invoke the `bmad-party-mode` skill with the current design system choice
|
||||
- Process the collaborative design system insights that come back
|
||||
- Ask user: "Accept these changes to the design system decision? (y/n)"
|
||||
- If yes: Update content with improvements, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to `{planning_artifacts}/ux-design-specification.md`
|
||||
- Update frontmatter: append step to end of stepsCompleted array
|
||||
- Load `./step-07-defining-experience.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from step 6.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Design system options clearly presented and explained
|
||||
✅ Decision framework applied to project requirements
|
||||
✅ Specific design system chosen with clear rationale
|
||||
✅ Implementation approach planned
|
||||
✅ Customization strategy defined
|
||||
✅ A/P/C menu presented and handled correctly
|
||||
✅ Content properly appended to document when C selected
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Not explaining design system concepts clearly
|
||||
❌ Rushing to recommendation without understanding requirements
|
||||
❌ Not considering technical constraints or team capabilities
|
||||
❌ Choosing design system without clear rationale
|
||||
❌ Not planning implementation approach
|
||||
❌ Not presenting A/P/C menu after content generation
|
||||
❌ Appending content without user selecting 'C'
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved to document, load `./step-07-defining-experience.md` to define the core user interaction.
|
||||
|
||||
Remember: Do NOT proceed to step-07 until user explicitly selects 'C' from the A/P/C menu and content is saved!
|
||||
@@ -1,255 +0,0 @@
|
||||
# Step 7: Defining Core Experience
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ ALWAYS treat this as collaborative discovery between UX facilitator and stakeholder
|
||||
- 📋 YOU ARE A UX FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on defining the core interaction that defines the product
|
||||
- 🎯 COLLABORATIVE discovery, not assumption-based design
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ⚠️ Present A/P/C menu after generating defining experience content
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update output file frontmatter, adding this step to the end of the list of stepsCompleted.
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## COLLABORATION MENUS (A/P/C):
|
||||
|
||||
This step will generate content and present choices:
|
||||
|
||||
- **A (Advanced Elicitation)**: Use discovery protocols to develop deeper experience insights
|
||||
- **P (Party Mode)**: Bring multiple perspectives to define optimal core experience
|
||||
- **C (Continue)**: Save the content to the document and proceed to next step
|
||||
|
||||
## PROTOCOL INTEGRATION:
|
||||
|
||||
- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
|
||||
- When 'P' selected: Invoke the `bmad-party-mode` skill
|
||||
- PROTOCOLS always return to this step's A/P/C menu
|
||||
- User accepts/rejects protocol changes before proceeding
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from previous steps are available
|
||||
- Core experience from step 3 provides foundation
|
||||
- Design system choice from step 6 informs implementation
|
||||
- Focus on the defining interaction that makes the product special
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Define the core interaction that, if nailed, makes everything else follow in the user experience.
|
||||
|
||||
## DEFINING EXPERIENCE SEQUENCE:
|
||||
|
||||
### 1. Identify the Defining Experience
|
||||
|
||||
Focus on the core interaction:
|
||||
"Every successful product has a defining experience - the core interaction that, if we nail it, everything else follows.
|
||||
|
||||
**Think about these famous examples:**
|
||||
|
||||
- Tinder: "Swipe to match with people"
|
||||
- Snapchat: "Share photos that disappear"
|
||||
- Instagram: "Share perfect moments with filters"
|
||||
- Spotify: "Discover and play any song instantly"
|
||||
|
||||
**For {{project_name}}:**
|
||||
What's the core action that users will describe to their friends?
|
||||
What's the interaction that makes users feel successful?
|
||||
If we get ONE thing perfectly right, what should it be?"
|
||||
|
||||
### 2. Explore the User's Mental Model
|
||||
|
||||
Understand how users think about the core task:
|
||||
"**User Mental Model Questions:**
|
||||
|
||||
- How do users currently solve this problem?
|
||||
- What mental model do they bring to this task?
|
||||
- What's their expectation for how this should work?
|
||||
- Where are they likely to get confused or frustrated?
|
||||
|
||||
**Current Solutions:**
|
||||
|
||||
- What do users love/hate about existing approaches?
|
||||
- What shortcuts or workarounds do they use?
|
||||
- What makes existing solutions feel magical or terrible?"
|
||||
|
||||
### 3. Define Success Criteria for Core Experience
|
||||
|
||||
Establish what makes the core interaction successful:
|
||||
"**Core Experience Success Criteria:**
|
||||
|
||||
- What makes users say 'this just works'?
|
||||
- When do they feel smart or accomplished?
|
||||
- What feedback tells them they're doing it right?
|
||||
- How fast should it feel?
|
||||
- What should happen automatically?
|
||||
|
||||
**Success Indicators:**
|
||||
|
||||
- [Success indicator 1]
|
||||
- [Success indicator 2]
|
||||
- [Success indicator 3]"
|
||||
|
||||
### 4. Identify Novel vs. Established Patterns
|
||||
|
||||
Determine if we need to innovate or can use proven patterns:
|
||||
"**Pattern Analysis:**
|
||||
Looking at your core experience, does this:
|
||||
|
||||
- Use established UX patterns that users already understand?
|
||||
- Require novel interaction design that needs user education?
|
||||
- Combine familiar patterns in innovative ways?
|
||||
|
||||
**If Novel:**
|
||||
|
||||
- What makes this different from existing approaches?
|
||||
- How will we teach users this new pattern?
|
||||
- What familiar metaphors can we use?
|
||||
|
||||
**If Established:**
|
||||
|
||||
- Which proven patterns should we adopt?
|
||||
- How can we innovate within familiar patterns?
|
||||
- What's our unique twist on established interactions?"
|
||||
|
||||
### 5. Define Experience Mechanics
|
||||
|
||||
Break down the core interaction into details:
|
||||
"**Core Experience Mechanics:**
|
||||
Let's design the step-by-step flow for [defining experience]:
|
||||
|
||||
**1. Initiation:**
|
||||
|
||||
- How does the user start this action?
|
||||
- What triggers or invites them to begin?
|
||||
|
||||
**2. Interaction:**
|
||||
|
||||
- What does the user actually do?
|
||||
- What controls or inputs do they use?
|
||||
- How does the system respond?
|
||||
|
||||
**3. Feedback:**
|
||||
|
||||
- What tells users they're succeeding?
|
||||
- How do they know when it's working?
|
||||
- What happens if they make a mistake?
|
||||
|
||||
**4. Completion:**
|
||||
|
||||
- How do users know they're done?
|
||||
- What's the successful outcome?
|
||||
- What's next?"
|
||||
|
||||
### 6. Generate Defining Experience Content
|
||||
|
||||
Prepare the content to append to the document:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
When saving to document, append these Level 2 and Level 3 sections:
|
||||
|
||||
```markdown
|
||||
## 2. Core User Experience
|
||||
|
||||
### 2.1 Defining Experience
|
||||
|
||||
[Defining experience description based on conversation]
|
||||
|
||||
### 2.2 User Mental Model
|
||||
|
||||
[User mental model analysis based on conversation]
|
||||
|
||||
### 2.3 Success Criteria
|
||||
|
||||
[Success criteria for core experience based on conversation]
|
||||
|
||||
### 2.4 Novel UX Patterns
|
||||
|
||||
[Novel UX patterns analysis based on conversation]
|
||||
|
||||
### 2.5 Experience Mechanics
|
||||
|
||||
[Detailed mechanics for core experience based on conversation]
|
||||
```
|
||||
|
||||
### 7. Present Content and Menu
|
||||
|
||||
Show the generated defining experience content and present choices:
|
||||
"I've defined the core experience for {{project_name}} - the interaction that will make users love this product.
|
||||
|
||||
**Here's what I'll add to the document:**
|
||||
|
||||
[Show the complete markdown content from step 6]
|
||||
|
||||
**What would you like to do?**
|
||||
[A] Advanced Elicitation - Let's refine the core experience definition
|
||||
[P] Party Mode - Bring different perspectives on the defining interaction
|
||||
[C] Continue - Save this to the document and move to visual foundation
|
||||
|
||||
### 8. Handle Menu Selection
|
||||
|
||||
#### If 'A' (Advanced Elicitation):
|
||||
|
||||
- Invoke the `bmad-advanced-elicitation` skill with the current defining experience content
|
||||
- Process the enhanced experience insights that come back
|
||||
- Ask user: "Accept these improvements to the defining experience? (y/n)"
|
||||
- If yes: Update content with improvements, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'P' (Party Mode):
|
||||
|
||||
- Invoke the `bmad-party-mode` skill with the current defining experience
|
||||
- Process the collaborative experience insights that come back
|
||||
- Ask user: "Accept these changes to the defining experience? (y/n)"
|
||||
- If yes: Update content with improvements, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to `{planning_artifacts}/ux-design-specification.md`
|
||||
- Update frontmatter: append step to end of stepsCompleted array
|
||||
- Load `./step-08-visual-foundation.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from step 6.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Defining experience clearly articulated
|
||||
✅ User mental model thoroughly analyzed
|
||||
✅ Success criteria established for core interaction
|
||||
✅ Novel vs. established patterns properly evaluated
|
||||
✅ Experience mechanics designed in detail
|
||||
✅ A/P/C menu presented and handled correctly
|
||||
✅ Content properly appended to document when C selected
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Not identifying the true core interaction
|
||||
❌ Missing user's mental model and expectations
|
||||
❌ Not establishing clear success criteria
|
||||
❌ Not properly evaluating novel vs. established patterns
|
||||
❌ Experience mechanics too vague or incomplete
|
||||
❌ Not presenting A/P/C menu after content generation
|
||||
❌ Appending content without user selecting 'C'
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved to document, load `./step-08-visual-foundation.md` to establish visual design foundation.
|
||||
|
||||
Remember: Do NOT proceed to step-08 until user explicitly selects 'C' from the A/P/C menu and content is saved!
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user