sinapse-ai 1.0.0

package/squad-product/tasks/synthesize-research-findings.md

@@ -0,0 +1,128 @@
+---
+task: synthesize-research-findings
+responsavel: "@ps-discovery-lead"
+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"
+---
+
+# Synthesize Research Findings
+
+## Metadata
+- **Agent:** ps-discovery-lead (Quorum)
+- **Complexity:** Medium-High
+- **Estimated Time:** 3-4 hours
+- **Produces:** Research synthesis, insight map, evidence-based recommendations
+
+## Purpose
+Sintetizar descobertas de multiplas fontes de pesquisa (entrevistas, analytics, surveys, testes) em insights acionaveis. Transformar dados brutos em decisoes de produto.
+
+## Steps
+
+### Step 1: Gather All Data Sources
+**Inventory Check:**
+| Source | Type | Sample Size | Confidence | Status |
+|--------|------|-------------|-----------|--------|
+| User interviews | Qualitative | N sessions | High/Med/Low | Collected/Pending |
+| Analytics data | Quantitative | N users/events | High/Med/Low | Collected/Pending |
+| Survey responses | Mixed | N responses | High/Med/Low | Collected/Pending |
+| Usability tests | Qualitative | N sessions | High/Med/Low | Collected/Pending |
+| Support tickets | Qualitative | N tickets | High/Med/Low | Collected/Pending |
+| Competitor analysis | Secondary | N competitors | Medium | Collected/Pending |
+
+**Minimum for Synthesis:** At least 2 different data sources to enable triangulation.
+
+### Step 2: Affinity Mapping (Qualitative Data)
+**Process:**
+1. Extract all observations, quotes, and data points onto individual cards
+2. Group related cards without pre-defined categories (bottom-up)
+3. Name each group with an insight statement (not a topic label)
+4. Arrange groups by relationship and hierarchy
+
+**Insight Statement Format:**
+- BAD: "Login issues" (topic, not insight)
+- GOOD: "Users abandon login when asked to create account before seeing value" (specific, actionable)
+
+**Hierarchy:**
+```
+Theme (broad pattern)
+  └── Insight (specific finding)
+       └── Evidence (quotes, data points, observations)
+            └── Source (interview #, analytics query, etc.)
+```
+
+### Step 3: Triangulation Matrix
+**Cross-reference findings across sources:**
+| Insight | Interviews | Analytics | Survey | Usability | Confidence |
+|---------|-----------|-----------|--------|-----------|-----------|
+| [insight 1] | Supported (3/5) | Confirmed (metric) | N/A | Confirmed | HIGH |
+| [insight 2] | Supported (4/5) | No data | Contradicted | N/A | MEDIUM |
+| [insight 3] | Mentioned (1/5) | Confirmed (metric) | Confirmed | N/A | HIGH |
+| [insight 4] | Supported (2/5) | No data | No data | N/A | LOW |
+
+**Confidence Rules:**
+- **HIGH:** Supported by 2+ independent sources
+- **MEDIUM:** Supported by 1 source, not contradicted by others
+- **LOW:** Single source only or contradicted by another source
+- **CONFLICT:** Sources disagree — requires additional research
+
+### Step 4: Prioritize Insights by Impact
+**Impact Assessment per Insight:**
+| Dimension | Score (1-5) | Notes |
+|-----------|------------|-------|
+| User impact (how many affected) | | |
+| Severity (how painful) | | |
+| Frequency (how often) | | |
+| Business value (revenue/retention) | | |
+| Feasibility (can we address this) | | |
+| **Total** | **/25** | |
+
+**Priority Bands:**
+- 20-25: Critical — address immediately
+- 15-19: High — plan for next quarter
+- 10-14: Medium — add to backlog
+- Below 10: Low — monitor, do not invest now
+
+### Step 5: Generate Recommendations
+**Per Priority Insight:**
+```
+INSIGHT: [specific finding with evidence]
+CONFIDENCE: HIGH | MEDIUM | LOW
+EVIDENCE: [summary of supporting data]
+RECOMMENDATION: [specific action to take]
+RISK IF IGNORED: [what happens if we do nothing]
+NEXT STEP: [immediate action item]
+OWNER: [agent/role responsible]
+```
+
+### Step 6: Create Research Synthesis Document
+**Structure:**
+1. Executive Summary (1 paragraph, key findings + top recommendation)
+2. Research Overview (methods used, sample sizes, timeline)
+3. Key Insights (prioritized, with evidence)
+4. Recommendations (actionable, with owners)
+5. Open Questions (what we still do not know)
+6. Appendix (raw data references, methodology notes)
+
+## Output Artifacts
+- `research-synthesis-[topic].md` | `insight-map.md` | `triangulation-matrix.md` | `recommendations.md`
+
+## Quality Criteria
+- All data sources inventoried | Triangulation attempted for key insights | Confidence levels assigned | Recommendations specific and actionable | Open questions documented | No insights without evidence

package/squad-product/tasks/triage-client-request.md

@@ -0,0 +1,82 @@
+---
+task: triage-client-request
+responsavel: "@ps-orchestrator"
+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"
+---
+
+# Triage Client Request
+
+## Metadata
+- **Agent:** ps-orchestrator (Vector)
+- **Complexity:** Low-Medium
+- **Estimated Time:** 30-60 minutes
+- **Depends On:** Client request received (via Proxy)
+- **Produces:** Triage decision, routing, initial sizing
+
+## Purpose
+Triagem rápida de requests de cliente para determinar rota correta: Discovery, Delivery ou Backlog. Evita que requests entrem direto em desenvolvimento sem validação adequada.
+
+## Steps
+
+### Step 1: Request Classification
+| Type | Signal | Route | SLA |
+|------|--------|-------|-----|
+| Bug/Issue | "Something is broken" | Delivery (hotfix) | 24-48h |
+| Enhancement | "Can you add/change X?" | Triage → Backlog | 5 days |
+| New Feature | "We need capability Y" | Discovery | 2 weeks |
+| Strategic | "We want to enter market Z" | Strategy → Discovery | 1 month |
+| Urgent | "We need this by Friday" | Assess urgency validity | 4 hours |
+
+### Step 2: Apply Reframe Test (Rich Mironov)
+1. What problem is the client trying to solve?
+2. Who specifically is affected?
+3. How are they working around it today?
+4. What happens if we don't do this?
+5. How will we know it's solved?
+
+**Output:** Original Request → Reframed Problem Statement → Affected Users → Current Workaround → Cost of Inaction → Success Metric
+
+### Step 3: Quick Sizing (T-shirt)
+| Size | Effort | Timeline | Team |
+|------|--------|----------|------|
+| XS | <1 day | This sprint | 1 person |
+| S | 1-3 days | This sprint | 1 person |
+| M | 1-2 weeks | Next sprint | 2 people |
+| L | 2-4 weeks | Needs planning | 3+ people |
+| XL | 1+ month | Needs discovery | Squad |
+
+### Step 4: Route Decision
+```
+IF bug AND severity ≥ High → Delivery (hotfix), notify Tempo
+IF enhancement AND size ≤ S → Delivery (add to sprint)
+IF new feature OR size ≥ M → Backlog; IF no evidence → Discovery first
+IF strategic → Charter assessment → Discovery sprint
+IF urgent claim → Validate urgency (real vs artificial deadline)
+```
+
+## Output Artifacts
+- `request-triage-[id].md` | Backlog item or Discovery brief created
+
+## Quality Criteria
+- Reframe applied (not just accepting request as-is)
+- Size estimate within 24 hours
+- Route decision documented with rationale

package/squad-product/tasks/triage-technical-debt-backlog.md

@@ -0,0 +1,160 @@
+---
+task: triage-technical-debt-backlog
+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"
+---
+
+# Triage Technical Debt Backlog
+
+## Metadata
+- **Agent:** ps-delivery-manager (Tempo)
+- **Complexity:** Medium
+- **Estimated Time:** 2-3 hours
+- **Produces:** Prioritized tech debt backlog, severity classification, sprint allocation plan
+
+## Purpose
+Classificar e priorizar divida tecnica para alocar budget de sprint de forma eficiente. Baseado em Martin Fowler Technical Debt Quadrant e framework de severidade pragmatico.
+
+## Steps
+
+### Step 1: Inventory Technical Debt
+**Debt Collection Sources:**
+| Source | Method | Frequency |
+|--------|--------|-----------|
+| Engineering team | Debt cards durante desenvolvimento | Continuous |
+| Code reviews | Flagged during PR reviews | Per PR |
+| Incidents | Post-mortem action items | Per incident |
+| Performance monitoring | Degradation alerts | Weekly |
+| Security scans | Vulnerability reports | Monthly |
+| Dependency audits | Outdated package checks | Monthly |
+
+**Debt Card Template:**
+```
+DEBT: [short title]
+Location: [file/module/system affected]
+Type: [code/architecture/infrastructure/testing/documentation]
+Description: [what the debt is]
+Impact: [what happens if not addressed]
+Origin: [how this debt was created]
+Reporter: [who identified it]
+Date Identified: [when]
+```
+
+### Step 2: Classify Using Fowler Quadrant
+**Martin Fowler Technical Debt Quadrant:**
+```
+              DELIBERATE                    INADVERTENT
+         ┌──────────────────────┬──────────────────────┐
+RECKLESS │ "We know this is     │ "What is layered     │
+         │  wrong but ship it"  │  architecture?"       │
+         │                      │                      │
+         │ Quick-fix shortcuts  │ Knowledge gaps        │
+         │ Known tech debt      │ Unknown tech debt     │
+         ├──────────────────────┼──────────────────────┤
+PRUDENT  │ "We must ship now    │ "Now we know how we  │
+         │  and deal with it"   │  should have done it"│
+         │                      │                      │
+         │ Strategic debt       │ Evolutionary debt    │
+         │ Conscious tradeoff   │ Natural learning     │
+         └──────────────────────┴──────────────────────┘
+```
+
+**Classification per Debt Item:**
+| Debt | Quadrant | Implication |
+|------|---------|-------------|
+| Deliberate-Reckless | Should not have been created, fix ASAP |
+| Deliberate-Prudent | Strategic, track and schedule payback |
+| Inadvertent-Reckless | Training issue, fix + prevent recurrence |
+| Inadvertent-Prudent | Natural evolution, address when relevant |
+
+### Step 3: Severity Assessment
+**Per Debt Item:**
+| Dimension | Score (1-5) | Criteria |
+|-----------|------------|---------|
+| User Impact | | 5=blocks users, 1=invisible to users |
+| Velocity Impact | | 5=slows every sprint, 1=no dev impact |
+| Risk Level | | 5=security/data loss risk, 1=cosmetic |
+| Spread | | 5=affects entire codebase, 1=isolated |
+| Growth Rate | | 5=getting worse rapidly, 1=stable |
+| **Total** | **/25** | |
+
+**Severity Bands:**
+| Score | Severity | Sprint Allocation |
+|-------|----------|------------------|
+| 20-25 | Critical | Immediate (this sprint) |
+| 15-19 | High | Next 1-2 sprints |
+| 10-14 | Medium | Scheduled within quarter |
+| 5-9 | Low | Opportunistic (when touching related code) |
+| Below 5 | Cosmetic | Document but do not allocate time |
+
+### Step 4: Calculate Debt Ratio
+**Tech Debt Ratio:**
+```
+Debt Ratio = Time to Fix All Debt / Time to Rebuild System
+
+Healthy: < 10%
+Manageable: 10-20%
+Concerning: 20-40%
+Critical: > 40%
+```
+
+**Debt Velocity:**
+```
+New Debt per Sprint: [items added]
+Debt Resolved per Sprint: [items fixed]
+Net Debt Change: New - Resolved
+Trend: Increasing / Stable / Decreasing
+```
+
+### Step 5: Prioritized Backlog
+**Priority Order:**
+| Priority | Debt Item | Severity | Effort | Sprint Target | Owner |
+|----------|----------|----------|--------|--------------|-------|
+| P1 | [item] | Critical | [pts] | Current sprint | [who] |
+| P2 | [item] | High | [pts] | Next sprint | [who] |
+| P3 | [item] | Medium | [pts] | This quarter | [who] |
+| ... | | | | | |
+
+**Sprint Allocation Rule:**
+```
+Minimum 15% of sprint capacity dedicated to tech debt
+Allocation increases if Debt Ratio > 20%:
+  - 20-30% ratio: allocate 20% of capacity
+  - 30-40% ratio: allocate 25% of capacity
+  - > 40% ratio: allocate 30%+ (or dedicated debt sprint)
+```
+
+### Step 6: Prevention Measures
+**Debt Prevention Practices:**
+| Practice | Description | Who |
+|----------|-----------|-----|
+| Definition of Done includes debt check | Every story reviewed for new debt | Dev team |
+| Debt card creation mandatory | When shortcuts taken, create card | Developer |
+| Quarterly debt review | Full backlog triage | Delivery manager |
+| Refactoring budget protected | 15% minimum enforced | Delivery manager |
+| Architecture decision records | Document trade-offs | Architect |
+
+## Output Artifacts
+- `tech-debt-backlog-[date].md` | `debt-severity-assessment.md` | `sprint-debt-allocation.md` | `debt-health-report.md`
+
+## Quality Criteria
+- All known debt inventoried | Fowler quadrant classified | Severity scored per item | Debt ratio calculated | Sprint allocation follows minimum 15% rule | Prevention measures documented | Trend tracked over time

package/squad-product/tasks/validate-problem-hypothesis.md

@@ -0,0 +1,150 @@
+---
+task: validate-problem-hypothesis
+responsavel: "@ps-discovery-lead"
+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"
+---
+
+# Validate Problem Hypothesis
+
+## Metadata
+- **Agent:** ps-discovery-lead (Quorum)
+- **Complexity:** Medium
+- **Estimated Time:** 1-2 weeks
+- **Produces:** Problem validation report, evidence log, go/no-go recommendation
+
+## Purpose
+Validar se o problema que acreditamos existir e real, frequente e doloroso o suficiente para justificar investimento. Foco em validar o PROBLEMA antes de pensar em solucao. Baseado em The Mom Test (Rob Fitzpatrick) e Continuous Discovery (Teresa Torres).
+
+## Steps
+
+### Step 1: Formulate Problem Hypothesis
+**Template:**
+```
+We believe that [target user segment]
+struggles with [specific problem]
+when trying to [goal/job-to-be-done]
+because [hypothesized root cause].
+
+This matters because [frequency] of [segment] experience this,
+and it costs them [time/money/frustration/risk].
+```
+
+**Quality Checks:**
+- [ ] Problem is specific (not "users are unhappy")
+- [ ] Segment is defined (not "everyone")
+- [ ] Root cause is hypothesized (can be tested)
+- [ ] Impact is estimable (frequency + severity)
+
+### Step 2: Identify What Would Prove/Disprove
+**Evidence That Validates:**
+- [ ] Users describe this problem unprompted in interviews
+- [ ] Problem frequency >= [threshold] per week/month
+- [ ] Users have active workarounds (behavioral evidence of pain)
+- [ ] Users willing to invest time/money to solve it
+- [ ] Problem appears in support data / reviews / NPS verbatims
+
+**Evidence That Invalidates:**
+- [ ] Users do not mention this problem even when prompted
+- [ ] Problem frequency too low to matter
+- [ ] Existing solutions are "good enough" (no switching motivation)
+- [ ] Only affects very small segment
+- [ ] Users rank other problems significantly higher
+
+### Step 3: Design Validation Approach
+**The Mom Test Rules (Rob Fitzpatrick):**
+1. Talk about their life, not your idea
+2. Ask about specifics in the past, not generics about the future
+3. Talk less, listen more
+4. Do not pitch — learn
+
+**Interview Questions (Problem-Focused):**
+- "Tell me about the last time you tried to [goal/JTBD]" (specific past)
+- "What was the hardest part?" (unprompted pain identification)
+- "How do you handle that today?" (workaround = evidence of pain)
+- "How often does this happen?" (frequency)
+- "What happens when you cannot solve it?" (severity/impact)
+- "Have you tried anything to fix this? What happened?" (motivation level)
+- "What do you spend the most time on?" (priority indicator)
+
+**DO NOT ASK:**
+- "Would you use a product that does X?" (hypothetical, meaningless)
+- "Do you think this is a problem?" (leading, gets polite yes)
+- "How much would you pay for..." (hypothetical before validation)
+
+### Step 4: Collect Evidence (Multi-Source)
+**Source 1: Problem Interviews (5-8)**
+| Question | P1 | P2 | P3 | P4 | P5 | Pattern |
+|----------|-----|-----|-----|-----|-----|---------|
+| Mentions problem? | Y/N | Y/N | Y/N | Y/N | Y/N | [N/5] |
+| Has workaround? | Y/N | Y/N | Y/N | Y/N | Y/N | [N/5] |
+| Frequency | [how often] | | | | | [median] |
+| Severity (1-5) | [score] | | | | | [avg] |
+
+**Source 2: Quantitative Signals**
+| Signal | Data Point | Supports? |
+|--------|-----------|-----------|
+| Support tickets about this | [count/period] | Y/N |
+| Feature requests related | [count] | Y/N |
+| Drop-off at relevant funnel step | [%] | Y/N |
+| NPS verbatims mentioning this | [count] | Y/N |
+| Competitor reviews mentioning this | [count] | Y/N |
+
+**Source 3: Behavioral Evidence**
+- Active workarounds observed: [list]
+- Time/money users spend on workarounds: [estimate]
+- Competitor solutions users adopt: [list]
+
+### Step 5: Analyze & Score
+**Problem Validation Scorecard:**
+| Dimension | Score (1-5) | Evidence |
+|-----------|------------|---------|
+| Problem exists (users confirm) | | [summary] |
+| Problem is frequent (happens often) | | [frequency data] |
+| Problem is severe (high impact) | | [severity evidence] |
+| Problem is widespread (large segment) | | [segment size] |
+| Users motivated to solve (active workarounds) | | [workaround evidence] |
+| **TOTAL** | **/25** | |
+
+**Decision Thresholds:**
+| Score | Verdict | Action |
+|-------|---------|--------|
+| 20-25 | STRONG VALIDATION | Proceed to solution exploration |
+| 15-19 | MODERATE VALIDATION | Validate further with more data |
+| 10-14 | WEAK VALIDATION | Pivot scope or segment |
+| Below 10 | NOT VALIDATED | Kill hypothesis, explore different problem |
+
+### Step 6: Document Decision
+**Problem Validation Report:**
+```
+HYPOTHESIS: [original problem hypothesis]
+VERDICT: VALIDATED / PARTIALLY VALIDATED / NOT VALIDATED
+CONFIDENCE: HIGH / MEDIUM / LOW
+EVIDENCE SUMMARY: [2-3 sentences]
+DECISION: [proceed / pivot / kill]
+NEXT STEPS: [specific actions]
+```
+
+## Output Artifacts
+- `problem-validation-[id].md` | `interview-evidence-log.md` | `validation-scorecard.md` | `problem-decision.md`
+
+## Quality Criteria
+- Problem hypothesis specific and falsifiable | The Mom Test rules followed (no pitching) | Min 5 interviews conducted | Quantitative data checked | Scorecard completed with evidence | Decision documented with rationale

package/squad-product/tasks/validate-product-hypothesis.md

@@ -0,0 +1,74 @@
+---
+task: validate-product-hypothesis
+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"
+---
+
+# Validate Product Hypothesis
+
+## Metadata
+- **Agent:** ps-product-strategist (Charter)
+- **Complexity:** Medium-High
+- **Estimated Time:** 1-2 weeks per hypothesis
+- **Produces:** Validation report, go/no-go decision, evidence log
+
+## Purpose
+Validar hipotese de produto com evidencia antes de investir em desenvolvimento. Framework de Assumption Testing (Teresa Torres).
+
+## Steps
+
+### Step 1: Hypothesis Formulation
+```
+We believe that [specific change/feature/action]
+will result in [measurable outcome]
+for [target user segment]
+because [rationale based on evidence].
+We will know this is true when [specific metric] reaches [threshold] within [timeframe].
+```
+
+### Step 2: Assumption Mapping
+Break hypothesis into testable assumptions across 4 dimensions:
+- **Desirability:** Do users want it? (problem frequency, willingness to switch, preference over alternatives)
+- **Viability:** Does business benefit? (willingness to pay, metric improvement, unit economics)
+- **Feasibility:** Can we build it? (technology, timeline, regulatory)
+- **Usability:** Can users use it? (comprehension, task completion)
+
+Priority: Test lowest confidence + highest risk first.
+
+### Step 3: Experiment Design (Strategyzer Test Card)
+Hypothesis > Test method > Metric > Success criteria > Duration > Cost
+
+### Step 4: Run Experiment (document all results)
+
+### Step 5: Analyze (Strategyzer Learning Card)
+Observation > Learning > Decision: VALIDATED / INVALIDATED / INCONCLUSIVE > Action
+
+### Step 6: Decision & Next Steps
+Validated > proceed to delivery planning
+Invalidated > pivot or explore alternatives
+Inconclusive > better experiment or more data
+
+## Output Artifacts
+- `hypothesis-validation-[id].md` | `experiment-results.md` | `evidence-log.md`
+
+## Quality Criteria
+- Hypothesis specific and falsifiable | Assumptions mapped across 4 dimensions | Threshold defined BEFORE running | Results documented regardless of outcome