Discovery Question Generator

discovery-question-generator turns a normalized fact sheet into a call-ready discovery plan. It is optimized for one target persona and one call goal at a time — not generic discovery boilerplate. Unknowns and risks from the fact sheet become explicit validation prompts instead of guesses.

What this skill is

A conversational discovery-planning workflow. You hand it a fact sheet (or a prior discovery artifact), a product area, a target persona, and a call goal, and it returns:

• A short summary.
• A discovery plan.
• Stakeholder questions tailored to the persona.
• A signal scorecard.
• Red flags.
• Citations or assumptions.

The skill is intentionally light on external research. It runs from prior artifacts and local notes. Firecrawl is used only when a missing claim blocks the plan.

Trigger conditions

Use this skill when the user asks for:

• Discovery questions.
• Stakeholder-specific call prep.
• A qualification plan for the next meeting.
• A signal scorecard.
• Red flags before talking to a champion or an exec.

Intake order

Codex asks one question at a time, in this order:

1. Fact sheet or prior discovery artifact — an artifactRef or a paste.
2. notes.productArea — what you are selling (for example, “Onboarding automation”).
3. notes.targetPersona — the specific persona on the call (for example, “RevOps lead”).
4. notes.callGoal — what a successful call looks like (for example, “Confirm scope and success metrics”).

If any of these already appear in the invocation, Codex skips the matching question.

Output shape

The artifact is returned in chat with these sections:

1. Summary
2. Discovery plan
3. Stakeholder questions
4. Signal scorecard
5. Red flags
6. Citations or assumptions

How to best use this skill

Bring a fact sheet. The generator is designed to consume a fact sheet from artifactRefs before falling back to raw notes. When you have run discovery-context-ingester first, this skill is sharper: the questions are tied to actual claims in the sheet, not a generic persona template.

Pick one persona per run. The plan is tuned to one stakeholder. If you have a call with a champion and an exec on the same day, run the skill twice — once per persona. Mixing personas dilutes the signal scorecard.

State the call goal as a decision. “Confirm scope and success metrics” or “Get signoff on a POC by end of call” shapes the plan. Vague goals like “learn more” produce vague questions.

Keep questions tied to the next decision. The skill is explicit about dropping generic discovery boilerplate. If you see filler questions in the output, your call goal is probably too broad.

Treat red flags as gating checks. The red flags section is not cosmetic. It surfaces the items that, if confirmed, should stop the deal from progressing into POC. Sort them by severity before the call.

Use signal scorecard live. The scorecard is designed to be read during the call. Each item is a yes/no signal you can tick off in real time.

Save is opt-in. The plan is returned in chat. Ask explicitly to save it to a markdown path.

How to combine with other skills

The question generator sits between discovery ingestion and the next call. Before it: ingestion. After it: demo prep or fit-gap, informed by what you learned.

• From Discovery Context Ingester. This is the preferred upstream. Unknowns and source gaps in the fact sheet become validation prompts.
• From Account Intel Brief. If no fact sheet exists, the brief’s initiatives and discovery question bank can seed the plan. The fact-sheet path is still preferred.
• Into Demo Scenario Builder. Questions that land on the call will refine the persona and success criteria you pass into the demo builder.
• Into Architecture Fit Mapper. Constraints you confirm during discovery flow into notes.constraints for the architecture map.
• Into Security Review Prep. Customer questions captured on the call can be passed into security prep as notes.customerQuestions.

Example invocations

Explicit:

$discovery-question-generator "Acme Health"

Natural language:

Build discovery questions for the RevOps lead at Acme Health. The goal is to confirm scope and success metrics. Use the fact sheet already in chat.

Example normalized input (for reference — you never type this directly):

{
  "account": { "name": "Acme Health" },
  "objective": "Prepare the next discovery call",
  "notes": {
    "productArea": "Onboarding automation",
    "targetPersona": "RevOps lead",
    "callGoal": "Confirm scope and success metrics"
  },
  "artifactRefs": [],
  "destinations": {},
  "providerMode": "local-only"
}

Provider behavior

• Firecrawl — optional. The skill usually runs from prior artifacts and local notes and will only reach for Firecrawl when a missing claim blocks the plan.
• Without FIRECRAWL_API_KEY — the plan stays local-only. Unsupported claims are labelled as assumptions or unknown.
• External writeback — this skill does not write externally. The plan is returned in chat. If you want it in a doc, run it through a writeback- capable skill (for example, drop the plan into a Google Doc manually or let account-intel-brief bundle it with a fuller brief).

Related reference

• Grounding Rules — why unresolved items become explicit validation prompts.
• Discovery Context Ingester — the recommended upstream skill.