arkaos 2.54.0 → 2.56.0

package/VERSION

@@ -1 +1 @@
-2.54.0
+2.56.0

package/departments/content/skills/youtube-strategy/SKILL.md

@@ -1,7 +1,9 @@
 ---
 name: content/youtube-strategy
 description: >
-  YouTube strategy: title/thumbnail packaging, script structure, SEO, upload cadence.
+  YouTube strategy — channel positioning, title × thumbnail architecture,
+  hook + script structure, SEO + metadata, publishing cadence, cross-platform
+  distribution.
 allowed-tools: [Read, Write, Edit, Bash, Grep, Glob, Agent, WebFetch, WebSearch]
 ---
 
@@ -19,14 +21,141 @@ treat them as your default source. External research supplements, it
 does not replace the vault.
 <!-- arka:kb-first-prefix end -->
 
-# Youtube Strategy — `/content youtube <topic>`
+# YouTube Strategy — `/content youtube <topic>`
 
-> **Agent:** Rafael (Content Strategist) | **Framework:** MrBeast Method + YouTube Algorithm
+> **Lead:** Rafael (Content Strategist) | **Cross-dept:** Isabel (Visual Designer) + Teresa (Copy) + Luna (Marketing) | **Frameworks:** MrBeast Title × Thumbnail Method + Algorithm-Aware Retention Design
 
-## What It Does
+## What ships
 
-YouTube strategy: title/thumbnail packaging, script structure, SEO, upload cadence.
+A production YouTube strategy in 7 deliverables:
 
-## Output
+1. **Channel positioning** with competing-channel analysis
+2. **10 title × thumbnail pairs** with CTR patterns named
+3. **Hook architecture** + retention curve plan per video
+4. **Script structure** with retention drops mapped
+5. **SEO metadata + playlist hierarchy**
+6. **Publishing cadence** with view + subscriber targets
+7. **Cross-platform derivative spec** (Shorts, threads, newsletter)
 
-YouTube strategy with 10 video ideas, title/thumb variants, and growth targets
+## The CTR-Retention Math (why packaging matters)
+
+The YouTube algorithm rewards two metrics in tight loop:
+
+- **CTR (click-through rate)** — % of impressions that click. Median is 4-6%; top performers 10-15%.
+- **AVD (average view duration)** — minutes watched per view. Algorithm normalizes by video length but rewards higher absolute AVD.
+
+CTR depends on **title × thumbnail × topic** working together. AVD depends on **hook + retention curve + payoff**. If CTR is high but AVD is low, the algorithm interprets the video as clickbait and demotes it. If CTR is low but AVD is high, the video starves of impressions.
+
+Target floor: CTR ≥ 6%, AVD ≥ 40% of length, retention curve no sharp drops in first 30 seconds.
+
+## Title × Thumbnail Patterns (CTR levers)
+
+Each title × thumbnail pair uses one of these named patterns. Mixing patterns randomly produces noise; picking a primary pattern per channel produces compounding.
+
+| Pattern | Title shape | Thumbnail shape | Use case |
+|---|---|---|---|
+| **Curiosity Gap** | "What happens when [unexpected]" | One element + question mark + face surprised | Investigation, experiment videos |
+| **Transformation** | "From X to Y in Z time" | Before / After split | Tutorial, journey, case study |
+| **Specific Claim** | "I [verb] [specific number] [specific subject]" | Numbers visible + product / outcome | Stunt, achievement, deep-dive |
+| **Loss Aversion** | "Don't [common mistake]" | Red X + warning icon + face concerned | Warning, education |
+| **Authority + Specific** | "How [expert title] [does specific thing]" | Person + tool / artifact + clean type | Expert content, behind-the-scenes |
+| **Comparison** | "X vs Y: Which actually [outcome]" | Split with both items + clear winner cue | Review, head-to-head |
+| **Contrarian** | "Why everyone is wrong about X" | Strikethrough on common belief + face defiant | Opinion, takedown, education |
+
+Thumbnail design rules (visual hierarchy):
+- **One focal point** — eye lands on a single element first
+- **Face if relevant** — human face drives 30-40% CTR lift on most topics
+- **Contrast** — high-saturation focal vs muted background
+- **Type ≤ 4 words** — readable on mobile at 320px width
+- **No clickbait that breaks promise** — title and thumbnail must accurately preview the payoff
+
+## Hook Architecture (first 30 seconds)
+
+The first 30 seconds determines whether the viewer stays. The hook structure that consistently retains:
+
+```
+0-3s   PATTERN INTERRUPT — visual + audio shock or unexpected statement
+3-10s  PROMISE — name the transformation / outcome the viewer gets
+10-20s STAKES — why this matters, what they'll lose by leaving
+20-30s PREVIEW — quick montage of the 3 best moments coming up
+```
+
+Pattern interrupts that work: starting mid-action, a contradictory statement, an unexpected location, an unexpected visual element. Pattern interrupts that don't work: long intro animations, founder face talking to camera with no visual.
+
+## Script Structure (full video)
+
+Default structure for a 10-12 minute video (the optimal range for monetisation + retention):
+
+```
+0:00 - 0:30   Hook (see Hook Architecture)
+0:30 - 2:00   Setup — name the problem, stakes, why now
+2:00 - 4:00   Reframe — show the prevailing wrong answer + your alternative frame
+4:00 - 8:00   Content blocks (2-3 blocks) — each with a mini-hook, a payoff, a transition
+8:00 - 10:00  Payoff — the promised transformation / answer delivered concretely
+10:00 - 11:00 Recap + CTA — quick recap + subscribe / next video / link in description
+11:00 - 12:00 Outro + end screen — pattern-interrupt sting + related video CTA
+```
+
+Retention drops happen at predictable moments: 1:00 (initial commitment), 4:00 (mid-video boredom), 8:00 (sense of completion). Insert a mini-hook 10 seconds before each predicted drop to retain viewers through it.
+
+## SEO Metadata Stack
+
+For each video, fill the metadata stack:
+
+```yaml
+title:
+  primary_keyword: "<2-3 word keyword>"
+  full_title: "<title with keyword + pattern + emotional anchor>"
+  variants_for_testing: 3-5 alternates
+
+description:
+  first_140_chars: "<keyword-loaded summary that appears in search>"
+  full_description:
+    - paragraph 1: hook + value prop (250 chars)
+    - paragraph 2: timestamps with keyword variants
+    - paragraph 3: links + CTAs
+    - paragraph 4: hashtags (3-5 max, mixed broad + niche)
+  pinned_comment: "<first comment author posts with related links>"
+
+tags:
+  primary: ["<broad topic>", "<specific topic>"]
+  long_tail: ["<specific phrase>", "<question phrase>"]
+  branded: ["<channel name>", "<series name>"]
+
+end_screen:
+  best_for_viewer: <related video by same channel>
+  subscribe_cta: <button position>
+
+playlists:
+  series_playlist: <series name if applicable>
+  topic_playlist: <topic cluster>
+```
+
+## Publishing Cadence Math
+
+Sustainability beats burst. The cadence math:
+
+- **Long-form video** anchor — 1 per week typical floor for growth channels, 1 per 2 weeks for high-production
+- **Shorts derivatives** — 3-5 per long-form video, posted on rolling schedule
+- **Community posts** — 2-3 per week to keep algorithm engagement signal
+- **Live / Premiere** — optional monthly cadence for community deepening
+
+First 90 days targets:
+- Week 1-4: 4 long-forms, 16-20 shorts. Target: identify which pattern resonates.
+- Week 5-8: Double down on winning pattern. Target: first video to 10k views.
+- Week 9-12: Optimise + scale. Target: first 1000 subs OR 100k cumulative views, whichever ships first.
+
+## Cross-Platform Derivatives (per long-form video)
+
+Each long-form video should produce:
+- **3-5 YouTube Shorts** (vertical, 30-60s, hook-led clips)
+- **1 Twitter/X thread** (10-15 tweets summarising the video with embedded clips)
+- **1 LinkedIn post** (professional framing for B2B audiences)
+- **1 newsletter section** (long-form summary with personal context)
+- **1 Podcast adaptation** (audio extraction if relevant)
+
+Derivative production should be templated — derivatives are not new content, they are repackaging.
+
+## Output → Obsidian: `WizardingCode/Content/YouTube/<topic>-<date>/`
+
+Delivers: channel positioning + 10 title × thumbnail pairs + hook architecture + script structure for 3-5 videos + SEO metadata stack per video + 90-day cadence + cross-platform derivative spec + 1-page executive summary.

package/departments/content/workflows/system.yaml

@@ -0,0 +1,136 @@
+id: content-system
+name: Content Operating System
+description: Build a complete Content OS — strategy + production system + distribution + repurposing + analytics — that compounds output over time
+department: content
+tier: enterprise
+command: "/content system"
+requires_branch: false
+requires_spec: false
+quality_gate_required: true
+
+phases:
+  - id: brief
+    name: Content OS Brief
+    description: Define audience, content goals, current capacity, platforms, runway, success metric
+    agents:
+      - agent_id: content-director-rafael
+        role: Frame audience, goals, current production cadence, target platforms, success metric
+    gate:
+      type: user_approval
+      description: User confirms audience, goals, platforms, success metric
+
+  - id: pillar-design
+    name: Content Pillar Design
+    description: Define 3-5 content pillars that align audience interest × business value × differentiation
+    agents:
+      - agent_id: content-director-rafael
+        role: 3-5 pillar topics with audience-interest score + business-value score per pillar
+      - agent_id: marketing-director-luna
+        role: Search demand + competitive density per pillar
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves the pillar set
+    outputs:
+      - type: document
+        format: markdown
+        obsidian_path: "WizardingCode/Content/OS/Pillars/"
+        description: Content pillar definition with audience/business/differentiation scoring
+
+  - id: format-stack
+    name: Format Stack
+    description: Define the format stack per pillar (long-form anchor + short-form derivatives + repurposing chain)
+    agents:
+      - agent_id: content-director-rafael
+        role: Format stack design (anchor format + 4-6 derivative formats per anchor)
+      - agent_id: short-form-specialist
+        role: Short-form derivative specifications (Reels / Shorts / Tweets / Carousels)
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves the format stack
+
+  - id: production-cadence
+    name: Production Cadence
+    description: Set realistic cadence — anchor pieces per month, derivatives per anchor, total weekly output
+    agents:
+      - agent_id: content-director-rafael
+        role: Cadence math — anchor cycle time, derivative multiplier, weekly total, sustainability check
+    gate:
+      type: user_approval
+      description: User approves the cadence
+
+  - id: distribution-channels
+    name: Distribution Channels
+    description: Map content type × platform — where each anchor and each derivative lives, with platform-native adaptations
+    agents:
+      - agent_id: content-director-rafael
+        role: Channel map with platform-native adaptations per format
+      - agent_id: marketing-director-luna
+        role: Distribution amplification — paid, partnerships, syndication options
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves distribution map
+
+  - id: analytics-stack
+    name: Analytics Stack
+    description: Define the metrics that matter — per-pillar performance, per-format performance, per-channel performance, North Star metric
+    agents:
+      - agent_id: content-director-rafael
+        role: Analytics dashboard spec with per-level metrics (pillar / format / channel)
+      - agent_id: tech-director-francisca
+        role: Tracking implementation feasibility
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves analytics stack
+
+  - id: ops-systems
+    name: Ops & Systems
+    description: Templates, briefs, asset library, review workflow, publishing workflow, archive
+    agents:
+      - agent_id: content-director-rafael
+        role: Operational templates and workflow specs (brief, review, publish, archive)
+    gate:
+      type: auto
+
+  - id: self-critique
+    name: Self-Critique
+    description: Stress-test the system — is cadence sustainable? Are pillars differentiated? Does analytics tie to North Star?
+    agents:
+      - agent_id: content-director-rafael
+        role: Coherence check across pillars / format stack / cadence / analytics / North Star
+    gate:
+      type: auto
+
+  - id: quality-gate
+    name: Quality Gate
+    model_override: opus
+    description: Mandatory quality review
+    agents:
+      - agent_id: cqo-marta
+        role: Orchestrate quality review
+      - agent_id: copy-director-eduardo
+        role: Pillar prose, format brief quality, no clichés
+        parallel: true
+      - agent_id: tech-director-francisca
+        role: Cadence feasibility, tracking integrity, workflow operability
+        parallel: true
+    gate:
+      type: quality_gate
+      required_verdict: APPROVED
+
+  - id: delivery
+    name: Content OS Package Delivery
+    description: Compile the full Content OS — pillars + format stack + cadence + distribution + analytics + ops templates
+    agents:
+      - agent_id: content-director-rafael
+        role: Full Content OS package + 1-page executive summary
+    gate:
+      type: auto
+    outputs:
+      - type: document
+        format: markdown
+        obsidian_path: "WizardingCode/Content/OS/"
+        description: Complete Content OS — pillars + format stack + cadence + distribution + analytics + ops templates + exec summary

package/departments/content/workflows/youtube.yaml

@@ -0,0 +1,144 @@
+id: content-youtube
+name: YouTube Strategy
+description: Full YouTube strategy — channel positioning, title × thumbnail × hook architecture, script structure, SEO optimization, distribution
+department: content
+tier: enterprise
+command: "/content youtube"
+requires_branch: false
+requires_spec: false
+quality_gate_required: true
+
+phases:
+  - id: brief
+    name: YouTube Brief
+    description: Define topic, target audience, current channel state, monetisation goal, weekly capacity
+    agents:
+      - agent_id: content-director-rafael
+        role: Frame topic, audience, current subscribers + AVG view duration, monetisation goal
+    gate:
+      type: user_approval
+      description: User confirms YouTube brief
+
+  - id: channel-positioning
+    name: Channel Positioning
+    description: Position the channel in the YouTube taxonomy — niche, target persona, channel promise, competing channels
+    agents:
+      - agent_id: content-director-rafael
+        role: Channel positioning statement + competing channels analysis
+      - agent_id: brand-strategist-mateus
+        role: Differentiation angle, channel identity
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves channel positioning
+    outputs:
+      - type: document
+        format: markdown
+        obsidian_path: "WizardingCode/Content/YouTube/Positioning/"
+        description: Channel positioning + competing channels + differentiation angle
+
+  - id: title-thumbnail-architecture
+    name: Title × Thumbnail Architecture
+    description: Design 10 title × thumbnail pairs using CTR-tested patterns — curiosity gap + transformation + specificity + visual hierarchy
+    agents:
+      - agent_id: content-director-rafael
+        role: 10 title × thumbnail pairs with CTR pattern named per pair
+      - agent_id: visual-designer-isabel
+        role: Thumbnail visual hierarchy specs (face / contrast / focal-point / text-overlay rules)
+        parallel: true
+    gate:
+      type: user_approval
+      description: User selects 3-5 title × thumbnail pairs for first videos
+
+  - id: hook-script-structure
+    name: Hook × Script Structure
+    description: First 30s hook architecture + retention curve plan for the full script
+    agents:
+      - agent_id: content-director-rafael
+        role: Hook framework (negative → positive → curiosity gap → preview) + retention curve plan
+      - agent_id: sales-copywriter-teresa
+        role: Hook copy variants (3 per video) + script outline with retention drops mapped
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves hook + script structure
+    outputs:
+      - type: document
+        format: markdown
+        obsidian_path: "WizardingCode/Content/YouTube/Scripts/"
+        description: Hook architecture + script structure with retention curve plan
+
+  - id: seo-metadata
+    name: SEO & Metadata
+    description: Title keywords, description optimization, tags, end-screen design, playlist architecture
+    agents:
+      - agent_id: content-director-rafael
+        role: SEO metadata specs per video; playlist hierarchy
+      - agent_id: marketing-director-luna
+        role: Keyword research + search volume targeting
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves SEO + playlist architecture
+
+  - id: publishing-cadence
+    name: Publishing Cadence
+    description: Set sustainable publishing cadence with first-week / first-month / first-quarter targets
+    agents:
+      - agent_id: content-director-rafael
+        role: Cadence math + first-week / first-month / first-quarter view + subscriber targets
+    gate:
+      type: user_approval
+      description: User approves cadence and targets
+
+  - id: distribution-amplification
+    name: Distribution & Amplification
+    description: Cross-platform distribution — Shorts derivatives, Twitter/LinkedIn threads, email newsletter, podcast
+    agents:
+      - agent_id: content-director-rafael
+        role: Cross-platform derivative spec per long-form video
+      - agent_id: short-form-specialist
+        role: Shorts adaptation spec (3-5 Shorts per long-form)
+        parallel: true
+    gate:
+      type: auto
+
+  - id: self-critique
+    name: Self-Critique
+    description: Stress-test the strategy — is the cadence sustainable? Does positioning differentiate from competing channels? Does the CTR pattern math hold?
+    agents:
+      - agent_id: content-director-rafael
+        role: Coherence + sustainability + differentiation check
+    gate:
+      type: auto
+
+  - id: quality-gate
+    name: Quality Gate
+    model_override: opus
+    description: Mandatory quality review
+    agents:
+      - agent_id: cqo-marta
+        role: Orchestrate quality review
+      - agent_id: copy-director-eduardo
+        role: Title copy, hook copy, script structure, no clickbait that breaks promise
+        parallel: true
+      - agent_id: tech-director-francisca
+        role: Thumbnail visual hierarchy, retention curve feasibility, SEO metadata correctness
+        parallel: true
+    gate:
+      type: quality_gate
+      required_verdict: APPROVED
+
+  - id: delivery
+    name: YouTube Strategy Package Delivery
+    description: Compile the full YouTube strategy package
+    agents:
+      - agent_id: content-director-rafael
+        role: Full YouTube strategy package + 1-page executive summary
+    gate:
+      type: auto
+    outputs:
+      - type: document
+        format: markdown
+        obsidian_path: "WizardingCode/Content/YouTube/"
+        description: Complete YouTube strategy — positioning + title × thumbnail pairs + hook architecture + script structure + SEO metadata + publishing cadence + distribution + exec summary

package/departments/pm/skills/roadmap-build/SKILL.md

@@ -1,7 +1,10 @@
 ---
 name: pm/roadmap-build
 description: >
-  Product roadmap: outcome-based (not feature-based), NOW/NEXT/LATER format.
+  Outcome-driven product roadmap — North Star + outcome tree + 3-horizon
+  map (Now/Next/Later) + bet selection + capacity allocation + audience-
+  specific communication. Replaces feature-list roadmaps with measurable
+  bets.
 allowed-tools: [Read, Write, Edit, Bash, Grep, Glob, Agent, WebFetch, WebSearch]
 ---
 
@@ -21,12 +24,114 @@ does not replace the vault.
 
 # Roadmap Build — `/pm roadmap <product>`
 
-> **Agent:** Carolina (Product Manager) | **Framework:** Outcome-Driven Roadmaps (Cagan)
+> **Lead:** Carolina (Product Manager) | **Cross-dept:** Tomas (Strategy) + Francisca (Tech) + Eduardo (Copy) | **Frameworks:** Marty Cagan Outcome-Driven Roadmaps + Three Horizons + Bets vs Promises
 
-## What It Does
+## What ships
 
-Product roadmap: outcome-based (not feature-based), NOW/NEXT/LATER format.
+A production roadmap in 6 deliverables:
 
-## Output
+1. **North Star metric** — the one number the product team optimises
+2. **Outcome tree** — 3-5 outcomes that decompose the North Star, each measurable
+3. **Three-horizon map** — Now (committed) / Next (validating) / Later (exploring)
+4. **Bet selection** — 1-3 bets per outcome with hypothesis + success criteria
+5. **Capacity allocation** — team mapping with fixed-time vs fixed-scope policy
+6. **Per-audience communication** — exec / engineering / sales / customer views
 
-Product roadmap with outcomes, time horizons, and success metrics
+## North Star Metric (the math constraint)
+
+The North Star is **one number**, not a dashboard. Properties of a valid North Star:
+
+- **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.
+- **Leading enough** — moves on quarterly cadence, not yearly. Revenue is too lagging for product team decisions.
+- **Causal to revenue** — a working North Star explains revenue movement with 90-day lag.
+- **Movable by product** — the team can affect it with shipped work, not just marketing or sales.
+
+Examples that work: Airbnb's "Nights Booked", Slack's "Messages sent in active teams", Stripe's "Payment volume processed".
+
+Examples that fail: NPS (too lagging, hard to move), "Number of users" (vanity), "Engineering velocity" (internal, not customer).
+
+## Outcome Tree (decomposition)
+
+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.
+
+```
+NORTH STAR: Active teams using core feature 3+ times/week
+
+  OUTCOME 1: Trial-to-paid conversion rate (currently 6%, target 12%)
+    BET 1.1: Improve onboarding completion rate
+    BET 1.2: Reduce time-to-first-value
+
+  OUTCOME 2: Weekly active rate per paid team (currently 60%, target 80%)
+    BET 2.1: Habit loop in core workflow
+    BET 2.2: Notification system that drives return
+
+  OUTCOME 3: Feature adoption depth (currently 1.4 features per active team, target 2.5)
+    BET 3.1: Discoverability improvements
+    BET 3.2: Cross-feature integration
+
+  OUTCOME 4: Team-to-team expansion (currently 5% of paid teams expand, target 15%)
+    BET 4.1: Multi-team workflow
+    BET 4.2: Admin tools for organisations
+```
+
+Each outcome must answer: *if this number moves by X, does the North Star move by Y? Show the math.*
+
+## Three Horizons (commitment-by-horizon)
+
+| Horizon | Time | Commitment | Communication |
+|---|---|---|---|
+| **Now** | Current quarter | High — committed, in flight | Specific bets named, in-progress |
+| **Next** | Following quarter | Medium — validating, scoped | Bets shaped, not yet started |
+| **Later** | 2-4 quarters out | Low — exploring, hypothesis-stage | Directional only, "we believe X matters" |
+
+The rule: **the further out, the lower the commitment**. Roadmaps that promise specific Q4 features at Q1 confidence lose all credibility when they slip.
+
+## Bets vs Promises (Shape Up alignment)
+
+A bet has:
+- **Appetite** (time budget, fixed)
+- **Hypothesis** (if we ship X, Y will change)
+- **Success criteria** (Y moves by Z)
+- **Failure criteria** (if Y doesn't move by Z by date W, we stop)
+
+A promise has:
+- Date
+- Specific deliverable
+- No falsification path
+
+Roadmaps with promises are commitments to specific outputs. Roadmaps with bets are commitments to specific *learning*. Bets compound; promises break.
+
+## Capacity Allocation Policy
+
+Each bet has a policy on what's fixed vs variable:
+
+- **Fixed time, variable scope** (Shape Up default) — appetite is the constraint. Scope is whatever fits.
+- **Fixed scope, variable time** (legacy waterfall) — only use when externally constrained (regulatory, contractual).
+- **Fixed both** — invalid. Pick one. Trying to fix both produces death marches.
+
+Typical mix for a product team: 60% Fixed Time (Now horizon), 30% Discovery (Next horizon), 10% Exploration (Later horizon, hypothesis testing).
+
+## Per-Audience Communication
+
+The same roadmap presents differently to different audiences. Same data, different framing.
+
+| Audience | What they see | What's redacted |
+|---|---|---|
+| **Exec / Board** | Outcomes + North Star projection + bet portfolio | Specific feature lists, internal team names |
+| **Engineering** | Bets with appetite + technical context | Sales-speak, customer logo lists |
+| **Sales / GTM** | What's shipping + when (Now horizon only) | Discovery hypotheses, failed bets |
+| **Customer-facing** | Public-safe directional ("We're investing in X") | Specifics, dates, anything we might not ship |
+
+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.
+
+## Common Failure Modes
+
+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.
+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.
+3. **Promising the Later horizon** — exposing speculative quarters as commitments. When they slip, the team loses credibility on the Now horizon too.
+4. **No falsification on bets** — bets without failure criteria become marathons. Set the kill-switch date upfront.
+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.
+
+## Output → Obsidian: `WizardingCode/Product/Roadmap/<product>-<date>/`
+
+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.

package/departments/pm/workflows/discover.yaml

@@ -0,0 +1,136 @@
+id: pm-discover
+name: Product Discovery
+description: Continuous product discovery using Opportunity Solution Tree (Teresa Torres) — interviews + assumption tests + outcome alignment
+department: pm
+tier: enterprise
+command: "/pm discover"
+requires_branch: false
+requires_spec: false
+quality_gate_required: true
+
+phases:
+  - id: brief
+    name: Discovery Brief
+    description: Define product outcome, the question we're answering, current evidence base, runway for discovery
+    agents:
+      - agent_id: product-director-carolina
+        role: Frame outcome, question, current evidence, time budget
+    gate:
+      type: user_approval
+      description: User confirms outcome statement and discovery question
+
+  - id: opportunity-mapping
+    name: Opportunity Mapping
+    description: Map the Opportunity Solution Tree — desired outcome at top, opportunities (customer needs) in middle, solution candidates at bottom
+    agents:
+      - agent_id: product-director-carolina
+        role: OST construction with explicit opportunity definitions
+      - agent_id: ux-designer-sofia-d
+        role: Customer journey lens — where do opportunities surface?
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves OST structure
+    outputs:
+      - type: document
+        format: markdown
+        obsidian_path: "WizardingCode/Product/Discovery/OST/"
+        description: Opportunity Solution Tree with opportunity definitions
+
+  - id: interview-plan
+    name: Interview Plan
+    description: Plan 5-10 customer interviews — recruit criteria, script, capture format
+    agents:
+      - agent_id: product-director-carolina
+        role: Interview script with story-based question structure (specific recent moments, not opinions)
+    gate:
+      type: user_approval
+      description: User approves interview plan and recruit criteria
+
+  - id: interview-execution
+    name: Interviews + Synthesis
+    description: Run interviews; synthesize into opportunity additions/refinements to the OST
+    agents:
+      - agent_id: product-director-carolina
+        role: Run interviews, capture verbatim notes, synthesize into opportunity refinements
+    gate:
+      type: user_approval
+      description: User approves interview synthesis
+    outputs:
+      - type: document
+        format: markdown
+        obsidian_path: "WizardingCode/Product/Discovery/Interviews/"
+        description: Interview synthesis with opportunity refinements
+
+  - id: opportunity-selection
+    name: Opportunity Selection
+    description: Pick the target opportunity using impact × confidence × ease prioritisation
+    agents:
+      - agent_id: product-director-carolina
+        role: Opportunity selection with explicit prioritisation matrix and rationale
+    gate:
+      type: user_approval
+      description: User approves target opportunity
+
+  - id: assumption-tests
+    name: Assumption Mapping & Tests
+    description: For the chosen opportunity, list assumptions (desirability / viability / feasibility / usability) and design tests for the riskiest
+    agents:
+      - agent_id: product-director-carolina
+        role: Assumption map + test design for top 3 riskiest assumptions
+      - agent_id: tech-director-francisca
+        role: Feasibility-assumption test feasibility check
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves the top 3 assumption tests
+
+  - id: experiment-execution
+    name: Experiment Execution Plan
+    description: Concrete 2-week experiments — what to do, success criteria, failure criteria, owner
+    agents:
+      - agent_id: product-director-carolina
+        role: 2-week experiment plan per top-3 assumption
+    gate:
+      type: user_approval
+      description: User approves experiment execution plan
+
+  - id: self-critique
+    name: Self-Critique
+    description: Stress-test discovery — does the chosen opportunity tie to the outcome? Are assumption tests falsifiable?
+    agents:
+      - agent_id: product-director-carolina
+        role: Coherence check
+    gate:
+      type: auto
+
+  - id: quality-gate
+    name: Quality Gate
+    model_override: opus
+    description: Mandatory quality review
+    agents:
+      - agent_id: cqo-marta
+        role: Orchestrate quality review
+      - agent_id: copy-director-eduardo
+        role: Interview script quality, synthesis prose, no leading questions
+        parallel: true
+      - agent_id: tech-director-francisca
+        role: Assumption test rigour, feasibility math, falsifiability
+        parallel: true
+    gate:
+      type: quality_gate
+      required_verdict: APPROVED
+
+  - id: delivery
+    name: Discovery Package Delivery
+    description: Compile discovery package — OST + interviews + opportunity selection + assumption tests + experiment plan
+    agents:
+      - agent_id: product-director-carolina
+        role: Full discovery package + 1-page executive summary
+    gate:
+      type: auto
+    outputs:
+      - type: document
+        format: markdown
+        obsidian_path: "WizardingCode/Product/Discovery/"
+        description: Complete discovery package — OST + interview synthesis + opportunity selection + assumption tests + 2-week experiment plan + exec summary

package/departments/pm/workflows/roadmap.yaml

@@ -0,0 +1,127 @@
+id: pm-roadmap
+name: Outcome-Driven Roadmap
+description: Outcome-driven product roadmap (3 horizons) — replaces feature-list roadmaps with measurable outcomes and bets
+department: pm
+tier: enterprise
+command: "/pm roadmap"
+requires_branch: false
+requires_spec: false
+quality_gate_required: true
+
+phases:
+  - id: brief
+    name: Roadmap Brief
+    description: Define product vision, current state, time horizon, owner organisation, stakeholders
+    agents:
+      - agent_id: product-director-carolina
+        role: Frame vision, current state, horizon, stakeholders
+    gate:
+      type: user_approval
+      description: User confirms vision and horizon
+
+  - id: outcome-definition
+    name: North Star + Outcome Tree
+    description: Define the North Star metric and 3-5 derived outcomes that decompose it
+    agents:
+      - agent_id: product-director-carolina
+        role: North Star + outcome tree definition with measurable per-outcome metrics
+      - agent_id: strategy-director-tomas
+        role: Strategic coherence — does the North Star align with company strategy?
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves North Star and outcome tree
+    outputs:
+      - type: document
+        format: markdown
+        obsidian_path: "WizardingCode/Product/Roadmap/NorthStar/"
+        description: North Star + outcome tree with metrics per outcome
+
+  - id: three-horizons
+    name: Three Horizons (Now / Next / Later)
+    description: Map work across the 3 horizons — Now (committed), Next (validating), Later (exploring)
+    agents:
+      - agent_id: product-director-carolina
+        role: Three-horizon mapping with explicit commitment levels per horizon
+    gate:
+      type: user_approval
+      description: User approves horizon mapping
+
+  - id: bet-selection
+    name: Bet Selection
+    description: For each outcome, select 1-3 bets (large, named, time-boxed efforts) with hypothesis + success criteria
+    agents:
+      - agent_id: product-director-carolina
+        role: Bet selection with hypothesis + success criteria per bet
+      - agent_id: strategy-director-tomas
+        role: Bet-outcome coherence and competitive context check
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves bet selection
+
+  - id: capacity-allocation
+    name: Capacity Allocation
+    description: Allocate team capacity across bets — fixed-time vs fixed-scope policy per bet
+    agents:
+      - agent_id: product-director-carolina
+        role: Capacity allocation with team mapping
+      - agent_id: tech-director-francisca
+        role: Technical feasibility + capacity math
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves capacity allocation
+
+  - id: communication-plan
+    name: Communication Plan
+    description: Internal stakeholder communication strategy — what each audience sees, how often, what's redacted
+    agents:
+      - agent_id: product-director-carolina
+        role: Per-audience roadmap view (exec / engineering / sales / customer-facing)
+      - agent_id: copy-director-eduardo
+        role: Per-audience copy adaptations
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves communication strategy
+
+  - id: self-critique
+    name: Self-Critique
+    description: Stress-test the roadmap — are bets falsifiable? Does capacity match commitments? Are outcomes measurable?
+    agents:
+      - agent_id: product-director-carolina
+        role: Coherence check across outcomes / bets / capacity / horizons
+    gate:
+      type: auto
+
+  - id: quality-gate
+    name: Quality Gate
+    model_override: opus
+    description: Mandatory quality review
+    agents:
+      - agent_id: cqo-marta
+        role: Orchestrate quality review
+      - agent_id: copy-director-eduardo
+        role: Outcome prose, bet hypothesis clarity, no clichés
+        parallel: true
+      - agent_id: tech-director-francisca
+        role: Capacity math, feasibility, measurement integrity
+        parallel: true
+    gate:
+      type: quality_gate
+      required_verdict: APPROVED
+
+  - id: delivery
+    name: Roadmap Package Delivery
+    description: Compile the roadmap package + audience-specific versions
+    agents:
+      - agent_id: product-director-carolina
+        role: Full roadmap + audience-specific views + 1-page executive summary
+    gate:
+      type: auto
+    outputs:
+      - type: document
+        format: markdown
+        obsidian_path: "WizardingCode/Product/Roadmap/"
+        description: Complete roadmap — North Star + outcome tree + 3-horizon map + bet definitions + capacity allocation + per-audience communication

package/departments/pm/workflows/shape.yaml

@@ -0,0 +1,136 @@
+id: pm-shape
+name: Shape Up Pitch
+description: Shape Up pitch (Basecamp method) — appetite + problem + solution sketch + rabbit holes + no-gos for a 6-week build cycle
+department: pm
+tier: enterprise
+command: "/pm shape"
+requires_branch: false
+requires_spec: false
+quality_gate_required: true
+
+phases:
+  - id: brief
+    name: Shaping Brief
+    description: Define the raw problem, the appetite (2 / 4 / 6 weeks), the people who'll build it
+    agents:
+      - agent_id: product-director-carolina
+        role: Frame raw problem, set appetite, name the build team
+    gate:
+      type: user_approval
+      description: User confirms problem, appetite, and team
+
+  - id: setting-boundaries
+    name: Setting Boundaries
+    description: Define what's IN scope and what's OUT — appetite is the constraint, fixed time variable scope
+    agents:
+      - agent_id: product-director-carolina
+        role: Scope definition — IN list, OUT list, explicit no-gos
+    gate:
+      type: user_approval
+      description: User approves scope boundaries
+
+  - id: rough-solution
+    name: Rough Solution
+    description: Sketch the solution at the right altitude — fat marker level, not pixel level. Just enough to commit
+    agents:
+      - agent_id: product-director-carolina
+        role: Solution sketch with fat-marker fidelity
+      - agent_id: ux-designer-sofia-d
+        role: User flow at fat-marker level
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves rough solution
+    outputs:
+      - type: document
+        format: markdown
+        obsidian_path: "WizardingCode/Product/Shape/Solutions/"
+        description: Fat-marker solution sketch with user flow
+
+  - id: rabbit-holes
+    name: Rabbit Holes
+    description: Identify rabbit holes — risks, unknowns, technical debt traps — and either eliminate them in shaping or surface as risks
+    agents:
+      - agent_id: product-director-carolina
+        role: Rabbit hole identification + mitigation strategy per hole
+      - agent_id: tech-director-francisca
+        role: Technical rabbit holes (data, integration, dependency)
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves rabbit hole mitigation strategy
+
+  - id: no-gos
+    name: No-Gos
+    description: Explicitly name what's NOT being built — features that look related but aren't part of this bet
+    agents:
+      - agent_id: product-director-carolina
+        role: No-gos list with rationale per item
+    gate:
+      type: auto
+
+  - id: pitch-document
+    name: Pitch Document
+    description: Compile the pitch — problem + appetite + solution + rabbit holes + no-gos + nobody-decisions
+    agents:
+      - agent_id: product-director-carolina
+        role: Full Shape Up pitch document with all 5 sections
+      - agent_id: copy-director-eduardo
+        role: Pitch readability — does it commit the reader to a decision?
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves pitch document before betting table
+
+  - id: betting-decision
+    name: Betting Table Decision
+    description: Decide GO / NO-GO / RESHAPE at the betting table — does the appetite, solution, and team fit the next cycle?
+    agents:
+      - agent_id: product-director-carolina
+        role: Betting decision with rationale
+      - agent_id: strategy-director-tomas
+        role: Strategic alignment check
+        parallel: true
+    gate:
+      type: user_approval
+      description: User makes the betting decision (GO / NO-GO / RESHAPE)
+
+  - id: self-critique
+    name: Self-Critique
+    description: Stress-test the pitch — is the appetite realistic? Are rabbit holes fully named? Are no-gos enforced?
+    agents:
+      - agent_id: product-director-carolina
+        role: Pitch coherence check
+    gate:
+      type: auto
+
+  - id: quality-gate
+    name: Quality Gate
+    model_override: opus
+    description: Mandatory quality review
+    agents:
+      - agent_id: cqo-marta
+        role: Orchestrate quality review
+      - agent_id: copy-director-eduardo
+        role: Pitch prose, no over-promise, decision-forcing language
+        parallel: true
+      - agent_id: tech-director-francisca
+        role: Appetite × scope feasibility, rabbit hole completeness
+        parallel: true
+    gate:
+      type: quality_gate
+      required_verdict: APPROVED
+
+  - id: delivery
+    name: Pitch Package Delivery
+    description: Compile the pitch package — pitch doc + rabbit hole register + betting decision + handoff to build team
+    agents:
+      - agent_id: product-director-carolina
+        role: Full pitch package + handoff brief for build team
+    gate:
+      type: auto
+    outputs:
+      - type: document
+        format: markdown
+        obsidian_path: "WizardingCode/Product/Shape/"
+        description: Complete pitch package — pitch doc + rabbit hole register + no-gos + betting decision + build-team handoff

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "arkaos",
-  "version": "2.54.0",
+  "version": "2.56.0",
   "description": "The Operating System for AI Agent Teams",
   "type": "module",
   "bin": {

package/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "arkaos-core"
-version = "2.54.0"
+version = "2.56.0"
 description = "Core engine for ArkaOS — The Operating System for AI Agent Teams"
 readme = "README.md"
 license = {text = "MIT"}