burgess 0.1.0

package/skills/derive-positioning/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: derive-positioning
+description: Derive market positioning from Burgess's themes using April Dunford's five components in order (competitive alternatives → unique attributes → value → best-fit customers → market category), logging every judgment call as a proposed decision record. Use this skill whenever the user asks about positioning, differentiation, ICPs, target customers, market category, "who is this for", "why us vs competitors", or a beachhead/niche strategy — standalone or as the step after derive-themes. Positioning is a decision; this skill drafts and argues, humans decide.
+---
+
+# Derive Positioning
+
+Positioning is a set of interdependent choices, so derive the five components **in this order** — each answer constrains the next. Never start from a fill-in-the-blanks positioning statement: the template assumes each blank has one obvious answer, when most products could be positioned several ways. The template is an optional summary written last (Dunford's central correction — see `references/frameworks.md`). What v2.1 learned the hard way and this skill enforces: every judgment call becomes a **proposed decision record** with rejected alternatives, because the rejections are what make the choice reviewable.
+
+## Inputs
+
+Read `projections/themes.md` (the alternatives map and DIFFERENTIATOR/TABLE-STAKES classifications are load-bearing) and any existing decision records in `decisions/`. Run `python scripts/check_stale.py` first — if themes are stale or missing, say so; proceed only with the user's eyes open (recorded in `open_questions`). **Standalone without themes:** gather the minimum interactively — what customers use instead, what the product does that alternatives can't, who has bought/loved it — record via `intake-interview`'s steps, then derive a minimal alternatives map inline and flag that a full `derive-themes` run should follow.
+
+## Procedure — five components, in order
+
+1. **Competitive alternatives.** From the themes map: what would best-fit customers actually do without this product? Include status quo and "do nothing". Rank by real-world frequency — `winloss` evidence rules; without it, mark the ranking `[I]` and put it in `open_questions`.
+2. **Unique attributes.** Only DIFFERENTIATOR strength themes qualify — table stakes never, however impressive. Per attribute: which alternatives lack it and why, `[E:]` citations. An attribute resting solely on `secondhand` evidence cannot appear here.
+3. **Value.** Translate each attribute: attribute → so what → customer outcome. State value as evidence-backed benefit, grouped into 2–4 value themes. Where the outcome claim rests on inference rather than customer evidence, tag `[I]` — messaging downstream must know which benefits are validated.
+4. **Best-fit customers (ICPs).** Who cares *most* — not everyone who could use it, but where the value is urgent. Per ICP: JTBD, pains, buying triggers, and observable characteristics that make a great-fit prospect recognizable in the wild. Every ICP traces to at least one problem theme.
+5. **Market category.** The frame of reference that makes the value obvious. Consider: head-on (existing category), subsegment/niche (usually the right answer), new category (rare, expensive to educate — strong justification required). **This choice is a proposed decision record** (`decisions/dec-NNN.md`, `decided_by: null`): chosen frame, `rejected` frames with reasons, rationale, evidence inputs. The artifact cites it `[D: dec-NNN]`. If a decision record already covers this question — decided or proposed — cite it instead of proposing a duplicate; propose a new record only to argue for *changing* it (naming the record it would supersede), and never silently contradict a decided one. This is what makes regeneration deterministic: same evidence + same decisions → same conclusions.
+
+Optional, when relevant:
+
+6. **Why now.** Trends that make this timely — only ones connecting to evidenced capabilities; never trend-chasing.
+7. **Beachhead.** Early-stage products: a beachhead niche plus bowling-pin expansion path. Always a proposed decision record — it's a GTM bet, not an analysis output.
+8. **Positioning statements.** Moore-style, one per ICP, written last as a summary of decisions already made. Optional.
+
+## Output
+
+Write the proposed decision records to `decisions/` first — they must exist before the artifact cites them. Then write `projections/positioning.md`: frontmatter per schema (`artifact: positioning`, `depends_on: [themes, decisions]`, `proposed_decisions` listing the new dec-ids), sections in component order, then the optional sections (why now, beachhead, positioning statements — derived last, placed here), closing with **Differentiation Pillars** (table: pillar, strength theme, alternative's gap, proof `[E:]`) as the physical last section.
+
+Then: `python scripts/check_stale.py --record positioning`; commit decisions first (`decision: propose dec-NNN`), then the projection (`regen: positioning`); run `red-team` against it — every regeneration gets the adversarial pass. Expect the checker to warn about undecided decisions cited by the draft — that's by design (blocks approval, not drafting), not something to "fix".
+
+## Guardrails
+
+- **Positioning describes the market today.** Claim only current, evidenced capability. Future capability belongs in vision; check consistency with `projections/vision.md` if it exists, but never import its promises.
+- **Pre-launch rule** (mandatory when nothing is shipped): "current" means shipped and demonstrated. Committed spec scope may ground positioning but must be phrased prospectively (never "we've demonstrated"), labeled as committed scope, and "may this ship before launch evidence exists?" becomes a proposed decision record. State the pre-launch basis prominently in the artifact preamble.
+- No "best", "leading", "only" without evidence. No differentiation pillar without a DIFFERENTIATOR theme behind it.
+- Secondhand evidence never solely supports a differentiator or headline claim.
+- Every uncited factual sentence is a defect the red team will flag — cite `[E:]`, `[D:]`, `[I]`, or `[A]` as you write, not as a cleanup pass.
+
+## Checkpoint
+
+Present the five components as **decisions with alternatives** ("we could also frame this as X — here's why Y wins"), the proposed decision records, and the open questions. The market-category choice deserves real debate before anything is built on it. In a waived run: record, don't hold — but the consolidated sign-off list at run end must name the category and beachhead decisions explicitly.

package/skills/derive-themes/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: derive-themes
+description: Cluster Burgess's evidence base into strategic themes — problem themes named by customer problem, strength themes tested as DIFFERENTIATOR vs TABLE STAKES against a competitive-alternatives map, and risk themes. Use this skill when the user wants themes, differentiators, a competitive landscape, "what really matters" distilled from their evidence, "what are our strengths", or "how do we compare to alternatives" — and as the analysis step between evidence ingestion and positioning. Requires an evidence base; if none exists, route to ingest-evidence or intake-interview first.
+---
+
+# Derive Themes
+
+Convert many evidence items into few evidence-backed clusters. This is affinity mapping: the clusters, not the raw items, are what positioning and vision build on. The load-bearing discipline here is the **order**: build the competitive-alternatives map *before* classifying strengths, because a strength is only a differentiator relative to what customers would actually do instead — and without the map first, everything flatters its way into being a differentiator. Formats in the burgess skill's `references/schemas.md`; grounding in `references/frameworks.md`.
+
+## Inputs
+
+Read the evidence base: every `active` and `disputed` item in `evidence/items/` (group by `type` and `tags`), plus `gap-report.md` for what you're working without. **Standalone with a thin evidence base:** gather the minimum interactively — top pains, main capabilities and limitations, what customers use instead — but record the answers through `intake-interview`'s recording steps (transcript + items) first, then derive from the items. There is no off-the-books context.
+
+## Procedure
+
+1. **Problem themes (3–7).** Cluster `user_pain`, `jtbd`, and `market` items. Name each theme by the **customer's problem**, not the product's feature ("teams can't trust hand-offs", not "workflow automation"). Per theme: description in neutral language, affected segments, evidence citations `[E: ev-NNNN, ...]`.
+
+2. **Competitive-alternatives map — before strengths.** From `competitive`, `winloss`, and `market` items: what would customers actually do if this product didn't exist? Include named competitors AND the status quo, spreadsheets/manual process, building in-house, hiring someone, and **doing nothing** — the status quo is usually the biggest competitor. Per alternative: type, what it's genuinely good at and bad at *from the customer's view*, evidence. Rank by how often customers actually choose them — `winloss` items are the ground truth for ranking; without them the ranking is `[I]` and says so. If no competitive evidence exists, build the map from tagged inference and put it prominently in `open_questions` — it is load-bearing for positioning.
+
+3. **Strength themes (3–7), tested against the map.** Cluster `capability` items and architecture properties. Classify each theme, mechanically:
+   - **DIFFERENTIATOR** — the alternatives genuinely lack it; name which alternatives and why, with evidence.
+   - **TABLE STAKES** — customers expect it; main alternatives have it too. Table stakes stay in the artifact (they answer objections later) but never drive positioning.
+   - A strength shared by the main alternatives **cannot** be a differentiator, however central it is to the product. When your classification diverges from how the source documents frame a capability, say so and flag it for human adjudication — that divergence is a feature, not an error.
+   - A DIFFERENTIATOR resting solely on `secondhand` items is not allowed — downgrade or flag it.
+
+4. **Risk themes.** Cluster `limitation` items, constraints, and incident patterns. These feed vision guardrails and the prohibited-claims list; extracting them honestly now is what keeps marketing honest later.
+
+## Output
+
+Write `projections/themes.md`: frontmatter per schema (`artifact: themes`, `status: draft`, `depends_on: [evidence]`), then **Problem Themes**, **Competitive Alternatives** (table: alternative, type, good at, bad at, evidence; plus a short narrative naming the biggest real competitor), **Strength Themes** (each marked DIFFERENTIATOR or TABLE STAKES with rationale), **Risk Themes**. Stable IDs throughout — PT1… for problem themes, ST1… for strengths, RT1… for risks, and A1… for alternatives in the map — so downstream artifacts and decisions can reference them.
+
+Then: `python scripts/check_stale.py --record themes`, commit `regen: themes from <N> evidence items`, and offer a `red-team` pass if positioning already exists (it just went stale).
+
+## Guardrails
+
+- Every theme cites ≥2 evidence items, or 1 plus an explicit `[A]` recorded in `open_questions` for confirmation.
+- Neutral, factual language — themes are analysis, not copy.
+- `disputed` items may be cited but the dispute must be visible where cited; a theme resting on a disputed item inherits an open question.
+- Themes never cite sources directly — projections cite items; items cite sources.
+
+## Checkpoint
+
+Ask: do these themes ring true, and does the alternatives map match what they hear from real customers and lost deals? Their corrections are better evidence than any document — capture them via `intake-interview` recording (items!), then regenerate. In a waived run, the questions land in `open_questions` and the run continues.

package/skills/generate-assets/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: generate-assets
+description: Apply Burgess's brand platform and message house to produce draft assets — homepage/web copy, a vision & positioning deck outline, and an internal "how to talk about us" explainer. Use this skill whenever the user asks for website copy, hero copy, landing page text, a positioning deck, launch copy, or internal enablement docs about how to describe the product — after messaging and brand-platform exist, or standalone with the output labeled "unvalidated draft" prominently.
+---
+
+# Generate Assets
+
+Apply the platform; invent nothing. Every asset is a *draft application* of decisions already made — the message house supplies the claims, the brand platform supplies the voice, the prohibited-claims list supplies the boundaries. If writing an asset requires a claim that isn't in the message house, that's a gap to flag upstream, not a license to improvise. Formats in the burgess skill's `references/schemas.md`.
+
+## Inputs
+
+Read `projections/brand-platform.md`, `projections/messaging.md`, and `projections/positioning.md` (for ICP context); run `python scripts/check_stale.py` first — assets built on stale messaging are pre-broken. **Standalone without upstream:** gather the minimum interactively (value prop, top three messages with proof, voice adjectives), record via `intake-interview`'s steps, and label every output "unvalidated draft — no underlying message house" at the top.
+
+## Procedure
+
+Produce each asset in the brand voice. Open each file with a header noting which message-house elements and voice traits it uses — that's what makes drift detectable in the red-team pass:
+
+1. **`web-copy.md`** — Homepage hero (headline ≈ master value prop in ≤10 words; subhead; primary CTA), then one section per key message with its proof points, a "who it's for" section speaking to each ICP in its own terms, and an honest FAQ drawn from the objections & responses (including the honest caveats — an FAQ that dodges is worse than none).
+2. **`deck-outline.md`** — Vision & positioning deck, slide by slide, one point per slide: problem (problem themes) → why now → vision → what we do (category + value) → why us (differentiation pillars + proof) → who it's for (ICPs) → roadmap/milestones → ask. Presenter notes carry the `[E:]`/`[D:]` citations so a presenter can answer "says who?" live.
+3. **`internal-explainer.md`** — "How to talk about our product": the one-liner, the 30-second version, the 2-minute version; per-audience guidance (customer, investor, candidate, press); the voice do/don't examples; and the **prohibited-claims list reproduced in full** — this document is how the guardrails reach every future employee and tool.
+
+## Output
+
+Write the three files into `projections/assets/`, each with frontmatter per schema (`artifact: assets`, `depends_on: [messaging, brand-platform]`) and a "draft — requires human (and where flagged, legal) review" line in the header.
+
+Then: `python scripts/check_stale.py --record assets`, commit `regen: assets`, and run `red-team` — the prohibited-claims scan and tense scan run against every asset, zero tolerance.
+
+## Guardrails
+
+- Only message-house claims and their proof points; no new claims, no superlatives absent from messaging.
+- Check every asset against the prohibited-claims list **before finishing**, not after the red team catches it — the red team is the net, not the process.
+- Pre-launch rule end-to-end: assets are where past-tense drift historically lands ("we've demonstrated the swap" shipped in live testing as exactly this defect). Prospective phrasing, committed-scope labeling, every time.
+- Engineered benefit bullets keep their flags when they appear in assets — web copy may polish the phrasing, never launder the flag away.
+
+## Checkpoint
+
+Deliver the assets with a short note on gaps found while writing (claims the message house lacked, voice traits that fought each other) — these route back to messaging/brand, and finding them is part of this skill's job, not a failure. Recommend the full-chain red-team review now that the complete artifact set exists.

package/skills/generate-vision/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: generate-vision
+description: Articulate core ideology (purpose + values discovered from behavioral evidence) and an envisioned future (vision statement, destination, strategic pillars, milestones) from Burgess's evidence base. Use this skill whenever the user asks for a product or company vision, mission, purpose, values, "north star", strategic pillars, a BHAG, or a future press release. Purpose and values are discovered, not invented — this skill needs culture evidence; if none exists it routes through intake-interview first.
+---
+
+# Generate Vision
+
+Follow the Collins & Porras structure: **core ideology** (purpose and values — stable, discovered from how the organization already behaves) plus an **envisioned future** (ambitious, time-bound, vivid). Keeping the halves distinct is the whole trick: purpose never changes; the envisioned future is a bet with a date on it. Grounding in the burgess skill's `references/frameworks.md`; formats in `references/schemas.md`.
+
+## Inputs
+
+Read `projections/themes.md`, all `culture` evidence items, and existing decision records; run `python scripts/check_stale.py` first. **If `culture` evidence is thin or absent** — the common case for document-only corpora — run the vision-targeted `intake-interview` questions first (purpose, values-in-conduct: "tell me about a time you turned down revenue on principle"). Ask the user for a horizon; if nobody can answer (waived run), use 5 years and propose it as a decision record. Purpose has no horizon.
+
+## Procedure
+
+1. **Core purpose.** One sentence: why the organization exists beyond making money. Not a product description ("we make deployment tools") but the human outcome behind it ("software teams ship without fear"). Discover it from the evidence — what problems the team keeps choosing to solve — and cite the items that reveal it.
+2. **Core values (3–5).** Each value needs behavioral evidence: a postmortem culture visible in incident docs, privacy stances baked into architecture, quality bars enforced at cost `[E:]`. A value with no behavioral trace may be included but must be marked **ASPIRATIONAL** — the team is claiming it, not living it yet, and the human must confirm they mean to claim it.
+3. **Vision statement.** One sentence describing the destination. Quality tests: concrete enough to help say *no* to things; free of superlatives and buzzwords; clearly about the future (distinct from purpose); a stranger could tell whether it came true.
+4. **Destination.** A vivid half-page: the world in N years if this succeeds — customers, ecosystem, what became normal that isn't today. Vividness is functional: people can't align on an abstraction.
+5. **Strategic pillars (3–5).** Big bets connecting strength themes to problem themes while addressing risk themes. Per pillar: description, linked themes, supporting capabilities `[E:]`, constraints considered. A pillar built only on TABLE-STAKES strengths is a weak bet — flag it. A pillar resting on a bet about third-party behavior (regulators, platform vendors) must say so — the board persona will find it anyway.
+6. **Milestones.** Per horizon, outcomes aligned to `metric` evidence items and roadmap so the vision connects to what the org already measures.
+7. **Optional stress test.** A one-page future press release (Amazon PR/FAQ style) dated at the horizon. If it's boring, the vision is too — revise before presenting.
+
+**Decisions:** the horizon, any ASPIRATIONAL value the user chooses to claim, and the vision statement itself are human decisions — propose decision records (`decided_by: null`) and cite them `[D:]`.
+
+## Output
+
+Write `projections/vision.md`: frontmatter per schema (`artifact: vision`, `depends_on: [themes, decisions]`), sections: **Core Ideology** (Core Purpose; Core Values with evidence or ASPIRATIONAL flags), **Envisioned Future** (Vision Statement; Destination; Strategic Pillars; Milestones), optional **Future Press Release**.
+
+Then: `python scripts/check_stale.py --record vision`, commit `regen: vision`, run `red-team` (the skeptical-board-member persona earns its keep here).
+
+## Guardrails
+
+- Purpose (why we exist now) and vision (where we're going) must not blur — the red team checks this pair explicitly.
+- No pillar may claim capabilities absent from the evidence or contradicted by `limitation` items — ambition lives in the destination, honesty in the pillars.
+- Positioning is consistency-checked against vision, never derived from it; don't let vision language leak into "today" claims anywhere.
+- Values are inherited verbatim by the brand platform later — write them as if they'll be carved over a door, because they will be.
+
+## Checkpoint
+
+This artifact needs leadership-level review, not a skim: purpose and values only work if the humans own them. Present the vision statement, purpose, and values first; the narrative second. List every ASPIRATIONAL value and proposed decision explicitly. Vision is a decision — the draft is an input to it, not a substitute for it.

package/skills/ingest-evidence/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: ingest-evidence
+description: Atomize source documents (PRDs, architecture docs, decks, transcripts, win/loss notes, support threads, reviews) into Burgess's evidence base — one provenance-linked, confidence-tagged claim per file — plus the source registry and the gap report. Use this skill whenever the user provides documents to ingest into strategy work, says "read these docs", "add this to the evidence base", drops in new material (a win/loss report, call transcripts, an exit interview), or starts any docs-to-strategy task. Also use it to re-ingest an updated version of a previously ingested document.
+---
+
+# Ingest Evidence
+
+Turn documents into **atomized evidence items**: one claim per file, typed, provenance-linked, confidence-tagged, dated. Atomization is what makes everything downstream tractable — a new document changes *specific items*, not "the context", so staleness propagates mechanically and diffs stay readable. Formats live in the burgess skill's `references/schemas.md`; working rules in `references/conventions.md`. If no strategy repo exists yet, run the `burgess` orchestrator's scaffold first.
+
+## Procedure
+
+1. **Register sources.** Add every document to `evidence/sources.yaml`: key, title, kind, date, sha256 if the file is on disk, `availability: available`. When a source cites companion documents you don't have (a spec, a brief, research), register them too with `availability: referenced_unavailable` — secondhand citations must resolve to a registry entry. Re-ingesting a newer version of a registered source: add it as a new entry (or update date/sha256), then handle supersession in step 5.
+
+2. **Skim everything before extracting anything.** Conflicts between documents only surface if you've seen all of them.
+
+3. **Atomize.** Extract claims into `evidence/items/ev-NNNN.md` (monotonic numbering — check the highest existing ID first). Per item: `type`, one-sentence `claim`, `source` key, `location` (structured identifiers cite directly: `FR-18`, `SM-5`, `§3.1`), `confidence`, `date_observed` (when the source asserted it, not today), `tags`, `status: active`.
+   - **Granularity:** prefer more, smaller items; when in doubt, split. A sentence bundling a pain and a capability is two items.
+   - **Confidence:** `stated` only for what the doc explicitly says. Reasonable deductions are `inferred` — say from what in the prose. Things needing human confirmation are `assumption`. Claims a doc carries on behalf of an unavailable companion are `secondhand` — these never solely support a differentiator or headline claim downstream.
+   - **Verbatim language:** for `customer_language` items, preserve the exact quote in the prose body — it is the raw material for messaging. Never paraphrase a customer.
+   - **Limitations matter as much as capabilities.** Extract them deliberately — they feed risk themes and the prohibited-claims list. Documents advertise strengths; you dig for limits.
+   - **Tags:** short, reusable, lowercase (`icp-failed-pilot`, `governance`). Tags are how themes find their clusters.
+
+4. **Detect conflicts.** Two items asserting incompatible claims (different target users, different numbers): mark **both** `status: disputed`, cross-reference in prose, and surface the pair for human resolution. Never silently pick a winner — silent conflict resolution is a named failure mode.
+
+5. **Detect supersession.** Newer version of the same source: mark items the new version replaces as `status: superseded` with `superseded_by: <new-ev-id>`. Superseded items stay on disk (provenance) but leave the evidence hash, so downstream staleness triggers correctly.
+
+6. **Regenerate `gap-report.md`** (in place — git history is its archive). For each missing outside-in evidence type — customer language, competitive alternatives, win/loss, market data, usage/commercial ground truth, culture/values evidence — write: why it matters downstream, a concrete question the team can answer, and a value-per-effort tier. Say explicitly that win/loss notes and ~5 sales-call transcripts buy more positioning truth than almost anything else. Give each gap a stable anchor (`q1`, `q2`, …) so decisions can cite `gap-report#q3`.
+
+7. **Report and route.** Run `python scripts/check_stale.py` — new evidence marks downstream projections stale; tell the user which. Commit as `evidence: ingest <sources> (+N items)`.
+
+## The gap report is the wedge
+
+The first thing Burgess produces is not strategy — it is an honest account of what the available evidence *cannot* support. A documents-only corpus (the common case: PRDs + architecture docs) describes the product from the inside; positioning needs outside-in evidence. When the corpus is documents-only, **recommend running `intake-interview` before deriving anything** — the interview is the front door for filling gaps, not a fallback. Deliver the gap report as standalone value even if the user never generates a single projection.
+
+## Guardrails
+
+- Neutral, factual language in every item — marketing spin in an evidence item launders opinion into the layer everything else trusts.
+- Every item carries source + location + confidence + date. An item that can't be traced is a defect, not a style issue.
+- Don't inflate confidence: PRD authors write for engineers, so user pains are often implied — extract them as `inferred`, not `stated`.
+- Never delete items — supersede or dispute them. The evidence base is append-mostly; its history is the audit trail.
+
+## Checkpoint
+
+Present: item count by type, conflicts found, referenced-unavailable sources, and the gap report. Invite the user to answer gap questions now (route to `intake-interview`) or accept the gaps explicitly. In a waived run, record acceptance as an open question and continue.

package/skills/intake-interview/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: intake-interview
+description: Run a structured founder/leadership interview that fills the gaps in Burgess's evidence base — driven by the current gap report, transcribed, and atomized into evidence items. Use this skill whenever the user wants to answer gap-report questions, says "interview me", "let's fill the gaps", "I don't have docs, let's just talk", corrects a theme or artifact in conversation (capture it!), or is early-stage with nothing written down. This is the FRONT DOOR of Burgess, not a fallback — for early-stage companies the founder interview is the highest-density corpus and the documents are merely supporting evidence.
+---
+
+# Intake Interview
+
+A conversation that becomes evidence. The interview exists because the highest-value strategic evidence — what customers actually said, why deals were lost, what the founder refuses to build — usually isn't written down anywhere. Your job: ask the right questions, get *specifics*, transcribe faithfully, and atomize the answers into evidence items so everything downstream can cite them. Formats in the burgess skill's `references/schemas.md`.
+
+## Prepare
+
+1. Read `gap-report.md` if it exists — its questions are your agenda, highest value-per-effort first.
+2. Ask what the user wants to derive next, and weight questions accordingly:
+   - **Positioning next** → competitive alternatives ("what would customers do without you?"), ICP instincts ("who loves this most, and what do they have in common?"), lost-deal stories, customer language.
+   - **Vision next** → purpose ("why does this company exist beyond money?"), values-in-conduct ("tell me about a time you turned down revenue / shipped late on principle"), horizon.
+3. **Zero-document mode:** no corpus, no gap report? Run the interview as ingestion. Cover, in order: who the customer is and their pain (in their words), what customers do instead today, what's genuinely different, wins/losses so far, what's shipped vs. planned, why this company exists. Then generate the first gap report from what's still missing.
+
+## Interview style
+
+- **A few questions at a time** — two or three, never a form. Follow the user's energy; a good tangent about a lost deal outranks the next scripted question.
+- **Chase specifics.** "Tell me about the last deal you lost — what did they do instead?" beats "who are your competitors?". Ask for the last time, the actual words, the specific customer. Generalities produce `inferred`; stories produce `stated`.
+- **Capture verbatim customer language.** When the user quotes a customer, get the exact words and who said them — that's a `customer_language` item, the scarcest resource in most corpora.
+- **Distinguish knowledge from hope.** "We think enterprises will want this" is an `assumption`; "Acme's CISO told us X" is `stated`. Reflect the tag back when it matters: "I'm recording that as an assumption to validate — fair?"
+- **Shipped vs. committed.** For anything capability-like, ask whether it's shipped and demonstrated or committed scope — the pre-launch rule downstream depends on this distinction being captured now.
+
+## Record
+
+1. **Transcript** → `evidence/intake/intake-<date>.md`: frontmatter (`date`, `participants`, `driven_by: gap-report` or `standalone`), then Q/A pairs, answers verbatim or near-verbatim. Append-only.
+2. **Register** the transcript in `sources.yaml`: key `intake-<date>`, `kind: interview`, `availability: available`.
+3. **Atomize** answers into evidence items exactly as `ingest-evidence` would: `source: intake-<date>`, `location` = question anchor, `confidence: stated` (or `assumption` where the user was speculating — be honest about which), one claim per item, verbatim quotes preserved for `customer_language`. Interview answers that contradict existing items: mark both `disputed` and tell the user — their memory and their PRD disagreeing is a finding, not an embarrassment.
+4. **Regenerate `gap-report.md`** showing what the interview closed and what remains — the user should *see* the gaps shrink; that visible progress is what converts them into an evidence contributor.
+5. Run `python scripts/check_stale.py`; report the staleness cascade. Commit as `evidence: intake <date> (+N items, closed q2, q5)`.
+
+## Guardrails
+
+- Never lead the witness: ask "what did they do instead?", not "so they probably stuck with spreadsheets?". Leading questions manufacture evidence.
+- The transcript records what was said, not what you wish was said — cleaning up grammar is fine; sharpening claims is not.
+- Don't interrogate past usefulness: when the gaps that matter for the next step are closed, offer to stop. A 20-minute interview the founder finishes beats a 90-minute one they abandon.
+- Corrections made during any checkpoint (themes review, positioning review) are intake evidence — capture them through this skill's recording steps even outside a formal interview.
+
+## Checkpoint
+
+Summarize: items created (by type and confidence), gaps closed, gaps remaining, contradictions surfaced. Recommend the natural next step (usually `derive-themes` once alternatives + pains have evidence, or more documents if the interview revealed some exist).

package/skills/red-team/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: red-team
+description: Adversarially attack Burgess projections — trace citation chains, scan for consistency defects and past-tense drift, and argue against the strategy as a skeptical customer, the strongest competitor, and a skeptical board member. Use this skill after ANY projection regenerates (the orchestrator triggers it automatically), on demand when the user asks for a review, critique, red team, "poke holes in this", or a coherence check of strategy artifacts, and before any artifact is approved for external use. Runs against whatever projections exist — a lone themes.md or the full chain.
+---
+
+# Red Team
+
+Drift compounds silently in long generation chains — that's why this pass runs on every regeneration, not as a finale. Three parts, in order: mechanical checks first (cheap, deterministic), then coherence tracing, then adversarial personas. The value of the persona pass is proportional to how hard it argues; a polite red team is a rubber stamp with extra steps. Formats in the burgess skill's `references/schemas.md`.
+
+## Scope
+
+Run against whatever exists in `projections/` — the whole set after a full run, or just the artifacts that changed after a regeneration (say which in the review frontmatter). Read the evidence items and decisions the artifacts cite; you cannot judge a chain you haven't walked.
+
+## Part 0 — Mechanical checks
+
+Run `python scripts/check_stale.py` first. It catches broken/malformed citations, superseded items still cited, undecided decisions under approved artifacts, staleness, and hand-edits. Report its findings; don't re-derive them by hand.
+
+## Part 1 — Vertical coherence
+
+Sample claims from each artifact under review — every headline claim, plus a spread of body claims. For each, trace the full chain: claim → theme → evidence item(s) → source. A chain is broken when:
+- the citation doesn't support the claim as written (the item says less, or something else — the most common break),
+- the claim outruns the item's confidence (`inferred`/`assumption` evidence carrying a flat assertion),
+- a differentiator or headline claim rests solely on `secondhand` items,
+- a factual sentence carries no tag at all (`[E:]`, `[D:]`, `[I]`, `[A]`) — a defect by definition; HIGH when it sits in differentiator or headline copy, Medium elsewhere,
+- an `[A]` in the body is missing from `open_questions`.
+
+Record each trace in a table: claim, chain, pass/fail with the exact break point. Target: a reviewer should be able to re-walk any chain from your table alone.
+
+## Part 2 — Horizontal consistency
+
+- **Purpose ≠ vision:** the timeless why and the dated destination must not blur (when vision.md exists).
+- **Positioning claims today only:** no future capability imported from vision; committed-scope claims labeled as such.
+- **Tense scan (automatic HIGH):** for pre-launch products, any past-tense results claim for unshipped capability — "we've demonstrated", "proven with customers", "customers achieve" — is an automatic HIGH finding, no judgment call. This exact defect shipped in live testing; the scan is why it won't again.
+- **Prohibited-claims scan** (once `brand-platform.md` exists): every artifact and asset checked against the list, zero tolerance.
+- **Voice consistency** (once assets exist): the brand's do/don't traits actually followed.
+- **Decision consistency:** artifacts contradicting a decided decision record, or silently deviating from one, get flagged — deviation may be right, but it must be argued, not smuggled.
+
+## Part 3 — Adversarial personas
+
+Adopt each fully; argue hard; severity-rate findings (High/Medium/Low); no pass/fail — personas argue, they don't grade:
+
+1. **The skeptical target customer** (make it the specific ICP): hears the pitch, pushes back with their real constraints, names what the messaging conveniently omits, asks the question the sales rep dreads.
+2. **The strongest competitive alternative** (from the alternatives map — often the status quo or a suite vendor): writes an actual counter-pitch, exploiting every weakness in the positioning, including the true things it would say.
+3. **The skeptical board member:** interrogates the vision and market bet — what has to be true, what evidence is missing, where the economics wobble.
+
+## Output
+
+Write `reviews/review-<date>.md` (append-only; `-2` suffix for a second run the same day): frontmatter (`date`, `artifacts_reviewed`, `run_reason` — free text, typically post-regeneration or on-demand; note any abbreviated scope here too), then Parts 0–3, then a **findings table**: finding, severity, owning artifact, and disposition — where a finding reveals a *drafting error*, route it to the owning artifact for regeneration; where it reveals a *missing input*, propose the fix at the right layer: a new evidence item to gather (add to gap report), or a decision record to put in front of a human. Findings about stale non-projection state — an outdated proposed-decision rationale, a gap report that missed a regeneration — route to those files directly; decisions and the gap report are sources, not projections, and may be edited (committed as `decision:` / `evidence:`). Never fix findings by editing projections directly.
+
+Commit as `review: <date> (<N> findings, <M> high)`. Present the findings table with high severities first, and say plainly whether anything blocks approval.
+
+## Guardrails
+
+- Attack the artifacts, not the strawman: quote the actual claim you're attacking.
+- A finding without a location (artifact + claim) is a vibe, not a finding.
+- Include the true-but-uncomfortable competitor arguments — the user is better served hearing them here than in a lost deal.
+- If everything passes, say so briefly and mean it; manufacturing findings to look rigorous is its own form of drift.