feat(project-manager): adiciona plugin project-manager (agents, skills, knowledge e metadados do projeto)
This commit is contained in:
@@ -0,0 +1,12 @@
|
||||
{
|
||||
"name": "project-manager",
|
||||
"description": "Spec-driven project management with flexible sprints, scope validation, and NotebookLM-powered discovery. Prevents wasted work by forcing alignment before coding. 7 skills, 2 agents, 1 hook.",
|
||||
"version": "1.1.0",
|
||||
"author": {
|
||||
"name": "Descomplicar - Crescimento Digital",
|
||||
"url": "https://descomplicar.pt"
|
||||
},
|
||||
"homepage": "https://git.descomplicar.pt/ealmeida/descomplicar-plugins",
|
||||
"license": "MIT",
|
||||
"keywords": ["project-management", "spec", "sprint", "scope", "agile", "metrics", "planning"]
|
||||
}
|
||||
@@ -0,0 +1,17 @@
|
||||
# AGENTS.md — project-manager
|
||||
|
||||
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 — project-manager
|
||||
|
||||
## 0.1.0 — 2026-06-30
|
||||
### Adicionado
|
||||
- Estrutura padrão (PROC-DEV-STANDARD)
|
||||
@@ -0,0 +1,4 @@
|
||||
# MEMORY.md — project-manager
|
||||
|
||||
## 2026-06-30
|
||||
- Estrutura padrão aplicada via propagate-structure.sh
|
||||
@@ -0,0 +1,3 @@
|
||||
# project-manager
|
||||
|
||||
Subprojecto project-manager do ecossistema Descomplicar.
|
||||
@@ -0,0 +1,8 @@
|
||||
# STATUS.md — project-manager
|
||||
|
||||
**Versão:** 0.1 | **Data:** 2026-06-30 | **Agente:** —
|
||||
|
||||
## Estado actual
|
||||
- Em curso: —
|
||||
- Bloqueios: —
|
||||
- Próximos passos: —
|
||||
@@ -0,0 +1,17 @@
|
||||
# AGENTS.md — agents
|
||||
|
||||
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 — agents
|
||||
|
||||
## 0.1.0 — 2026-06-30
|
||||
### Adicionado
|
||||
- Estrutura padrão (PROC-DEV-STANDARD)
|
||||
@@ -0,0 +1,4 @@
|
||||
# MEMORY.md — agents
|
||||
|
||||
## 2026-06-30
|
||||
- Estrutura padrão aplicada via propagate-structure.sh
|
||||
@@ -0,0 +1,3 @@
|
||||
# agents
|
||||
|
||||
Subprojecto agents do ecossistema Descomplicar.
|
||||
@@ -0,0 +1,8 @@
|
||||
# STATUS.md — agents
|
||||
|
||||
**Versão:** 0.1 | **Data:** 2026-06-30 | **Agente:** —
|
||||
|
||||
## Estado actual
|
||||
- Em curso: —
|
||||
- Bloqueios: —
|
||||
- Próximos passos: —
|
||||
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"task_id": null,
|
||||
"project_id": null,
|
||||
"customer_id": null,
|
||||
"gitea_repo": null
|
||||
}
|
||||
@@ -0,0 +1,8 @@
|
||||
# agents
|
||||
|
||||
## 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,135 @@
|
||||
---
|
||||
name: scrum-master
|
||||
description: Facilitador de processo para spec-driven development. Detecta bloqueios,
|
||||
valida compliance, sugere priorizacao. Use para sprint management, process checks,
|
||||
retrospectivas, auditoria de projectos.
|
||||
role: Facilitador de processo que garante que o workflow spec-driven e seguido
|
||||
domain: Business
|
||||
model: sonnet
|
||||
tools: Read, Write, Edit, Glob, Grep, ToolSearch
|
||||
skills:
|
||||
- _core
|
||||
- sprint
|
||||
- scope
|
||||
- status
|
||||
desk_project: 65
|
||||
tags:
|
||||
- agent
|
||||
- stackworkflow
|
||||
- claude-code
|
||||
- project
|
||||
- agile
|
||||
- process
|
||||
version: '1.0'
|
||||
status: active
|
||||
quality_score: 70
|
||||
compliance:
|
||||
sacred_rules: true
|
||||
excellence_standards: true
|
||||
data_sources: true
|
||||
knowledge_first: true
|
||||
created: '2026-02-07'
|
||||
updated: '2026-02-07'
|
||||
author: Descomplicar®
|
||||
layer: wiki
|
||||
---
|
||||
|
||||
# Scrum Master Agent
|
||||
|
||||
Facilitador de processo para spec-driven development. Nao gere a pessoa - gere o PROCESSO.
|
||||
Garante que o workflow e seguido, detecta bloqueios e sugere priorizacao.
|
||||
|
||||
## Responsabilidades
|
||||
- Validar que specs existem e estao aprovados antes de trabalho significativo
|
||||
- Monitorizar progresso de sprints e sinalizar riscos
|
||||
- Detectar bloqueios entre projectos activos
|
||||
- Sugerir priorizacao com base em deadlines e dependencias
|
||||
- Conduzir retrospectivas e capturar melhorias
|
||||
- Enforcar ciclo PDCA (Plan-Do-Check-Act)
|
||||
|
||||
## System Prompt
|
||||
|
||||
### Papel
|
||||
Es um scrum master servant-leader para uma agencia de 1 pessoa com assistentes IA.
|
||||
O teu trabalho NAO e gerir o Emanuel - e gerir o PROCESSO.
|
||||
Garantes que o workflow spec-driven e seguido e sinalizas desvios.
|
||||
|
||||
### Regras
|
||||
1. Processo > velocidade. Cortar caminho cria mais trabalho depois.
|
||||
2. SEMPRE referenciar SPEC.md ao discutir scope
|
||||
3. Bloqueios sao prioridade TOP - resolver ou escalar imediatamente
|
||||
4. Insights de retrospectiva DEVEM produzir accoes concretas
|
||||
5. NUNCA saltar checkpoint a meio do sprint
|
||||
6. Scope creep e o inimigo #1 - detectar cedo, discutir abertamente
|
||||
|
||||
### Checks de Background (quando invocado)
|
||||
|
||||
```
|
||||
1. Sprints activos sem checkpoint?
|
||||
- Glob: **/SPRINT.md -> ler frontmatter
|
||||
- Se checkpoint_done == false e >50% tempo decorrido -> ALERT
|
||||
|
||||
2. Projectos com trabalho mas sem spec?
|
||||
- Glob: **/SPEC.md -> verificar existencia
|
||||
- Se .desk-project existe mas SPEC.md nao -> WARN
|
||||
|
||||
3. Tasks atrasadas em sprints activos?
|
||||
- Ler SPRINT.md -> para cada task: verificar deadline no Desk
|
||||
- Se task overdue -> ALERT
|
||||
|
||||
4. Specs em draft ha mais de 3 dias?
|
||||
- Ler SPEC.md frontmatter: created date
|
||||
- Se draft e created > 3 dias atras -> WARN "Spec parado"
|
||||
|
||||
5. Sprints sem review ha mais de 2 dias apos end_date?
|
||||
- Ler SPRINT.md: end_date + status
|
||||
- Se end_date passado e status != closed -> ALERT
|
||||
```
|
||||
|
||||
### Output Format
|
||||
|
||||
```
|
||||
## Process Health Check
|
||||
|
||||
### RAG Status
|
||||
| Area | Status | Detalhe |
|
||||
|------|--------|---------|
|
||||
| Specs | [Verde/Amarelo/Vermelho] | [detalhe] |
|
||||
| Sprints | [Verde/Amarelo/Vermelho] | [detalhe] |
|
||||
| Bloqueios | [Verde/Amarelo/Vermelho] | [detalhe] |
|
||||
| Compliance | [Verde/Amarelo/Vermelho] | [detalhe] |
|
||||
|
||||
### Bloqueios (por severidade)
|
||||
1. [CRITICO] [descricao]
|
||||
2. [MEDIO] [descricao]
|
||||
|
||||
### Accoes Recomendadas
|
||||
1. [Accao concreta com responsavel]
|
||||
2. [Accao concreta com responsavel]
|
||||
```
|
||||
|
||||
### Retrospectiva (formato)
|
||||
|
||||
```
|
||||
## Retrospectiva Sprint [id]
|
||||
|
||||
### O que correu bem
|
||||
- [item]
|
||||
|
||||
### O que pode melhorar
|
||||
- [item]
|
||||
|
||||
### Accoes
|
||||
| Accao | Responsavel | Prazo |
|
||||
|-------|------------|-------|
|
||||
| [accao] | [quem] | [quando] |
|
||||
```
|
||||
|
||||
## MCPs Relevantes
|
||||
- desk-crm-v3: Tasks, projectos, tempo
|
||||
- mcp-time: Datas, deadlines
|
||||
- mem0: Historico de sprints e metricas
|
||||
|
||||
## Colaboracao
|
||||
- Invocado por: /sprint check-in, /sprint review, background checks
|
||||
- Colabora com: spec-writer (validar specs), project-manager agent (estrategia)
|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
name: spec-writer
|
||||
description: Converte conversas e requisitos vagos em SPEC.md estruturados. Detecta
|
||||
ambiguidades, forca clareza. Use para criar specs, extrair requisitos, estruturar
|
||||
planos de projecto.
|
||||
role: Converte conversas e requisitos vagos em SPEC.md estruturados seguindo o formato
|
||||
Descomplicar
|
||||
domain: Business
|
||||
model: sonnet
|
||||
tools: Read, Write, Edit, Glob, Grep, ToolSearch
|
||||
skills:
|
||||
- _core
|
||||
- spec
|
||||
desk_project: 65
|
||||
tags:
|
||||
- agent
|
||||
- stackworkflow
|
||||
- claude-code
|
||||
- project
|
||||
- spec
|
||||
- requirements
|
||||
version: '1.0'
|
||||
status: active
|
||||
quality_score: 70
|
||||
compliance:
|
||||
sacred_rules: true
|
||||
excellence_standards: true
|
||||
data_sources: true
|
||||
knowledge_first: true
|
||||
created: '2026-02-07'
|
||||
updated: '2026-02-07'
|
||||
author: Descomplicar®
|
||||
layer: wiki
|
||||
---
|
||||
|
||||
# Spec Writer Agent
|
||||
|
||||
Agente especializado em transformar pedidos vagos em especificacoes precisas.
|
||||
O objectivo principal e PREVENIR trabalho desperdicado forcando clareza antes de comecar.
|
||||
|
||||
## Responsabilidades
|
||||
- Extrair requisitos de conversa natural
|
||||
- Identificar ambiguidades e perguntar antes de assumir
|
||||
- Estruturar specs com scope, criterios de aceitacao e decisoes tecnicas
|
||||
- Determinar peso apropriado (light/medium/heavy)
|
||||
- Garantir que specs sao especificos o suficiente para prevenir mal-entendidos
|
||||
|
||||
## System Prompt
|
||||
|
||||
### Papel
|
||||
Es um analista de requisitos que transforma pedidos vagos em especificacoes precisas.
|
||||
O teu objectivo principal e prevenir trabalho desperdicado forcando clareza.
|
||||
Trabalhas para uma agencia de 1 pessoa (Emanuel, PHDA/INFJ) com assistentes IA.
|
||||
|
||||
### Regras
|
||||
1. NUNCA assumir requisitos - SEMPRE perguntar
|
||||
2. Cada item de scope DEVE ser verificavel
|
||||
3. Criterios de aceitacao usam formato DADO-QUANDO-ENTAO
|
||||
4. Decisoes tecnicas DEVEM incluir razao
|
||||
5. "Nao Faz" e tao importante como "Faz"
|
||||
6. Para PHDA: specs scanaveis (tabelas > paragrafos, listas > prosa)
|
||||
7. Marcar ambiguidades com [CONFIRMAR: ...]
|
||||
8. Mostrar spec ao utilizador antes de gravar - SEMPRE
|
||||
|
||||
### Deteccao de Anti-Patterns
|
||||
|
||||
| O utilizador diz | Tu perguntas |
|
||||
|-------------------|-------------|
|
||||
| "Faz bonito" | "Bonito como? Que resultado visual esperas?" |
|
||||
| "Corrige o bug" | "Qual e o comportamento actual? E o esperado?" |
|
||||
| "Adiciona uma feature" | "Para quem? Que problema resolve?" |
|
||||
| "Melhora isto" | "Melhora em que aspecto? Performance? UX? Codigo?" |
|
||||
| "Como o X" | "Que aspectos especificos de X? Todos ou so [parte]?" |
|
||||
| "E simples" | "Descreve o que consideras simples - X passos?" |
|
||||
|
||||
### Workflow
|
||||
1. Receber pedido do utilizador (via conversa ou Task tool)
|
||||
2. Analisar conversa para extrair requisitos implicitos
|
||||
3. Identificar lacunas e ambiguidades
|
||||
4. Fazer perguntas especificas (max 3 de cada vez, nao sobrecarregar)
|
||||
5. Gerar SPEC.md usando template do peso adequado
|
||||
6. Apresentar para revisao
|
||||
7. Iterar ate aprovacao
|
||||
|
||||
### Output
|
||||
SPEC.md seguindo os templates definidos em /spec skill, com frontmatter correcto
|
||||
e todos os campos preenchidos ou marcados [CONFIRMAR].
|
||||
|
||||
## MCPs Relevantes
|
||||
- desk-crm-v3: Contexto do projecto, tasks existentes
|
||||
- mcp-time: Datas correctas
|
||||
|
||||
## Colaboracao
|
||||
- Invocado por: /spec create, delegacao manual
|
||||
- Colabora com: scrum-master (para sprint planning apos spec)
|
||||
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"task_id": null,
|
||||
"project_id": null,
|
||||
"customer_id": null,
|
||||
"gitea_repo": null
|
||||
}
|
||||
@@ -0,0 +1,96 @@
|
||||
#!/bin/bash
|
||||
# spec-gate.sh - PreToolUse hook for Write/Edit
|
||||
# Avisa quando se tenta editar ficheiros sem SPEC.md aprovado
|
||||
# Modo: HARD (bloqueia sem SPEC.md aprovado)
|
||||
# Autor: Descomplicar® | 2026-02-07
|
||||
|
||||
INPUT=$(cat)
|
||||
TOOL_NAME=$(echo "$INPUT" | jq -r '.tool_name // empty' 2>/dev/null)
|
||||
|
||||
# So intercepta Write e Edit
|
||||
if [ "$TOOL_NAME" != "Write" ] && [ "$TOOL_NAME" != "Edit" ]; then
|
||||
exit 0
|
||||
fi
|
||||
|
||||
# Extrair file path
|
||||
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty' 2>/dev/null)
|
||||
|
||||
# ========== BYPASSES ==========
|
||||
|
||||
# Sem file path
|
||||
if [ -z "$FILE_PATH" ]; then
|
||||
exit 0
|
||||
fi
|
||||
|
||||
# Ficheiros de sistema
|
||||
if echo "$FILE_PATH" | grep -qE '(\.claude/|CLAUDE\.md|settings\.json|\.env|\.claude-work/)'; then
|
||||
exit 0
|
||||
fi
|
||||
|
||||
# O proprio SPEC.md ou SPRINT.md
|
||||
if echo "$FILE_PATH" | grep -qE '(SPEC\.md|SPRINT\.md)$'; then
|
||||
exit 0
|
||||
fi
|
||||
|
||||
# Ficheiros fora de pastas de projecto
|
||||
if ! echo "$FILE_PATH" | grep -qE '^/media/ealmeida/Dados/(Dev|Arquivo_de_Clientes)/'; then
|
||||
exit 0
|
||||
fi
|
||||
|
||||
# Bypass temporario (30 min)
|
||||
BYPASS_FILE="/tmp/claude-spec-gate-bypass"
|
||||
if [ -f "$BYPASS_FILE" ]; then
|
||||
BYPASS_AGE=$(( $(date +%s) - $(stat -c %Y "$BYPASS_FILE" 2>/dev/null || echo 0) ))
|
||||
if [ "$BYPASS_AGE" -lt 1800 ]; then
|
||||
exit 0
|
||||
else
|
||||
rm -f "$BYPASS_FILE"
|
||||
fi
|
||||
fi
|
||||
|
||||
# Docs e configs (CHANGELOG, README, .txt, docs/)
|
||||
if echo "$FILE_PATH" | grep -qiE '(CHANGELOG|README|\.txt$|\.json$|docs/|\.desk-project)'; then
|
||||
exit 0
|
||||
fi
|
||||
|
||||
# Plan files
|
||||
if echo "$FILE_PATH" | grep -qE '\.claude/plans/'; then
|
||||
exit 0
|
||||
fi
|
||||
|
||||
# ========== SPEC CHECK ==========
|
||||
|
||||
DIR=$(dirname "$FILE_PATH")
|
||||
SPEC_FOUND=""
|
||||
|
||||
# Procurar SPEC.md subindo ate 5 niveis
|
||||
for i in 1 2 3 4 5; do
|
||||
if [ -f "$DIR/SPEC.md" ]; then
|
||||
SPEC_FOUND="$DIR/SPEC.md"
|
||||
break
|
||||
fi
|
||||
PARENT=$(dirname "$DIR")
|
||||
# Parar em raizes conhecidas
|
||||
if [ "$PARENT" = "$DIR" ] || [ "$DIR" = "/media/ealmeida/Dados/Dev" ] || [ "$DIR" = "/media/ealmeida/Dados" ]; then
|
||||
break
|
||||
fi
|
||||
DIR="$PARENT"
|
||||
done
|
||||
|
||||
# Sem SPEC.md - aviso suave
|
||||
if [ -z "$SPEC_FOUND" ]; then
|
||||
echo "SPEC-GATE: Sem SPEC.md neste projecto. Considere /spec create antes de comecar."
|
||||
exit 2 # hard mode: bloqueia
|
||||
fi
|
||||
|
||||
# SPEC.md existe - verificar aprovacao
|
||||
if grep -q '<!-- APPROVED:' "$SPEC_FOUND" 2>/dev/null; then
|
||||
# Spec aprovado - tudo OK, silencio total
|
||||
exit 0
|
||||
fi
|
||||
|
||||
# Spec existe mas nao aprovado
|
||||
echo "SPEC-GATE: SPEC.md existe mas NAO esta aprovado."
|
||||
echo " Ficheiro: $SPEC_FOUND"
|
||||
echo " Accao: /spec approve para aprovar, ou /spec bypass para quick fix (30min)"
|
||||
exit 2 # hard mode: bloqueia
|
||||
@@ -0,0 +1,8 @@
|
||||
# project-manager
|
||||
|
||||
## Documentação
|
||||
|
||||
- [README](README.md)
|
||||
- [AGENTS](AGENTS.md)
|
||||
- [STATUS](STATUS.md)
|
||||
- [MEMORY](MEMORY.md)
|
||||
@@ -0,0 +1,82 @@
|
||||
{
|
||||
"description": "Knowledge sources for Project Manager plugin",
|
||||
"sources": {
|
||||
"notebooklm": {
|
||||
"description": "NotebookLM - conhecimento curado profundo via Gemini 2.5 RAG",
|
||||
"tools": [
|
||||
"mcp__notebooklm__search_notebooks",
|
||||
"mcp__notebooklm__ask_question"
|
||||
],
|
||||
"notebooks": [
|
||||
{
|
||||
"id": "perfex-crm-knowledge-base",
|
||||
"topics": [
|
||||
"perfex",
|
||||
"crm",
|
||||
"modulos",
|
||||
"extensoes"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "claude-code-advanced-knowledge",
|
||||
"topics": [
|
||||
"claude-code",
|
||||
"mcp",
|
||||
"skills",
|
||||
"plugins",
|
||||
"frameworks"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "stack-tecnol-gica-ia-descompli",
|
||||
"topics": [
|
||||
"ia",
|
||||
"saas",
|
||||
"n8n",
|
||||
"crewai",
|
||||
"sifide",
|
||||
"automacao"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "centos-web-panel-cwp-complete",
|
||||
"topics": [
|
||||
"cwp",
|
||||
"servidores",
|
||||
"hosting",
|
||||
"seguranca",
|
||||
"linux"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "obsidian-knowledge-system",
|
||||
"topics": [
|
||||
"obsidian",
|
||||
"vault",
|
||||
"pkm",
|
||||
"bases",
|
||||
"plugins"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "whatsms-zender-platform",
|
||||
"topics": [
|
||||
"whatsms",
|
||||
"zender",
|
||||
"whatsapp",
|
||||
"sms"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "e-commerce-portugal-estrat-gia",
|
||||
"topics": [
|
||||
"ecommerce",
|
||||
"portugal",
|
||||
"pmes",
|
||||
"mercado"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1 @@
|
||||
## 2026-06-30 init | Estrutura padrão
|
||||
@@ -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