haiku-method 2.2.0

package/studios/compliance/stages/scope/STAGE.md

@@ -0,0 +1,13 @@
+---
+name: scope
+description: Define the compliance framework, identify applicable controls, and map to systems
+hats: [compliance-analyst, scope-definer, verifier]
+fix_hats: [compliance-analyst, feedback-assessor]
+review: auto
+elaboration: collaborative
+inputs: []
+---
+
+# Scope
+
+Define the compliance framework, identify applicable controls, and map to systems.

package/studios/compliance/stages/scope/discovery/CONTROL-MAPPING.md

@@ -0,0 +1,30 @@
+---
+name: control-mapping
+location: .haiku/intents/{intent-slug}/knowledge/CONTROL-MAPPING.md
+scope: intent
+format: text
+required: true
+---
+
+# Control Mapping
+
+Map regulatory framework controls to organizational systems, services, and processes. This output drives the assess stage's evaluation work.
+
+## Content Guide
+
+Structure the mapping around the target framework:
+
+- **Framework identification** — which framework(s) and version(s) are in scope
+- **Applicable controls** — each control with its requirement description and applicability rationale
+- **Excluded controls** — controls deemed not applicable with documented justification
+- **System inventory** — all in-scope systems, services, data stores, and integrations
+- **Control-to-system mapping** — which systems are relevant to each control
+- **Data classification** — sensitivity level and type of data handled by each system
+- **Scope boundaries** — explicit in-scope/out-of-scope delineation with rationale
+
+## Quality Signals
+
+- Every control has an applicability determination with rationale
+- Exclusions are justified, not just omitted
+- System inventory includes third-party services and integrations
+- Data classifications are consistent and follow a defined scheme

package/studios/compliance/stages/scope/hats/compliance-analyst.md

@@ -0,0 +1,8 @@
+**Focus:** Analyze the target regulatory framework(s), identify all applicable controls, and determine which organizational systems and processes fall within scope. Understand the regulatory landscape before mapping begins.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** assume all controls apply without evaluating applicability
+- The agent **MUST NOT** ignore overlapping requirements across multiple frameworks
+- The agent **MUST** document the rationale for scope inclusion/exclusion decisions
+- The agent **MUST NOT** treat compliance as a checkbox exercise rather than understanding the control's intent
+- The agent **MUST NOT** skip the regulatory context that explains why a control exists

package/studios/compliance/stages/scope/hats/feedback-assessor.md

@@ -0,0 +1,11 @@
+---
+agent_type: general-purpose
+model: haiku
+---
+**Focus:** Independently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** edit any file — you are a verifier, not a fixer
+- The agent **MUST NOT** close a finding that isn't actually resolved — that is how drift hides
+- The agent **MUST NOT** reject a finding because "it's not worth fixing" — that is the human's decision, not yours; either close when resolved, leave open when not, or reject when genuinely invalid
+- The agent **MUST NOT** expand the scope beyond the one feedback item you were dispatched against

package/studios/compliance/stages/scope/hats/scope-definer.md

@@ -0,0 +1,8 @@
+**Focus:** Map applicable controls to specific systems, services, and data flows. Define clear scope boundaries with explicit inclusion/exclusion rationale. Build the system inventory that drives downstream assessment.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** define scope too broadly, making assessment unmanageable
+- The agent **MUST NOT** define scope too narrowly, leaving critical systems unaddressed
+- The agent **MUST** classify data handled by each in-scope system
+- The agent **MUST NOT** omit third-party services and integrations from the inventory
+- The agent **MUST NOT** leave scope boundaries ambiguous or undocumented

package/studios/compliance/stages/scope/hats/verifier.md

@@ -0,0 +1,26 @@
+**Focus:** Validate the per-unit knowledge artifact for the scope stage of compliance. Units here are scoping memo — knowledge artifacts that downstream stages consume. Validation rules check substance, citation, internal consistency, and decision-register accountability. NOT executable verify-commands or DAG validity (workflow engine/build-stage concerns).
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
+- The agent **MUST NOT** validate against frontmatter schema, `depends_on:` resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities.
+- The agent **MUST NOT** advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
+- The agent **MUST NOT** reject for stylistic preferences. Substantive gaps only.
+- The agent **MUST** name a specific failed criterion in any rejection.
+- The agent **MUST NOT** invent rules not in this mandate. Stage scope is the contract.
+
+## What you check (BODY ONLY)
+
+### 1. Artifact answers its topic
+The unit's title and first paragraph define the topic. The remaining body MUST deliver substantive content on that topic. Reject placeholders, content-free outlines, or redirects.
+
+### 2. Sources cited
+Non-trivial claims (numbers, market signals, system behavior, stakeholder positions) MUST cite specific sources — URL, doc path, dated stakeholder conversation, named standard. Reject "industry common knowledge" or unsourced numerical claims.
+
+### 3. Internal consistency
+Title, mission, and body must align. Numerical/categorical claims must be consistent across the body. Recommendations must follow from the evidence presented.
+
+### 4. Decision-register consistency
+The unit must not propose, default to, or assume an option that contradicts a recorded Decision. Cite the Decision ID in any rejection.
+
+### 5. Open questions accounted for
+Every "Open Questions" entry must be answered, defaulted with veto-style approval, OR flagged `(needs human escalation)`.

package/studios/compliance/stages/scope/outputs/CONTROL-MAPPING.md

@@ -0,0 +1,25 @@
+---
+name: control-mapping
+location: .haiku/intents/{intent-slug}/stages/scope/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Control Mapping
+
+Framework requirements mapped to specific systems, owners, and scope boundaries.
+
+## Expected Artifacts
+
+- **Control inventory** -- all applicable controls from the target framework with applicability justification
+- **System inventory** -- in-scope services, data stores, and integrations with data classification
+- **Scope boundary document** -- explicit inclusion/exclusion rationale for each system and control
+- **Regulatory obligations** -- applicable regulations identified and prioritized
+
+## Quality Signals
+
+- Every control has an applicability determination with rationale
+- System inventory includes data classification for each asset
+- Exclusions have documented justification, not just omission
+- Scope boundaries are clear enough for an external auditor to follow

package/studios/compliance/stages/scope/phases/ELABORATION.md

@@ -0,0 +1,16 @@
+# Scope Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Control mapping identifies all applicable controls from the target framework with justification for any exclusions"
+- "System inventory lists every in-scope service, data store, and integration with its data classification"
+- "Scope boundary document clearly defines what is in-scope and out-of-scope with rationale for each decision"
+
+### Bad criteria — vague (no clear check)
+
+- "Scope is defined"
+- "Controls are mapped"
+- "Systems are inventoried"
+

package/studios/compliance/stages/scope/review-agents/completeness.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify all applicable controls are identified and mapped to systems.
+
+**Check:**
+- The agent **MUST** verify that the compliance framework is correctly identified and versioned
+- The agent **MUST** verify that all in-scope systems, data stores, and processes are inventoried
+- The agent **MUST** verify that no applicable controls are missing from the mapping
+- The agent **MUST** verify that out-of-scope items have documented justification for exclusion

package/studios/compliance/templates/quarterly-evidence-collection.md

@@ -0,0 +1,31 @@
+---
+name: quarterly-evidence-collection
+studio: compliance
+description: Quarterly evidence collection cycle for ongoing compliance
+parameters:
+  - name: framework
+    description: "Compliance framework: SOC2, HIPAA, GDPR, ISO27001"
+    required: true
+  - name: quarter
+    description: "Quarter: Q1, Q2, Q3, Q4"
+    required: true
+  - name: year
+    description: Year
+    required: true
+stages-override: [assess, document]
+units:
+  - name: "control-review"
+    stage: assess
+    criteria:
+      - "All {{ framework }} controls reviewed for {{ quarter }} {{ year }}"
+      - "Gaps identified with severity ratings"
+      - "No critical gaps from previous quarter remain unresolved"
+  - name: "evidence-package"
+    stage: document
+    criteria:
+      - "Evidence collected for all in-scope controls"
+      - "Screenshots and logs are timestamped within the quarter"
+      - "Evidence index updated and organized per auditor format"
+---
+
+Recurring quarterly compliance evidence collection. Does not require full scope/remediate cycle.

package/studios/customer-success/STUDIO.md

@@ -0,0 +1,11 @@
+---
+name: customer-success
+description: Customer success lifecycle from onboarding through adoption, health monitoring, expansion, and renewal
+stages: [onboarding, adoption, health-check, expansion, renewal]
+category: go-to-market
+default_model: sonnet
+---
+
+# Customer Success Studio
+
+Customer success lifecycle for managing accounts from initial onboarding through product adoption, health monitoring, expansion opportunities, and renewal. Works for SaaS, enterprise accounts, and managed services.

package/studios/customer-success/examples/q2-churn-playbook/intent.md

@@ -0,0 +1,17 @@
+---
+title: q2-churn-playbook
+studio: customer-success
+stages: [onboarding, adoption, health-check, expansion, renewal]
+status: complete
+---
+
+# Q2 Churn Recovery Playbook
+
+Build and execute a churn recovery playbook for mid-market accounts that signed up in Q3 2025 but never completed onboarding. Q1 logo churn spiked 40% driven almost entirely by this cohort. The playbook needs a re-onboarding motion, a health signal update, and a save-play for renewal conversations.
+
+## Goals
+
+- Segment and score the at-risk Q3 mid-market cohort (50–200 seat accounts)
+- Launch a re-onboarding touchpoint program with CSM + product marketing
+- Define leading health indicators specific to workspace setup failure
+- Cut Q2 logo churn by at least 50% from Q1 levels

package/studios/customer-success/examples/q2-churn-playbook/pre-intent.yml

@@ -0,0 +1,17 @@
+related:
+  - product-strategy
+  - sales
+  - marketing
+turns:
+  - role: user
+    text: "Q1 logo churn spiked 40%. Build me a playbook to stop the bleeding."
+  - role: agent
+    text: "Do we know which segment is churning — SMB, mid-market, enterprise?"
+  - role: user
+    text: "Mid-market, mostly 50-200 seat accounts that signed up in Q3."
+  - role: agent
+    text: "Is there a common failure pattern — onboarding gap, feature mismatch, price objection?"
+  - role: user
+    text: "Onboarding. They never got past the workspace setup."
+  - role: agent
+    text: "Got it — the playbook will focus on the Q3 mid-market cohort and onboarding recovery."

package/studios/customer-success/fix-hats/reconciler.md

@@ -0,0 +1,10 @@
+---
+agent_type: general-purpose
+---
+**Focus:** Reconcile cross-stage artifacts against studio-wide standards. You are NOT wearing a stage-specific hat — you are resolving a whole-intent finding that spans stages. Your mandate is alignment, not fresh authoring.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** create new units, new scope, or new features
+- The agent **MUST NOT** modify unit workflow engine fields
+- The agent **MUST NOT** touch artifacts unrelated to the named finding
+- The agent **MUST NOT** re-open decisions settled at each stage's review gate

package/studios/customer-success/fix-hats/validator.md

@@ -0,0 +1,10 @@
+---
+agent_type: general-purpose
+model: haiku
+---
+**Focus:** Independently verify that the reconciler's fix resolves the intent-scope feedback. You are the terminal hat — the workflow engine trusts your closure decision.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** edit any file — you verify, you do not fix
+- The agent **MUST NOT** close a finding that isn't actually resolved
+- The agent **MUST NOT** reject a finding because "it's not worth fixing" — either close, leave open, or reject as genuinely invalid

package/studios/customer-success/operations/health-score-refresh.md

@@ -0,0 +1,21 @@
+---
+name: health-score-refresh
+type: scheduled
+owner: agent
+schedule: "0 8 * * 1"
+runtime: node
+---
+
+**Purpose:** Recalculate account health scores weekly. Leading indicators prevent churn surprises.
+
+**Procedure:**
+- Pull usage metrics for the review period
+- Check support ticket volume and severity trends
+- Verify stakeholder engagement (meeting attendance, response times)
+- Recalculate composite health score
+- Flag accounts that crossed risk thresholds
+
+**Signals:**
+- Weekly cadence
+- After any major product incident
+- Approaching renewal window (90 days out)

package/studios/customer-success/operations/nps-collection.md

@@ -0,0 +1,20 @@
+---
+name: nps-collection
+type: scheduled
+owner: agent
+schedule: "0 9 1 */3 *"
+runtime: node
+---
+
+**Purpose:** Collect Net Promoter Score feedback at regular intervals to track satisfaction trends.
+
+**Procedure:**
+- Send NPS survey to active accounts
+- Collect and aggregate responses
+- Segment scores by account tier, tenure, and health
+- Route detractor responses to the account owner for follow-up
+
+**Signals:**
+- Quarterly survey cadence
+- After major product launches
+- After incident resolution (relationship repair check)

package/studios/customer-success/operations/renewal-tracker.md

@@ -0,0 +1,20 @@
+---
+name: renewal-tracker
+type: scheduled
+owner: human
+frequency: "monthly"
+---
+
+**Purpose:** Track upcoming renewals and ensure proactive engagement starts early enough.
+
+**Procedure:**
+- [ ] Review renewals in the next 90/60/30 day windows
+- [ ] Verify renewal strategy exists for each upcoming renewal
+- [ ] Check health scores for renewal accounts
+- [ ] Identify at-risk renewals needing executive engagement
+- [ ] Confirm pricing and terms are prepared
+
+**Signals:**
+- Monthly tracking cadence
+- Account enters 90-day renewal window
+- Health score drops for a renewal account

package/studios/customer-success/reflections/adoption.md

@@ -0,0 +1,17 @@
+---
+name: adoption
+studio: customer-success
+---
+
+**Analyze:** Feature adoption rates, usage patterns, time-to-value for onboarded accounts.
+
+**Look for:**
+- Features with low adoption despite high value
+- Adoption patterns that predict expansion readiness
+- Onboarding steps that correlated with faster time-to-value
+- Accounts that plateaued in adoption
+
+**Produce:**
+- Adoption funnel by feature
+- Onboarding effectiveness assessment
+- Recommendations for adoption playbook improvements

package/studios/customer-success/reflections/retention.md

@@ -0,0 +1,17 @@
+---
+name: retention
+studio: customer-success
+---
+
+**Analyze:** Renewal outcomes, churn reasons, expansion revenue, health score accuracy.
+
+**Look for:**
+- Did health scores predict renewal outcomes accurately?
+- What churn signals were missed?
+- Expansion revenue relative to targets
+- Whether onboarding quality correlated with retention
+
+**Produce:**
+- Retention rate and trend analysis
+- Health score model accuracy assessment
+- Recommendations for earlier churn intervention

package/studios/customer-success/review-agents/cross-stage-consistency.md

@@ -0,0 +1,17 @@
+---
+scope: intent
+interpretation: lens
+---
+**Mandate:** Verify the intent's artifacts are internally consistent across stages. You are the only reviewer that sees the whole intent at once — your job is to catch seams that per-stage reviewers miss.
+
+**Check:**
+- The agent **MUST** verify that each stage's outputs align with what upstream stages specified — no dropped requirements, no silent scope expansion
+- The agent **MUST** verify that naming is consistent across stages — a concept named one thing upstream should carry the same name downstream
+- The agent **MUST** verify that stages' declared outputs exist at the paths their unit frontmatter promised
+- The agent **MUST** verify that the stages collectively deliver the intent's stated goal (read `intent.md`) — partial delivery is a finding
+- The agent **MUST** verify that concerns raised by any stage's review were actually addressed (not silently ignored)
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** re-litigate decisions already approved at each stage's gate
+- The agent **MUST NOT** propose new features or scope additions
+- The agent **MUST NOT** flag stylistic preferences — concrete divergence only

package/studios/customer-success/stages/adoption/STAGE.md

@@ -0,0 +1,15 @@
+---
+name: adoption
+description: Drive product adoption, usage patterns, and feature discovery
+hats: [adoption-coach, usage-analyst, verifier]
+fix_hats: [adoption-coach, feedback-assessor]
+review: auto
+elaboration: autonomous
+inputs:
+  - stage: onboarding
+    discovery: onboarding-report
+---
+
+# Adoption
+
+Drive product adoption, usage patterns, and feature discovery.

package/studios/customer-success/stages/adoption/discovery/USAGE-REPORT.md

@@ -0,0 +1,30 @@
+---
+name: usage-report
+location: .haiku/intents/{intent-slug}/knowledge/USAGE-REPORT.md
+scope: intent
+format: text
+required: true
+---
+
+# Usage Report
+
+Document product adoption patterns and enablement progress. This output feeds downstream stages (health-check, expansion, renewal) with quantified usage intelligence.
+
+## Content Guide
+
+Structure the report around adoption dimensions:
+
+- **Usage metrics summary** — DAU/MAU, feature utilization rates, workflow completion rates
+- **Feature adoption heatmap** — which features are heavily used, lightly used, and unused
+- **Adoption trends** — usage trajectory over time, acceleration or deceleration patterns
+- **User segmentation** — adoption patterns by team, role, or persona
+- **Bottlenecks identified** — where users drop off, struggle, or abandon workflows
+- **Enablement actions taken** — training, content, and coaching delivered with measured impact
+- **Recommendations for health-check** — signals to monitor and risks to track
+
+## Quality Signals
+
+- Metrics are quantified with specific numbers, not qualitative assessments
+- Trends include directional context (improving, stable, declining) with evidence
+- Bottlenecks trace to specific workflow steps, not vague "low adoption" claims
+- Enablement actions are tied to measurable outcome changes

package/studios/customer-success/stages/adoption/hats/adoption-coach.md

@@ -0,0 +1,8 @@
+**Focus:** Guide customers from basic usage to deep product engagement. Identify underutilized features, create enablement strategies, and connect product capabilities to the customer's specific business outcomes.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** push feature adoption without connecting to customer business value
+- The agent **MUST NOT** create generic enablement plans that ignore the customer's specific use cases
+- The agent **MUST NOT** measure adoption by logins rather than meaningful workflow completion
+- The agent **MUST NOT** overwhelm customers with too many features at once instead of sequencing
+- The agent **MUST** track whether enablement efforts actually change usage behavior

package/studios/customer-success/stages/adoption/hats/feedback-assessor.md

@@ -0,0 +1,11 @@
+---
+agent_type: general-purpose
+model: haiku
+---
+**Focus:** Independently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** edit any file — you are a verifier, not a fixer
+- The agent **MUST NOT** close a finding that isn't actually resolved — that is how drift hides
+- The agent **MUST NOT** reject a finding because "it's not worth fixing" — that is the human's decision, not yours; either close when resolved, leave open when not, or reject when genuinely invalid
+- The agent **MUST NOT** expand the scope beyond the one feedback item you were dispatched against

package/studios/customer-success/stages/adoption/hats/usage-analyst.md

@@ -0,0 +1,8 @@
+**Focus:** Analyze product usage data to identify adoption patterns, bottlenecks, and opportunities. Transform raw telemetry into actionable insights about how the customer is — and isn't — using the product.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** report vanity metrics (page views, logins) without measuring value-driving actions
+- The agent **MUST NOT** analyze usage in isolation without comparing against benchmarks or goals
+- The agent **MUST NOT** present data without interpreting what it means for the customer's success
+- The agent **MUST NOT** ignore declining usage trends until they become critical
+- The agent **MUST** segment usage by team, role, or workflow to find specific adoption gaps

package/studios/customer-success/stages/adoption/hats/verifier.md

@@ -0,0 +1,26 @@
+**Focus:** Validate the per-unit operational artifact for the adoption stage of customer-success. Units here are adoption play — operational steps with concrete preconditions, actions, and post-condition checks. Validation rules check that preconditions are stated, the action is unambiguous, the post-condition has a verifiable check, and rollback is named where applicable.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
+- The agent **MUST NOT** validate against frontmatter schema, `depends_on:` resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities.
+- The agent **MUST NOT** advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
+- The agent **MUST NOT** reject for stylistic preferences. Substantive gaps only.
+- The agent **MUST** name a specific failed criterion in any rejection.
+- The agent **MUST NOT** invent rules not in this mandate. Stage scope is the contract.
+
+## What you check (BODY ONLY)
+
+### 1. Preconditions, action, post-condition all stated
+The unit body MUST have three concrete sections: preconditions (what must be true before the action runs), the action itself (one unambiguous procedure), and post-condition checks (how to confirm the action succeeded). Reject if any of the three is missing or vague.
+
+### 2. Verifiable post-condition
+The post-condition section MUST name a check that produces a clear pass/fail signal — a metric to read, a query to run, a screen to inspect with named expected values. "Verify by eye that things look good" is a reject.
+
+### 3. Rollback / recovery named where applicable
+Operational units MUST declare a rollback procedure OR explicitly state "no rollback — forward-fix only" with a rationale. Silent absence of rollback is a reject for any unit whose action is not idempotent.
+
+### 4. Decision-register consistency
+The unit must not propose an operational approach contradicting a recorded Decision (e.g., blue-green deploy when Decision N chose canary). Cite the Decision ID.
+
+### 5. Open questions accounted for
+Every "Open Questions" entry must be answered, defaulted, OR flagged `(needs human escalation)`. Operational open questions left to runtime are how outages happen.

package/studios/customer-success/stages/adoption/outputs/USAGE-REPORT.md

@@ -0,0 +1,25 @@
+---
+name: usage-report
+location: .haiku/intents/{intent-slug}/stages/adoption/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Usage Report
+
+Quantified adoption metrics and enablement plan for driving product usage.
+
+## Expected Artifacts
+
+- **Adoption metrics** -- quantified usage data across key features (DAU/MAU, feature breadth, workflow completion)
+- **Enablement plan** -- prioritized recommendations for underutilized capabilities
+- **Adoption patterns** -- identified bottlenecks, at-risk workflows, and usage trends
+- **Feature-to-outcome mapping** -- each feature linked to a concrete business outcome
+
+## Quality Signals
+
+- Usage metrics are quantified, not subjective assessments
+- Enablement recommendations map features to business outcomes the customer cares about
+- At least 3 underutilized features are identified with specific enablement actions
+- Customer has progressed from initial setup usage to habitual engagement

package/studios/customer-success/stages/adoption/phases/ELABORATION.md

@@ -0,0 +1,16 @@
+# Adoption Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Usage report identifies at least 3 underutilized features with specific enablement recommendations per feature"
+- "Adoption plan includes measurable targets for DAU/MAU ratio, feature breadth, and workflow completion rates"
+- "Enablement materials map each feature to a concrete business outcome the customer cares about"
+
+### Bad criteria — vague (no clear check)
+
+- "Adoption is increasing"
+- "Customer is using the product"
+- "Features were explained"
+

package/studios/customer-success/stages/adoption/review-agents/effectiveness.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify adoption strategies are evidence-based and measurable.
+
+**Check:**
+- The agent **MUST** verify that usage metrics are defined and tracked against targets
+- The agent **MUST** verify that feature discovery recommendations are prioritized by customer value, not product roadmap
+- The agent **MUST** verify that adoption blockers are identified with specific remediation actions
+- The agent **MUST** verify that success is measured by customer outcomes, not just login frequency

package/studios/customer-success/stages/expansion/STAGE.md

@@ -0,0 +1,15 @@
+---
+name: expansion
+description: Identify and pursue upsell/cross-sell opportunities
+hats: [growth-strategist, value-consultant, verifier]
+fix_hats: [growth-strategist, feedback-assessor]
+review: [ask, await]
+elaboration: collaborative
+inputs:
+  - stage: health-check
+    discovery: health-report
+---
+
+# Expansion
+
+Identify and pursue upsell/cross-sell opportunities.

package/studios/customer-success/stages/expansion/discovery/OPPORTUNITY-BRIEF.md

@@ -0,0 +1,30 @@
+---
+name: opportunity-brief
+location: .haiku/intents/{intent-slug}/knowledge/OPPORTUNITY-BRIEF.md
+scope: intent
+format: text
+required: true
+---
+
+# Opportunity Brief
+
+Document expansion opportunities with business justification. This output feeds the renewal stage with a clear picture of growth potential and customer value alignment.
+
+## Content Guide
+
+Structure the brief around each expansion opportunity:
+
+- **Opportunity summary** — prioritized list of upsell/cross-sell opportunities with revenue estimates
+- **Customer alignment** — how each opportunity maps to the customer's stated strategic priorities
+- **Value justification** — ROI model per opportunity using the customer's own data and outcomes
+- **Competitive context** — alternatives the customer could pursue and why this is the better path
+- **Rollout plan** — phased adoption approach per opportunity with success milestones
+- **Stakeholder strategy** — who needs to approve, champion, and implement each opportunity
+- **Risk factors** — what could prevent expansion success and how to mitigate
+
+## Quality Signals
+
+- Every opportunity ties to a customer need, not just a product capability
+- Revenue estimates include defensible assumptions, not aspirational numbers
+- ROI models use the customer's actual data, not industry averages
+- Rollout plans account for the customer's capacity to absorb change

package/studios/customer-success/stages/expansion/hats/feedback-assessor.md

@@ -0,0 +1,11 @@
+---
+agent_type: general-purpose
+model: haiku
+---
+**Focus:** Independently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** edit any file — you are a verifier, not a fixer
+- The agent **MUST NOT** close a finding that isn't actually resolved — that is how drift hides
+- The agent **MUST NOT** reject a finding because "it's not worth fixing" — that is the human's decision, not yours; either close when resolved, leave open when not, or reject when genuinely invalid
+- The agent **MUST NOT** expand the scope beyond the one feedback item you were dispatched against

package/studios/customer-success/stages/expansion/hats/growth-strategist.md

@@ -0,0 +1,8 @@
+**Focus:** Identify expansion opportunities by aligning product capabilities with the customer's evolving needs and strategic priorities. Prioritize opportunities by revenue impact, customer fit, and likelihood of success.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** push products the customer doesn't need to hit quota
+- The agent **MUST NOT** identify opportunities without grounding them in the customer's stated priorities
+- The agent **MUST NOT** ignore account health signals — expanding an unhealthy account accelerates churn
+- The agent **MUST** siz opportunities with defensible revenue estimates
+- The agent **MUST NOT** propose expansion without a phased adoption plan

package/studios/customer-success/stages/expansion/hats/value-consultant.md

@@ -0,0 +1,8 @@
+**Focus:** Build ROI justifications and business cases for expansion opportunities. Translate product capabilities into financial and operational impact using the customer's own data and language.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** use generic ROI models instead of the customer's actual data
+- The agent **MUST NOT** leadd with product features instead of business outcomes
+- The agent **MUST NOT** build business cases that only resonate with technical buyers, not economic buyers
+- The agent **MUST NOT** overpromise ROI without defensible assumptions
+- The agent **MUST** tailor the value narrative to each stakeholder's priorities