Una Claude Skill que toma un account brief, la etapa actual del deal, el mapa nombrado de stakeholders y el inventario de collateral del equipo, y produce un outline estructurado de deal-room hacia el comprador. El outline mapea cada stakeholder a los assets que lo mueven, propone un arco narrativo de tres actos, gatea artefactos de pricing y security detrás de la etapa del deal y el estatus de NDA, y emite una lista de preguntas de gap que el AE tiene que responder antes de que el deal-room pueda compartirse.
La skill reemplaza las dos a tres horas que un AE pasa curando collateral a mano para un comprador con plan de acción mutuo, sin reemplazar el juicio del AE sobre qué reference customer nombrado usar, qué banda de descuento está en juego, o si el comprador efectivamente aceptó el timeline del close-plan.
Cuándo usar
Recurre a esto cuando una opportunity está en motion de etapa tardía y el comprador necesita un solo artefacto — una página de Notion, una sala de DocSend, una colección de Highspot — para manejar su revisión interna. Concretamente:
Después de un call de plan acordado mutuamente, cuando el rep necesita enviar al buying committee un set curado de assets que le hablen a cada persona en la sala.
Antes del kickoff de revisión de procurement / security, para ensamblar los artefactos que procurement va a pedir igual.
Cuando el AE está rolleando una evaluación con múltiples stakeholders y quiere que cada persona aterrice primero en la página que efectivamente atiende sus criterios de decisión.
La skill asume que ya hiciste el trabajo de discovery y produjiste un account brief — el output de account-research-claude-skill es el formato de input canónico, pero cualquier brief estructurado con stakeholders nombrados, prioridades estratégicas y una hipótesis de wedge-pain funciona.
Cuándo NO usar
Auto-publicar un deal-room sin revisión del rep. El SKILL.md del bundle es explícito: el output es un outline más un draft de mapeo de assets. Un AE humano selecciona, redacta y aprueba antes de que el comprador vea cualquier cosa. La skill nunca envía, nunca publica.
Deals que aún no están en una etapa de plan acordado mutuamente. Las etapas de pre-discovery, calificación y demo temprana no necesitan un deal room. Mandar uno temprano se lee como una forcing function que el comprador no pidió, y entrena al comprador a anclarse en términos comerciales antes de que la conversación de valor haya aterrizado.
Renewals donde no se requiere collateral nuevo. Un deck de QBR y un reporte de uso no son un deal room.
Logos net-new pre-NDA, para las secciones de security y pricing. La skill se rehúsa a poblar esas secciones sin nda_signed: true en el input.
Setup
Pon el bundle en el directorio de Skills del equipo. Copia apps/web/public/artifacts/deal-room-generator-skill/SKILL.md y los tres archivos de referencia en tu carpeta de Skills. La skill lee de references/ en cada invocación, así que el layout del directorio importa.
Reemplaza el template de inventario de assets con el real. Edita references/1-asset-inventory-template.md para que la tabla refleje tu librería de collateral real — cada asset con type, personas, stages, last_updated, nda_required y link. Cualquier cosa que falte se trata como “do not select”; la skill prefiere la omisión a adivinar.
Afina la matriz de stage-to-asset. El default en references/2-stage-to-asset-matrix.md es conservador — pricing gateado a proposal o más tarde, artefactos de security solo con NDA, references de customer nombrado solo con NDA. Si tu política comercial es distinta, edita la matriz; la skill cita el path de la matriz en cada output, así que las desviaciones de la política del equipo son auditables.
Cablea el acceso de lectura a Salesforce si quieres que la skill jale stakeholders directamente de los contact roles de la Opportunity. Opcional — la mayoría de los reps pasan el mapa de stakeholders a mano desde sus notas, lo cual tiende a ser más preciso que los contact roles igual.
Cablea Notion (o DocSend, o Highspot) como destino de publicación. La skill produce el outline; un paso separado de publicación convierte el outline en un artefacto hacia el comprador. La publicación es intencionalmente manual — ver “Cuándo NO usar.”
Prueba en una cuenta. Toma una opportunity que conozcas al dedillo — preferentemente una que ya cerró, donde puedas comparar el outline de la skill contra lo que efectivamente despachaste. Spot-check del mapeo de personas y las secciones gateadas por NDA. Afina la matriz y el inventario de assets en consecuencia.
Qué hace la skill en realidad
La skill corre cinco sub-tareas secuenciales, todas documentadas en el SKILL.md del bundle:
Valida la etapa y el gating. Cross-referencia deal_stage y nda_signed contra la matriz. Las secciones gateadas se emiten como “gated: NDA required” en lugar de omitirse silenciosamente, así el rep puede ver qué se está conteniendo y perseguir el NDA explícitamente.
Mapea assets a stakeholders, no a etapa del deal. Para cada stakeholder nombrado, la skill camina el inventario de assets y selecciona los uno a tres assets que matchean la persona y la seniority. Un CFO recibe primero el calculador de ROI y el one-pager de pricing; un Director de Engineering recibe primero el diagrama de arquitectura y el resumen de SOC 2; un lead end-user recibe primero el video walkthrough del workflow. Los packs de assets manejados por etapa (el approach obvio) producen el mismo deal-room para cada comprador en la misma etapa. El mapeo manejado por persona fuerza al AE a pensar sobre la gente real en la sala.
Construye un arco narrativo de tres actos. “Why act” cita una prioridad estratégica del account brief, en el lenguaje del comprador. “Why us” jala un proof point por persona presente. “Why now” es el resumen del close-plan — cómo se ven los próximos 14 a 30 días y qué owna cada rol del lado del comprador.
Capa secciones específicas de etapa. Pricing solo aparece en proposal o más tarde. Artefactos de security solo con nda_signed: true. La matriz hace cumplir esto incluso cuando el rep está impaciente.
Emite preguntas de gap. Para cada sección donde el rep necesita hacer un juicio — elegir una reference específica, confirmar una banda de descuento, confirmar una fecha de implementación — una pregunta jalada de references/3-rep-gap-questions.md aparece bajo “Rep gaps to fill.” Estas son deliberadamente bloqueantes: el outline del deal-room no está “listo” hasta que el rep las responda.
El output es un archivo Markdown con el arco narrativo inline, una tabla de mapeo de stakeholder a asset, un checklist de secciones a publicar (con razones de gating anotadas), y la lista de preguntas de gap al fondo. Mira la sección “Output format” en el SKILL.md del bundle para el template literal.
Realidad de costos
Por generación de deal-room, el costo de tokens aterriza en el rango de unos centavos a menos de un dólar — típicamente alrededor de 8k-15k tokens de input (account brief, mapa de stakeholders, inventario de assets, matriz, referencia de gap-questions) y 2k-4k tokens de output. En Claude Sonnet a aproximadamente $3 por millón de input y $15 por millón de output, eso es del orden de $0.06 a $0.10 por deal room.
El tiempo ahorrado por AE es el número mayor. El workflow de hand-curation corre dos a tres horas por opportunity de etapa tardía: elegir el case study correcto de la librería de assets, escribir el arco narrativo, redactar el FAQ, decidir qué artefactos de security son compartibles pre-NDA, construir la tabla de close-plan. La skill comprime esto a un pase de revisión de 15 a 25 minutos sobre un outline generado. Para un AE corriendo 6-10 deals con plan de acción mutuo a la vez, eso es 12-30 horas por trimestre de vuelta por rep.
El costo que es más difícil de cuantificar pero es el punto real: deal-rooms que se despachan más rápido, con collateral mapeado por persona, cierran a tasas más altas que deal-rooms llenos de links genéricos de “todo lo que tenemos.” La skill hace que la versión disciplinada sea barata lo suficiente para hacerla cada vez.
Métrica de éxito
La métrica a vigilar para que se mueva es tiempo desde el call de plan-mutuo hasta deal-room enviado. Pre-skill, la mediana en un equipo SaaS típico se sienta alrededor de dos a tres días hábiles; post-skill, debería aterrizar en menos de un día. Si la métrica no se mueve, la skill se está tratando como un generador que el AE corre y descarta en lugar de un draft que edita y despacha — usualmente una señal de que el inventario de assets está stale o el mapeo de personas está disparando en stakeholders de baja confianza.
Una métrica secundaria: NDA turn time. Con los callouts de “NDA required” en secciones gateadas saliendo explícitamente a la luz en cada outline, los reps tienden a perseguir NDAs antes; espera ver el tiempo de ejecución de NDA caer después de unos sprints de usar la skill.
vs alternativas
vs. DealHub — DealHub es un producto completo de digital sales room: branded, hosteado, con analytics de engagement y orquestación de contratos. Es la respuesta correcta para un equipo que quiere una experiencia productizada hacia el comprador y está dispuesto a estandarizar en los templates de un vendor y pagar por-asiento. La skill es la respuesta correcta cuando el equipo ya tiene el destino de publicación (Notion, Highspot, DocSend) y quiere el juicio upstream — qué assets, en qué orden, para qué persona, gateado por qué — hecho consistentemente entre reps sin comprar otra herramienta.
vs. GetAccept — Forma similar a DealHub. La fortaleza de GetAccept es la capa de e-signature y engagement-tracking; la skill deja eso a lo que tu equipo ya use y se enfoca en el paso de content design del deal-room que GetAccept asume que el rep ya hizo.
vs. construir deal-rooms manualmente en Notion — Esto es lo que la mayoría de los equipos efectivamente hacen. Funciona, y es la comparación más cercana. La diferencia que la skill hace es consistencia: la disciplina de mapeo de personas, el gating de NDA, los prompts de gap-question. Un AE senior haciendo esto a mano va a producir algo cercano al output de la skill; un AE junior haciéndolo a mano se va a saltar las gap questions y va a despachar pricing pre-NDA. La skill hace que el output del AE senior sea el piso.
Watch-outs
Compartir collateral pre-NDA. La matriz en references/2-stage-to-asset-matrix.md se rehúsa a poblar secciones de security, arquitectura detallada y reference de customer nombrado sin nda_signed: true. Las secciones gateadas aparecen en el outline como “gated: NDA required” para que el rep pueda ver qué se está conteniendo; la omisión silenciosa dejaría que un rep despache un deal-room incompleto sin darse cuenta de qué pasó por encima.
Mismatch de persona. La inferencia basada en título puede poner el asset equivocado frente a la persona equivocada — un “VP Operations” puede ser el economic buyer en una empresa y un blocker en otra. La skill emite una nota de confianza por stakeholder y saca a la luz mapeos de baja confianza bajo “Rep gaps to fill” en lugar de fijarlos.
Assets stale. Deal-rooms llenos de case studies de dos años y páginas de pricing reemplazadas hacen más daño que ningún deal-room. El formato de inventario de assets requiere una fecha last_updated en cada entrada; la skill flaggea cualquier asset seleccionado más viejo que nueve meses en el output como stale? para que el rep lo refresque o lo quite antes de publicar.
Drift narrativo. Es fácil que la narrativa sugerida divague hacia positioning genérico. El párrafo “Why act” debe citar una prioridad estratégica del account brief; si no hay prioridad estratégica disponible, la sección se emite como “REQUIRES INPUT — no strategic priority in brief” en lugar de llenarse con perogrulladas.
Hábito de publicar como un generador. La skill produce un outline, no un artefacto terminado. Los reps que tratan el output como el artefacto despachan deal-rooms con nombres de customer placeholder y fechas de go-live no comprometidas. Trata la lista de gap-questions como bloqueante antes de publicar.
Stack
Claude — drafting de narrativa, mapeo de personas, selección de gap-question
Salesforce — fuente opcional para jalar stakeholders desde los contact roles de Opportunity
Notion / DocSend / Highspot — destino de publicación para el deal-room final hacia el comprador (la publicación es manual a propósito)
El inventario de assets — la librería de collateral existente de tu equipo, catalogada en el formato que los archivos de referencia del bundle especifican
---
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}
