Uma Claude Skill que recebe um account brief, o deal stage atual, o mapa de stakeholders nomeados e o inventário de collateral do time, e produz um outline estruturado de deal-room voltado para o comprador. O outline mapeia cada stakeholder aos assets que o movimentam, propõe um arco narrativo em três atos, restringe pricing e artefatos de segurança ao deal stage e ao status de NDA, e emite uma lista de gap questions que o AE precisa responder antes que o deal-room possa ser compartilhado.
A skill substitui as duas a três horas que um AE gasta curando collateral manualmente para um comprador de mutual-action-plan, sem substituir o julgamento do AE sobre qual reference customer nomeado usar, qual faixa de desconto está em jogo ou se o comprador realmente concordou com o cronograma do close-plan.
Quando usar
Use isso quando uma oportunidade está em late-stage e o comprador precisa de um único artefato — uma página de Notion, uma sala DocSend, uma coleção Highspot — para conduzir a revisão interna dele. Concretamente:
Depois de uma call de mutually-agreed-plan, quando o rep precisa enviar ao buying committee um conjunto curado de assets que conversem com cada persona presente.
Antes de um kickoff de procurement / security review, para montar os artefatos que procurement vai pedir de qualquer jeito.
Quando o AE está consolidando uma avaliação multi-stakeholder e quer que cada persona caia primeiro na página que efetivamente atende aos critérios de decisão dela.
A skill assume que você já fez o trabalho de discovery e produziu um account brief — o output do account-research-claude-skill é o formato de input canônico, mas qualquer brief estruturado com stakeholders nomeados, prioridades estratégicas e uma hipótese de wedge-pain funciona.
Quando NÃO usar
Publicar um deal-room automaticamente sem revisão do rep. O SKILL.md do bundle é explícito: o output é um outline mais um draft de mapeamento de assets. Um AE humano seleciona, redige e aprova antes que o comprador veja qualquer coisa. A skill nunca envia, nunca publica.
Deals que ainda não estão em mutually-agreed-plan. Pre-discovery, qualification e estágios iniciais de demo não precisam de deal-room. Mandar um cedo demais soa como forcing function que o comprador não pediu, e treina o comprador a ancorar nos termos comerciais antes de a conversa de valor aterrissar.
Renewals em que nenhum collateral novo é necessário. Um deck de QBR e um relatório de uso não são um deal-room.
Logos net-new pré-NDA, para as seções de segurança e pricing. A skill se recusa a popular essas seções sem nda_signed: true no input.
Setup
Coloque o bundle no diretório de Skills do time. Copie apps/web/public/artifacts/deal-room-generator-skill/SKILL.md e os três arquivos de referência para sua pasta de Skills. A skill lê de references/ a cada invocação, então o layout do diretório importa.
Substitua o template de asset inventory pelo real. Edite references/1-asset-inventory-template.md para que a tabela reflita sua biblioteca de collateral real — todo asset com type, personas, stages, last_updated, nda_required e link. Qualquer coisa faltando é tratada como “não selecionar”; a skill prefere omitir a chutar.
Ajuste a matriz stage-to-asset. O default em references/2-stage-to-asset-matrix.md é conservador — pricing restrito a proposal ou posterior, artefatos de segurança só com NDA, named customer references só com NDA. Se sua política comercial é diferente, edite a matriz; a skill cita o caminho da matriz em todo output, então desvios da política do time ficam auditáveis.
Conecte o read access do Salesforce se você quer que a skill puxe stakeholders direto dos contact roles da Opportunity. Opcional — a maioria dos reps passa o mapa de stakeholders à mão a partir das notas deles, o que tende a ser mais preciso do que os contact roles de qualquer jeito.
Conecte o Notion (ou DocSend, ou Highspot) como target de publicação. A skill produz o outline; uma etapa separada de publicação transforma o outline em um artefato voltado ao comprador. Publicar é manual de propósito — veja “Quando NÃO usar”.
Teste em uma conta. Pegue uma oportunidade que você conhece a fundo — de preferência uma que já fechou, em que você consegue comparar o outline da skill com o que você de fato entregou. Confira o mapeamento de personas e as seções gated por NDA. Ajuste a matriz e o asset inventory conforme.
O que a skill realmente faz
A skill roda cinco sub-tarefas sequenciais, todas documentadas no SKILL.md do bundle:
Valida stage e gating. Cruza deal_stage e nda_signed com a matriz. Seções gated saem como “gated: NDA required” em vez de ficarem silenciosamente omitidas, para que o rep veja o que está sendo segurado e corra atrás da NDA explicitamente.
Mapeia assets para stakeholders, não para deal stage. Para cada stakeholder nomeado, a skill percorre o asset inventory e seleciona os um a três assets que combinam com a persona e a senioridade. Um CFO recebe primeiro a calculadora de ROI e o one-pager de pricing; um Director of Engineering recebe primeiro o diagrama de arquitetura e o resumo de SOC 2; um lead end-user recebe primeiro o vídeo de walkthrough do workflow. Pacotes de assets stage-driven (a abordagem óbvia) produzem o mesmo deal-room para todo comprador no mesmo stage. Mapeamento persona-driven força o AE a pensar nas pessoas que realmente estão na sala.
Monta um arco narrativo de três atos. “Why act” cita uma prioridade estratégica do account brief, na linguagem do próprio comprador. “Why us” puxa um proof point por persona presente. “Why now” é o resumo do close-plan — como ficam os próximos 14 a 30 dias e o que cada papel do lado do comprador é dono.
Adiciona seções stage-específicas. Pricing só aparece em proposal ou posterior. Artefatos de segurança só com nda_signed: true. A matriz aplica isso mesmo quando o rep está impaciente.
Emite gap questions. Para cada seção em que o rep precisa fazer um judgment call — escolher uma reference específica, confirmar uma faixa de desconto, confirmar uma data de implementação — uma pergunta puxada de references/3-rep-gap-questions.md aparece sob “Rep gaps to fill.” Elas são deliberadamente bloqueantes: o outline do deal-room não está “pronto” até o rep respondê-las.
O output é um arquivo Markdown com o arco narrativo inline, uma tabela de mapeamento stakeholder-para-asset, um checklist de seções a publicar (com motivos de gating anotados) e a lista de gap questions no final. Veja a seção “Output format” no SKILL.md do bundle para o template literal.
Realidade de custo
Por deal-room gerado, o custo em tokens fica na faixa de poucos centavos a menos de um dólar — tipicamente cerca de 8k-15k input tokens (account brief, mapa de stakeholders, asset inventory, matriz, referência de gap questions) e 2k-4k output tokens. Em Claude Sonnet a aproximadamente $3 por milhão de input e $15 por milhão de output, isso dá da ordem de $0,06 a $0,10 por deal-room.
Tempo economizado por AE é o número maior. O workflow de curadoria manual roda duas a três horas por oportunidade late-stage: escolher o case study certo da asset library, escrever o arco narrativo, redigir o FAQ, decidir quais artefatos de segurança são compartilháveis pré-NDA, montar a tabela de close-plan. A skill comprime isso para uma passada de revisão de 15 a 25 minutos sobre um outline gerado. Para um AE rodando 6-10 deals de mutual-action-plan ao mesmo tempo, isso são 12-30 horas por trimestre devolvidas por rep.
O custo mais difícil de quantificar mas que é o ponto real: deal-rooms que saem mais rápido, com collateral mapeado por persona, fecham a taxas maiores do que deal-rooms cheios de links genéricos de “tudo o que temos”. A skill torna a versão disciplinada barata o suficiente para fazer toda vez.
Métrica de sucesso
A métrica para observar mexer é tempo da call de mutual-plan até o deal-room enviado. Pré-skill, a mediana num time típico de SaaS fica em torno de dois a três dias úteis; pós-skill, deve cair para menos de um dia. Se a métrica não mexer, a skill está sendo tratada como um gerador que o AE roda e descarta em vez de um draft que ele edita e entrega — geralmente sinal de que o asset inventory está desatualizado ou o mapeamento de persona está disparando em stakeholders de baixa confiança.
Uma métrica secundária: tempo de turn da NDA. Com os callouts “NDA required” em seções gated aparecendo explicitamente em todo outline, os reps tendem a correr atrás de NDAs mais cedo; espere ver o tempo de execução de NDA cair depois de alguns sprints usando a skill.
vs. alternativas
vs. DealHub — DealHub é um produto completo de digital sales room: brandeado, hospedado, com analytics de engajamento e orquestração de contratos. É a resposta certa para um time que quer uma experiência de comprador produtizada e está disposto a padronizar nos templates de um vendor e pagar por seat. A skill é a resposta certa quando o time já tem o target de publicação (Notion, Highspot, DocSend) e quer o julgamento upstream — quais assets, em que ordem, para qual persona, gated por quê — feito de forma consistente entre reps sem comprar mais uma ferramenta.
vs. GetAccept — Formato similar ao DealHub. A força do GetAccept é a camada de e-signature e tracking de engajamento; a skill deixa isso para o que seu time já usa e foca na etapa de design de conteúdo do deal-room, que o GetAccept assume que o rep já fez.
vs. montar deal-rooms manualmente no Notion — Isso é o que a maioria dos times de fato faz. Funciona, e é a comparação mais próxima. A diferença que a skill faz é consistência: a disciplina de mapeamento por persona, o gating de NDA, os prompts de gap question. Um AE sênior fazendo isso à mão vai produzir algo próximo do output da skill; um AE júnior fazendo à mão vai pular as gap questions e mandar pricing pré-NDA. A skill faz do output do AE sênior o piso.
Watch-outs
Compartilhar collateral pré-NDA. A matriz em references/2-stage-to-asset-matrix.md se recusa a popular seções de segurança, arquitetura-detalhada e named customer-reference sem nda_signed: true. Seções gated aparecem no outline como “gated: NDA required” para o rep ver o que está sendo segurado; omissão silenciosa deixaria um rep entregar um deal-room incompleto sem perceber o que ficou de fora.
Persona mismatch. Inferência por título pode colocar o asset errado na frente da pessoa errada — um “VP Operations” pode ser o economic buyer numa empresa e um blocker em outra. A skill emite uma nota de confiança por stakeholder e expõe mapeamentos de baixa confiança sob “Rep gaps to fill” em vez de travá-los.
Assets desatualizados. Deal-rooms cheios de case studies de dois anos atrás e páginas de pricing superadas fazem mais estrago do que deal-room nenhum. O formato do asset inventory exige uma data last_updated em toda entrada; a skill marca qualquer asset selecionado com mais de nove meses no output como stale? para o rep atualizar ou remover antes de publicar.
Drift narrativo. É fácil a narrativa sugerida vagar para positioning genérico. O parágrafo de “Why act” precisa citar uma prioridade estratégica do account brief; se nenhuma prioridade estratégica está disponível, a seção sai como “REQUIRES INPUT — no strategic priority in brief” em vez de ser preenchida com lugar-comum.
Publicar com hábito de gerador. A skill produz um outline, não um artefato finalizado. Reps que tratam o output como o artefato entregam deal-rooms com nomes-placeholder de cliente e datas de go-live não comprometidas. Trate a lista de gap questions como bloqueante antes de publicar.
Stack
Claude — drafting narrativo, mapeamento de persona, seleção de gap question
Salesforce — fonte opcional para puxar stakeholders a partir dos contact roles da Opportunity
Notion / DocSend / Highspot — target de publicação para o deal-room final voltado ao comprador (publicar é manual de propósito)
O asset inventory — a biblioteca de collateral existente do seu time, catalogada no formato que os arquivos de referência do bundle especificam
---
name: deal-room-generator
description: Build a buyer-facing deal-room outline for a late-stage opportunity. Takes an account brief, the current deal stage, the stakeholder map, and an asset-library inventory; produces a structured outline that maps each stakeholder to the assets that move them, the suggested narrative arc, and the gaps where the rep needs to fill in proof or commercial terms before sharing.
---
# Deal-room generator
## When to invoke
Invoke this skill when a late-stage opportunity needs a buyer-facing collateral package — typically once a mutually-agreed close plan exists, the buying committee is named, and the AE has to pull together a single artifact (a Notion page, a DocSend room, a Highspot collection) for the buyer to navigate internally.
Good moments:
- After a mutual-action-plan call, when the rep needs to send the buyer a curated set of assets to drive an internal review.
- Before a procurement / security review kickoff, to assemble the artifacts procurement is going to ask for anyway.
- When the AE is rolling up a multi-stakeholder evaluation and wants every persona to land on the page that speaks to them first.
Do NOT invoke this skill for:
- **Auto-publishing a deal-room without rep review.** The output is an outline and an asset-mapping draft. A human AE must select, redact, and approve before the buyer sees anything. The skill never sends, never publishes.
- **Deals that are not yet in a mutually-agreed-plan stage.** Pre-discovery, qualification, and early demo stages do not need a deal room. Sending one early is a forcing function the buyer did not ask for and reads as desperation.
- **Renewals where no new collateral is required.** A QBR deck and a usage report are not a deal room.
- **Net-new logos pre-NDA** for the security and pricing sections — the skill will refuse to populate those sections without an explicit `nda_signed: true` input.
## Inputs
Required:
- `account_brief` — the structured pre-discovery brief produced by the `account-research` skill, or an equivalent. Provides industry, scale, strategic priorities, persona-relevance hints.
- `deal_stage` — one of `mutual_plan`, `proposal`, `procurement`, `legal_redline`. Drives which sections the skill populates and which asset categories it pulls from.
- `stakeholder_map` — a list of named stakeholders on the buying committee, each with role (`economic_buyer`, `champion`, `technical_evaluator`, `end_user`, `procurement`, `legal`, `security`), seniority, and a one-line context note (e.g. "burned by previous vendor's pricing surprise").
- `asset_inventory` — the team's current collateral library, in the format of `references/asset-inventory-template.md`. Must include each asset's type, persona fit, deal-stage fit, last-updated date, and any share-restrictions (NDA-only, customer-logos-redacted, etc.).
Optional:
- `nda_signed` — boolean. Defaults to `false`. Gates security artifacts, customer reference details, and detailed architecture diagrams.
- `competitor_in_play` — slug of a named competitor the buyer is also evaluating. Pulls the relevant battlecard into the outline.
- `narrative_hint` — free-text from the rep, e.g. "land-and-expand framing, buyer is anxious about migration risk." Influences the suggested narrative arc.
## Reference files
Always read these from `references/` before generating the outline. Without them, the output is a generic deal-room template and not specific to this account.
- `references/asset-inventory-template.md` — the format the rep uses to describe what is in the asset library. Replace the template content with the team's actual inventory before invoking.
- `references/stage-to-asset-matrix.md` — the matrix that controls which asset categories appear at which deal stage and which are gated by NDA.
- `references/rep-gap-questions.md` — the question set the skill emits for the rep to fill in (proof points, named customers, commercial terms) before the deal-room is shared with the buyer.
## Method
Run these five sub-tasks in order. They are sequential — later steps depend on earlier outputs.
### 1. Validate stage and gating
Read `deal_stage` and `nda_signed`. Cross-reference against `references/stage-to-asset-matrix.md`. If the stage is `mutual_plan` and `nda_signed` is `false`, the skill refuses to populate the security, detailed-architecture, and reference-customer-name sections — these are listed in the output as "gated: NDA required" rather than silently omitted, so the rep can see what is being held back and why.
The engineering choice: silent omission would let the rep ship an incomplete deal-room without realizing what they pushed past. Explicit gates force a review step.
### 2. Map assets to stakeholders, not to deal stage
For each named stakeholder, walk the `asset_inventory` and select the 1-3 assets that match that stakeholder's role and seniority. A CFO in the buying committee gets the ROI calculator and the pricing-model one-pager first; a Director of Engineering gets the architecture diagram and the SOC 2 summary first; an end-user lead gets the workflow walkthrough video first.
The engineering choice: deal-stage-driven asset packs (the obvious approach) produce the same deal-room for every buyer at the same stage. Persona-driven mapping forces the AE to think about the actual people in the room. The matrix in `stage-to-asset-matrix.md` is a filter on what is *available* at each stage, not a substitute for persona matching.
### 3. Build the narrative arc
Propose a three-act structure for the deal-room landing page:
1. **Why act** — the strategic priority of the buyer that this purchase addresses, drawn from the `account_brief`. One paragraph, the buyer's own language where possible.
2. **Why us** — the wedge differentiation, with one proof point per stakeholder persona present in the buying committee. Pulls from the asset inventory's case-study and proof entries.
3. **Why now** — the close-plan summary: what the next 14-30 days look like, what the buyer's internal review needs from each role.
The narrative is a *suggestion* — the AE may rewrite it. The skill outputs the proposed arc inline so it is reviewable, not buried in a separate file.
### 4. Layer in stage-specific sections
Walk the matrix from step 1 and add the sections that this `deal_stage` unlocks:
- `mutual_plan` — landing narrative, persona-mapped assets, mutual close plan template, FAQ.
- `proposal` — adds the pricing model summary, ROI calculator link, contract preview (terms only, not signed).
- `procurement` — adds vendor questionnaire responses, security overview, insurance certificates list.
- `legal_redline` — adds MSA + DPA preview, jurisdictional appendices.
Pricing only appears at `proposal` or later. The engineering choice: exposing pricing in the `mutual_plan` stage trains buyers to anchor on the list price before the value conversation lands. The matrix enforces this even if the rep is impatient.
### 5. Emit gap questions
For every section where the rep needs to make a judgment call — pick a specific customer reference, confirm a discount band, confirm an implementation date — emit a question pulled from `references/rep-gap-questions.md`. These appear at the bottom of the output under "Rep gaps to fill" and are deliberately blocking: the deal-room outline is not "done" until the rep answers them.
## Output format
```markdown
# Deal-room outline — {Account name}
**Stage:** {deal_stage} **NDA signed:** {true|false} **Competitor in
play:** {competitor or "none"}
## Suggested narrative arc
1. **Why act.** {Buyer's strategic priority, one paragraph in their language.}
2. **Why us.** {Wedge differentiation + one proof point per persona present.}
3. **Why now.** {Close-plan summary — what the next 14-30 days require from
each role.}
## Stakeholder → asset mapping
| Stakeholder | Role | Lead asset | Supporting asset | Asset gated? |
|---|---|---|---|---|
| {Name} | Economic buyer | ROI calculator (v3, 2025-03) | Pricing model 1-pager | No |
| {Name} | Technical evaluator | Architecture diagram | SOC 2 summary | NDA-gated |
| {Name} | End user | Workflow walkthrough (4 min) | Product tour | No |
| {Name} | Procurement | Vendor questionnaire response | Insurance certs list | No |
## Sections to publish
- [x] Landing narrative (above)
- [x] Persona-mapped asset shelf
- [x] Mutual close plan (template attached: `mutual-close-plan.md`)
- [x] FAQ (rep edits before publishing)
- [ ] Pricing model summary — **gated: stage is `mutual_plan`, requires
`proposal` or later**
- [ ] Security overview — **gated: NDA required**
- [ ] Reference-customer detail — **gated: NDA required**
## Rep gaps to fill before sharing
1. **Pick the reference customer for the technical evaluator's persona.**
Three candidates from the inventory match: {A}, {B}, {C}. Which is the
closest analog to the buyer's environment?
2. **Confirm the implementation date in "Why now."** The narrative says
"go-live within 60 days of signature" — confirm engineering capacity.
3. **Confirm any commercial concessions to mention in the FAQ.** The FAQ
currently says "standard terms"; if a discount or extended payment
terms are on the table, the FAQ should be updated before publishing.
## Sources
- Account brief: {ref}
- Asset inventory: {ref}
- Stage-to-asset matrix: `references/stage-to-asset-matrix.md`
```
## Watch-outs
- **Sharing collateral pre-NDA.** The skill refuses to populate security, detailed-architecture, and named-customer-reference sections without `nda_signed: true`. *Guard:* gated sections appear in the output as "gated: NDA required" so the rep can see what is missing and chase the NDA explicitly, rather than silently shipping an incomplete deal-room.
- **Persona mismatch.** Title-based mapping can put the wrong asset in front of the wrong person — a "VP Operations" might be the economic buyer at one company and a blocker at another. *Guard:* the skill emits a per-stakeholder confidence note (`high` if the title pattern matches the ICP rubric exactly, `low` if it is inferred) and surfaces low-confidence mappings under "Rep gaps to fill" instead of locking them in.
- **Stale assets.** Deal-rooms full of 2-year-old case studies and superseded pricing pages do more damage than no deal-room at all. *Guard:* the asset inventory format requires a `last_updated` date on every entry; the skill flags any selected asset older than 9 months in the output as `stale?` so the rep refreshes or removes before publishing.
- **Narrative drift from the brief.** It is easy for the suggested narrative to wander into generic positioning. *Guard:* the "Why act" paragraph must cite a strategic priority from the `account_brief`; if no strategic priority is available, the section is emitted as `[REQUIRES INPUT — no strategic priority in brief]` rather than filled with platitudes.
# Asset inventory — TEMPLATE
> Replace this template's contents with your team's actual collateral
> inventory. The `deal-room-generator` skill reads this on every run and
> uses it to map assets to stakeholders. Without your real inventory, the
> output is a generic deal-room template.
The skill expects every asset to declare: `id`, `title`, `type`, `personas`, `stages`, `last_updated`, `nda_required`, and `link`. Anything missing is treated as "do not select" — the skill prefers omission over guessing.
## Asset format
Each entry in this table corresponds to one piece of collateral.
| id | title | type | personas | stages | last_updated | nda_required | link |
|---|---|---|---|---|---|---|---|
| roi-calc-v3 | ROI calculator (v3) | calculator | economic_buyer | proposal, procurement | 2026-02-14 | false | {url} |
| arch-diagram-2026 | Reference architecture | diagram | technical_evaluator, security | mutual_plan, proposal, procurement | 2026-01-09 | true | {url} |
| soc2-summary | SOC 2 Type II summary | security_doc | security, technical_evaluator | proposal, procurement | 2026-03-30 | true | {url} |
| workflow-tour-4min | Workflow walkthrough | video | end_user | mutual_plan, proposal | 2025-11-22 | false | {url} |
| customer-acme-case | Acme Corp case study | case_study | economic_buyer, champion | mutual_plan, proposal | 2025-09-01 | true | {url} |
| pricing-model-1pg | Pricing model one-pager | pricing | economic_buyer, procurement | proposal, procurement | 2026-04-04 | false | {url} |
| msa-preview | MSA preview (clean copy) | legal | legal, procurement | legal_redline | 2026-04-22 | true | {url} |
| dpa-preview | DPA preview | legal | legal, security | legal_redline | 2026-04-22 | true | {url} |
| insurance-certs | Insurance certificate list | compliance | procurement | procurement, legal_redline | 2026-04-15 | false | {url} |
| vendor-quest-response | Vendor questionnaire response | compliance | procurement, security | procurement | 2026-03-12 | true | {url} |
## Field meanings
- **id** — short slug, used in the deal-room outline tables.
- **type** — one of `case_study`, `calculator`, `diagram`, `video`, `security_doc`, `pricing`, `legal`, `compliance`, `battlecard`, `faq`. The skill uses this to group assets in the persona shelf.
- **personas** — list, drawn from: `economic_buyer`, `champion`, `technical_evaluator`, `end_user`, `procurement`, `legal`, `security`.
- **stages** — list, drawn from: `mutual_plan`, `proposal`, `procurement`, `legal_redline`.
- **last_updated** — ISO date. Anything older than 9 months from today is surfaced as `stale?` in the output so the rep refreshes or removes it.
- **nda_required** — boolean. The skill cross-references this against the `nda_signed` input; gated assets appear in the outline as "gated: NDA required" rather than being silently omitted.
- **link** — internal URL to the canonical version of the asset (Highspot, DocSend, Notion, Drive, Seismic — whatever your team uses).
## Battlecards (optional sub-section)
If the deal has a `competitor_in_play` input, the skill also reads this sub-section and pulls the matching battlecard into the persona shelf for the technical evaluator and economic buyer.
| competitor_slug | battlecard_id | last_updated | link |
|---|---|---|---|
| {competitor-1} | bc-{competitor-1} | YYYY-MM-DD | {url} |
| {competitor-2} | bc-{competitor-2} | YYYY-MM-DD | {url} |
## Last edited
{YYYY-MM-DD} — update on every material change so the deal-room outline can flag stale entries.
# Stage-to-asset matrix
> The `deal-room-generator` skill uses this matrix to decide which asset
> categories appear at which deal stage and which are gated by NDA. It is a
> *filter* on the asset inventory, not a substitute for persona matching.
> The skill maps assets to stakeholders first, then applies this matrix to
> remove categories the stage does not unlock.
## Stage gating
Rows are asset categories. Columns are deal stages. A check means the category is allowed at that stage; a dash means the skill must omit it even if a matching asset exists. NDA-gated cells require both the stage gate and `nda_signed: true` on the input.
| Asset category | mutual_plan | proposal | procurement | legal_redline |
|---|---|---|---|---|
| Landing narrative | yes | yes | yes | yes |
| Mutual close plan | yes | yes | yes | yes |
| FAQ | yes | yes | yes | yes |
| Persona walkthrough video | yes | yes | yes | yes |
| Reference architecture diagram | NDA only | NDA only | NDA only | NDA only |
| SOC 2 summary | NDA only | NDA only | NDA only | NDA only |
| Detailed security questionnaire | — | NDA only | NDA only | NDA only |
| Customer case study (named) | NDA only | NDA only | NDA only | NDA only |
| Customer case study (anonymized) | yes | yes | yes | yes |
| ROI calculator | — | yes | yes | yes |
| Pricing model one-pager | — | yes | yes | yes |
| Contract preview (MSA terms only) | — | yes | yes | yes |
| Insurance certificate list | — | — | yes | yes |
| Vendor questionnaire response | — | — | NDA only | NDA only |
| MSA + DPA full preview | — | — | — | NDA only |
| Battlecard (if competitor_in_play) | yes | yes | yes | yes |
## Why pricing is gated to `proposal` and later
Exposing pricing in `mutual_plan` trains buyers to anchor on the list price before the value conversation has landed. The wedge use case has not been tied back to the buyer's strategic priority yet. Almost every deal that ends in "the price is too high" had pricing exposed too early. The gate is enforced by the matrix even when the rep is impatient.
## Why customer-named case studies are NDA-gated
Customer reference programs typically come with contractual obligations on how the customer name is used in pre-sales contexts. The anonymized versions are the safe default; the named versions go into the deal-room only after the buyer has signed an NDA that protects both the buyer and the reference customer.
## Why detailed security artifacts are gated past `mutual_plan`
A buyer who has not yet committed to a mutual action plan does not need the SOC 2 audit detail or the architecture diagram — surfacing them shifts the conversation into a procurement frame before the value conversation is finished. The exception is when security is on the buying committee from day one (rare in mid-market, common in regulated enterprise); in that case the rep should override by passing `nda_signed: true` once the NDA is in place.
## Override behavior
The skill never silently overrides the matrix. If the rep wants to include a gated asset earlier than the matrix permits, the matrix entry itself must be edited (and committed) — the skill output cites the matrix file path, so any deviation from the team's policy is auditable.
## Last edited
{YYYY-MM-DD}
# Rep gap questions
> The `deal-room-generator` skill emits these questions in the
> "Rep gaps to fill before sharing" section of every output. They are
> deliberately blocking — the deal-room outline is not considered "done"
> until the rep answers them. The list below is the master set; the skill
> selects the subset relevant to the deal stage and stakeholder mix on
> the current run.
## Reference customer selection
Whenever a case study is mapped to a stakeholder, the skill asks:
- **Which named reference is the closest analog to this buyer's environment?** The inventory may have three case studies that match the persona; the skill cannot pick the right one without rep judgment about industry, scale, and the specific pain that resonates.
- **Has the reference customer been re-confirmed for use in pre-sales in the last 6 months?** Reference programs lapse. Confirm before the buyer's AE-to-AE call gets scheduled.
- **Is the reference willing to take an inbound call from this buyer?** Sharing the case study is one thing; tee-ing up a live reference call is another. Note this in the deal-room FAQ.
## Commercial terms
Whenever pricing or contract preview appears, the skill asks:
- **What discount band, if any, is approved for this deal?** The pricing one-pager shows list price; the FAQ should reflect what the rep is actually empowered to offer.
- **Are extended payment terms on the table?** Net-60 or annual prepay in exchange for a multi-year commitment is a common ask; if the rep has authority, the FAQ should signal it.
- **Is there a multi-year discount structure to surface?** Most buyers do not ask; some procurement teams will. Pre-empt by including the ladder in the FAQ.
## Implementation and timeline
Whenever the "Why now" section references a go-live date, the skill asks:
- **Is the proposed go-live date confirmed with implementation engineering?** Default narrative says "go-live within 60 days of signature" — confirm capacity before the buyer treats it as a commitment.
- **What is the named owner on the buyer's side for each milestone in the mutual close plan?** A close plan with no buyer-side owners is a rep wishlist, not a plan.
## Persona-mapping confirmations
Whenever a stakeholder mapping has `confidence: low`, the skill asks:
- **Is {Name} actually the {role}, or are they a {alternative role}?** Title-based inference can be wrong; the rep is the only person who knows what was said on the discovery call.
- **Should we add a stakeholder the skill missed?** The skill maps from the `stakeholder_map` input only. If the buyer mentioned a name that was not in the input, the rep adds it before sharing.
## Competitive framing
Whenever `competitor_in_play` is set and a battlecard is included:
- **Has the buyer named the competitor in writing, or is this an inference?** If it is an inference, the battlecard goes in the rep's prep notes, not the buyer-facing deal-room.
- **Is there a known displacement story in the case-study inventory?** A "we replaced {competitor}" case study, where allowed, is the most effective single asset against a specific competitor.
## NDA and gating
Whenever the matrix has gated content as "NDA only" and `nda_signed` is false, the skill asks:
- **Is the NDA in flight, blocked, or not started?** Drives the close-plan next-step item. The deal-room outline notes this as `[gated: NDA required — status: ?]` until the rep answers.
## Last edited
{YYYY-MM-DD}
