A Claude Skill that takes an account brief, the current deal stage, the named stakeholder map, and the team’s collateral inventory, and produces a structured buyer-facing deal-room outline. The outline maps each stakeholder to the assets that move them, proposes a three-act narrative arc, gates pricing and security artifacts behind the deal stage and NDA status, and emits a list of gap questions the AE has to answer before the deal-room can be shared.
The skill replaces the two-to-three hours an AE spends curating collateral by hand for a mutual-action-plan buyer, without replacing the AE’s judgment about which named reference customer to use, what discount band is in play, or whether the buyer has actually agreed to the close-plan timeline.
When to use
Reach for this when an opportunity is in the late-stage motion and the buyer needs a single artifact — a Notion page, a DocSend room, a Highspot collection — to drive their internal review. Concretely:
After a mutually-agreed-plan call, when the rep needs to send the buying committee a curated set of assets that speak to each persona in the room.
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 first on the page that actually addresses their decision criteria.
The skill assumes you have already done the discovery work and produced an account brief — the account-research-claude-skill output is the canonical input format, but any structured brief with named stakeholders, strategic priorities, and a wedge-pain hypothesis works.
When NOT to use
Auto-publishing a deal-room without rep review. The bundle’s SKILL.md is explicit: the output is an outline plus an asset-mapping draft. A human AE selects, redacts, and approves before the buyer sees anything. The skill never sends, never publishes.
Deals not yet in a mutually-agreed-plan stage. Pre-discovery, qualification, and early-demo stages do not need a deal room. Sending one early reads as a forcing function the buyer did not ask for, and trains the buyer to anchor on commercial terms before the value conversation has landed.
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 refuses to populate those sections without nda_signed: true on the input.
Setup
Drop the bundle into the team’s Skills directory. Copy apps/web/public/artifacts/deal-room-generator-skill/SKILL.md and the three reference files into your Skills folder. The skill reads from references/ on every invocation, so the directory layout matters.
Replace the asset inventory template with the real thing. Edit references/1-asset-inventory-template.md so the table reflects your actual collateral library — every asset with type, personas, stages, last_updated, nda_required, and link. Anything missing is treated as “do not select”; the skill prefers omission over guessing.
Tune the stage-to-asset matrix. The default in references/2-stage-to-asset-matrix.md is conservative — pricing gated to proposal or later, security artifacts NDA-only, named customer references NDA-only. If your commercial policy is different, edit the matrix; the skill cites the matrix path in every output, so deviations from team policy are auditable.
Wire Salesforce read access if you want the skill to pull stakeholders directly from the Opportunity contact roles. Optional — most reps pass the stakeholder map in by hand from their notes, which tends to be more accurate than the contact roles anyway.
Wire Notion (or DocSend, or Highspot) as the publishing target. The skill produces the outline; a separate publishing step turns the outline into a buyer-facing artifact. Publishing is intentionally manual — see “When NOT to use.”
Test on one account. Pick an opportunity you know cold — preferably one that already closed, where you can compare the skill’s outline against what you actually shipped. Spot-check the persona mapping and the NDA-gated sections. Tune the matrix and the asset inventory accordingly.
What the skill actually does
The skill runs five sequential sub-tasks, all documented in the bundle’s SKILL.md:
Validate stage and gating. Cross-references deal_stage and nda_signed against the matrix. Gated sections are emitted as “gated: NDA required” rather than silently omitted, so the rep can see what is being held back and chase the NDA explicitly.
Map assets to stakeholders, not to deal stage. For each named stakeholder, the skill walks the asset inventory and selects the one to three assets that match the persona and seniority. A CFO gets the ROI calculator and pricing one-pager first; a Director of Engineering gets the architecture diagram and SOC 2 summary first; an end-user lead gets the workflow walkthrough video first. 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.
Build a three-act narrative arc. “Why act” cites a strategic priority from the account brief, in the buyer’s own language. “Why us” pulls one proof point per persona present. “Why now” is the close-plan summary — what the next 14 to 30 days look like and what each role on the buyer side owns.
Layer in stage-specific sections. Pricing only appears at proposal or later. Security artifacts only with nda_signed: true. The matrix enforces this even when the rep is impatient.
Emit gap questions. For every section where the rep needs to make a judgment call — pick a specific reference, confirm a discount band, confirm an implementation date — a question pulled from references/3-rep-gap-questions.md appears under “Rep gaps to fill.” These are deliberately blocking: the deal-room outline is not “done” until the rep answers them.
The output is a Markdown file with the narrative arc inline, a stakeholder to asset mapping table, a checklist of sections to publish (with gating reasons annotated), and the gap-question list at the bottom. See the “Output format” section in the bundle’s SKILL.md for the literal template.
Cost reality
Per deal-room generation, the token cost lands in the range of a few cents to under a dollar — typically around 8k-15k input tokens (account brief, stakeholder map, asset inventory, matrix, gap-questions reference) and 2k-4k output tokens. On Claude Sonnet at roughly $3 per million input and $15 per million output, that is on the order of $0.06 to $0.10 per deal room.
Time-saved per AE is the larger number. The hand-curation workflow runs two to three hours per late-stage opportunity: pick the right case study from the asset library, write the narrative arc, draft the FAQ, decide which security artifacts are share-able pre-NDA, build the close-plan table. The skill compresses this to a 15-to-25-minute review pass over a generated outline. For an AE running 6-10 mutual-action-plan deals at a time, that is 12-30 hours per quarter back per rep.
The cost that is harder to quantify but is the actual point: deal-rooms that ship faster, with persona-mapped collateral, close at higher rates than deal-rooms full of generic “everything we have” links. The skill makes the disciplined version cheap enough to do every time.
Success metric
The metric to watch move is time from mutual-plan call to deal-room sent. Pre-skill, the median in a typical SaaS team sits around two to three business days; post-skill, it should land at under one day. If the metric does not move, the skill is being treated as a generator the AE runs and discards rather than as a draft they edit and ship — usually a sign that the asset inventory is stale or the persona-mapping is firing on low-confidence stakeholders.
A secondary metric: NDA turn time. With the gated-section “NDA required” callouts surfaced explicitly in every outline, reps tend to chase NDAs sooner; expect to see NDA execution time drop after a few sprints of using the skill.
vs alternatives
vs. DealHub — DealHub is a full digital sales room product: branded, hosted, with engagement analytics and contract orchestration. It is the right answer for a team that wants a productized buyer experience and is willing to standardize on a vendor’s templates and pay per-seat. The skill is the right answer when the team already has the publishing target (Notion, Highspot, DocSend) and wants the upstream judgment — which assets, in which order, for which persona, gated by what — done consistently across reps without buying another tool.
vs. GetAccept — Similar shape to DealHub. GetAccept’s strength is the e-signature and engagement-tracking layer; the skill leaves that to whatever your team already uses and focuses on the deal-room content design step that GetAccept assumes the rep has already done.
vs. building deal-rooms manually in Notion — This is what most teams actually do. It works, and is the closest comparison. The difference the skill makes is consistency: the persona-mapping discipline, the NDA gating, the gap-question prompts. A senior AE doing this by hand will produce something close to the skill’s output; a junior AE doing it by hand will skip the gap questions and ship pricing pre-NDA. The skill makes the senior-AE output the floor.
Watch-outs
Sharing collateral pre-NDA. The matrix in references/2-stage-to-asset-matrix.md refuses to populate security, detailed-architecture, and named customer-reference sections without nda_signed: true. Gated sections appear in the outline as “gated: NDA required” so the rep can see what is being held back; silent omission would let a rep ship an incomplete deal-room without realizing what they pushed past.
Persona mismatch. Title-based inference 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. The skill emits a per-stakeholder confidence note and surfaces low-confidence mappings under “Rep gaps to fill” rather than locking them in.
Stale assets. Deal-rooms full of two-year-old case studies and superseded pricing pages do more damage than no deal-room at all. The asset inventory format requires a last_updated date on every entry; the skill flags any selected asset older than nine months in the output as stale? so the rep refreshes or removes it before publishing.
Narrative drift. It is easy for the suggested narrative to wander into generic positioning. 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.
Publishing as a generator habit. The skill produces an outline, not a finished artifact. Reps who treat the output as the artifact ship deal-rooms with placeholder customer names and uncommitted go-live dates. Treat the gap-questions list as blocking before publishing.
Stack
Claude — narrative drafting, persona mapping, gap-question selection
Salesforce — optional source for stakeholder pulls from Opportunity contact roles
Notion / DocSend / Highspot — publishing target for the final buyer-facing deal-room (publishing is manual on purpose)
The asset inventory — your team’s existing collateral library, catalogued in the format the bundle’s reference files specify
---
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}
