Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Project scope is well-defined (jump to /attune:project-init)
Mid-project pivots (use Skill(attune:war-room) for strategic decisions)
Integration
With superpowers:
Delegates to Skill(superpowers:brainstorming) for Socratic method
Augments with project-specific patterns
Uses project brainstorm templates
Without superpowers:
Standalone questioning framework
Project-focused ideation patterns
Structured output templates
War Room Integration (REQUIRED):
After Phase 3 (Approach Generation), automatically invokes Skill(attune:war-room)
All brainstorming context passed to War Room for expert deliberation
War Room provides multi-LLM pressure testing and synthesis
Only bypassed for Type 2 decisions (RS ≤ 0.40) with explicit user confirmation
Brainstorming Framework
Phase 1: Problem Definition
Socratic Questions:
What problem are you solving?
Who experiences this problem?
What makes this problem worth solving now?
What happens if this problem isn't solved?
What existing solutions have been tried?
Output: Problem statement in docs/project-brief.md
Template:
## Problem Statement**Who**: [Target users/stakeholders]
**What**: [The problem they face]
**Where**: [Context where problem occurs]
**When**: [Frequency/timing of problem]
: [Impact of the problem]
: [Existing solutions and limitations]
**Why**
**Current State**
Verification: Run the command with --help flag to verify availability.
Phase 2: Constraint Discovery
Questions:
What are non-negotiable technical constraints?
What are resource constraints (time, budget, team)?
What integration points are required?
What compliance/regulatory requirements apply?
What are success criteria and failure modes?
Output: Constraints matrix
Template:
## Constraints### Technical- [Constraint 1 with rationale]
- [Constraint 2 with rationale]
### Resources-**Timeline**: [Duration with milestones]
-**Team**: [Size and skills]
-**Budget**: [If applicable]
### Integration- [Required system 1]
- [Required system 2]
### Compliance- [Requirement 1]
- [Requirement 2]
### Success Criteria- [ ] [Measurable criterion 1]
- [ ] [Measurable criterion 2]
Verification: Run the command with --help flag to verify availability.
Phase 3: Approach Generation
Technique: Generate 3-5 distinct approaches
For each approach:
Clear description (1-2 sentences)
Technology stack
Pros (3-5 points)
Cons (3-5 points)
Risks (2-3 points)
Estimated effort
Trade-offs
Template:
## Approach [N]: [Name]**Description**: [Clear 1-2 sentence description]
**Stack**: [Technologies and tools]
**Pros**:
- [Advantage 1]
- [Advantage 2]
- [Advantage 3]
**Cons**:
- [Disadvantage 1]
- [Disadvantage 2]
- [Disadvantage 3]
**Risks**:
- [Risk 1 with likelihood]
- [Risk 2 with likelihood]
**Effort**: [S/M/L/XL or time estimate]
**Trade-offs**:
- [Trade-off 1 with mitigation]
- [Trade-off 2 with mitigation]
Verification: Run the command with --help flag to verify availability.
Design for Isolation:
When generating approaches, evaluate each against two
isolation tests:
Comprehension test: Can someone understand what
each unit does without reading its internals? If a
unit requires reading implementation details to
understand its purpose, the boundary is wrong.
Change test: Can you change a unit's internals
without breaking its consumers? If changing
implementation details forces changes elsewhere,
the interface is leaking.
File size as design signal: Files exceeding 500 lines
(Python/Go) or 300 lines (JavaScript/TypeScript) often
indicate a unit is doing too much. This is a design
smell, not just a style issue. When flagging large files,
suggest extracting specific concerns (e.g., "Extract
validation logic into a separate module to improve
testability").
Verification: Run the command with --help flag to verify availability.
Phase 3.5: War Room Deliberation (REQUIRED)
Automatic Trigger: After generating approaches, MUST invoke Skill(attune:war-room) for expert deliberation
When War Room is invoked:
All brainstorming context (problem, constraints, approaches) automatically passed to War Room
Expert panel reviews, challenges, and pressures each approach
Reversibility assessment conducted
Multi-LLM deliberation identifies blind spots
Supreme Commander provides synthesis with rationale
Command:
# Automatically invoked from brainstorm - DO NOT SKIP
/attune:war-room --from-brainstorm
War Room Output:
Reversibility Score (RS) and decision type
Red Team challenges for each approach
Premortem analysis on selected approach
Supreme Commander Decision document
Implementation orders and watch points
Bypass Conditions (ONLY skip war room if ALL true):
RS ≤ 0.40 (Type 2 decision - clearly reversible)
Single obvious approach with no meaningful trade-offs
Low complexity with well-documented pattern
User explicitly declines after being shown RS assessment
Verification: Run the command with --help flag to verify availability.
Phase 5.5: Record the Tradeoff (decision journal)
Persist the Phase 5 selection to docs/tradeoffs.md now, while the reasoning
is live. This is the entry that survives past the session: the decision, the
alternatives weighed, and what was given up. Draft and confirm:
If leyline is installed, invoke Skill(leyline:decision-journal) and follow
it to append a tradeoff entry. The Phase 5 fields map directly: Selected
Approach to decision, the rationale to a Y-statement, Trade-offs Accepted
to consequences_negative, and Rejected Approaches to options. Set
phase to brainstorm. Show the drafted entry; append on user confirmation
(status starts proposed).
Fallback (leyline absent): append an entry to docs/tradeoffs.md by hand
using the in-file ENTRY TEMPLATE; assign the next TR-NNN id and add an
active-index row.
Skip only when there was genuinely one obvious approach with no meaningful
trade-off (the same condition that bypasses War Room).
Output: Project Brief
Final output saved to docs/project-brief.md:
# [Project Name] - Project Brief**Date**: [YYYY-MM-DD]
**Author**: [Name]
**Status**: Draft | Approved
## Problem Statement
[From Phase 1]
## Goals1. [Primary goal]
2. [Secondary goal]
3. [Tertiary goal]
## Constraints
[From Phase 2]
## Approach Comparison
[From Phase 3 & 4]
## War Room Decision
[From Phase 3.5 - includes RS assessment, Red Team challenges, premortem]
## Selected Approach
[From Phase 5, informed by War Room synthesis]
## Next Steps1.`/attune:specify` - Create detailed specification
2.`/attune:blueprint` - Plan architecture and tasks
3.`/attune:project-init` - Initialize project structure
Verification: Run the command with --help flag to verify availability.
Questioning Patterns
Socratic Method
Clarification:
"What do you mean by [term]?"
"Can you give an example?"
"What is the difference between X and Y?"
Probing Assumptions:
"What are you assuming about [aspect]?"
"Why do you think that assumption is valid?"
"What if that assumption is wrong?"
Probing Reasoning:
"Why do you think this approach is best?"
"What evidence supports this?"
"Are there alternative explanations?"
Questioning Viewpoints:
"What would [stakeholder] think about this?"
"What are the counterarguments?"
"How might this fail?"
Probing Implications:
"What happens if we choose this approach?"
"What are the long-term consequences?"
"What does this commit us to?"
Constraint-Based Thinking
Must Have (Non-negotiable):
What absolutely must be true for success?
What constraints cannot be changed?
Should Have (Important):
What would significantly increase success?
What preferences matter most?
Could Have (Nice to have):
What would be beneficial but not critical?
What can we defer or drop if needed?
Won't Have (Explicit exclusions):
What are we explicitly NOT doing?
What scope boundaries prevent creep?
Red Flags to Surface
During brainstorming, watch for:
⚠️ Vague problem statements ("make it better")
⚠️ Unclear success criteria
⚠️ Hidden assumptions about users or technology
⚠️ Single approach bias (not exploring alternatives)
