feat(project-manager): adiciona plugin project-manager (agents, skills, knowledge e metadados do projeto)
This commit is contained in:
@@ -0,0 +1,17 @@
|
||||
# AGENTS.md — skills
|
||||
|
||||
Directrizes específicas deste projecto para agentes IA.
|
||||
|
||||
## Referências obrigatórias
|
||||
|
||||
- `ECOSYSTEM.md` — Hub/06-Operacoes/Documentacao/ECOSYSTEM.md
|
||||
- `PROC-DEV-STANDARD` — D7-SIS-006
|
||||
- `PROC-AUDIT-STANDARD` — D7-SIS-007
|
||||
|
||||
## Protocolo de sessão
|
||||
|
||||
Início: ler MEMORY.md + STATUS.md. Fim: actualizar ambos.
|
||||
|
||||
## Convenções específicas
|
||||
|
||||
- (a definir)
|
||||
@@ -0,0 +1,5 @@
|
||||
# CHANGELOG — skills
|
||||
|
||||
## 0.1.0 — 2026-06-30
|
||||
### Adicionado
|
||||
- Estrutura padrão (PROC-DEV-STANDARD)
|
||||
@@ -0,0 +1,4 @@
|
||||
# MEMORY.md — skills
|
||||
|
||||
## 2026-06-30
|
||||
- Estrutura padrão aplicada via propagate-structure.sh
|
||||
@@ -0,0 +1,3 @@
|
||||
# skills
|
||||
|
||||
Subprojecto skills do ecossistema Descomplicar.
|
||||
@@ -0,0 +1,8 @@
|
||||
# STATUS.md — skills
|
||||
|
||||
**Versão:** 0.1 | **Data:** 2026-06-30 | **Agente:** —
|
||||
|
||||
## Estado actual
|
||||
- Em curso: —
|
||||
- Bloqueios: —
|
||||
- Próximos passos: —
|
||||
@@ -0,0 +1,160 @@
|
||||
---
|
||||
name: brainstorm
|
||||
description: Brainstorming estruturado que explora ideias de múltiplos ângulos antes de criar spec. Consulta NotebookLM para perspectivas de especialistas.
|
||||
layer: wiki
|
||||
---
|
||||
|
||||
# /brainstorm v1.2 - Ideacao Estruturada
|
||||
|
||||
> **NOTA 07-04-2026:** referências a "Dify KB" no corpo desta skill são obsoletas (Dify removido em 06-03-2026). Substituir por NotebookLM ou /knowledge nas próximas iterações. Workflow geral mantém-se válido.
|
||||
|
||||
Explora ideias de multiplos angulos antes de formalizar num spec.
|
||||
Consulta especialistas via NotebookLM (conhecimento curado profundo).
|
||||
|
||||
**Flow:** brainstorm -> /spec create -> /sprint plan -> codigo
|
||||
|
||||
---
|
||||
|
||||
## Comandos
|
||||
|
||||
| Comando | Funcao |
|
||||
|---------|--------|
|
||||
| `/brainstorm` | Brainstorm interactivo sobre ideia |
|
||||
| `/brainstorm <tema>` | Brainstorm focado num tema |
|
||||
| `/brainstorm decide` | Resumir opcoes e ajudar a decidir |
|
||||
| `/brainstorm save` | Guardar resultado para usar no /spec |
|
||||
|
||||
---
|
||||
|
||||
## Protocolo Principal
|
||||
|
||||
```
|
||||
1. mcp__mcp-time__current_time
|
||||
2. RECEBER ideia do utilizador:
|
||||
- Se argumento dado: usar como tema
|
||||
- Se nao: "Qual e a ideia que queres explorar?"
|
||||
|
||||
3. FASE 1 - Entender a Ideia
|
||||
a. Repetir a ideia nas proprias palavras:
|
||||
"Se entendo bem, queres [X] para resolver [Y]. Correcto?"
|
||||
b. Perguntar contexto se faltar:
|
||||
- Para quem e? (cliente, interno, produto)
|
||||
- Que problema resolve?
|
||||
- Ha restricoes (tempo, budget, tecnicas)?
|
||||
|
||||
4. FASE 2 - Consultar Especialistas
|
||||
|
||||
**Passo A: NotebookLM (conhecimento curado profundo)**
|
||||
|
||||
Encontrar notebooks relevantes ao tema:
|
||||
```
|
||||
mcp__notebooklm__search_notebooks({
|
||||
query: "[tema palavras-chave]"
|
||||
})
|
||||
```
|
||||
|
||||
Perguntar ao(s) notebook(s) encontrado(s):
|
||||
```
|
||||
mcp__notebooklm__ask_question({
|
||||
question: "Quais sao as melhores abordagens para [tema]? Que boas praticas existem?",
|
||||
notebook_id: "[id do notebook relevante]"
|
||||
})
|
||||
```
|
||||
|
||||
Mapeamento de notebooks a temas:
|
||||
| Tema | Notebooks NotebookLM |
|
||||
|------|---------------------|
|
||||
| CRM/Perfex | perfex-crm-knowledge-base |
|
||||
| Dev/Claude Code | claude-code-advanced-knowledge |
|
||||
| IA/SaaS/Automacao | stack-tecnol-gica-ia-descompli |
|
||||
| Servidores/Hosting | centos-web-panel-cwp-complete |
|
||||
| PKM/Obsidian | obsidian-knowledge-system |
|
||||
| WhatSMS/WhatsApp | whatsms-zender-platform |
|
||||
| E-commerce PT | e-commerce-portugal-estrat-gia |
|
||||
|
||||
REGRA: Consultar 1-2 notebooks relevantes. Se nenhum encaixa, saltar para Dify KB.
|
||||
Apresentar insights como "com base no conhecimento curado sobre [tema]..."
|
||||
|
||||
**Passo B: Dify KB (boas praticas gerais)**
|
||||
|
||||
Escolher 2-3 datasets complementares:
|
||||
| Tema | Datasets Dify KB |
|
||||
|------|---------------------|
|
||||
| Negocio/estrategia | "Estrategia", "Marketing Digital" |
|
||||
| Desenvolvimento | "Desenvolvimento de Software", "Arquitectura" |
|
||||
| Marketing | "Marketing Digital", "SEO", "Content Marketing" |
|
||||
| Gestao | "Gestao de Projetos", "Gestao de Processos" |
|
||||
| Produto | "Product Management", "UX/UI" |
|
||||
| Infraestrutura | "DevOps", "Seguranca" |
|
||||
| E-commerce | "E-commerce", "Marketing Digital" |
|
||||
| Generico | "Estrategia", "Produtividade" |
|
||||
|
||||
Para cada dataset relevante:
|
||||
```
|
||||
mcp__dify-kb__dify_kb_retrieve_segments({
|
||||
dataset: "[nome]",
|
||||
query: "[tema + palavras-chave]"
|
||||
})
|
||||
```
|
||||
|
||||
Apresentar insights como "boas praticas de [dominio] sugerem..."
|
||||
|
||||
**Combinar ambas as fontes** para perspectivas mais ricas.
|
||||
NotebookLM = contexto profundo e especifico. Dify KB = principios gerais e frameworks.
|
||||
|
||||
5. FASE 3 - Explorar Angulos
|
||||
Apresentar a ideia de MULTIPLAS perspectivas:
|
||||
|
||||
### Perspectiva Tecnica
|
||||
- Viabilidade, complexidade, stack
|
||||
- [Insight do dataset de Desenvolvimento/Arquitectura]
|
||||
|
||||
### Perspectiva de Negocio
|
||||
- ROI, valor para cliente, diferenciacao
|
||||
- [Insight do dataset de Estrategia/Marketing]
|
||||
|
||||
### Perspectiva Pratica
|
||||
- Tempo, recursos, dependencias
|
||||
- [Insight do dataset de Gestao]
|
||||
|
||||
### Riscos e Alternativas
|
||||
- O que pode correr mal
|
||||
- Abordagens alternativas
|
||||
- "E se em vez de X, fizessemos Y?"
|
||||
|
||||
6. FASE 4 - Pros e Contras
|
||||
|
||||
| Aspecto | Pro | Contra |
|
||||
|---------|-----|--------|
|
||||
| [aspecto 1] | [vantagem] | [desvantagem] |
|
||||
|
||||
7. FASE 5 - Interaccao
|
||||
"O que ressoa mais? Queres explorar algum angulo em detalhe?"
|
||||
|
||||
ITERAR com o utilizador ate:
|
||||
- A ideia estar clara
|
||||
- As decisoes principais estarem tomadas
|
||||
- O scope estiver delineado
|
||||
|
||||
8. PERGUNTAR: "Pronto para formalizar? Posso criar o /spec com base nesta discussao."
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## `/brainstorm decide`
|
||||
|
||||
Para quando ha multiplas opcoes e o utilizador precisa escolher:
|
||||
|
||||
```
|
||||
1. Listar opcoes identificadas na discussao
|
||||
2. Para cada opcao:
|
||||
- Resumo em 1-2 frases
|
||||
- Score por criterio (tecnico, negocio, pratico)
|
||||
- Recomendacao: "Melhor para [cenario]"
|
||||
3. Consultar datasets para argumentos adicionais
|
||||
4. Apresentar comparacao:
|
||||
|
||||
## Decisao: [tema]
|
||||
|
||||
| Criterio | Opcao A | Opcao B | Opcao C |
|
||||
|----------|---------|---------|------
|
||||
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"task_id": null,
|
||||
"project_id": null,
|
||||
"customer_id": null,
|
||||
"gitea_repo": null
|
||||
}
|
||||
@@ -0,0 +1,164 @@
|
||||
---
|
||||
name: discover
|
||||
description: Pesquisa e discovery de viabilidade, abordagens e estado da arte. Pesquisa NotebookLM, web, codebase e Context7.
|
||||
layer: wiki
|
||||
---
|
||||
|
||||
# /discover v1.2 - Pesquisa e Discovery
|
||||
|
||||
> **NOTA 07-04-2026:** referências a "Dify KB" no corpo desta skill são obsoletas (Dify removido em 06-03-2026). Substituir por NotebookLM ou /knowledge nas próximas iterações. Workflow geral mantém-se válido.
|
||||
|
||||
Investiga antes de opinar. Recolhe factos, abordagens e estado da arte para alimentar o brainstorm.
|
||||
Usa NotebookLM (Gemini 2.5 com RAG sobre conhecimento curado) como fonte primaria de pesquisa interna.
|
||||
|
||||
**Flow:** ideia -> **discover** -> brainstorm -> spec -> sprint -> codigo
|
||||
|
||||
---
|
||||
|
||||
## Comandos
|
||||
|
||||
| Comando | Funcao |
|
||||
|---------|--------|
|
||||
| `/discover` | Pesquisa interactiva sobre tema |
|
||||
| `/discover <tema>` | Pesquisa focada |
|
||||
| `/discover tech <tema>` | Foco em abordagens tecnicas e libraries |
|
||||
| `/discover market <tema>` | Foco em mercado, concorrentes, tendencias |
|
||||
| `/discover internal <tema>` | Foco no que ja temos (codebase, KB, projectos) |
|
||||
| `/discover save` | Guardar findings para brainstorm |
|
||||
|
||||
---
|
||||
|
||||
## Protocolo Principal
|
||||
|
||||
```
|
||||
1. mcp__mcp-time__current_time
|
||||
2. RECEBER tema:
|
||||
- Se argumento dado: usar como query base
|
||||
- Se nao: "O que queres investigar?"
|
||||
|
||||
3. CLARIFICAR objectivo:
|
||||
"Queres saber:"
|
||||
a) Se e viavel tecnicamente?
|
||||
b) Que abordagens/ferramentas existem?
|
||||
c) O que a concorrencia faz?
|
||||
d) O que ja temos que pode ajudar?
|
||||
e) Tudo acima?
|
||||
|
||||
4. FASE 1 - Pesquisa Interna (o que ja sabemos)
|
||||
|
||||
a. NotebookLM - Conhecimento curado profundo (Gemini 2.5 + RAG):
|
||||
PRIMEIRO, encontrar notebooks relevantes:
|
||||
mcp__notebooklm__search_notebooks({
|
||||
query: "[tema palavras-chave]"
|
||||
})
|
||||
|
||||
DEPOIS, perguntar aos notebooks encontrados:
|
||||
mcp__notebooklm__ask_question({
|
||||
question: "[pergunta especifica sobre o tema]",
|
||||
notebook_id: "[id do notebook relevante]"
|
||||
})
|
||||
|
||||
Notebooks disponiveis e quando usar:
|
||||
| Notebook | Temas |
|
||||
|----------|-------|
|
||||
| perfex-crm-knowledge-base | Perfex CRM, modulos, extensoes |
|
||||
| claude-code-advanced-knowledge | Claude Code, MCP, skills, plugins |
|
||||
| stack-tecnol-gica-ia-descompli | Stack IA/SaaS, n8n, CrewAI, SIFIDE |
|
||||
| centos-web-panel-cwp-complete | CWP, servidores, hosting, seguranca |
|
||||
| obsidian-knowledge-system | Obsidian, vault, PKM, bases |
|
||||
| whatsms-zender-platform | WhatSMS, Zender, WhatsApp |
|
||||
| e-commerce-portugal-estrat-gia | E-commerce PT, PMEs, mercado |
|
||||
|
||||
REGRA: Consultar 1-3 notebooks relevantes. Se tema nao encaixa em nenhum, saltar.
|
||||
|
||||
b. Dify KB - Pesquisar em datasets relevantes:
|
||||
mcp__dify-kb__dify_kb_retrieve_segments({
|
||||
dataset: "[relevante]",
|
||||
query: "[tema]"
|
||||
})
|
||||
Repetir para 2-4 datasets que possam ter info.
|
||||
|
||||
c. Codebase local - Procurar implementacoes existentes:
|
||||
Grep/Glob por termos relacionados em:
|
||||
- /media/ealmeida/Dados/Dev/
|
||||
- ~/.claude/plugins/
|
||||
|
||||
d. Memória (Mem0) - Experiencias anteriores:
|
||||
mcp__mem_search_memories({
|
||||
query: "[tema]"
|
||||
})
|
||||
|
||||
e. Projectos Desk - Trabalho anterior relacionado:
|
||||
Se tema se relaciona com projecto existente,
|
||||
verificar tasks e discussoes relevantes.
|
||||
|
||||
5. FASE 2 - Pesquisa Externa (o que o mundo sabe)
|
||||
|
||||
a. Web Search - Estado da arte:
|
||||
WebSearch("[tema] best practices 2026")
|
||||
WebSearch("[tema] alternatives comparison")
|
||||
|
||||
b. Context7 - Documentacao de libraries:
|
||||
SE tema e tecnico:
|
||||
mcp__plugin_context7_context7__resolve-library-id({
|
||||
libraryName: "[library relevante]"
|
||||
})
|
||||
Depois: query-docs para detalhes
|
||||
|
||||
c. WebFetch - Artigos especificos:
|
||||
Se WebSearch encontra artigos relevantes,
|
||||
buscar detalhes com WebFetch.
|
||||
|
||||
6. FASE 3 - Compilar Findings
|
||||
|
||||
---
|
||||
## Discovery: [tema]
|
||||
_Data: YYYY-MM-DD_
|
||||
|
||||
### O Que Ja Temos
|
||||
- [Codigo/skills/MCPs existentes relevantes]
|
||||
- [Experiencias anteriores (memoria)]
|
||||
- [Knowledge base interna]
|
||||
|
||||
### Estado da Arte
|
||||
- [O que o mercado/industria faz]
|
||||
- [Ferramentas e abordagens populares]
|
||||
- [Tendencias 2026]
|
||||
|
||||
### Abordagens Possiveis
|
||||
|
||||
| Abordagem | Descricao | Complexidade | Exemplo |
|
||||
|-----------|-----------|-------------|---------|
|
||||
| A | [desc] | Baixa/Media/Alta | [ref] |
|
||||
| B | [desc] | Baixa/Media/Alta | [ref] |
|
||||
|
||||
### Documentacao Relevante
|
||||
- [Links e refs encontrados]
|
||||
|
||||
### Lacunas
|
||||
- [O que NAO encontrei e precisamos investigar mais]
|
||||
|
||||
### Recomendacao Inicial
|
||||
[Baseada nos factos recolhidos, nao em opiniao]
|
||||
---
|
||||
|
||||
7. PERGUNTAR:
|
||||
"Queres aprofundar algum ponto? Ou avancar para /brainstorm?"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Variantes
|
||||
|
||||
### `/discover tech <tema>`
|
||||
|
||||
Foco tecnico - ignora mercado, concentra-se em:
|
||||
```
|
||||
1. Libraries e frameworks (Context7)
|
||||
2. Padroes de implementacao (WebSearch)
|
||||
3. Codigo existente no projecto (Grep/Glob)
|
||||
4. Benchmarks e comparacoes
|
||||
5. Documentacao oficial
|
||||
```
|
||||
|
||||
### `/dis
|
||||
@@ -0,0 +1,8 @@
|
||||
# skills
|
||||
|
||||
## Documentação
|
||||
|
||||
- [README](README.md)
|
||||
- [AGENTS](AGENTS.md)
|
||||
- [STATUS](STATUS.md)
|
||||
- [MEMORY](MEMORY.md)
|
||||
@@ -0,0 +1 @@
|
||||
## 2026-06-30 init | Estrutura padrão
|
||||
@@ -0,0 +1,114 @@
|
||||
---
|
||||
name: scope
|
||||
description: Validação de scope que verifica se o trabalho está dentro do spec e detecta scope creep.
|
||||
layer: wiki
|
||||
---
|
||||
|
||||
# /scope v1.0 - Validacao de Scope
|
||||
|
||||
Check rapido: "o trabalho que estou a fazer esta dentro do que combinámos?"
|
||||
|
||||
---
|
||||
|
||||
## Comandos
|
||||
|
||||
| Comando | Funcao |
|
||||
|---------|--------|
|
||||
| `/scope` | Check rapido (1-3 linhas) |
|
||||
| `/scope detail` | Analise detalhada com mapeamento ficheiros-scope |
|
||||
|
||||
---
|
||||
|
||||
## Protocolos
|
||||
|
||||
### `/scope` (check rapido)
|
||||
|
||||
```
|
||||
1. Procurar SPEC.md:
|
||||
- Directorio actual, depois pais (max 5 niveis)
|
||||
- Parar em /media/ealmeida/Dados/Dev ou /media/ealmeida/Dados
|
||||
2. SE nao encontrado:
|
||||
"Sem SPEC.md. A trabalhar sem contrato de scope."
|
||||
PARAR.
|
||||
3. SE encontrado mas nao aprovado:
|
||||
"Spec em draft (nao aprovado). Tratando como guia."
|
||||
4. Parse SPEC.md:
|
||||
- Items "Faz" (scope in)
|
||||
- Items "Nao Faz" (scope out)
|
||||
5. Analisar trabalho recente:
|
||||
a. Se git repo:
|
||||
- git diff --stat (uncommitted changes)
|
||||
- git diff --stat HEAD~3..HEAD (ultimos 3 commits)
|
||||
b. Se nao git: ficheiros modificados nas ultimas 2h (via stat)
|
||||
6. Classificar cada ficheiro modificado:
|
||||
- Corresponde a item do scope -> OK
|
||||
- Mencionado em "Nao Faz" -> ALERTA
|
||||
- Nao mencionado -> WARN (potencial creep)
|
||||
7. Output rapido:
|
||||
|
||||
SE tudo OK:
|
||||
"Dentro do spec. X/Y scope items em progresso."
|
||||
|
||||
SE ha alertas:
|
||||
"SCOPE ALERT: [N] ficheiros modificados fora do spec."
|
||||
" - [ficheiro1]: nao mencionado no spec"
|
||||
" - [ficheiro2]: esta em 'Nao Faz'"
|
||||
"Considere /spec update ou criar novo spec."
|
||||
```
|
||||
|
||||
### `/scope detail`
|
||||
|
||||
```
|
||||
1. Executar tudo de /scope
|
||||
2. ADICIONAR mapeamento detalhado:
|
||||
|
||||
---
|
||||
## Scope Detail: [titulo do spec]
|
||||
|
||||
### Mapeamento Scope -> Ficheiros
|
||||
|
||||
| Scope Item | Ficheiros Associados | Status |
|
||||
|-----------|---------------------|--------|
|
||||
| Item 1 | a.php, b.js | Em progresso |
|
||||
| Item 2 | - | Nao iniciado |
|
||||
|
||||
### Ficheiros Fora do Scope
|
||||
|
||||
| Ficheiro | Tipo Alteracao | Possivel Motivo |
|
||||
|----------|---------------|-----------------|
|
||||
| c.css | Modificado | Refactoring nao planeado? |
|
||||
| d.php | Novo | Feature nova? |
|
||||
|
||||
### Criterios de Aceitacao
|
||||
|
||||
| Criterio | Verificavel? | Estado |
|
||||
|----------|-------------|--------|
|
||||
| DADO X QUANDO Y ENTAO Z | Sim | Pendente |
|
||||
|
||||
### Recomendacao
|
||||
- [O que fazer com o trabalho fora do scope]
|
||||
- [Criar novo spec? Actualizar existente? Reverter?]
|
||||
---
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Regras
|
||||
|
||||
1. `/scope` deve ser RAPIDO (segundos, nao minutos)
|
||||
2. Nao modificar nenhum ficheiro - apenas leitura e analise
|
||||
3. Ser factual - reportar o que ve, nao julgar
|
||||
4. Scope creep nao e mau por si - e mau quando nao e detectado
|
||||
5. Sugerir solucoes (update spec, criar novo) nao apenas reportar problemas
|
||||
|
||||
---
|
||||
|
||||
## Healing Log
|
||||
|
||||
Registo de erros conhecidos e como evitá-los. Lido automaticamente antes de executar.
|
||||
|
||||
```jsonl
|
||||
{"date":"","issue":"","fix":"","source":"user|auto"}
|
||||
```
|
||||
|
||||
*Adicionar nova linha após cada erro corrigido.*
|
||||
@@ -0,0 +1,245 @@
|
||||
---
|
||||
name: spec
|
||||
description: Spec-driven development — cria e gere SPEC.md como contrato entre utilizador e Claude. Suporta 3 pesos (light/medium/heavy).
|
||||
disable-model-invocation: true
|
||||
layer: wiki
|
||||
---
|
||||
|
||||
# /spec v1.0 - Spec-Driven Development
|
||||
|
||||
Contrato bilateral: forca o Emanuel a definir o que quer e forca o Claude a provar que entendeu.
|
||||
|
||||
**Sem spec aprovado, sem codigo.**
|
||||
|
||||
## Contexto NotebookLM
|
||||
|
||||
ANTES de executar, consultar notebooks para contexto especializado:
|
||||
|
||||
| Notebook | ID | Consultar quando |
|
||||
|----------|-----|-----------------|
|
||||
| Gestão de Projectos e Agile | 0c9c079c-a426-486c-99eb-1564d42d37ad | Sempre |
|
||||
|
||||
```
|
||||
mcp__notebooklm__notebook_query({
|
||||
notebook_id: "0c9c079c-a426-486c-99eb-1564d42d37ad",
|
||||
query: "<adaptar ao contexto do pedido do utilizador>"
|
||||
})
|
||||
```
|
||||
|
||||
Integrar insights do NotebookLM nas recomendações e decisões.
|
||||
|
||||
---
|
||||
|
||||
## Comandos
|
||||
|
||||
| Comando | Funcao |
|
||||
|---------|--------|
|
||||
| `/spec` | Mostrar spec actual ou guiar criacao |
|
||||
| `/spec create` | Criar SPEC.md a partir de conversa |
|
||||
| `/spec create light` | Spec minimo (<2h) |
|
||||
| `/spec create heavy` | Spec completo com milestones e riscos |
|
||||
| `/spec approve` | Marcar como aprovado (so Emanuel) |
|
||||
| `/spec update` | Alterar spec (track amendments se aprovado) |
|
||||
| `/spec check` | Validar trabalho actual vs spec |
|
||||
| `/spec review` | Mover draft -> review |
|
||||
| `/spec bypass` | Criar bypass temporario (30min) para quick fixes |
|
||||
|
||||
---
|
||||
|
||||
## Pesos
|
||||
|
||||
| Peso | Quando | Seccoes |
|
||||
|------|--------|---------|
|
||||
| **light** | Quick fix, tarefa simples, <2h | Problema, Solucao, Scope |
|
||||
| **medium** | Feature, modulo, 2-8h | + Criterios de Aceitacao, Decisoes |
|
||||
| **heavy** | Projecto novo, >8h | + Milestones, Riscos, Dependencias |
|
||||
|
||||
**Auto-deteccao de peso:**
|
||||
- Conversa com <3 frases de requisitos -> light
|
||||
- Feature especifica com decisoes tecnicas -> medium
|
||||
- Projecto novo / multiplos componentes -> heavy
|
||||
- O utilizador pode sempre forcar o peso
|
||||
|
||||
---
|
||||
|
||||
## Template SPEC.md
|
||||
|
||||
### Light
|
||||
|
||||
```markdown
|
||||
---
|
||||
spec_version: 1.0
|
||||
weight: light
|
||||
status: draft
|
||||
created: YYYY-MM-DD
|
||||
updated: YYYY-MM-DD
|
||||
approved: null
|
||||
desk_project: null
|
||||
desk_task: null
|
||||
---
|
||||
|
||||
# SPEC: [Titulo]
|
||||
|
||||
## Problema
|
||||
[O que esta mal ou falta]
|
||||
|
||||
## Solucao
|
||||
[O que se vai fazer]
|
||||
|
||||
## Scope
|
||||
### Faz
|
||||
- [ ] Item 1
|
||||
- [ ] Item 2
|
||||
|
||||
### Nao Faz
|
||||
- [Item excluido]
|
||||
```
|
||||
|
||||
### Medium (default)
|
||||
|
||||
```markdown
|
||||
---
|
||||
spec_version: 1.0
|
||||
weight: medium
|
||||
status: draft
|
||||
created: YYYY-MM-DD
|
||||
updated: YYYY-MM-DD
|
||||
approved: null
|
||||
desk_project: null
|
||||
desk_task: null
|
||||
sprint: null
|
||||
scope_changes: 0
|
||||
---
|
||||
|
||||
# SPEC: [Titulo]
|
||||
|
||||
## Problema
|
||||
[O que esta mal ou falta. Nas palavras do utilizador.]
|
||||
|
||||
## Solucao
|
||||
[O que se vai fazer. Abordagem escolhida e porque.]
|
||||
|
||||
## Scope
|
||||
|
||||
### Faz
|
||||
- [ ] Item 1
|
||||
- [ ] Item 2
|
||||
|
||||
### Nao Faz
|
||||
- Item excluido 1
|
||||
|
||||
## Criterios de Aceitacao
|
||||
1. DADO [contexto] QUANDO [accao] ENTAO [resultado]
|
||||
2. ...
|
||||
|
||||
## Decisoes Tecnicas
|
||||
|
||||
| Decisao | Razao |
|
||||
|---------|-------|
|
||||
| [Escolha] | [Porque] |
|
||||
|
||||
<!-- APPROVED: YYYY-MM-DD by [nome] -->
|
||||
```
|
||||
|
||||
### Heavy
|
||||
|
||||
```markdown
|
||||
---
|
||||
spec_version: 1.0
|
||||
weight: heavy
|
||||
status: draft
|
||||
created: YYYY-MM-DD
|
||||
updated: YYYY-MM-DD
|
||||
approved: null
|
||||
desk_project: null
|
||||
desk_task: null
|
||||
sprint: null
|
||||
scope_changes: 0
|
||||
---
|
||||
|
||||
# SPEC: [Titulo]
|
||||
|
||||
## Problema
|
||||
[Contexto completo do problema]
|
||||
|
||||
## Solucao
|
||||
[Abordagem detalhada]
|
||||
|
||||
## Scope
|
||||
|
||||
### Faz
|
||||
- [ ] Item 1
|
||||
- [ ] Item 2
|
||||
|
||||
### Nao Faz
|
||||
- Item excluido 1
|
||||
|
||||
## Criterios de Aceitacao
|
||||
1. DADO [contexto] QUANDO [accao] ENTAO [resultado]
|
||||
2. ...
|
||||
|
||||
## Decisoes Tecnicas
|
||||
|
||||
| Decisao | Razao |
|
||||
|---------|-------|
|
||||
| [Escolha] | [Porque] |
|
||||
|
||||
## Milestones
|
||||
|
||||
| # | Milestone | Data | Criterio |
|
||||
|---|-----------|------|----------|
|
||||
| M1 | [Nome] | [Data] | [Como saber que esta feito] |
|
||||
|
||||
## Riscos
|
||||
|
||||
| Risco | Probabilidade | Impacto | Mitigacao |
|
||||
|-------|--------------|---------|-----------|
|
||||
| [Risco] | Alta/Media/Baixa | Alto/Medio/Baixo | [Plano] |
|
||||
|
||||
## Dependencias
|
||||
- [Dependencia externa 1]
|
||||
- [Componente que precisa estar pronto primeiro]
|
||||
|
||||
## Alteracoes (pos-aprovacao)
|
||||
### [DATA] - [Descricao]
|
||||
- Adicionado: X
|
||||
- Removido: Y
|
||||
- Razao: Z
|
||||
|
||||
<!-- APPROVED: YYYY-MM-DD by [nome] -->
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Protocolos
|
||||
|
||||
### `/spec` (sem argumentos)
|
||||
|
||||
```
|
||||
1. Procurar SPEC.md no directorio actual (ou pais, max 3 niveis)
|
||||
2. SE encontrado:
|
||||
a. Ler e mostrar resumo:
|
||||
- Titulo, peso, status
|
||||
- Scope: X/Y items feitos
|
||||
- Aprovacao: sim/nao (data)
|
||||
b. Sugerir accoes: approve, check, update
|
||||
3. SE nao encontrado:
|
||||
a. "Nenhum spec encontrado nesta pasta."
|
||||
b. "Quer criar um? Descreva o que precisa ou use /spec create."
|
||||
```
|
||||
|
||||
### `/spec create` [weight]
|
||||
|
||||
```
|
||||
1. mcp__mcp-time__current_time -> data actual
|
||||
2. Verificar se SPEC.md ja existe
|
||||
- Se existe e status != completed:
|
||||
"Ja existe um spec activo. Usar /spec update ou apagar o existente?"
|
||||
PARAR e esperar resposta.
|
||||
3. Detectar contexto do projecto:
|
||||
a. Ler .desk-project se existe -> project_id, project_name, desk_task
|
||||
b. Se nao existe: "Em que projecto estamos? (ou 'novo')"
|
||||
4. Determinar peso:
|
||||
a. Se argumento dado (light/medium/heavy): usar esse
|
||||
b. Se nao: analisar conversa anterior
|
||||
|
||||
@@ -0,0 +1,188 @@
|
||||
---
|
||||
name: sprint
|
||||
description: Sprints flexíveis que lêem tasks do Desk CRM, agrupam em sprints com checkpoints e reviews.
|
||||
disable-model-invocation: true
|
||||
layer: wiki
|
||||
---
|
||||
|
||||
# /sprint v1.0 - Sprints Flexiveis
|
||||
|
||||
Sprints com duracao flexivel, Desk CRM como fonte de verdade, checkpoints obrigatorios.
|
||||
|
||||
## Contexto NotebookLM
|
||||
|
||||
ANTES de executar, consultar notebooks para contexto especializado:
|
||||
|
||||
| Notebook | ID | Consultar quando |
|
||||
|----------|-----|-----------------|
|
||||
| Gestão de Projectos e Agile | 0c9c079c-a426-486c-99eb-1564d42d37ad | Sempre |
|
||||
|
||||
```
|
||||
mcp__notebooklm__notebook_query({
|
||||
notebook_id: "0c9c079c-a426-486c-99eb-1564d42d37ad",
|
||||
query: "<adaptar ao contexto do pedido do utilizador>"
|
||||
})
|
||||
```
|
||||
|
||||
Integrar insights do NotebookLM nas recomendações e decisões.
|
||||
|
||||
---
|
||||
|
||||
## Comandos
|
||||
|
||||
| Comando | Funcao |
|
||||
|---------|--------|
|
||||
| `/sprint` | Mostrar sprint activo |
|
||||
| `/sprint plan` | Criar sprint a partir de tasks Desk |
|
||||
| `/sprint check-in` | Checkpoint a meio do sprint |
|
||||
| `/sprint review` | Review final do sprint |
|
||||
| `/sprint close` | Fechar sprint e calcular metricas |
|
||||
| `/sprint add <task_id>` | Adicionar task ao sprint activo |
|
||||
| `/sprint remove <task_id>` | Remover task do sprint |
|
||||
|
||||
---
|
||||
|
||||
## SPRINT.md Template
|
||||
|
||||
```markdown
|
||||
---
|
||||
sprint_id: YYYY-WNN-[projecto]
|
||||
project_id: null
|
||||
start_date: YYYY-MM-DD
|
||||
end_date: YYYY-MM-DD
|
||||
status: active
|
||||
checkpoint_done: false
|
||||
spec_refs: []
|
||||
tasks_planned: 0
|
||||
tasks_added_after: 0
|
||||
---
|
||||
|
||||
# Sprint: [Goal em 1 frase]
|
||||
|
||||
## Tasks
|
||||
|
||||
| Desk ID | Task | Prioridade | Estimativa | Status | Tempo Real |
|
||||
|---------|------|-----------|-----------|--------|-----------|
|
||||
|
||||
## Checkpoint (Meio do Sprint)
|
||||
_Data: [a preencher]_
|
||||
- On track: [sim/nao]
|
||||
- Bloqueios: [lista]
|
||||
- Scope changes: [lista]
|
||||
- Accao: [continuar/ajustar]
|
||||
|
||||
## Review (Final do Sprint)
|
||||
_Data: [a preencher]_
|
||||
- Tasks completadas: X/Y
|
||||
- Tasks adicionadas pos-planeamento: N
|
||||
- Tempo estimado: Xh
|
||||
- Tempo real: Yh
|
||||
- Scope changes: N
|
||||
- Licoes aprendidas: [lista]
|
||||
- Proximos passos: [lista]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Protocolos
|
||||
|
||||
### `/sprint` (sem argumentos)
|
||||
|
||||
```
|
||||
1. Procurar SPRINT.md no directorio actual (ou pais, max 3 niveis)
|
||||
2. SE encontrado e status == active:
|
||||
a. Ler SPRINT.md
|
||||
b. Buscar estado actual das tasks no Desk CRM:
|
||||
Para cada task_id na tabela:
|
||||
mcp__desk-crm-v3__get_task({ id: task_id })
|
||||
c. Mostrar:
|
||||
---
|
||||
## Sprint Activo: [goal]
|
||||
**Projecto:** [nome] (#id)
|
||||
**Periodo:** [start] -> [end] (dia X de Y)
|
||||
**Checkpoint:** [feito/pendente]
|
||||
|
||||
| Task | Status Desk | Sprint |
|
||||
|------|------------|--------|
|
||||
|
||||
**Progresso:** X/Y tasks (Z%)
|
||||
---
|
||||
3. SE nao encontrado:
|
||||
"Sem sprint activo. Usar /sprint plan para criar."
|
||||
```
|
||||
|
||||
### `/sprint plan`
|
||||
|
||||
```
|
||||
1. mcp__mcp-time__current_time -> data actual
|
||||
2. Detectar contexto:
|
||||
a. Ler .desk-project se existe -> project_id
|
||||
b. Se nao: perguntar projecto
|
||||
3. Buscar tasks abertas do Desk CRM:
|
||||
mcp__desk-crm-v3__get_tasks({ project_id: X, status: [1, 4] })
|
||||
(status 1=Not Started, 4=In Progress)
|
||||
4. Verificar SPEC.md:
|
||||
- Se existe e aprovado: incluir referencia no sprint
|
||||
- Se nao existe: WARN "Sem spec aprovado. Considere /spec create."
|
||||
- Nao bloquear por isto (gradual adoption)
|
||||
5. Apresentar tasks ao Emanuel por prioridade:
|
||||
|
||||
## Tasks Disponiveis para Sprint
|
||||
|
||||
### Urgente / Alta
|
||||
- #1450: Implement API (4h estimado)
|
||||
- #1451: Fix login bug (1h estimado)
|
||||
|
||||
### Normal
|
||||
- #1448: Write docs (2h estimado)
|
||||
|
||||
### Baixa
|
||||
- #1452: Refactor CSS (3h estimado)
|
||||
|
||||
6. Perguntar:
|
||||
"Que tasks incluir neste sprint? E data limite?"
|
||||
(pode ser: "todas as urgentes", "#1450 e #1448", etc.)
|
||||
7. Calcular estimativa total
|
||||
8. GERAR SPRINT.md:
|
||||
- sprint_id: YYYY-WNN-[projecto] (semana ISO actual)
|
||||
- tasks_planned: contagem
|
||||
- Preencher tabela de tasks
|
||||
9. CONFIRMAR: "Sprint com [N] tasks, ~[X]h, ate [data]. Criar?"
|
||||
10. Gravar SPRINT.md
|
||||
11. Guardar em mem0:
|
||||
save_memory({
|
||||
content: "Sprint [id] iniciado: [N] tasks, [X]h, ate [data]",
|
||||
tags: ["sprint", "project-[id]", sprint_id]
|
||||
})
|
||||
12. "Sprint criado. Check-in recomendado em [data_meio]."
|
||||
```
|
||||
|
||||
### `/sprint check-in`
|
||||
|
||||
```
|
||||
1. Ler SPRINT.md
|
||||
- Se nao existe ou status != active: "Sem sprint activo."
|
||||
2. Se checkpoint_done == true:
|
||||
"Checkpoint ja realizado. Para novo check-in, usar /sprint review."
|
||||
3. mcp__mcp-time__current_time -> calcular dia actual vs periodo
|
||||
4. Para cada task do sprint:
|
||||
mcp__desk-crm-v3__get_task({ id: task_id })
|
||||
- Comparar status actual vs planeado
|
||||
5. Calcular:
|
||||
- % tempo decorrido
|
||||
- % tasks completadas
|
||||
- Tasks adicionadas apos planeamento (comparar com tasks_planned)
|
||||
6. Detectar alertas:
|
||||
- >50% tempo decorrido mas <40% tasks feitas -> "ATRASADO"
|
||||
- Tasks novas adicionadas -> "SCOPE CREEP: [N] tasks nao planeadas"
|
||||
- Tasks bloqueadas -> "BLOQUEIO: [task]"
|
||||
7. Apresentar:
|
||||
---
|
||||
## Checkpoint Sprint [id]
|
||||
|
||||
**Progresso:** X/Y tasks (Z%)
|
||||
**Tempo:** dia M de N (W% decorrido)
|
||||
**Alerta:** [verde/amarelo/vermelho]
|
||||
|
||||
### Tasks
|
||||
| Task | Planeado | A
|
||||
@@ -0,0 +1,142 @@
|
||||
---
|
||||
name: status
|
||||
description: Dashboard de projecto que agrega spec, sprint, desk, git e timer numa única vista.
|
||||
layer: wiki
|
||||
---
|
||||
|
||||
# /status v1.0 - Dashboard de Projecto
|
||||
|
||||
Agrega todas as fontes num unico painel: SPEC.md + SPRINT.md + Desk CRM + git + timer.
|
||||
|
||||
---
|
||||
|
||||
## Comandos
|
||||
|
||||
| Comando | Funcao |
|
||||
|---------|--------|
|
||||
| `/status` | Status completo do projecto actual |
|
||||
| `/status quick` | Resumo em 1-2 linhas |
|
||||
| `/status all` | Status de todos os projectos activos |
|
||||
|
||||
---
|
||||
|
||||
## Protocolos
|
||||
|
||||
### `/status`
|
||||
|
||||
```
|
||||
1. mcp__mcp-time__current_time
|
||||
2. Detectar contexto:
|
||||
a. Ler .desk-project se existe -> project_id, project_name
|
||||
b. Se nao: usar directorio actual como contexto
|
||||
3. RECOLHER em paralelo:
|
||||
a. SPEC: Ler SPEC.md (status, peso, scope items, aprovacao)
|
||||
b. SPRINT: Ler SPRINT.md (progresso, checkpoint, periodo)
|
||||
c. DESK: mcp__desk-crm-v3__get_tasks({ project_id, status: [1,2,4,5] })
|
||||
d. TIMER: Ler ~/.claude-work/active-timer.json
|
||||
e. GIT: git log --oneline -5 && git status --short (se git repo)
|
||||
4. COMPOR dashboard:
|
||||
|
||||
---
|
||||
## Projecto: [nome] (#id)
|
||||
|
||||
### Spec
|
||||
[Se existe:]
|
||||
- **Status:** [draft/approved/in_progress/amended]
|
||||
- **Titulo:** [titulo]
|
||||
- **Progresso:** X/Y scope items
|
||||
- **Amendments:** N alteracoes pos-aprovacao
|
||||
[Se nao existe:]
|
||||
- **Sem spec.** Considere `/spec create`
|
||||
|
||||
### Sprint
|
||||
[Se activo:]
|
||||
- **Sprint:** [id] | [start] -> [end]
|
||||
- **Tasks:** X/Y completadas (Z%)
|
||||
- **Checkpoint:** [feito em DATA / pendente]
|
||||
[Se nao activo:]
|
||||
- **Sem sprint activo.** Use `/sprint plan`
|
||||
|
||||
### Desk CRM
|
||||
- **Tasks abertas:** N (U urgentes, H alta prioridade)
|
||||
- **Tasks bloqueadas:** N
|
||||
- **Tempo esta semana:** Xh
|
||||
|
||||
### Timer
|
||||
[Se activo:]
|
||||
- **Timer:** #[task_id] - [nome] (Xh Xm)
|
||||
[Se nao:]
|
||||
- **Sem timer activo**
|
||||
|
||||
### Git
|
||||
[Se repo:]
|
||||
- **Ultimos commits:** N (7 dias)
|
||||
- **Changes nao committed:** N ficheiros
|
||||
[Se nao repo:]
|
||||
- **Sem repositorio git**
|
||||
|
||||
### Bloqueios
|
||||
- [bloqueio 1]
|
||||
- [Nenhum detectado]
|
||||
---
|
||||
```
|
||||
|
||||
### `/status quick`
|
||||
|
||||
```
|
||||
1. Mesma recolha mas output compacto:
|
||||
|
||||
[nome] (#id) | Spec: [status] | Sprint: [X/Y tasks] | Desk: [N open] | Timer: [activo/off]
|
||||
|
||||
Exemplo:
|
||||
"Stack (#65) | Spec: approved (3/5) | Sprint W06: 2/4 tasks | Desk: 8 open | Timer: off"
|
||||
```
|
||||
|
||||
### `/status all`
|
||||
|
||||
```
|
||||
1. Encontrar todos os .desk-project:
|
||||
Glob: /media/ealmeida/Dados/Dev/**/.desk-project
|
||||
2. Para cada projecto encontrado:
|
||||
a. Ler .desk-project -> project_id, project_name
|
||||
b. Quick fetch Desk: mcp__desk-crm-v3__get_tasks({ project_id, status: [1,4] })
|
||||
c. Verificar existencia de SPEC.md e SPRINT.md
|
||||
3. Compilar tabela:
|
||||
|
||||
---
|
||||
## Projectos Activos
|
||||
|
||||
| Projecto | Spec | Sprint | Tasks Abertas | Bloqueios |
|
||||
|----------|------|--------|--------------|-----------|
|
||||
| Stack (#65) | approved | W06 (2/4) | 8 | 0 |
|
||||
| SFV (#80) | draft | - | 12 | 2 |
|
||||
| Hub (#90) | - | - | 3 | 0 |
|
||||
|
||||
**Total:** N projectos, M tasks abertas, K bloqueios
|
||||
---
|
||||
|
||||
NOTA: /status all pode demorar ~30s por projecto.
|
||||
Limitar a projectos com .desk-project (nao todos os do Desk CRM).
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Regras
|
||||
|
||||
1. **NUNCA** modificar dados - apenas leitura
|
||||
2. Dados em falta = mostrar sugestao (nao esconder)
|
||||
3. Bloqueios devem saltar a vista (primeiro destaque)
|
||||
4. Se falhar alguma fonte (MCP offline): mostrar as restantes com nota
|
||||
5. `/status quick` para uso em `/today`; `/status` para analise
|
||||
|
||||
---
|
||||
|
||||
## Healing Log
|
||||
|
||||
Registo de erros conhecidos e como evitá-los. Lido automaticamente antes de executar.
|
||||
|
||||
```jsonl
|
||||
{"date":"","issue":"","fix":"","source":"user|auto"}
|
||||
```
|
||||
|
||||
*Adicionar nova linha após cada erro corrigido.*
|
||||
Reference in New Issue
Block a user