Un Claude Skill qui prend un brief de compte, l’étape actuelle de la transaction, la carte des parties prenantes nommées, et l’inventaire de supports de l’équipe, et produit un plan structuré de deal room orienté acheteur. Le plan mappe chaque partie prenante aux actifs qui la font avancer, propose un arc narratif en trois actes, conditionne les actifs de tarification et de sécurité à l’étape de la transaction et au statut NDA, et émet une liste de questions de lacunes que le commercial doit combler avant que la deal room puisse être partagée.
Le skill remplace les deux à trois heures qu’un commercial passe à sélectionner manuellement des supports pour un acheteur sur un mutual-action-plan, sans remplacer le jugement du commercial sur le client de référence nommé à utiliser, la fourchette de remise en jeu, ou si l’acheteur a réellement accepté le calendrier du plan de clôture.
Quand utiliser
Mobilisez-le quand une opportunité est dans le mouvement en phase avancée et que l’acheteur a besoin d’un artefact unique — une page Notion, une salle DocSend, une collection Highspot — pour piloter sa revue interne. Concrètement :
Après un appel avec un plan mutuellement convenu, quand le commercial doit envoyer au comité d’achat un ensemble curated d’actifs s’adressant à chaque persona dans la pièce.
Avant le démarrage d’une revue procurement / sécurité, pour assembler les actifs que le procurement va de toute façon demander.
Quand le commercial gère une évaluation multi-parties prenantes et veut que chaque persona atterrisse en premier sur la page qui adresse réellement ses critères de décision.
Le skill suppose que vous avez déjà effectué le travail de découverte et produit un brief de compte — la sortie de account-research-claude-skill est le format d’input canonique, mais tout brief structuré avec des parties prenantes nommées, des priorités stratégiques, et une hypothèse de wedge-pain fonctionne.
Quand NE PAS utiliser
Publication automatique d’une deal room sans révision du commercial. Le SKILL.md du bundle est explicite : la sortie est un plan plus un brouillon de mapping d’actifs. Un commercial humain sélectionne, rédige, et approuve avant que l’acheteur voie quoi que ce soit. Le skill n’envoie jamais, ne publie jamais.
Transactions pas encore en phase de plan mutuellement convenu. Les phases de pré-découverte, qualification, et démo précoce n’ont pas besoin d’une deal room. En envoyer une tôt se lit comme un mécanisme de forçage que l’acheteur n’a pas demandé, et conditionne l’acheteur à s’ancrer sur les conditions commerciales avant que la conversation de valeur ait atterri.
Renouvellements où aucun nouveau support n’est requis. Un deck de QBR et un rapport d’usage ne constituent pas une deal room.
Nouveaux logos pré-NDA pour les sections sécurité et tarification. Le skill refuse de renseigner ces sections sans nda_signed: true dans l’input.
Configuration
Déposer le bundle dans le répertoire Skills de l’équipe. Copiez apps/web/public/artifacts/deal-room-generator-skill/SKILL.md et les trois fichiers de référence dans votre dossier Skills. Le skill lit depuis references/ à chaque invocation, donc la disposition du répertoire compte.
Remplacer le modèle d’inventaire d’actifs par le vrai. Modifiez references/1-asset-inventory-template.md pour que le tableau reflète votre bibliothèque de supports réelle — chaque actif avec type, personas, stages, last_updated, nda_required, et link. Tout ce qui manque est traité comme « ne pas sélectionner » ; le skill préfère l’omission à la devinette.
Affiner la matrice étape-vers-actif. La valeur par défaut dans references/2-stage-to-asset-matrix.md est conservative — tarification conditionnée à proposal ou plus tard, actifs de sécurité NDA-only, références clients nommées NDA-only. Si votre politique commerciale est différente, modifiez la matrice ; le skill cite le chemin de la matrice dans chaque sortie, donc les déviations de la politique d’équipe sont auditables.
Connecter l’accès en lecture Salesforce si vous souhaitez que le skill extraie les parties prenantes directement des rôles de contact de l’Opportunité. Optionnel — la plupart des commerciaux passent la carte des parties prenantes à la main depuis leurs notes, ce qui tend à être plus précis que les rôles de contact de toute façon.
Connecter Notion (ou DocSend, ou Highspot) comme cible de publication. Le skill produit le plan ; une étape de publication séparée transforme le plan en artefact orienté acheteur. La publication est intentionnellement manuelle — voir « Quand NE PAS utiliser ».
Tester sur un compte. Choisissez une opportunité que vous connaissez parfaitement — de préférence une qui a déjà conclu, où vous pouvez comparer le plan du skill avec ce que vous avez réellement livré. Vérifiez le mapping de persona et les sections conditionnées par NDA. Affinez la matrice et l’inventaire d’actifs en conséquence.
Ce que le skill fait réellement
Le skill exécute cinq sous-tâches séquentielles, toutes documentées dans le SKILL.md du bundle :
Valider l’étape et le conditionnement. Croise deal_stage et nda_signed contre la matrice. Les sections conditionnées sont émises comme « conditionné : NDA requis » plutôt que silencieusement omises, afin que le commercial puisse voir ce qui est retenu et poursuivre explicitement le NDA.
Mapper les actifs aux parties prenantes, pas à l’étape de la transaction. Pour chaque partie prenante nommée, le skill parcourt l’inventaire d’actifs et sélectionne un à trois actifs correspondant au persona et au niveau de séniorité. Un DG reçoit d’abord la calculatrice ROI et le résumé tarifaire ; un Directeur Ingénierie reçoit d’abord le diagramme d’architecture et le résumé SOC 2 ; un responsable utilisateurs finaux reçoit d’abord la vidéo de démonstration workflow. Les packs d’actifs pilotés par étape (l’approche évidente) produisent la même deal room pour chaque acheteur à la même étape. Le mapping piloté par persona force le commercial à penser aux personnes réelles dans la pièce.
Construire un arc narratif en trois actes. « Pourquoi agir » cite une priorité stratégique du brief de compte, dans le propre langage de l’acheteur. « Pourquoi nous » extrait une preuve par persona présent. « Pourquoi maintenant » est le résumé du plan de clôture — à quoi ressemblent les 14 à 30 prochains jours et ce que chaque rôle côté acheteur possède.
Intégrer des sections spécifiques à l’étape. La tarification n’apparaît qu’à proposal ou plus tard. Les actifs de sécurité uniquement avec nda_signed: true. La matrice applique cela même quand le commercial est impatient.
Émettre les questions de lacunes. Pour chaque section où le commercial doit prendre un jugement — choisir une référence spécifique, confirmer une fourchette de remise, confirmer une date d’implémentation — une question extraite de references/3-rep-gap-questions.md apparaît sous « Lacunes du commercial à combler ». Ces questions sont délibérément bloquantes : le plan de deal room n’est pas « fait » jusqu’à ce que le commercial y réponde.
La sortie est un fichier Markdown avec l’arc narratif inline, un tableau de mapping partie prenante-vers-actif, une checklist de sections à publier (avec les raisons de conditionnement annotées), et la liste de questions de lacunes en bas. Voir la section « Format de sortie » dans le SKILL.md du bundle pour le modèle littéral.
Réalité des coûts
Par génération de deal room, le coût en tokens se situe dans une plage de quelques centimes à moins d’un dollar — typiquement environ 8 000 à 15 000 tokens en entrée (brief de compte, carte des parties prenantes, inventaire d’actifs, matrice, référence de questions de lacunes) et 2 000 à 4 000 tokens en sortie. Sur Claude Sonnet à environ 3 $ par million en entrée et 15 $ par million en sortie, c’est de l’ordre de 0,06 à 0,10 $ par deal room.
Le temps économisé par commercial est le chiffre plus important. Le workflow de sélection manuelle prend deux à trois heures par opportunité en phase avancée : choisir la bonne étude de cas dans la bibliothèque d’actifs, écrire l’arc narratif, rédiger la FAQ, décider quels actifs de sécurité sont partageables avant NDA, construire le tableau du plan de clôture. Le skill comprime cela à une passe de révision de 15 à 25 minutes sur un plan généré. Pour un commercial gérant 6 à 10 transactions avec mutual-action-plan simultanément, c’est 12 à 30 heures par trimestre restituées par commercial.
Le coût plus difficile à quantifier mais qui est le vrai point : les deal rooms qui partent plus vite, avec des supports mappés par persona, ont des taux de clôture supérieurs aux deal rooms pleines de liens génériques « tout ce que nous avons ». Le skill rend la version disciplinée assez bon marché pour la faire à chaque fois.
Mesure de succès
La métrique à observer évoluer est le temps entre l’appel mutual-plan et l’envoi de la deal room. Avant le skill, la médiane dans une équipe SaaS typique se situe autour de deux à trois jours ouvrés ; après le skill, elle devrait atterrir sous un jour. Si la métrique ne bouge pas, le skill est traité comme un générateur que le commercial exécute et écarte plutôt que comme un brouillon qu’il modifie et envoie — généralement signe que l’inventaire d’actifs est obsolète ou que le mapping de persona se déclenche sur des parties prenantes à faible confiance.
Une métrique secondaire : le délai d’exécution NDA. Avec les callouts « NDA requis » des sections conditionnées remontés explicitement dans chaque plan, les commerciaux tendent à poursuivre les NDAs plus tôt ; attendez-vous à voir le délai d’exécution NDA baisser après quelques sprints d’utilisation du skill.
Par rapport aux alternatives
vs DealHub — DealHub est un produit complet de salle de vente digitale : marque, hébergé, avec des analyses d’engagement et une orchestration de contrats. C’est la bonne réponse pour une équipe qui veut une expérience acheteur productisée et est prête à se standardiser sur les modèles d’un fournisseur et à payer par siège. Le skill est la bonne réponse quand l’équipe a déjà la cible de publication (Notion, Highspot, DocSend) et veut le jugement en amont — quels actifs, dans quel ordre, pour quel persona, conditionné par quoi — fait de manière cohérente entre les commerciaux sans acheter un autre outil.
vs GetAccept — Forme similaire à DealHub. La force de GetAccept est la couche de signature électronique et de suivi d’engagement ; le skill laisse cela à ce que votre équipe utilise déjà et se concentre sur l’étape de conception du contenu de la deal room que GetAccept suppose que le commercial a déjà faite.
vs construire des deal rooms manuellement dans Notion — C’est ce que la plupart des équipes font réellement. Cela fonctionne, et c’est la comparaison la plus proche. La différence que fait le skill est la cohérence : la discipline de mapping de persona, le conditionnement NDA, les invitations aux questions de lacunes. Un commercial senior faisant cela à la main produira quelque chose de proche de la sortie du skill ; un commercial junior faisant cela à la main sautera les questions de lacunes et enverra la tarification avant NDA. Le skill fait de la sortie du commercial senior le plancher.
Points de vigilance
Partager des supports avant NDA. La matrice dans references/2-stage-to-asset-matrix.md refuse de renseigner les sections sécurité, architecture-détaillée, et références-clients-nommées sans nda_signed: true. Les sections conditionnées apparaissent dans le plan comme « conditionné : NDA requis » afin que le commercial puisse voir ce qui est retenu ; une omission silencieuse laisserait un commercial envoyer une deal room incomplète sans réaliser ce qu’il a passé outre.
Inadéquation de persona. L’inférence basée sur le titre peut mettre le mauvais actif devant la mauvaise personne — un « VP Operations » peut être l’acheteur économique dans une entreprise et un bloqueur dans une autre. Le skill émet une note de confiance par partie prenante et remonte les mappings à faible confiance sous « Lacunes du commercial à combler » plutôt que de les verrouiller.
Actifs obsolètes. Des deal rooms pleines d’études de cas vieilles de deux ans et de pages de tarification dépassées font plus de dégâts qu’aucune deal room. Le format de l’inventaire d’actifs exige une date last_updated sur chaque entrée ; le skill signale tout actif sélectionné de plus de neuf mois dans la sortie comme obsolète ? afin que le commercial le rafraîchisse ou le supprime avant de publier.
Dérive narrative. Il est facile que le narratif suggéré dérive vers un positionnement générique. Le paragraphe « Pourquoi agir » doit citer une priorité stratégique du brief de compte ; si aucune priorité stratégique n’est disponible, la section est émise comme « NÉCESSITE INPUT — aucune priorité stratégique dans le brief » plutôt que remplie de platitudes.
Publier dans une habitude de générateur. Le skill produit un plan, pas un artefact fini. Les commerciaux qui traitent la sortie comme l’artefact envoient des deal rooms avec des noms de clients génériques et des dates de mise en service non confirmées. Traitez la liste de questions de lacunes comme bloquante avant de publier.
Stack
Claude — rédaction narrative, mapping de persona, sélection de questions de lacunes
Salesforce — source optionnelle pour les extractions de parties prenantes depuis les rôles de contact de l’Opportunité
Notion / DocSend / Highspot — cible de publication pour la deal room finale orientée acheteur (la publication est manuelle intentionnellement)
L’inventaire d’actifs — votre bibliothèque de supports existante de l’équipe, cataloguée dans le format que les fichiers de référence du bundle spécifient
---
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}
