- All SKILL.md files now <500 lines (avg reduction 69%) - Detailed content extracted to references/ subdirectories - Frontmatter standardised: only name + description (Anthropic standard) - New skills: brand-guidelines, spec-coauthor, report-templates, skill-creator - Design skills: anti-slop guidelines, premium-proposals reference - Removed non-standard frontmatter fields (triggers, version, author, category) Plugins affected: infraestrutura, marketing, dev-tools, crm-ops, gestao, core-tools, negocio, perfex-dev, wordpress, design-media Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
6.9 KiB
6.9 KiB
name, description
| name | description |
|---|---|
| interview | Preparação de entrevistas técnicas e avaliação de candidatos. Cria perguntas, avalia respostas e fornece feedback. |
/interview - Entrevista Estruturada de Requisitos
Skill para clarificar requisitos antes de iniciar trabalho. Reduz ambiguidade e evita retrabalho.
Contexto NotebookLM
ANTES de executar, consultar notebooks para contexto especializado:
| Notebook | ID | Consultar quando |
|---|---|---|
| Estratégia e Empreendedorismo | 79d43410 | Para contexto negócio |
mcp__notebooklm__notebook_query({
notebook_id: "79d43410-0e29-4be1-881d-84db6bdc239a",
query: "<adaptar ao contexto do pedido do utilizador>"
})
Integrar insights do NotebookLM nas recomendações e decisões.
QUANDO USAR
- Início de projecto novo
- Tarefa complexa ou ambígua
- Pedido do utilizador pouco claro
- Antes de decisões arquitecturais
EXECUÇÃO
Fase 1: Contexto (OBRIGATÓRIO)
Perguntar usando AskUserQuestion:
1. O QUÊ?
- "Descreve o que queres alcançar em 1-2 frases"
2. PORQUÊ?
- "Qual o problema que isto resolve?"
- "O que acontece se não fizermos?"
3. PARA QUEM?
- "Quem vai usar/beneficiar disto?"
Fase 2: Objectivos
4. RESULTADO ESPERADO
- "Como sabes que está feito?"
- "O que muda quando terminar?"
5. PRIORIDADE
- "É urgente ou importante?"
- "Deadline real ou desejado?"
Fase 3: Restrições
6. TECNOLOGIA
- "Há tecnologias obrigatórias ou proibidas?"
- "Integra com sistemas existentes?"
7. RECURSOS
- "Quanto tempo podes dedicar?"
- "Há dependências de terceiros?"
8. LIMITAÇÕES
- "O que NÃO deve fazer?"
- "Há riscos conhecidos?"
Fase 4: Validação
9. CRITÉRIOS DE SUCESSO
- "Como vamos validar que funciona?"
- "Há testes ou cenários específicos?"
10. EXEMPLOS
- "Tens exemplos do que queres?"
- "Ou do que NÃO queres?"
OUTPUT
Após recolher respostas, gerar documento com BACKLOG CLARO:
---
title: "REQ - [Nome do Projecto/Tarefa]"
date: YYYY-MM-DD
type: requisitos
status: draft
tags: [requisitos, interview, backlog, PROJECTO]
---
# Requisitos: [Nome]
## Contexto
- **O quê:** [resposta]
- **Porquê:** [resposta]
- **Para quem:** [resposta]
## Objectivos
- **Resultado esperado:** [resposta]
- **Prioridade:** [Urgente/Importante/Normal]
- **Deadline:** [data ou N/A]
## Restrições
- **Tecnologia:** [resposta]
- **Recursos:** [resposta]
- **Limitações:** [resposta]
---
## BACKLOG
> Lista ordenada de tarefas antes de arrancar.
### Fase 1: Preparação
- [ ] [tarefa preparatória 1]
- [ ] [tarefa preparatória 2]
### Fase 2: Desenvolvimento
- [ ] [tarefa core 1]
- [ ] [tarefa core 2]
- [ ] [tarefa core 3]
### Fase 3: Validação
- [ ] [teste/validação 1]
- [ ] [teste/validação 2]
### Fase 4: Entrega
- [ ] [tarefa final 1]
- [ ] [documentação se aplicável]
---
## Critérios de Sucesso
- [ ] [critério 1]
- [ ] [critério 2]
- [ ] [critério 3]
## Riscos Identificados
| Risco | Impacto | Mitigação |
|-------|---------|-----------|
| [risco] | [alto/médio/baixo] | [acção] |
## Decisões Tomadas
| Decisão | Motivo | Alternativas Descartadas |
|---------|--------|--------------------------|
| [decisão] | [razão] | [alternativas] |
---
*Gerado via `/interview` - YYYY-MM-DD*
Regras do Backlog
- Ordenação: Tarefas na ordem de execução
- Granularidade: Cada tarefa = 1-4 horas max
- Dependências: Tarefas bloqueantes primeiro
- Checkboxes: Para tracking de progresso
- Fases: Agrupar por momento (preparação, dev, validação, entrega)
MODO RÁPIDO
Se o utilizador pedir /interview quick ou a tarefa for simples:
Perguntar apenas:
- O quê?
- Resultado esperado?
- Restrições importantes?
Output: Lista bullet points, não documento completo.
MODO TÉCNICO
Se o utilizador pedir /interview tech ou for projecto de código:
Adicionar:
- Arquitectura preferida?
- Padrões de código?
- Testes necessários?
- Documentação esperada?
GUARDAR REQUISITOS
Após gerar documento:
- Se projecto tem pasta: Guardar em
[pasta-projecto]/docs/REQ-[nome].md - Se não: Guardar em Obsidian vault
00-Inbox/REQ-[nome].md - Memória: Guardar resumo em Supabase para referência futura
await mcp__memory-supabase__save_memory({
content: "Requisitos [nome]: [resumo 2-3 frases]",
metadata: {
type: "requisitos",
project: "[nome]",
date: "YYYY-MM-DD"
}
});
ANTI-PATTERNS
NÃO fazer:
- Assumir respostas
- Saltar perguntas "óbvias"
- Começar a implementar antes de terminar
- Fazer todas as perguntas de uma vez (usar fases)
FAZER:
- Adaptar perguntas ao contexto
- Pedir exemplos concretos
- Validar entendimento ("Então queres X, correcto?")
- Identificar ambiguidades
EXEMPLO DE USO
Utilizador: /interview
Claude: Vou fazer algumas perguntas para clarificar os requisitos.
**Fase 1: Contexto**
[AskUserQuestion com 3 perguntas iniciais]
Utilizador: [respostas]
Claude: Entendido. Agora sobre objectivos...
**Fase 2: Objectivos**
[continua...]
INTEGRAÇÃO
- Antes de
/wp-dev: Usar/interview techpara requisitos WordPress - Antes de projecto CRM: Usar
/interviewpara requisitos cliente - Com
/desk: Associar requisitos a tarefa CRM
Skill criada: 2026-01-27 Versão: 1.0
Quando NÃO Usar
- Para tarefas fora do domínio de especialização desta skill
- Quando outra skill mais específica está disponível
- Para operações que requerem aprovação manual obrigatória
- Quando os requisitos não estão claramente definidos
Protocolo de Execução
-
Análise Inicial
- Verificar requisitos e contexto
- Identificar ferramentas necessárias
-
Preparação
- Validar acesso a recursos
- Preparar ambiente de trabalho
-
Execução
- Executar operações de forma incremental
- Validar cada passo antes de prosseguir
-
Validação
- Verificar resultados obtidos
- Confirmar sucesso da operação
-
Conclusão
- Documentar alterações realizadas
- Reportar status final e próximos passos
Exemplos de Uso
Exemplo 1: Caso Básico
User: [requisição simples relacionada com interview]
Skill: [execução directa com validação]
Output: [resultado conciso e accionável]
Exemplo 2: Caso Complexo
User: [requisição multi-passo ou complexa]
Skill:
1. Análise dos requisitos
2. Planeamento da abordagem
3. Execução faseada
4. Validação contínua
Output: [resultado detalhado com próximos passos]
Exemplo 3: Caso com Dependências
User: [requisição que depende de outros sistemas]
Skill:
1. Verificar dependências disponíveis
2. Coordenar com skills/MCPs necessários
3. Executar workflow integrado
Output: [resultado completo com referências]