sinapse-ai 1.0.0

package/squad-product/tasks/run-sprint-planning-session.md

@@ -0,0 +1,147 @@
+---
+task: run-sprint-planning-session
+responsavel: "@ps-delivery-manager"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: false
+
+Entrada:
+  - campo: context
+    tipo: object
+    origem: "workflow ou manual"
+    obrigatorio: true
+
+Saida:
+  - campo: resultado
+    tipo: document
+    destino: "stakeholders"
+
+Checklist:
+  - "[ ] Validar inputs e pre-condicoes"
+  - "[ ] Executar steps conforme documentado"
+  - "[ ] Verificar criterios de qualidade"
+  - "[ ] Gerar output no formato especificado"
+---
+
+# Run Sprint Planning Session
+
+## Metadata
+- **Agent:** ps-delivery-manager (Tempo)
+- **Complexity:** Medium
+- **Estimated Time:** 2-3 hours (session) + 1h prep
+- **Produces:** Sprint backlog, sprint goal, capacity plan, commitment confirmation
+
+## Purpose
+Facilitar sessao de sprint planning que resulte em compromisso claro da equipe com um sprint goal e backlog priorizado. Combina Scrum planning com agency-specific adaptacoes (multi-client, variabilidade de escopo).
+
+## Steps
+
+### Step 1: Pre-Planning Preparation
+**Capacity Calculation:**
+```
+Sprint Duration: [N days]
+Team Members: [list with availability %]
+
+Per Member:
+  Available Days = Sprint Days × Availability %
+  Productive Hours = Available Days × Focus Factor (typically 0.6-0.8)
+  Story Points Capacity = Productive Hours × Historical Points/Hour
+
+Team Capacity:
+  Total Available Days: [sum]
+  Total Story Points: [sum of individual capacities]
+  Buffer (10-15%): [points reserved for unknowns]
+  Committable Capacity: Total - Buffer = [points]
+```
+
+**Budget Allocation:**
+| Category | % of Capacity | Points | Rationale |
+|----------|--------------|--------|-----------|
+| Delivery (new features) | 60-70% | [pts] | Sprint goal progress |
+| Tech Debt | 15-20% | [pts] | Non-negotiable maintenance |
+| Discovery | 10-15% | [pts] | Research, validation |
+| Buffer | 5-10% | [pts] | Unplanned, meetings, support |
+
+**Pre-Planning Checklist:**
+- [ ] Backlog refined and prioritized (top items ready)
+- [ ] Acceptance criteria clear for top 10-15 items
+- [ ] Dependencies identified and resolved
+- [ ] Previous sprint velocity known
+- [ ] Team availability confirmed (vacations, holidays, other clients)
+
+### Step 2: Sprint Planning Session
+**Agenda (2-3 hours):**
+
+**Part 1: Context & Goal (30 min)**
+- Previous sprint review (velocity, completion rate, learnings)
+- Product priorities for this sprint (from ps-orchestrator)
+- Client expectations and deadlines
+- Draft sprint goal
+
+**Sprint Goal Template:**
+```
+This sprint, we will [primary deliverable]
+so that [user/business benefit]
+measured by [how we know we succeeded].
+
+Secondary objectives (if capacity allows):
+- [secondary goal 1]
+- [secondary goal 2]
+```
+
+**Part 2: Backlog Selection (60-90 min)**
+- Walk through prioritized backlog items
+- For each candidate item:
+  - Clarify: "Do we understand what this requires?"
+  - Estimate: Team estimation (Planning Poker or T-shirt)
+  - Dependencies: "What blocks this or what does this block?"
+  - Commit: "Can we complete this in this sprint?"
+
+**Estimation Reference:**
+| Size | Story Points | Typical Effort | Confidence |
+|------|-------------|---------------|-----------|
+| XS | 1 | < 0.5 day | Very High |
+| S | 2-3 | 0.5-1 day | High |
+| M | 5 | 2-3 days | Medium |
+| L | 8 | 3-5 days | Medium-Low |
+| XL | 13 | > 1 week | Low (should split) |
+
+**Part 3: Commitment & Plan (30 min)**
+- Review total committed vs capacity
+- Confidence vote (Fist of Five: 1-5)
+  - >= 3.5 average: Proceed with commitment
+  - < 3.5: Reduce scope until confidence rises
+- Identify risks and mitigation
+
+### Step 3: Sprint Backlog Compilation
+**Sprint Backlog Document:**
+| # | Item | Type | Points | Assignee | Dependencies | Status |
+|---|------|------|--------|----------|-------------|--------|
+| 1 | [story/task] | Feature/Debt/Discovery | [pts] | [name] | [blockers] | Ready |
+| 2 | [story/task] | | [pts] | [name] | | Ready |
+| ... | | | | | | |
+
+**Sprint Summary:**
+```
+Sprint: [sprint number / name]
+Duration: [start date] — [end date]
+Sprint Goal: [goal statement]
+Total Points Committed: [N] / [capacity] ([% of capacity])
+Team Confidence: [score /5]
+Key Risks: [list]
+```
+
+### Step 4: Post-Planning Actions
+- [ ] Sprint backlog visible to all (update tool)
+- [ ] Sprint goal posted in team channel
+- [ ] Daily standup scheduled
+- [ ] Mid-sprint check scheduled
+- [ ] Sprint review/demo scheduled
+- [ ] Dependencies communicated to dependent teams
+- [ ] Client-facing deadlines confirmed
+
+## Output Artifacts
+- `sprint-plan-[sprint-number].md` | `sprint-backlog.md` | `capacity-plan.md` | `sprint-risks.md`
+
+## Quality Criteria
+- Capacity calculated with actual availability | Budget allocation follows ratio | Sprint goal specific and measurable | All items estimated | Confidence vote >= 3.5 | Buffer included | Dependencies mapped

package/squad-product/tasks/scope-agency-mvp.md

@@ -0,0 +1,159 @@
+---
+task: scope-agency-mvp
+responsavel: "@ps-delivery-manager"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: false
+
+Entrada:
+  - campo: context
+    tipo: object
+    origem: "workflow ou manual"
+    obrigatorio: true
+
+Saida:
+  - campo: resultado
+    tipo: document
+    destino: "stakeholders"
+
+Checklist:
+  - "[ ] Validar inputs e pre-condicoes"
+  - "[ ] Executar steps conforme documentado"
+  - "[ ] Verificar criterios de qualidade"
+  - "[ ] Gerar output no formato especificado"
+---
+
+# Scope Agency MVP
+
+## Metadata
+- **Agent:** ps-delivery-manager (Tempo)
+- **Complexity:** Medium-High
+- **Estimated Time:** 3-4 hours
+- **Produces:** MVP scope document, feature matrix, timeline estimate, trade-off decisions
+
+## Purpose
+Definir escopo de MVP para contexto de agencia onde tempo e orcamento sao fixos (fixed-bid ou retainer). Aplicar Shape Up (Ryan Singer) para scoping baseado em appetite, nao em estimativa aberta.
+
+## Steps
+
+### Step 1: Define Appetite (Shape Up)
+**Appetite vs Estimate:**
+```
+ESTIMATE (traditional): "How long will this take?" → open-ended
+APPETITE (Shape Up): "How much time are we willing to spend?" → fixed constraint
+
+Appetite for this MVP: [N weeks]
+Team size: [N people]
+Total investment: [N person-weeks]
+```
+
+**Appetite Calibration:**
+| Appetite | Typical Scope | When to Use |
+|----------|-------------|-----------|
+| Small Batch (1-2 weeks) | Single feature, well-defined | Quick win, proof of concept |
+| Big Batch (4-6 weeks) | Multi-feature MVP | New product launch, major initiative |
+| Extended (6-8 weeks) | Complex MVP with integrations | Enterprise, multi-stakeholder |
+
+### Step 2: Identify Core Job-to-be-Done
+**The ONE job this MVP must complete:**
+```
+When [user type] is in [situation],
+they want to [motivation/action],
+so they can [desired outcome].
+
+This is the job. Everything in MVP serves THIS job.
+If a feature does not serve this job, it is out.
+```
+
+### Step 3: Feature Scoping (MoSCoW for MVP)
+**Must Have (MVP = only these):**
+| Feature | User Job | Complexity | Notes |
+|---------|---------|-----------|-------|
+| [feature 1] | [which job it serves] | S/M/L | [essential because...] |
+
+**Should Have (v1.1 — next iteration):**
+| Feature | User Job | Complexity | Notes |
+|---------|---------|-----------|-------|
+| [feature 1] | [job] | [size] | [deferred because...] |
+
+**Could Have (v2.0 — if validated):**
+| Feature | User Job | Complexity | Notes |
+|---------|---------|-----------|-------|
+| [feature 1] | [job] | [size] | [nice to have because...] |
+
+**Will Not Have (explicitly out of scope):**
+| Feature | Reason Out | When Revisit |
+|---------|-----------|-------------|
+| [feature 1] | [why excluded] | [condition for reconsideration] |
+
+### Step 4: Scope Hammering (Shape Up)
+**For each Must Have, ask:**
+1. "What is the simplest version that still works?" (reduce)
+2. "Can we use an existing solution instead of building?" (reuse)
+3. "Can this be manual first and automated later?" (defer automation)
+4. "What edge cases can we handle with a message instead of code?" (simplify)
+5. "Does this need to be perfect or just functional?" (lower fidelity)
+
+**Scope Decisions (document trade-offs):**
+| Feature | Full Version | MVP Version | What We Cut | Trade-off |
+|---------|-------------|-------------|-----------|-----------|
+| [feature] | [ideal scope] | [reduced scope] | [what was removed] | [impact of cut] |
+
+### Step 5: Technical Approach for Speed
+**Build vs Buy vs Borrow:**
+| Component | Build | Buy/Use Existing | Decision | Rationale |
+|-----------|-------|-----------------|----------|-----------|
+| Auth | Custom auth | Auth0/Supabase Auth | [choice] | [why] |
+| Payments | Custom | Stripe | [choice] | [why] |
+| Email | Custom | SendGrid/Resend | [choice] | [why] |
+| Analytics | Custom | Mixpanel/Amplitude | [choice] | [why] |
+| CMS | Custom | Contentful/Sanity | [choice] | [why] |
+
+**Technical Shortcuts (acceptable for MVP):**
+| Shortcut | Risk | Mitigation | Technical Debt Created |
+|---------|------|-----------|----------------------|
+| [shortcut 1] | [risk level] | [how we manage] | [debt to repay later] |
+
+### Step 6: Timeline & Milestones
+**MVP Timeline (within appetite):**
+| Week | Focus | Deliverable | Demo |
+|------|-------|------------|------|
+| Week 1 | Foundation + core flow | [deliverable] | Internal demo |
+| Week 2 | Core features complete | [deliverable] | Client check-in |
+| Week 3 | Polish + edge cases | [deliverable] | Stakeholder demo |
+| Week 4 | Testing + launch prep | [deliverable] | Go-live |
+
+**Hill Chart (Shape Up):**
+```
+Each feature plotted on:
+  Left side (uphill) = Figuring out → uncertainty, exploration
+  Right side (downhill) = Making it happen → execution, known work
+  Top of hill = Approach figured out, execution clear
+
+Feature A: [position on hill]
+Feature B: [position on hill]
+Feature C: [position on hill]
+```
+
+### Step 7: MVP Success Criteria
+**How do we know the MVP succeeded?**
+| Metric | Target | Measurement Method | Timeline |
+|--------|--------|-------------------|----------|
+| [primary metric] | [threshold] | [how measured] | [when measured] |
+| [secondary metric] | [threshold] | [how measured] | [when measured] |
+| [qualitative signal] | [what to observe] | [how observed] | [when checked] |
+
+**Go/No-Go for v1.1:**
+```
+If [metric] >= [threshold] within [timeframe]:
+  → Proceed to v1.1 (add Should Have features)
+If [metric] < [threshold]:
+  → Diagnose: Is it a product problem or a market problem?
+  → Decide: Iterate / Pivot / Kill
+```
+
+## Output Artifacts
+- `mvp-scope-[project].md` | `feature-matrix.md` | `scope-trade-offs.md` | `mvp-timeline.md` | `mvp-success-criteria.md`
+
+## Quality Criteria
+- Appetite defined (not open-ended estimate) | Core JTBD identified | MoSCoW applied rigorously | Scope hammered (simplest version) | Build vs buy decided | Timeline within appetite | Success criteria defined before building | Explicit out-of-scope list

package/squad-product/tasks/score-okrs-retrospective.md

@@ -0,0 +1,65 @@
+---
+task: score-okrs-retrospective
+responsavel: "@ps-product-strategist"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: false
+
+Entrada:
+  - campo: context
+    tipo: object
+    origem: "workflow ou manual"
+    obrigatorio: true
+
+Saida:
+  - campo: resultado
+    tipo: document
+    destino: "stakeholders"
+
+Checklist:
+  - "[ ] Validar inputs e pre-condicoes"
+  - "[ ] Executar steps conforme documentado"
+  - "[ ] Verificar criterios de qualidade"
+  - "[ ] Gerar output no formato especificado"
+---
+
+# Score OKRs Retrospective
+
+## Metadata
+- **Agent:** ps-product-strategist (Charter)
+- **Complexity:** Medium
+- **Estimated Time:** 2-3 hours
+- **Produces:** OKR scores, retrospective analysis, learnings for next quarter
+
+## Purpose
+Scoring formal dos OKRs do quarter e retrospectiva dos resultados para entender por que atingimos ou nao, e o que aprender.
+
+## Steps
+
+### Step 1: Data Collection (per KR)
+Baseline (quarter start) > Target > Actual (quarter end) > Score (0.0-1.0)
+
+**Scoring:** 1.0=Exceeded (rare, may indicate sandbagging) | 0.7=Target hit (ideal for aspirational) | 0.5=Significant progress but short | 0.3=Some progress | 0.0=No progress
+
+### Step 2: Score Each Objective
+Objective Score = Average of KR Scores. Overall = average of all objectives.
+**Health Check:** 0.6-0.7 healthy | >0.8 not ambitious enough | <0.4 execution or target issues
+
+### Step 3: Root Cause Analysis (for KRs scoring <0.5)
+Target unrealistic | External factor changed | Execution issue | Wrong metric | Dependency failed | Strategy wrong
+For KRs >0.9: Sandbagged | External tailwind | Exceptional execution | Market favor
+
+### Step 4: Pattern Analysis
+Themes across strongest/weakest KRs | Were objectives aligned with what mattered? | Did we measure right things? | Important outcomes NOT tracked?
+
+### Step 5: Learnings for Next Quarter
+**Continue:** Practices that worked
+**Stop:** Practices that did not contribute
+**Start:** New practices based on learnings
+**Unfinished Business:** KRs that carry forward (adjusted)
+
+## Output Artifacts
+- `okr-scores-Q[N].md` | `okr-retrospective-Q[N].md` | `okr-learnings-for-Q[N+1].md`
+
+## Quality Criteria
+- Every KR scored with actual data | Root cause for every KR below 0.5 | Pattern analysis identifies systemic issues | Learnings feed into next quarter planning

package/squad-product/tasks/setup-new-client-product-operations.md

@@ -0,0 +1,156 @@
+---
+task: setup-new-client-product-operations
+responsavel: "@ps-product-ops-specialist"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: false
+
+Entrada:
+  - campo: context
+    tipo: object
+    origem: "workflow ou manual"
+    obrigatorio: true
+
+Saida:
+  - campo: resultado
+    tipo: document
+    destino: "stakeholders"
+
+Checklist:
+  - "[ ] Validar inputs e pre-condicoes"
+  - "[ ] Executar steps conforme documentado"
+  - "[ ] Verificar criterios de qualidade"
+  - "[ ] Gerar output no formato especificado"
+---
+
+# Setup New Client Product Operations
+
+## Metadata
+- **Agent:** ps-product-ops-specialist (Mosaic)
+- **Complexity:** Medium-High
+- **Estimated Time:** 4-6 hours
+- **Produces:** Client operations setup, tool configuration, process onboarding, baseline metrics
+
+## Purpose
+Configurar operacoes de produto para novo cliente de forma padronizada. O setup correto nos primeiros dias determina a eficiencia do engajamento inteiro.
+
+## Steps
+
+### Step 1: Client Ops Kickoff Checklist
+**Day 1-2: Access & Tools**
+- [ ] Client provides access to existing analytics (GA, Amplitude, etc.)
+- [ ] Client provides access to existing project management tool
+- [ ] Client provides access to design files (Figma, etc.)
+- [ ] Client provides access to codebase (if applicable)
+- [ ] Client provides access to support/feedback channels
+- [ ] Client provides access to documentation (existing)
+- [ ] Communication channels established (Slack channel, email list)
+- [ ] Meeting cadence agreed (daily standup, weekly sync, etc.)
+
+**Day 2-3: Tool Setup**
+- [ ] Project board created (with standard columns/workflow)
+- [ ] Sprint/cycle structure configured
+- [ ] Labels/tags standardized (bug, feature, tech-debt, discovery)
+- [ ] Notification rules configured
+- [ ] Analytics dashboard created with baseline metrics
+- [ ] Shared document space created (knowledge base structure)
+- [ ] Time tracking configured (if retainer)
+
+**Day 3-5: Process Onboarding**
+- [ ] Sprint cadence confirmed
+- [ ] Meeting schedule set (all recurring meetings created)
+- [ ] Communication protocols shared with client
+- [ ] Escalation path documented and shared
+- [ ] RACI matrix created for key activities
+- [ ] Reporting cadence agreed (weekly status, monthly metrics)
+
+### Step 2: Baseline Metrics Capture
+**Capture Current State (before we start):**
+| Metric | Current Value | Date Captured | Source | Notes |
+|--------|-------------|--------------|--------|-------|
+| Active Users (MAU) | [N] | [date] | [tool] | |
+| Activation Rate | [%] | [date] | [tool] | |
+| D30 Retention | [%] | [date] | [tool] | |
+| NPS | [score] | [date] | [tool] | |
+| Page Load Time | [ms] | [date] | [tool] | |
+| Error Rate | [%] | [date] | [tool] | |
+| Feature Adoption (core) | [%] | [date] | [tool] | |
+
+**Why Baseline Matters:** Without baseline, we cannot demonstrate improvement. Capture BEFORE making any changes.
+
+### Step 3: Standard Project Board Setup
+**Board Columns (standard):**
+```
+Backlog → Refined → Sprint Ready → In Progress → In Review → QA → Done
+```
+
+**Standard Labels:**
+| Label | Color | Description |
+|-------|-------|-------------|
+| feature | Blue | New functionality |
+| bug | Red | Defect/fix |
+| tech-debt | Orange | Technical maintenance |
+| discovery | Purple | Research/validation |
+| spike | Yellow | Investigation/learning |
+| client-request | Green | Client-initiated |
+| blocked | Red border | Cannot proceed |
+
+**Standard Fields:**
+| Field | Type | Required? |
+|-------|------|----------|
+| Priority | P1-P4 | Yes |
+| Estimate | Story points | Yes (for sprint items) |
+| Sprint | Sprint selector | Yes (for sprint items) |
+| Client | Client tag | Yes (if multi-client) |
+| Type | feature/bug/debt/discovery | Yes |
+
+### Step 4: Communication Setup
+**Recurring Meetings:**
+| Meeting | Frequency | Duration | Participants | Purpose |
+|---------|-----------|----------|-------------|---------|
+| Daily standup | Daily | 15 min | Dev team | Progress + blockers |
+| Client sync | Weekly | 30 min | PM + client PO | Priorities + decisions |
+| Sprint planning | Bi-weekly | 2h | Full team | Sprint commitment |
+| Sprint demo | Bi-weekly | 1h | Team + client | Showcase deliveries |
+| Sprint retro | Bi-weekly | 1h | Dev team | Process improvement |
+| Monthly metrics | Monthly | 30 min | PM + stakeholders | Performance review |
+
+**Async Communication Rules:**
+| Type | Channel | Response SLA |
+|------|---------|-------------|
+| Urgent (production down) | Phone/direct message | 1 hour |
+| Important (blocker) | Slack DM | 4 hours |
+| Normal (question) | Slack channel | 24 hours |
+| FYI (status update) | Email | 48 hours |
+| Documentation | Shared docs | No SLA |
+
+### Step 5: Documentation Bootstrap
+**Initial Documents to Create:**
+| Document | Owner | Timeline | Template |
+|----------|-------|----------|---------|
+| Stakeholder Map | Client PM | Day 1 | stakeholder-map-template |
+| Product Health Baseline | Analyst | Day 3 | health-scorecard-template |
+| Decision Log (start) | Client PM | Day 1 | decision-log-template |
+| Sprint Cadence Doc | Delivery Mgr | Day 2 | sprint-template |
+| Communication Plan | Client PM | Day 2 | comms-plan-template |
+
+### Step 6: Operations Readiness Assessment
+**Readiness Scorecard (end of Week 1):**
+| Dimension | Score (1-5) | Status | Blocker if Not Ready |
+|-----------|------------|--------|---------------------|
+| Access & permissions | | Ready/Not | Cannot work without access |
+| Tools configured | | Ready/Not | Inefficient without tools |
+| Communication established | | Ready/Not | Misalignment risk |
+| Baseline captured | | Ready/Not | Cannot measure improvement |
+| Processes agreed | | Ready/Not | Unclear expectations |
+| Team onboarded | | Ready/Not | Productivity delay |
+| **Average** | **/5** | | |
+
+**Readiness Threshold:** Average >= 4.0 to begin sprint work.
+**Below 4.0:** Create action plan for remaining setup items.
+
+## Output Artifacts
+- `client-ops-setup-[client].md` | `baseline-metrics.md` | `communication-plan.md` | `ops-readiness-assessment.md`
+
+## Quality Criteria
+- All access obtained before sprint 1 | Tools configured with standard setup | Baseline metrics captured | Communication cadence agreed | Standard processes introduced | Readiness score >= 4.0 | All setup documented

package/squad-product/tasks/standardize-cross-client-metrics.md

@@ -0,0 +1,136 @@
+---
+task: standardize-cross-client-metrics
+responsavel: "@ps-product-ops-specialist"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: false
+
+Entrada:
+  - campo: context
+    tipo: object
+    origem: "workflow ou manual"
+    obrigatorio: true
+
+Saida:
+  - campo: resultado
+    tipo: document
+    destino: "stakeholders"
+
+Checklist:
+  - "[ ] Validar inputs e pre-condicoes"
+  - "[ ] Executar steps conforme documentado"
+  - "[ ] Verificar criterios de qualidade"
+  - "[ ] Gerar output no formato especificado"
+---
+
+# Standardize Cross-Client Metrics
+
+## Metadata
+- **Agent:** ps-product-ops-specialist (Mosaic)
+- **Complexity:** Medium-High
+- **Estimated Time:** 4-6 hours
+- **Produces:** Standard metric definitions, cross-client dashboard, benchmarking framework
+
+## Purpose
+Padronizar definicoes de metricas entre clientes para permitir benchmarking, comparacao e aprendizado cruzado. Quando cada cliente mede "retention" de forma diferente, nao ha como comparar ou aprender.
+
+## Steps
+
+### Step 1: Metric Audit Across Clients
+**Current State:**
+| Metric Name | Client A Definition | Client B Definition | Client C Definition | Consistent? |
+|-------------|--------------------|--------------------|--------------------|-----------|
+| Active User | [their definition] | [their definition] | [their definition] | [Y/N] |
+| Retention | [their definition] | [their definition] | [their definition] | [Y/N] |
+| Activation | [their definition] | [their definition] | [their definition] | [Y/N] |
+| Churn | [their definition] | [their definition] | [their definition] | [Y/N] |
+| NPS | [their definition] | [their definition] | [their definition] | [Y/N] |
+
+### Step 2: Define Standard Definitions
+**Universal Metric Standards:**
+```
+STANDARD METRIC: Active User
+Definition: A user who performed [core action] at least once in [time period]
+Variants:
+  - DAU: Core action in last 24 hours
+  - WAU: Core action in last 7 days
+  - MAU: Core action in last 30 days
+Note: "Core action" is product-specific, defined per client at onboarding
+
+STANDARD METRIC: Retention (D-N)
+Definition: % of users from cohort who perform core action on day N
+Formula: Users active on Day N / Users in cohort × 100
+Standard periods: D1, D7, D14, D30, D60, D90
+Cohort definition: Signup date (or activation date — specify)
+
+STANDARD METRIC: Activation Rate
+Definition: % of signups who complete the product-specific aha moment
+Formula: Users who reached aha / Total signups × 100
+Timeframe: Within [N days] of signup (product-specific)
+Note: "Aha moment" defined per product at onboarding
+
+STANDARD METRIC: Churn Rate (Monthly)
+Definition: % of customers lost in a calendar month
+Formula: Customers who churned / Customers at start of month × 100
+"Churned" = [no core action for N days] OR [subscription cancelled]
+
+STANDARD METRIC: NPS
+Definition: Net Promoter Score per standard methodology
+Formula: % Promoters (9-10) - % Detractors (0-6)
+Survey frequency: Quarterly (standard) or after key interactions
+Sample: All active users, minimum 40 responses for statistical validity
+```
+
+### Step 3: Client-Specific Customization Layer
+**Per Client, Map Standard to Specific:**
+| Standard Metric | Client-Specific Definition | Core Action | Threshold |
+|----------------|--------------------------|-------------|-----------|
+| Active User | [what counts as active for this product] | [specific event] | [frequency] |
+| Activation | [what is the aha moment] | [specific milestone] | [within N days] |
+| Retention | [same formula, specific core action] | [event] | [D30] |
+| Churn | [behavioral or subscription-based] | [trigger event] | [N days inactive] |
+
+### Step 4: Cross-Client Benchmarking
+**Benchmark Dashboard:**
+| Metric | Client A | Client B | Client C | Agency Avg | Industry Avg |
+|--------|---------|---------|---------|-----------|-------------|
+| Activation Rate | [%] | [%] | [%] | [%] | [%] |
+| D30 Retention | [%] | [%] | [%] | [%] | [%] |
+| NPS | [score] | [score] | [score] | [avg] | [avg] |
+| DAU/MAU | [ratio] | [ratio] | [ratio] | [avg] | [avg] |
+| Health Score | [N/100] | [N/100] | [N/100] | [avg] | — |
+
+**Benchmarking Rules:**
+- Compare apples to apples (same product type, similar stage)
+- Never share client data with other clients (anonymize)
+- Use benchmarks for learning, not competition
+- Industry benchmarks sourced from published data (Lenny Rachitsky, First Round, OpenView)
+
+### Step 5: Cross-Client Learnings
+**Pattern Detection:**
+| Pattern | Observed In | Potential Universal Learning |
+|---------|-----------|------------------------------|
+| [pattern] | Client A, C | [what we can apply elsewhere] |
+| [pattern] | Client B | [unique to this context?] |
+
+**Knowledge Transfer Rules:**
+- Anonymize all client-specific data
+- Share patterns and approaches, not specific metrics
+- Document what worked and what did not
+- Create playbooks from repeated successes
+
+### Step 6: Governance
+**Metric Standards Governance:**
+| Rule | Details |
+|------|---------|
+| New client onboarding | Map standard metrics during kickoff |
+| Metric definition changes | Require ops approval + 30-day transition |
+| Benchmark updates | Quarterly with latest industry data |
+| Cross-client report | Monthly internal (never shared with clients) |
+| Standard review | Semi-annual review of all definitions |
+
+## Output Artifacts
+- `standard-metric-definitions.md` | `client-metric-mapping/[client].md` | `cross-client-benchmarks.md` | `metric-governance-policy.md`
+
+## Quality Criteria
+- All core metrics have universal definitions | Client-specific mappings documented | Benchmarks include industry comparisons | Client data never shared across clients | Governance process defined | Quarterly benchmark updates scheduled