MCPcad

Revisar Programa de Necessidades

Interrogue um programa à procura de lacunas, contradições e premissas não ditas

Grátis

Depois de instalada, o Claude a carrega sozinho quando a conversa combina. Você também pode chamá-la direto com /brief-review.

Instale só este

Rode no seu terminal — precisa de Node
npx mcpcad@latest --skill brief-review --global
Primeira vez? A instalação inteira, passo a passo
  1. Abra o Claude Code — a versão de terminal ou o app desktop, tanto faz.
  2. No terminal, cole a linha acima e aperte Enter. No app, cole no chat e peça ao Claude para rodá-la.
  3. 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:

  1. 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.
  2. Completude do programa — Áreas (bruta/útil), populações, adjacências, mobiliário e equipamentos, premissas de crescimento. Confira contra references/program_benchmarks.md para as faixas típicas por tipologia na América do Norte.
  3. 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.
  4. 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.
  5. 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.
  6. 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?
  7. 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.
  8. 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-summary deve 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 usar append_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 — prepara docs/briefs/ e o índice de programas
  • scripts/append_to_index.py — acrescenta uma linha a docs/briefs/index.md
  • references/brief_axes.md — método detalhado da revisão em oito eixos, com subcritérios e exemplos de achados
  • references/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.md sã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-summary e code-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 KB
  • SKILL.md9,7 KB
  • assets/brief-review-template.md2,0 KB
  • references/brief_axes.md11,8 KB
  • references/program_benchmarks.md6,5 KB
  • scripts/append_to_index.py1,5 KB
  • scripts/init_briefs_workspace.py0,7 KB