菜单
Use quando for atualizar documentação após concluir uma user story ou feature. Ativado por "documentar", "README", "doc da API", "atualizar catalog", "atualizar AGENTS.md". Sempre executar após harness-testing para fechar o loop de entrega.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use quando for projetar arquitetura técnica de uma feature ou projeto. Ativado por "arquitetura", "stack", "design técnico", "padrão de camadas". Requer PRD como entrada. Auto-skip para features pequenas — ir direto para harness-tasks.
Use quando for revisar código antes de abrir um PR, ou ao processar feedback de review. Ativado por "revisar", "code review", "review do PR", "blockers do review". É um sensor inferencial — executar após todos os sensores computacionais (lint, type check, testes) passarem.
Pipeline completo de desenvolvimento de software com IA — PRD → Arquitetura → Tasks → Código → Review → Testes → Docs → CI/CD → Iteração. Baseado nas práticas de Harness Engineering da Anthropic, OpenAI e Thoughtworks/Martin Fowler: guias (feedforward) + sensores (feedback) que se auto-corrigem antes de chegar ao humano. Ative quando o usuário mencionar "criar PRD", "planejar feature", "iniciar projeto", "especificar", "arquitetura", "quebrar em tasks", "implementar", "code review", "gerar testes", "documentar", "CI/CD", "analisar feedback", "por onde começo", "como organizo o projeto com IA", "quero construir um app", "vamos iniciar", "quero desenvolver", ou qualquer combinação dessas ações. Combine com skills disponíveis (tlc-spec-driven, superpowers, context7) para máxima efetividade — verificar disponibilidade via `harness.config.yaml`.
Use quando for implementar uma task técnica do breakdown. Ativado por "implementar", "código", "implement T-XX", "executar task". Uma task por invocação. Requer PRD (seções relevantes) + arquitetura + AGENTS.md como contexto.
Use quando for analisar feedback de produção para planejar o próximo ciclo de desenvolvimento. Ativado por "analisar feedback", "próximo ciclo", "o que melhorar", "retrospectiva", "dados de uso". Esta etapa fecha o steering loop e reinicia o pipeline.
Use quando for criar um PRD, especificar uma feature ou iniciar um novo projeto. Ativado por "criar PRD", "especificar", "iniciar projeto", "o que definir antes de codar", "por onde começo", "quero construir um app". Invocar antes de qualquer arquitetura ou breakdown de tasks.
| name | harness-documentation |
| description | Use quando for atualizar documentação após concluir uma user story ou feature. Ativado por "documentar", "README", "doc da API", "atualizar catalog", "atualizar AGENTS.md". Sempre executar após harness-testing para fechar o loop de entrega. |
Persona: Technical writer.
.catalog/ ← fonte de verdade técnica (versionada no repositório)
architecture.md, conventions.md, concerns.md, features.md, stack.md...
[delivery_docs.path]/ ← docs de entrega quando `project_tracking.tool: local` ou fallback (padrão: .milestones/)
Ferramenta de rastreamento ← issues/cards/epics/stories conforme project_tracking.tool
Regra: AGENTS.md é a tabela de roteamento (≤100 linhas) — aponta para .catalog/ e para os itens de rastreamento.
Após cada [level2] concluída, atualizar estes arquivos quando project_tracking.tool: local ou quando uma ferramenta externa caiu para fallback markdown:
[delivery_docs.path]/[level1-nome]/[level2-XX]/changelog.md — o que mudou, por quê, impacto[delivery_docs.path]/[level1-nome]/[level2-XX]/tech-spec.md — marcar tasks completas, atualizar status para ✅[delivery_docs.path]/[level1-nome]/[level1].md — marcar [level2] completaFechar entrega conforme project_tracking.tool — ver references/11-project-tracking.md. Não duplique docs locais se GitHub/Jira/Linear/Azure DevOps é a fonte de verdade ativa e conectada.
Atualizar somente quando a US introduziu algo novo:
| Arquivo | Quando atualizar |
|---|---|
.catalog/features.md | Nova funcionalidade implementada |
.catalog/architecture.md | Novo ADR, mudança de camada, padrão estrutural |
.catalog/conventions.md | Novo padrão de código emergiu |
.catalog/concerns.md | Nova dívida técnica ou risco |
.catalog/stack.md | Nova dependência ou configuração |
Jamais delete ADRs — são a memória histórica do projeto.
| Situação | Abordagem |
|---|---|
release_management.strategy: github-auto-release | Label release:* no PR e release notes geradas pelo workflow |
release_management.strategy: github-legacy | Milestone versionada apenas se configurada; release notes conforme convenção |
release_management.strategy: release-please | Conventional Commits → geração automática de CHANGELOG.md e Release |
release_management.strategy: manual-changelog | Manter CHANGELOG.md ou changelog de entrega manual |
release_management.strategy: none | Não criar changelog/release formal |
Regra: Nunca escrever changelog versionado manualmente se
release_management.strategydelega isso agithub-auto-releaseourelease-please. Verharness-engineering/references/13-release-management.md.
Sempre: entrega fechada conforme project_tracking.tool; [delivery_docs.path]/ atualizado apenas se for fonte ativa ou fallback.
Se aplicável: .catalog/ atualizado + AGENTS.md atualizado se houve mudança estrutural
harness-cicd(ou voltar para harness-implementation para a próxima US do milestone)
Template completo de prompt: Ver ./prompt.md