arkaos 2.55.0 → 2.56.0
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/VERSION
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
2.
|
|
1
|
+
2.56.0
|
|
@@ -1,7 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: pm/roadmap-build
|
|
3
3
|
description: >
|
|
4
|
-
|
|
4
|
+
Outcome-driven product roadmap — North Star + outcome tree + 3-horizon
|
|
5
|
+
map (Now/Next/Later) + bet selection + capacity allocation + audience-
|
|
6
|
+
specific communication. Replaces feature-list roadmaps with measurable
|
|
7
|
+
bets.
|
|
5
8
|
allowed-tools: [Read, Write, Edit, Bash, Grep, Glob, Agent, WebFetch, WebSearch]
|
|
6
9
|
---
|
|
7
10
|
|
|
@@ -21,12 +24,114 @@ does not replace the vault.
|
|
|
21
24
|
|
|
22
25
|
# Roadmap Build — `/pm roadmap <product>`
|
|
23
26
|
|
|
24
|
-
> **
|
|
27
|
+
> **Lead:** Carolina (Product Manager) | **Cross-dept:** Tomas (Strategy) + Francisca (Tech) + Eduardo (Copy) | **Frameworks:** Marty Cagan Outcome-Driven Roadmaps + Three Horizons + Bets vs Promises
|
|
25
28
|
|
|
26
|
-
## What
|
|
29
|
+
## What ships
|
|
27
30
|
|
|
28
|
-
|
|
31
|
+
A production roadmap in 6 deliverables:
|
|
29
32
|
|
|
30
|
-
|
|
33
|
+
1. **North Star metric** — the one number the product team optimises
|
|
34
|
+
2. **Outcome tree** — 3-5 outcomes that decompose the North Star, each measurable
|
|
35
|
+
3. **Three-horizon map** — Now (committed) / Next (validating) / Later (exploring)
|
|
36
|
+
4. **Bet selection** — 1-3 bets per outcome with hypothesis + success criteria
|
|
37
|
+
5. **Capacity allocation** — team mapping with fixed-time vs fixed-scope policy
|
|
38
|
+
6. **Per-audience communication** — exec / engineering / sales / customer views
|
|
31
39
|
|
|
32
|
-
|
|
40
|
+
## North Star Metric (the math constraint)
|
|
41
|
+
|
|
42
|
+
The North Star is **one number**, not a dashboard. Properties of a valid North Star:
|
|
43
|
+
|
|
44
|
+
- **Lagging enough** — represents customer value, not just activity. "Active users" is leading; "Active users who completed the core action 3 times in 7 days" is closer to value.
|
|
45
|
+
- **Leading enough** — moves on quarterly cadence, not yearly. Revenue is too lagging for product team decisions.
|
|
46
|
+
- **Causal to revenue** — a working North Star explains revenue movement with 90-day lag.
|
|
47
|
+
- **Movable by product** — the team can affect it with shipped work, not just marketing or sales.
|
|
48
|
+
|
|
49
|
+
Examples that work: Airbnb's "Nights Booked", Slack's "Messages sent in active teams", Stripe's "Payment volume processed".
|
|
50
|
+
|
|
51
|
+
Examples that fail: NPS (too lagging, hard to move), "Number of users" (vanity), "Engineering velocity" (internal, not customer).
|
|
52
|
+
|
|
53
|
+
## Outcome Tree (decomposition)
|
|
54
|
+
|
|
55
|
+
Decompose the North Star into 3-5 outcomes. Each outcome is a number, not a description. The math should hold: if all outcomes move, the North Star moves.
|
|
56
|
+
|
|
57
|
+
```
|
|
58
|
+
NORTH STAR: Active teams using core feature 3+ times/week
|
|
59
|
+
|
|
60
|
+
OUTCOME 1: Trial-to-paid conversion rate (currently 6%, target 12%)
|
|
61
|
+
BET 1.1: Improve onboarding completion rate
|
|
62
|
+
BET 1.2: Reduce time-to-first-value
|
|
63
|
+
|
|
64
|
+
OUTCOME 2: Weekly active rate per paid team (currently 60%, target 80%)
|
|
65
|
+
BET 2.1: Habit loop in core workflow
|
|
66
|
+
BET 2.2: Notification system that drives return
|
|
67
|
+
|
|
68
|
+
OUTCOME 3: Feature adoption depth (currently 1.4 features per active team, target 2.5)
|
|
69
|
+
BET 3.1: Discoverability improvements
|
|
70
|
+
BET 3.2: Cross-feature integration
|
|
71
|
+
|
|
72
|
+
OUTCOME 4: Team-to-team expansion (currently 5% of paid teams expand, target 15%)
|
|
73
|
+
BET 4.1: Multi-team workflow
|
|
74
|
+
BET 4.2: Admin tools for organisations
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
Each outcome must answer: *if this number moves by X, does the North Star move by Y? Show the math.*
|
|
78
|
+
|
|
79
|
+
## Three Horizons (commitment-by-horizon)
|
|
80
|
+
|
|
81
|
+
| Horizon | Time | Commitment | Communication |
|
|
82
|
+
|---|---|---|---|
|
|
83
|
+
| **Now** | Current quarter | High — committed, in flight | Specific bets named, in-progress |
|
|
84
|
+
| **Next** | Following quarter | Medium — validating, scoped | Bets shaped, not yet started |
|
|
85
|
+
| **Later** | 2-4 quarters out | Low — exploring, hypothesis-stage | Directional only, "we believe X matters" |
|
|
86
|
+
|
|
87
|
+
The rule: **the further out, the lower the commitment**. Roadmaps that promise specific Q4 features at Q1 confidence lose all credibility when they slip.
|
|
88
|
+
|
|
89
|
+
## Bets vs Promises (Shape Up alignment)
|
|
90
|
+
|
|
91
|
+
A bet has:
|
|
92
|
+
- **Appetite** (time budget, fixed)
|
|
93
|
+
- **Hypothesis** (if we ship X, Y will change)
|
|
94
|
+
- **Success criteria** (Y moves by Z)
|
|
95
|
+
- **Failure criteria** (if Y doesn't move by Z by date W, we stop)
|
|
96
|
+
|
|
97
|
+
A promise has:
|
|
98
|
+
- Date
|
|
99
|
+
- Specific deliverable
|
|
100
|
+
- No falsification path
|
|
101
|
+
|
|
102
|
+
Roadmaps with promises are commitments to specific outputs. Roadmaps with bets are commitments to specific *learning*. Bets compound; promises break.
|
|
103
|
+
|
|
104
|
+
## Capacity Allocation Policy
|
|
105
|
+
|
|
106
|
+
Each bet has a policy on what's fixed vs variable:
|
|
107
|
+
|
|
108
|
+
- **Fixed time, variable scope** (Shape Up default) — appetite is the constraint. Scope is whatever fits.
|
|
109
|
+
- **Fixed scope, variable time** (legacy waterfall) — only use when externally constrained (regulatory, contractual).
|
|
110
|
+
- **Fixed both** — invalid. Pick one. Trying to fix both produces death marches.
|
|
111
|
+
|
|
112
|
+
Typical mix for a product team: 60% Fixed Time (Now horizon), 30% Discovery (Next horizon), 10% Exploration (Later horizon, hypothesis testing).
|
|
113
|
+
|
|
114
|
+
## Per-Audience Communication
|
|
115
|
+
|
|
116
|
+
The same roadmap presents differently to different audiences. Same data, different framing.
|
|
117
|
+
|
|
118
|
+
| Audience | What they see | What's redacted |
|
|
119
|
+
|---|---|---|
|
|
120
|
+
| **Exec / Board** | Outcomes + North Star projection + bet portfolio | Specific feature lists, internal team names |
|
|
121
|
+
| **Engineering** | Bets with appetite + technical context | Sales-speak, customer logo lists |
|
|
122
|
+
| **Sales / GTM** | What's shipping + when (Now horizon only) | Discovery hypotheses, failed bets |
|
|
123
|
+
| **Customer-facing** | Public-safe directional ("We're investing in X") | Specifics, dates, anything we might not ship |
|
|
124
|
+
|
|
125
|
+
The mistake: showing customers the same roadmap as engineering. Customers see dates and treat them as promises; engineering sees dates and treats them as appetite. Different commitment levels need different framings.
|
|
126
|
+
|
|
127
|
+
## Common Failure Modes
|
|
128
|
+
|
|
129
|
+
1. **Feature roadmap disguised as outcome roadmap** — list of features renamed "outcomes". The test: can you measure success without shipping a specific feature? If no, it's a feature roadmap.
|
|
130
|
+
2. **North Star that doesn't move** — picking a metric that takes 6+ months to respond. The team can't tell if work is working.
|
|
131
|
+
3. **Promising the Later horizon** — exposing speculative quarters as commitments. When they slip, the team loses credibility on the Now horizon too.
|
|
132
|
+
4. **No falsification on bets** — bets without failure criteria become marathons. Set the kill-switch date upfront.
|
|
133
|
+
5. **Same view for all audiences** — engineering sees customer-facing directional language and treats it as imprecision. Customers see engineering specificity and treat it as promise.
|
|
134
|
+
|
|
135
|
+
## Output → Obsidian: `WizardingCode/Product/Roadmap/<product>-<date>/`
|
|
136
|
+
|
|
137
|
+
Delivers: North Star definition + outcome tree (3-5 outcomes with metrics) + three-horizon map + bet definitions (hypothesis + success criteria + appetite per bet) + capacity allocation + per-audience roadmap views + 1-page executive summary.
|
|
@@ -0,0 +1,136 @@
|
|
|
1
|
+
id: pm-discover
|
|
2
|
+
name: Product Discovery
|
|
3
|
+
description: Continuous product discovery using Opportunity Solution Tree (Teresa Torres) — interviews + assumption tests + outcome alignment
|
|
4
|
+
department: pm
|
|
5
|
+
tier: enterprise
|
|
6
|
+
command: "/pm discover"
|
|
7
|
+
requires_branch: false
|
|
8
|
+
requires_spec: false
|
|
9
|
+
quality_gate_required: true
|
|
10
|
+
|
|
11
|
+
phases:
|
|
12
|
+
- id: brief
|
|
13
|
+
name: Discovery Brief
|
|
14
|
+
description: Define product outcome, the question we're answering, current evidence base, runway for discovery
|
|
15
|
+
agents:
|
|
16
|
+
- agent_id: product-director-carolina
|
|
17
|
+
role: Frame outcome, question, current evidence, time budget
|
|
18
|
+
gate:
|
|
19
|
+
type: user_approval
|
|
20
|
+
description: User confirms outcome statement and discovery question
|
|
21
|
+
|
|
22
|
+
- id: opportunity-mapping
|
|
23
|
+
name: Opportunity Mapping
|
|
24
|
+
description: Map the Opportunity Solution Tree — desired outcome at top, opportunities (customer needs) in middle, solution candidates at bottom
|
|
25
|
+
agents:
|
|
26
|
+
- agent_id: product-director-carolina
|
|
27
|
+
role: OST construction with explicit opportunity definitions
|
|
28
|
+
- agent_id: ux-designer-sofia-d
|
|
29
|
+
role: Customer journey lens — where do opportunities surface?
|
|
30
|
+
parallel: true
|
|
31
|
+
gate:
|
|
32
|
+
type: user_approval
|
|
33
|
+
description: User approves OST structure
|
|
34
|
+
outputs:
|
|
35
|
+
- type: document
|
|
36
|
+
format: markdown
|
|
37
|
+
obsidian_path: "WizardingCode/Product/Discovery/OST/"
|
|
38
|
+
description: Opportunity Solution Tree with opportunity definitions
|
|
39
|
+
|
|
40
|
+
- id: interview-plan
|
|
41
|
+
name: Interview Plan
|
|
42
|
+
description: Plan 5-10 customer interviews — recruit criteria, script, capture format
|
|
43
|
+
agents:
|
|
44
|
+
- agent_id: product-director-carolina
|
|
45
|
+
role: Interview script with story-based question structure (specific recent moments, not opinions)
|
|
46
|
+
gate:
|
|
47
|
+
type: user_approval
|
|
48
|
+
description: User approves interview plan and recruit criteria
|
|
49
|
+
|
|
50
|
+
- id: interview-execution
|
|
51
|
+
name: Interviews + Synthesis
|
|
52
|
+
description: Run interviews; synthesize into opportunity additions/refinements to the OST
|
|
53
|
+
agents:
|
|
54
|
+
- agent_id: product-director-carolina
|
|
55
|
+
role: Run interviews, capture verbatim notes, synthesize into opportunity refinements
|
|
56
|
+
gate:
|
|
57
|
+
type: user_approval
|
|
58
|
+
description: User approves interview synthesis
|
|
59
|
+
outputs:
|
|
60
|
+
- type: document
|
|
61
|
+
format: markdown
|
|
62
|
+
obsidian_path: "WizardingCode/Product/Discovery/Interviews/"
|
|
63
|
+
description: Interview synthesis with opportunity refinements
|
|
64
|
+
|
|
65
|
+
- id: opportunity-selection
|
|
66
|
+
name: Opportunity Selection
|
|
67
|
+
description: Pick the target opportunity using impact × confidence × ease prioritisation
|
|
68
|
+
agents:
|
|
69
|
+
- agent_id: product-director-carolina
|
|
70
|
+
role: Opportunity selection with explicit prioritisation matrix and rationale
|
|
71
|
+
gate:
|
|
72
|
+
type: user_approval
|
|
73
|
+
description: User approves target opportunity
|
|
74
|
+
|
|
75
|
+
- id: assumption-tests
|
|
76
|
+
name: Assumption Mapping & Tests
|
|
77
|
+
description: For the chosen opportunity, list assumptions (desirability / viability / feasibility / usability) and design tests for the riskiest
|
|
78
|
+
agents:
|
|
79
|
+
- agent_id: product-director-carolina
|
|
80
|
+
role: Assumption map + test design for top 3 riskiest assumptions
|
|
81
|
+
- agent_id: tech-director-francisca
|
|
82
|
+
role: Feasibility-assumption test feasibility check
|
|
83
|
+
parallel: true
|
|
84
|
+
gate:
|
|
85
|
+
type: user_approval
|
|
86
|
+
description: User approves the top 3 assumption tests
|
|
87
|
+
|
|
88
|
+
- id: experiment-execution
|
|
89
|
+
name: Experiment Execution Plan
|
|
90
|
+
description: Concrete 2-week experiments — what to do, success criteria, failure criteria, owner
|
|
91
|
+
agents:
|
|
92
|
+
- agent_id: product-director-carolina
|
|
93
|
+
role: 2-week experiment plan per top-3 assumption
|
|
94
|
+
gate:
|
|
95
|
+
type: user_approval
|
|
96
|
+
description: User approves experiment execution plan
|
|
97
|
+
|
|
98
|
+
- id: self-critique
|
|
99
|
+
name: Self-Critique
|
|
100
|
+
description: Stress-test discovery — does the chosen opportunity tie to the outcome? Are assumption tests falsifiable?
|
|
101
|
+
agents:
|
|
102
|
+
- agent_id: product-director-carolina
|
|
103
|
+
role: Coherence check
|
|
104
|
+
gate:
|
|
105
|
+
type: auto
|
|
106
|
+
|
|
107
|
+
- id: quality-gate
|
|
108
|
+
name: Quality Gate
|
|
109
|
+
model_override: opus
|
|
110
|
+
description: Mandatory quality review
|
|
111
|
+
agents:
|
|
112
|
+
- agent_id: cqo-marta
|
|
113
|
+
role: Orchestrate quality review
|
|
114
|
+
- agent_id: copy-director-eduardo
|
|
115
|
+
role: Interview script quality, synthesis prose, no leading questions
|
|
116
|
+
parallel: true
|
|
117
|
+
- agent_id: tech-director-francisca
|
|
118
|
+
role: Assumption test rigour, feasibility math, falsifiability
|
|
119
|
+
parallel: true
|
|
120
|
+
gate:
|
|
121
|
+
type: quality_gate
|
|
122
|
+
required_verdict: APPROVED
|
|
123
|
+
|
|
124
|
+
- id: delivery
|
|
125
|
+
name: Discovery Package Delivery
|
|
126
|
+
description: Compile discovery package — OST + interviews + opportunity selection + assumption tests + experiment plan
|
|
127
|
+
agents:
|
|
128
|
+
- agent_id: product-director-carolina
|
|
129
|
+
role: Full discovery package + 1-page executive summary
|
|
130
|
+
gate:
|
|
131
|
+
type: auto
|
|
132
|
+
outputs:
|
|
133
|
+
- type: document
|
|
134
|
+
format: markdown
|
|
135
|
+
obsidian_path: "WizardingCode/Product/Discovery/"
|
|
136
|
+
description: Complete discovery package — OST + interview synthesis + opportunity selection + assumption tests + 2-week experiment plan + exec summary
|
|
@@ -0,0 +1,127 @@
|
|
|
1
|
+
id: pm-roadmap
|
|
2
|
+
name: Outcome-Driven Roadmap
|
|
3
|
+
description: Outcome-driven product roadmap (3 horizons) — replaces feature-list roadmaps with measurable outcomes and bets
|
|
4
|
+
department: pm
|
|
5
|
+
tier: enterprise
|
|
6
|
+
command: "/pm roadmap"
|
|
7
|
+
requires_branch: false
|
|
8
|
+
requires_spec: false
|
|
9
|
+
quality_gate_required: true
|
|
10
|
+
|
|
11
|
+
phases:
|
|
12
|
+
- id: brief
|
|
13
|
+
name: Roadmap Brief
|
|
14
|
+
description: Define product vision, current state, time horizon, owner organisation, stakeholders
|
|
15
|
+
agents:
|
|
16
|
+
- agent_id: product-director-carolina
|
|
17
|
+
role: Frame vision, current state, horizon, stakeholders
|
|
18
|
+
gate:
|
|
19
|
+
type: user_approval
|
|
20
|
+
description: User confirms vision and horizon
|
|
21
|
+
|
|
22
|
+
- id: outcome-definition
|
|
23
|
+
name: North Star + Outcome Tree
|
|
24
|
+
description: Define the North Star metric and 3-5 derived outcomes that decompose it
|
|
25
|
+
agents:
|
|
26
|
+
- agent_id: product-director-carolina
|
|
27
|
+
role: North Star + outcome tree definition with measurable per-outcome metrics
|
|
28
|
+
- agent_id: strategy-director-tomas
|
|
29
|
+
role: Strategic coherence — does the North Star align with company strategy?
|
|
30
|
+
parallel: true
|
|
31
|
+
gate:
|
|
32
|
+
type: user_approval
|
|
33
|
+
description: User approves North Star and outcome tree
|
|
34
|
+
outputs:
|
|
35
|
+
- type: document
|
|
36
|
+
format: markdown
|
|
37
|
+
obsidian_path: "WizardingCode/Product/Roadmap/NorthStar/"
|
|
38
|
+
description: North Star + outcome tree with metrics per outcome
|
|
39
|
+
|
|
40
|
+
- id: three-horizons
|
|
41
|
+
name: Three Horizons (Now / Next / Later)
|
|
42
|
+
description: Map work across the 3 horizons — Now (committed), Next (validating), Later (exploring)
|
|
43
|
+
agents:
|
|
44
|
+
- agent_id: product-director-carolina
|
|
45
|
+
role: Three-horizon mapping with explicit commitment levels per horizon
|
|
46
|
+
gate:
|
|
47
|
+
type: user_approval
|
|
48
|
+
description: User approves horizon mapping
|
|
49
|
+
|
|
50
|
+
- id: bet-selection
|
|
51
|
+
name: Bet Selection
|
|
52
|
+
description: For each outcome, select 1-3 bets (large, named, time-boxed efforts) with hypothesis + success criteria
|
|
53
|
+
agents:
|
|
54
|
+
- agent_id: product-director-carolina
|
|
55
|
+
role: Bet selection with hypothesis + success criteria per bet
|
|
56
|
+
- agent_id: strategy-director-tomas
|
|
57
|
+
role: Bet-outcome coherence and competitive context check
|
|
58
|
+
parallel: true
|
|
59
|
+
gate:
|
|
60
|
+
type: user_approval
|
|
61
|
+
description: User approves bet selection
|
|
62
|
+
|
|
63
|
+
- id: capacity-allocation
|
|
64
|
+
name: Capacity Allocation
|
|
65
|
+
description: Allocate team capacity across bets — fixed-time vs fixed-scope policy per bet
|
|
66
|
+
agents:
|
|
67
|
+
- agent_id: product-director-carolina
|
|
68
|
+
role: Capacity allocation with team mapping
|
|
69
|
+
- agent_id: tech-director-francisca
|
|
70
|
+
role: Technical feasibility + capacity math
|
|
71
|
+
parallel: true
|
|
72
|
+
gate:
|
|
73
|
+
type: user_approval
|
|
74
|
+
description: User approves capacity allocation
|
|
75
|
+
|
|
76
|
+
- id: communication-plan
|
|
77
|
+
name: Communication Plan
|
|
78
|
+
description: Internal stakeholder communication strategy — what each audience sees, how often, what's redacted
|
|
79
|
+
agents:
|
|
80
|
+
- agent_id: product-director-carolina
|
|
81
|
+
role: Per-audience roadmap view (exec / engineering / sales / customer-facing)
|
|
82
|
+
- agent_id: copy-director-eduardo
|
|
83
|
+
role: Per-audience copy adaptations
|
|
84
|
+
parallel: true
|
|
85
|
+
gate:
|
|
86
|
+
type: user_approval
|
|
87
|
+
description: User approves communication strategy
|
|
88
|
+
|
|
89
|
+
- id: self-critique
|
|
90
|
+
name: Self-Critique
|
|
91
|
+
description: Stress-test the roadmap — are bets falsifiable? Does capacity match commitments? Are outcomes measurable?
|
|
92
|
+
agents:
|
|
93
|
+
- agent_id: product-director-carolina
|
|
94
|
+
role: Coherence check across outcomes / bets / capacity / horizons
|
|
95
|
+
gate:
|
|
96
|
+
type: auto
|
|
97
|
+
|
|
98
|
+
- id: quality-gate
|
|
99
|
+
name: Quality Gate
|
|
100
|
+
model_override: opus
|
|
101
|
+
description: Mandatory quality review
|
|
102
|
+
agents:
|
|
103
|
+
- agent_id: cqo-marta
|
|
104
|
+
role: Orchestrate quality review
|
|
105
|
+
- agent_id: copy-director-eduardo
|
|
106
|
+
role: Outcome prose, bet hypothesis clarity, no clichés
|
|
107
|
+
parallel: true
|
|
108
|
+
- agent_id: tech-director-francisca
|
|
109
|
+
role: Capacity math, feasibility, measurement integrity
|
|
110
|
+
parallel: true
|
|
111
|
+
gate:
|
|
112
|
+
type: quality_gate
|
|
113
|
+
required_verdict: APPROVED
|
|
114
|
+
|
|
115
|
+
- id: delivery
|
|
116
|
+
name: Roadmap Package Delivery
|
|
117
|
+
description: Compile the roadmap package + audience-specific versions
|
|
118
|
+
agents:
|
|
119
|
+
- agent_id: product-director-carolina
|
|
120
|
+
role: Full roadmap + audience-specific views + 1-page executive summary
|
|
121
|
+
gate:
|
|
122
|
+
type: auto
|
|
123
|
+
outputs:
|
|
124
|
+
- type: document
|
|
125
|
+
format: markdown
|
|
126
|
+
obsidian_path: "WizardingCode/Product/Roadmap/"
|
|
127
|
+
description: Complete roadmap — North Star + outcome tree + 3-horizon map + bet definitions + capacity allocation + per-audience communication
|
|
@@ -0,0 +1,136 @@
|
|
|
1
|
+
id: pm-shape
|
|
2
|
+
name: Shape Up Pitch
|
|
3
|
+
description: Shape Up pitch (Basecamp method) — appetite + problem + solution sketch + rabbit holes + no-gos for a 6-week build cycle
|
|
4
|
+
department: pm
|
|
5
|
+
tier: enterprise
|
|
6
|
+
command: "/pm shape"
|
|
7
|
+
requires_branch: false
|
|
8
|
+
requires_spec: false
|
|
9
|
+
quality_gate_required: true
|
|
10
|
+
|
|
11
|
+
phases:
|
|
12
|
+
- id: brief
|
|
13
|
+
name: Shaping Brief
|
|
14
|
+
description: Define the raw problem, the appetite (2 / 4 / 6 weeks), the people who'll build it
|
|
15
|
+
agents:
|
|
16
|
+
- agent_id: product-director-carolina
|
|
17
|
+
role: Frame raw problem, set appetite, name the build team
|
|
18
|
+
gate:
|
|
19
|
+
type: user_approval
|
|
20
|
+
description: User confirms problem, appetite, and team
|
|
21
|
+
|
|
22
|
+
- id: setting-boundaries
|
|
23
|
+
name: Setting Boundaries
|
|
24
|
+
description: Define what's IN scope and what's OUT — appetite is the constraint, fixed time variable scope
|
|
25
|
+
agents:
|
|
26
|
+
- agent_id: product-director-carolina
|
|
27
|
+
role: Scope definition — IN list, OUT list, explicit no-gos
|
|
28
|
+
gate:
|
|
29
|
+
type: user_approval
|
|
30
|
+
description: User approves scope boundaries
|
|
31
|
+
|
|
32
|
+
- id: rough-solution
|
|
33
|
+
name: Rough Solution
|
|
34
|
+
description: Sketch the solution at the right altitude — fat marker level, not pixel level. Just enough to commit
|
|
35
|
+
agents:
|
|
36
|
+
- agent_id: product-director-carolina
|
|
37
|
+
role: Solution sketch with fat-marker fidelity
|
|
38
|
+
- agent_id: ux-designer-sofia-d
|
|
39
|
+
role: User flow at fat-marker level
|
|
40
|
+
parallel: true
|
|
41
|
+
gate:
|
|
42
|
+
type: user_approval
|
|
43
|
+
description: User approves rough solution
|
|
44
|
+
outputs:
|
|
45
|
+
- type: document
|
|
46
|
+
format: markdown
|
|
47
|
+
obsidian_path: "WizardingCode/Product/Shape/Solutions/"
|
|
48
|
+
description: Fat-marker solution sketch with user flow
|
|
49
|
+
|
|
50
|
+
- id: rabbit-holes
|
|
51
|
+
name: Rabbit Holes
|
|
52
|
+
description: Identify rabbit holes — risks, unknowns, technical debt traps — and either eliminate them in shaping or surface as risks
|
|
53
|
+
agents:
|
|
54
|
+
- agent_id: product-director-carolina
|
|
55
|
+
role: Rabbit hole identification + mitigation strategy per hole
|
|
56
|
+
- agent_id: tech-director-francisca
|
|
57
|
+
role: Technical rabbit holes (data, integration, dependency)
|
|
58
|
+
parallel: true
|
|
59
|
+
gate:
|
|
60
|
+
type: user_approval
|
|
61
|
+
description: User approves rabbit hole mitigation strategy
|
|
62
|
+
|
|
63
|
+
- id: no-gos
|
|
64
|
+
name: No-Gos
|
|
65
|
+
description: Explicitly name what's NOT being built — features that look related but aren't part of this bet
|
|
66
|
+
agents:
|
|
67
|
+
- agent_id: product-director-carolina
|
|
68
|
+
role: No-gos list with rationale per item
|
|
69
|
+
gate:
|
|
70
|
+
type: auto
|
|
71
|
+
|
|
72
|
+
- id: pitch-document
|
|
73
|
+
name: Pitch Document
|
|
74
|
+
description: Compile the pitch — problem + appetite + solution + rabbit holes + no-gos + nobody-decisions
|
|
75
|
+
agents:
|
|
76
|
+
- agent_id: product-director-carolina
|
|
77
|
+
role: Full Shape Up pitch document with all 5 sections
|
|
78
|
+
- agent_id: copy-director-eduardo
|
|
79
|
+
role: Pitch readability — does it commit the reader to a decision?
|
|
80
|
+
parallel: true
|
|
81
|
+
gate:
|
|
82
|
+
type: user_approval
|
|
83
|
+
description: User approves pitch document before betting table
|
|
84
|
+
|
|
85
|
+
- id: betting-decision
|
|
86
|
+
name: Betting Table Decision
|
|
87
|
+
description: Decide GO / NO-GO / RESHAPE at the betting table — does the appetite, solution, and team fit the next cycle?
|
|
88
|
+
agents:
|
|
89
|
+
- agent_id: product-director-carolina
|
|
90
|
+
role: Betting decision with rationale
|
|
91
|
+
- agent_id: strategy-director-tomas
|
|
92
|
+
role: Strategic alignment check
|
|
93
|
+
parallel: true
|
|
94
|
+
gate:
|
|
95
|
+
type: user_approval
|
|
96
|
+
description: User makes the betting decision (GO / NO-GO / RESHAPE)
|
|
97
|
+
|
|
98
|
+
- id: self-critique
|
|
99
|
+
name: Self-Critique
|
|
100
|
+
description: Stress-test the pitch — is the appetite realistic? Are rabbit holes fully named? Are no-gos enforced?
|
|
101
|
+
agents:
|
|
102
|
+
- agent_id: product-director-carolina
|
|
103
|
+
role: Pitch coherence check
|
|
104
|
+
gate:
|
|
105
|
+
type: auto
|
|
106
|
+
|
|
107
|
+
- id: quality-gate
|
|
108
|
+
name: Quality Gate
|
|
109
|
+
model_override: opus
|
|
110
|
+
description: Mandatory quality review
|
|
111
|
+
agents:
|
|
112
|
+
- agent_id: cqo-marta
|
|
113
|
+
role: Orchestrate quality review
|
|
114
|
+
- agent_id: copy-director-eduardo
|
|
115
|
+
role: Pitch prose, no over-promise, decision-forcing language
|
|
116
|
+
parallel: true
|
|
117
|
+
- agent_id: tech-director-francisca
|
|
118
|
+
role: Appetite × scope feasibility, rabbit hole completeness
|
|
119
|
+
parallel: true
|
|
120
|
+
gate:
|
|
121
|
+
type: quality_gate
|
|
122
|
+
required_verdict: APPROVED
|
|
123
|
+
|
|
124
|
+
- id: delivery
|
|
125
|
+
name: Pitch Package Delivery
|
|
126
|
+
description: Compile the pitch package — pitch doc + rabbit hole register + betting decision + handoff to build team
|
|
127
|
+
agents:
|
|
128
|
+
- agent_id: product-director-carolina
|
|
129
|
+
role: Full pitch package + handoff brief for build team
|
|
130
|
+
gate:
|
|
131
|
+
type: auto
|
|
132
|
+
outputs:
|
|
133
|
+
- type: document
|
|
134
|
+
format: markdown
|
|
135
|
+
obsidian_path: "WizardingCode/Product/Shape/"
|
|
136
|
+
description: Complete pitch package — pitch doc + rabbit hole register + no-gos + betting decision + build-team handoff
|
package/package.json
CHANGED