haiku-method 2.2.0

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

@@ -0,0 +1,26 @@
+**Focus:** Validate the per-unit design/synthesis artifact for the expansion stage of customer-success. Units here are expansion proposal — designed outputs that downstream stages execute against. Validation rules check substance, internal coherence with the brief, traceability to upstream inputs, and decision-register accountability. NOT executable verify-commands.
+
+**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 design brief
+The unit's title and first paragraph define the design problem. The remaining body MUST deliver a concrete designed artifact (specification, structure, interaction model, plan element, etc.) — not an outline, not a deferral, not a "we'll figure this out later".
+
+### 2. Trace to upstream inputs
+Every design choice that depends on upstream knowledge MUST cite the specific upstream artifact (knowledge unit, decision, requirement). Reject choices that conflict with — or float free of — what the upstream stages established.
+
+### 3. Internal coherence
+Sub-components / sections of the design must compose without contradiction. A design that says "single-tenant" in one section and "multi-tenant by default" in another is rejected. Cite the contradicting paragraphs.
+
+### 4. Decision-register consistency
+The unit must not propose an option contradicting a recorded Decision. Cite the Decision ID.
+
+### 5. Open questions accounted for
+Every "Open Questions" entry must be answered, defaulted, OR flagged `(needs human escalation)`. Design open questions left unresolved without an escalation flag are a reject — downstream stages cannot consume an under-specified design.

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

@@ -0,0 +1,25 @@
+---
+name: opportunity-brief
+location: .haiku/intents/{intent-slug}/stages/expansion/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Opportunity Brief
+
+Prioritized expansion opportunities with ROI justification and rollout plans.
+
+## Expected Artifacts
+
+- **Expansion opportunities** -- prioritized list tied to demonstrated customer value and quantified business impact
+- **ROI justifications** -- grounded in the customer's own usage data and outcomes
+- **Customer alignment** -- opportunities mapped to the customer's strategic priorities
+- **Rollout proposals** -- phased plans with success metrics tied to customer business outcomes
+
+## Quality Signals
+
+- At least 2 expansion opportunities are identified with quantified revenue impact
+- Each opportunity maps to a specific customer pain point with supporting evidence
+- ROI justifications use the customer's actual usage data, not generic projections
+- Proposals are ready for customer-facing presentation

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

@@ -0,0 +1,16 @@
+# Expansion Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Opportunity brief identifies at least 2 expansion opportunities with quantified revenue impact and customer value justification"
+- "Each opportunity maps to a specific customer pain point or strategic initiative with supporting evidence from usage data"
+- "Expansion proposal includes a phased rollout plan with success metrics tied to customer business outcomes"
+
+### Bad criteria — vague (no clear check)
+
+- "Upsell opportunities identified"
+- "Growth plan exists"
+- "Customer could buy more"
+

package/studios/customer-success/stages/expansion/review-agents/opportunity-validity.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify expansion opportunities are genuine and well-timed.
+
+**Check:**
+- The agent **MUST** verify that upsell recommendations align with the customer's actual needs and usage patterns
+- The agent **MUST** verify that timing considers the customer's contract cycle and budget planning
+- The agent **MUST** verify that value proposition is specific to this customer, not a generic pitch
+- The agent **MUST** verify that current satisfaction and adoption levels support the expansion conversation

package/studios/customer-success/stages/health-check/STAGE.md

@@ -0,0 +1,15 @@
+---
+name: health-check
+description: Monitor account health, identify risks, and create action plans
+hats: [health-monitor, risk-analyst, verifier]
+fix_hats: [health-monitor, feedback-assessor]
+review: ask
+elaboration: autonomous
+inputs:
+  - stage: adoption
+    discovery: usage-report
+---
+
+# Health Check
+
+Monitor account health, identify risks, and create action plans.

package/studios/customer-success/stages/health-check/discovery/HEALTH-REPORT.md

@@ -0,0 +1,30 @@
+---
+name: health-report
+location: .haiku/intents/{intent-slug}/knowledge/HEALTH-REPORT.md
+scope: intent
+format: text
+required: true
+---
+
+# Health Report
+
+Document the account's overall health assessment with risk analysis. This output feeds downstream stages (expansion, renewal) with a clear picture of account stability.
+
+## Content Guide
+
+Structure the report around health dimensions:
+
+- **Health score summary** — overall rating (healthy/at-risk/critical) with confidence level
+- **Dimensional assessment** — usage health, engagement health, support health, stakeholder health, contract alignment
+- **Risk register** — severity-ranked churn indicators with leading vs lagging classification
+- **Root cause analysis** — underlying drivers for any unhealthy dimensions
+- **Mitigation plans** — specific actions per risk with owners, success criteria, and priority
+- **Escalation items** — issues requiring immediate leadership attention
+- **Expansion readiness** — whether the account is healthy enough to pursue growth
+
+## Quality Signals
+
+- Every health dimension has a rating backed by specific evidence
+- Risks distinguish between leading indicators (predictive) and lagging indicators (reactive)
+- Mitigation plans have measurable success criteria, not just action items
+- Expansion readiness assessment is honest — unhealthy accounts are flagged, not glossed over

package/studios/customer-success/stages/health-check/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/health-check/hats/health-monitor.md

@@ -0,0 +1,8 @@
+**Focus:** Assess overall account health across multiple dimensions — usage, engagement, support interactions, stakeholder sentiment, and contract alignment. Produce a holistic health score with evidence backing each dimension.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** rely on a single metric (like NPS) as a proxy for overall health
+- The agent **MUST** captur qualitative signals like stakeholder sentiment or executive engagement
+- The agent **MUST NOT** assess health at a single point in time without tracking trends
+- The agent **MUST NOT** ignore silent accounts — no complaints doesn't mean healthy
+- The agent **MUST NOT** rate dimensions without documenting the specific evidence behind each rating

package/studios/customer-success/stages/health-check/hats/risk-analyst.md

@@ -0,0 +1,8 @@
+**Focus:** Identify churn risks, quantify their severity, and create concrete mitigation plans. Look for leading indicators — not just lagging ones — to catch problems before they become irreversible.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** only identify risks after the customer has already escalated
+- The agent **MUST NOT** list risks without severity ranking or mitigation plans
+- The agent **MUST NOT** treat all risks as equally urgent instead of triaging by impact and reversibility
+- The agent **MUST** distinguish between leading indicators (predictive) and lagging indicators (already happened)
+- The agent **MUST NOT** create mitigation plans without measurable success criteria or owners

package/studios/customer-success/stages/health-check/hats/verifier.md

@@ -0,0 +1,26 @@
+**Focus:** Validate the per-unit knowledge artifact for the health-check stage of customer-success. Units here are health-signal report — 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/customer-success/stages/health-check/outputs/HEALTH-REPORT.md

@@ -0,0 +1,25 @@
+---
+name: health-report
+location: .haiku/intents/{intent-slug}/stages/health-check/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Health Report
+
+Scored account health assessment with risk identification and mitigation plans.
+
+## Expected Artifacts
+
+- **Health scorecard** -- account rated across multiple dimensions (usage, engagement, support sentiment, stakeholder access, contract alignment)
+- **Risk assessment** -- churn indicators identified with severity levels and leading indicators
+- **Mitigation plans** -- concrete actions for each risk with success criteria and owners
+- **Escalation paths** -- documented procedures for critical risks
+
+## Quality Signals
+
+- Health assessment covers at least 5 dimensions with evidence for each rating
+- Each risk has a concrete mitigation plan with measurable success criteria
+- Report includes a clear verdict: healthy, at-risk, or critical
+- Escalation paths are documented for critical risks

package/studios/customer-success/stages/health-check/phases/ELABORATION.md

@@ -0,0 +1,16 @@
+# Health Check Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Health scorecard rates account across at least 5 dimensions (usage, engagement, support sentiment, stakeholder access, contract alignment) with evidence for each rating"
+- "Risk assessment identifies specific churn indicators with severity levels and mitigation timelines"
+- "Action plan includes owner assignments and measurable success criteria for each remediation item"
+
+### Bad criteria — vague (no clear check)
+
+- "Account health is assessed"
+- "Risks are identified"
+- "Action plan exists"
+

package/studios/customer-success/stages/health-check/review-agents/risk-accuracy.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify health scores accurately reflect account risk.
+
+**Check:**
+- The agent **MUST** verify that health scoring criteria are applied consistently across accounts
+- The agent **MUST** verify that leading indicators (support tickets, usage decline, stakeholder changes) are weighted appropriately
+- The agent **MUST** verify that risk classifications trigger specific action plans, not just color codes
+- The agent **MUST** verify that no at-risk accounts are classified as healthy due to recency bias

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

@@ -0,0 +1,13 @@
+---
+name: onboarding
+description: Guide new customers through setup, training, and initial value realization
+hats: [onboarding-lead, technical-enabler, verifier]
+fix_hats: [onboarding-lead, feedback-assessor]
+review: ask
+elaboration: collaborative
+inputs: []
+---
+
+# Onboarding
+
+Guide new customers through setup, training, and initial value realization.

package/studios/customer-success/stages/onboarding/discovery/ONBOARDING-REPORT.md

@@ -0,0 +1,30 @@
+---
+name: onboarding-report
+location: .haiku/intents/{intent-slug}/knowledge/ONBOARDING-REPORT.md
+scope: intent
+format: text
+required: true
+---
+
+# Onboarding Report
+
+Document the onboarding journey for the customer account. This output feeds downstream stages (adoption, health-check, expansion, renewal) as their foundational context.
+
+## Content Guide
+
+Structure the report around the customer's onboarding milestones:
+
+- **Customer profile** — account details, key stakeholders, and strategic objectives
+- **Setup completed** — technical integrations, configurations, and environment details
+- **Training delivered** — sessions conducted, materials provided, attendee coverage
+- **Initial value achieved** — first success milestones hit with measurable outcomes
+- **Stakeholder map** — decision makers, champions, and technical contacts
+- **Open items** — unresolved issues, pending integrations, or deferred requests
+- **Adoption recommendations** — areas of focus for the adoption stage based on onboarding observations
+
+## Quality Signals
+
+- Every milestone has a measurable outcome, not just a completion checkbox
+- Stakeholder map includes roles, influence levels, and engagement status
+- Open items have owners and expected resolution paths
+- Recommendations for adoption are specific and grounded in onboarding observations

package/studios/customer-success/stages/onboarding/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/onboarding/hats/onboarding-lead.md

@@ -0,0 +1,8 @@
+**Focus:** Orchestrate the onboarding journey — define success milestones, coordinate stakeholders, and ensure the customer reaches initial value realization as quickly as possible. Own the onboarding plan and drive accountability.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** treat onboarding as a checklist without tying steps to customer outcomes
+- The agent **MUST NOT** skip stakeholder identification and relying on a single point of contact
+- The agent **MUST** define what "initial value" looks like in measurable terms
+- The agent **MUST NOT** rush through setup without confirming the customer understands why each step matters
+- The agent **MUST NOT** fail to document handoff context for the adoption stage

package/studios/customer-success/stages/onboarding/hats/technical-enabler.md

@@ -0,0 +1,8 @@
+**Focus:** Handle technical setup, integration configuration, data migration, and environment validation. Ensure the product is correctly deployed and connected to the customer's ecosystem before training begins.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** configure integrations without verifying they work end-to-end
+- The agent **MUST** document environment-specific configuration decisions
+- The agent **MUST NOT** assume the customer's technical team understands the product's architecture
+- The agent **MUST NOT** leave integration edge cases undocumented for the adoption team to discover
+- The agent **MUST NOT** skip validation of data flow through the entire integration chain

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

@@ -0,0 +1,26 @@
+**Focus:** Validate the per-unit operational artifact for the onboarding stage of customer-success. Units here are onboarding milestone — 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/onboarding/outputs/ONBOARDING-REPORT.md

@@ -0,0 +1,25 @@
+---
+name: onboarding-report
+location: .haiku/intents/{intent-slug}/stages/onboarding/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Onboarding Report
+
+Documentation of customer setup, training delivery, and initial value realization.
+
+## Expected Artifacts
+
+- **Setup completion record** -- documented setup steps completed with verification status
+- **Training delivery log** -- sessions delivered with attendance and feedback captured
+- **Initial value metrics** -- first measurable success milestone achieved by the customer
+- **Handoff brief** -- account context, key stakeholders, and open items for adoption stage
+
+## Quality Signals
+
+- Customer has achieved their first measurable success milestone
+- Technical integrations are verified working
+- Handoff includes complete account context for the adoption stage
+- Open items are documented with owners and timelines

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

@@ -0,0 +1,16 @@
+# Onboarding Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Onboarding plan includes a success milestone checklist with measurable outcomes for each week"
+- "Technical setup guide covers all integration points with verified configuration steps"
+- "Training materials address at least 3 distinct user personas with role-specific workflows"
+
+### Bad criteria — vague (no clear check)
+
+- "Customer is onboarded"
+- "Setup is done"
+- "Training was provided"
+

package/studios/customer-success/stages/onboarding/review-agents/completeness.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the onboarding plan covers all steps to initial value realization.
+
+**Check:**
+- The agent **MUST** verify that all technical setup steps are documented with prerequisites
+- The agent **MUST** verify that training materials cover the customer's actual use cases, not just generic features
+- The agent **MUST** verify that success milestones are defined and measurable
+- The agent **MUST** verify that handoff from sales context is complete — no lost commitments or expectations

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

@@ -0,0 +1,15 @@
+---
+name: renewal
+description: Prepare renewal strategy, negotiate terms, and secure commitment
+hats: [renewal-manager, executive-sponsor, verifier]
+fix_hats: [renewal-manager, feedback-assessor]
+review: [external, await]
+elaboration: collaborative
+inputs:
+  - stage: expansion
+    discovery: opportunity-brief
+---
+
+# Renewal
+
+Prepare renewal strategy, negotiate terms, and secure commitment.

package/studios/customer-success/stages/renewal/discovery/RENEWAL-OUTCOME.md

@@ -0,0 +1,30 @@
+---
+name: renewal-outcome
+location: .haiku/intents/{intent-slug}/knowledge/RENEWAL-OUTCOME.md
+scope: intent
+format: text
+required: true
+---
+
+# Renewal Outcome
+
+Document the renewal result with lessons learned. This output provides a complete record of the renewal engagement for future account cycles.
+
+## Content Guide
+
+Structure the outcome around the renewal lifecycle:
+
+- **Value realization summary** — quantified ROI achieved during the contract period
+- **Renewal result** — renewed, expanded, downsized, or churned with specific terms
+- **Negotiation summary** — key discussion points, objections raised, concessions made
+- **Executive engagement** — business review outcomes and executive-level commitments
+- **Contract changes** — what changed from the previous contract and why
+- **Lessons learned** — what worked, what didn't, and what to do differently next cycle
+- **Next cycle recommendations** — priorities for the next onboarding-to-renewal cycle
+
+## Quality Signals
+
+- Value realization uses actual measured outcomes, not projected estimates
+- Negotiation summary captures what the customer actually cared about, not assumptions
+- Lessons learned are specific and actionable, not generic platitudes
+- Next cycle recommendations are concrete enough to act on immediately

package/studios/customer-success/stages/renewal/hats/executive-sponsor.md

@@ -0,0 +1,8 @@
+**Focus:** Provide executive-level engagement for the renewal — deliver the business review narrative, reinforce strategic alignment, and signal organizational commitment. Operate at the CxO level to frame the partnership's future.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** delegate executive engagement to operational staff during high-stakes renewals
+- The agent **MUST NOT** present a backward-looking report without a compelling forward vision
+- The agent **MUST** tailor the narrative to the specific executive audience
+- The agent **MUST NOT** engage only when the renewal is at risk instead of proactively reinforcing value
+- The agent **MUST NOT** fail to connect the product's impact to the customer's board-level priorities

package/studios/customer-success/stages/renewal/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/renewal/hats/renewal-manager.md

@@ -0,0 +1,8 @@
+**Focus:** Own the renewal process end-to-end — build the value realization narrative, prepare negotiation strategy, anticipate objections, and drive the deal to close. Balance customer retention with commercial objectives.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** start renewal conversations too late — reactive instead of proactive
+- The agent **MUST NOT** leadd with price instead of value realized
+- The agent **MUST** prepar for specific objections the customer is likely to raise
+- The agent **MUST NOT** offer concessions without understanding the customer's actual priorities
+- The agent **MUST NOT** treat renewal as a transaction rather than a strategic conversation about future value

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

@@ -0,0 +1,26 @@
+**Focus:** Validate the per-unit operational artifact for the renewal stage of customer-success. Units here are renewal motion — 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/renewal/outputs/RENEWAL-STRATEGY.md

@@ -0,0 +1,25 @@
+---
+name: renewal-strategy
+location: .haiku/intents/{intent-slug}/stages/renewal/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Renewal Strategy
+
+Comprehensive renewal preparation with value summary, negotiation brief, and executive review materials.
+
+## Expected Artifacts
+
+- **Value realization summary** -- quantified ROI achieved during the contract period from actual usage and outcome data
+- **Negotiation brief** -- anticipated objections with prepared responses and concession boundaries
+- **Executive business review** -- narrative of where they started, what they achieved, and where they can go next
+- **Renewal outcome record** -- final result (renewed, expanded, downsized, churned) with lessons learned
+
+## Quality Signals
+
+- Value summary uses actual usage data and outcomes, not estimates
+- Negotiation brief covers likely objections with walk-away criteria defined
+- Executive review tells a compelling value story grounded in data
+- Outcome is documented with lessons learned regardless of result

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

@@ -0,0 +1,16 @@
+# Renewal Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Renewal strategy includes a value summary with quantified ROI achieved during the contract period, sourced from actual usage and outcome data"
+- "Negotiation brief anticipates at least 3 potential customer objections with prepared responses and concession boundaries"
+- "Executive business review deck tells a clear value story: where they started, what they achieved, and where they can go next"
+
+### Bad criteria — vague (no clear check)
+
+- "Renewal is prepared"
+- "Contract terms discussed"
+- "Customer will renew"
+

package/studios/customer-success/stages/renewal/review-agents/risk-assessment.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the renewal strategy accounts for all risk factors.
+
+**Check:**
+- The agent **MUST** verify that churn risk signals are identified and addressed in the renewal approach
+- The agent **MUST** verify that competitive threats are assessed with specific intelligence, not assumptions
+- The agent **MUST** verify that pricing strategy reflects the value delivered and market conditions
+- The agent **MUST** verify that executive sponsor engagement is confirmed, not assumed from past interactions

package/studios/customer-success/templates/new-customer-onboarding.md

@@ -0,0 +1,43 @@
+---
+name: new-customer-onboarding
+studio: customer-success
+description: Onboard a new customer from kickoff through initial value realization
+parameters:
+  - name: company
+    description: Customer company name
+    required: true
+  - name: deal_context
+    description: Link to deal context from sales handoff
+    required: false
+  - name: tier
+    description: "Customer tier: enterprise, growth, starter"
+    required: false
+    default: growth
+units:
+  - name: "technical-setup"
+    stage: onboarding
+    criteria:
+      - "{{ company }} environment provisioned and accessible"
+      - "SSO/auth configured and tested"
+      - "Data migration completed (if applicable)"
+  - name: "kickoff"
+    stage: onboarding
+    criteria:
+      - "Kickoff meeting completed with key stakeholders"
+      - "Success milestones agreed and documented"
+      - "Training schedule established"
+  - name: "feature-adoption"
+    stage: adoption
+    criteria:
+      - "Core features activated by at least 3 users"
+      - "Usage reaches baseline threshold for {{ tier }} tier"
+      - "First business outcome achieved"
+  - name: "health-baseline"
+    stage: health-check
+    criteria:
+      - "Health score established with baseline metrics"
+      - "Account risk factors assessed"
+      - "Quarterly review cadence confirmed"
+---
+
+Standard onboarding for new customers. Typically triggered by a sales deal close.