--- id: duc01226/EasyPlatform/brainstorm version: "ec22f759" license: MIT install: manual updated: 2026-06-18 --- # brainstorm — Brainstorm runs your team through a scenario-aware ideation workflow—problem-solving, new product, or feature enhancement—using diverge-and-converge phases to move from raw ideas to a ranked shortlist of 3–5 candidates. Each finalist carries a problem statement, value hypothesis, riskiest assumption, and cheapest validation test, ensuring you commit to the right problem before building. Publisher: duc01226 · Stars: 7 · Updated: 2026-06-18 Install (manual): `git clone https://github.com/duc01226/EasyPlatform` ## SKILL.md > Codex compatibility note: > > - Invoke repository skills with `$skill-name` in Codex; this mirrored copy rewrites legacy Claude `/skill-name` references. > - Task tracker mandate: BEFORE executing any workflow or skill step, create/update task tracking for all steps and keep it synchronized as progress changes. > - User-question prompts mean to ask the user directly in Codex. > - Ignore Claude-specific mode-switch instructions when they appear. > - Strict execution contract: when a user explicitly invokes a skill, execute that skill protocol as written. > - Subagent authorization: when a skill is user-invoked or AI-detected and its protocol requires subagents, that skill activation authorizes use of the required `spawn_agent` subagent(s) for that task. > - Do not skip, reorder, or merge protocol steps unless the user explicitly approves the deviation first. > - For workflow skills, execute each listed child-skill step explicitly and report step-by-step evidence. > - If a required step/tool cannot run in this environment, stop and ask the user before adapting. ## Codex Project-Reference Loading (No Hooks) Codex uses static project-reference loading instead of runtime-injected project docs. When coding, planning, debugging, testing, or reviewing, open project docs explicitly using this routing. **Always read:** - `docs/project-config.json` (project-specific paths, commands, modules, and workflow/test settings) - `docs/project-reference/docs-index-reference.md` (routes to the full `docs/project-reference/*` catalog) - `docs/project-reference/lessons.md` (always-on guardrails and anti-patterns) **Missing/stale context route:** If `docs/project-config.json`, the docs index, `lessons.md`, `CLAUDE.md`, `AGENTS.md`, or any task-required reference doc is missing or stale, auto-run `$project-init` or the narrow setup route (`$project-config`, `$docs-init`, `$scan-all`, `$scan --target=`, `$claude-md-init`) before ordinary project-specific work. If Codex mirrors or `AGENTS.md` are missing/stale, ask the user to run `$sync-codex`; do not auto-run it. **Situation-based docs:** - Backend/CQRS/API/domain/entity changes: `backend-patterns-reference.md`, `domain-entities-reference.md`, `project-structure-reference.md` - Frontend/UI/styling/design-system: `frontend-patterns-reference.md`, `scss-styling-guide.md`, `design-system/README.md` - Spec authoring, `docs/specs/` pathing, or TC format: `feature-spec-reference.md`, `spec-system-reference.md`, `spec-principles.md` - Behavior/public-contract changes or spec-test-code sync: `workflow-spec-test-code-cycle-reference.md` plus the spec docs above - Derived spec indexes/ERDs/reimplementation guides: `spec-system-reference.md` and source Feature Specs under `docs/specs/` - Integration test implementation/review: `integration-test-reference.md` - E2E test implementation/review: `e2e-test-reference.md` - Code review/audit work: `code-review-rules.md` plus domain docs above based on changed files Do not read all docs blindly. Start from `docs-index-reference.md`, then open only relevant files for the task. > **[BLOCKING]** Execute skill steps in declared order. NEVER skip, reorder, or merge steps without explicit user approval. > **[BLOCKING]** Before each step or sub-skill call, update task tracking: set `in_progress` when step starts, set `completed` when step ends. > **[BLOCKING]** Every completed/skipped step MUST include brief evidence or explicit skip reason. > **[BLOCKING]** If Task tools are unavailable, create and maintain an equivalent step-by-step plan tracker with the same status transitions. ## Quick Summary **Goal:** Facilitate a structured PO/BA brainstorming session via the Double Diamond process (diverge to discover problems and opportunities, then converge to validate and prioritize) to deliver a scored, ranked shortlist of 3-5 candidate ideas — each carrying a problem + value hypothesis, an identified riskiest assumption, and the cheapest validation test designed — so the team commits to the right problem AND the right solution before building, never to a flat unvalidated idea list. **Summary:** - Run a direct user question Phase 0 FIRST to detect scenario (Problem-Solving / New Product / Enhancement), role (PO / BA / Mixed), and how-much-is-known — each scenario routes a different technique sequence (see Scenario Cheat Sheets), so misclassifying here derails everything downstream. - Strictly separate diverge (Phases 1 & 3 — generate, "Yes, and…", zero judgment) from converge (Phases 2 & 4 — narrow, RICE/Kano/MoSCoW scoring); mixing the two modes is the Golden Rule violation that kills idea output. - Never stop at a raw or flat idea list: every top-3 candidate MUST carry a problem + value hypothesis card, an identified riskiest assumption (RAT), and the single cheapest validation test designed before any build commitment. - Close with an opinionated decision (Phase 6 — recommend ONE option with trade-offs, not a menu), every claim evidence-backed at >80% confidence, then offer handoff via a direct user question to `$idea`, `$refine`, `$plan`, etc. **Three Scenarios:** | Scenario | Entry Trigger | Primary Methods | | ----------------------- | ------------------------------------------------------ | ------------------------------------------------------------------------------ | | **Problem-Solving** | "Something is broken / users complain / metric is bad" | 5 Whys → Fishbone → HMW → SCAMPER → Hypothesis RAT | | **New Product** | "Greenfield idea / new market / no codebase yet" | JTBD → Lean Canvas → Crazy 8s → Opportunity Scoring → Lean Hypothesis | | **Feature Enhancement** | "Existing product / add capability / improve flow" | Opportunity Solution Tree → SCAMPER → Impact Mapping → RICE → Value Hypothesis | **Double Diamond (master meta-framework):** ``` DIAMOND 1: Right Problem DIAMOND 2: Right Solution ──────────────────────────── ────────────────────────── Discover ──► Define Develop ──► Deliver (diverge) (converge) (diverge) (converge) ``` **Golden Rule:** NEVER evaluate ideas while generating them. Diverge and converge are separate modes. Mixing them kills creative output. **Be skeptical. Apply critical thinking. Every idea needs a testable hypothesis. Confidence >80% required before recommending.** --- ## Answer this question: $ARGUMENTS --- ## Phase 0: Session Setup (MANDATORY) Use a direct user question to detect scenario, role, and constraints before any technique. ### 0.1 — Scenario Detection Ask: 1. **"What scenario are we in?"** - Problem-solving — something is broken, users struggle, a metric is bad - New product — greenfield, no existing product in this space - Feature enhancement — existing product, add/improve/remove capability - Mixed — multiple of the above 2. **"What is the primary role in this session?"** - Product Owner — outcome-focused, business value, user outcomes - Business Analyst — requirements-focused, process analysis, stakeholder mapping - Both PO + BA — full discovery and requirements - Developer / Architect — technical feasibility brainstorm 3. **"How much is already known?"** - Raw seed — just an intuition or observation - Problem confirmed — we know the problem, need solutions - Solution direction known — need to evaluate and score options - Idea exists — need hypothesis validation only ### 0.2 — Context Loading - If project codebase exists: read `docs/specs/` to understand domain - If greenfield: skip codebase reading; rely on user input and web research - Load `docs/project-reference/domain-entities-reference.md` if entity context needed - Use `WebSearch` for market/competitor context when scenario = New Product or Enhancement --- ## Phase 1: Problem Framing — Diamond 1 Diverge **Goal:** Fully understand problem space before jumping to solutions. #1 brainstorming failure: solving the wrong problem. **Time-box:** 20–45 minutes of session time. ### 1.1 — Problem Statement (POV Format) Formulate a crisp problem statement BEFORE any ideation: ``` [User/Persona] needs [need/job-to-be-done] because [insight/root cause/context], but [current barrier/friction/failure]. ``` **Example:** ``` Operators need to quickly identify high-priority orders for action because peak-season backlogs delay fulfillment, but the current system shows raw order data with no ranking or comparison. ``` Use a direct user question to validate: - "Is this the core problem, or a symptom of a deeper problem?" - "Who specifically experiences this? How often? What's the cost?" - "What evidence do we have this problem actually exists?" ### 1.2 — Root Cause Analysis (for Problem-Solving scenario) Apply one of: **5 Whys:** ``` Problem: [stated problem] Why 1: [first cause] Why 2: [cause of cause 1] Why 3: [cause of cause 2] Why 4: [cause of cause 3] Why 5: [root cause] ← Fix HERE, not at Why 1 ``` **Fishbone (Ishikawa) — for systemic problems:** Spine = problem statement. Bones = 6 cause categories: - People, Process, Technology, Data, Environment, Policy - For each bone: ask "What in this category could cause the problem?" ### 1.3 — JTBD (Jobs-To-Be-Done) — for New Product & Enhancement Replace user stories with job stories to expose real motivation: **User Story (what):** As an operator, I want to see order totals, so that I can make decisions. **Job Story (why + context):** When I'm clearing a peak-season backlog with limited time, I want to instantly see which orders need action without opening every record, so I can make fast, defensible decisions before the cutoff. **Job Story Formula:** ``` When [triggering situation + context], I want to [motivation / job to be done], so I can [outcome / expected result]. ``` Generate 3–5 job stories covering main user segments. Each story = one opportunity. ### 1.4 — HMW (How Might We) Reframing Transform problem statements into ideation-ready questions: **Formula:** "How might we [verb] [object] so that [desired outcome]?" From the POV statement: - "How might we **help HR managers rank employees** so that promotion decisions take minutes not days?" - "How might we **surface hidden top performers** so that managers discover talent they'd otherwise miss?" - "How might we **reduce bias in performance scoring** so that promotion feels fair to all employees?" **Rules:** - Each HMW covers ONE idea direction - Generate 5–10 HMW questions per problem - Too broad = "How might we improve HR?" (useless) → too narrow = "How might we add a sort button?" (skip ideation, just build it) - Sweet spot: one-concept questions that invite multiple solutions **Output of Phase 1:** - [ ] Problem statement (POV format) - [ ] Root cause (5 Whys or Fishbone) — Problem-Solving only - [ ] 3–5 Job Stories - [ ] 5–10 HMW questions --- ## Phase 2: Opportunity Framing — Diamond 1 Converge **Goal:** Narrow problem space to highest-opportunity focus areas before ideating solutions. ### 2.1 — Opportunity Solution Tree (OST) — for Enhancement Teresa Torres' framework. Maps desired outcome → opportunities → solutions → experiments. ``` Desired Outcome (business metric) ├── Opportunity 1 (unmet user need / pain / want) │ ├── Solution A │ └── Solution B ├── Opportunity 2 │ ├── Solution C │ └── Solution D └── Opportunity 3 (deprioritized) ``` **Step 1:** State ONE desired outcome (lagging metric the team owns — e.g., "Increase manager satisfaction with review process from 3.2 to 4.0 CSAT") **Step 2:** Map ALL known opportunities (pains, needs, wants) from research/interviews **Step 3:** For each top opportunity, generate solution directions (not detailed solutions yet) **Step 4:** Pick 1–2 opportunities to develop further in Phase 3 ### 2.2 — Lean Canvas — for New Product One-page business model for greenfield ideas (Ash Maurya): | Block | Question | | ----------------- | ------------------------------------- | | Problem | Top 3 problems being solved | | Customer Segments | Who has this problem? Early adopters? | | Unique Value Prop | Single compelling message | | Solution | Top 3 features (not full spec) | | Channels | How to reach customers | | Revenue Streams | How to make money | | Cost Structure | Fixed + variable costs | | Key Metrics | One number that measures success | | Unfair Advantage | What can't easily be copied? | Fill one canvas per major target segment. Keep it to 20 min — speed is the point. ### 2.3 — Blue Ocean ERRC Grid — for Enhancement or New Product Eliminate-Reduce-Raise-Create grid (Chan Kim & Mauborgne): | Eliminate | Reduce | | --------------------------- | --------------------------------- | | Features users never use | Features that are over-engineered | | **Raise** | **Create** | | Features users want more of | Features no competitor offers | **Rule:** Every innovation should have at least ONE item in Create AND one in Eliminate. A product with only Raise entries is incremental — not differentiated. ### 2.4 — Value Proposition Canvas Connects customer profile to product value: **Customer Profile:** - Jobs (functional, social, emotional) - Pains (frustrations, obstacles, risks) - Gains (benefits, desires, measures of success) **Value Map:** - Products & Services (what you offer) - Pain Relievers (how you reduce pains) - Gain Creators (how you produce gains) **Fit = where Pain Relievers match Pains + Gain Creators match Gains.** **Output of Phase 2:** - [ ] OST with 2 selected opportunities (Enhancement) - [ ] Lean Canvas (New Product) - [ ] ERRC grid (New Product or Enhancement) - [ ] Value Proposition fit assessment --- ## Phase 3: Ideation — Diamond 2 Diverge **Goal:** Generate maximum quantity of solution ideas without judgment. Quality comes Phase 4. **Critical rule:** NO evaluation in this phase. Every idea is valid. "Yes, and..." not "Yes, but..." ### 3.1 — SCAMPER Apply each lens to the problem/existing product to generate solution directions: | Letter | Prompt | Example for order-prioritization feature | | -------------------- | -------------------------- | ------------------------------------------------------------- | | **S**ubstitute | What can be replaced? | Replace manual sorting with AI-assisted ranking | | **C**ombine | What can be merged? | Combine status + history + SLA risk in one view | | **A**dapt | What can be borrowed? | Adapt Netflix recommendation to surface priority orders | | **M**odify | What can be scaled/shrunk? | Shrink the review queue to a daily priority check | | **P**ut to other use | Different context? | Use order history for restocking recommendations | | **E**liminate | What can be removed? | Eliminate the nightly batch — replace with continuous signals | | **R**everse | Flip the process? | Let downstream stages pull orders instead of pushing | Generate at least 2 ideas per SCAMPER letter = minimum 14 ideas. ### 3.2 — Crazy 8s (Rapid Visual Ideation) **Time-box: 8 minutes. 8 ideas. No refinement.** Process: 1. Fold paper into 8 sections (or create 8 boxes mentally) 2. Sketch one idea concept per box — rough is fine 3. Timer forces quantity over perfection 4. Share and build on sketches For AI-facilitated sessions: - AI generates 8 distinct solution directions in 2 minutes - User picks top 3 to explore deeper - Each direction = 1 sentence + 1 key differentiator ### 3.3 — Brainwriting 6-3-5 For multi-stakeholder sessions (async-friendly): - 6 participants, 3 ideas each, 5 rounds - Each round: read previous ideas → add 3 new ideas OR build on existing - Result: up to 108 ideas in 30 minutes (works async via shared doc) For AI-facilitated sessions: - AI plays all 6 roles across 3 rounds - Generates ideas from: PO perspective, BA perspective, End User perspective, Dev perspective, Ops perspective, Business perspective ### 3.4 — Impact Mapping Gojko Adzic's technique. Maps Goal → Actors → Impacts → Deliverables: ``` GOAL: [business outcome with measurable target] ├── ACTOR: Who can help/hinder? │ ├── IMPACT: How should behavior change? │ │ └── DELIVERABLE: What feature produces this impact? │ └── IMPACT: What negative behavior to prevent? │ └── DELIVERABLE: What reduces this risk? └── ACTOR: ... ``` **Key insight:** Work backward from GOAL. If a deliverable doesn't trace to an actor behavior change, don't build it. ### 3.5 — Analogical Thinking "How does [industry X] solve [similar problem Y]?" | Analogy Source | Application to HR | | ----------------------------- | -------------------------------------- | | Spotify Discover Weekly | Personalized learning recommendations | | Uber surge pricing | Dynamic bonus pool allocation | | GitHub PR reviews | Peer skill endorsement with evidence | | Amazon recommendation engine | Next goal suggestion | | Netflix "because you watched" | "Colleagues like you also achieved..." | **Output of Phase 3:** - [ ] SCAMPER grid with 14+ ideas - [ ] Crazy 8s — 8 solution directions - [ ] Impact Map (top 2 goals) - [ ] Analogy-inspired ideas (3–5) - [ ] Total raw idea count: target 25–40 ideas --- ## Phase 4: Evaluation & Convergence — Diamond 2 Converge **Goal:** Reduce 25–40 raw ideas to a ranked shortlist of 3–5 candidates for hypothesis testing. ### 4.1 — Dot Voting (First Pass) Before scoring, do a quick gut-check elimination: - Each idea gets a ✅ (keep) / ❌ (drop) / 🔄 (merge with another) - Merge near-identical ideas - Drop ideas that violate hard constraints (budget, tech, legal) - Target: reduce to 10–15 candidates ### 4.2 — RICE Scoring Rank remaining candidates: ``` RICE Score = (Reach × Impact × Confidence) / Effort Reach: Users affected per quarter (100 / 500 / 1000 / 5000+) Impact: 0.25 minimal | 0.5 low | 1 medium | 2 high | 3 massive Confidence: 0.5 low (gut feel) | 0.8 medium (some data) | 1.0 high (validated) Effort: Story Points — 1 trivial | 3 small | 5 medium | 8 large | 13 very large ``` Score all 10–15 candidates. Sort descending. Top 5 = shortlist. ### 4.3 — Kano Model Classification For each shortlisted idea, classify: | Category | Description | If absent | If present | Example | | --------------- | --------------------- | ------------------ | --------------- | ---------------- | | **Must-Be** | Baseline expectation | Users angry | Users neutral | Login works | | **Performance** | More = better | Users dissatisfied | Users satisfied | Faster load | | **Delighter** | Unexpected value | Users neutral | Users delighted | Smart suggestion | | **Indifferent** | Doesn't matter | Users neutral | Users neutral | Icon colors | | **Reverse** | Some want, some don't | Segment upset | Segment happy | Auto-fill | **Strategy:** Must-Be → Performance → Delighter. Never skip Must-Be items for Delighters. ### 4.4 — Effort × Impact 2×2 Quick visual triage: ``` HIGH IMPACT │ Quick Wins ★ │ Major Projects ⚙️ │ (do first) │ (schedule carefully) ────┼──────────────────┼──────────────────── │ Fill-Ins 📋 │ Money Pits ⚠️ │ (if time) │ (avoid or cut) LOW IMPACT LOW EFFORT HIGH EFFORT ``` Plot each shortlisted idea. Quick Wins = default first picks unless Major Project has strategic necessity. ### 4.5 — MoSCoW for Release Scope For each idea in the shortlist, assign release priority: | Priority | Meaning | Threshold | | --------------- | ---------------------------------- | -------------------------------------- | | **Must Have** | MVP is broken without it | Include if >80% of value depends on it | | **Should Have** | Important but MVP works without it | Include if RICE > median | | **Could Have** | Nice to have, low risk to cut | Include if effort ≤ 3 SP | | **Won't Have** | Explicitly out of scope this cycle | Document for future | **Output of Phase 4:** - [ ] Dot-voted shortlist (10–15 ideas) - [ ] RICE-scored table (top 5 ranked) - [ ] Kano classification for each shortlisted idea - [ ] 2×2 matrix placement - [ ] MoSCoW assignment per idea --- ## Phase 5: Hypothesis Validation **Goal:** Before committing to build, test riskiest assumptions. 42% of startups fail from no market need — validate before building. ### 5.1 — Problem Hypothesis ```markdown **We believe** [target users/persona] **Experience** [specific problem] **Because** [root cause] **We'll know this is true when** [validation metric/observable evidence] ``` **Example:** ``` We believe Operators Experience frustration identifying high-priority orders during peak backlogs Because order data is fragmented across 3 systems with no unified ranking We'll know this is true when 3+ operators confirm they spend >2hrs per shift on manual data aggregation ``` ### 5.2 — Value Hypothesis ```markdown **We believe** [feature/solution] **Will deliver** [specific value/outcome] **To** [target users] **We'll know we're right when** [measurable success metric] ``` ### 5.3 — Riskiest Assumption Test (RAT) Identify the ONE assumption whose failure kills the idea: 1. List all assumptions: user behavior, technical feasibility, market demand, business model 2. Score each: `Probability of being wrong (0–1) × Impact if wrong (0–1)` 3. Highest score = Riskiest Assumption 4. Design cheapest possible test to validate/invalidate it **before** full build: - User interview (2–3 days) - Landing page / fake door test (1 week) - Prototype click-through (3–5 days) - Concierge MVP (1–2 weeks) - Smoke test / pre-sell (2–4 weeks) ### 5.4 — Build-Measure-Learn Loop For each top idea, define the loop: ``` BUILD: Minimum experiment to test the assumption (not a full product) MEASURE: One metric that proves/disproves the hypothesis LEARN: What decision do we make if metric is met / not met? PIVOT: If hypothesis invalidated — which alternative from Phase 3 do we try next? ``` **Output of Phase 5:** - [ ] Problem hypothesis card per top-3 idea - [ ] Value hypothesis card per top-3 idea - [ ] Riskiest Assumption identified per idea - [ ] Cheapest test designed - [ ] Build-Measure-Learn loop defined --- ## Phase 6: Decision & Recommendations **Goal:** Present a clear, opinionated recommendation with trade-offs. Not "here are all the options" — "here's what we recommend and why." ### 6.1 — Top 3 Options Table Present final shortlist as a decision table: | Option | RICE | Kano | Effort | Risk | RAT Test | Recommendation | | -------- | ---- | ----------- | ------ | ------ | --------------- | -------------- | | Option A | 320 | Delighter | 5 SP | Medium | 3-day interview | ⭐ Recommended | | Option B | 180 | Performance | 8 SP | Low | Prototype | Viable | | Option C | 90 | Must-Be | 13 SP | High | Pre-sell | Defer | ### 6.2 — Recommendation Statement ``` RECOMMENDED: [Option Name] Why: [1–2 sentences on RICE + Kano + strategic fit] Risk: [Primary risk + mitigation] First step: [Cheapest test to validate before full commitment] Time to validation: [Days/weeks] ``` ### 6.3 — Dependency & Sequencing Check - Does Option A depend on any existing feature/data/service not yet built? - Can experiments run in parallel? - What's the critical path to first validated learning? --- ## Phase 7: Documentation & Handoff ### Report Output Use naming pattern from `## Naming` section in injected context. Create markdown summary report: ```markdown # Brainstorm Session Report: [Topic] ## Session Context - Scenario: [Problem-Solving / New Product / Enhancement] - Role: [PO / BA / Mixed] - Date: [YYYY-MM-DD] - Input: [Original question/problem] ## Problem Statement [POV format] ## Root Cause Analysis [5 Whys or Fishbone — if Problem-Solving] ## Job Stories 1. [Job Story 1] 2. [Job Story 2] 3. [Job Story 3] ## HMW Questions 1. How might we... 2. How might we... ## Opportunity Map [OST or Lean Canvas — per scenario] ## Raw Ideas Generated [Total count: XX ideas across SCAMPER / Crazy 8s / Impact Mapping] ## Scored Shortlist (RICE) | Rank | Idea | RICE | Kano | Effort | Priority | | ---- | ---- | ---- | ---- | ------ | ----------- | | 1 | ... | ... | ... | ... | Must Have | | 2 | ... | ... | ... | ... | Should Have | ## Hypothesis Cards ### Top Recommendation: [Option Name] - Problem Hypothesis: ... - Value Hypothesis: ... - Riskiest Assumption: ... - Cheapest Test: ... - Success Metric: ... ## Decision [Recommendation + rationale] ## Next Steps - [ ] [First concrete action] - [ ] [Validation test] - [ ] [Stakeholder alignment needed] ``` --- ## Technique Quick Reference | Technique | Phase | When to Use | Time-box | | ------------------------- | ----- | ---------------------------------- | -------- | | POV Statement | P1 | Always | 10 min | | 5 Whys | P1 | Problem-solving scenario | 15 min | | Fishbone | P1 | Systemic/complex problems | 20 min | | JTBD / Job Stories | P1 | New product or enhancement | 20 min | | HMW Questions | P1 | Always — bridge problem → ideation | 15 min | | Opportunity Solution Tree | P2 | Enhancement scenario | 30 min | | Lean Canvas | P2 | New product scenario | 20 min | | Blue Ocean ERRC | P2 | Differentiation needed | 20 min | | Value Proposition Canvas | P2 | Product-market fit unclear | 25 min | | SCAMPER | P3 | Always — structured ideation | 30 min | | Crazy 8s | P3 | Need quantity fast | 8 min | | Brainwriting 6-3-5 | P3 | Multi-stakeholder, async | 30 min | | Impact Mapping | P3 | Outcome-first thinking | 30 min | | Analogical Thinking | P3 | Novel/creative directions needed | 15 min | | Dot Voting | P4 | First-pass elimination | 10 min | | RICE Scoring | P4 | Always for prioritization | 20 min | | Kano Model | P4 | Feature classification | 15 min | | 2×2 Effort/Impact | P4 | Visual triage | 10 min | | MoSCoW | P4 | Release scoping | 15 min | | Problem Hypothesis | P5 | Always before committing | 15 min | | Value Hypothesis | P5 | Always before committing | 15 min | | Riskiest Assumption Test | P5 | Before full build | 20 min | | Build-Measure-Learn | P5 | Lean validation | 20 min | --- ## Role-Specific Guidance ### PO Mode (Outcome Focus) - Lead with: desired business outcome → opportunities → experiments - Use: OST, Impact Mapping, RICE, Build-Measure-Learn - Ask: "What behavior change do we need to see in users?" - Resist: jumping to features before validating the outcome ### BA Mode (Requirements Focus) - Lead with: stakeholder needs → process gaps → requirements - Use: BABOK elicitation (interviews, workshops, document analysis), Fishbone, JTBD - Ask: "What does the system need to do to enable that behavior?" - Resist: over-specifying before the PO validates the opportunity ### Mixed PO + BA Mode - PO owns: problem statement, opportunity framing, prioritization, hypothesis - BA owns: requirements elicitation, acceptance criteria, edge cases, process mapping - Handoff point: after Phase 4 (scored shortlist) → BA writes acceptance criteria per idea --- ## Collaboration Tools - `planner` agent — research industry best practices for specific domain - `docs-manager` agent — understand existing feature constraints and domain context - `WebSearch` — market/competitor context for new product scenarios - `docs-seeker` skill — latest documentation for external plugins/APIs - `visual analysis tooling` skill — analyze visual mockups, screenshots, competitor UIs - `sequential-thinking` skill — complex problem decomposition requiring structured causal chains - `web-research` skill — deep market research for greenfield or competitive analysis --- ## Scenario Cheat Sheets ### Scenario A: Problem-Solving ``` 1. POV Statement → 2. 5 Whys / Fishbone → 3. HMW Questions → 4. SCAMPER on current solution → 5. RICE scoring → 6. Problem Hypothesis + RAT → 7. Recommend + cheapest test ``` ### Scenario B: New Product ``` 1. Job Stories (JTBD) → 2. Lean Canvas → 3. Blue Ocean ERRC → 4. HMW Questions → 5. Crazy 8s / Brainwriting → 6. Kano Classification → 7. Value Hypothesis + RAT → 8. MVP scope ``` ### Scenario C: Feature Enhancement ``` 1. Job Stories (JTBD) → 2. Opportunity Solution Tree → 3. HMW Questions → 4. SCAMPER on existing feature → 5. Impact Mapping → 6. RICE scoring → 7. 2×2 matrix → 8. Value Hypothesis + RAT → 9. Recommend + next experiment ``` --- ## Anti-Patterns to Avoid | Anti-Pattern | Why It Fails | Better Approach | | -------------------------------------------- | ------------------------------------------------ | -------------------------------------------- | | Jumping to solutions before defining problem | Builds the wrong thing | Always complete Phase 1 first | | Evaluating ideas while generating them | Kills creative output, premature closure | Strict diverge/converge separation | | One stakeholder perspective only | Misses jobs, pains, context | Brainwriting from 6 different roles | | No hypothesis before building | 42% of features fail — no market need | Always write hypothesis + RAT | | RICE without confidence score | Overestimates low-evidence ideas | Always include Confidence as a multiplier | | Kano ignored — building only Delighters | Users can't use a delighter with broken Must-Bes | Prioritize Must-Be → Performance → Delighter | | "Best idea wins" without validation test | HiPPO bias (Highest Paid Person's Opinion) | Every top idea needs a RAT test design | | Scope creep in ideation | Ideas balloon beyond what team can validate | Timebox each phase strictly | | Treating RICE score as final truth | RICE is directional, not precise | Use RICE + Kano + strategic context together | --- ## Critical Constraints - **DO NOT implement solutions** — brainstorm and advise only - **DO validate hypotheses** before endorsing any approach - **DO prioritize long-term maintainability** over short-term convenience - **DO consider both technical excellence and business pragmatism** - **DO produce a scored, ranked shortlist** — never just a flat idea list - **DO always design the cheapest validation test** — RAT before full spec --- ## Workflow Integration After brainstorm session concludes, use a direct user question to present next steps: | Next Step | When | Skill/Workflow | | ---------------------- | ----------------------------------------------------------- | ----------------------- | | `$idea` | Capture top idea as backlog artifact | `idea` skill | | `$refine` | Turn top idea into actionable PBI with AC | `refine` skill | | `$web-research` | Need deeper market/competitor research first | `web-research` skill | | `$plan` | Problem is clear, solution is validated, ready to implement | `plan` skill | | `$design-spec` | UI-heavy idea, need wireframes before spec | `design-spec` skill | | `$domain-analysis` | Idea touches domain entities, need model first | `domain-analysis` skill | | Continue brainstorming | More scenarios to explore | Stay in this session | --- > **[IMPORTANT]** Use task tracking to break ALL work into small tasks BEFORE starting. This prevents context loss from long sessions. --- > **AI Mistake Prevention** — Failure modes to avoid on every task: > > **Re-read files after context changes.** Context compaction, resume, or long-running work can make memory stale; verify current files before acting. > **Verify generated content against source evidence.** AI hallucinates APIs, names, claims, and document facts. Check the relevant source before documenting or referencing. > **Check downstream references before deleting or renaming.** Removing an artifact can stale docs, generated mirrors, configs, and callers; map references first. > **Trace the full impact chain after edits.** Changing a definition can miss derived outputs and consumers. Follow the affected chain before declaring done. > **Verify ALL affected outputs, not just the first.** One green check is not all green checks; validate every output surface the change can affect. > **Assume existing values are intentional — ask WHY before changing.** Before changing a constant, limit, flag, wording, or pattern, read nearby context and history. > **Surface ambiguity before acting — don't pick silently.** Multiple valid interpretations require an explicit question or stated assumption with risk. > **Keep shared guidance role-relevant.** Universal guidance must help every receiving skill or agent; code-specific obligations belong only in code-specific protocols. > **Critical Thinking Mindset** — Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence >80% to act. > **Anti-hallucination:** Never present guess as fact — cite sources for every claim, admit uncertainty freely, self-check output for errors, cross-reference independently, stay skeptical of own confidence — certainty without evidence root of all hallucination. > **Sequential Thinking Protocol** — Structured multi-step reasoning for complex/ambiguous work. Use when planning, reviewing, debugging, or refining ideas where one-shot reasoning is unsafe. > > **Trigger when:** complex problem decomposition · adaptive plans needing revision · analysis with course correction · unclear/emerging scope · multi-step solutions · hypothesis-driven debugging · cross-cutting trade-off evaluation. > > **Format (explicit mode — visible thought trail):** > > 1. `Thought N/M: [aspect]` — one aspect per thought, state assumptions/uncertainty > 2. `Thought N/M [REVISION of Thought K]: ...` — when prior reasoning invalidated; state Original / Why revised / Impact > 3. `Thought N/M [BRANCH A from Thought K]: ...` — explore alternative; converge with decision rationale > 4. `Thought N/M [HYPOTHESIS]: ...` then `[VERIFICATION]: ...` — test before acting > 5. `Thought N/N [FINAL]` — only when verified, all critical aspects addressed, confidence >80% > > **Mandatory closers:** Confidence % stated · Assumptions listed · Open questions surfaced · Next action concrete. > > **Stop conditions:** confidence <80% on any critical decision → escalate via ask the user directly · ≥3 revisions on same thought → re-frame the problem · branch count >3 → split into sub-task. > > **Implicit mode:** apply methodology internally without visible markers when adding markers would clutter the response (routine work where reasoning aids accuracy). > > **Deep-dive:** see `$sequential-thinking` skill (`.claude/skills/sequential-thinking/SKILL.md`) for worked examples (API design, debugging, architecture), advanced techniques (spiral refinement, hypothesis testing, convergence), and meta-strategies (uncertainty handling, revision cascades). **MUST ATTENTION** apply critical + sequential thinking — every claim needs appropriate traced evidence (`file:line` for repo/code claims; source URL or artifact section for research, product, content, and docs claims); confidence >80% to act, <60% DO NOT recommend. Anti-hallucination: never present guess as fact, admit uncertainty freely, cross-reference independently, stay skeptical of own confidence. **MUST ATTENTION** apply sequential-thinking — multi-step Thought N/M, REVISION/BRANCH/HYPOTHESIS markers, confidence % closer; see `$sequential-thinking` skill. **MUST ATTENTION** apply AI mistake prevention — verify generated content against evidence, trace downstream references before deleting or renaming, verify all affected outputs, re-read files after context loss, and surface ambiguity before acting. ## Prompt-Enhance Closing Anchors **IMPORTANT MUST ATTENTION** follow declared step order for this skill; NEVER skip, reorder, or merge steps without explicit user approval **IMPORTANT MUST ATTENTION** for every step/sub-skill call: set `in_progress` before execution, set `completed` after execution **IMPORTANT MUST ATTENTION** every skipped step MUST include explicit reason; every completed step MUST include concise evidence **IMPORTANT MUST ATTENTION** if Task tools unavailable, maintain an equivalent step-by-step plan tracker with synchronized statuses ## Closing Reminders - **IMPORTANT MUST ATTENTION Goal:** Deliver a scored, ranked shortlist of 3-5 candidate ideas — each carrying a problem + value hypothesis, an identified riskiest assumption, and the cheapest validation test designed — so the team commits to the right problem AND the right solution before building, never to a flat unvalidated idea list. **Protocols in force (concise digest of the SYNC/shared blocks this skill carries):** - **AI Mistake Prevention:** verify generated content against evidence, trace downstream references, verify all affected outputs, re-read after context loss, surface ambiguity. - **Critical Thinking:** traced `file:line` proof; confidence >80% to act; never guess. - **Sequential Thinking:** multi-step Thought N/M with REVISION/BRANCH/HYPOTHESIS markers, confidence closer. - **MANDATORY IMPORTANT MUST ATTENTION** detect scenario + role + how-much-known via a direct user question Phase 0 FIRST — each scenario routes a different technique sequence — why: misclassifying scenario derails every downstream phase. - **MANDATORY IMPORTANT MUST ATTENTION** separate diverge (Phases 1 & 3, generate, "Yes, and…", zero judgment) from converge (Phases 2 & 4, narrow + score) — NEVER evaluate ideas while generating them — why: mixing the two modes is the Golden Rule violation that kills creative output. - **MANDATORY IMPORTANT MUST ATTENTION** NEVER stop at a raw or flat idea list — every top-3 candidate carries a problem + value hypothesis card, an identified riskiest assumption (RAT), and the single cheapest validation test designed before any build commitment — why: 42% of features fail from no market need; validate before building. - **MANDATORY IMPORTANT MUST ATTENTION** break work into small todo tasks using task tracking BEFORE starting; mark each `completed` immediately, add a final review todo — why: long brainstorm sessions lose context without external task tracking. - **MANDATORY IMPORTANT MUST ATTENTION** search 3+ existing patterns first — read `docs/specs/` for domain (codebase) or `WebSearch` for market/competitor context (greenfield) before ideating — why: ideas ungrounded in domain or market evidence score on gut feel, not fit. - **MANDATORY IMPORTANT MUST ATTENTION** cite evidence for every claim, confidence >80% to recommend; RICE Confidence is a multiplier, not optional — why: low-evidence ideas without a Confidence score get over-ranked. - **MANDATORY IMPORTANT MUST ATTENTION** close with ONE opinionated recommendation + trade-offs (Phase 6) — never a flat menu of options — why: a menu pushes the decision back on the team and invites HiPPO bias. - **MANDATORY IMPORTANT MUST ATTENTION** use a direct user question for all user decisions and handoff routing (`$idea`, `$refine`, `$plan`) — never auto-decide — why: the user owns scenario, prioritization, and next-step choices. **Anti-Rationalization:** | Evasion | Rebuttal | | ----------------------------------------------- | --------------------------------------------------------------------------------------------- | | "Scenario is obvious, skip Phase 0 detection" | Misclassified scenario routes the wrong technique sequence. Run a direct user question first. | | "Just list the ideas, evaluation can wait" | A flat idea list is the deliverable failure. Score, rank, and hypothesis-test the top 3. | | "Skip the RAT — the idea is clearly good" | "Clearly good" is HiPPO bias. Design the cheapest test before any build commitment. | | "Diverge and converge together to save time" | Mixing modes kills creative output — the Golden Rule violation. Keep phases separate. | | "RICE without Confidence is close enough" | No Confidence multiplier over-ranks low-evidence ideas. Always score Confidence. | | "Already know the domain, skip context loading" | Show `docs/specs/` read or `WebSearch` evidence. No proof = ungrounded ideation. | **MUST ATTENTION** Phase 0 scenario detection FIRST · diverge/converge strictly separated · every top-3 idea carries a hypothesis + RAT + cheapest test — these three survive long sessions; re-anchor to them before recommending. ## Hookless Prompt Protocol Mirror (Auto-Synced) Source: `.claude/.ck.json` + `.claude/skills/shared/sync-inline-versions.md` (`:full` blocks) + `.claude/scripts/lib/hookless-prompt-protocol.cjs` ## [WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] Workflow Execution Protocol — MANDATORY IMPORTANT MUST CRITICAL. Do not skip for any reason. **Generic portability boundary:** Reusable skills and protocol text stay project-neutral; project-specific conventions are discovered from docs/project-config.json and docs/project-reference/. Apply shared AI-SDD from `shared/sdd-artifact-contract.md`. Read `docs/project-config.json` and `docs/project-reference/docs-index-reference.md`, then open the project reference docs named there. For spec, test-case, behavior-change, public-contract, or `docs/specs/` work, route through the local spec docs named by the docs index: `feature-spec-reference.md`, `spec-system-reference.md`, `spec-principles.md`, and `workflow-spec-test-code-cycle-reference.md` when specs/tests/code must stay synchronized. If either file or a required reference doc is missing or stale, auto-run `$project-init` (or the narrow lower-level route such as `$project-config`, `$docs-init`, `$scan-all`, or `$scan --target=`) before ordinary project-specific work. Any supported AI tool may execute when this shared context and local docs are available. 1. **DETECT:** If the prompt starts with an explicit slash skill/workflow command, execute it directly. Otherwise match the prompt against the workflow catalog and skill list. 2. **ANALYZE:** Choose the best option: execute directly, invoke a skill, activate a standard workflow, or compose a custom step combination. 3. **AUTO-SELECT:** Pick the best option yourself. Do not ask the user to choose between direct execution, skill, standard workflow, or custom workflow. 4. **ACTIVATE:** For a selected workflow, call `$start-workflow `; for a selected skill, invoke that skill; for a custom workflow, sequence custom steps directly; for direct execution, proceed with the task. 5. **CREATE TASKS:** task tracking for ALL workflow/skill/custom steps before execution when the selected path has multiple steps. 6. **EXECUTE:** Advance per the **Workflow Step Advancement & Parallel Phases** rule in your context instructions — model-driven; a sub-agent completion advances a step identically to an inline call; a parallel-phase group is an all-return barrier (advance only after ALL members return, never serialize it) ## Shared AI-SDD Protocol Markers Source: `.claude/skills/shared/sync-inline-versions.md` ## SYNC:ai-sdd-artifact-contract > **AI-SDD Artifact Contract** — Shared spec-driven development rules stay portable and source-owned. > > 1. Keep reusable AI-SDD principles in `.claude`; put repository-specific paths, commands, owners, products, and formats in project config/reference docs. > 2. Preserve cycle: `spec -> plan -> tasks -> implement -> verify -> update spec/docs`. > 3. Trace every requirement or invariant through decision, task, TC/test, source evidence, and docs/spec update. > 4. Treat code-to-spec extraction as reference-only until accepted by the canonical spec owner. > 5. Any supported AI tool may plan, implement, review, or verify with synced context; using multiple tools is optional. > 6. Update `.claude` source first, then sync generated mirrors; do not manually edit `.agents`, `.codex`, or `AGENTS.md`. — why: mirrors are generated artifacts; hand-edits are overwritten on the next sync > 7. If `docs/project-config.json`, root instruction files, or a required project-reference doc is missing or stale, auto-run `$project-init` or the narrow lower-level route before ordinary project-specific work. > > **Active reference:** `shared/sdd-artifact-contract.md` in the active skills root. --- ## SYNC:ai-sdd-artifact-contract:reminder - **MANDATORY** Apply `shared/sdd-artifact-contract.md`; keep reusable AI-SDD in `.claude` and local rules in project docs. - **MANDATORY** Code-to-spec extraction is reference-only until canonical acceptance; any supported AI tool may execute with synced context. - **MANDATORY** Update `.claude` source before syncing generated mirrors; do not manually edit `.agents`, `.codex`, or `AGENTS.md`. - **MANDATORY** Missing or stale project config, root instruction files, or required reference docs route project-specific work through `$project-init` or the narrow setup route automatically. **[TASK-PLANNING] [MANDATORY]** BEFORE executing any workflow or skill step, create/update task tracking for all planned steps, then keep it synchronized as each step starts/completes. ## [LESSON-LEARNED-REMINDER] [BLOCKING] Task Planning & Continuous Improvement — MANDATORY. Do not skip. Break work into small tasks (task tracking) before starting. Add final task: "Analyze AI mistakes & lessons learned". **Extract lessons — ROOT CAUSE ONLY, not symptom fixes:** 1. Name the FAILURE MODE (reasoning/assumption failure), not symptom — "assumed API existed without reading source" not "used wrong enum value". 2. Generality test: does this failure mode apply to ≥3 contexts/codebases? If not, abstract one level up. 3. Write as a universal rule — strip project-specific names/paths/classes. Useful on any codebase. 4. Consolidate: multiple mistakes sharing one failure mode → ONE lesson. 5. **Recurrence gate:** "Would this recur in future session WITHOUT this reminder?" — No → skip `$learn`. 6. **Auto-fix gate:** "Could `$code-review`/`$code-simplifier`/`$security-review`/`$lint` catch this?" — Yes → improve review skill instead. 7. BOTH gates pass → ask user to run `$learn`. **[CRITICAL-THINKING-MINDSET]** Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence >80% to act. **Anti-hallucination principle:** Never present guess as fact — cite sources for every claim, admit uncertainty freely, self-check output for errors, cross-reference independently, stay skeptical of own confidence — certainty without evidence root of all hallucination. **AI Attention principle (Primacy-Recency):** Put the 3 most critical rules at both top and bottom of long prompts/protocols so instruction adherence survives long context windows. **Goal-driven execution:** Define success criteria first, loop until verified, and stop only when observable checks pass. **Tests verify intent:** Tests must protect business rules/invariants and fail when the protected intent breaks, not only mirror current behavior. ## Common AI Mistake Prevention (System Lessons) - **Re-read files after context compaction.** Edit requires prior Read in same context; compaction wipes read state. Re-read before editing. - **Grep for old terms after bulk replacements.** AI over-trusts find/replace completeness. Grep full repo after bulk edits for missed refs in docs/configs/catalogs. - **Check downstream references before deleting.** Deletions cascade doc/code staleness. Map referencing files before removal. - **After memory loss, check existing state before creating new.** Compaction wipes prior-work memory. Query current state to resume — never blindly duplicate. - **Verify AI-generated content against actual code.** AI hallucinates APIs, class names, method signatures. Grep to confirm existence before documenting/referencing. - **Trace full dependency chain after edits.** Changing a definition misses downstream consumers. Trace the full chain. - **When renaming, grep ALL consumer file types.** Some file types silently ignore missing refs (no compile error). Search code, templates, configs, generated files. - **Trace ALL code paths when verifying correctness.** Code existing ≠ code executing. Trace early exits, error branches, conditional skips — not just happy path. - **Update docs that embed canonical data when source changes.** Docs inlining derived data (workflows, schemas, configs) go stale silently. Update all embedding docs alongside source. - **Verify sub-agent results after context recovery.** Background agents may finish while parent compacted — grep-verify output, don't trust assumed completion. - **Cross-check full target list against sub-agent assignments.** Parallel sub-agents by category miss boundary items. Reconcile union of assignments against target list before proceeding. - **Sub-agents inherit knowledge only from their agent .md definition — use custom agent types, not built-in Explore.** Tool adoption = permission + knowledge + enforcement (numbered workflow step). - **Persist sub-agent findings incrementally, not as a final batch.** Long sub-agents hit cutoffs before final write — findings lost. Instruct append-per-section to report file. - **When debugging, ask "whose responsibility?" before fixing.** Trace caller (wrong data) vs callee (wrong handling). Fix at responsible layer — never patch symptom site. - **Grep ALL removed names after extraction/refactoring.** Primary file "done" ≠ secondary files clean. Grep entire scope for every removed symbol before declaring complete. - **Assume existing values are intentional — ask WHY before changing.** Pattern-matching as "wrong" skips context. Before changing any constant/limit/flag: read comments, git blame, surrounding code. - **Verify ALL affected outputs, not just the first.** One build green ≠ all green. Multi-stack changes (backend/frontend/tests/docs) require verifying EVERY output. - **Evaluate fit before copying a nearby pattern.** Closest example ≠ matching preconditions — verify the new context shares the same constraints, base classes, scope, lifetime. - **Holistic-first debugging — resist nearest-attention trap.** Don't dive into first plausible cause. List EVERY precondition (config, env vars, paths, DB, endpoints, creds, versions, DI, data). Verify each against evidence (grep/query — not reasoning). Ask "what would falsify this?" — if nothing, it's not a hypothesis. Most expensive failure: going deeper in "obvious" layer while bug sits in layer never questioned. - **Surgical changes — apply the diff test (context-aware).** Two modes: (1) Bug fix → every line traces to the bug; no restyling; orphan cleanup only for imports YOUR changes made unused. (2) Review/enhancement → implement improvements AND announce as "Enhancement beyond main request: [what]". Never silently scope-creep. Diff test: "Would this line exist if I wasn't asked to do X?" — if no, delete or announce. - **Surface ambiguity before coding — don't pick silently.** Multiple valid interpretations → present each with effort: "[Request] could mean (1) [N h], (2) [N h]. Which matters?" List scope/format/volume/constraints assumptions first. If simpler path exists, say so. Never silently pick. - **[MANDATORY FIRST ACTION] ALWAYS activate a suitable skill or workflow BEFORE responding.** Match task against workflow catalog + skill list; invoke via skill invocation or `$start-workflow `. NEVER answer or write code before checking. Skip = protocol violation. - **Why-Review adversarial mindset — apply when reviewing any plan, decision, or design.** Default SKEPTIC not VALIDATOR: steel-man a rejected alternative, invert each stated reason ("what does it sacrifice?"), stress-test top 2-3 assumptions, run pre-mortem ("ships, fails in 3 months — what breaks?"), surface 1-2 alternatives author missed. Section presence ≠ quality; quality = causal reasoning + concrete mitigations + evidence, not "it's better" or "monitor closely". - **Front-load report-write in sub-agent prompts for large reviews.** Many-file sub-agents hit budget before final write — findings lost. Design prompts so: (1) report-write is first explicit deliverable, (2) append per-file/section (not batched), (3) scope bounded so reads don't exhaust budget. Truncated mid-sentence with no report file → spawn narrower scope, don't retry same prompt. - **After context compaction, re-verify all prior phase outcomes before continuing.** Summaries describe intent, not environment state (git index, filesystem, processes). On resume, FIRST audit: git status, re-read modified files, verify filesystem. Every "completed" claim is an untested hypothesis until evidence confirms. - **OOM/memory: check row count before row size.** Triage: (1) Unbounded query — no DB filter for trigger? Push filter to DB; eliminates OOM. (2) Large rows? Projection reduces proportionally. Row reduction > projection in ROI. - **Keep domain concepts out of generic/shared/infrastructure layers.** Reusable layer (shared library, framework, infra module) must reference NO consumer-specific domain concept — tenant/customer/product IDs, business entities, feature rules. Leak compiles + runs → passes review silently while coupling the "reusable" layer to one consumer. Keep shared type domain-free; push domain fields/logic down into the consumer via subclass/composition. — why: a layer coupled to one consumer's domain is no longer reusable. [View on SkillFed](https://skillfed.io/duc01226/EasyPlatform/brainstorm) · [View on GitHub](https://github.com/duc01226/EasyPlatform)