specsmd 0.0.0-dev.84 → 0.0.0-dev.86
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/flows/fire/agents/builder/skills/walkthrough-generate/SKILL.md +30 -27
- package/flows/ideation/agents/orchestrator/agent.md +8 -7
- package/flows/ideation/agents/orchestrator/skills/flame/SKILL.md +1 -0
- package/flows/ideation/agents/orchestrator/skills/flame/references/evaluation-criteria.md +4 -0
- package/flows/ideation/agents/orchestrator/skills/flame/references/six-hats-method.md +12 -0
- package/flows/ideation/agents/orchestrator/skills/forge/SKILL.md +1 -0
- package/flows/ideation/agents/orchestrator/skills/forge/references/disney-method.md +8 -0
- package/flows/ideation/agents/orchestrator/skills/forge/references/pitch-framework.md +15 -0
- package/flows/ideation/agents/orchestrator/skills/spark/SKILL.md +3 -1
- package/flows/ideation/agents/orchestrator/skills/spark/references/techniques/analogy.md +7 -0
- package/flows/ideation/agents/orchestrator/skills/spark/references/techniques/first-principles.md +5 -0
- package/flows/ideation/agents/orchestrator/skills/spark/references/techniques/inversion.md +6 -0
- package/flows/ideation/agents/orchestrator/skills/spark/references/techniques/questorming.md +6 -0
- package/flows/ideation/agents/orchestrator/skills/spark/references/techniques/random-word.md +1 -0
- package/flows/ideation/agents/orchestrator/skills/spark/references/techniques/scamper.md +15 -0
- package/flows/ideation/agents/orchestrator/skills/spark/references/techniques/what-if.md +6 -0
- package/flows/ideation/shared/protocols/anti-bias.md +7 -4
- package/flows/ideation/shared/protocols/deep-thinking.md +7 -0
- package/flows/ideation/shared/protocols/diverge-converge.md +2 -0
- package/flows/ideation/shared/protocols/interaction-adaptation.md +7 -0
- package/package.json +1 -1
|
@@ -115,7 +115,7 @@ Generate implementation walkthrough for human review after run completion.
|
|
|
115
115
|
<output_template>
|
|
116
116
|
**Walkthrough** (`.specs-fire/runs/{run-id}/walkthrough.md`):
|
|
117
117
|
|
|
118
|
-
|
|
118
|
+
````markdown
|
|
119
119
|
---
|
|
120
120
|
run: {run-id}
|
|
121
121
|
work_item: {work-item-id}
|
|
@@ -152,97 +152,100 @@ Generate implementation walkthrough for human review after run completion.
|
|
|
152
152
|
└─────────────────────────────┘
|
|
153
153
|
```
|
|
154
154
|
|
|
155
|
-
|
|
155
|
+
## Files Changed
|
|
156
156
|
|
|
157
|
-
|
|
157
|
+
### Created
|
|
158
158
|
|
|
159
159
|
| File | Purpose |
|
|
160
160
|
|------|---------|
|
|
161
161
|
| `{path}` | {purpose} |
|
|
162
162
|
|
|
163
|
-
|
|
163
|
+
### Modified
|
|
164
164
|
|
|
165
165
|
| File | Changes |
|
|
166
166
|
|------|---------|
|
|
167
167
|
| `{path}` | {changes} |
|
|
168
168
|
|
|
169
|
-
|
|
169
|
+
## Domain Model (if entities created)
|
|
170
170
|
|
|
171
|
-
|
|
171
|
+
### Entities
|
|
172
172
|
|
|
173
173
|
| Entity | Properties | Business Rules |
|
|
174
174
|
|--------|------------|----------------|
|
|
175
175
|
| {name} | {props} | {rules} |
|
|
176
176
|
|
|
177
|
-
|
|
177
|
+
### Value Objects
|
|
178
178
|
|
|
179
179
|
| Value Object | Properties | Constraints |
|
|
180
180
|
|--------------|------------|-------------|
|
|
181
181
|
| {name} | {props} | {constraints} |
|
|
182
182
|
|
|
183
|
-
|
|
183
|
+
## Key Implementation Details
|
|
184
184
|
|
|
185
|
-
|
|
185
|
+
### 1. {Detail Title}
|
|
186
186
|
|
|
187
187
|
{description of implementation approach}
|
|
188
188
|
|
|
189
|
-
|
|
189
|
+
## Security Considerations (if applicable)
|
|
190
190
|
|
|
191
191
|
| Concern | Approach |
|
|
192
192
|
|---------|----------|
|
|
193
193
|
| {concern} | {approach} |
|
|
194
194
|
|
|
195
|
-
|
|
195
|
+
## Performance Considerations (if applicable)
|
|
196
196
|
|
|
197
197
|
| Requirement | Implementation |
|
|
198
198
|
|-------------|----------------|
|
|
199
199
|
| {requirement} | {implementation} |
|
|
200
200
|
|
|
201
|
-
|
|
201
|
+
## Decisions Made
|
|
202
202
|
|
|
203
203
|
| Decision | Choice | Rationale |
|
|
204
204
|
|----------|--------|-----------|
|
|
205
205
|
| {decision} | {choice} | {rationale} |
|
|
206
206
|
|
|
207
|
-
|
|
207
|
+
## Deviations from Plan
|
|
208
208
|
|
|
209
209
|
{Changes from work item plan and why, or "None"}
|
|
210
210
|
|
|
211
|
-
|
|
211
|
+
## Dependencies Added
|
|
212
212
|
|
|
213
213
|
| Package | Why Needed |
|
|
214
214
|
|---------|------------|
|
|
215
215
|
| `{package}` | {reason} |
|
|
216
216
|
|
|
217
|
-
|
|
217
|
+
## How to Verify
|
|
218
218
|
|
|
219
219
|
1. **{Step Title}**
|
|
220
|
+
|
|
220
221
|
```bash
|
|
221
222
|
{command}
|
|
222
223
|
```
|
|
224
|
+
|
|
223
225
|
Expected: {expected output}
|
|
224
226
|
|
|
225
|
-
|
|
227
|
+
## Test Coverage
|
|
226
228
|
|
|
227
|
-
|
|
228
|
-
|
|
229
|
-
|
|
229
|
+
- Tests added: {count}
|
|
230
|
+
- Coverage: {percentage}%
|
|
231
|
+
- Status: {passing/failing}
|
|
230
232
|
|
|
231
|
-
|
|
233
|
+
## Ready for Review
|
|
232
234
|
|
|
233
|
-
|
|
234
|
-
|
|
235
|
-
|
|
236
|
-
|
|
237
|
-
|
|
235
|
+
- [x] All acceptance criteria met
|
|
236
|
+
- [x] Tests passing
|
|
237
|
+
- [x] No critical issues
|
|
238
|
+
- [ ] Documentation updated (if applicable)
|
|
239
|
+
- [x] Developer notes captured
|
|
238
240
|
|
|
239
|
-
|
|
241
|
+
## Developer Notes
|
|
240
242
|
|
|
241
243
|
{Gotchas, tips, or context for future work - keep brief}
|
|
242
244
|
|
|
243
245
|
---
|
|
244
246
|
*Generated by specs.md - fabriqa.ai FIRE Flow Run {run-id}*
|
|
245
|
-
|
|
247
|
+
|
|
248
|
+
````
|
|
246
249
|
|
|
247
250
|
</output_template>
|
|
248
251
|
|
|
@@ -70,9 +70,9 @@ You are the **Ideation Orchestrator** for specsmd.
|
|
|
70
70
|
└── concept-briefs/ # Shaped concepts
|
|
71
71
|
```
|
|
72
72
|
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
73
|
+
- Create session on first Spark batch
|
|
74
|
+
- Update session.yaml at each phase transition
|
|
75
|
+
- Session ID format: `{topic-slug}-{YYYYMMDD}`
|
|
76
76
|
</session_management>
|
|
77
77
|
|
|
78
78
|
<flow_transitions>
|
|
@@ -83,10 +83,11 @@ You are the **Ideation Orchestrator** for specsmd.
|
|
|
83
83
|
```
|
|
84
84
|
|
|
85
85
|
Users can also:
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
86
|
+
|
|
87
|
+
- Skip Spark (bring their own ideas to Flame)
|
|
88
|
+
- Skip Flame (bring evaluated ideas to Forge)
|
|
89
|
+
- Loop back (Forge → more Spark to explore new angles)
|
|
90
|
+
- Use any skill standalone
|
|
90
91
|
</flow_transitions>
|
|
91
92
|
|
|
92
93
|
<success_criteria>
|
|
@@ -116,6 +116,7 @@ Evaluate ideas fairly through multiple perspectives. Surface hidden value, ident
|
|
|
116
116
|
</flow>
|
|
117
117
|
|
|
118
118
|
<output_artifacts>
|
|
119
|
+
|
|
119
120
|
| Artifact | Location | Template |
|
|
120
121
|
|----------|----------|----------|
|
|
121
122
|
| Flame Report | `.specs-ideation/sessions/{id}/flame-report.md` | `./templates/flame-report.md.hbs` |
|
|
@@ -53,7 +53,9 @@ The core evaluation matrix. Every idea gets scored on both axes.
|
|
|
53
53
|
## Secondary Criteria
|
|
54
54
|
|
|
55
55
|
### Novelty (1-5)
|
|
56
|
+
|
|
56
57
|
How original is this idea?
|
|
58
|
+
|
|
57
59
|
- 5: Never seen before — genuinely new
|
|
58
60
|
- 4: New in this context — adapted from elsewhere
|
|
59
61
|
- 3: Fresh take on existing concept
|
|
@@ -61,6 +63,7 @@ How original is this idea?
|
|
|
61
63
|
- 1: Already exists / obvious
|
|
62
64
|
|
|
63
65
|
### Risk Profile
|
|
66
|
+
|
|
64
67
|
- **Technical risk**: Can this be built?
|
|
65
68
|
- **Market risk**: Will anyone want this?
|
|
66
69
|
- **Adoption risk**: Will people change behavior for this?
|
|
@@ -69,6 +72,7 @@ How original is this idea?
|
|
|
69
72
|
## Aggregation
|
|
70
73
|
|
|
71
74
|
The Flame Report presents:
|
|
75
|
+
|
|
72
76
|
1. **Impact × Feasibility matrix** — visual positioning
|
|
73
77
|
2. **Six Hats summary** — qualitative analysis per idea
|
|
74
78
|
3. **User Red Hat** — gut feelings
|
|
@@ -5,6 +5,7 @@
|
|
|
5
5
|
## Core Concept
|
|
6
6
|
|
|
7
7
|
Instead of arguing different positions, everyone (or the AI) wears the same "hat" at the same time, exploring one perspective fully before moving to the next. This prevents:
|
|
8
|
+
|
|
8
9
|
- **Ego defense** — ideas aren't "yours" or "mine"
|
|
9
10
|
- **Argument** — you're not debating, you're exploring perspectives
|
|
10
11
|
- **Incomplete analysis** — each hat forces a perspective that might be skipped
|
|
@@ -12,35 +13,41 @@ Instead of arguing different positions, everyone (or the AI) wears the same "hat
|
|
|
12
13
|
## The Six Hats
|
|
13
14
|
|
|
14
15
|
### White Hat — Facts & Data
|
|
16
|
+
|
|
15
17
|
- What do we know for certain?
|
|
16
18
|
- What data exists? What's missing?
|
|
17
19
|
- No interpretation or opinion — just facts
|
|
18
20
|
- **AI application**: State what's objectively true about the idea, what evidence supports it, what data would be needed
|
|
19
21
|
|
|
20
22
|
### Red Hat — Feelings & Intuition
|
|
23
|
+
|
|
21
24
|
- What's the gut reaction?
|
|
22
25
|
- Emotions, hunches, instincts — no justification needed
|
|
23
26
|
- **AI application**: This is the ONE hat where user input is critical. AI should ask: "What's your gut feeling?" If user defers, AI infers from engagement patterns.
|
|
24
27
|
|
|
25
28
|
### Black Hat — Risks & Caution
|
|
29
|
+
|
|
26
30
|
- What could go wrong?
|
|
27
31
|
- Where are the dangers, weaknesses, pitfalls?
|
|
28
32
|
- Devil's advocate perspective
|
|
29
33
|
- **AI application**: Be genuinely critical — not token concerns. Identify real risks: market, technical, adoption, unintended consequences.
|
|
30
34
|
|
|
31
35
|
### Yellow Hat — Benefits & Optimism
|
|
36
|
+
|
|
32
37
|
- What's the best case scenario?
|
|
33
38
|
- Why could this work? What's the upside?
|
|
34
39
|
- Look for value even in seemingly weak ideas
|
|
35
40
|
- **AI application**: Find genuine strengths. For weak ideas, ask: "What kernel of value exists here?"
|
|
36
41
|
|
|
37
42
|
### Green Hat — Creative Extensions
|
|
43
|
+
|
|
38
44
|
- How could this be improved, combined, extended?
|
|
39
45
|
- New alternatives, modifications, provocations
|
|
40
46
|
- This is the divergent hat within convergence
|
|
41
47
|
- **AI application**: Suggest creative modifications, combinations with other ideas, unexpected extensions
|
|
42
48
|
|
|
43
49
|
### Blue Hat — Process & Planning
|
|
50
|
+
|
|
44
51
|
- What would implementation look like?
|
|
45
52
|
- What steps are needed? What's the timeline?
|
|
46
53
|
- Meta-thinking about the idea
|
|
@@ -49,21 +56,26 @@ Instead of arguing different positions, everyone (or the AI) wears the same "hat
|
|
|
49
56
|
## Sequencing for Ideation Flow
|
|
50
57
|
|
|
51
58
|
### Rapid Evaluation Sequence (Flame default)
|
|
59
|
+
|
|
52
60
|
```
|
|
53
61
|
White → Yellow → Black → Green → Blue
|
|
54
62
|
```
|
|
63
|
+
|
|
55
64
|
Red Hat is handled separately (requires user input).
|
|
56
65
|
|
|
57
66
|
**Rationale**:
|
|
67
|
+
|
|
58
68
|
- Start with facts (ground the discussion)
|
|
59
69
|
- Benefits before risks (prevents premature dismissal)
|
|
60
70
|
- Creative extensions after critique (rescue and improve)
|
|
61
71
|
- Process last (only relevant for shortlisted ideas)
|
|
62
72
|
|
|
63
73
|
### Full Sequence (for top shortlisted ideas)
|
|
74
|
+
|
|
64
75
|
```
|
|
65
76
|
Blue → White → Red → Yellow → Black → Green → Blue
|
|
66
77
|
```
|
|
78
|
+
|
|
67
79
|
Starting and ending with Blue provides process framing.
|
|
68
80
|
|
|
69
81
|
## AI Execution Notes
|
|
@@ -137,6 +137,7 @@ Develop shortlisted ideas into polished, actionable concept briefs. AI and user
|
|
|
137
137
|
</flow>
|
|
138
138
|
|
|
139
139
|
<output_artifacts>
|
|
140
|
+
|
|
140
141
|
| Artifact | Location | Template |
|
|
141
142
|
|----------|----------|----------|
|
|
142
143
|
| Concept Brief | `.specs-ideation/sessions/{id}/concept-briefs/{name}.md` | `./templates/concept-brief.md.hbs` |
|
|
@@ -9,6 +9,7 @@ The same idea is examined through three completely separate lenses, in sequence.
|
|
|
9
9
|
## The Three Roles
|
|
10
10
|
|
|
11
11
|
### The Dreamer
|
|
12
|
+
|
|
12
13
|
- **Mindset**: "Anything is possible"
|
|
13
14
|
- **Perspective**: User/visionary — what would be amazing?
|
|
14
15
|
- **Time horizon**: Infinite
|
|
@@ -16,6 +17,7 @@ The same idea is examined through three completely separate lenses, in sequence.
|
|
|
16
17
|
- **Question**: "If we could do anything, what would this look like?"
|
|
17
18
|
|
|
18
19
|
**AI behavior in Dreamer mode**:
|
|
20
|
+
|
|
19
21
|
- Generate the most ambitious version of the idea
|
|
20
22
|
- No "but" or "however" — pure expansion
|
|
21
23
|
- Think about the emotional impact on users
|
|
@@ -23,6 +25,7 @@ The same idea is examined through three completely separate lenses, in sequence.
|
|
|
23
25
|
- Use vivid, exciting language
|
|
24
26
|
|
|
25
27
|
### The Realist
|
|
28
|
+
|
|
26
29
|
- **Mindset**: "How would this actually work?"
|
|
27
30
|
- **Perspective**: Project manager/engineer — what's the plan?
|
|
28
31
|
- **Time horizon**: 3-12 months
|
|
@@ -30,6 +33,7 @@ The same idea is examined through three completely separate lenses, in sequence.
|
|
|
30
33
|
- **Question**: "What needs to be true for this to work?"
|
|
31
34
|
|
|
32
35
|
**AI behavior in Realist mode**:
|
|
36
|
+
|
|
33
37
|
- Break the dream into concrete components
|
|
34
38
|
- Identify the minimum viable version
|
|
35
39
|
- Map resources, skills, and technology needed
|
|
@@ -37,6 +41,7 @@ The same idea is examined through three completely separate lenses, in sequence.
|
|
|
37
41
|
- Focus on what can be leveraged from existing work
|
|
38
42
|
|
|
39
43
|
### The Critic
|
|
44
|
+
|
|
40
45
|
- **Mindset**: "What could go wrong?"
|
|
41
46
|
- **Perspective**: Quality assurance/risk analyst — what are the weak spots?
|
|
42
47
|
- **Time horizon**: Full lifecycle
|
|
@@ -44,6 +49,7 @@ The same idea is examined through three completely separate lenses, in sequence.
|
|
|
44
49
|
- **Question**: "Why might this fail, and how do we prevent it?"
|
|
45
50
|
|
|
46
51
|
**AI behavior in Critic mode**:
|
|
52
|
+
|
|
47
53
|
- Identify genuine risks (not token concerns)
|
|
48
54
|
- Challenge the weakest assumptions
|
|
49
55
|
- Consider second-order effects and unintended consequences
|
|
@@ -72,6 +78,7 @@ The Forge skill uses Disney Strategy with a co-build emphasis:
|
|
|
72
78
|
| **Critic** | AI raises concerns (generates 40%) | User identifies personal concerns and co-develops mitigations (60%) |
|
|
73
79
|
|
|
74
80
|
The Critic phase has the highest user involvement because:
|
|
81
|
+
|
|
75
82
|
- Users know their context, stakeholders, and politics better than AI
|
|
76
83
|
- Risk assessment requires domain-specific knowledge
|
|
77
84
|
- Co-developing mitigations builds ownership and confidence
|
|
@@ -79,6 +86,7 @@ The Critic phase has the highest user involvement because:
|
|
|
79
86
|
## Anti-Pattern: The Premature Critic
|
|
80
87
|
|
|
81
88
|
The most common failure mode is jumping to critique too early. Signals:
|
|
89
|
+
|
|
82
90
|
- "That won't work because..." (before the idea is fully developed)
|
|
83
91
|
- "But what about..." (during Dreamer phase)
|
|
84
92
|
- Listing constraints before exploring possibilities
|
|
@@ -7,49 +7,60 @@ Structures for presenting concepts clearly and persuasively. Used when generatin
|
|
|
7
7
|
Every Concept Brief follows this structure:
|
|
8
8
|
|
|
9
9
|
### 1. One-Liner
|
|
10
|
+
|
|
10
11
|
A single sentence that captures the essence. If you can't say it in one sentence, the concept isn't clear enough.
|
|
11
12
|
|
|
12
13
|
**Formula**: [Action] + [for whom] + [unique mechanism] + [key benefit]
|
|
13
14
|
|
|
14
15
|
**Examples**:
|
|
16
|
+
|
|
15
17
|
- "A quest-based onboarding system that turns new hire setup into a game, cutting time-to-productivity by 60%."
|
|
16
18
|
- "A reverse mentoring platform where junior employees teach executives about emerging tech, building cross-generational understanding."
|
|
17
19
|
|
|
18
20
|
### 2. Problem
|
|
21
|
+
|
|
19
22
|
What pain exists today? Be specific and vivid.
|
|
20
23
|
|
|
21
24
|
**Formula**: [Who] + [experiences what pain] + [how often/severely] + [what it costs them]
|
|
22
25
|
|
|
23
26
|
### 3. Concept
|
|
27
|
+
|
|
24
28
|
How does this solve the problem? What's the mechanism?
|
|
25
29
|
|
|
26
30
|
**Elements**:
|
|
31
|
+
|
|
27
32
|
- Core mechanism (how it works)
|
|
28
33
|
- Key differentiator (why this approach vs. others)
|
|
29
34
|
- User experience (what does the user see/feel/do?)
|
|
30
35
|
|
|
31
36
|
### 4. Why It Works
|
|
37
|
+
|
|
32
38
|
What makes this concept compelling? Why will it succeed?
|
|
33
39
|
|
|
34
40
|
**Types of evidence**:
|
|
41
|
+
|
|
35
42
|
- Analogies that have worked elsewhere
|
|
36
43
|
- Research or data that supports the approach
|
|
37
44
|
- First-principles reasoning
|
|
38
45
|
- User psychology insights
|
|
39
46
|
|
|
40
47
|
### 5. Risks & Mitigations
|
|
48
|
+
|
|
41
49
|
What could go wrong, and what's the plan?
|
|
42
50
|
|
|
43
51
|
**Format per risk**:
|
|
52
|
+
|
|
44
53
|
- **Risk**: {what could go wrong}
|
|
45
54
|
- **Likelihood**: Low / Medium / High
|
|
46
55
|
- **Impact**: Low / Medium / High
|
|
47
56
|
- **Mitigation**: {specific action to prevent or address}
|
|
48
57
|
|
|
49
58
|
### 6. Next Steps
|
|
59
|
+
|
|
50
60
|
What would you do first to move this forward?
|
|
51
61
|
|
|
52
62
|
**Good next steps are**:
|
|
63
|
+
|
|
53
64
|
- Specific (not "do more research")
|
|
54
65
|
- Actionable (can be started this week)
|
|
55
66
|
- Time-bounded (has a deadline or milestone)
|
|
@@ -58,15 +69,19 @@ What would you do first to move this forward?
|
|
|
58
69
|
## Pitch Principles
|
|
59
70
|
|
|
60
71
|
### Specificity Over Abstraction
|
|
72
|
+
|
|
61
73
|
- Bad: "Leverage gamification to improve engagement"
|
|
62
74
|
- Good: "A quest system where each completed onboarding task unlocks a new tool, with a leaderboard showing progress vs. cohort average"
|
|
63
75
|
|
|
64
76
|
### Show, Don't Categorize
|
|
77
|
+
|
|
65
78
|
- Bad: "This is a B2B SaaS solution for the enterprise market"
|
|
66
79
|
- Good: "When a new VP of Engineering joins, they open their laptop and see a personalized roadmap..."
|
|
67
80
|
|
|
68
81
|
### One Problem, One Solution
|
|
82
|
+
|
|
69
83
|
Each concept brief tackles one clear problem. If there are multiple problems, make multiple briefs.
|
|
70
84
|
|
|
71
85
|
### The "Tell a Friend" Test
|
|
86
|
+
|
|
72
87
|
The one-liner should be something someone would actually say to a colleague: "Hey, have you heard about this thing that [one-liner]?"
|
|
@@ -20,7 +20,7 @@ Generate genuinely diverse, surprising ideas through rapid batches. AI is the cr
|
|
|
20
20
|
|
|
21
21
|
<llm critical="true">
|
|
22
22
|
<mandate>NEVER ask setup questions — generate ideas immediately on receiving a topic</mandate>
|
|
23
|
-
<mandate>
|
|
23
|
+
<mandate>SHOW which technique was used for each idea — e.g., "(via Inversion)" or "(via First Principles)" — so the user understands the thinking approach</mandate>
|
|
24
24
|
<mandate>ALWAYS use the deep thinking protocol before generating each batch</mandate>
|
|
25
25
|
<mandate>ALWAYS present ideas as vivid, specific, memorable concepts — not abstract descriptions</mandate>
|
|
26
26
|
<mandate>NEVER more than 2 questions in a row — always generate something creative first</mandate>
|
|
@@ -82,6 +82,7 @@ Generate genuinely diverse, surprising ideas through rapid batches. AI is the cr
|
|
|
82
82
|
<format>
|
|
83
83
|
**S{batch}-{number}** — {vivid idea title}
|
|
84
84
|
{2-3 sentence description — specific, concrete, imaginative}
|
|
85
|
+
*(technique: {technique used, e.g., Inversion, First Principles, SCAMPER, Analogy})*
|
|
85
86
|
</format>
|
|
86
87
|
<action>Number ideas sequentially across batches (S1-1, S1-2... S2-1, S2-2...)</action>
|
|
87
88
|
<anti_bias>
|
|
@@ -134,6 +135,7 @@ Generate genuinely diverse, surprising ideas through rapid batches. AI is the cr
|
|
|
134
135
|
</flow>
|
|
135
136
|
|
|
136
137
|
<output_artifacts>
|
|
138
|
+
|
|
137
139
|
| Artifact | Location | Template |
|
|
138
140
|
|----------|----------|----------|
|
|
139
141
|
| Spark Bank | `.specs-ideation/sessions/{id}/spark-bank.md` | `./templates/spark-bank.md.hbs` |
|
|
@@ -14,31 +14,37 @@
|
|
|
14
14
|
## Analogy Sources
|
|
15
15
|
|
|
16
16
|
### Nature (Biomimicry)
|
|
17
|
+
|
|
17
18
|
- How does nature solve similar problems?
|
|
18
19
|
- Velcro from burrs, bullet trains from kingfisher beaks, self-healing materials from skin
|
|
19
20
|
- Best for: structural, efficiency, and resilience problems
|
|
20
21
|
|
|
21
22
|
### Games & Sports
|
|
23
|
+
|
|
22
24
|
- How do games create engagement, manage competition, handle fairness?
|
|
23
25
|
- Matchmaking, progression systems, handicaps, spectator modes
|
|
24
26
|
- Best for: engagement, fairness, and motivation problems
|
|
25
27
|
|
|
26
28
|
### Architecture & Urban Planning
|
|
29
|
+
|
|
27
30
|
- How do cities manage flow, density, growth, safety?
|
|
28
31
|
- Zoning, traffic patterns, public spaces, wayfinding
|
|
29
32
|
- Best for: scale, navigation, and organization problems
|
|
30
33
|
|
|
31
34
|
### Music & Performance
|
|
35
|
+
|
|
32
36
|
- How do musicians create tension, resolution, improvisation, collaboration?
|
|
33
37
|
- Call-and-response, crescendo, variations on a theme
|
|
34
38
|
- Best for: experience design, pacing, and collaboration problems
|
|
35
39
|
|
|
36
40
|
### History & Civilization
|
|
41
|
+
|
|
37
42
|
- How did past civilizations solve similar problems?
|
|
38
43
|
- Trade routes, governance, knowledge preservation, cultural transmission
|
|
39
44
|
- Best for: communication, governance, and knowledge problems
|
|
40
45
|
|
|
41
46
|
### Medicine & Biology
|
|
47
|
+
|
|
42
48
|
- How does the body handle similar challenges?
|
|
43
49
|
- Immune system (threats), nervous system (signals), circulatory system (distribution)
|
|
44
50
|
- Best for: security, communication, and distribution problems
|
|
@@ -46,6 +52,7 @@
|
|
|
46
52
|
## AI Application Notes
|
|
47
53
|
|
|
48
54
|
When using analogy internally:
|
|
55
|
+
|
|
49
56
|
1. Abstract the topic to its core challenge (e.g., "reduce onboarding time" → "accelerate knowledge transfer")
|
|
50
57
|
2. Pick 2-3 distant domains from the list above
|
|
51
58
|
3. Find genuine analogies (not surface-level similarities)
|
package/flows/ideation/agents/orchestrator/skills/spark/references/techniques/first-principles.md
CHANGED
|
@@ -15,18 +15,22 @@
|
|
|
15
15
|
## Decomposition Framework
|
|
16
16
|
|
|
17
17
|
### Layer 1: Surface (What people do)
|
|
18
|
+
|
|
18
19
|
- Current behaviors, products, services
|
|
19
20
|
- "Everyone does it this way because..."
|
|
20
21
|
|
|
21
22
|
### Layer 2: Convention (Why they do it)
|
|
23
|
+
|
|
22
24
|
- Industry norms, best practices, legacy reasons
|
|
23
25
|
- "We've always done it this way because..."
|
|
24
26
|
|
|
25
27
|
### Layer 3: Constraints (Real vs. assumed)
|
|
28
|
+
|
|
26
29
|
- Physical laws, regulations, actual technical limits
|
|
27
30
|
- vs. "We assumed this was a constraint but it's actually a choice"
|
|
28
31
|
|
|
29
32
|
### Layer 4: Fundamentals (Irreducible truths)
|
|
33
|
+
|
|
30
34
|
- What must be true regardless of implementation?
|
|
31
35
|
- What does the user actually need (not what they're used to)?
|
|
32
36
|
- What are the physics/economics that can't be changed?
|
|
@@ -44,6 +48,7 @@
|
|
|
44
48
|
## AI Application Notes
|
|
45
49
|
|
|
46
50
|
When using first-principles internally:
|
|
51
|
+
|
|
47
52
|
1. Don't just list the fundamentals — actually strip away conventions and rebuild
|
|
48
53
|
2. The power is in identifying which "constraints" are actually conventions
|
|
49
54
|
3. Best used when ideas feel incremental — first-principles thinking produces category-shifting ideas
|
|
@@ -14,24 +14,29 @@
|
|
|
14
14
|
## Inversion Patterns
|
|
15
15
|
|
|
16
16
|
### Goal Inversion
|
|
17
|
+
|
|
17
18
|
- Goal: "Make onboarding fast" → Inverted: "How to make onboarding take forever?"
|
|
18
19
|
- Answers: No documentation, no buddy system, surprise requirements → Ideas: Pre-arrival portal, day-1 buddy auto-match, zero-surprise checklist
|
|
19
20
|
|
|
20
21
|
### User Inversion
|
|
22
|
+
|
|
21
23
|
- Design for the opposite user: experts → beginners, individuals → teams, tech-savvy → tech-averse
|
|
22
24
|
- Forces empathy and reveals assumptions
|
|
23
25
|
|
|
24
26
|
### Process Inversion
|
|
27
|
+
|
|
25
28
|
- Reverse the order: What if the last step came first?
|
|
26
29
|
- End-to-outcome: Start with the desired result and work backward
|
|
27
30
|
- Often reveals unnecessary steps
|
|
28
31
|
|
|
29
32
|
### Value Inversion
|
|
33
|
+
|
|
30
34
|
- What if the biggest cost became the biggest feature?
|
|
31
35
|
- What if the bug became the selling point?
|
|
32
36
|
- Turns weaknesses into differentiators
|
|
33
37
|
|
|
34
38
|
### Anti-Problem
|
|
39
|
+
|
|
35
40
|
- Instead of solving the problem, make it irrelevant
|
|
36
41
|
- Instead of reducing friction, make the friction delightful
|
|
37
42
|
- Reframe rather than fix
|
|
@@ -39,6 +44,7 @@
|
|
|
39
44
|
## AI Application Notes
|
|
40
45
|
|
|
41
46
|
When using inversion internally:
|
|
47
|
+
|
|
42
48
|
1. Pick the most interesting inversion pattern for the current topic
|
|
43
49
|
2. Actually go through the full inversion (state goal → invert → list failure modes → reverse)
|
|
44
50
|
3. The best ideas come from reversing *non-obvious* failure modes
|
package/flows/ideation/agents/orchestrator/skills/spark/references/techniques/questorming.md
CHANGED
|
@@ -16,26 +16,31 @@
|
|
|
16
16
|
## Question Types
|
|
17
17
|
|
|
18
18
|
### Assumption-Challenging
|
|
19
|
+
|
|
19
20
|
- Why do we assume [X] is necessary?
|
|
20
21
|
- What if [commonly accepted truth] were false?
|
|
21
22
|
- Who said this has to be done by [conventional actor]?
|
|
22
23
|
|
|
23
24
|
### Scope-Shifting
|
|
25
|
+
|
|
24
26
|
- What if we zoom out 10x — what's the bigger problem?
|
|
25
27
|
- What if we zoom in 10x — what's the specific pain point?
|
|
26
28
|
- What would this look like from the customer's customer's perspective?
|
|
27
29
|
|
|
28
30
|
### Stakeholder Questions
|
|
31
|
+
|
|
29
32
|
- Who benefits from the current broken state?
|
|
30
33
|
- Who would lose if we solved this perfectly?
|
|
31
34
|
- Who has already solved this in a different context?
|
|
32
35
|
|
|
33
36
|
### Temporal Questions
|
|
37
|
+
|
|
34
38
|
- Why hasn't this been solved yet?
|
|
35
39
|
- What will make this irrelevant in 5 years?
|
|
36
40
|
- What had to change for this to become solvable now?
|
|
37
41
|
|
|
38
42
|
### Provocative Questions
|
|
43
|
+
|
|
39
44
|
- What's the most expensive possible solution? The cheapest?
|
|
40
45
|
- What would a competitor do with this opportunity?
|
|
41
46
|
- What would a child suggest?
|
|
@@ -43,6 +48,7 @@
|
|
|
43
48
|
## AI Application Notes
|
|
44
49
|
|
|
45
50
|
When using questorming internally:
|
|
51
|
+
|
|
46
52
|
1. Generate a burst of 8-10 questions about the topic
|
|
47
53
|
2. Present 3-5 of the most provocative ones to the user
|
|
48
54
|
3. Ask: "Which of these feels most important?" (the one elicit moment)
|
package/flows/ideation/agents/orchestrator/skills/spark/references/techniques/random-word.md
CHANGED
|
@@ -27,6 +27,7 @@
|
|
|
27
27
|
## AI Application Notes
|
|
28
28
|
|
|
29
29
|
When using random-word internally:
|
|
30
|
+
|
|
30
31
|
1. Pick concepts from **distant domains** — nature, games, history, architecture, music
|
|
31
32
|
2. The more unrelated the concept, the more novel the connections
|
|
32
33
|
3. Generate at least 5 attribute-connections, then pick the 2-3 most surprising
|
|
@@ -7,38 +7,52 @@
|
|
|
7
7
|
## The Seven Operators
|
|
8
8
|
|
|
9
9
|
### S — Substitute
|
|
10
|
+
|
|
10
11
|
What can be substituted? Different materials, people, processes, components, approaches?
|
|
12
|
+
|
|
11
13
|
- Replace one element with something unexpected
|
|
12
14
|
- Swap the medium, channel, or context
|
|
13
15
|
|
|
14
16
|
### C — Combine
|
|
17
|
+
|
|
15
18
|
What can be combined? Blend two ideas, merge functions, mix purposes?
|
|
19
|
+
|
|
16
20
|
- Combine features from different domains
|
|
17
21
|
- Merge two user needs into one solution
|
|
18
22
|
|
|
19
23
|
### A — Adapt
|
|
24
|
+
|
|
20
25
|
What can be adapted from elsewhere? What analogies apply? What else is like this?
|
|
26
|
+
|
|
21
27
|
- Borrow solutions from other industries
|
|
22
28
|
- Adapt natural processes to the problem
|
|
23
29
|
|
|
24
30
|
### M — Modify (also: Magnify / Minimize)
|
|
31
|
+
|
|
25
32
|
What can be changed? Size, shape, color, meaning, frequency, intensity?
|
|
33
|
+
|
|
26
34
|
- Make it 10x bigger or smaller
|
|
27
35
|
- Change the speed, frequency, or intensity
|
|
28
36
|
- Alter the form factor entirely
|
|
29
37
|
|
|
30
38
|
### P — Put to Other Use
|
|
39
|
+
|
|
31
40
|
Can this serve a different purpose? New contexts? New users? New markets?
|
|
41
|
+
|
|
32
42
|
- Repurpose for a completely different audience
|
|
33
43
|
- Use the byproduct as the main product
|
|
34
44
|
|
|
35
45
|
### E — Eliminate
|
|
46
|
+
|
|
36
47
|
What can be removed? Simplify? What's non-essential?
|
|
48
|
+
|
|
37
49
|
- Remove the most complex component — what happens?
|
|
38
50
|
- Strip to the absolute minimum viable version
|
|
39
51
|
|
|
40
52
|
### R — Reverse (also: Rearrange)
|
|
53
|
+
|
|
41
54
|
What if the order were reversed? What if roles swapped? What if inside-out?
|
|
55
|
+
|
|
42
56
|
- Reverse the workflow
|
|
43
57
|
- Let the user become the provider
|
|
44
58
|
- Flip the value proposition
|
|
@@ -46,6 +60,7 @@ What if the order were reversed? What if roles swapped? What if inside-out?
|
|
|
46
60
|
## AI Application Notes
|
|
47
61
|
|
|
48
62
|
When using SCAMPER internally:
|
|
63
|
+
|
|
49
64
|
1. Pick 2-3 operators per batch (not all 7 — that produces too-similar ideas)
|
|
50
65
|
2. Apply each operator to a **different domain** from the domain wheel
|
|
51
66
|
3. Make the result vivid and specific, not abstract
|
|
@@ -14,27 +14,32 @@
|
|
|
14
14
|
## Types of What-If
|
|
15
15
|
|
|
16
16
|
### Constraint Removal
|
|
17
|
+
|
|
17
18
|
- What if money were no object?
|
|
18
19
|
- What if there were no technical limitations?
|
|
19
20
|
- What if you had unlimited time?
|
|
20
21
|
- What if there were no regulations?
|
|
21
22
|
|
|
22
23
|
### Constraint Inversion
|
|
24
|
+
|
|
23
25
|
- What if the user had to pay NOT to use it?
|
|
24
26
|
- What if it only worked for 5 minutes per day?
|
|
25
27
|
- What if it required 100 people to operate?
|
|
26
28
|
|
|
27
29
|
### Context Shift
|
|
30
|
+
|
|
28
31
|
- What if this existed in 1920? In 2120?
|
|
29
32
|
- What if this were designed for children? For astronauts? For animals?
|
|
30
33
|
- What if this operated underwater? In zero gravity? In complete darkness?
|
|
31
34
|
|
|
32
35
|
### Scale Shift
|
|
36
|
+
|
|
33
37
|
- What if 1 billion people used this simultaneously?
|
|
34
38
|
- What if it were the size of a building? A molecule?
|
|
35
39
|
- What if it lasted 100 years? 100 milliseconds?
|
|
36
40
|
|
|
37
41
|
### Role Reversal
|
|
42
|
+
|
|
38
43
|
- What if the customer built it and the company used it?
|
|
39
44
|
- What if the problem were actually the solution?
|
|
40
45
|
- What if success and failure metrics were swapped?
|
|
@@ -42,6 +47,7 @@
|
|
|
42
47
|
## AI Application Notes
|
|
43
48
|
|
|
44
49
|
When using what-if internally:
|
|
50
|
+
|
|
45
51
|
1. Identify 2-3 non-obvious assumptions about the topic
|
|
46
52
|
2. Pick the most interesting what-if type for each assumption
|
|
47
53
|
3. Briefly explore the scenario (2-3 sentences), then extract a concrete idea
|
|
@@ -24,16 +24,18 @@ The domain wheel has 12 sectors. Every idea must be tagged with its primary doma
|
|
|
24
24
|
## Enforcement Rules
|
|
25
25
|
|
|
26
26
|
### Per-Batch (5 ideas)
|
|
27
|
+
|
|
27
28
|
1. **Minimum 3 different domains** per batch — HARD REQUIREMENT
|
|
28
29
|
2. **Never 2 consecutive ideas from the same domain**
|
|
29
30
|
3. **Track domain usage** across the entire session
|
|
30
31
|
4. **Prioritize underused domains** — if a domain has 0 ideas, it should appear in the next 2 batches
|
|
31
32
|
|
|
32
33
|
### Per-Session
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
34
|
+
|
|
35
|
+
1. **After every 15 ideas**: inject 1 provocative idea (see Provocation Types below)
|
|
36
|
+
2. **After every 20 ideas**: shift perspective entirely (different user persona, different era, different culture)
|
|
37
|
+
3. **If user favorites cluster in 1-2 domains**: deliberately diversify the next batch into 4+ domains
|
|
38
|
+
4. **By session end**: aim for 8+ domains covered
|
|
37
39
|
|
|
38
40
|
### Domain Tracking Format
|
|
39
41
|
|
|
@@ -58,6 +60,7 @@ Provocations are deliberately absurd or extreme ideas that break fixation patter
|
|
|
58
60
|
| **Stakeholder swap** | Different user entirely | "Design this for a 5-year-old. Now for a 90-year-old." |
|
|
59
61
|
|
|
60
62
|
### Provocation Rules
|
|
63
|
+
|
|
61
64
|
- Label provocations internally but present them naturally among other ideas
|
|
62
65
|
- If a provocation resonates with the user, develop it into a real idea
|
|
63
66
|
- Provocations should be surprising but contain a kernel of insight
|
|
@@ -29,35 +29,41 @@ Execute the same reasoning chain as an internal process. Think through each step
|
|
|
29
29
|
## The 6-Step Reasoning Chain
|
|
30
30
|
|
|
31
31
|
### Think 1 — Domain Check
|
|
32
|
+
|
|
32
33
|
- Review domain usage tracking from session state
|
|
33
34
|
- Which domains are underexplored?
|
|
34
35
|
- Select 3+ target domains for this batch
|
|
35
36
|
- If user expressed preferences, balance between preferred and underexplored
|
|
36
37
|
|
|
37
38
|
### Think 2 — Raw Concepts
|
|
39
|
+
|
|
38
40
|
- Generate 1-2 raw ideas per selected domain
|
|
39
41
|
- Use a technique internally: SCAMPER, analogy, inversion, random-word, what-if, first-principles, or questorming
|
|
40
42
|
- Select technique based on: what hasn't been used recently, what fits the user's energy, what the topic needs
|
|
41
43
|
- Aim for 6-8 raw concepts to select 5 from
|
|
42
44
|
|
|
43
45
|
### Think 3 — Novelty Filter
|
|
46
|
+
|
|
44
47
|
- For each raw concept, ask: "Is this genuinely new or a repackaged version of an obvious idea?"
|
|
45
48
|
- Check against ideas already generated in this session
|
|
46
49
|
- Replace any that feel generic, incremental, or too similar to existing ideas
|
|
47
50
|
- The bar: would this make someone say "huh, I never thought of that"?
|
|
48
51
|
|
|
49
52
|
### Think 4 — Cross-pollinate
|
|
53
|
+
|
|
50
54
|
- If user has stated favorites, can any new ideas combine with them?
|
|
51
55
|
- Look for unexpected connections between the raw concepts themselves
|
|
52
56
|
- Create at least one idea that bridges two different domains
|
|
53
57
|
|
|
54
58
|
### Think 5 — Provocation
|
|
59
|
+
|
|
55
60
|
- Check: is a provocation due? (every 15 ideas)
|
|
56
61
|
- If yes: select a provocation type and generate one deliberately absurd idea
|
|
57
62
|
- If no: ensure at least one idea in the batch challenges a core assumption
|
|
58
63
|
- The provocation should be surprising but contain a genuine insight
|
|
59
64
|
|
|
60
65
|
### Think 6 — Polish
|
|
66
|
+
|
|
61
67
|
- For each of the 5 selected ideas:
|
|
62
68
|
- Make it vivid: use concrete details, not abstractions
|
|
63
69
|
- Make it specific: "a quest system where..." not "gamification"
|
|
@@ -65,6 +71,7 @@ Execute the same reasoning chain as an internal process. Think through each step
|
|
|
65
71
|
- Final anti-bias check: do the 5 ideas span 3+ domains? No 2 consecutive from same domain?
|
|
66
72
|
|
|
67
73
|
### Think 7 — Meta-check (Optional)
|
|
74
|
+
|
|
68
75
|
- Only if something feels off about the batch
|
|
69
76
|
- Is this batch genuinely diverse or are the ideas structurally similar?
|
|
70
77
|
- Does this batch feel different from the previous batch?
|
|
@@ -50,12 +50,14 @@ Mixing them kills creativity. Judging during generation produces safe, increment
|
|
|
50
50
|
## The "Deferred Judgment" Contract
|
|
51
51
|
|
|
52
52
|
During divergent phases, the AI MUST:
|
|
53
|
+
|
|
53
54
|
- Record every idea, even seemingly bad ones
|
|
54
55
|
- Never add qualifiers like "while this might not be practical..."
|
|
55
56
|
- Never rank or compare ideas within a divergent phase
|
|
56
57
|
- Treat every idea as equally valid until convergence
|
|
57
58
|
|
|
58
59
|
During convergent phases, the AI MUST:
|
|
60
|
+
|
|
59
61
|
- Apply consistent evaluation criteria
|
|
60
62
|
- Not generate new ideas (unless explicitly extending)
|
|
61
63
|
- Acknowledge trade-offs rather than seeking a single "best"
|
|
@@ -23,6 +23,7 @@ Generation-heavy at start (Spark), increasingly collaborative as ideas become co
|
|
|
23
23
|
## Hard Rules
|
|
24
24
|
|
|
25
25
|
### The 2-Question Limit
|
|
26
|
+
|
|
26
27
|
**NEVER more than 2 questions in a row before generating something creative.**
|
|
27
28
|
|
|
28
29
|
If the AI has asked 2 questions, it MUST generate output next — even if it doesn't have complete information. Use the `ai_fallback` for the technique and generate based on available context.
|
|
@@ -39,6 +40,7 @@ If the AI has asked 2 questions, it MUST generate output next — even if it doe
|
|
|
39
40
|
| (detailed responses, high engagement) | More co-build to leverage engagement |
|
|
40
41
|
|
|
41
42
|
### Ratio Tracking
|
|
43
|
+
|
|
42
44
|
Track the question-to-generation ratio. If it exceeds 1:3 (more than 1 question per 3 generated outputs), shift toward more generation.
|
|
43
45
|
|
|
44
46
|
## Technique-Interaction Mapping
|
|
@@ -62,19 +64,24 @@ Each technique declares its natural interaction type:
|
|
|
62
64
|
The AI reads engagement signals and adapts:
|
|
63
65
|
|
|
64
66
|
### High Energy Signals
|
|
67
|
+
|
|
65
68
|
- Long responses, exclamation marks, building on ideas
|
|
66
69
|
- **Response**: Match energy, increase pace, go bolder
|
|
67
70
|
|
|
68
71
|
### Medium Energy Signals
|
|
72
|
+
|
|
69
73
|
- Moderate responses, picking favorites, giving direction
|
|
70
74
|
- **Response**: Steady pace, follow their direction
|
|
71
75
|
|
|
72
76
|
### Low Energy Signals
|
|
77
|
+
|
|
73
78
|
- Short responses ("ok", "sure", "next"), slow replies
|
|
74
79
|
- **Response**: Generate more (don't ask), try a different angle, offer to pause or switch skills
|
|
75
80
|
|
|
76
81
|
### Re-energizing Tactics
|
|
82
|
+
|
|
77
83
|
When energy drops:
|
|
84
|
+
|
|
78
85
|
1. Switch technique (if SCAMPER isn't landing, try inversion or random-word)
|
|
79
86
|
2. Switch domain (if tech ideas aren't exciting, try nature or games)
|
|
80
87
|
3. Inject a provocation (absurd idea can re-spark interest)
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "specsmd",
|
|
3
|
-
"version": "0.0.0-dev.
|
|
3
|
+
"version": "0.0.0-dev.86",
|
|
4
4
|
"description": "Multi-agent orchestration system for AI-native software development. Delivers AI-DLC, Agile, and custom SDLC flows as markdown-based agent systems.",
|
|
5
5
|
"main": "lib/installer.js",
|
|
6
6
|
"bin": {
|