rogee/superpowers
1
0
Fork 0
mirror of https://github.com/obra/superpowers.git synced 2026-04-25 11:09:05 +08:00
Code Issues Packages Projects Releases Wiki Activity

feat: add mode-switching and amplifier-inspired skills

Browse Source 
**Mode-switching enhancements:**
- Update brainstorming skill with flexible UNDERSTANDING/EXPLORING/DESIGNING modes
- Update executing-plans skill with REVIEWING/EXECUTING/BLOCKED/REPORTING modes
- Add inline dot diagrams with full contextual labels for all valid transitions
- Enforce explicit mode switch announcements

**New architecture skills from amplifier patterns:**
- preserving-productive-tensions: Recognize when to preserve multiple valid approaches vs force resolution
- tracing-knowledge-lineages: Understand idea evolution to avoid repeating failures
- detecting-emergent-patterns: Cross-domain synthesis, collision-zone thinking, simplification cascades

All skills pressure-tested with subagents using RED-GREEN-REFACTOR methodology.
This commit is contained in:
Jesse Vincent
2025-10-10 11:58:54 -07:00
parent dee324d417
commit dedae3a786
5 changed files with 688 additions and 62 deletions
Download Patch File Download Diff File Expand all files Collapse all files

85
skills/collaboration/brainstorming/SKILL.md
View File

@@ -1,56 +1,87 @@
---
name: Brainstorming Ideas Into Designs
description: Interactive idea refinement using Socratic method to develop fully-formed designs
when_to_use: When your human partner says "I've got an idea", "Let's make/build/create", "I want to implement/add", "What if we". When starting design for complex feature. Before writing implementation plans. When idea needs refinement and exploration. ACTIVATE THIS AUTOMATICALLY when your human partner describes a feature or project idea - don't wait for /brainstorm command.
version: 2.0.0
description: Interactive idea refinement using mode-switching between understanding, exploring, and designing based on current needs
when_to_use: When your human partner says "I've got an idea", "Let's make/build/create", "I want to implement/add", "What if we". When starting design for complex feature. Before writing implementation plans. When idea needs refinement and exploration. When new constraints emerge during design. ACTIVATE THIS AUTOMATICALLY when your human partner describes a feature or project idea - don't wait for /brainstorm command.
version: 3.0.0
---
# Brainstorming Ideas Into Designs
## Overview
Transform rough ideas into fully-formed designs through structured questioning and alternative exploration.
Transform rough ideas into fully-formed designs through flexible mode-switching based on what's needed NOW, not rigid phase progression.
**Core principle:** Ask questions to understand, explore alternatives, present design incrementally for validation.
**Core principle:** Switch between operational modes (UNDERSTANDING, EXPLORING, DESIGNING) based on current needs. New constraints? Switch to UNDERSTANDING. Need alternatives? Switch to EXPLORING. Ready for details? Switch to DESIGNING.
**Announce at start:** "I'm using the Brainstorming skill to refine your idea into a design."
## The Process
## Operating Modes
### Phase 1: Understanding
- Check current project state in working directory
- Ask ONE question at a time to refine the idea
- Prefer multiple choice when possible
- Gather: Purpose, constraints, success criteria
```dot
digraph brainstorming_modes {
rankdir=LR;
node [shape=box, style=rounded];
### Phase 2: Exploration
- Propose 2-3 different approaches (reference skills/coding/exploring-alternatives)
- For each: Core architecture, trade-offs, complexity assessment
- Ask your human partner which approach resonates
UNDERSTANDING [label="UNDERSTANDING Mode\n\nAsk ONE question at a time\nGather: purpose, constraints, success criteria\nApply YAGNI ruthlessly"];
### Phase 3: Design Presentation
- Present in 200-300 word sections
- Cover: Architecture, components, data flow, error handling, testing
- Ask after each section: "Does this look right so far?"
EXPLORING [label="EXPLORING Mode\n\nPropose 2-3 different approaches\nFor each: architecture, trade-offs, complexity\nAsk which approach resonates"];
### Phase 4: Worktree Setup (for implementation)
DESIGNING [label="DESIGNING Mode\n\nPresent in 200-300 word sections\nCover: architecture, components, data flow\nAsk 'Does this look right?' after each section"];
UNDERSTANDING -> EXPLORING [label="Have enough context to propose alternatives\n(gathered purpose, constraints, success criteria)"];
EXPLORING -> UNDERSTANDING [label="New constraints emerge\n(compliance, infrastructure, security, 'Oh I forgot to mention...')"];
EXPLORING -> DESIGNING [label="Approach selected and validated\n(partner chose an approach, have all critical constraints)"];
DESIGNING -> UNDERSTANDING [label="Fundamental gaps revealed during validation\n(missing constraints, assumptions questioned)"];
DESIGNING -> EXPLORING [label="Need to compare alternatives\n(trade-offs significant, partner asks 'what are the options?')"];
}
```
## Mode Switching Rules
**YOU MUST announce every mode switch:** "Switching to [MODE] mode because [reason]"
**No exceptions:**
- Not "I need to understand..." (switching without announcing)
- Not implied switches (acting in new mode without announcement)
- Every mode change requires explicit announcement
## Red Flags - You're Forcing Forward
- New constraint emerges but you continue current mode
- "I'll incorporate this into the current approach" (without re-evaluating)
- Partner says "wait, there's also..." but you don't switch to UNDERSTANDING
- Designing without all critical constraints
- Exploring alternatives with incomplete requirements
- Switching modes without announcing the switch
**All of these mean: STOP. Switch to appropriate mode (and announce it).**
## After Design Validation
### Worktree Setup (for implementation)
When design is approved and implementation will follow:
- Announce: "I'm using the Using Git Worktrees skill to set up an isolated workspace."
- Switch to skills/collaboration/using-git-worktrees
- Follow that skill's process for directory selection, safety verification, and setup
- Return here when worktree ready
### Phase 5: Planning Handoff
### Planning Handoff
Ask: "Ready to create the implementation plan?"
When your human partner confirms (any affirmative response):
When your partner confirms (any affirmative response):
- Announce: "I'm using the Writing Plans skill to create the implementation plan."
- Switch to skills/collaboration/writing-plans skill
- Create detailed plan in the worktree
## Remember
- One question per message during Phase 1
- Apply YAGNI ruthlessly (reference skills/architecture/reducing-complexity)
- Explore 2-3 alternatives before settling
- Present incrementally, validate as you go
- Announce skill usage at start
- Modes are operational stances, not linear phases
- You can move freely: UNDERSTANDING ↔ EXPLORING ↔ DESIGNING
- Always announce mode switches
- One question per message in UNDERSTANDING mode
- Present design incrementally in DESIGNING mode
- New constraints ALWAYS trigger return to UNDERSTANDING

94
skills/collaboration/executing-plans/SKILL.md
View File

@@ -1,59 +1,83 @@
---
name: Executing Plans
description: Execute detailed plans in batches with review checkpoints
when_to_use: When have a complete implementation plan to execute. When implementing in separate session from planning. When your human partner points you to a plan file to implement.
version: 2.0.0
description: Execute detailed plans with mode-switching for review, execution, and handling blockers
when_to_use: When have a complete implementation plan to execute. When implementing in separate session from planning. When your human partner points you to a plan file to implement. When hit a blocker during execution. When plan needs re-review after updates.
version: 3.0.0
---
# Executing Plans
## Overview
Load plan, review critically, execute tasks in batches, report for review between batches.
Execute implementation plans by switching between reviewing, executing, and handling blockers based on current needs.
**Core principle:** Batch execution with checkpoints for architect review.
**Core principle:** Review critically, execute in batches, stop when blocked, report at checkpoints.
**Announce at start:** "I'm using the Executing Plans skill to implement this plan."
## The Process
## Operating Modes
### Step 1: Load and Review Plan
1. Read plan file
2. Review critically - identify any questions or concerns about the plan
3. If concerns: Raise them with your human partner before starting
4. If no concerns: Create TodoWrite and proceed
```dot
digraph executing_modes {
rankdir=LR;
node [shape=box, style=rounded];
### Step 2: Execute Batch
**Default: First 3 tasks**
REVIEWING [label="REVIEWING Mode\n\nRead plan critically\nIdentify concerns/questions/gaps\nCreate TodoWrite if plan is sound"];
For each task:
1. Mark as in_progress
2. Follow each step exactly (plan has bite-sized steps)
3. Run verifications as specified
4. Mark as completed
EXECUTING [label="EXECUTING Mode\n\nWork through batch (default 3 tasks)\nFollow each step exactly\nRun all verifications\nMark tasks completed"];
### Step 3: Report
When batch complete:
- Show what was implemented
- Show verification output
- Say: "Ready for feedback."
BLOCKED [label="BLOCKED Mode\n\nStop execution immediately\nIdentify specific blocker\nAsk for clarification/help"];
### Step 4: Continue
Based on feedback:
- Apply changes if needed
- Execute next batch
- Repeat until complete
REPORTING [label="REPORTING Mode\n\nShow what was implemented\nShow verification output\nSay 'Ready for feedback'"];
### Step 5: Complete Development
REVIEWING -> EXECUTING [label="Plan is sound, no concerns\n(created TodoWrite, ready to start first batch)"];
After all tasks complete and verified:
REVIEWING -> BLOCKED [label="Plan has issues that prevent starting\n(missing info, unclear instructions, dependencies)"];
EXECUTING -> BLOCKED [label="Hit a blocker mid-batch\n(missing dependency, test fails, unclear instruction)"];
EXECUTING -> REPORTING [label="Batch completed successfully\n(all tasks done, verifications pass)"];
BLOCKED -> REVIEWING [label="Blocker resolved with plan update\n(partner updated plan, need to re-review changes)"];
BLOCKED -> EXECUTING [label="Blocker resolved, can continue\n(got clarification, continue current batch)"];
REPORTING -> EXECUTING [label="Feedback received, continue\n(no fundamental issues, execute next batch)"];
REPORTING -> REVIEWING [label="Feedback requires plan changes\n(approach needs rethinking, plan being updated)"];
}
```
## Mode Switching Rules
**YOU MUST announce every mode switch:** "Switching to [MODE] mode because [reason]"
**No exceptions:**
- Not silent switches
- Not implied mode changes
- Every switch requires explicit announcement
## Red Flags - You're Forcing Through
- Hit a blocker but continue executing anyway
- Plan has concerns but you start executing
- Tests fail but you mark task completed
- Unclear instruction but you guess instead of asking
- Partner updating plan but you don't switch to REVIEWING
**All of these mean: STOP. Switch to appropriate mode (and announce it).**
## After All Tasks Complete
When all tasks are done and verified:
- Announce: "I'm using the Finishing a Development Branch skill to complete this work."
- Switch to skills/collaboration/finishing-a-development-branch
- Follow that skill to verify tests, present options, execute choice
## Remember
- Review plan critically first
- Follow plan steps exactly
- Don't skip verifications
- Reference skills when plan says to
- Between batches: just report and wait
- Modes are operational stances, not rigid steps
- You can switch freely based on what's needed
- Always announce mode switches
- Blockers require immediate BLOCKED mode
- Never force through when stuck