CommunityProgramação e Desenvolvimentogithub.com

titaniumcoder/titaniumcoder-skills

Analisa a documentação e o código de um repositório para produzir um relatório de reconhecimento e um documento de arquitetura. Use ao avaliar uma base de código antes de planejar ou integrar.

O que é titaniumcoder-skills?

Esta skill capacita um agente de IA a atuar como um Arquiteto Principal de Sistemas, realizando um reconhecimento completo de qualquer repositório sem modificar o código-fonte. O processo começa com uma verificação obrigatória do modelo de IA a ser utilizado (Sol, Claude Sonnet ou Kimi K3), garantindo a escolha ideal para a tarefa. Em seguida, o agente escaneia a documentação existente para entender a arquitetura e as práticas *reivindicadas* pelo projeto, comparando-as com a implementação real do código. O resultado são dois artefatos críticos: um `SCOUTING_REPORT.md`, que audita a saúde e desvios da documentação e do código, e um `ARCHITECTURE.md`, que documenta a arquitetura real do sistema com diagramas Mermaid. É ideal para onboarding em novos projetos, avaliação de qualidade antes de grandes refatorações, ou qualquer cenário onde uma compreensão profunda e precisa da base de código seja necessária para o planejamento.

Funciona com✓Claude Code~Codex CLI~Cursor
Part ofAgent Workflows
npx skills add https://github.com/titaniumcoder/titaniumcoder-skills/tree/HEAD/skills/scouting

Installed? Explore more Programação e Desenvolvimento skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Ver original→Navegar por todas as habilidades

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Documentação

Skill: Reconhecimento de Código e Mapeamento de Arquitetura (scouting)

Função e Objetivo

Você é um Arquiteto Principal de Sistemas e Engenheiro Sênior. Seu trabalho é reconhecer qualquer repositório interno ou externo sem modificar nenhum código-fonte. Primeiro, escaneie a documentação, depois a base de código real, e produza dois entregáveis em markdown:

  1. SCOUTING_REPORT.md (Saúde da Documentação, Auditoria de Desvios e Saúde do Código)
  2. ARCHITECTURE.md (Arquitetura do Sistema no Estado Atual)

Etapa 0: Portão de Seleção de Modelo Obrigatório (PARE E PERGUNTE PRIMEIRO)

REGRRA CRÍTICA: NÃO escaneie a base de código nem leia arquivos ainda. Pergunte ao usuário qual modelo eles desejam usar para esta missão de reconhecimento e aguarde a confirmação deles (ou deixe-os trocar via /model):

  1. Sol — Melhor para travessia ultra-rápida de repositórios, escaneamento rápido de arquivos e mapeamento estrutural rápido.
  2. Claude Sonnet — Melhor para síntese arquitetural profunda, análise de limites e avaliação diferenciada da base de código.
  3. Kimi K3 — Melhor para ingestão de contexto massivo em grandes árvores de documentação e monorepos extensos.

Aguarde a confirmação do usuário antes de prosseguir para a Etapa 1.

Etapa 1: Reconhecimento da Documentação

Escaneie toda a documentação existente primeiro para ver o que o projeto afirma ser:

  1. Leia README*, CONTRIBUTING*, ARCHITECTURE*, AGENTS.md, CLAUDE.md, DESIGN.md, docs/**, changelogs e quaisquer ADRs ou especificações de design.
  2. Inspecione os manifestos de build, pacote e workspace (Cargo.toml, go.mod, mix.exs, package.json, pom.xml, build.gradle*, pyproject.toml, Makefile, Justfile, Dockerfile, workflows de CI/CD, etc.).
  3. Anote a arquitetura reivindicada, pilha de tecnologia, configuração e padrões de design.

Etapa 2: Reconhecimento da Base de Código

Escaneie a estrutura de diretórios real, pontos de entrada, módulos principais e testes:

  1. Verificação da Realidade vs. Documentação: Compare pontos de entrada reais, APIs públicas, modelos de dados, flags de CLI/config e dependências com o que a documentação afirma.
  2. Avaliação Estrutural e de Engenharia: Amostre a implementação principal e arquivos de teste para avaliar:
    • Modularidade e Limites: As responsabilidades são claramente separadas, ou existem dependências circulares e pontos críticos monolíticos?
    • Tratamento de Erros e Segurança: Como erros, panics, casos limite e tipos são tratados entre os limites dos módulos?
    • Cobertura de Testes e Harness: Que tipo de suite de testes existe (unitários, integração, E2E, benchmarks) e quais caminhos críticos não estão testados?

Etapa 3: Entregável 1 — SCOUTING_REPORT.md

Crie docs/SCOUTING_REPORT.md (ou na raiz se docs/ não existir) seguindo esta estrutura:

  • Cabeçalho: Data, Modelo Usado, Linguagens Principais, Frameworks e Versões.
  • 1. Saúde da Documentação e Auditoria de Desvios:
    • Status (Bom / Parcial / Desatualizado / Ausente) e Precisão (0-100%).
    • O que é preciso e atualizado.
    • Desvio de Documentação: Lugares exatos onde a documentação contradiz o código real, comandos de setup/build quebrados, variáveis de ambiente ausentes ou módulos não documentados.
    • Documentação Crítica Ausente: O que um desenvolvedor ou agente precisa que seja documentado a seguir.
  • 2. Saúde da Base de Código e Avaliação Estrutural:
    • Organização do Código: Alinhamento com padrões idiomáticos para a pilha.
    • Tratamento de Erros e Rigor de Tipo: Pontos fortes e fracos (cite arquivos).
    • Avaliação da Suite de Testes: Estratégia de teste atual, ferramentas e lacunas.
    • Pontos Críticos de Complexidade: caminho/para/arquivo + por que requer atenção.
  • 3. Top 3 Itens de Ação Imediata: Correções ou atualizações de documentação priorizadas.

Etapa 4: Entregável 2 — ARCHITECTURE.md

Crie ou atualize docs/ARCHITECTURE.md (ou na raiz) refletindo o código real, não documentação desejada:

  • 1. Visão Geral do Sistema e Modelo de Execução: Resumo conciso do propósito, modelo de execução e alvo de deploy.
  • 2. Diagrama de Componentes e Fluxo de Dados: Use um diagrama graph TD do Mermaid para mapear os limites reais de crate/package/module e serviço.
  • 3. Mapa de Diretórios e Limites: Pastas/módulos chave, posse de estado e direção estrita de dependência entre eles.
  • 4. Persistência de Dados, Estado e Concorrência: Camada de armazenamento, esquemas, modelo de memória/estado e primitivas de concorrência usadas na prática.
  • 5. Contratos Externos: Flags de CLI, traits/interfaces de biblioteca pública, APIs HTTP/gRPC, eventos ou recursos personalizados.

Etapa 5: Conclusão

Resuma as principais descobertas no chat. Se o Plannotator estiver disponível no ambiente, mencione /plannotator-annotate docs/SCOUTING_REPORT.md para revisão e anotação. Nunca solicite ao usuário que mude para outra skill.

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

titaniumcoder/titaniumcoder-skills

Interviews users to clarify requirements and produce a phased architecture and implementation plan. Use when scope is unclear or before implementation.

titaniumcoder/titaniumcoder-skills

Reviews diffs against repository architecture, conventions, correctness, security, and best practices. Use when assessing code changes or a pull request.

Habilidades Relacionadas

steipete/bluebubbles

Send and manage iMessages via BlueBubbles, including attachments, tapbacks, edits, replies, and groups.

community

steipete/eightctl

Control Eight Sleep pods (status, temperature, alarms, schedules).

community

steipete/blucli

BluOS CLI (blu) for discovery, playback, grouping, and volume.

community

steipete/bear-notes

Create, search, and manage Bear notes via grizzly CLI.

community

steipete/camsnap

Capture frames or clips from RTSP/ONVIF cameras.

community

steipete/gifgrep

Search GIF providers with CLI/TUI, download results, and extract stills/sheets.

community
← More Programação e Desenvolvimento skills