Ein Claude Skill, der ein Account-Briefing, die aktuelle Deal-Stage, die benannte Stakeholder-Map und das Collateral-Inventar des Teams nimmt und einen strukturierten käuferseitigen Deal-Room-Outline produziert. Der Outline ordnet jeden Stakeholder den Assets zu, die ihn bewegen, schlägt einen Drei-Akt-Narrativbogen vor, sperrt Preisgestaltungs- und Sicherheits-Artefakte hinter Deal-Stage und NDA-Status und gibt eine Liste von Gap-Questions aus, die der AE beantworten muss, bevor der Deal-Room geteilt werden kann.
Der Skill ersetzt die zwei bis drei Stunden, die ein AE damit verbringt, Collateral manuell für einen Mutual-Action-Plan-Käufer zu kuratieren, ohne das Urteilsvermögen des AE darüber zu ersetzen, welchen namentlichen Referenzkunden er verwendet, welches Rabattband im Spiel ist oder ob der Käufer dem Close-Plan-Timeline tatsächlich zugestimmt hat.
Wann einsetzen
Greifen Sie darauf zurück, wenn eine Opportunity in der Late-Stage-Motion ist und der Käufer ein einzelnes Artefakt benötigt — eine Notion-Seite, einen DocSend-Room, eine Highspot-Collection — um seine interne Überprüfung voranzutreiben. Konkret:
Nach einem Mutual-Action-Plan-Call, wenn der Rep dem Buying Committee einen kuratierten Satz von Assets senden muss, die jeden Persona ansprechen.
Vor einem Procurement- oder Security-Review-Kickoff, um die Artefakte zusammenzustellen, nach denen Procurement sowieso fragen wird.
Wenn der AE eine Multi-Stakeholder-Evaluierung zusammenführt und möchte, dass jede Persona zuerst auf der Seite landet, die tatsächlich ihre Entscheidungskriterien anspricht.
Der Skill setzt voraus, dass Sie die Discovery-Arbeit bereits geleistet und ein Account-Briefing erstellt haben — der account-research-claude-skill-Output ist das kanonische Input-Format, aber jedes strukturierte Briefing mit benannten Stakeholdern, strategischen Prioritäten und einer Wedge-Pain-Hypothese funktioniert.
Wann NICHT einsetzen
Auto-Publishing eines Deal-Rooms ohne Rep-Review. Das SKILL.md des Bundles ist explizit: Der Output ist ein Outline plus ein Asset-Mapping-Entwurf. Ein menschlicher AE wählt aus, redigiert und genehmigt, bevor der Käufer irgendetwas sieht. Der Skill sendet nie, veröffentlicht nie.
Deals, die noch nicht in einer Mutually-Agreed-Plan-Stage sind. Pre-Discovery, Qualifizierung und frühe Demo-Stages brauchen keinen Deal-Room. Einen früh zu senden liest sich als erzwungenes Mittel, das der Käufer nicht angefordert hat, und trainiert den Käufer, sich auf kommerzielle Bedingungen zu konzentrieren, bevor das Value-Gespräch gelandet ist.
Verlängerungen, bei denen kein neues Collateral erforderlich ist. Ein QBR-Deck und ein Nutzungsbericht sind kein Deal-Room.
Neulogos vor NDA, für die Sicherheits- und Preisgestaltungsabschnitte. Der Skill weigert sich, diese Abschnitte ohne nda_signed: true im Input zu befüllen.
Einrichtung
Bundle in das Skills-Verzeichnis des Teams ablegen. Kopieren Sie apps/web/public/artifacts/deal-room-generator-skill/SKILL.md und die drei Referenzdateien in Ihren Skills-Ordner. Der Skill liest bei jeder Ausführung aus references/, daher ist das Verzeichnis-Layout wichtig.
Asset-Inventar-Vorlage durch das Echte ersetzen. Bearbeiten Sie references/1-asset-inventory-template.md, sodass die Tabelle Ihre tatsächliche Collateral-Bibliothek widerspiegelt — jedes Asset mit type, personas, stages, last_updated, nda_required und link. Fehlendes wird als „nicht auswählen” behandelt; der Skill bevorzugt Weglassung gegenüber Raten.
Stage-to-Asset-Matrix einstellen. Der Default in references/2-stage-to-asset-matrix.md ist konservativ — Preisgestaltung gesperrt bis proposal oder später, Sicherheits-Artefakte nur mit NDA, namentliche Kundenreferenzen nur mit NDA. Wenn Ihre kommerzielle Policy anders ist, bearbeiten Sie die Matrix; der Skill zitiert den Matrixpfad in jedem Output, sodass Abweichungen von der Team-Policy auditierbar sind.
Salesforce-Lesezugriff verdrahten, wenn der Skill Stakeholder direkt aus den Opportunity Contact Roles ziehen soll. Optional — die meisten Reps übergeben die Stakeholder-Map von Hand aus ihren Notizen, was tendenziell genauer ist als die Contact Roles ohnehin.
Notion (oder DocSend oder Highspot) als Publishing-Ziel verdrahten. Der Skill produziert den Outline; ein separater Publishing-Schritt macht den Outline zu einem käuferseitigen Artefakt. Publishing ist absichtlich manuell — siehe „Wann NICHT einsetzen”.
Auf einem Account testen. Wählen Sie eine Opportunity, die Sie in- und auswendig kennen — vorzugsweise eine, die bereits abgeschlossen ist, bei der Sie den Outline des Skills gegen das vergleichen können, was Sie tatsächlich verschickt haben. Prüfen Sie das Persona-Mapping und die NDA-gesperrten Abschnitte stichprobenartig. Passen Sie die Matrix und das Asset-Inventar entsprechend an.
Was der Skill tatsächlich macht
Der Skill führt fünf sequenzielle Sub-Tasks aus, die alle im SKILL.md des Bundles dokumentiert sind:
Stage und Gating validieren. Kreuzt deal_stage und nda_signed gegen die Matrix. Gesperrte Abschnitte werden als „gesperrt: NDA erforderlich” ausgegeben statt still weggelassen, sodass der Rep sehen kann, was zurückgehalten wird, und explizit nach dem NDA fragen kann.
Assets Stakeholdern zuordnen, nicht der Deal-Stage. Für jeden benannten Stakeholder geht der Skill durch das Asset-Inventar und wählt ein bis drei Assets aus, die zur Persona und Seniorität passen. Ein CFO erhält zuerst den ROI-Rechner und den Preisgestaltungs-One-Pager; ein Director of Engineering erhält zuerst das Architekturdiagramm und die SOC-2-Zusammenfassung; ein End-User-Lead erhält zuerst das Workflow-Walkthrough-Video. Stage-getriebene Asset-Packs (der offensichtliche Ansatz) produzieren denselben Deal-Room für jeden Käufer in derselben Stage. Persona-gesteuertes Mapping zwingt den AE, über die tatsächlichen Menschen im Raum nachzudenken.
Drei-Akt-Narrativbogen aufbauen. „Why act” zitiert eine strategische Priorität aus dem Account-Briefing in der eigenen Sprache des Käufers. „Why us” zieht einen Beweis-Punkt pro anwesender Persona. „Why now” ist die Close-Plan-Zusammenfassung — wie die nächsten 14 bis 30 Tage aussehen und was jede Rolle auf Käuferseite besitzt.
Stage-spezifische Abschnitte einschichten. Preisgestaltung erscheint nur bei proposal oder später. Sicherheits-Artefakte nur mit nda_signed: true. Die Matrix erzwingt dies auch wenn der Rep ungeduldig ist.
Gap-Questions ausgeben. Für jeden Abschnitt, in dem der Rep eine Ermessensentscheidung treffen muss — einen spezifischen Referenzkunden auswählen, ein Rabattband bestätigen, ein Implementierungsdatum bestätigen — erscheint eine aus references/3-rep-gap-questions.md gezogene Frage unter „Rep-Gaps to fill.” Diese sind absichtlich blockierend: Der Deal-Room-Outline ist nicht „fertig”, bis der Rep sie beantwortet hat.
Der Output ist eine Markdown-Datei mit dem Narrativbogen inline, einer Stakeholder-zu-Asset-Mapping-Tabelle, einer Checkliste von zu veröffentlichenden Abschnitten (mit Gating-Gründen annotiert) und der Gap-Questions-Liste am Ende. Siehe den „Output format”-Abschnitt im SKILL.md des Bundles für die wörtliche Vorlage.
Kostenrealität
Pro Deal-Room-Generierung landen die Token-Kosten im Bereich von wenigen Cents bis unter einem Dollar — typischerweise rund 8k–15k Input-Token (Account-Briefing, Stakeholder-Map, Asset-Inventar, Matrix, Gap-Questions-Referenz) und 2k–4k Output-Token. Auf Claude Sonnet bei etwa 3 $ pro Million Input und 15 $ pro Million Output sind das in der Größenordnung von 0,06 bis 0,10 $ pro Deal-Room.
Die eingesparte Zeit pro AE ist die größere Zahl. Der manuelle Kurations-Workflow läuft zwei bis drei Stunden pro Late-Stage-Opportunity: Die richtige Fallstudie aus der Asset-Bibliothek auswählen, den Narrativbogen schreiben, die FAQ entwerfen, entscheiden, welche Sicherheits-Artefakte vor NDA teilbar sind, die Close-Plan-Tabelle aufbauen. Der Skill komprimiert dies auf einen 15- bis 25-minütigen Review-Pass über einen generierten Outline. Für einen AE mit 6–10 Mutual-Action-Plan-Deals gleichzeitig sind das 12–30 Stunden pro Quartal zurück pro Rep.
Die Kosten, die schwieriger zu quantifizieren sind, aber der eigentliche Punkt sind: Deal-Rooms, die schneller versendet werden, mit persona-gemapptem Collateral, schließen zu höheren Raten als Deal-Rooms voller generischer „alles was wir haben”-Links. Der Skill macht die disziplinierte Version günstig genug, um sie jedes Mal zu tun.
Erfolgsmetrik
Die zu beobachtende Metrik ist die Zeit vom Mutual-Plan-Call bis zum versandten Deal-Room. Vor dem Skill liegt der Median in einem typischen SaaS-Team bei etwa zwei bis drei Werktagen; nach dem Skill sollte er unter einem Tag landen. Wenn die Metrik sich nicht bewegt, wird der Skill als Generator behandelt, den der AE ausführt und verwirft, anstatt als Entwurf, den er bearbeitet und versendet — in der Regel ein Zeichen dafür, dass das Asset-Inventar veraltet ist oder das Persona-Mapping bei Stakeholdern mit geringer Konfidenz feuert.
Eine sekundäre Metrik: NDA-Turn-Zeit. Mit den in jedem Outline explizit aufgezeigten gesperrten Abschnitt-„NDA erforderlich”-Callouts neigen Reps dazu, NDAs früher zu verfolgen; erwarten Sie, dass die NDA-Ausführungszeit nach einigen Sprints mit dem Skill sinkt.
Vergleich mit Alternativen
vs. DealHub — DealHub ist ein vollständiges Digital-Sales-Room-Produkt: gebrandmarkt, gehostet, mit Engagement-Analytics und Contract-Orchestration. Es ist die richtige Antwort für ein Team, das ein produktisiertes Käufer-Erlebnis möchte und bereit ist, sich auf die Templates eines Anbieters zu standardisieren und pro Seat zu zahlen. Der Skill ist die richtige Antwort, wenn das Team bereits das Publishing-Ziel hat (Notion, Highspot, DocSend) und das vorgelagerte Urteilsvermögen — welche Assets, in welcher Reihenfolge, für welche Persona, gesperrt durch was — konsistent über Reps hinweg getan haben möchte, ohne ein weiteres Tool zu kaufen.
vs. GetAccept — Ähnliche Form wie DealHub. GetAccepts Stärke liegt in der E-Signatur- und Engagement-Tracking-Schicht; der Skill überlässt das, was Ihr Team bereits verwendet, und konzentriert sich auf den Deal-Room-Content-Design-Schritt, den GetAccept voraussetzt, dass der Rep bereits getan hat.
vs. Deal-Rooms manuell in Notion aufbauen — Das ist es, was die meisten Teams tatsächlich tun. Es funktioniert und ist der engste Vergleich. Der Unterschied, den der Skill macht, ist Konsistenz: die Persona-Mapping-Disziplin, das NDA-Gating, die Gap-Question-Prompts. Ein erfahrener AE, der das von Hand tut, wird etwas produzieren, das dem Output des Skills nahekommt; ein Junior-AE, der es von Hand tut, wird die Gap-Questions überspringen und Preisgestaltung vor NDA versenden. Der Skill macht den Output des erfahrenen AE zum Floor.
Watch-outs
Collateral vor NDA teilen. Die Matrix in references/2-stage-to-asset-matrix.md weigert sich, Sicherheits-, detaillierte Architektur- und namentliche Kundenreferenz-Abschnitte ohne nda_signed: true zu befüllen. Gesperrte Abschnitte erscheinen im Outline als „gesperrt: NDA erforderlich”, sodass der Rep sehen kann, was zurückgehalten wird; stille Weglassung würde einem Rep erlauben, einen unvollständigen Deal-Room zu versenden, ohne zu bemerken, was er übersprungen hat.
Persona-Mismatch. Titel-basierte Inferenz kann das falsche Asset vor die falsche Person stellen — ein „VP Operations” könnte bei einem Unternehmen der wirtschaftliche Käufer sein und bei einem anderen ein Blocker. Der Skill gibt eine Per-Stakeholder-Konfidenznotiz aus und zeigt Mappings mit geringer Konfidenz unter „Rep-Gaps to fill” auf, anstatt sie festzuschreiben.
Veraltete Assets. Deal-Rooms voller zwei Jahre alter Fallstudien und überholter Preisseiten richten mehr Schaden an als gar kein Deal-Room. Das Asset-Inventar-Format verlangt ein last_updated-Datum für jeden Eintrag; der Skill flaggt jedes ausgewählte Asset, das älter als neun Monate ist, im Output als stale?, damit der Rep es vor dem Veröffentlichen auffrischt oder entfernt.
Narrative Drift. Es ist leicht, dass der vorgeschlagene Narrativ ins generische Positioning abdriftet. Der „Why act”-Absatz muss eine strategische Priorität aus dem Account-Briefing zitieren; wenn keine strategische Priorität vorhanden ist, wird der Abschnitt als „ERFORDERT INPUT — keine strategische Priorität im Briefing” ausgegeben statt mit Plattitüden gefüllt.
Publishing als Generator-Gewohnheit. Der Skill produziert einen Outline, kein fertiges Artefakt. Reps, die den Output als Artefakt behandeln, versenden Deal-Rooms mit Platzhalter-Kundennamen und nicht bestätigten Go-Live-Daten. Behandeln Sie die Gap-Questions-Liste als blockierend vor dem Veröffentlichen.
Stack
Claude — Narrativ-Entwurf, Persona-Mapping, Gap-Question-Auswahl
Salesforce — optionale Quelle für Stakeholder-Ziehungen aus Opportunity Contact Roles
Notion / DocSend / Highspot — Publishing-Ziel für den finalen käuferseitigen Deal-Room (Publishing ist absichtlich manuell)
Das Asset-Inventar — die bestehende Collateral-Bibliothek Ihres Teams, katalogisiert im Format, das die Referenzdateien des Bundles spezifizieren
---
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}
