███╗   ██╗███████╗    ███████╗██╗      ██████╗ ██╗    ██╗    ██╗  ██╗██╗████████╗
 ████╗  ██║██╔════╝    ██╔════╝██║     ██╔═══██╗██║    ██║    ██║ ██╔╝██║╚══██╔══╝
 ██╔██╗ ██║███████╗    █████╗  ██║     ██║   ██║██║ █╗ ██║    █████╔╝ ██║   ██║
 ██║╚██╗██║╚════██║    ██╔══╝  ██║     ██║   ██║██║███╗██║    ██╔═██╗ ██║   ██║
 ██║ ╚████║███████║    ██║     ███████╗╚██████╔╝╚███╔███╔╝    ██║  ██╗██║   ██║
 ╚═╝  ╚═══╝╚══════╝    ╚═╝     ╚══════╝ ╚═════╝  ╚══╝╚══╝     ╚═╝  ╚═╝╚═╝   ╚═╝

Powered by Claude Code · Speckit · BMAD · TLC Spec-Driven

"Humans Decide. Agents Execute." Transforma a engenharia de sistemas legados de reativa e tribal em estruturada, assistida por agentes e mensurável — sem reescrever um único sistema.

Quick Start · Workflows · Agentes · Comandos · Speckit · Roadmap

O que é

O NS Flow Kit é um framework operacional para times que mantêm sistemas legados heterogêneos (.NET, Java, Delphi, Oracle, PHP, Node, Python). Agentes de IA especializados executam o trabalho pesado — investigar, propor fix, gerar testes, montar PR — e humanos aprovam em pontos de parada definidos. Todo o conhecimento acumulado vira memória institucional (o Speckit), então o mesmo problema nunca é resolvido duas vezes do zero.

| Problema do legado | Como o kit resolve | |--------------------|--------------------| | Conhecimento tribal | Speckit captura padrões, riscos e decisões de forma consultável | | Discovery manual lento | Agentes investigam contra o Speckit antes de você escrever código | | Blast radius desconhecido | impact-analyzer mapeia o que cada mudança afeta | | Processo inconsistente | Workflows padronizados com checkpoints humanos obrigatórios | | Zero aprendizado institucional | learning-agent atualiza o Speckit ao fechar cada ticket |

Como funciona

Quatro conceitos sustentam todos os workflows:

1. Speckit First — antes de investigar, os agentes leem a base de conhecimento em .speckit/ (domínio, risk-map, ADRs, known-issues). Quanto mais maduro o Speckit, mais rápido o discovery.
2. Agentes encadeados — cada agente tem responsabilidade única e output estruturado. Eles se encadeiam (ex: bug-investigator → impact-analyzer) e gravam artifacts rastreáveis em .ns-flow/.
3. Checkpoints humanos — o agente para, apresenta um resumo e aguarda aprovação antes de prosseguir. Você decide; o agente executa.
4. Encerramento via learning-agent — o ticket só fecha quando o aprendizado volta para o Speckit.

 Ticket (Azure DevOps Boards / GitHub Issues)
        │
        ▼
 Workflow (bug · feature · data-fix · vuln · …)   ── agentes executam cada etapa
        │
        ▼
 ⚡ Checkpoints humanos  ── você aprova antes de cada avanço
        │
        ▼
 Entrega (commits · PR · release)  →  learning-agent  →  Speckit atualizado

📊 Visão visual de todos os workflows: veja o guia navegável em docs/workflows/.

Quick Start

Quatro comandos para começar. O passo a passo completo (MCP, autenticação, troubleshooting) está em docs/workflows/00-instalacao-setup.md.

# 1. Instalar o Claude Code (requer Node 24.15.0 + conta Anthropic)
npm install -g @anthropic/claude-code && claude login

# 2. (Recomendado) Conectar ao Azure DevOps ou GitHub para ler/escrever tickets
npx @nstechhub/corporate-ns-flow-kit setup-mcp

# 3. Instalar o kit no seu repositório
cd /caminho/do/seu/repo
npx @nstechhub/corporate-ns-flow-kit init

# 4. Popular o Speckit (base de conhecimento que os agentes consultam)
claude
/bootstrap-repo Nome-Sistema --stack dotnet

Depois do bootstrap, revise os campos [DRAFT] gerados em .speckit/ (o bug-investigator usa esse contexto) e rode seu primeiro ticket. Detalhes em docs/workflows/00-instalacao-setup.md.

Sem Claude Code? O kit também funciona via Cursor / VS Code + IA ou qualquer IA no browser — o bootstrap roda como script e os prompts dos agentes ficam em .claude/agents/. Veja os caminhos B e C no doc de instalação.

Escolha seu workflow

Cada workflow é um pipeline de agentes com checkpoints humanos, com guia detalhado em docs/workflows/ — o que faz, passo a passo, arquivos gerados e quem aprova o quê.

Duas esteiras em paralelo: Produto (upstream — o PO parte de uma ideia e cria a demanda pronta no board via /discover) e Sustentação (a demanda já chega como card → /route). Ambas convergem no board e alimentam /feature. Ver o Guia do PO.

| Workflow | Quando usar | Trigger | Guia | |----------|-------------|---------|------| | Product Discovery 🔬 | Ideia de produto sem card no board (esteira upstream) | /discover "{texto}" | doc | | Feature | Nova funcionalidade (Spec-Driven, auto-sized) | /feature <ticket> | doc | | Bug | Defeito com root cause única | /analyze-bug <ticket> | doc | | Small Improvement | Ajuste leve sem lógica de negócio | /analyze-bug <ticket> | doc | | Data Fix | Root cause puramente de banco | /analyze-bug → /data-fix <ticket> | doc | | Vulnerability 🔬 | Findings de SAST/DAST/pentest por classe CWE | /scan-vuln → /analyze-vuln CWE-NN | doc | | Orchestration | Coordenar 2+ tickets em paralelo | /manage-queue | doc | | Health Monitor | Resiliência proativa / pós-deploy | /health-check <sistema> | doc |

Outros fluxos auxiliares (critical-incident, parallel) estão definidos em .claude/workflows/. Comandos de entrada/apoio (/route, /performance-analyze) estão em .claude/commands/.

🔬 = experimental — promovido para estável após 2 pilotos em stacks diferentes.

Comandos

Slash commands (Claude Code)

# Produto (esteira upstream — sem card no board ainda)
/discover "{texto da ideia}"       # 🔬 Discovery → Refino → Protótipo → cria Epic + Stories

# Porta de entrada (esteira de sustentação)
/route <ticket>                    # classifica o flow e decide o repo, com evidência

# Onboarding & manutenção do conhecimento
/bootstrap-repo Sistema --stack X  # popula Speckit + docs do repo
/bootstrap-security --stack X      # 🔬 popula cwe-catalog + scaffold tools/
/update-speckit Sistema --since X  # varredura periódica pós-sprint
/wiki-index [--full|--incremental] # mapeia a Wiki do Azure DevOps → apps (azure-wiki-indexer)
/new-app-expert-agent              # cria subagent expert_<APP> (regras, integrações, deps)

# Bug / Feature
/analyze-bug <ticket>              # investigação → BugReport + ImpactReport
/generate-fix <ticket>            # gera o patch mínimo
/run-regression <ticket>          # valida + escreve testes (RED→GREEN)
/open-pr <ticket>                 # cria PR com rollback plan
/release-check <ticket>           # verifica gates e gera release package
/feature <ticket>                 # Specify → Design → Tasks → Execute (auto-sized)

# Qualidade 🔬 (Esteira de Qualidade — 4 gates shift-left: 1–3 + S security)
/qa-plan <ticket> [--pr <id>]     # estratégia por camada (FEAT-{N}); --pr reconcilia os CTs com o diff do PR (Azure DevOps) após o open-pr
/qa-publish <ticket>              # opt-in Azure: publica os CTs como Test Cases no Azure Test Plans (create-or-update)
/run-regression <ticket>          # Gate 1 — cobertura do diff + RED→GREEN
/smoke <ticket>                   # Gate 2 — caminho crítico
/validacao-testes <ticket>        # Gate 3 — E2E em HML com evidência
/qa-gate <ticket>                 # meta-gate: cobertura + smoke + E2E + security (SAST do diff)
# + /security-review no /open-pr (lente semântica) bloqueia a PR com finding ≥ MEDIUM

# Análise & coordenação
/performance-analyze <alvo>       # análise de performance (queries + compute + render)
/manage-queue [dev1 dev2 …]       # backlog priorizado + detecção de conflitos
/health-check Sistema             # saúde proativa, roteamento por severidade

# Code review (read-only — nunca altera o PR)
/ns-review-pr <PR_ID> [repo]      # review de PR do Azure DevOps via MCP
/ns-review-branch [base]          # review do diff da branch local contra a base

# Auditoria & conformidade (read-only)
/cnpj-alfa-scan [ticket] [--with-db]   # CNPJ alfanumérico IN RFB 2229/2024 (cnpj-alfa-auditor)
/batimento-rcv <caixa30> [flags]       # reconciliação RCV origem MariaDB × destino SQL Server

# DB Fix (sem alteração de código-fonte)
/data-fix <ticket>                # script SQL idempotente (PRE-CHECK + rollback)

# Security 🔬 (experimental)
/scan-vuln [--semgrep-only|--veracode-only|--include-pentest=<path>]
/analyze-vuln CWE-NN <ticket>     # investigação por classe — padrão único de fix

CLI (npx @nstechhub/corporate-ns-flow-kit)

init                              # instala/atualiza o kit no projeto
setup-mcp [--provider github|azure-devops] [--switch]   # configura MCP do provider
setup-workflows                  # copia templates de GitHub Actions / Azure Pipelines
install-plugin <nome>            # instala um plugin do kit (ex.: ns-flow-obsidian-mind)

Subagentes auto-roteados (não são slash commands)

| Subagente | Acionado por | |-----------|--------------| | azure-card-refiner / github-issue-refiner | "Refinar card/issue NNN" | | expert_<APP> | Perguntas sobre uma app (criados via /new-app-expert-agent) | | doc-gen | "Gera doc técnica desse projeto" |

O Squad de Agentes

22 agentes core (execução) — cada um com responsabilidade única, limites definidos e output estruturado. Refiners (azure-card-refiner, github-issue-refiner), doc-gen e os agentes read-only de review/auditoria/conhecimento vivem no mesmo diretório, mas não contam nesse total.

| Grupo | Agentes | Papel | |-------|---------|-------| | Ciclo bug/feature | bug-investigator · impact-analyzer · architecture-agent · builder-agent · code-reviewer-agent · test-validator · pr-generator · release-agent · learning-agent | Investiga → valida → constrói → revisa → testa → entrega → aprende | | UX (evolução de UI) | ux-design-agent | Preserva o design system do produto e moderniza dentro dele — só valida/orienta | | Produto 🔬 | product-discovery-agent | Discovery → refino → decomposição em Epic/Stories (esteira upstream) | | Coordenação & saúde | orchestrator-agent · health-monitor-agent | Prioriza backlog; monitora resiliência | | DB layer | db-diagnostic-agent · data-fix-agent | Diagnostica e gera fixes de banco (nunca executa) | | Security 🔬 | vuln-triage · vuln-investigator | Ingestão multi-fonte; investigação por classe CWE | | Entrada & performance | intake-router-agent · performance-analyzer-agent | Roteia a demanda; analisa performance | | Qualidade 🔬 | qa-strategist · smoke-runner · qa-expert (+ test-validator · vuln-triage) | 4 gates shift-left: cobertura · smoke · E2E · security. qa-strategist também reconcilia os CTs com o diff do PR (/qa-plan --pr) e alimenta o /qa-publish (Test Cases no Azure Test Plans) | | Review & auditoria (read-only) | pr-reviewer · cnpj-alfa-auditor · rcv-batimento-auditor | Code review de PR/branch; auditoria CNPJ alfanumérico (IN RFB 2229/2024); batimento de embarques RCV — geram relatório, nunca alteram código/PR/dados | | Conhecimento | azure-wiki-indexer (+ refiners · doc-gen · expert_<APP>) | Indexa a Wiki, refina cards/issues, gera docs e experts por aplicação |

O code-reviewer-agent revisa o diff antes do checkpoint humano (escopo, corretude, segurança, reuso, testes, UX) — o terceiro passo do trio architecture → builder → code-reviewer, alimentando a decisão do revisor em vez de substituí-la.

Definições em .claude/agents/. Os agentes do ciclo compartilham protocolos canônicos em .claude/agents/_shared/ (busca de ticket via MCP/CLI, criação de card/issue, publicação de Test Case no Azure Test Plans, notificação opt-in de checkpoint).

Speckit — Memória Institucional

O Speckit é o que impede que o mesmo problema seja resolvido duas vezes do zero.

.speckit/
├── domain/          # sistemas, clientes, escalação
├── architecture/    # overview, risk map, integrações
├── business-rules/  # regras de negócio com impacto técnico
├── known-issues/    # padrões de bug confirmados + anti-patterns (+ cwe-catalog 🔬)
├── design-system/   # tokens, componentes e padrões de UX (curado pelo UX owner)
├── decisions/       # ADR registry
└── incidents/       # histórico de P1s, retrospectivas, metrics-feed

/bootstrap-repo Sistema --stack dotnet          # setup inicial (ou ./scripts/bootstrap-speckit.sh)
/update-speckit Sistema --since "2 weeks ago"   # atualização periódica pós-sprint

Maturidade — o valor cresce com o uso:

| Match rate | Significado | |------------|-------------| | 0–10% | Recém-populado (normal no início) | | 10–30% | Acumulando padrões — agentes ganham velocidade | | 30–50% | Maturidade operacional — discovery acelerado | | 50%+ | Maioria dos bugs já tem contexto histórico |

O bootstrap analisa estrutura, stack, histórico Git (hotspots, commits de bug), TODOs/FIXMEs, SQL concatenado, credenciais hardcoded e connection strings. Captura de conhecimento tácito (medos, nomes enganosos, cascatas ocultas) é opcional via Speckit Amplifier — cat .speckit/domain/tribal-knowledge-template.md.

Políticas (os agentes não podem ignorar)

| Política | O que governa | |----------|---------------| | coding-principles | Minimum Viable Patch, hypothesis-first, RED→GREEN, commits atômicos | | ux-consistency-policy | Preserva o design system do produto; moderniza dentro dele — sem identidade nova / one-off | | db-change-policy | Categorias A/B/C/D de banco — DDL bloqueia pipeline até aprovação humana | | production-policy | Nenhum acesso direto à produção — tudo via pipeline | | security-policy | Zero credenciais hardcoded, SQL parametrizado, sanitização de inputs | | branch-naming | Formato {tipo}/{TICKET_ID}-{slug} — habilita auto-link de issue e parsing por CI | | release-policy | Janelas, freeze periods, quality gates por severidade, fast-track de security | | vulnerability-policy 🔬 | 10 regras hard-stop do vulnerability-flow | | qa-policy 🔬 | 4 gates de qualidade (cobertura · smoke · E2E · security SAST do diff) + /security-review no PR — sem /qa-gate verde, sem PR/release |

Definições em .claude/policies/.

Plugins

Capacidades opcionais que estendem o kit. Cada plugin vive em plugins/<nome>/ (com plugin.json, README.md, install.js e, opcionalmente, agent-instructions.md, policy.md, templates/) e é instalado sob demanda.

A) Via marketplace do Claude Code (recomendado) — registra o marketplace privado uma vez e instala pelos comandos /plugin:

/plugin marketplace add nstechhub/corporate-ns-flow-kit
/plugin install ns-flow-obsidian-mind@ns-flow-kit
/plugin install ns-flow-movidesk@ns-flow-kit
/plugin install ns-flow-aws@ns-flow-kit
/plugin install ns-flow-azure-cloud@ns-flow-kit

Instale em user scope para que o plugin valha em todos os seus projetos. Como o repositório é privado, a instalação usa suas credenciais git (gh auth login ou SSH).

B) Via CLI do kit — alternativa para quem já tem o kit instalado no projeto:

npx @nstechhub/corporate-ns-flow-kit install-plugin <nome>

| Plugin | O que faz | |--------|-----------| | ns-flow-obsidian-mind | Conecta um cofre Obsidian compartilhado — o repositório git corporate-ns-flow-kit-memory, clonado localmente — como cérebro persistente dos agentes. Conhecimento por aplicação em três pastas: 01-Reference (curado por humanos, agentes só leem), 02-Workspace (agentes operam livremente) e 03-Synthesis (consolidação com origem citada). Versionado via git com a main protegida: o trabalho acontece numa branch por usuário (userBranch, definida no setup) e a integração à main é via Pull Request — atualização por merge da base antes de ler, commit/push da branch + PR após gravar (restrito ao repoPath, com pushMode configurável). Comandos: setup, new-app, import, synthesize, sync. | | ns-flow-movidesk | Integração somente-leitura com a API pública do Movidesk (Ticket API v1). Um wrapper Node lê o token de .local-config.json (ou da env MOVIDESK_TOKEN), trata rate limit (HTTP 429) e devolve JSON sanitizado — o token nunca entra no contexto do modelo. Permite detalhe de ticket, busca por filtro OData e consulta de pessoas/serviços. Escrita desabilitada por padrão (writeEnabled=false, atrás de checkpoint humano). Comandos: setup, ticket, search. | | ns-flow-aws | Integração com os MCP servers oficiais da AWS (AWS Labs) — foco em SQS + cobertura ampla (aws-sns-sqs + aws-api, via uvx). Auth por perfil nomeado ou access keys; read-only por padrão (operações destrutivas exigem checkpoint humano). Comandos: setup, sqs-peek, sqs-stats, sqs-dlq + agente aws-sqs-investigator. Pré-req: uv/uvx (Python) + credenciais AWS. | | ns-flow-azure-cloud | Integração com o Azure MCP Server oficial (@azure/mcp) — foco em Service Bus + recursos de nuvem Azure (não é o azure-devops). Auth via az login (DefaultAzureCredential), sem segredo gravado; read-only por padrão. Comandos: setup, sb-peek, sb-stats, sb-dlq + agente azure-servicebus-investigator. Pré-req: Azure CLI logado. |

Catálogo de plugins em .claude-plugin/marketplace.json. Detalhes de cada plugin no seu próprio README.md em plugins/.

Estrutura do repositório

.claude/          # Camada de execução (Claude Code)
  agents/         #   27 agentes (22 core + review/auditoria/conhecimento), com _shared/ (protocolos canônicos)
  commands/       #   slash commands
  workflows/      #   definições canônicas dos fluxos
  policies/       #   9 políticas hard-stop
  context/ hooks/ prompts/
.ns-flow/         # Artifacts por ticket (subpastas criadas sob demanda: analysis, design, delivery, discovery,
                  #   intake, state, orchestration, monitoring, code-reviews, templates)
plugins/          # Plugins opcionais do kit (ns-flow-obsidian-mind) — instalados via `install-plugin <nome>`
docs/
  workflows/      # 👉 Guias dos workflows + instalação detalhada
  onboarding/     #   IDE compatibility · squad member guide
  testing/        #   smoke-test-guide
migrations/       # Scripts SQL versionados e idempotentes (Data Fix)
tools/            # Wrappers SAST — semgrep/ + veracode/ (Security 🔬)
scripts/          # bootstrap-speckit · update-speckit · init-ticket · validate-kit

Variáveis por projeto (no CLAUDE.md): ARTIFACTS_DIR (.ns-flow), SPECKIT_DIR (.speckit). Padrão de ticket (ADO- / GH-) em .claude/.local-config.json.

Stacks suportados

| Stack | Bug/Feature | Geração de teste | Security 🔬 | |-------|:-----------:|:----------------:|:-----------:| | .NET Framework 4.8 | ✅ | ✅ xUnit/NUnit | ✅ (PoC CITNET validado) | | Java 8/11 | ✅ | ✅ JUnit 5 | ⏳ piloto pendente | | Oracle PL/SQL | ✅ | ✅ | ⚠️ catálogo limitado | | SQL Server | ✅ | ✅ | n/a | | Node / TypeScript | ✅ | ✅ Jest/Vitest | ⏳ piloto pendente | | Python | ✅ | ✅ pytest | ⏳ piloto pendente | | PHP 5.x–7.x | ✅ | ⚠️ PHPUnit se disponível | ⏳ piloto pendente | | Delphi | ✅ | ⚠️ manual | ⚠️ fallback |

Stacks com banco usam db-change-policy obrigatória. O Security Flow é experimental: só .NET tem PoC validado; os demais funcionam via fallback até passarem por um piloto.

Métricas

O learning-agent alimenta .speckit/incidents/metrics-feed.jsonl após cada ticket, com type: "bug" | "feature" | "vulnerability" | "data-fix" para segregar KPIs.

| Métrica (bug/feature, maduro) | Target | |-------------------------------|--------| | Speckit match rate | > 40% | | Discovery time P2 | ≤ 4h | | Cycle time total P2 | ≤ 10h | | Rework rate | < 15% | | Regression rate | < 5% |

Targets de DB Fix e Vulnerability nos respectivos guias em docs/workflows/. Benchmark (PoC CITNET): 401 findings brutos → 192 únicos → 8 classes CWE fechadas em 24 commits → 0 regressões.

Compatibilidade de IDEs

Roda em qualquer ambiente baseado em VS Code, sem adaptar conteúdo.

| IDE | Suporte | |-----|---------| | Claude Code | ✅ Nativo — slash commands + agentes encadeados | | Cursor | ✅ .cursor/rules/ + Tasks | | VS Code + Copilot | ✅ .github/copilot-instructions.md + Tasks | | VS Code + Gemini / Antigravity | ✅ Tasks + #file: references | | VS Code puro | ⚠️ Manual — Tasks + scripts + AI no browser |

Guia completo: docs/onboarding/ide-compatibility-guide.md

Onboarding do squad

Semana 0:  /bootstrap-repo SISTEMA  →  revisar DRAFTs  →  validar com o time
Semana 1:  primeiro ticket real no bug-flow  →  debrief
Semana 2+: learning-agent após cada ticket  +  /update-speckit toda segunda
Mês 2:     Speckit match rate > 25%  →  agentes acertando padrões
Mês 3:     Cycle time P2 ≤ 10h  →  velocidade de cruzeiro

Guia completo: docs/onboarding/squad-member-guide.md

AI-Ready Repository Standard

| Nível | Critério | |-------|----------| | 1 — Legível | README, stack documentado, zero credenciais no repo | | 2 — Navegável | .speckit/domain/ preenchido, 3+ ADRs, known-issues iniciais | | 3 — Agent-Ready | Risk map atualizado, dependency map, smoke tests, runbooks | | 4 — Intelligence-Ready | Match rate > 40%, metrics-feed ativo, MCP integrado | | 5 — Security-Hardened 🔬 | cwe-catalog com paths reais, SAST integrado, vuln-flow em 3+ classes |

Roadmap

• ✅ v1.0–v1.4 — ciclo bug/feature completo, multi-provider (Azure DevOps + GitHub), coordenação & resiliência, DB fix layer, intake router e performance analyzer. Notas até 1.2.0-experimental em CHANGELOG.md; para versões mais recentes, use as releases/tags do GitHub.
• ✅ v1.5.0 — três esteiras: Produto + Dev + Qualidade.
• ✅ v1.5.1 — code review no loop (code-reviewer-agent, trio do build cycle) + tema de UX para evolução de legado (ux-design-agent + ux-consistency-policy + .speckit/design-system/).
• ✅ v1.5.2 — camada de adapters de IDE (Cursor .cursor/rules/ + GitHub Copilot .github/copilot-instructions.md + .vscode/ tasks), finos e apontando para .claude/, propagados pelo init.
• ✅ v1.6.x — paridade total dos adapters (Cursor + Copilot + VS Code) com o Claude Code em todas as esteiras, playbooks de auditoria (CNPJ alfanumérico, batimento RCV) e ajustes de release/CI.
• ✅ v1.7.0 (atual) — QA → Azure Test Plans: /qa-publish publica os CT-{MOD}-NNN do QA Plan como Test Cases reais (create-or-update, Azure-only, aprovação explícita do QA) e /qa-plan --pr reconcilia os CTs com o diff do PR após o open-pr. Publicar Test Case não é gate — não substitui o Gate 3.
• 🔬 v1.2.0-experimental — Vulnerability Flow (PoC CITNET validado). Promoção para estável após 2º piloto em stack diferente. Decisão em ADR-007.
• 🔬 v1.5.0 — Esteira de Qualidade (Quality Layer) — 4 gates shift-left (cobertura · smoke · E2E · security) embutidos no pipeline; o dev entrega com qualidade garantida e o QA vira owner dos agentes. Decisão em ADR-009.
• 🔬 v1.5.0 — Esteira de Produto (Product Discovery Track) — /discover leva o PO de um texto a Epic + User Stories no board (Discovery → Refino → Protótipo → Publicação), com protótipo via Claude/Lovable. Decisão em ADR-008.
• 🔮 v2.0 — Multi-repo Intelligence — Speckit compartilhado entre repos, cross-repo pattern detection, engineering intelligence a nível de organização.

Contribuindo

Melhorias via PR:

• Novos anti-patterns → .speckit/known-issues/anti-patterns.md
• Suporte a novo stack → atualizar agentes + este README
• Correções nos agentes → PR com justificativa
• Novos ADRs → .speckit/decisions/

Mudanças em políticas exigem justificativa detalhada no PR.

Licença

MIT — use, adapte e distribua livremente. Se usar em produção, uma ⭐ no repo ajuda outros times a encontrar.

Built for squads that ship legacy systems at the speed of modern engineering.

nstechhub