@daniellins/power-claude 0.16.3

package/template/.claude/skills/pc-wave/SKILL.md

@@ -0,0 +1,133 @@
+---
+name: pc-wave
+description: "Executa um lote de stories de um epic em ondas: DAG de dependências, partição por File List (sem conflito de arquivos em paralelo), pc-full-cycle por story, fan-in com checagem real de conflito e merge só com aprovação. Use para: rodar uma wave de stories, executar epic em lote, stories em paralelo, wave."
+---
+
+# pc-wave — Execução de Lote de Stories (orquestrador de wave)
+
+Protocolo completo e autocontido. Nenhuma engine externa: o plano (DAG + batches) é construído lendo as stories com ferramentas nativas, e o estado vive em JSON.
+
+## Invocação
+
+```
+/pc-wave {epic-id} --stories docs/stories/a.md,docs/stories/b.md [yolo|interactive] [--dry-run]
+```
+
+Alternativa: `--epic-dir docs/stories/` + filtro por prefixo de id (ex.: `2.`) para resolver as stories do epic. Default: `interactive`.
+
+## Estado durável (retomável)
+
+Arquivo: `.power-claude/wave/{epic-id}/state.json`. Schema:
+
+```json
+{
+  "epic_id": "epic-2",
+  "mode": "interactive",
+  "batches": [["2.1", "2.3"], ["2.2"]],
+  "stories": {
+    "2.1": { "path": "docs/stories/2.1.story.md", "depends_on": [],
+             "files_predicted": ["src/a.ts"], "branch": "feat/2.1-slug",
+             "status": "pending" }
+  },
+  "merge_approved": false,
+  "updated_at": "ISO-8601"
+}
+```
+
+`status` por story: `pending | running | completed | failed | blocked`. **Retomada:** ao invocar, leia o state.json; se existe, continue do primeiro batch com stories não-`completed` (reavaliando bloqueios); se não, execute o Stage 1.
+
+## Stage 1 — Plano determinístico (DAG + partição)
+
+Construa o plano **lendo os arquivos das stories** — nunca por suposição:
+
+1. **Resolver paths:** toda story listada deve existir em disco. Faltou uma → HALT.
+2. **DAG:** extraia a seção de dependências de cada story (`Dependências`/`Depends on`/campo equivalente). Dependência fora da wave = considerada satisfeita **somente se** a story dependida está `Done` em disco; caso contrário → HALT com o gap. Ciclo no grafo → HALT (liste o ciclo).
+3. **Partição por File List prevista:** extraia a File List prevista (ou os arquivos citados nos ACs) de cada story. Regras:
+   - Ordenação topológica pelo DAG primeiro; dentro de cada conjunto "pronto", o subconjunto máximo com File Lists **disjuntas** roda no mesmo batch (paralelo).
+   - Stories com interseção de arquivos NUNCA no mesmo batch — vão para batches posteriores.
+   - File List vazia = tratada como não-conflitante (mas ainda sequenciada pelo DAG).
+4. **Sanidade de status:** stories `Draft` passarão por validate dentro do `pc-full-cycle` (ok); story já `Done` → marque `completed` e não redespache.
+5. Grave `batches` + `stories` no state.json. `--dry-run` → imprima o plano (batches, deps, arquivos) e **PARE**.
+
+## Stage 2 — Confirmação
+
+Mostre o plano ao humano: batches (o que roda em paralelo e por quê), dependências e arquivos previstos. Em `interactive`, prossiga só com OK explícito. Em `yolo`, prossiga direto — mas o plano impresso fica no relato.
+
+## Stage 3 — Dispatch (pc-full-cycle por story)
+
+Para cada batch, **em ordem**:
+
+1. Preflight do batch: para cada story, os gates de escopo do `pc-full-cycle` valem (story existe, status coerente, gates do projeto configurados). Working tree limpa antes de iniciar o batch.
+2. Despache **`pc-full-cycle`** para cada story do batch — em subagentes paralelos quando disponíveis (um por story, cada um em sua branch `feat/{id}-{slug}`); fallback: sequencial, uma story por vez. Prompt: `Execute a skill pc-full-cycle na story {path}; mode={mode}. Não faça git push.`
+3. **Fan-in do batch (verificação independente):** para cada story, confira EM DISCO antes de aceitar o resultado — nunca pelo relato do child:
+   - state.json do ciclo (`.power-claude/cycle/{id}/state.json`) com todas as fases `done`;
+   - story `Status: Done` + gate file com veredito não-FAIL em `docs/qa/gates/`;
+   - branch da story existe com commits (`git log main..feat/{id}-* --oneline`).
+   Evidência ausente = story **`failed`**, mesmo que o child tenha relatado sucesso ("do not fake green").
+4. **Cascata de bloqueio:** story A `failed`/HALT → todo dependente (direto ou transitivo) vira `blocked` no state e **não é despachado**. Batches posteriores continuam apenas para stories cujas dependências estão todas `completed`. Nunca marque verde para desbloquear.
+5. Atualize o state.json após cada story e cada batch.
+
+## Stage 4 — Fan-in final (checagem REAL de conflito)
+
+Antes de qualquer merge, com todas as branches da wave no repo local:
+
+1. **Interseção de arquivos entre branches:** para cada par de branches da wave,
+   ```bash
+   git diff --name-only main...feat/{a} | sort > /tmp/wave-a.txt
+   git diff --name-only main...feat/{b} | sort > /tmp/wave-b.txt
+   comm -12 /tmp/wave-a.txt /tmp/wave-b.txt
+   ```
+   Interseção não-vazia = conflito potencial que a partição prevista não capturou (File List prevista ≠ real). Liste arquivo a arquivo.
+2. **Working tree limpa** (`git status`) — alteração solta fora de branch de story é red flag; identifique a origem antes de seguir.
+3. Conflito detectado → **reporte ao humano + papel devops com a lista exata**; nunca resolva por sobrescrita silenciosa, nunca prossiga para merge.
+
+## Stage 5 — Merge-back (só com aprovação)
+
+Merge/push/PR **exclusivos do papel devops, com aprovação humana** (`merge_approved: true` no state só após OK explícito). Esta skill nunca faz push. Handoff:
+
+```yaml
+handoff:
+  from: pc-wave
+  to: devops
+  epic_id: "{epic-id}"
+  stories_completed: ["2.1", "2.3"]
+  stories_failed_or_blocked: ["2.2 (blocked: depende de 2.1 FAIL)"]
+  branches: ["feat/2.1-slug", "feat/2.3-slug"]
+  conflicts: []          # do Stage 4, se houver
+  next_action: "criar/mergear PRs conforme política do repo"
+```
+
+## Condições de bloqueio (HALT da wave)
+
+| Condição | Ação |
+|----------|------|
+| Ciclo no DAG ou path de story ausente | HALT no Stage 1 |
+| Dependência externa não-Done | HALT no Stage 1 com o gap |
+| Circuit breaker de QG numa story (3 iterações FAIL) | Story `failed`; dependentes `blocked`; wave segue nos ramos independentes |
+| Evidência em disco divergente do relato do child | Story `failed` (do not fake green) |
+| Conflito de fan-in não resolvido | Sem merge; escalar humano + devops |
+
+## Modos
+
+| Modo | Comportamento |
+|------|---------------|
+| `interactive` | Confirma o plano; pausa entre batches e em toda condição de bloqueio |
+| `yolo` | Auto-confirma o plano; children autônomos; para em HALT e sempre antes do merge |
+| `--dry-run` | Só o plano (Stage 1) |
+
+## Aprendizados (obrigatório ao fim da wave)
+
+Faça **append** — nunca sobrescreva — em `.power-claude/cycle/learnings.md`:
+
+```markdown
+## {data ISO} — Wave {epic-id} — {completed}/{total} stories
+- Partição prevista vs conflito real no fan-in: {bateu | divergiu: arquivos…}
+- Stories bloqueadas e causa-raiz: {…}
+- Padrão/armadilha para as próximas waves: {1-3 bullets}
+```
+
+## Fronteiras
+
+- Nunca `git push` / `gh pr create` / merge — papel devops + aprovação humana.
+- Nunca redefinir escopo de story para "caber" num batch — replaneje a partição.
+- Nunca editar state.json (da wave ou dos ciclos) para fabricar progresso.

package/template/.env.example

@@ -0,0 +1,10 @@
+# POWER CLAUDE — variáveis de ambiente (todas OPCIONAIS)
+# Copie para .env e preencha somente o que o seu uso exigir.
+# O .gitignore já impede o versionamento de .env*.
+
+# Opcional: necessária apenas para automações/scripts que chamam a API da Anthropic
+# diretamente (fora do Claude Code, que usa a própria autenticação).
+ANTHROPIC_API_KEY=
+
+# Opcional: necessária apenas para workflows (ex.: N8N) que integram modelos da OpenAI.
+OPENAI_API_KEY=

package/template/knowledge/analyst/brainstorming.md

@@ -0,0 +1,40 @@
+# Brainstorming — Facilitação (output: docs/brainstorming-session-results.md)
+
+**PRINCÍPIO INEGOCIÁVEL — VOCÊ É FACILITADOR:** guie o usuário a gerar as PRÓPRIAS ideias via perguntas, prompts e exemplos. Nunca gere por ele (salvo pedido explícito e insistente). Uma técnica por vez; pergunte antes de trocar; quantidade gera qualidade (meta: ~100 ideias em 60 min); julgamento adiado durante a geração.
+
+## Setup (4 perguntas, sem antecipar o que vem depois)
+
+1. Sobre o que vamos fazer brainstorming? 2. Restrições ou parâmetros? 3. Objetivo: exploração ampla ou ideação focada? 4. Quer documento estruturado ao final? (default: sim)
+
+Depois, ofereça 4 abordagens numeradas: (1) usuário escolhe técnicas; (2) analyst recomenda pelo contexto; (3) seleção aleatória; (4) fluxo progressivo (amplo → estreito).
+
+## 20 técnicas
+
+**Expansão criativa:** 1. What If Scenarios (uma pergunta provocativa por vez) · 2. Analogical Thinking (dê 1 analogia, peça 2-3) · 3. Reversal/Inversion (pergunta invertida) · 4. First Principles ("quais os fundamentos?").
+**Frameworks estruturados:** 5. SCAMPER (uma letra por vez) · 6. Six Thinking Hats (um chapéu por vez) · 7. Mind Mapping (conceito central, peça ramos).
+**Colaborativas:** 8. "Yes, And..." (alternando) · 9. Brainwriting/Round Robin (construção mútua) · 10. Random Stimulation (palavra aleatória → conexões).
+**Exploração profunda:** 11. Five Whys (um "porquê" por vez, aguarde resposta) · 12. Morphological Analysis (parâmetros primeiro, depois combinações) · 13. Provocation PO (afirmação provocativa → extrair ideias úteis).
+**Avançadas:** 14. Forced Relationships (conectar conceitos sem relação) · 15. Assumption Reversal (desafiar premissas centrais) · 16. Role Playing (perspectivas de stakeholders) · 17. Time Shifting ("como em 1995? em 2030?") · 18. Resource Constraints ("e com $10 e 1 hora?") · 19. Metaphor Mapping (metáforas estendidas) · 20. Question Storming (gerar perguntas antes de respostas).
+
+## Fluxo em 4 fases
+
+1. **Warm-up** (5-10 min) — construir confiança criativa.
+2. **Divergente** (20-30 min) — quantidade sobre qualidade.
+3. **Convergente** (15-20 min) — agrupar e categorizar.
+4. **Síntese** (10-15 min) — refinar e desenvolver conceitos.
+
+Fique numa técnica até o usuário querer: trocar de técnica, aplicar ideias a outra técnica, convergir, ou encerrar.
+
+## Documento de saída
+
+- **Executive Summary:** tópico e objetivos, técnicas usadas e duração, total de ideias, temas e padrões.
+- **Por técnica:** nome/descrição, ideias geradas (palavras do usuário), insights, conexões notáveis.
+- **Categorização:** **Immediate Opportunities** (implementável já) · **Future Innovations** (requer desenvolvimento/pesquisa) · **Moonshots** (ambiciosas, transformadoras) · **Insights & Learnings** (percepções da sessão).
+- **Action Planning:** top 3 prioridades com rationale, próximos passos, recursos/pesquisa necessários, timeline.
+- **Reflexão:** o que funcionou, áreas a explorar, técnicas de follow-up, perguntas emergentes.
+
+## Engajamento
+
+- Cheque energia ("como você está se sentindo com essa direção?"); ofereça pausa ou troca se cair.
+- Aprofunde: "conta mais...", "yes, and...", "como isso se conecta com sua ideia anterior sobre...?"
+- Capture as ideias no documento desde o início (se solicitado), em tempo real.

package/template/knowledge/analyst/brief-skeleton.md

@@ -0,0 +1,32 @@
+# Brief Skeleton — Project Brief (output: docs/brief.md)
+
+Documento fundacional que alimenta o planner. Título: `Project Brief: {projeto}`. Antes de começar, levante insumos disponíveis (brainstorming, market research, análise competitiva, ideias iniciais).
+
+## Seções (nesta ordem)
+
+1. **Executive Summary** — conceito em 1-2 frases, problema primário, mercado-alvo, proposta de valor. **Escreva por ÚLTIMO.**
+2. **Problem Statement** — estado atual e dores; impacto quantificado; por que soluções existentes falham; urgência de resolver agora.
+3. **Proposed Solution** — conceito central e abordagem; diferenciais-chave; por que esta solução vence onde outras falharam; visão de alto nível.
+4. **Target Users** — por segmento (primário obrigatório, secundário se houver): perfil demográfico/firmográfico, comportamentos e workflows atuais, necessidades e dores, objetivos.
+5. **Goals & Success Metrics** — objetivos SMART. Três listas: Business Objectives (cada um com métrica), User Success Metrics, KPIs (`{kpi}: {definição e alvo}`).
+6. **MVP Scope** — Core Features (must-have, cada uma com rationale), **Out of Scope** (explícito), MVP Success Criteria. Separe must-have de nice-to-have com o usuário.
+7. **Post-MVP Vision** — Phase 2 Features; visão de 1-2 anos; oportunidades de expansão. Sem overcommit.
+8. **Technical Considerations** — pensamentos iniciais, NÃO decisões finais: plataformas/browser/performance; preferências de frontend/backend/database/infra; repo structure, service architecture, integrações, security/compliance.
+9. **Constraints & Assumptions** — Constraints: budget, timeline, recursos, técnicas. Key Assumptions em bullets.
+10. **Risks & Open Questions** — Key Risks (descrição + impacto), Open Questions, áreas que precisam de mais pesquisa.
+11. **Appendices** — A. Research Summary (se houver), B. Stakeholder Input, C. References.
+12. **Next Steps** — Immediate Actions (lista numerada) + **Planner Handoff** (seção final obrigatória).
+
+## Planner Handoff (texto-base)
+
+> Este brief fornece o contexto completo de {projeto}. Planner: revise o brief por inteiro, trabalhe o PRD seção por seção com o usuário, peça esclarecimentos onde houver lacunas e sugira melhorias. Incertezas e riscos listados acima NÃO estão resolvidos — trate-os como entrada, não como decisão.
+
+## Refinamento por seção (ofereça após cada seção)
+
+- Expandir com detalhes específicos · Validar contra produtos similares de sucesso · Stress-testar premissas com edge cases · Explorar abordagens alternativas · Analisar trade-offs de recursos/constraints · Gerar estratégias de mitigação de risco · Desafiar escopo pela ótica MVP minimalista · Brainstorm de features criativas · "If only we had [recurso/tempo]..." · Prosseguir
+
+## Regras
+
+- Modo interativo (seção a seção) ou rascunho completo para revisão — pergunte antes.
+- Todo dado com fonte e data; premissas declaradas como premissas.
+- Rationale registrado por seção (por que este escopo, por que este segmento).

package/template/knowledge/analyst/competitor-skeleton.md

@@ -0,0 +1,39 @@
+# Competitor Analysis Skeleton (output: docs/competitor-analysis.md)
+
+Título: `Competitive Analysis Report: {produto}`. Antes de mergulhar em perfis, defina propósito e priorize competidores.
+
+## Seções
+
+1. **Executive Summary** — insights competitivos, principais ameaças e oportunidades, ações recomendadas. **Escreva por ÚLTIMO.**
+2. **Analysis Scope & Methodology**
+   - Propósito: entrada em mercado / posicionamento / gap de features / pricing / alvos de parceria-aquisição / avaliação de ameaça.
+   - **5 categorias de competidor**: Direct (mesmo produto, mesmo mercado) · Indirect (produto diferente, mesma necessidade) · Potential (poderia entrar fácil) · Substitute (solução alternativa) · Aspirational (best-in-class).
+   - Metodologia: fontes, janela temporal, níveis de confiança, limitações.
+3. **Competitive Landscape Overview**
+   - Market Structure: nº de players ativos, concentração, dinâmica, entradas/saídas recentes.
+   - **Matriz de priorização 2×2 (Market Share × Threat)**: P1 Core (share alto + ameaça alta) · P2 Emerging Threats (share baixo + ameaça alta) · P3 Established Players (share alto + ameaça baixa) · P4 Monitor Only (baixo + baixa).
+4. **Competitor Profiles** — completos para P1/P2, condensados para P3/P4. Por competidor:
+   - Company Overview: fundação, HQ, tamanho, funding, liderança.
+   - Business Model: modelo de receita, mercado-alvo, proposta de valor, GTM, foco estratégico.
+   - Product: ofertas core, features de destaque, UX, stack, pricing.
+   - Strengths / Weaknesses (bullets).
+   - Market Position: share estimado, base de clientes, trajetória, movimentos recentes.
+5. **Comparative Analysis**
+   - Feature Comparison Matrix (tabela: você × top 3): core functionality, UX (app, onboarding), integrações/API, pricing/free tier.
+   - **SWOT**: sua solução (S/W/O/T) e vs. competidor principal (vantagens, desvantagens, oportunidades de diferenciação).
+   - Positioning Map em 2 dimensões relevantes (ex.: Price×Features, Ease×Power, Especialização×Amplitude, Self-serve×High-touch).
+6. **Strategic Analysis**
+   - Sustainable Advantages (moats): network effects, switching costs, marca, barreiras tecnológicas, vantagens regulatórias.
+   - Vulnerable Points: segmentos mal atendidos, features ausentes, UX ruim, preço alto, presença geográfica limitada.
+   - Blue Ocean: segmentos/casos de uso não atendidos, novos modelos de negócio, expansão geográfica, propostas de valor distintas.
+7. **Strategic Recommendations** — Differentiation (propostas a enfatizar, features a priorizar, segmentos, messaging); Offensive (atacar fraquezas, ganhar deals, capturar clientes deles); Defensive (fortalecer vulnerabilidades, criar switching costs, aprofundar relações); Parcerias & ecossistema.
+8. **Monitoring & Intelligence Plan** — quem rastrear (com rationale); métricas (produto, pricing, wins/losses, funding/M&A, messaging); fontes (sites/blogs, reviews, relatórios, redes, patentes); cadência: Weekly / Monthly / Quarterly (revisão completa).
+
+## Refinamento por seção (ofereça após cada seção)
+
+- Deep dive na estratégia de um competidor · Dinâmica de um segmento · War-gaming de respostas competitivas · Cenários parceria vs. competição · Stress-testar claims de diferenciação · Potencial de disrupção (seu ou deles) · Comparar com mercados adjacentes · Insights win/loss · "If only we had known [plano do competidor X]..." · Prosseguir
+
+## Regras
+
+- Todo dado com fonte, data e confiança; estimativas de share sempre marcadas como estimativas.
+- Não inflar ameaças nem subestimar incumbentes: evidência antes de veredito.

package/template/knowledge/analyst/elicitation-menu.md

@@ -0,0 +1,49 @@
+# Elicitation Menu — Motor de Refinamento por Seção
+
+Após rascunhar cada seção de um documento, ofereça um menu numerado **0-9**: selecione 9 métodos relevantes ao contexto (0-8) + sempre **"9. Prosseguir / sem ações adicionais"**. Execute o método escolhido sobre a seção atual, mostre o resultado e reofereça o menu até o usuário prosseguir.
+
+**Seleção contextual:** inclua sempre 2-3 métodos core (reflexivos); complete com métodos que casem com o tipo de conteúdo (risco para arquitetura, persona para UX, game-based para decisões contestadas).
+
+## Métodos core (reflexivos)
+
+- **Expand or Contract for Audience** — expandir (detalhe) ou contrair (simplificar); calibrar para público-alvo específico.
+- **Explain Reasoning (CoT)** — expor passo a passo o raciocínio, premissas e pontos de decisão que levaram ao conteúdo.
+- **Critique and Refine** — revisar falhas e inconsistências pela expertise do papel; propor versão refinada.
+
+## Análise estrutural
+
+- **Analyze Logical Flow & Dependencies** — progressão lógica, consistência interna, dependências entre elementos, ordenação.
+- **Assess Alignment with Goals** — contribuição aos objetivos declarados; desalinhamentos e lacunas; ajustes sugeridos.
+
+## Risco e desafio
+
+- **Identify Risks & Unforeseen Issues** — riscos, edge cases negligenciados, consequências não intencionais, desafios de implementação.
+- **Challenge from Critical Perspective** — advogado do diabo; atacar fraquezas; aplicar YAGNI para cortar escopo.
+
+## Exploração criativa
+
+- **Tree of Thoughts** — decompor em "pensamentos" intermediários, explorar múltiplos caminhos, classificar (sure/likely/impossible), buscar o caminho ótimo.
+- **Hindsight "If Only..."** — retrospectiva imaginada; extrair o insight "se soubéssemos X"; converter em aprendizado acionável.
+
+## Multi-persona
+
+- **Agile Team Perspective Shift** — rotacionar: PO (valor), SM (processo), Dev (implementação), QA (testes/qualidade).
+- **Stakeholder Round Table** — mesa virtual de personas; conflitos e sinergias; síntese acionável.
+- **Meta-Prompting** — questionar a estrutura e a metodologia da própria abordagem; propor frameworks alternativos.
+
+## Avançados
+
+- **Self-Consistency Validation** — gerar múltiplos caminhos de raciocínio; comparar consistência; identificar onde divergem e por quê.
+- **ReWOO** — separar raciocínio puro de ações com ferramentas; resolver o resolvível por raciocínio; otimizar eficiência.
+- **Persona-Pattern Hybrid** — papel + padrão (ex.: Architect+Risk, UX+Journey, PM+Stakeholder).
+- **Emergent Collaboration Discovery** — deixar perspectivas emergirem; capturar descobertas serendípicas.
+
+## Game-based
+
+- **Red Team vs Blue Team** — Red ataca e acha vulnerabilidades; Blue defende e fortalece; revela pontos cegos.
+- **Innovation Tournament** — alternativas competem; pontuar por critérios; combinar vencedores.
+- **Escape Room Challenge** — tratar constraints como sala trancada; mínimo viável; workarounds criativos.
+
+## Controle
+
+- **Proceed / No Further Actions** — aceitar a seção como está e seguir para a próxima.

package/template/knowledge/analyst/market-research-skeleton.md

@@ -0,0 +1,36 @@
+# Market Research Skeleton (output: docs/market-research.md)
+
+Título: `Market Research Report: {produto}`. Comece entendendo QUE decisões a pesquisa vai informar.
+
+## Seções
+
+1. **Executive Summary** — achados-chave, avaliação da oportunidade, recomendações estratégicas. **Escreva por ÚLTIMO.**
+2. **Research Objectives & Methodology** — decisões a informar, perguntas a responder, critérios de sucesso; fontes (primárias/secundárias), frameworks aplicados, período de coleta, limitações e premissas.
+3. **Market Overview**
+   - Market Definition: categoria, escopo geográfico, segmentos incluídos, posição na cadeia de valor.
+   - **TAM / SAM / SOM** — calcule com premissas explícitas usando 1+ das 3 abordagens:
+     - *Top-down*: parte de dados de indústria e afunila.
+     - *Bottom-up*: constrói a partir de unit economics/clientes.
+     - *Value theory*: valor entregue vs. alternativas.
+   - Trends & Drivers: 3-5 tendências (descrição + impacto; PESTEL quando útil), growth drivers, inibidores.
+4. **Customer Analysis**
+   - Segment Profiles (por segmento): descrição, tamanho ($/clientes), características, dores, processo de compra, willingness to pay.
+   - **Jobs-to-be-Done**: Functional (tarefas práticas), Emotional (sentimentos buscados), Social (como quer ser percebido).
+   - Customer Journey (segmento primário): Awareness → Consideration → Purchase → Onboarding → Usage → Advocacy.
+5. **Competitive Landscape** — estrutura (nº de players, concentração, intensidade); top 3-5 players (share estimado, forças/fraquezas, foco, pricing); posicionamentos, gaps e oportunidades. (Análise profunda → *bench.)
+6. **Industry Analysis**
+   - **Porter's Five Forces** — cada força com nível + evidência + implicação: Supplier Power, Buyer Power, Competitive Rivalry, Threat of New Entry, Threat of Substitutes.
+   - Technology Adoption Lifecycle: estágio atual + evidência, implicações estratégicas, progressão esperada.
+7. **Opportunity Assessment**
+   - Oportunidades (cada uma **quantificada**): descrição, tamanho/potencial, requisitos para capturar, riscos.
+   - Recomendações: Go-to-Market (priorização de segmentos, posicionamento, canais, parcerias); Pricing (modelo, faixas, value metric); Risk Mitigation (mercado, competitivo, execução, regulatório).
+8. **Appendices** — A. Fontes de dados, B. Cálculos detalhados, C. Análises suplementares.
+
+## Refinamento por seção (ofereça após cada seção)
+
+- Expandir sizing com análise de sensibilidade · Deep dive em segmento · Analisar tendência emergente · Comparar com mercado análogo · Stress-testar premissas · Explorar mercados adjacentes · Desafiar definição/fronteiras do mercado · Cenários best/base/worst · "If only we had considered [fator X]..." · Prosseguir
+
+## Regras
+
+- Todo número com fonte, data e nível de confiança; cálculos com premissas visíveis no apêndice.
+- Distinguir fato (com fonte) de estimativa (com método) de opinião (declarada).

package/template/knowledge/analyst/research-prompt-structure.md

@@ -0,0 +1,48 @@
+# Research Prompt — Estrutura (output: prompt pronto para pesquisa profunda)
+
+Gera prompts de pesquisa bem estruturados a partir de brief, brainstorming, market research ou pergunta seca. A qualidade do prompt determina a qualidade dos insights.
+
+## Passo 1 — Tipo de pesquisa (apresente numerado)
+
+1. **Product Validation** — validar hipóteses e market fit; testar premissas; viabilidade técnica/negócio; riscos e mitigação.
+2. **Market Opportunity** — tamanho e crescimento; segmentos e dinâmica; estratégias de entrada; timing e prontidão.
+3. **User & Customer** — personas e comportamentos; jobs-to-be-done e dores; jornadas e touchpoints; willingness to pay.
+4. **Competitive Intelligence** — análise e posicionamento de competidores; comparação de capacidades; modelos de negócio; vantagens e gaps.
+5. **Technology & Innovation** — tendências; abordagens e arquiteturas; tecnologias emergentes; build vs. buy vs. partner.
+6. **Industry & Ecosystem** — cadeias de valor; players e relações; fatores regulatórios; parcerias.
+7. **Strategic Options** — direções estratégicas; modelos de negócio alternativos; GTM; caminhos de expansão.
+8. **Risk & Feasibility** — fatores de risco; desafios de implementação; recursos necessários; implicações legais.
+9. **Custom** — objetivos definidos pelo usuário.
+
+## Passo 2 — Processar insumos
+
+- **Brief:** extrair conceitos e objetivos, usuários-alvo, constraints, incertezas e premissas.
+- **Brainstorming:** sintetizar temas, áreas a validar, hipóteses a testar.
+- **Market research:** aprofundar oportunidades identificadas, validar achados, explorar adjacências.
+- **Do zero:** perguntas de contexto → espaço do problema → objetivos → critérios de sucesso.
+
+## Passo 3 — Estrutura do prompt (colabore com o usuário em cada bloco)
+
+```markdown
+## Research Objective       — objetivo, decisões que a pesquisa informará, critérios de sucesso, fronteiras
+## Background Context       — contexto relevante dos insumos
+## Research Questions
+### Primary (Must Answer)   — perguntas centrais, priorizadas, com dependências mapeadas
+### Secondary (Nice to Have)— contexto adicional, visão de futuro
+## Research Methodology
+### Information Sources     — tipos de fonte e prioridades; critérios de credibilidade
+### Analysis Frameworks     — frameworks específicos a aplicar
+### Data Requirements       — qualidade, recência, credibilidade
+## Expected Deliverables    — executive summary (achados, implicações, ações); análise detalhada por tipo; tabelas, matrizes, fontes
+## Success Criteria         — como avaliar se a pesquisa cumpriu os objetivos
+## Timeline and Priority    — restrições de tempo e faseamento, se houver
+```
+
+## Passo 4 — Revisar e encaminhar
+
+- Apresente o prompt completo, explique escolhas, destaque premissas; colha feedback (objetivos corretos? escopo adequado? entregáveis suficientes?) e refine.
+- Execução: assistente de IA com capacidade de pesquisa, pesquisa humana guiada, ou híbrido. Defina como os achados alimentam a próxima fase e como validá-los.
+
+## Regras
+
+- Perguntas específicas > genéricas; equilibre abrangência com foco; documente premissas e limitações; planeje refino iterativo.

package/template/knowledge/analyst/roi-skeleton.md

@@ -0,0 +1,51 @@
+# ROI Skeleton — Análise com Números Duros (output: docs/roi-analysis.md)
+
+Calcula economia real de uma iniciativa (consolidação, automação, migração, feature) com fórmulas visíveis. Serve para justificar investimento a stakeholders.
+
+## Inputs (elicite antes de calcular)
+
+- Tamanho do time e taxa horária média (default: $150/h — marque defaults como estimativa).
+- Horas/mês gastas hoje no problema (estime se desconhecido e sinalize a estimativa).
+- Custo de implementação (dev-weeks × taxa; incluir migração e treinamento? pergunte).
+- Estimativa conservadora ou agressiva; período de ROI (default: 1 ano).
+
+## Cálculo (mostre TODAS as fórmulas)
+
+1. **Custo ANTES** = unidades × horas/unidade/mês × taxa × 12 (inclua debugging, updates, fixes de consistência, reviews).
+2. **Custo DEPOIS** = mesma fórmula com o estado futuro + overhead da nova solução.
+3. **Economia** = mensal (antes − depois); anual (× 12).
+4. **Custo de implementação** = tempo de dev + migração + treinamento.
+5. **ROI ratio** = economia anual ÷ custo de implementação.
+6. **Breakeven (meses)** = custo de implementação ÷ economia mensal.
+7. **Projeção 3 anos** = (economia anual × 3) − custo de implementação.
+8. **Impacto em velocidade** = tempo poupado por entrega → multiplicador projetado → valor em $ e FTE-equivalente.
+
+## Entregáveis
+
+- **roi-analysis.md** — cálculos detalhados com fórmulas, análise de sensibilidade (best/worst case), comparação antes/depois.
+- **Executive summary (1 página)** — só números-chave:
+
+```markdown
+## Investment   — ${custo} ({dev-weeks})
+## Return       — ${economia}/ano
+## ROI          — {ratio}x
+## Breakeven    — {meses/dias}
+## Impact       — {redução %}, {multiplicador de velocidade}, {FTE-equivalente}
+**Recommendation:** {aprovação/condições, com payback}
+```
+
+## Critérios de sucesso
+
+- [ ] Custos antes E depois calculados com fórmulas exibidas.
+- [ ] Estimativas realistas ancoradas no contexto do time; defaults de indústria sinalizados como aproximação.
+- [ ] ROI positivo (>2x mínimo) — se negativo, explique por quê e sugira alternativa de maior impacto.
+- [ ] Breakeven calculado (tipicamente <1 ano).
+- [ ] Impacto em velocidade quantificado.
+- [ ] Sensibilidade best/worst incluída; resumo pronto para stakeholder.
+
+## Regras
+
+- Estimativas conservadoras por default (economia real costuma ser maior — deixe o número defender-se sozinho).
+- Dados salariais são sensíveis: use no cálculo, não logue nem exponha além do necessário.
+- ROI irrealista (breakeven de dias) merece dupla checagem de inputs antes de publicar.
+- Recalcule após a implementação para validar projeções.

package/template/knowledge/voice-dna/README.md

@@ -0,0 +1,99 @@
+# Voice DNA — a sua voz como dado, não como instrução solta
+
+Este diretório guarda **DNA de voz**: a descrição estruturada de como alguém escreve, extraída
+de material real que a pessoa já escreveu. Os pods de conteúdo leem daqui para produzir peças
+**na sua voz** em vez de uma voz genérica de assistente.
+
+**É opcional.** Nenhum gate do framework exige DNA. Sem ele, os pods rodam e produzem saída
+correta — só genérica. O que os pods que assinam peças **em seu nome** perguntam é outra coisa,
+bem mais barata: nome, handle e uma linha de autoridade (ver "A escada" abaixo).
+
+## Arquivos deste diretório
+
+| Arquivo | O que é |
+|---|---|
+| `voice-dna.example.yaml` | A **forma declarada** — placeholder com as 10 seções, comentado campo a campo. O template nunca distribui o DNA de uma pessoa real. |
+| `voice-dna.yaml` | **O seu DNA** (você cria; não vem no pacote). Nome reservado, sem nome de pessoa. |
+| `{slug}-dna.yaml` | DNA de **terceiro**, saída default do `mind-extractor` quando o corpus não é seu. |
+| `README.md` | Este arquivo. |
+
+Os arquivos de DNA (o seu e o de terceiros) são **dado pessoal**. Este diretório inteiro é
+declarado como **camada do dono**: no repositório do framework, um oráculo de máquina reprova o
+empacotamento se qualquer arquivo daqui sair sem ser um `.example.` com a sentinela
+(`pc:placeholder` / `meta.placeholder: true`). Se você distribuir este projeto, aplique a mesma
+regra: o que está aqui é seu, não do pacote.
+
+## A escada — três degraus, e o degrau 1 já funciona
+
+Voz não é tudo-ou-nada. Suba só até onde valer a pena para você:
+
+| Degrau | O que você fornece | Onde mora | Resultado |
+|---|---|---|---|
+| **1 — sem voz** | nada | — | Funciona. Saída correta, tom neutro. |
+| **2 — guia de estilo** | 3 campos: pessoa gramatical, léxico proibido, uma linha de tom | `pods/<pod>/knowledge/dono.yaml` | O texto para de soar como assistente. É o melhor custo-benefício. |
+| **3 — DNA completo** | um corpus do que você já escreveu | `knowledge/voice-dna/voice-dna.yaml` (aqui) | O texto passa a soar como você, com evidência por campo. |
+
+**Quando o degrau 3 existe, ele é o dono do assunto voz:** os campos `voz.*` do degrau 2 não são
+autorados em paralelo — ficam ausentes ou carregam `derived_from:` apontando para o DNA. Dois
+lugares autorando o mesmo fato é como uma configuração começa a mentir.
+
+## Como instanciar
+
+**Rota recomendada — extrair de material real:**
+
+```bash
+# no Claude Code, com o pod squad-forge instalado:
+/power:forge          # → agente mind-extractor → *extract {caminho-do-corpus}
+```
+
+O `mind-extractor` inventaria as fontes, classifica cada uma (SOURCE-AUDIT: `ouro` = material
+autoral seu; `bronze` = derivado/indireto), recusa a extração se **nenhuma** fonte for ouro, e
+preenche cada campo com `evidence:` — a citação que sustenta o campo — e `confidence:` conforme
+o número de ocorrências independentes. Saída: `knowledge/voice-dna/{slug}-dna.yaml`; renomeie
+para `voice-dna.yaml` quando o corpus for seu.
+
+**Rota manual — copiar e preencher:**
+
+```bash
+cp knowledge/voice-dna/voice-dna.example.yaml knowledge/voice-dna/voice-dna.yaml
+```
+
+Ao personalizar de verdade, **apague a linha `placeholder: true`** de `meta:` — é ela que diz aos
+agentes que o arquivo ainda não é seu.
+
+**Por que não existe um questionário que preencha isto:** um DNA de voz não é declarável por
+introspecção. Pedir a alguém que enumere os próprios tiques e antipadrões produz **autorretrato**,
+não DNA — campos sem evidência e `confidence` fabricado. Sem corpus, não há DNA real; fique no
+degrau 2, que é honesto e barato.
+
+## As 10 seções
+
+`meta` (procedência da extração + sentinela) · `identity` (temas, posicionamento, público) ·
+`tone` (registro, energia, relação com o leitor) · `structures` (a forma por canal) ·
+`hooks` (como você começa, com exemplos literais) · `vocabulary` (palavras, números, pontuação,
+formatação) · `argumentation` (como você convence e discorda) · `signatures` (o que só você faz) ·
+`anti_patterns` (o que nunca aparece) · `gaps_e_limitacoes` (o que o DNA não sabe).
+
+Duas seções carregam mais peso do que aparentam: **`hooks`**, porque a abertura é o que mais se
+copia errado; e **`anti_patterns`**, porque é o único bloco que consegue **reprovar** um rascunho
+antes de ele chegar a você.
+
+## Como o pod consome o DNA no pipeline
+
+- **Pesquisa / radar:** ao analisar referências e concorrentes, os padrões observados são
+  filtrados por `anti_patterns` — o que fere a sua voz é descartado antes de virar insight.
+- **Criação:** o argumento central é montado com `argumentation` + `hooks` + `signatures`;
+  toda afirmação factual precisa de fonte rastreável (No Invention vale mesmo na sua voz).
+- **Adaptação por canal:** `structures` decide a forma de cada canal; `vocabulary` decide o
+  léxico, a formatação e a pontuação.
+
+## Quality gate
+
+Um rascunho só passa quando satisfaz as duas condições, nesta ordem:
+
+1. **Não viola nenhum `anti_pattern`** — verificação de exclusão, feita primeiro porque é a barata.
+2. **Passa no blind test:** lido ao lado de duas peças do seu corpus real, não dá para dizer qual
+   é a gerada. Este é julgamento humano; nenhum script decide por você.
+
+Um DNA com `confidence: low` em muitos campos **não reprova nada** — significa que o corpus era
+estreito. Amplie o corpus e extraia de novo; `gaps_e_limitacoes` diz por onde começar.