Revisar Programa de Necessidades
Interrogue um programa à procura de lacunas, contradições e premissas não ditas
GrátisDepois de instalada, o Claude a carrega sozinho quando a conversa combina. Você também pode chamá-la direto com /brief-review.
Instale só este
npx mcpcad@latest --skill brief-review --globalPrimeira vez? A instalação inteira, passo a passo
- Abra o Claude Code — a versão de terminal ou o app desktop, tanto faz.
- No terminal, cole a linha acima e aperte Enter. No app, cole no chat e peça ao Claude para rodá-la.
- Reinicie o Claude Code. A instalação é só isso.
O que esta skill faz
Revisar Programa de Necessidades
Visão geral
Interrogue um programa de necessidades, edital ou OPR (Owner's Project Requirements, requisitos do proprietário) segundo oito eixos de revisão e produza uma análise escrita que fica em docs/briefs/. A saída é um documento de trabalho — lista lacunas, contradições e perguntas de esclarecimento recomendadas para devolver ao proprietário antes de o projeto começar.
Alinhado à prática norte-americana: expectativas de programa dos contratos AIA B101 / B201, ASHRAE Guideline 0 (OPR) e pré-requisitos de requisitos documentados do LEED v4.1 / WELL v2.
Quando usar
Acione com:
- Texto de programa / edital / OPR colado com um pedido de avaliação.
- Caminhos de arquivo de um documento de programa que o usuário quer revisado.
- Pedidos explícitos: "revise este programa", "confira o edital", "destrinche o OPR", "este programa está completo?", "o que falta neste programa".
NÃO acione para:
- Crítica de um projeto existente (use
design-critic). - Análise de zoneamento (use
zoning-summary). - Revisão de jogo de pranchas (use
drawing-checklist). - Traduzir o conteúdo do programa para linguagem do cliente (use
client-translator).
Fluxo de trabalho
Passo 1 — Prepare o ambiente se precisar
Confira se docs/briefs/index.md existe. Se não existir:
python scripts/init_briefs_workspace.py
Passo 2 — Reúna o contexto
- Leia
docs/project.md, se existir, para proprietário, terreno, jurisdição e decisões anteriores. - Leia o programa em si (texto colado, caminho de arquivo ou PDF anexado).
- Identifique o tipo de programa:
rfp|opr|program-brief|design-brief. Alguns eixos se aplicam de forma diferente conforme o tipo (por exemplo, poder de decisão pesa mais em editais; critérios de desempenho pesam mais em OPRs).
Passo 3 — Aplique a revisão em oito eixos
Carregue references/brief_axes.md para o método completo com subcritérios. Referência rápida:
- Objetivos declarados x não declarados — O que o proprietário pede x o que o tipo de edifício/mercado indica que ele realmente precisa. Explicite os objetivos não declarados.
- Completude do programa — Áreas (bruta/útil), populações, adjacências, mobiliário e equipamentos, premissas de crescimento. Confira contra
references/program_benchmarks.mdpara as faixas típicas por tipologia na América do Norte. - Contexto do terreno e da jurisdição — Endereço, zona citada, órgão aprovador nomeado, edição de norma aplicável (ano do IBC, emendas estaduais, locais), zona climática (ASHRAE 169), jurisdição de incêndio, concessionárias.
- Critérios de desempenho — Metas de energia (EUI, versão da ASHRAE 90.1, IECC), certificações (LEED / WELL / Living Building / Fitwel / Passive House / RELi), escopo de comissionamento (ASHRAE Guideline 0), referências de avaliação pós-ocupação, resultados mensuráveis.
- Realismo de prazo e orçamento — Checagem de ordem de grandeza contra o custo típico por área para a tipologia e a região (use
references/program_benchmarks.md). Sinalize se o prazo exclui a análise do órgão aprovador ou suprimentos de prazo longo. - Poder de decisão e governança — Quem aprova no estudo preliminar, anteprojeto e executivo? Ponto único de contato? Representante do proprietário / gerente de projeto? Comitês internos, aprovações de conselho, audiências públicas?
- Riscos e exclusões — O que está explicitamente fora do escopo? Premissas sobre materiais perigosos, responsabilidade pela geotecnia, verificação das condições existentes, escopo do levantamento, escopo de demolição, taxas de aprovação, itens fornecidos pelo proprietário.
- Sustentabilidade e resiliência — Pede-se um caminho para carbono zero? Riscos climáticos considerados (inundação, vento, calor, incêndio florestal, sismo)? A troca entre retrofit e construção nova foi tratada? Se resiliência é prioridade declarada mas nenhum risco é nomeado, essa lacuna é o próprio achado.
Concentre-se nos 3 a 5 eixos com sinal real. Não finja pontuar todos os eixos em todo programa — anote numa linha os que estão claramente bem e siga.
Passo 4 — Escreva a revisão
Leia assets/brief-review-template.md e preencha os campos. Nome do arquivo:
docs/briefs/<YYYY-MM-DD>-<slug>-review.md
Regra do slug: minúsculas, remova [^a-z0-9-], no máximo 40 caracteres, derivado do nome do projeto ou do tema do programa (acme-hq-opr, westside-school-rfp). Se já existir uma revisão com a mesma data+slug, acrescente o sufixo -<n>.
Use a ferramenta Write. Escreva a revisão em português; se o programa estiver em outro idioma, cite os trechos no original e traduza logo em seguida.
Passo 5 — Atualize o índice de programas
python scripts/append_to_index.py \
--date 2026-05-07 \
--slug acme-hq-opr \
--brief-type opr \
--primary-axes "objectives,performance,decision-rights"
O script acrescenta uma linha a docs/briefs/index.md. NÃO edite o índice à mão com a ferramenta Edit — o alinhamento da tabela quebra fácil.
Passo 6 — Relate
Diga ao usuário:
- O caminho do arquivo da revisão.
- As 2 ou 3 lacunas ou contradições mais urgentes.
- Uma lista curta de perguntas de esclarecimento recomendadas para devolver ao proprietário.
- Se o
zoning-summarydeve rodar em seguida.
Estrutura da saída
A revisão deve terminar com duas listas de ação:
- Lacunas a fechar antes do estudo preliminar — itens que o proprietário precisa resolver antes de o estudo preliminar começar de verdade.
- Perguntas ao proprietário — escritas como perguntas diretas, prontas para copiar num e-mail ou numa resposta no estilo RFI.
Regras
- Toda lacuna diz POR QUÊ, ancorada num dos oito eixos — nunca "isto parece vago" sem a etiqueta do eixo.
- Recuse inventar áreas de programa que o programa não declarou. Se a área bruta faltar, sinalize; não chute.
- Se o programa citar uma edição de norma, nomeie a edição explicitamente (ex.: "IBC 2021 com as emendas da Califórnia de 2023"). Se a edição faltar, sinalize.
- Distinga contradições duras (duas cláusulas que não podem ser verdadeiras ao mesmo tempo) de tensões brandas (prioridades que competem mas podem ser equilibradas).
- Especificidade acima de generalidade. "O programa declara LEED Gold mas exclui o comissionamento, que é pré-requisito do LEED (EAp1)" é melhor do que "a seção de sustentabilidade não está clara".
Antipadrões
- Listar todos os eixos mesmo quando a maioria está claramente bem — escolha os 3 a 5 com sinal real.
- Sugerir reprojeto. A revisão do programa avalia o programa, não o projeto.
- Inventar referências que não estão em
references/program_benchmarks.md— se a tipologia não estiver coberta, diga isso. - Editar
index.mdà mão em vez de usarappend_to_index.py. - Fingir que o programa está pior do que está para parecer minucioso. Reconheça o que está sólido.
Recursos
scripts/init_briefs_workspace.py— preparadocs/briefs/e o índice de programasscripts/append_to_index.py— acrescenta uma linha adocs/briefs/index.mdreferences/brief_axes.md— método detalhado da revisão em oito eixos, com subcritérios e exemplos de achadosreferences/program_benchmarks.md— custos por área, área por ocupante e proporções de programa típicos de tipologias norte-americanas (para checar prazo e orçamento)assets/brief-review-template.md— modelo em markdown da revisão
O que ela não verifica
O que esta skill faz. Lê um programa, edital ou OPR segundo oito eixos e grava
uma revisão em docs/briefs/ que termina em duas listas: lacunas a fechar antes do
estudo preliminar e perguntas a devolver ao proprietário. Cada lacuna é etiquetada
com o eixo de onde veio, para o leitor ver por que ela conta como lacuna.
O que ela não faz.
- Não preenche o que o programa deixou de fora. Uma área, orçamento, edição de norma ou órgão aprovador ausente é relatado como lacuna e nunca preenchido com um valor típico. Isso é o projeto, não uma falha.
- Não projeta nem reprojeta. Avalia o programa, não o projeto que o programa descreve.
- Não estima custo nem prazo. Os valores em
references/program_benchmarks.mdsão de nível de planejamento e existem para sinalizar um orçamento implausível, não para virar um. Quem estima é o orçamentista. - Não verifica zoneamento nem normas. Isso é com
zoning-summaryecode-compliance-review. - Não fala com o proprietário. As perguntas de esclarecimento são redigidas para você enviar.
O que você precisa antes de começar. O programa em si, em texto ou arquivo, que tipo de documento é (edital, OPR, programa de necessidades, briefing de projeto) e a jurisdição e edição da norma se o programa não as nomear.
Arquivos que ele coloca no seu disco
.claude/skills/brief-review/6 arquivos · 32,3 KBSKILL.md9,7 KBassets/brief-review-template.md2,0 KBreferences/brief_axes.md11,8 KBreferences/program_benchmarks.md6,5 KBscripts/append_to_index.py1,5 KBscripts/init_briefs_workspace.py0,7 KB