burgess 0.1.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/LICENSE ADDED
@@ -0,0 +1,21 @@
1
+ MIT License
2
+
3
+ Copyright (c) 2026 Burgess contributors
4
+
5
+ Permission is hereby granted, free of charge, to any person obtaining a copy
6
+ of this software and associated documentation files (the "Software"), to deal
7
+ in the Software without restriction, including without limitation the rights
8
+ to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9
+ copies of the Software, and to permit persons to whom the Software is
10
+ furnished to do so, subject to the following conditions:
11
+
12
+ The above copyright notice and this permission notice shall be included in all
13
+ copies or substantial portions of the Software.
14
+
15
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18
+ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21
+ SOFTWARE.
package/README.md ADDED
@@ -0,0 +1,108 @@
1
+ # Burgess
2
+
3
+ **An evidence-first strategy engine, delivered as agent skills.**
4
+
5
+ The Cambrian explosion produced a thousand wild body plans — and we only know any of it happened because one evidence bed preserved everything: the **Burgess Shale**. Every claim paleontology makes about that era traces back to specimens in that shale, dated and in place.
6
+
7
+ Your strategy deck is a reconstruction. Burgess is the fossil bed it's reconstructed from.
8
+
9
+ Burgess turns your company's documents and interviews into a living, provenance-linked **evidence base** — and projects vision, positioning, messaging, and brand from it as cheap, regenerable artifacts. When new evidence lands (a win/loss report, five sales-call transcripts, a churned customer's exit interview), staleness propagates mechanically through a dependency graph and the affected artifacts regenerate — with humans approving the decisions, never the mechanics.
10
+
11
+ Strategy documents rot because the evidence behind each claim was never captured — only the conclusions were. Burgess inverts the asset:
12
+
13
+ - **The evidence base is the product.** Every user pain, capability, limitation, customer quote, win/loss reason, and competitive fact — atomized, source-linked, confidence-tagged, dated.
14
+ - **Artifacts are projections.** Positioning, messaging, web copy: regenerable renderings of the evidence through established frameworks (Dunford positioning, Collins & Porras vision, message house).
15
+ - **Everything is plain markdown + YAML in git.** Diffable positioning is the killer feature: *"here is the diff to our differentiation claims since March, and the evidence that changed."*
16
+ - **Humans decide; the system drafts and argues.** Every judgment call becomes a decision record with rejected alternatives; a red team attacks every regeneration.
17
+
18
+ ## Install
19
+
20
+ **Via npm:**
21
+
22
+ ```bash
23
+ npm install -g burgess
24
+ burgess install # -> ~/.claude/skills (Claude Code, all projects)
25
+
26
+ # or without installing anything globally:
27
+ npx burgess install
28
+ ```
29
+
30
+ Options: `--project` (this repo's `.claude/skills/` only), `--codex` (`~/.agents/skills/`), `--dest DIR`, `--force`.
31
+
32
+ **Manually:** copy the folders in `skills/` into `~/.claude/skills/` (Claude Code) or `~/.agents/skills/` (Codex). Both use the same open SKILL.md standard.
33
+
34
+ > Upgrading from the `vision-workflow` bundle or the `groundwork` working-name build? Remove those folders — Burgess supersedes them and competing bundles will answer the same requests.
35
+
36
+ ## Get started
37
+
38
+ Open Claude Code in your product repo (or a fresh repo for strategy) and say:
39
+
40
+ > **"set up burgess"**
41
+
42
+ The orchestrator scaffolds a `strategy/` directory and guides you from there:
43
+
44
+ - **Have documents?** *"Ingest these docs"* — PRDs, architecture docs, decks, transcripts, win/loss notes.
45
+ - **Nothing written down?** *"Interview me"* — for early-stage teams the founder interview **is** ingestion, and it's the highest-density evidence source you have.
46
+ - **Coming back later?** *"Where were we?"* — the orchestrator reads the manifest and tells you what exists, what's stale, and what needs a human decision.
47
+
48
+ The first thing Burgess produces is not strategy — it's the **gap report**: an honest account of what your evidence *cannot* support yet, with the highest-value questions to answer next (win/loss notes and ~5 sales-call transcripts buy more positioning truth than almost anything else).
49
+
50
+ ## The pipeline
51
+
52
+ | Skill | What it does |
53
+ |---|---|
54
+ | `burgess` | Orchestrator: scaffolds the repo, detects state, runs steps in order, enforces checkpoints and staleness |
55
+ | `ingest-evidence` | Atomizes documents into typed, cited evidence items; regenerates the gap report |
56
+ | `intake-interview` | Gap-driven founder/leadership interview; answers become evidence items |
57
+ | `derive-themes` | Problem/strength/risk themes; competitive-alternatives map; differentiator vs table-stakes test |
58
+ | `derive-positioning` | Dunford five-component positioning; category and beachhead as proposed decision records |
59
+ | `derive-messaging` | Message house, per-ICP benefits from real customer language, pitches, objection handling |
60
+ | `generate-vision` | Purpose + values discovered from behavior; envisioned future with pillars and milestones |
61
+ | `build-brand-platform` | Voice with do/don't pairs; value pillars with proof; the prohibited-claims list |
62
+ | `generate-assets` | Web copy, deck outline, internal explainer — message-house claims only |
63
+ | `red-team` | Adversarial pass after every regeneration: citation chains, tense scan, skeptic personas |
64
+
65
+ Start with the wedge (ingest → interview → themes → positioning → red team). Messaging, vision, brand, and assets come when you're ready — positioning churns weekly; brand churns yearly.
66
+
67
+ ## What your strategy repo looks like
68
+
69
+ ```
70
+ strategy/
71
+ ├── evidence/ # THE FOSSIL BED
72
+ │ ├── sources.yaml # registry of every source (incl. referenced-but-unavailable)
73
+ │ ├── items/ # one file per claim: ev-0001.md ... typed, cited, confidence-tagged
74
+ │ └── intake/ # interview transcripts (append-only)
75
+ ├── decisions/ # human judgments with rationale + rejected alternatives (dec-001.md ...)
76
+ ├── projections/ # REGENERABLE — never hand-edited
77
+ ├── reviews/ # red-team output, one per run (append-only)
78
+ ├── scripts/check_stale.py # staleness + citation checker (stdlib Python, CI-ready)
79
+ ├── gap-report.md # always current: what the evidence can't support yet
80
+ └── manifest.yaml # the dependency DAG: hashes, staleness, generation records
81
+ ```
82
+
83
+ ## The git workflow
84
+
85
+ - **Branch per strategy change.** New evidence batch or decision → branch → regenerate affected projections → PR. The PR diff *is* the strategy review.
86
+ - **Never hand-edit projections.** Fix the evidence or the decision, regenerate. `check_stale.py` detects hand-edits.
87
+ - **Approval = merge + status flip.** A human flips `status: approved` in frontmatter and fills `decided_by` on decisions. Agents never do.
88
+ - **Commit prefixes** keep the log readable as a changelog: `evidence:`, `decision:`, `regen:`, `review:`.
89
+ - **CI:** run `python strategy/scripts/check_stale.py` — non-zero exit if anything is stale, hand-edited, or has broken citations.
90
+
91
+ ## Citation grammar
92
+
93
+ Projections cite evidence items and decisions; items cite sources. Two hops, each simple.
94
+
95
+ - `[E: ev-0042]` — evidence item (carries source, location, confidence, date)
96
+ - `[D: dec-003]` — human decision record
97
+ - `[I]` — inference by the drafting agent (says from what)
98
+ - `[A]` — assumption awaiting confirmation (must appear in `open_questions`)
99
+
100
+ A factual sentence in a projection with none of these tags is a defect the red team flags. Secondhand evidence never solely supports a differentiator or headline claim.
101
+
102
+ ## A worked example
103
+
104
+ `examples/seelray/` contains a complete Burgess run against a real ~600-line PRD — evidence base, gap report, themes, positioning with proposed decision records, a staleness cascade triggered by a win/loss batch, red-team reviews (including one catching planted defects), and a delete-and-regenerate acceptance test. Its git log reads as a strategy changelog.
105
+
106
+ ## License
107
+
108
+ MIT
package/bin/burgess.js ADDED
@@ -0,0 +1,136 @@
1
+ #!/usr/bin/env node
2
+ /**
3
+ * Burgess installer — copies the Burgess agent skills into your
4
+ * Claude Code or Codex skills directory. No dependencies, no telemetry.
5
+ *
6
+ * npx burgess install # ~/.claude/skills (Claude Code, personal)
7
+ * npx burgess install --project # ./.claude/skills (this repo only)
8
+ * npx burgess install --codex # ~/.agents/skills (Codex)
9
+ * npx burgess install --dest DIR # anywhere else
10
+ */
11
+
12
+ "use strict";
13
+ const fs = require("node:fs");
14
+ const path = require("node:path");
15
+ const os = require("node:os");
16
+
17
+ const SKILLS_SRC = path.join(__dirname, "..", "skills");
18
+ const args = process.argv.slice(2);
19
+ const cmd = args.find((a) => !a.startsWith("-")) || "help";
20
+ const has = (flag) => args.includes(flag);
21
+ const val = (flag) => {
22
+ const i = args.indexOf(flag);
23
+ return i !== -1 && args[i + 1] ? args[i + 1] : null;
24
+ };
25
+
26
+ function targetDir() {
27
+ if (val("--dest")) return path.resolve(val("--dest"));
28
+ const codex = has("--codex");
29
+ if (has("--project")) return path.resolve(codex ? ".agents/skills" : ".claude/skills");
30
+ return path.join(os.homedir(), codex ? ".agents/skills" : ".claude/skills");
31
+ }
32
+
33
+ function skillNames() {
34
+ return fs
35
+ .readdirSync(SKILLS_SRC, { withFileTypes: true })
36
+ .filter((d) => d.isDirectory())
37
+ .map((d) => d.name);
38
+ }
39
+
40
+ function install() {
41
+ const dest = targetDir();
42
+ fs.mkdirSync(dest, { recursive: true });
43
+ const names = skillNames();
44
+ const skipped = [];
45
+ const installed = [];
46
+ for (const name of names) {
47
+ const to = path.join(dest, name);
48
+ if (fs.existsSync(to) && !has("--force")) {
49
+ skipped.push(name);
50
+ continue;
51
+ }
52
+ fs.rmSync(to, { recursive: true, force: true });
53
+ fs.cpSync(path.join(SKILLS_SRC, name), to, { recursive: true });
54
+ installed.push(name);
55
+ }
56
+ console.log(`\nBurgess skills -> ${dest}\n`);
57
+ if (installed.length) console.log(` installed: ${installed.join(", ")}`);
58
+ if (skipped.length)
59
+ console.log(
60
+ ` skipped (already exist): ${skipped.join(", ")}\n` +
61
+ ` re-run with --force to overwrite them`
62
+ );
63
+
64
+ // Older bundles overlap in scope; flag them if present. "groundwork" was
65
+ // Burgess's working name before publication.
66
+ const legacy = ["vision-workflow", "ingest-context", "derive-strategic-themes",
67
+ "generate-messaging", "generate-brand-assets", "groundwork"].filter((n) =>
68
+ fs.existsSync(path.join(dest, n))
69
+ );
70
+ if (legacy.length)
71
+ console.log(
72
+ `\n note: found older bundle folders (${legacy.join(", ")}).\n` +
73
+ ` Burgess supersedes them — consider removing those folders so\n` +
74
+ ` two workflows don't compete to answer the same requests.`
75
+ );
76
+
77
+ console.log(`
78
+ Get started
79
+ -----------
80
+ 1. Open ${has("--codex") ? "Codex" : "Claude Code"} in your product repo (or an empty repo for strategy).
81
+ 2. Say: "set up burgess" — the orchestrator scaffolds a strategy/ directory
82
+ and guides you from there.
83
+ 3. Have documents? Say "ingest these docs". Have nothing written down?
84
+ Say "interview me" — the intake interview IS ingestion for early-stage teams.
85
+
86
+ The first thing you get is a gap report: an honest account of what your
87
+ evidence can't yet support, and the highest-value questions to answer next.
88
+ `);
89
+ }
90
+
91
+ function uninstall() {
92
+ const dest = targetDir();
93
+ const removed = [];
94
+ for (const name of skillNames()) {
95
+ const to = path.join(dest, name);
96
+ if (fs.existsSync(to)) {
97
+ fs.rmSync(to, { recursive: true, force: true });
98
+ removed.push(name);
99
+ }
100
+ }
101
+ console.log(removed.length ? `removed from ${dest}: ${removed.join(", ")}` : `nothing to remove in ${dest}`);
102
+ }
103
+
104
+ function list() {
105
+ console.log("Burgess skills in this package:\n");
106
+ for (const name of skillNames()) {
107
+ const skillMd = path.join(SKILLS_SRC, name, "SKILL.md");
108
+ let desc = "";
109
+ try {
110
+ const m = fs.readFileSync(skillMd, "utf8").match(/^description:\s*(.+)$/m);
111
+ if (m) desc = m[1].split(". ")[0] + ".";
112
+ } catch {}
113
+ console.log(` ${name.padEnd(22)} ${desc}`);
114
+ }
115
+ }
116
+
117
+ function help() {
118
+ console.log(`
119
+ burgess — evidence-first strategy skills for Claude Code / Codex
120
+
121
+ Usage:
122
+ burgess install [--project] [--codex] [--dest DIR] [--force]
123
+ burgess uninstall [--project] [--codex] [--dest DIR]
124
+ burgess list
125
+
126
+ Targets:
127
+ (default) ~/.claude/skills Claude Code, all your projects
128
+ --project ./.claude/skills Claude Code, this repo only
129
+ --codex ~/.agents/skills Codex (combine with --project for ./.agents/skills)
130
+ --dest DIR anywhere
131
+
132
+ Then open your agent and say "set up burgess".
133
+ `);
134
+ }
135
+
136
+ ({ install, uninstall, list, help }[cmd] || help)();
package/package.json ADDED
@@ -0,0 +1,30 @@
1
+ {
2
+ "name": "burgess",
3
+ "version": "0.1.0",
4
+ "description": "Burgess: an evidence-first strategy engine as agent skills. Turn documents and interviews into a provenance-linked evidence base; project positioning, messaging, vision, and brand from it as regenerable, diffable artifacts.",
5
+ "keywords": [
6
+ "claude-code",
7
+ "codex",
8
+ "agent-skills",
9
+ "positioning",
10
+ "strategy",
11
+ "messaging",
12
+ "brand",
13
+ "product-marketing"
14
+ ],
15
+ "bin": {
16
+ "burgess": "bin/burgess.js"
17
+ },
18
+ "files": [
19
+ "bin",
20
+ "skills",
21
+ "README.md"
22
+ ],
23
+ "scripts": {
24
+ "postinstall": "node -e \"if(!process.env.npm_config_global)console.log('Run: npx burgess install (or burgess help)')\""
25
+ },
26
+ "engines": {
27
+ "node": ">=18"
28
+ },
29
+ "license": "MIT"
30
+ }
@@ -0,0 +1,43 @@
1
+ ---
2
+ name: build-brand-platform
3
+ description: Assemble a brand platform from Burgess's vision, positioning, and messaging — purpose and values inherited verbatim, personality and voice with do/don't examples, value pillars with proof, usage guidelines, and the prohibited-claims list that enforces every upstream guardrail downstream. Use this skill whenever the user asks for a brand platform, brand guidelines, brand voice, tone of voice, brand personality, or "how should we sound" — after vision and positioning exist, or standalone with a warning that style without strategy doesn't hold.
4
+ ---
5
+
6
+ # Build Brand Platform
7
+
8
+ The brand platform wraps the strategy into an identity system anyone — marketer, founder, agency, or AI — can apply consistently. Its authority comes from **inheritance**: purpose and values from vision, pillars from positioning, proof from evidence. The platform adds *expression* (personality, voice, governance), never new strategy. Its sharpest tooth is the prohibited-claims list — the mechanism by which every evidence guardrail upstream reaches every future writer and tool. Formats in the burgess skill's `references/schemas.md`.
9
+
10
+ ## Inputs
11
+
12
+ Read `projections/vision.md`, `projections/positioning.md`, `projections/messaging.md`, and the decisions they cite; run `python scripts/check_stale.py` first. **Standalone without upstream artifacts:** gather the minimum interactively (what the company exists to do, top differentiators with proof, 2–3 adjectives for how it wants to sound), record via `intake-interview`'s steps, and warn plainly: a platform without underlying positioning is style without strategy.
13
+
14
+ ## Procedure
15
+
16
+ 1. **Inherit purpose and values.** Copy `core_purpose` and `core_values` from `projections/vision.md` **verbatim in meaning**. If customer-facing phrasing must differ from internal wording, show both and note the translation — meaning must not drift. Never re-derive purpose here; two competing purposes is how brands become incoherent. If vision.md doesn't exist, this section is blocked, not improvised — offer to run `generate-vision`.
17
+ 2. **Personality and voice (3–5 traits).** Traits that express the values and fit the ICPs (a developer-tools brand and a healthcare brand earn trust with different registers). Per trait: one **Do** (an example sentence in-voice) and one **Don't** (the near-miss anti-pattern — the exaggerated or off-key version). The don'ts are what make voice guidelines usable; without them every trait reads as "confident but friendly" mush.
18
+ 3. **Value pillars — reasons to believe (3–5).** Take the differentiation pillars from positioning and attach concrete proof points `[E:]`. Every pillar answers "says who?" with something checkable.
19
+ 4. **Usage guidelines.** How the voice flexes by context: website (persuasive), docs (plain, precise), sales (direct), employer brand (candid). Same personality, different register.
20
+ 5. **Prohibited claims.** Compile the specific list downstream writers and AI tools must never use:
21
+ - claims the evidence base cannot support (name them — "fastest", "only platform that…"),
22
+ - claims contradicting known `limitation` items (enumerate each limitation marketing could be tempted to contradict),
23
+ - superlatives without proof ("best", "leading", "guaranteed"),
24
+ - compliance-sensitive phrasing (certifications not held, regulated-industry promises),
25
+ - **past-tense results language for anything not shipped and measured** ("we've demonstrated", "proven with customers") — for pre-launch products this is the list's most load-bearing entry,
26
+ - custody/scope precision rules where the evidence draws a boundary (e.g., a claim true of one tier but not the default).
27
+ Be specific, not generic — a prohibited-claims list that could apply to any company enforces nothing.
28
+
29
+ ## Output
30
+
31
+ Write `projections/brand-platform.md`: frontmatter per schema (`artifact: brand-platform`, `depends_on: [vision, positioning, messaging]`), sections: **Purpose** (inherited; translation noted), **Values** (inherited), **Personality & Voice** (per trait: Do / Don't), **Value Pillars** (table: pillar, proof points `[E:]`), **Usage Guidelines**, **Prohibited Claims**.
32
+
33
+ Then: `python scripts/check_stale.py --record brand-platform`, commit `regen: brand-platform`, run `red-team` — which from now on scans everything against the prohibited-claims list.
34
+
35
+ ## Guardrails
36
+
37
+ - Purpose and values inherited verbatim in meaning; only surface phrasing may adapt, with the translation shown.
38
+ - Every value pillar carries at least one cited proof point.
39
+ - The prohibited-claims list must cover every known limitation from the evidence base that marketing could contradict — walk the `limitation` items one by one and check.
40
+
41
+ ## Checkpoint
42
+
43
+ Present the personality traits with their Do/Don't pairs and the full prohibited-claims list — the two sections humans most need to own. Ask whether legal/compliance should review the prohibited list before assets are generated; record the answer as a decision.
@@ -0,0 +1,66 @@
1
+ ---
2
+ name: burgess
3
+ description: Orchestrates Burgess, the evidence-first strategy engine — turns a company's documents and interviews into a provenance-linked evidence base and projects positioning, messaging, vision, and brand from it. Use this skill whenever the user wants to set up or run Burgess, asks "where were we" on strategy work, wants a status check on their strategy repo, mentions turning docs/PRDs/interviews into positioning or vision, asks what's stale or needs regenerating, or wants to start the guided strategy process. Also trigger on first contact with a repo containing a strategy/ directory with a manifest.yaml.
4
+ ---
5
+
6
+ # Burgess Orchestrator
7
+
8
+ Burgess inverts the usual strategy asset: the durable product is the **evidence base** — atomized, provenance-linked, confidence-tagged claims — and every strategy artifact (themes, positioning, messaging, vision, brand) is a cheap, regenerable **projection** of it. Your job as orchestrator: know the state, run the right skill next, enforce the checkpoints, keep the staleness math honest, and make the whole thing feel guided rather than bureaucratic.
9
+
10
+ Read `references/schemas.md` (formats), `references/conventions.md` (working rules), and `references/frameworks.md` (grounding) before running anything you haven't run this session. Those three files are shared by every Burgess skill.
11
+
12
+ ## The pipeline
13
+
14
+ | Step | Skill | Reads | Writes |
15
+ |---|---|---|---|
16
+ | Ingest | `ingest-evidence` | source docs | `evidence/`, `gap-report.md` |
17
+ | Interview | `intake-interview` | `gap-report.md` | `evidence/intake/`, new items, `gap-report.md` |
18
+ | Themes | `derive-themes` | evidence | `projections/themes.md` |
19
+ | Positioning | `derive-positioning` | themes, decisions | `projections/positioning.md`, proposed decisions |
20
+ | Messaging (P2) | `derive-messaging` | positioning | `projections/messaging.md` |
21
+ | Vision (P3) | `generate-vision` | themes, decisions | `projections/vision.md` |
22
+ | Brand (P3) | `build-brand-platform` | vision, positioning, messaging | `projections/brand-platform.md` |
23
+ | Assets (P3) | `generate-assets` | messaging, brand | `projections/assets/` |
24
+ | Red team | `red-team` | any projections | `reviews/review-<date>.md` |
25
+
26
+ If a step's skill is not installed, follow this skill's `references/` directly — the references are canonical; the skills are packaging.
27
+
28
+ ## First run: scaffold and guide
29
+
30
+ If no `strategy/` directory with a `manifest.yaml` exists:
31
+
32
+ 1. **Ask where it lives** — its own repo or a `strategy/` directory in the current repo (default: `strategy/` here).
33
+ 2. **Scaffold**: create the layout from `references/schemas.md` (§Repo layout); write `manifest.yaml` verbatim from the schema template; write an empty `sources.yaml` (`sources: []`); copy `scripts/check_stale.py` from this skill's `scripts/` into `strategy/scripts/`; write a `.gitattributes` containing `* text=auto eol=lf` (staleness hashes are computed over file bytes — line-ending rewrites across machines would fake staleness).
34
+ 3. **Git**: if not already in a git repo, recommend `git init` — diffable strategy is the point. First commit: `evidence: scaffold burgess strategy repo`.
35
+ 4. **Route by what they have.** Ask one question: "Do you have documents (PRD, architecture docs, decks, transcripts) — or should we start by talking?" Documents → `ingest-evidence`. Nothing yet → `intake-interview` standalone (for early-stage companies the founder interview IS ingestion). Never make a documents-less user feel they're missing a prerequisite.
36
+
37
+ Tell the user what got created and what happens next in one short paragraph, not a lecture.
38
+
39
+ ## Every run: detect state first
40
+
41
+ 1. Run `python scripts/check_stale.py` in the strategy repo before doing anything.
42
+ 2. Report a status table: each node — exists? status (draft/approved)? stale? — plus open `proposed_decisions` awaiting `decided_by`, open `open_questions`, and the top unanswered gap-report questions.
43
+ 3. Confirm scope: continue where things left off, run a specific step, ingest new material, or red-team. When the user asks "where were we", this table *is* the answer — lead with the single most useful next action.
44
+
45
+ ## Running steps
46
+
47
+ - Run skills in dependency order; never generate downstream of a stale input without telling the user (proceeding on stale/draft inputs is allowed, recorded in `open_questions`).
48
+ - After any skill writes a projection: run `python scripts/check_stale.py --record <node>`, then run `red-team` against the changed artifacts (every regeneration, not just finales), then commit with the right prefix (`regen:`, `review:`).
49
+ - Regenerating an `approved` artifact: set its frontmatter back to `draft` and tell the user why (new evidence means the human re-approves the projection of it).
50
+ - New evidence mid-stream (user drops in win/loss notes, transcripts): route to `ingest-evidence`, then report the staleness cascade and offer regeneration in dependency order.
51
+
52
+ ## Checkpoints
53
+
54
+ After each artifact: present a summary, its `open_questions`, and its `proposed_decisions`; ask the human to approve, correct, or answer. Corrections are evidence — route them through `intake-interview` capture (they become items), never silent edits.
55
+
56
+ **Waived runs** ("just run it all"): checkpoints are recorded, not held. Questions land in `open_questions`, proposed decisions stay undecided, everything stays `draft`, and the run ends with a single consolidated sign-off list: every decision awaiting `decided_by`, every `[A]`, every gap accepted. Do not soften this list — the waiver deferred the decisions; it didn't make them.
57
+
58
+ **Approval**: only humans flip `status: approved` or fill `decided_by`. When the user says "approved", tell them exactly which frontmatter line to change (or make the edit at their explicit direction, quoting their approval in the commit message: `decision: dec-003 decided by <name>`).
59
+
60
+ ## Hand-edit warnings
61
+
62
+ When `check_stale.py` reports HAND-EDITED: someone changed a projection directly. Don't regenerate over it — the edit is information trapped in the wrong layer. Show the diff vs. what was recorded, ask what evidence or decision the edit reflects, capture that in `evidence/` or `decisions/`, then regenerate.
63
+
64
+ ## Phasing
65
+
66
+ Phase 1 (evidence, gap report, intake, themes, positioning, red team) is the wedge — it churns weekly and delivers value with zero projections generated. Offer Phase 2 (messaging) once positioning is approved; Phase 3 (vision, brand, assets) when the user asks or when messaging is settled. Don't push the full pipeline on a user who came for positioning.
@@ -0,0 +1,64 @@
1
+ # Burgess Conventions
2
+
3
+ Working rules every skill follows. These encode failure modes observed in live testing — each rule exists because its absence produced a specific defect.
4
+
5
+ ## The prime directive
6
+
7
+ **The evidence base is the product; artifacts are projections.** Any strategy artifact must be regenerable from `evidence/` + `decisions/` alone. If regenerating an artifact would lose information, that information belonged in an evidence item or a decision record — put it there first, then regenerate.
8
+
9
+ ## Never hand-edit projections
10
+
11
+ A wrong claim in `positioning.md` is fixed by correcting or adding evidence items or decision records, then regenerating. Hand-edits trap information outside the evidence base and die on the next regeneration. `check_stale.py` detects hand-edits (current hash ≠ recorded `output_hash`); when it flags one, help the user move the edit's substance into evidence/decisions before regenerating over it.
12
+
13
+ ## Humans decide; agents draft and argue
14
+
15
+ - Agents never write `status: approved` in any frontmatter. Ever.
16
+ - Agents never fill `decided_by` on a decision record. They propose with `decided_by: null` and mandatory `rejected` alternatives.
17
+ - Every judgment call (market category, beachhead, horizon, values, "may pre-launch claims ship?") becomes a PROPOSED decision record — not prose in an artifact.
18
+ - An unfilled decision blocks `approved` on artifacts citing it, but never blocks `draft` generation.
19
+ - Regeneration honors existing decision records, decided or proposed: cite them, don't re-propose duplicates. A new record on an already-covered question exists only to argue for changing the old one, and names it. Same evidence + same decisions → same conclusions is the regenerability contract.
20
+
21
+ ## Checkpoint discipline and waived runs
22
+
23
+ After generating any artifact: present it with its `open_questions` and `proposed_decisions`, and hold for human review. When the user says "just run it all" (a **waived run**), checkpoints are *recorded, not held*: every checkpoint question lands in `open_questions`, everything stays `draft`, and the run ends with one consolidated sign-off list. Never simulate approval; never soften the sign-off list because the user waived checkpoints — the waiver defers decisions, it doesn't make them.
24
+
25
+ ## Pre-launch rule
26
+
27
+ "Current capability" means **shipped and demonstrated**. For pre-launch products, committed spec scope may ground positioning, but every such claim must be:
28
+ 1. phrased prospectively (never "we've demonstrated", "proven with customers"),
29
+ 2. labeled as committed scope, and
30
+ 3. gated on a recorded human decision: "may this ship before launch evidence exists?" — propose the decision record; don't decide it.
31
+
32
+ Past-tense results claims for unshipped capability are automatic HIGH red-team findings. This exact defect occurred in live testing; the tense scan is not optional.
33
+
34
+ ## Conflicts and supersession
35
+
36
+ Two sources disagree → mark **both** items `disputed`, surface for human resolution, cite both until resolved. Never silently pick one. A newer version of the same source → mark old items `superseded`, link `superseded_by`; superseded items stay on disk (provenance) but leave the evidence hash.
37
+
38
+ ## Staleness
39
+
40
+ Run `python scripts/check_stale.py` (in the strategy repo) **before and after** any operation. Before: report what's stale so the user isn't building on sand. After: `--record` the nodes you regenerated, and commit `manifest.yaml` in the same commit as the projection it records — they change together or the tree drifts. Draft artifacts citing undecided decisions produce checker *warnings* by design — they block approval, not drafting, and the run still reports clean; don't chase them. Offer regeneration in dependency order: evidence → themes → positioning → messaging → vision → brand-platform → assets. Regenerating an `approved` artifact demotes it to `draft`.
41
+
42
+ ## Red team on every regeneration
43
+
44
+ Drift compounds silently in long generation chains. After any projection regenerates, run the `red-team` skill against the changed artifact set — as part of the pipeline, not as a finale. On-demand runs against any artifact subset are also fine.
45
+
46
+ ## Git workflow
47
+
48
+ - **Branch per strategy change.** New evidence batch or decision → branch → regenerate affected projections → PR. The PR diff *is* the strategy review: reviewers see exactly which claims changed and which evidence moved them.
49
+ - **Approval = merge + status flip.** A human flips `status: approved` in artifact frontmatter (and fills `decided_by`) in the PR. Agents never do.
50
+ - **Commit prefixes** so the strategy log reads like a changelog:
51
+ - `evidence:` — new/changed evidence items, sources, intake transcripts
52
+ - `decision:` — decision records proposed or decided
53
+ - `regen:` — projections regenerated (say from what: `regen: positioning after ev-0107..0112`)
54
+ - `review:` — red-team output
55
+ - `reviews/` and `evidence/intake/` are append-only; `gap-report.md` and projections are current-state (git history is their archive).
56
+ - If the strategy repo isn't under git yet, recommend `git init` at scaffold time — diffable positioning is the killer feature, and it needs git.
57
+
58
+ ## Language discipline
59
+
60
+ Neutral, factual language in evidence items, gap reports, and themes. Persuasive language only downstream of positioning. Marketing spin in an evidence item is a defect: it launders opinion into the layer everything else trusts.
61
+
62
+ ## Standalone invocation
63
+
64
+ Every skill runs solo. When upstream inputs are missing, gather the minimum interactively, then **record what you gathered as intake evidence** (transcript + atomized items), never as untracked context. Standalone runs still update the manifest and gap report — there is no off-the-books mode.
@@ -0,0 +1,39 @@
1
+ # Framework Grounding
2
+
3
+ Established strategy frameworks each skill rests on. These are settled for Burgess — do not re-litigate them mid-run. Each note says what the framework is and why the skill uses it that way, so a skill can explain its rules when a user pushes back.
4
+
5
+ ## Themes: affinity mapping (KJ method)
6
+
7
+ Clustering many observations into 3–7 named themes is affinity mapping / thematic analysis — long-established synthesis practice; 3–7 clusters matches working-memory guidance. Themes are named by the **customer's problem**, not the product's feature ("teams can't trust hand-offs", not "workflow automation"), because problem-named themes survive product pivots and feature-named ones don't.
8
+
9
+ ## Competitive analysis: Dunford's competitive alternatives
10
+
11
+ The competitive unit of analysis is **what customers would actually do instead** — which includes the status quo, spreadsheets, manual process, building in-house, hiring someone, and doing nothing — not just named competitor products (April Dunford, *Obviously Awesome*). The status quo is usually the biggest competitor; a map with only named products is incomplete. Consequence, applied mechanically: a strength shared by the main alternatives is **TABLE STAKES**, never a differentiator, however central it is to the product. The alternatives map is built *before* strength classification so the test has something to test against. This defeats flattery bias — the failure mode where everything becomes a differentiator.
12
+
13
+ ## Positioning: Dunford's five components, in order
14
+
15
+ Derive: competitive alternatives → unique attributes → value → best-fit customers → market category. The order matters because each answer constrains the next; positioning is a set of interdependent choices, not blanks in a template. Dunford is explicitly critical of *starting* from the Moore fill-in-the-blanks statement ("For [ICP] who [need]…") — it assumes each blank has one obvious answer. The Moore statement is only ever an optional **summary output**, written last. Market-category options: head-on (existing category), subsegment/niche (usually the right answer), new category (rare, expensive to educate — strong justification required). Record rejected categories with reasons; the rejections make the choice reviewable.
16
+
17
+ ## Beachhead: Moore's bowling pin (optional, early-stage)
18
+
19
+ For early-stage products: a beachhead niche with outsized value plus a bowling-pin expansion path to adjacent segments (Geoffrey Moore, *Crossing the Chasm*). Optional; a recommendation, not a product constraint — always a proposed decision record.
20
+
21
+ ## Vision: Collins & Porras core ideology + envisioned future
22
+
23
+ Vision = **core ideology** (core purpose — why the org exists beyond making money — plus 3–5 core values) + **envisioned future** (vivid destination at a horizon, strategic pillars, milestones) (Collins & Porras, "Building Your Company's Vision", HBR 1996). Purpose and values are *discovered from behavior*, not invented — a value with no behavioral evidence (from `culture` evidence items) is marked ASPIRATIONAL for human confirmation. Purpose/values are stable; the envisioned future is a bet with a date. Positioning describes the market **today** and must be winnable now — merely *consistent with* the vision, never derived from it. Optional stress test: a future press release (Amazon PR/FAQ practice) — if it's boring, the vision is too.
24
+
25
+ ## Messaging: the message house
26
+
27
+ One roof (master value proposition), 3–5 walls (key messages, one per differentiation pillar), proof-point foundation — so every downstream asset draws from the same small set of claims backed by the same proof, instead of each asset inventing its own. Messaging is downstream of positioning, never the reverse. Benefit bullets come from `customer_language` evidence items; where none exist they are engineered from internal language and flagged `engineered — validate with customers` so nobody mistakes them for validated copy.
28
+
29
+ ## Brand: inheritance + prohibited claims
30
+
31
+ Brand platform structure (purpose, values, personality, voice as trait + do + don't, value pillars with proof, governance) follows mainstream brand-identity practice (Aaker's identity system; Keller's insistence that every claimed benefit carries proof). Purpose and values are **inherited verbatim in meaning** from vision — one source of truth; two competing purposes is how brands become incoherent. The **prohibited-claims list** is the downstream enforcement mechanism: claims the evidence can't support, claims contradicting known limitations, unproven superlatives, compliance-sensitive phrasing, and past-tense results language for unshipped capability. It's what makes the evidence guardrails enforceable by every future writer and tool.
32
+
33
+ ## Red team: the pre-mortem
34
+
35
+ An adversarial pass is standard QA for strategy (Klein's pre-mortem). For AI-generated strategy it is essential: the chain is long and drift accumulates. Personas argue **hard** — a skeptical target customer, the strongest competitive alternative writing a counter-pitch, a skeptical board member. Personas produce severity-rated findings, never pass/fail; the value of the pass is proportional to how hard it argues.
36
+
37
+ ## Gap-first ingestion
38
+
39
+ Documents describe the product from the inside. Positioning and vision also need outside-in evidence: customer language, competitive alternatives, win/loss, market data (Dunford; JTBD research per Christensen/Ulwick). The single biggest failure mode of "positioning from the PRD" is inside-out positioning that describes the architecture instead of the customer's problem. So ingestion always produces the gap report, and the intake interview is the front door for filling it — for early-stage companies the founder interview is the highest-density corpus, and the documents are supporting evidence for what it surfaces.