dossier-generator¶

Turn a built system plus a client/deal context into three linked artifacts: a dual-format dossier (human executive summary + agent-facing implementation spec), a customer-acquisition research package, and a talk-through deck. Use when packaging an engineering build into a sellable, consumable artifact, or whenever the goal is "I built something, get a deal or a case study out of it." This is the anti-circling machine: it converts a build into shareable, decision-ready, agent-executable output.

Security: CLEAN

Install¶

brunnr install dossier-generator

Security Scan¶

File Info¶

Skill Prompt¶

Dossier Generator ("build to deal")¶

What it produces¶

1. The dossier (Markdown). The canonical source of truth AND the agent-consumable spec. Two halves that snap together on an I/O contract:
2. Part A, human executive summary (skim + decide): intent, ROI-first, estimated cost, opportunity, principal sources, assumptions, confidence boundaries, and a fillable Decisions Block.
3. Part B, agent implementation spec (execute): operational instructions, structured ICP and deal flow, a comparable-client research sub-pipeline, account research, offer sketch, codebase architecture, deliverables.
4. The Part B run output (Markdown). What you get when an agent executes Part B against the filled decisions: the ICP filters, a real researched comparable-client table, account briefs, the entry offer sheet, a lead-funnel sketch, a sanitized architecture one-pager, and next-actions. This is the send-to-partner artifact.
5. The deck (HTML artifact). The human-facing presentation generated from the dossier: Part 0 the decision, Part 1 the pitch, Part 2 the architecture. Built to be talked through (screen-record / Loom), grounded in the real codebase for Part 2.

Keep all three. The Markdown is what an agent runs and the source everything else is generated from; the deck is what a human's eyes consume. They are not substitutes.

Inputs¶

• An executive interview about the offering and the deal (below).
• One or more codebases to extract the architecture from (real, so Part 2 is true, not invented).

The flow¶

Step 1 — Executive interview¶

Prompt the user for these. If a field is unknown, mark it and continue; do not invent. - The capability. What does the system actually do, in one paragraph? - The client / source. Who is it built for? (You will codename them; get a neutral codename.) - The ROI, mandatory. What cost or inefficiency does this remove? Frame as "we sell the removal of X," never as selling the technology. Labor hours, escalation, error/liability tail, audit cost, budget efficiency, sales-team efficiency. This drives Part A's top section. - The first vertical. Which market segment do we point at first? - Deal flow and timelines. The stages from cold to closed, and rough durations. - Entry motion. Which rung do we lead with (paid discovery vs free qualifier), and what is the realistic first "yes"? - Target accounts. Named, or delegate sourcing to the research sub-pipeline. - Confidence boundaries. What is proven (grounded in code that runs) vs reasoned vs open research question? - Open questions to close before committing. - The codebase(s) to point Part 2 at.

Step 2 — Fill the dossier¶

Populate dossier-template.md from the interview. Part A is ROI-first and honest about confidence. Part B is executable and unambiguous. Codename the client throughout, scrub any fingerprints (real stack, niche platforms, corpus, naming) while keeping the architecture structurally executable, and generalize it (an AWS-native or cloud-neutral analog, in the greenfield language of choice).

Step 3 — Run Part B¶

Execute Part B against the filled Decisions Block. Prefer a background agent with web access for the comparable-client research, so the prospect list is real and cited, not guessed. Output the Part B run file.

Step 4 — Emit the deck¶

Generate the Part 0/1/2 deck per deck-spec.md, using the artifact-design skill. Part 0 and Part 1 come from Part A; Part 2 comes from the real codebase. Deploy as an Artifact (default-private).

Step 5 — Return¶

Hand back the three artifacts and a one-line Loom teach-through note. Point out what needs the user's decision or a human adversarial review.

Rules the skill enforces¶

• Confidentiality. Codename the client; scrub identifying detail; keep structural executability. Never output the real client name even if it surfaces during research.
• ROI-first. The business sections MUST carry a cost-removed / efficiency argument. Price against value removed, not features or tokens.
• Confidence boundaries. Flag strong (code-grounded) vs weak (open research) explicitly. This is the part a sharp partner respects most; do not skip it.
• The I/O contract. Part A's Decisions Block is Part B's input. If a decision field is empty, Part B halts on that branch and flags it rather than guessing.
• Grounded architecture. Part 2 and the architecture sections are grounded in the actual codebase, not fabricated. Real algorithms, generalized for confidentiality.
• Prose. Plain, concrete prose. No em dashes, no three-item rhythmic lists, no puffery, no AI-vocabulary filler (crucial, showcase, pivotal, landscape, testament). Say what the thing is and what it costs.

Files¶

• dossier-template.md — the parameterized dual-format template to fill.
• deck-spec.md — the Part 0/1/2 deck outline and build approach.

README¶

You built the thing. It works. It has been sitting in a repo for three weeks because packaging it feels like a different job.

What this does¶

The gap between "I built something" and "someone paid me for it" is usually packaging, and packaging is where builds go to die. You circle. You half-write a deck. You never send it.

dossier-generator closes that gap. You answer an interview about the offering, you point it at the codebase, and it emits the artifacts you actually need to put in front of a buyer.

What you get¶

Three linked artifacts, all generated from one source.

Keep all three. The Markdown is what an agent runs and what everything else is generated from. The deck is what a human's eyes consume. One does not replace the other.

The I/O contract¶

Part A ends in a Decisions Block: the calls only a human can make. Part B takes that block as its input.

If a decision field is empty, Part B halts on that branch and flags it. It will not guess its way through your pricing.

That contract is the whole reason the two halves can live in one file.

ROI first¶

The business sections carry a cost-removed argument or they do not ship. You are selling the removal of a cost, so name the cost: labor hours, escalation volume, error and liability tail, audit burden.

Price against the value removed. Not against features, and not against tokens.

Confidence boundaries¶

Every claim gets marked as one of three things:

• Proven. Grounded in code that runs.
• Reasoned. A defensible inference you have not tested.
• Open. A research question you have not answered.

This is the section a sharp partner respects most, and it is the one people skip. Do not skip it.

Confidentiality¶

The client gets a codename. Identifying detail gets scrubbed: the real stack, the niche platforms, the corpus, the naming. The architecture stays structurally executable so the work is still real, and it gets generalized into a cloud-neutral analog.

The real client name never appears in the output, even if it surfaces during research.

Install¶

Claude Code¶

### If you haven't added the brunnr marketplace yet
/plugin marketplace add Peleke/brunnr

### Install
/plugin install dossier-generator@brunnr-skills

CLI¶

### Install brunnr
uv tool install brunnr    # or: pipx install brunnr

### Install the skill
brunnr install dossier-generator

Usage¶

/dossier-generator

It runs an executive interview first. Expect to answer:

• The capability. What does the system do, in one paragraph?
• The client. Who was it built for, and what codename do we give them?
• The ROI. What cost does this remove? (Required. Everything else hangs off it.)
• The first vertical. Which segment do we point at first?
• Deal flow. The stages from cold to closed, and rough durations.
• Entry motion. Paid discovery or free qualifier, and what the realistic first yes looks like.
• Confidence boundaries. What is proven, what is reasoned, what is open.
• The codebase. So Part 2 describes a real architecture.

Unknown fields get marked and skipped. Nothing gets invented.

The flow¶

1. Interview. The questions above.
2. Fill the dossier. Part A is ROI-first and honest about confidence. Part B is executable and unambiguous.
3. Run Part B. Best with a background agent that has web access, so the comparable-client list is researched and cited.
4. Emit the deck. Part 0 and Part 1 from Part A, Part 2 from the real codebase.
5. Return. Three artifacts, plus a note on what still needs your decision.

Rules this skill enforces¶

1. Codename the client. Always. Scrub the fingerprints, keep the structure executable.
2. ROI or it does not ship. Name the cost being removed.
3. Mark confidence. Proven, reasoned, or open. Never blur them.
4. Honor the contract. Empty decision field means halt and flag, not guess.
5. Ground the architecture. Part 2 comes from code that exists. Generalized for confidentiality, never fabricated.
6. Plain prose. No puffery, no filler, no inflated verbs.

Files¶

• dossier-template.md: the parameterized dual-format template the skill fills.
• deck-spec.md: the Part 0/1/2 deck outline and build approach.

The pairing¶

The dossier is the human half plus the spec. If you want a clean, self-contained folder an agent can run without any of the sales framing, agent-pack builds exactly that.

Further reading¶

• brunnr: the skills marketplace