Add proactive assumption challenging to brainstorming skill#541
Add proactive assumption challenging to brainstorming skill#541thakoreh wants to merge 1 commit into
Conversation
Before accepting a user's feature request framing, the brainstorming skill should challenge product assumptions like a senior PM would. Changes: - Add 'Challenge product assumptions' step after exploring context - Add challenge questions section with examples - Update process flow diagram to include new step - Update checklist to include the new step This ensures AI assistants don't accept user framing uncritically and surface better product decisions early when the cost of wrong assumptions is highest. Fixes: obra#530
📝 WalkthroughWalkthroughThe brainstorming skill's planning workflow is enhanced by introducing a new "Challenge product assumptions" step positioned between "Explore project context" and "Ask clarifying questions." The process flow diagram is updated accordingly, and detailed guidance is added explaining how to challenge assumptions with example questions and scenarios before proceeding with design work. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
skills/brainstorming/SKILL.md (1)
12-12: Align the overview and “Understanding the idea” bullets with the new challenge step.The overview and the “Understanding the idea” bullets still read as if clarifying questions come immediately after context, which contradicts the newly inserted “Challenge product assumptions” step. Consider updating those lines to explicitly mention the challenge step before clarifying questions.
✏️ Suggested text update
-Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval. +Start by understanding the current project context, then challenge product assumptions before asking clarifying questions one at a time. Once you understand what you're building, present the design and get user approval.-**Understanding the idea:** -- Check out the current project state first (files, docs, recent commits) -- Ask questions one at a time to refine the idea +**Understanding the idea:** +- Check out the current project state first (files, docs, recent commits) +- Challenge product assumptions before clarifying +- Ask questions one at a time to refine the ideaAlso applies to: 84-90
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@skills/brainstorming/SKILL.md` at line 12, Update the SKILL.md bullets so the Overview and the "Understanding the idea" section explicitly mention and sequence the new "Challenge product assumptions" step before asking clarifying questions; locate the Overview heading and the "Understanding the idea" bullet list and insert or reword to: first contextualize the project, then perform the "Challenge product assumptions" step (call out that you should critique constraints and propose alternatives), and only after that proceed to ask clarifying questions one at a time and present the design for approval—apply the same change to the duplicate content around lines referenced as also applies to: 84-90.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@skills/brainstorming/SKILL.md`:
- Line 12: Update the SKILL.md bullets so the Overview and the "Understanding
the idea" section explicitly mention and sequence the new "Challenge product
assumptions" step before asking clarifying questions; locate the Overview
heading and the "Understanding the idea" bullet list and insert or reword to:
first contextualize the project, then perform the "Challenge product
assumptions" step (call out that you should critique constraints and propose
alternatives), and only after that proceed to ask clarifying questions one at a
time and present the design for approval—apply the same change to the duplicate
content around lines referenced as also applies to: 84-90.
Add a new step between exploring project context and asking clarifying questions that challenges the framing of the request before accepting it. Mirrors what a senior PM or founding product designer would do — push back on embedded assumptions early to save implementation effort. Implements obra/superpowers#530 via PR #541. Co-Authored-By: Claude <noreply@anthropic.com>
Add a new step between exploring project context and asking clarifying questions that challenges the framing of the request before accepting it. Mirrors what a senior PM or founding product designer would do — push back on embedded assumptions early to save implementation effort. Implements obra/superpowers#530 via PR #541. Co-authored-by: Claude <noreply@anthropic.com>
…n challenging Add structured composing-teams decision framework (4+ tasks AND 2+ independent AND 2+ specialist domains) replacing vibes-based trigger. Add assumption challenging step before clarifying questions. Add research step (search for existing solutions before designing). Fix design doc path to directory-based docs/plans/<project>/design.md. Add state.yml writes (phase, design.path, design.approved). Mark design.md as immutable for downstream skills. Add explicit user gate: design approval checkpoint before any plan invocation is now structurally enforced via HARD-GATE + checklist order. Rewrite process steps with numbered stages for clarity. Addresses obra#565, obra#574, obra#530, obra#107, PR obra#541, PR obra#386, Findings D, G, H, J. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…n challenging Add structured composing-teams decision framework (4+ tasks AND 2+ independent AND 2+ specialist domains) replacing vibes-based trigger. Add assumption challenging step before clarifying questions. Add research step (search for existing solutions before designing). Fix design doc path to directory-based docs/plans/<project>/design.md. Add state.yml writes (phase, design.path, design.approved). Mark design.md as immutable for downstream skills. Add explicit user gate: design approval checkpoint before any plan invocation is now structurally enforced via HARD-GATE + checklist order. Rewrite process steps with numbered stages for clarity. Addresses obra#565, obra#574, obra#530, obra#107, PR obra#541, PR obra#386, Findings D, G, H, J. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Thanks for this! Challenging assumptions is a good instinct. v5.0.0 added scope assessment to brainstorming — it now catches oversized projects and decomposes them into sub-projects before speccing. That covers the most impactful case of assumption-challenging (building the wrong-sized thing). Closing as the brainstorming skill was substantially reworked in v5. — Claude (claude-opus-4-6, Claude Code 2.1.71, session 64908a66-5c98-4c79-b0f7-1aa7eac2dcb0) |
…n challenging Add structured composing-teams decision framework (4+ tasks AND 2+ independent AND 2+ specialist domains) replacing vibes-based trigger. Add assumption challenging step before clarifying questions. Add research step (search for existing solutions before designing). Fix design doc path to directory-based docs/plans/<project>/design.md. Add state.yml writes (phase, design.path, design.approved). Mark design.md as immutable for downstream skills. Add explicit user gate: design approval checkpoint before any plan invocation is now structurally enforced via HARD-GATE + checklist order. Rewrite process steps with numbered stages for clarity. Addresses obra#565, obra#574, obra#530, obra#107, PR obra#541, PR obra#386, Findings D, G, H, J. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Description
Fixes #530 - Brainstorming skill should proactively challenge product assumptions
Problem
During product brainstorming sessions, the skill explores requirements and design well, but does not proactively challenge the assumptions embedded in the user's request. AI assistants tend to accept user framing and jump to implementation, missing opportunities to surface better product decisions early.
Solution
Added a new step "Challenge product assumptions" that runs after exploring project context and before asking clarifying questions. This mirrors what a founding product designer or senior PM would do naturally.
Changes
Example Challenge Questions
Motivation
The cost of a wrong assumption is highest before any code is written. Challenging assumptions early saves implementation effort and surfaces better product decisions.