arkaos 2.57.0 → 2.59.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 +1 -1
- package/departments/ecom/skills/product-launch/SKILL.md +165 -6
- package/departments/ecom/workflows/audit.yaml +130 -0
- package/departments/ecom/workflows/launch.yaml +137 -0
- package/departments/ecom/workflows/marketplace.yaml +139 -0
- package/departments/org/skills/culture-define/SKILL.md +143 -6
- package/departments/org/workflows/culture.yaml +134 -0
- package/package.json +1 -1
- package/pyproject.toml +1 -1
package/VERSION
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
2.
|
|
1
|
+
2.59.0
|
|
@@ -1,7 +1,9 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: ecom/product-launch
|
|
3
3
|
description: >
|
|
4
|
-
|
|
4
|
+
E-commerce product launch plan — positioning + pricing ladder + content
|
|
5
|
+
assets + channel mix + ad creative + day-by-day launch sequence + post-
|
|
6
|
+
launch optimisation triggers.
|
|
5
7
|
allowed-tools: [Read, Write, Edit, Bash, Grep, Glob, Agent, WebFetch, WebSearch]
|
|
6
8
|
---
|
|
7
9
|
|
|
@@ -21,12 +23,169 @@ does not replace the vault.
|
|
|
21
23
|
|
|
22
24
|
# Product Launch — `/ecom launch <product>`
|
|
23
25
|
|
|
24
|
-
> **
|
|
26
|
+
> **Lead:** Ricardo (E-Commerce Director) | **Cross-dept:** Mateus (Brand) + Helena (CFO) + Luna (Marketing) + Pedro (Paid) + Isabel (Visual) + Eduardo (Copy) | **Framework:** GTM × Launch Sequence + Inventory-Aware Demand Curve
|
|
25
27
|
|
|
26
|
-
## What
|
|
28
|
+
## What ships
|
|
27
29
|
|
|
28
|
-
|
|
30
|
+
A production launch package in 7 deliverables:
|
|
29
31
|
|
|
30
|
-
|
|
32
|
+
1. **Positioning** — competitive set + onlyness frame + price tier
|
|
33
|
+
2. **Pricing ladder** — anchor + main + promo + bundle with margin math per tier
|
|
34
|
+
3. **Content assets** — product page + photo brief + video brief + email + social copy
|
|
35
|
+
4. **Channel mix** — owned + marketplace + paid + organic + partnerships per priority
|
|
36
|
+
5. **Ad creative plan** — static + video + UGC + retargeting per channel
|
|
37
|
+
6. **Day-by-day launch sequence** — soft launch through post-launch optimisation
|
|
38
|
+
7. **Executive summary** — 1-page printable with sales target + kill-switch criterion
|
|
31
39
|
|
|
32
|
-
|
|
40
|
+
## Positioning Frame (e-commerce specific)
|
|
41
|
+
|
|
42
|
+
Position the SKU on three axes simultaneously:
|
|
43
|
+
|
|
44
|
+
1. **Competitive set** — name 3-5 directly competing SKUs across price tiers
|
|
45
|
+
2. **Differentiation angle** — what's the one thing this SKU does that the competitive set doesn't
|
|
46
|
+
3. **Price tier** — entry / mid / premium / luxury with explicit anchor comparison
|
|
47
|
+
|
|
48
|
+
Format:
|
|
49
|
+
```yaml
|
|
50
|
+
positioning:
|
|
51
|
+
category: <product category>
|
|
52
|
+
competitive_set: [<SKU 1>, <SKU 2>, <SKU 3>]
|
|
53
|
+
onlyness: "The only <category> that <unique mechanism> for <customer> who want <outcome>"
|
|
54
|
+
price_tier: entry | mid | premium | luxury
|
|
55
|
+
anchor_competitor: <SKU we benchmark against>
|
|
56
|
+
anchor_price: <competitor price>
|
|
57
|
+
our_price: <price + delta vs anchor + rationale>
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
## Pricing Ladder
|
|
61
|
+
|
|
62
|
+
Every launch ships with a 4-tier pricing ladder, not a single price:
|
|
63
|
+
|
|
64
|
+
| Tier | Use | Margin floor | When to show |
|
|
65
|
+
|---|---|---|---|
|
|
66
|
+
| **Anchor** | Shown crossed-out to anchor perception | n/a (decorative) | First view |
|
|
67
|
+
| **Main** | Default offer | Gross margin ≥ category benchmark | Default state |
|
|
68
|
+
| **Promo** | Limited-time deal (launch week, holiday) | Gross margin ≥ 60% of main | Launch week + scarcity moments |
|
|
69
|
+
| **Bundle** | Multi-SKU or main + accessory | Combined margin ≥ main × 1.3 | Cart upsell |
|
|
70
|
+
|
|
71
|
+
Margin math must close at every tier. Promo prices that don't cover variable costs are not promos — they're losses.
|
|
72
|
+
|
|
73
|
+
## Content Asset Inventory
|
|
74
|
+
|
|
75
|
+
Required assets per launch:
|
|
76
|
+
|
|
77
|
+
```yaml
|
|
78
|
+
content_assets:
|
|
79
|
+
product_page:
|
|
80
|
+
- hero_image: 1
|
|
81
|
+
- lifestyle_images: 3-5
|
|
82
|
+
- detail_shots: 3-5
|
|
83
|
+
- video: 15-30s
|
|
84
|
+
- bullets: 5-7
|
|
85
|
+
- long_description: 200-400 words
|
|
86
|
+
- faq: 5-8 questions
|
|
87
|
+
|
|
88
|
+
email:
|
|
89
|
+
- launch_announcement: 1
|
|
90
|
+
- reminder_24h_before: 1
|
|
91
|
+
- launch_day: 1
|
|
92
|
+
- day_3_social_proof: 1
|
|
93
|
+
- day_7_last_chance: 1
|
|
94
|
+
|
|
95
|
+
social:
|
|
96
|
+
- announcement_post: 3-5 platforms × 1 format
|
|
97
|
+
- launch_day_post: 3-5 platforms × 1 format
|
|
98
|
+
- countdown_stories: 3-7 days
|
|
99
|
+
|
|
100
|
+
ad_creative:
|
|
101
|
+
- static_image: 5-10 variants
|
|
102
|
+
- video_15s: 3-5 variants
|
|
103
|
+
- video_30s: 2-3 variants
|
|
104
|
+
- ugc_request_brief: 1
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
## Channel Mix Priority
|
|
108
|
+
|
|
109
|
+
Channel ramp follows a deliberate sequence. Day-0 is not "everywhere at once" — it's a controlled wedge.
|
|
110
|
+
|
|
111
|
+
| Priority | Day 0 | Week 1 | Month 1 | Why this order |
|
|
112
|
+
|---|---|---|---|---|
|
|
113
|
+
| 1 | Email list (warm) | Email + retargeting | Email + retargeting + organic | Warmest audience first, validates demand signal |
|
|
114
|
+
| 2 | Direct traffic + organic | Direct + organic + meta paid | Add marketplace listing | Earned reach before paid |
|
|
115
|
+
| 3 | Marketplace listing | Paid scale-up | TikTok / influencer | Paid only after CR validated |
|
|
116
|
+
| 4 | Influencer outreach | Influencer publishes | Affiliate program | Third-party signal once core demand proven |
|
|
117
|
+
|
|
118
|
+
Skipping the warm-audience-first step burns paid spend on uninformed buyers and produces unstable CR baselines.
|
|
119
|
+
|
|
120
|
+
## Day-by-Day Launch Sequence Template
|
|
121
|
+
|
|
122
|
+
```
|
|
123
|
+
T-30 Inventory commit + content brief signed off
|
|
124
|
+
T-21 Photo + video shoot
|
|
125
|
+
T-14 Product page in staging
|
|
126
|
+
T-7 Email warm-up (#1 sent — "something's coming")
|
|
127
|
+
T-3 Email reminder (#2 sent — date + sneak peek)
|
|
128
|
+
T-0 LAUNCH:
|
|
129
|
+
06:00 — Product page live
|
|
130
|
+
08:00 — Email blast to full list
|
|
131
|
+
10:00 — Social announcement (all platforms)
|
|
132
|
+
12:00 — First-hour analytics check (CR, AOV, traffic)
|
|
133
|
+
14:00 — Retargeting ads live (only if signal positive)
|
|
134
|
+
16:00 — Live-stream / Q&A if applicable
|
|
135
|
+
20:00 — End-of-day metrics review + decision: continue ramp or pause
|
|
136
|
+
T+1 Day-2 email + paid ramp decision
|
|
137
|
+
T+3 Social proof email (real customer reactions)
|
|
138
|
+
T+7 "Last chance for launch pricing" email
|
|
139
|
+
T+8 Move to evergreen pricing
|
|
140
|
+
T+14 Post-launch retrospective + decision (scale / iterate / kill)
|
|
141
|
+
```
|
|
142
|
+
|
|
143
|
+
Each step has a named owner and a success criterion. The "decision: continue ramp or pause" gate at T+0 evening is the load-bearing one — preventing wasted paid spend on a dud.
|
|
144
|
+
|
|
145
|
+
## Inventory-Aware Demand Curve
|
|
146
|
+
|
|
147
|
+
Match channel ramp to inventory levels:
|
|
148
|
+
|
|
149
|
+
```yaml
|
|
150
|
+
inventory_demand_curve:
|
|
151
|
+
units_in_stock: <N>
|
|
152
|
+
base_sales_velocity: <units per day at baseline>
|
|
153
|
+
launch_uplift_factor: 5-15x baseline typical
|
|
154
|
+
days_of_stock_at_launch_velocity: <calculated>
|
|
155
|
+
|
|
156
|
+
scenarios:
|
|
157
|
+
sold_out_before_day_3:
|
|
158
|
+
action: "Throttle paid spend immediately, switch promo to 'next batch' positioning"
|
|
159
|
+
pre_emptive: "Set inventory alert at 30% stock; cap ad spend automatically"
|
|
160
|
+
sold_out_between_day_3_and_day_7:
|
|
161
|
+
action: "Pause paid Day 4, reactivate when restock confirmed"
|
|
162
|
+
pre_emptive: "Pre-order option live by Day 3 if velocity > 2x projection"
|
|
163
|
+
sells_through_below_projection:
|
|
164
|
+
action: "Switch to discovery-mode messaging, increase retargeting frequency"
|
|
165
|
+
pre_emptive: "Have 'discovery angle 2' copy variant pre-approved for fast swap"
|
|
166
|
+
```
|
|
167
|
+
|
|
168
|
+
Launches that ignore inventory produce either backorder customer-experience disasters or markdown-spiral losses.
|
|
169
|
+
|
|
170
|
+
## Kill-Switch Criteria (named upfront)
|
|
171
|
+
|
|
172
|
+
Every launch ships with explicit kill criteria — if any fires, stop spending paid budget:
|
|
173
|
+
|
|
174
|
+
- Day-0 CR < 50% of category benchmark
|
|
175
|
+
- Day-3 cumulative AOV < 80% of projected
|
|
176
|
+
- Day-7 return rate > 2× category baseline
|
|
177
|
+
- Day-7 negative-review-to-purchase ratio > category baseline
|
|
178
|
+
|
|
179
|
+
Kill-switch criteria stated upfront prevent the "let's just spend more to make it work" trap.
|
|
180
|
+
|
|
181
|
+
## Common Failure Modes
|
|
182
|
+
|
|
183
|
+
1. **Single-price launch** — no ladder, leaves margin on the table and removes promo lever
|
|
184
|
+
2. **Channel-everywhere day-0** — burns paid spend before CR signal is validated
|
|
185
|
+
3. **Inventory-blind ramp** — sells out at peak demand or markdowns at post-peak slump
|
|
186
|
+
4. **No kill-switch** — bad launches drag on consuming budget without falsification path
|
|
187
|
+
5. **Asset shortage** — running launch with incomplete photo/video set produces below-benchmark CR
|
|
188
|
+
|
|
189
|
+
## Output → Obsidian: `WizardingCode/Ecom/Launches/<product>-<date>/`
|
|
190
|
+
|
|
191
|
+
Delivers: positioning + pricing ladder (margin math per tier) + content asset inventory + channel mix priority + day-by-day launch sequence + ad creative plan + inventory-aware demand curve + kill-switch criteria + 1-page executive summary.
|
|
@@ -0,0 +1,130 @@
|
|
|
1
|
+
id: ecom-audit
|
|
2
|
+
name: Store Audit
|
|
3
|
+
description: Full e-commerce store audit — UX + SEO + performance + content + conversion — with ranked remediation plan
|
|
4
|
+
department: ecom
|
|
5
|
+
tier: enterprise
|
|
6
|
+
command: "/ecom audit"
|
|
7
|
+
requires_branch: false
|
|
8
|
+
requires_spec: false
|
|
9
|
+
quality_gate_required: true
|
|
10
|
+
|
|
11
|
+
phases:
|
|
12
|
+
- id: brief
|
|
13
|
+
name: Audit Brief
|
|
14
|
+
description: Define store URL, vertical, audience, primary KPI, scope of audit
|
|
15
|
+
agents:
|
|
16
|
+
- agent_id: ecom-director-ricardo
|
|
17
|
+
role: Frame store, vertical, baseline KPIs (conversion rate, AOV, traffic mix)
|
|
18
|
+
gate:
|
|
19
|
+
type: user_approval
|
|
20
|
+
description: User confirms audit scope and baseline KPIs
|
|
21
|
+
|
|
22
|
+
- id: ux-audit
|
|
23
|
+
name: UX Audit (Baymard + Nielsen)
|
|
24
|
+
description: Baymard 76-criteria checklist + Nielsen 10 heuristics audit on key flows
|
|
25
|
+
agents:
|
|
26
|
+
- agent_id: ux-designer-sofia-d
|
|
27
|
+
role: UX audit with criteria-level scoring per key flow (homepage / category / PDP / cart / checkout)
|
|
28
|
+
gate:
|
|
29
|
+
type: user_approval
|
|
30
|
+
description: User approves UX audit
|
|
31
|
+
outputs:
|
|
32
|
+
- type: document
|
|
33
|
+
format: markdown
|
|
34
|
+
obsidian_path: "WizardingCode/Ecom/Audits/UX/"
|
|
35
|
+
description: UX audit with Baymard + Nielsen scores per flow
|
|
36
|
+
|
|
37
|
+
- id: seo-audit
|
|
38
|
+
name: SEO Audit
|
|
39
|
+
description: Technical SEO + on-page + content audit
|
|
40
|
+
agents:
|
|
41
|
+
- agent_id: seo-specialist-ana
|
|
42
|
+
role: Technical SEO (Core Web Vitals + crawl + index + schema) + on-page audit (title + meta + content + internal links)
|
|
43
|
+
gate:
|
|
44
|
+
type: user_approval
|
|
45
|
+
description: User approves SEO audit
|
|
46
|
+
|
|
47
|
+
- id: performance-audit
|
|
48
|
+
name: Performance Audit
|
|
49
|
+
description: Core Web Vitals + page weight + render path + mobile performance
|
|
50
|
+
agents:
|
|
51
|
+
- agent_id: ux-designer-sofia-d
|
|
52
|
+
role: Performance audit with LCP/INP/CLS + page weight + render-blocking analysis per key flow
|
|
53
|
+
gate:
|
|
54
|
+
type: user_approval
|
|
55
|
+
description: User approves performance audit
|
|
56
|
+
|
|
57
|
+
- id: content-audit
|
|
58
|
+
name: Content Audit
|
|
59
|
+
description: Product copy + category copy + about + policies + brand voice consistency
|
|
60
|
+
agents:
|
|
61
|
+
- agent_id: copy-director-eduardo
|
|
62
|
+
role: Content audit with brand voice consistency check + copy quality scoring
|
|
63
|
+
gate:
|
|
64
|
+
type: user_approval
|
|
65
|
+
description: User approves content audit
|
|
66
|
+
|
|
67
|
+
- id: conversion-audit
|
|
68
|
+
name: Conversion Audit
|
|
69
|
+
description: ResearchXL framework — heuristic + quantitative + qualitative + technical
|
|
70
|
+
agents:
|
|
71
|
+
- agent_id: conversion-strategist-ines
|
|
72
|
+
role: ResearchXL audit across all 4 dimensions, identifies top 10 conversion friction points
|
|
73
|
+
gate:
|
|
74
|
+
type: user_approval
|
|
75
|
+
description: User approves conversion audit
|
|
76
|
+
outputs:
|
|
77
|
+
- type: document
|
|
78
|
+
format: markdown
|
|
79
|
+
obsidian_path: "WizardingCode/Ecom/Audits/Conversion/"
|
|
80
|
+
description: ResearchXL conversion audit with top 10 friction points
|
|
81
|
+
|
|
82
|
+
- id: ranked-remediation
|
|
83
|
+
name: Ranked Remediation Plan
|
|
84
|
+
description: ICE prioritisation of all findings across UX + SEO + Performance + Content + Conversion
|
|
85
|
+
agents:
|
|
86
|
+
- agent_id: ecom-director-ricardo
|
|
87
|
+
role: ICE scoring per finding, ranked remediation plan with effort estimates
|
|
88
|
+
gate:
|
|
89
|
+
type: user_approval
|
|
90
|
+
description: User approves ranked remediation
|
|
91
|
+
|
|
92
|
+
- id: self-critique
|
|
93
|
+
name: Self-Critique
|
|
94
|
+
description: Stress-test the audit — is every finding evidence-backed? Are remediations sized correctly?
|
|
95
|
+
agents:
|
|
96
|
+
- agent_id: ecom-director-ricardo
|
|
97
|
+
role: Audit coherence + remediation feasibility check
|
|
98
|
+
gate:
|
|
99
|
+
type: auto
|
|
100
|
+
|
|
101
|
+
- id: quality-gate
|
|
102
|
+
name: Quality Gate
|
|
103
|
+
model_override: opus
|
|
104
|
+
description: Mandatory quality review
|
|
105
|
+
agents:
|
|
106
|
+
- agent_id: cqo-marta
|
|
107
|
+
role: Orchestrate quality review
|
|
108
|
+
- agent_id: copy-director-eduardo
|
|
109
|
+
role: Audit prose, scoring rationale clarity, no clichés
|
|
110
|
+
parallel: true
|
|
111
|
+
- agent_id: tech-director-francisca
|
|
112
|
+
role: Technical findings accuracy, scoring math, prioritisation rigour
|
|
113
|
+
parallel: true
|
|
114
|
+
gate:
|
|
115
|
+
type: quality_gate
|
|
116
|
+
required_verdict: APPROVED
|
|
117
|
+
|
|
118
|
+
- id: delivery
|
|
119
|
+
name: Audit Report Delivery
|
|
120
|
+
description: Compile full audit + executive summary + 30-day quick-win plan + 90-day strategic plan
|
|
121
|
+
agents:
|
|
122
|
+
- agent_id: ecom-director-ricardo
|
|
123
|
+
role: Full audit report + executive summary + 30/90-day plans
|
|
124
|
+
gate:
|
|
125
|
+
type: auto
|
|
126
|
+
outputs:
|
|
127
|
+
- type: document
|
|
128
|
+
format: markdown
|
|
129
|
+
obsidian_path: "WizardingCode/Ecom/Audits/"
|
|
130
|
+
description: Complete store audit — UX + SEO + Performance + Content + Conversion + ranked remediation + 30-day + 90-day plans + exec summary
|
|
@@ -0,0 +1,137 @@
|
|
|
1
|
+
id: ecom-launch
|
|
2
|
+
name: Product Launch (E-commerce)
|
|
3
|
+
description: Product launch plan for an e-commerce SKU or collection — positioning + pricing + content + distribution + ad creative + post-launch optimisation
|
|
4
|
+
department: ecom
|
|
5
|
+
tier: enterprise
|
|
6
|
+
command: "/ecom launch"
|
|
7
|
+
requires_branch: false
|
|
8
|
+
requires_spec: false
|
|
9
|
+
quality_gate_required: true
|
|
10
|
+
|
|
11
|
+
phases:
|
|
12
|
+
- id: brief
|
|
13
|
+
name: Launch Brief
|
|
14
|
+
description: Define product, target customer, launch date, sales target, budget, inventory commit
|
|
15
|
+
agents:
|
|
16
|
+
- agent_id: ecom-director-ricardo
|
|
17
|
+
role: Frame product, target customer, launch date, sales target, budget
|
|
18
|
+
gate:
|
|
19
|
+
type: user_approval
|
|
20
|
+
description: User confirms product brief and launch parameters
|
|
21
|
+
|
|
22
|
+
- id: positioning
|
|
23
|
+
name: Product Positioning
|
|
24
|
+
description: Position the SKU — competitive set, differentiation angle, price tier
|
|
25
|
+
agents:
|
|
26
|
+
- agent_id: ecom-director-ricardo
|
|
27
|
+
role: Positioning statement + competitive set + price tier
|
|
28
|
+
- agent_id: brand-strategist-mateus
|
|
29
|
+
role: Brand-relative positioning + onlyness frame
|
|
30
|
+
parallel: true
|
|
31
|
+
gate:
|
|
32
|
+
type: user_approval
|
|
33
|
+
description: User approves positioning
|
|
34
|
+
|
|
35
|
+
- id: pricing-strategy
|
|
36
|
+
name: Pricing Strategy
|
|
37
|
+
description: Price ladder — anchor + main + promo + bundle. Margin math per tier.
|
|
38
|
+
agents:
|
|
39
|
+
- agent_id: ecom-director-ricardo
|
|
40
|
+
role: Price ladder with margin per tier
|
|
41
|
+
- agent_id: cfo-helena
|
|
42
|
+
role: Margin floor + promo economics check
|
|
43
|
+
parallel: true
|
|
44
|
+
gate:
|
|
45
|
+
type: user_approval
|
|
46
|
+
description: User approves pricing strategy
|
|
47
|
+
|
|
48
|
+
- id: content-assets
|
|
49
|
+
name: Content Assets
|
|
50
|
+
description: Product page copy + photography brief + video brief + email copy + social copy
|
|
51
|
+
agents:
|
|
52
|
+
- agent_id: ecom-director-ricardo
|
|
53
|
+
role: Content asset inventory with delivery dates
|
|
54
|
+
- agent_id: copy-director-eduardo
|
|
55
|
+
role: Product page + email + social copy
|
|
56
|
+
parallel: true
|
|
57
|
+
- agent_id: visual-designer-isabel
|
|
58
|
+
role: Photography + video brief specs
|
|
59
|
+
parallel: true
|
|
60
|
+
gate:
|
|
61
|
+
type: user_approval
|
|
62
|
+
description: User approves content assets
|
|
63
|
+
|
|
64
|
+
- id: distribution-channels
|
|
65
|
+
name: Distribution Channels
|
|
66
|
+
description: Channel mix — owned channels + marketplace + paid + organic + partnerships
|
|
67
|
+
agents:
|
|
68
|
+
- agent_id: ecom-director-ricardo
|
|
69
|
+
role: Channel mix with day-0 / week-1 / month-1 priorities
|
|
70
|
+
- agent_id: marketing-director-luna
|
|
71
|
+
role: Paid + organic channel allocation
|
|
72
|
+
parallel: true
|
|
73
|
+
gate:
|
|
74
|
+
type: user_approval
|
|
75
|
+
description: User approves channel mix
|
|
76
|
+
|
|
77
|
+
- id: ad-creative
|
|
78
|
+
name: Ad Creative Plan
|
|
79
|
+
description: Ad creative across formats — static + video + UGC + retargeting
|
|
80
|
+
agents:
|
|
81
|
+
- agent_id: paid-specialist-pedro
|
|
82
|
+
role: Ad creative plan with format × channel matrix
|
|
83
|
+
- agent_id: visual-designer-isabel
|
|
84
|
+
role: Creative brief per format
|
|
85
|
+
parallel: true
|
|
86
|
+
gate:
|
|
87
|
+
type: auto
|
|
88
|
+
|
|
89
|
+
- id: launch-sequence
|
|
90
|
+
name: Launch Sequence
|
|
91
|
+
description: Day-by-day sequence — soft launch, hard launch, post-launch optimisation triggers
|
|
92
|
+
agents:
|
|
93
|
+
- agent_id: ecom-director-ricardo
|
|
94
|
+
role: Day-by-day launch sequence with daily success criteria
|
|
95
|
+
gate:
|
|
96
|
+
type: user_approval
|
|
97
|
+
description: User approves launch sequence
|
|
98
|
+
|
|
99
|
+
- id: self-critique
|
|
100
|
+
name: Self-Critique
|
|
101
|
+
description: Stress-test the launch — does inventory match demand projection? Are channel ramp curves realistic? Is the kill-switch criterion clear?
|
|
102
|
+
agents:
|
|
103
|
+
- agent_id: ecom-director-ricardo
|
|
104
|
+
role: Launch coherence + inventory + ramp curve check
|
|
105
|
+
gate:
|
|
106
|
+
type: auto
|
|
107
|
+
|
|
108
|
+
- id: quality-gate
|
|
109
|
+
name: Quality Gate
|
|
110
|
+
model_override: opus
|
|
111
|
+
description: Mandatory quality review
|
|
112
|
+
agents:
|
|
113
|
+
- agent_id: cqo-marta
|
|
114
|
+
role: Orchestrate quality review
|
|
115
|
+
- agent_id: copy-director-eduardo
|
|
116
|
+
role: All copy quality + no over-promise + no AI clichés
|
|
117
|
+
parallel: true
|
|
118
|
+
- agent_id: tech-director-francisca
|
|
119
|
+
role: Tracking + inventory + channel-tech integrity
|
|
120
|
+
parallel: true
|
|
121
|
+
gate:
|
|
122
|
+
type: quality_gate
|
|
123
|
+
required_verdict: APPROVED
|
|
124
|
+
|
|
125
|
+
- id: delivery
|
|
126
|
+
name: Launch Package Delivery
|
|
127
|
+
description: Compile the launch package — positioning + pricing + content + channels + ads + sequence + analytics + executive summary
|
|
128
|
+
agents:
|
|
129
|
+
- agent_id: ecom-director-ricardo
|
|
130
|
+
role: Full launch package + executive summary
|
|
131
|
+
gate:
|
|
132
|
+
type: auto
|
|
133
|
+
outputs:
|
|
134
|
+
- type: document
|
|
135
|
+
format: markdown
|
|
136
|
+
obsidian_path: "WizardingCode/Ecom/Launches/"
|
|
137
|
+
description: Complete launch package — positioning + pricing + content + distribution + ad creative + launch sequence + exec summary
|
|
@@ -0,0 +1,139 @@
|
|
|
1
|
+
id: ecom-marketplace
|
|
2
|
+
name: Marketplace Operations
|
|
3
|
+
description: Marketplace operations setup or optimization (Mirakl, multi-vendor, Amazon/Shopify) — catalog + onboarding + orders + payments + analytics
|
|
4
|
+
department: ecom
|
|
5
|
+
tier: enterprise
|
|
6
|
+
command: "/ecom marketplace"
|
|
7
|
+
requires_branch: false
|
|
8
|
+
requires_spec: false
|
|
9
|
+
quality_gate_required: true
|
|
10
|
+
|
|
11
|
+
phases:
|
|
12
|
+
- id: brief
|
|
13
|
+
name: Marketplace Brief
|
|
14
|
+
description: Define marketplace type (operator vs participant), platform, vendor scale target, vertical
|
|
15
|
+
agents:
|
|
16
|
+
- agent_id: ecom-director-ricardo
|
|
17
|
+
role: Frame marketplace type, platform, vendor scale, vertical
|
|
18
|
+
gate:
|
|
19
|
+
type: user_approval
|
|
20
|
+
description: User confirms marketplace context
|
|
21
|
+
|
|
22
|
+
- id: governance-model
|
|
23
|
+
name: Governance Model
|
|
24
|
+
description: Define curated vs open, commission model, vendor approval criteria, content moderation
|
|
25
|
+
agents:
|
|
26
|
+
- agent_id: ecom-director-ricardo
|
|
27
|
+
role: Governance model with curation criteria + commission economics + moderation policy
|
|
28
|
+
- agent_id: strategy-director-tomas
|
|
29
|
+
role: Strategic positioning — vertical specialisation vs horizontal
|
|
30
|
+
parallel: true
|
|
31
|
+
gate:
|
|
32
|
+
type: user_approval
|
|
33
|
+
description: User approves governance model
|
|
34
|
+
outputs:
|
|
35
|
+
- type: document
|
|
36
|
+
format: markdown
|
|
37
|
+
obsidian_path: "WizardingCode/Ecom/Marketplace/Governance/"
|
|
38
|
+
description: Governance model with curation + commission + moderation policies
|
|
39
|
+
|
|
40
|
+
- id: catalog-architecture
|
|
41
|
+
name: Catalog Architecture
|
|
42
|
+
description: Taxonomy, attribute schema, normalisation rules, deduplication strategy
|
|
43
|
+
agents:
|
|
44
|
+
- agent_id: ecom-director-ricardo
|
|
45
|
+
role: Taxonomy + attribute schema + dedup strategy
|
|
46
|
+
- agent_id: tech-director-francisca
|
|
47
|
+
role: Schema technical feasibility + ETL pipeline implications
|
|
48
|
+
parallel: true
|
|
49
|
+
gate:
|
|
50
|
+
type: user_approval
|
|
51
|
+
description: User approves catalog architecture
|
|
52
|
+
|
|
53
|
+
- id: vendor-onboarding
|
|
54
|
+
name: Vendor Onboarding Flow
|
|
55
|
+
description: Onboarding flow — application + verification + agreement + training + first-listing
|
|
56
|
+
agents:
|
|
57
|
+
- agent_id: ecom-director-ricardo
|
|
58
|
+
role: Onboarding flow with friction-vs-quality trade-off explicit
|
|
59
|
+
- agent_id: ux-designer-sofia-d
|
|
60
|
+
role: Onboarding UX with completion targets per step
|
|
61
|
+
parallel: true
|
|
62
|
+
gate:
|
|
63
|
+
type: user_approval
|
|
64
|
+
description: User approves onboarding flow
|
|
65
|
+
|
|
66
|
+
- id: order-fulfilment
|
|
67
|
+
name: Order & Fulfilment Flow
|
|
68
|
+
description: Order routing + fulfilment SLA + returns/refunds + dispute resolution
|
|
69
|
+
agents:
|
|
70
|
+
- agent_id: ecom-director-ricardo
|
|
71
|
+
role: Order flow design + SLA spec + dispute resolution policy
|
|
72
|
+
gate:
|
|
73
|
+
type: user_approval
|
|
74
|
+
description: User approves order/fulfilment flow
|
|
75
|
+
|
|
76
|
+
- id: payments-payouts
|
|
77
|
+
name: Payments & Payouts
|
|
78
|
+
description: Payment processing model + split-payment to vendors + escrow + chargeback handling
|
|
79
|
+
agents:
|
|
80
|
+
- agent_id: ecom-director-ricardo
|
|
81
|
+
role: Payment + payout model with chargeback handling policy
|
|
82
|
+
- agent_id: cfo-helena
|
|
83
|
+
role: Cash flow + escrow capital requirement check
|
|
84
|
+
parallel: true
|
|
85
|
+
gate:
|
|
86
|
+
type: user_approval
|
|
87
|
+
description: User approves payments model
|
|
88
|
+
|
|
89
|
+
- id: analytics-stack
|
|
90
|
+
name: Analytics Stack
|
|
91
|
+
description: Vendor-facing analytics + operator analytics + customer-facing trust signals
|
|
92
|
+
agents:
|
|
93
|
+
- agent_id: ecom-director-ricardo
|
|
94
|
+
role: Analytics layer with per-audience views
|
|
95
|
+
- agent_id: tech-director-francisca
|
|
96
|
+
role: Data pipeline feasibility
|
|
97
|
+
parallel: true
|
|
98
|
+
gate:
|
|
99
|
+
type: auto
|
|
100
|
+
|
|
101
|
+
- id: self-critique
|
|
102
|
+
name: Self-Critique
|
|
103
|
+
description: Stress-test the model — does governance scale? Is fulfilment SLA enforceable? Does the take-rate math close?
|
|
104
|
+
agents:
|
|
105
|
+
- agent_id: ecom-director-ricardo
|
|
106
|
+
role: Coherence + scalability + economics check
|
|
107
|
+
gate:
|
|
108
|
+
type: auto
|
|
109
|
+
|
|
110
|
+
- id: quality-gate
|
|
111
|
+
name: Quality Gate
|
|
112
|
+
model_override: opus
|
|
113
|
+
description: Mandatory quality review
|
|
114
|
+
agents:
|
|
115
|
+
- agent_id: cqo-marta
|
|
116
|
+
role: Orchestrate quality review
|
|
117
|
+
- agent_id: copy-director-eduardo
|
|
118
|
+
role: Policy prose, vendor-facing copy, no AI clichés
|
|
119
|
+
parallel: true
|
|
120
|
+
- agent_id: tech-director-francisca
|
|
121
|
+
role: Schema integrity, pipeline feasibility, payment model correctness
|
|
122
|
+
parallel: true
|
|
123
|
+
gate:
|
|
124
|
+
type: quality_gate
|
|
125
|
+
required_verdict: APPROVED
|
|
126
|
+
|
|
127
|
+
- id: delivery
|
|
128
|
+
name: Marketplace Package Delivery
|
|
129
|
+
description: Compile the marketplace package + 90-day launch roadmap if greenfield, or 90-day optimisation roadmap if existing
|
|
130
|
+
agents:
|
|
131
|
+
- agent_id: ecom-director-ricardo
|
|
132
|
+
role: Full marketplace package + 90-day roadmap
|
|
133
|
+
gate:
|
|
134
|
+
type: auto
|
|
135
|
+
outputs:
|
|
136
|
+
- type: document
|
|
137
|
+
format: markdown
|
|
138
|
+
obsidian_path: "WizardingCode/Ecom/Marketplace/"
|
|
139
|
+
description: Complete marketplace package — governance + catalog + onboarding + order flow + payments + analytics + 90-day roadmap
|
|
@@ -1,7 +1,9 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: org/culture-define
|
|
3
3
|
description: >
|
|
4
|
-
Culture definition
|
|
4
|
+
Culture definition — values (inversion-tested), observable behaviours,
|
|
5
|
+
reinforcing rituals, decision principles, and operationalisation in hiring
|
|
6
|
+
+ performance + promotion.
|
|
5
7
|
allowed-tools: [Read, Write, Edit, Bash, Grep, Glob, Agent, WebFetch, WebSearch]
|
|
6
8
|
---
|
|
7
9
|
|
|
@@ -21,12 +23,147 @@ does not replace the vault.
|
|
|
21
23
|
|
|
22
24
|
# Culture Define — `/org culture`
|
|
23
25
|
|
|
24
|
-
> **
|
|
26
|
+
> **Lead:** Sofia (COO) | **Cross-dept:** Tomas (Strategy) + Clara (KB) + Eduardo (Copy) + Marta (CQO) | **Frameworks:** Netflix Culture + Lencioni Five Dysfunctions + Dalio Principles + Inversion Test
|
|
25
27
|
|
|
26
|
-
## What
|
|
28
|
+
## What ships
|
|
27
29
|
|
|
28
|
-
|
|
30
|
+
A production culture document in 6 deliverables:
|
|
29
31
|
|
|
30
|
-
|
|
32
|
+
1. **Cultural archaeology** — what's already true vs aspirational
|
|
33
|
+
2. **Values set** — 4-6 values that pass the inversion test
|
|
34
|
+
3. **Behaviour map** — 3-5 observable behaviours per value
|
|
35
|
+
4. **Ritual catalogue** — value-reinforcing rituals with owners + frequency
|
|
36
|
+
5. **Decision principles** — how the org decides, disagrees, commits
|
|
37
|
+
6. **Operationalisation plan** — culture wired into hiring + onboarding + performance + promotion
|
|
31
38
|
|
|
32
|
-
|
|
39
|
+
## The Inversion Test (the only test that matters)
|
|
40
|
+
|
|
41
|
+
A value passes the inversion test if **its opposite is a defensible position held by another reputable company**. Values that fail the inversion test are platitudes, not values.
|
|
42
|
+
|
|
43
|
+
| Value | Inverse | Pass / Fail |
|
|
44
|
+
|---|---|---|
|
|
45
|
+
| "Move fast" | "Move with deliberation, premortem every change" | PASS — Boeing, surgical software vendors |
|
|
46
|
+
| "Customer obsession" | "Engineer obsession — make the system right, customers adapt" | PASS — Linux kernel, AWS internal services |
|
|
47
|
+
| "Excellence" | (no defensible opposite — nobody says "mediocrity") | FAIL — platitude |
|
|
48
|
+
| "Integrity" | (no defensible opposite — nobody says "dishonesty") | FAIL — platitude |
|
|
49
|
+
| "Bias for action" | "Bias for analysis — measure twice, cut once" | PASS — research orgs, regulated industries |
|
|
50
|
+
| "Radical candour" | "Diplomatic harmony — preserve relationships over signals" | PASS — Japanese corporate culture, diplomatic services |
|
|
51
|
+
|
|
52
|
+
If you cannot name a real company that holds the opposite position, the value is not a value. Drop it.
|
|
53
|
+
|
|
54
|
+
## Cultural Archaeology (extract before defining)
|
|
55
|
+
|
|
56
|
+
Before defining culture aspirationally, **map what already is**. Cultural artefacts to inspect:
|
|
57
|
+
|
|
58
|
+
- **Slack/Discord patterns** — who responds when, what gets celebrated, what gets ignored
|
|
59
|
+
- **Decision logs** — what got built vs what got rejected, with rationale
|
|
60
|
+
- **Founder choices** — first hires, first firings, first product cuts
|
|
61
|
+
- **Calendar reality** — what gets weekly time vs quarterly time vs never
|
|
62
|
+
- **Recognition patterns** — who gets praised publicly, for what
|
|
63
|
+
- **Conflict patterns** — how disagreement is surfaced, escalated, resolved
|
|
64
|
+
|
|
65
|
+
Map the as-is. Then compare to the desired-is. The gap between as-is and desired-is is the culture-change work — and most of it is operationalisation, not aspiration.
|
|
66
|
+
|
|
67
|
+
## Behaviour Mapping (observable + coachable)
|
|
68
|
+
|
|
69
|
+
Each value translates to 3-5 behaviours that are:
|
|
70
|
+
|
|
71
|
+
- **Observable** — a third-party could watch and identify the behaviour
|
|
72
|
+
- **Coachable** — a manager can give feedback specific to this behaviour
|
|
73
|
+
- **Inversion-defensible** — the inverse behaviour would identifiably belong to a different value
|
|
74
|
+
|
|
75
|
+
Example translation:
|
|
76
|
+
|
|
77
|
+
```yaml
|
|
78
|
+
value: "Radical Candour"
|
|
79
|
+
behaviours:
|
|
80
|
+
- observable: "In meetings, names a disagreement explicitly within 30 seconds of forming it"
|
|
81
|
+
coachable: "Manager can flag: 'You sat on that disagreement for 5 minutes before raising it. What kept you quiet?'"
|
|
82
|
+
- observable: "Gives critical feedback to peers directly before going to manager"
|
|
83
|
+
coachable: "Manager can flag: 'You came to me about Marco's work — have you told Marco first?'"
|
|
84
|
+
- observable: "Writes the dissenting view in the decision document, not in DM"
|
|
85
|
+
coachable: "Manager can flag: 'I see you DM'd me your concern — that belongs in the doc thread.'"
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
Behaviours that aren't observable + coachable are aspirations, not culture.
|
|
89
|
+
|
|
90
|
+
## Ritual Catalogue (load-bearing rituals)
|
|
91
|
+
|
|
92
|
+
Rituals reinforce values by repetition. Each ritual must:
|
|
93
|
+
|
|
94
|
+
- **Have an owner** — named human who runs it
|
|
95
|
+
- **Have a value it reinforces** — explicit link, not "team-building"
|
|
96
|
+
- **Be load-bearing** — if removed, the value erodes
|
|
97
|
+
- **Have a cadence** — daily / weekly / monthly / quarterly / annual
|
|
98
|
+
|
|
99
|
+
Decorative rituals (Friday afternoon trivia with no value link) should be cut. Load-bearing rituals (Monday decision-log review reinforcing "Radical Candour") should be defended.
|
|
100
|
+
|
|
101
|
+
Sample ritual catalogue format:
|
|
102
|
+
|
|
103
|
+
```yaml
|
|
104
|
+
rituals:
|
|
105
|
+
- name: "Decision Log Review"
|
|
106
|
+
cadence: weekly
|
|
107
|
+
owner: <coo>
|
|
108
|
+
value_reinforced: Radical Candour + Document Everything
|
|
109
|
+
description: 30min weekly review of decisions made + dissents noted
|
|
110
|
+
load_bearing: yes # removing this means decisions lose dissent visibility
|
|
111
|
+
```
|
|
112
|
+
|
|
113
|
+
## Decision Principles
|
|
114
|
+
|
|
115
|
+
How the org decides:
|
|
116
|
+
|
|
117
|
+
```yaml
|
|
118
|
+
decision_principles:
|
|
119
|
+
fast_lane:
|
|
120
|
+
criteria: "Reversible, contained blast radius, single owner can decide"
|
|
121
|
+
process: "DRI decides, posts decision in #decisions, moves on"
|
|
122
|
+
slow_lane:
|
|
123
|
+
criteria: "Irreversible, cross-team impact, or > $X spend"
|
|
124
|
+
process: "RFC posted, 1-week comment period, decision meeting, exec sign-off if > $Y"
|
|
125
|
+
disagree_and_commit:
|
|
126
|
+
when: "Decision is made and you dissented"
|
|
127
|
+
expected_behaviour: "Make the decision succeed as if it were yours"
|
|
128
|
+
escalation:
|
|
129
|
+
when: "Cannot reach decision within timebox"
|
|
130
|
+
process: "Escalate to specific named human, no triangulation"
|
|
131
|
+
```
|
|
132
|
+
|
|
133
|
+
Decision principles must be specific enough to predict behaviour, not vague enough to mean nothing.
|
|
134
|
+
|
|
135
|
+
## Operationalisation (the hard part)
|
|
136
|
+
|
|
137
|
+
Values without operational integration are wall posters. Wire culture into:
|
|
138
|
+
|
|
139
|
+
### Hiring
|
|
140
|
+
- Interview rubrics test for each value's observable behaviours
|
|
141
|
+
- "Culture interview" measures inverse-test alignment, not generic "good fit"
|
|
142
|
+
- Reject criteria: candidate who consistently exhibits inverse behaviours
|
|
143
|
+
|
|
144
|
+
### Onboarding
|
|
145
|
+
- Day 1: Values + behaviour map + inversion test framing
|
|
146
|
+
- Week 2: Shadowing of load-bearing rituals
|
|
147
|
+
- Month 1: Reflection conversation — which values felt foreign vs native?
|
|
148
|
+
|
|
149
|
+
### Performance Review
|
|
150
|
+
- Behaviour-specific feedback against each value's observable list
|
|
151
|
+
- "What value did you most embody this period? What evidence?"
|
|
152
|
+
- Areas-for-development tied to specific behaviours
|
|
153
|
+
|
|
154
|
+
### Promotion
|
|
155
|
+
- Each level requires demonstrating specific behaviours
|
|
156
|
+
- Senior level requires modelling behaviours to others
|
|
157
|
+
- Lead level requires defending values when convenient to violate them
|
|
158
|
+
|
|
159
|
+
## Common Failure Modes
|
|
160
|
+
|
|
161
|
+
1. **Platitude values** — "Excellence", "Integrity", "Innovation" without inverses. Drop them
|
|
162
|
+
2. **As-is denial** — defining the aspirational culture without mapping the actual culture. Gap becomes invisible
|
|
163
|
+
3. **Decorative rituals** — Friday trivia with no value link. Cut it
|
|
164
|
+
4. **Behaviours without observability** — "be a team player" is not a behaviour, "names disagreement within 30 seconds" is
|
|
165
|
+
5. **Wall poster syndrome** — values defined but not wired into hiring / performance / promotion. Operationalisation is 80% of the work
|
|
166
|
+
|
|
167
|
+
## Output → Obsidian: `WizardingCode/Org/Culture/<company>-<date>/`
|
|
168
|
+
|
|
169
|
+
Delivers: cultural archaeology (as-is map) + values set (inversion-tested) + behaviour map (3-5 observable behaviours per value) + ritual catalogue (load-bearing only) + decision principles + operationalisation plan (hiring + onboarding + performance + promotion) + 1-page executive summary.
|
|
@@ -0,0 +1,134 @@
|
|
|
1
|
+
id: org-culture
|
|
2
|
+
name: Culture Definition
|
|
3
|
+
description: Define organisational culture explicitly — values + behaviours + rituals + decision principles — that can be operationalised in hiring, performance, and decision-making
|
|
4
|
+
department: org
|
|
5
|
+
tier: enterprise
|
|
6
|
+
command: "/org culture"
|
|
7
|
+
requires_branch: false
|
|
8
|
+
requires_spec: false
|
|
9
|
+
quality_gate_required: true
|
|
10
|
+
|
|
11
|
+
phases:
|
|
12
|
+
- id: brief
|
|
13
|
+
name: Culture Brief
|
|
14
|
+
description: Define company stage, current culture state (default-on or explicit), audience for the document
|
|
15
|
+
agents:
|
|
16
|
+
- agent_id: coo-sofia
|
|
17
|
+
role: Frame company stage, current culture state, audience
|
|
18
|
+
gate:
|
|
19
|
+
type: user_approval
|
|
20
|
+
description: User confirms scope and audience
|
|
21
|
+
|
|
22
|
+
- id: archaeology
|
|
23
|
+
name: Cultural Archaeology
|
|
24
|
+
description: Extract the existing implicit culture from artefacts — Slack patterns, email norms, decisions taken, founder choices
|
|
25
|
+
agents:
|
|
26
|
+
- agent_id: coo-sofia
|
|
27
|
+
role: Cultural artefact analysis — what's already true vs aspirational
|
|
28
|
+
- agent_id: kb-curator-clara
|
|
29
|
+
role: Mine the KB for founder stories, public statements, recurring decision patterns
|
|
30
|
+
parallel: true
|
|
31
|
+
gate:
|
|
32
|
+
type: user_approval
|
|
33
|
+
description: User approves the as-is culture map
|
|
34
|
+
|
|
35
|
+
- id: values-set
|
|
36
|
+
name: Values Set (Real, Not Marketing)
|
|
37
|
+
description: Define 4-6 values that pass the inversion test — values whose opposites are also defensible positions held by other companies
|
|
38
|
+
agents:
|
|
39
|
+
- agent_id: coo-sofia
|
|
40
|
+
role: Values selection with inversion test per value
|
|
41
|
+
- agent_id: strategy-director-tomas
|
|
42
|
+
role: Strategic coherence — do values reinforce competitive position?
|
|
43
|
+
parallel: true
|
|
44
|
+
gate:
|
|
45
|
+
type: user_approval
|
|
46
|
+
description: User approves values set
|
|
47
|
+
outputs:
|
|
48
|
+
- type: document
|
|
49
|
+
format: markdown
|
|
50
|
+
obsidian_path: "WizardingCode/Org/Culture/Values/"
|
|
51
|
+
description: Values set with inversion test + strategic rationale per value
|
|
52
|
+
|
|
53
|
+
- id: behaviours
|
|
54
|
+
name: Behaviour Mapping
|
|
55
|
+
description: Translate each value to 3-5 concrete behaviours that are observable and coachable
|
|
56
|
+
agents:
|
|
57
|
+
- agent_id: coo-sofia
|
|
58
|
+
role: Per-value behaviour mapping with observable + coachable criteria
|
|
59
|
+
gate:
|
|
60
|
+
type: user_approval
|
|
61
|
+
description: User approves behaviour map
|
|
62
|
+
|
|
63
|
+
- id: rituals
|
|
64
|
+
name: Rituals & Practices
|
|
65
|
+
description: Identify the rituals that reinforce values — weekly cadences, decision rituals, recognition patterns, retrospective formats
|
|
66
|
+
agents:
|
|
67
|
+
- agent_id: coo-sofia
|
|
68
|
+
role: Ritual catalogue with frequency + owner + value-reinforced per ritual
|
|
69
|
+
gate:
|
|
70
|
+
type: user_approval
|
|
71
|
+
description: User approves ritual catalogue
|
|
72
|
+
|
|
73
|
+
- id: decision-principles
|
|
74
|
+
name: Decision Principles
|
|
75
|
+
description: Codify decision principles — when do we decide fast vs slow, who decides what, how do we disagree, how do we commit
|
|
76
|
+
agents:
|
|
77
|
+
- agent_id: coo-sofia
|
|
78
|
+
role: Decision principles with examples per principle
|
|
79
|
+
- agent_id: cqo-marta
|
|
80
|
+
role: Quality + governance integration check
|
|
81
|
+
parallel: true
|
|
82
|
+
gate:
|
|
83
|
+
type: user_approval
|
|
84
|
+
description: User approves decision principles
|
|
85
|
+
|
|
86
|
+
- id: operationalisation
|
|
87
|
+
name: Operationalisation
|
|
88
|
+
description: Wire culture into hiring, onboarding, performance review, promotion criteria
|
|
89
|
+
agents:
|
|
90
|
+
- agent_id: coo-sofia
|
|
91
|
+
role: Operational integration plan per HR surface
|
|
92
|
+
gate:
|
|
93
|
+
type: user_approval
|
|
94
|
+
description: User approves operationalisation plan
|
|
95
|
+
|
|
96
|
+
- id: self-critique
|
|
97
|
+
name: Self-Critique
|
|
98
|
+
description: Stress-test — does each value pass the inversion test? Are behaviours observable? Are rituals load-bearing or decorative?
|
|
99
|
+
agents:
|
|
100
|
+
- agent_id: coo-sofia
|
|
101
|
+
role: Culture coherence check + decorative-ritual elimination
|
|
102
|
+
gate:
|
|
103
|
+
type: auto
|
|
104
|
+
|
|
105
|
+
- id: quality-gate
|
|
106
|
+
name: Quality Gate
|
|
107
|
+
model_override: opus
|
|
108
|
+
description: Mandatory quality review
|
|
109
|
+
agents:
|
|
110
|
+
- agent_id: cqo-marta
|
|
111
|
+
role: Orchestrate quality review
|
|
112
|
+
- agent_id: copy-director-eduardo
|
|
113
|
+
role: Values prose, no aspirational clichés, behaviour specificity
|
|
114
|
+
parallel: true
|
|
115
|
+
- agent_id: tech-director-francisca
|
|
116
|
+
role: Operationalisation feasibility, observability of behaviours, ritual ownership clarity
|
|
117
|
+
parallel: true
|
|
118
|
+
gate:
|
|
119
|
+
type: quality_gate
|
|
120
|
+
required_verdict: APPROVED
|
|
121
|
+
|
|
122
|
+
- id: delivery
|
|
123
|
+
name: Culture Document Delivery
|
|
124
|
+
description: Compile the culture document — values + behaviours + rituals + decision principles + operationalisation
|
|
125
|
+
agents:
|
|
126
|
+
- agent_id: coo-sofia
|
|
127
|
+
role: Full culture document + 1-page executive summary
|
|
128
|
+
gate:
|
|
129
|
+
type: auto
|
|
130
|
+
outputs:
|
|
131
|
+
- type: document
|
|
132
|
+
format: markdown
|
|
133
|
+
obsidian_path: "WizardingCode/Org/Culture/"
|
|
134
|
+
description: Complete culture document — values (inversion-tested) + behaviours + rituals + decision principles + operationalisation plan + exec summary
|
package/package.json
CHANGED