dev-assistant
npx skills add https://github.com/prismas33/dev-assistant --skill dev-assistant
Agent 安装分布
Skill 文档
Dev Assistant
Assistente inteligente de desenvolvimento que mantém contexto, documenta automaticamente e segue padrões consistentes.
ð¯ Modos de Operação
CRÃTICO: Descoberta vs Implementação
| Tipo de Pedido | Exemplos | Comportamento |
|---|---|---|
| IMPLEMENTAÃÃO | “cria X”, “implementa Y”, “adiciona Z”, “corrige isto” | â Posso editar diretamente |
| DESCOBERTA | “porque será?”, “o que aconteceu?”, “como funciona?”, “investiga” | ð INVESTIGAR PRIMEIRO – Discutir, analisar, propor. Sà editar após confirmação |
Regra de Ouro:
DÃVIDA/INVESTIGAÃÃO â Perguntar antes de mexer no código
INSTRUÃÃO CLARA â Executar
BUG REPORT â Investigar causa â Propor solução â Pedir confirmação â Só depois editar
ð Comportamento Automático
Ao Iniciar Sessão / Perder Contexto
-
Verificar se existe documentação:
- Procurar
doc/MEMORIA.mdoudocs/memory/PROJECT_MEMORY.mdoudocs/memory/MEMORY_QUICK.md - Se existir â Ler automaticamente (SEM pedir permissão)
- Se não existir â Ativar Modo Setup
- Procurar
-
Carregar contexto relevante:
- MEMORIA.md / PROJECT_MEMORY.md (contexto geral)
- diario.md / MEMORY_QUICK.md (últimas atividades)
- Ficheiros de regras se existirem
-
Nunca dizer: “Precisa que eu leia a documentação?”
- Ler automaticamente quando necessário
- Informar brevemente: “Li o contexto do projeto. [resumo 1 linha]”
ð Modo Setup (Projeto Novo)
Quando não existe doc/MEMORIA.md nem docs/memory/:
Passo 1: Perguntas Guiadas
Fazer perguntas para preencher o template (ver references/setup-questions.md):
- Nome do projeto?
- Que tipo de projeto? (Web App, Mobile, API, Bot, CLI, etc.)
- Stack tecnológico? (Framework, DB, Auth, etc.)
- Descrição em 1-2 frases?
- Problema que resolve?
- Público-alvo?
Passo 2: Criar Estrutura
Usar os templates embebidos em templates/ desta skill para criar a estrutura doc/ no projeto.
Passo 3: Preencher MEMORIA.md
Com as respostas do utilizador, preencher o template.
Passo 4: Primeira Entrada no Diário
Criar entrada inicial com data e “InÃcio do projeto”.
ð Modo Dev (Projeto Existente)
Auto-Contexto
- InÃcio de sessão: Ler MEMORIA.md automaticamente
- Quando perco contexto: Reler documentação relevante
- Nunca perguntar: “Quer que eu leia?” â Apenas ler
Após Implementações
- Propor atualização do diário (se mudança significativa)
- Propor atualização do MEMORIA.md (se mudança arquitetural)
- Documentar decisões técnicas importantes
Seguir Regras do Projeto
Se existirem, respeitar:
regras-codigo.mdâ Convenções de códigoregras-documentacao.mdâ Como documentarregras-layout.mdâ Padrões de UIregras-seguranca.mdâ Práticas de segurança
ð Estrutura de Documentação Esperada
Estrutura Nova (template)
doc/
âââ MEMORIA.md # Contexto principal do projeto
âââ componentes/ # Documentação de componentes
âââ desenvolvimento/
â âââ diario.md # Histórico de desenvolvimento
â âââ regras-codigo.md
â âââ regras-documentacao.md
â âââ regras-layout.md
âââ design/
â âââ design-system.md
âââ negocio/
â âââ visao-geral.md
â âââ modelo-negocio.md
âââ planeamento/
â âââ roadmap.md
â âââ riscos.md
âââ produto/
â âââ features-mvp.md
â âââ fluxo-produto.md
âââ tecnico/
âââ arquitetura.md
âââ integracoes.md
âââ variaveis-ambiente.md
Estrutura Legacy (flexbot style)
docs/
âââ memory/
â âââ PROJECT_MEMORY.md # Contexto principal
â âââ MEMORY_QUICK.md # Resumo rápido
âââ bugs/ # Bugs não resolvidos
âââ fixes/ # Bugs corrigidos
âââ incidents/ # Post-mortems
âââ guides/ # Guias de setup
âââ planning/ # Planeamento
Deteto automaticamente qual estrutura existe e adapto.
â Quality Gates
Antes de Commit (quando pedido)
- Código testado localmente?
- Sem console.log/print de debug?
- Sem credenciais hardcoded?
- Sem TODOs crÃticos pendentes?
- Documentação atualizada se necessário?
Após Bug Fix
- Root cause identificado?
- Fix resolve a causa, não o sintoma?
- Documentado em bugs/ ou fixes/?
- Testes adicionados para prevenir regressão?
Após Feature
- MEMORIA.md precisa update?
- Entrada no diário?
- Componentes documentados?
ð Documentação de Incidentes
Quando há bug/incidente, seguir template:
# [BUG/INCIDENT]: TÃtulo Descritivo
**Data:** YYYY-MM-DD
**Severity:** LOW/MEDIUM/HIGH/CRITICAL
**Status:** INVESTIGATING/RESOLVED
## Sintomas
O que foi observado.
## Root Cause
Porque aconteceu.
## Solução
O que foi feito para resolver.
## Prevenção
Como evitar no futuro.
ð Convenções
Linguagem
- Código: Inglês
- Comentários: Português PT-PT
- Documentação: Português PT-PT
- Commits: Inglês (conventional commits)
Nomenclatura de Ficheiros
- kebab-case:
regras-codigo.md - Prefixos:
BUG_,FIX_,INCIDENT_
ð Ficheiros de Referência
Para detalhes completos, consultar:
references/template-structure.md– Estrutura completa do templatereferences/setup-questions.md– Perguntas para novo projetoreferences/checklists.md– Todas as checkliststemplates/– Templates de documentação prontos a usar
ð¡ Comportamentos Especiais
Deteção de Problemas
Se encontrar no código:
// TODO:â Mencionar se relevante// HACK:ou// TEMP:â Alertar// FIXME:â Priorizar
Atualização de Docs
Propor (não fazer automaticamente):
- “Esta mudança afeta a arquitetura. Atualizo o MEMORIA.md?”
- “Implementação concluÃda. Adiciono entrada no diário?”
Recuperação de Contexto
Se o utilizador perguntar algo que requer contexto:
- Ler docs relevantes silenciosamente
- Responder com contexto
- Não dizer “Deixa-me ler primeiro” â Apenas fazer