@aicopycoders/exodus 2026.9.1100-beta.2 → 2026.9.1400-beta.0

package/assets/skills/positioning-spiral/SKILL.md

@@ -0,0 +1,166 @@
+---
+name: positioning-spiral
+description: The parent thinking loop for positioning a product before any ads get written. Use it whenever someone is onboarding a new brand or client, starting a new SKU, asking "who do we sell this to and what's the story", "what's the mechanism", "does this hang together", "are we positioned right", or wants segments, personas, and mechanisms figured out together. It cycles through five stations (features, targets, research, catalog, thinking) until segments, mechanisms, and story are coherent, calling the station skills (odf, mechanism, find-competitors, patterns-and-gaps) as needed. Trigger it even when the user only names one piece ("let's look at the ingredients", "find me competitors for this") if no coherent positioning exists yet, because that piece will change the others. Do not use it for writing ad copy or images; it stops when the story is coherent.
+---
+
+# Positioning Spiral
+
+Positioning is not a line. It is a spiral. The mechanism you pick depends on the segment, the segment depends on what is provable, what is provable depends on what competitors have already paid to learn, and all of it has to fit inside a catalog that already exists. So you do not do these once each. You loop through them, and each pass changes the question at the next station, until the whole thing holds together and nothing contradicts it.
+
+This skill is the parent (the positioning spiral). It decides which station to visit next, keeps the loop in think mode, and runs the exit test. The station skills do the depth. If a station skill is not installed, run that station as a conversation using the notes below.
+
+## The two modes
+
+Read the `thinking-vs-build` skill if installed. The short version:
+
+- **Think mode** is the default for this whole loop. One station per exchange. Short lists. One or two words per item. Propose, let the user cut, move on. No documents.
+- **Build bursts** happen inside a station when data needs gathering: rip these ads, scrape these reviews, pull these competitor pages. Run them comprehensively without check-ins, write files early, report spend, then come back to think mode and say what the new data changed.
+- **The exit test passing is the build cue.** Only then write the story page, the grid, and the mechanism map.
+
+The most common failure is building a document at a station that only needed a list. If the user has not said "build", "make", "write the doc", or "put that in", stay in think mode.
+
+## The five stations
+
+Each station answers one question. Each has inputs to ask for, a station skill for depth, and a note on what it tends to change elsewhere.
+
+### 1. Features: what is possible to say
+
+Ingredients first. Then everything else the brand can honestly claim: the form factor (dropper, gummy, powder), the founders and creators and their story, the brand's origin, manufacturing or sourcing facts, anything a competitor could not copy tomorrow.
+
+Ask for: the formula with doses, the product bible or spec, founder background, what the brand already says about itself.
+
+Output in think mode: a list of candidate mechanisms and story elements, one or two words each, with the ingredient or feature that backs each one. The star ingredient goes in every mechanism. Supporting ingredients never lead.
+
+Depth: `mechanism` skill (competitor mechanism file, the Genesis mechanism bots, the simplicity gates, the lock).
+
+Changes elsewhere: a mechanism the market already believes (cortisol, gut, hormones) pulls targets toward the people who use that word. A founder story pulls toward the identity axis.
+
+### 2. Targets: who is plausible
+
+Segments and personas. Outcomes the buyer wants fixed, the demographics you can tick from across the room, the identity they claim, the facets that explain why they are here now.
+
+Ask for: current buyers, the ads with the best hold, comments under running ads.
+
+Output in think mode: outcomes as one or two words with sub-outcomes beneath, then demographics, identity, facets, one axis per exchange.
+
+Depth: `odf` skill, MAP entry point. The stress-test rules there apply: different human not synonym, nothing in two rows, states and occasions are facets, copy lines are not segments.
+
+Changes elsewhere: every new segment needs a mechanism it believes and a competitor or review that proves someone like them buys. A segment with neither goes on hold.
+
+### 3. Research: what is proven, and what people already say
+
+Two halves, kept separate because they prove different things.
+
+**Competitor products.** Who is scaling, on which mechanism (their UMP, the mechanism they sell as positioning), with what offer, for how long. Group competitors by mechanism, not by category. A long-running ad is evidence the angle converts. Rip transcript, headline, body, rank, on-screen text, and keep the user's per-brand notes verbatim next to the evidence.
+
+**Voice of customer.** Reviews, comments, Reddit, in exact words. Rank sources by volume because volume is language richness. Count mentions. Keep quote banks by theme with reference numbers. Negatives are data.
+
+Ask for: the brands the user already watches and their read on each, Atria or Ad Library access, Amazon categories to shortlist.
+
+Output in think mode: the two or three angles competitors have proven, the two or three themes reviews say loudest, and one line on where they disagree with the current targets.
+
+Depth: `find-competitors` (who is strong, proven with numbers, grouped by UMP) and `patterns-and-gaps` (what repeats, what lands, what is missing).
+
+Changes elsewhere: this is where "stress" dies and "3AM waking" is born. If no competitor and no review backs a target, mark it hypothesis and move it down the focus order.
+
+### 4. Catalog: what does not collide
+
+Every proposal against the brand's other SKUs and the brand's own live ads. A sister product already claiming the mechanism is a collision. A sister product's ads targeting the same segment is a collision. The product bible saying one ingredient while the ad says another is a flag.
+
+Ask for: the full catalog with formulas, the brand's own ad account pulled by SKU.
+
+Output in think mode: one line per collision and the copy rule that resolves it ("cortisol belly belongs to the collagen; we take night cortisol").
+
+Depth: none needed; this is a scan. Run it after any new mechanism or target proposal, before the user asks. They will ask anyway.
+
+Changes elsewhere: a collision sends you back to features or targets for a lane the catalog leaves open.
+
+### 5. Thinking: the coherent story
+
+The station where the user and the skill sit with the other four and ask whether it holds. No new data. Say the story in three sentences: who, what they feel, what the product does about it and why it works. Then check it against the exit test.
+
+Output in think mode: the story in three sentences, the focus order with a simple argument from ads, competitors, reviews, and logic, and the list of what is still hypothesis.
+
+## How to run the loop
+
+1. **Load what exists and say it back in one paragraph.** Product, formula, what it sells today, who buys now, what is winning and fatiguing, the sister SKUs. If the user has tested ads, read them raw before anything else; own winning ads outrank everything.
+2. **Enter at the richest station.** Usually features if the brand is new, targets if there are tested ads, research if the user arrives with a competitor list and a hypothesis. Do not force a fixed order.
+3. **One station per exchange.** Put a short list down. Let the user cut. Name what the answer changes at other stations in one line.
+4. **Run build bursts only for data.** When a station needs a rip or a scrape, say the plan back in two lines, get the go, then run it comprehensively and report spend. Write files early so a cut connection loses nothing.
+5. **Spiral.** After each station, ask which station the new answer weakens. Go there. Typical paths: features → targets → research → targets again → catalog → features again → thinking.
+6. **Run the standing checks every pass** (below).
+7. **When the exit test passes, say so and stop.** Offer the build: story page, segment grid, mechanism map. Wait for the build cue.
+8. **When the user says "note your place"**: what is done, what is missing, what is next. Then wait.
+
+## Exit test
+
+The story is coherent when every focus segment has all five, and nothing in one row contradicts another:
+
+| Segment | Mechanism | Proof | Quote bank | Collision |
+|---|---|---|---|---|
+| one outcome × one demographic × one or two facets | star ingredient plus at most one partner plus the form factor | a scaling competitor on this angle or an own winning ad | reviews or comments in their words, with counts | none, or a copy rule that resolves it |
+
+Anything backed by logic alone is marked HYPOTHESIS and sits below the proven segments in the focus order. The story in three sentences reads the same from every row.
+
+Evidence ladder when arguing a cell: own winning ad > long-running competitor ad > comment under a running ad > review or Reddit quote > logic.
+
+## Standing checks
+
+- **Collision** after any positioning or mechanism proposal, before being asked.
+- **"Is this backed by the reviews?"** Answer with counts or say thin.
+- **"Are we missing anything?"** Check the data for the biggest themes not on the list. Name at most three.
+- **Segments seen.** Any segment spotted in a competitor ad or the brand's own ads goes on a running list, even if it is not a focus.
+- **Compliance deferred.** World of possibilities first; flag hot words, do not censor them.
+- **Use the user's taxonomy.** Outcome, sub-outcome, demographic, identity, facet. Mechanism = ingredient story. UMP = the mechanism a competitor sells.
+
+## Output when the exit test passes
+
+```
+# <Brand> — <Product> — Positioning Story (v1, <date>)
+
+## The story (three sentences)
+Who. What they feel. What the product does and why it works.
+
+## Focus segments
+| # | Segment | Mechanism | Proof | Quote bank | Collision rule |
+
+## Hold (hypothesis)
+| Segment | Why it is on hold | What would prove it |
+
+## Collisions and copy rules
+- <sister SKU> owns <angle>; we take <angle>.
+
+## Segments seen (not focus yet)
+<a> · <b> · <c>
+
+## Where the evidence lives
+| Source | Path or link |
+```
+
+Then hand off: `odf` writes the grid and the personas, `mechanism` writes the mechanism map, and the production plan follows.
+
+## Worked example: Evenkeel Reset Gummies
+
+Fictional brand, fictional competitors, fictional numbers. The shape is what matters.
+
+**Setup.** Evenkeel sells Reset Gummies: saffron extract, magnesium glycinate, rhodiola, in an evening gummy. The founder is a former ER nurse. Sister SKUs: Night Tea (sleep) and Glow Collagen, whose ads already say "lowers cortisol". Current ads say "stress relief" and are fatiguing.
+
+**Pass 1, targets.** Tested ads read raw. The best hold is on an ad about waking at 3AM, not on any stress ad. Proposed outcomes: Sleep, Mood, Stress, Cortisol, Energy. User cuts Stress to a sub-outcome: "nobody buys for stress." What this changes: features needs a mechanism for night waking.
+
+**Pass 2, features.** Saffron has mood and sleep evidence; magnesium glycinate has night waking; rhodiola is a daytime adaptogen. Candidate mechanisms: "night cortisol" (saffron + magnesium), "mood" (saffron alone), "energy" (rhodiola). Star ingredient set to saffron; it goes in every one. What this changes: research needs to prove someone buys "night cortisol".
+
+**Pass 3, research.** Competitors grouped by UMP. Dawnfield ($2M a month) runs cortisol with symptom stacks in the hook: belly, puffy face, hips, wired at night. Nuvella runs cortisol plus gut. Root & Rise runs perimenopause. Reviews: "wake at 3AM" is the top sleep phrase by count; "puffy face" appears in cortisol product reviews, not sleep ones. What this changes: cortisol is proven as a word, but the visible symptoms are body and face, which Evenkeel cannot honestly claim to fix.
+
+**Pass 4, catalog.** Glow Collagen already says "lowers cortisol" and shows belly and face. Collision. Copy rule: Collagen owns cortisol belly and face; Reset owns night cortisol and the 3AM wake. Night Tea owns "fall asleep"; Reset owns "stay asleep". What this changes: targets tighten to staying asleep, peri mood, and evening rage.
+
+**Pass 5, thinking.** Story: women 40 to 55 who fall asleep fine and wake at 3AM with a racing mind; their evening cortisol never drops; saffron and magnesium bring it down so they sleep through. Proof: Dawnfield's night ads and the 3AM count in reviews. Quote bank: sleep reviews, 3AM theme. Collision: resolved by the copy rule. Hypothesis on hold: men 35 plus who wake at 4AM, no competitor proof yet.
+
+Exit test passes on three segments. The build cue comes from the user. ODF writes the grid.
+
+## What this skill is not
+
+It does not write ads, hooks, or images. It does not choose formats or conceits. It does not replace the station skills; it sequences them. When the story is coherent, it stops.
+
+## Standards
+
+Before producing anything, read `STANDARDS.md` at the workspace root (and the section for this output type). Grade the draft against it before showing it; rewrite failures first. When the user reacts with a judgment, a banking phrase, or the same note twice, hand the reaction to `remember-that`. At the end of the session, `handoff` scrapes the chat and proposes entries.

package/assets/skills/remember-that/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: remember-that
+description: Bank a reaction so it never has to be given again. Fires the moment the user says "remember that", "lock that in", "bank that", "add that to my rules", "always do X", "never do Y", "from now on", "make sure this never happens again", or gives the same note a second time. Also fires when they react to a draft with a clear judgment ("perfect, keep that", "that joke was too much", "not like that, like this"). It quotes the reaction verbatim, decides the rung (note, rule, tool, skill), writes it to STANDARDS.md in the right section, pushes winning lines to the matching Exodus bank, offers rather than pushes anything that would change a workflow or primer, and says in one line where it went. This is the Standards Ladder's "correct once, remember forever" move, packaged.
+---
+
+# Remember that
+
+A reaction that is not banked evaporates by the next session. This skill makes the bank happen in ten seconds, without the user opening a file.
+
+Read `STANDARDS.md` first, especially "How I give feedback". It governs this skill.
+
+## When it fires
+
+- A banking phrase: remember that, lock that in, bank that, add to my rules, always, never, from now on.
+- A tool phrase: make sure this never happens again, this can never slip through, set up a check.
+- A repeat: the same note given twice in this or a previous session (the Log section shows previous ones).
+- A judgment on a draft, when "How I give feedback" allows proposals: perfect keep that, too much, not like that.
+
+If it is a judgment rather than a phrase, propose the entry and wait for a yes. Never write a rule the user has not approved.
+
+## What it does, in order
+
+1. **Quote it exactly.** The raw words, typos included. The quote is the evidence; the rule is the interpretation.
+2. **Name the rung.**
+   - Note: said once, unclear if it generalises. Log it, do not write a rule yet. Say "logged; say it again and it becomes a rule."
+   - Rule: said with "always / never / from now on", or said twice. Write the one-line rule.
+   - Tool: "make sure this never happens again", or a rule that has been broken twice since it was banked. Say it should be a tool, describe the check in one line, build it under `standards/tools/` if the user says go (a script, a lint, a checklist the skill must run). Log it under Tools.
+   - Skill: a whole job that keeps repeating. Hand to `bot-builder`.
+3. **Pick the section.** Hooks, Copy, Statics, Workflows, Skills, Gnomes, Tools. A phrase the bots over-use goes to Gnomes. A change to how a skill behaves goes to Skills. Never edit the skill file itself: `exodus update` rewrites every skill folder, so the edit would be lost. The skills read their Skills rules from `STANDARDS.md`.
+4. **Write the entry.** One line, dated, then the quote underneath:
+   ```
+   - 2026-09-14 · Open on a declarative line, never a question.
+     > "Stop opening my emails with a question. It reads soft."
+   ```
+   Add the same line to Log with the rung and the destination.
+5. **Push what belongs on the server.**
+   - A winning line the user approved (a hook, a headline, a body) → `npx @aicopycoders/exodus bank promote <key> "<text>"` with `--awareness <pair>` for body banks. Automatic when "How I give feedback" says so. Keys: `hooks`, `headlines`, `body:unawareProblemAware`, `body:solutionProductAware`, `body:mostAware`, `modules`.
+   - A style rule that should change how a pipeline writes → offer, do not push: "This would go into the brand voice (`exodus foundation set brandVoice`) or the Guidelines note on the bot nodes in your workflow (`customInstructions`; a Prompt node has no such note, its text is `promptText`). Want it there?" Only on a yes: export, edit, validate, import.
+6. **Say where it went, in one line.** "Banked as a rule under Copy, and promoted to the hooks bank." Then continue the work; do not stop the session.
+
+## Rules for the skill itself
+
+- The user is the only source of rules. Proposals wait. Nothing the AI wrote goes in as if the user said it.
+- One entry per reaction. Do not merge, generalise, or rewrite old entries. If a new one contradicts an old one, add the new one and mark the old one superseded with the date.
+- Hand-edited files are read-only. If the reaction is about a file the user touched, write the rule, do not edit the file.
+- When a section passes a page, move it to `standards/<section>.md`, leave a one-line pointer in STANDARDS.md, and say so.
+- When a rule has been broken twice since it was banked, say so and offer the tool rung. A recurring failure is not a reason to nag harder.
+- Reading rules back: "show me my rules for hooks" prints that section verbatim.
+
+## What this skill is not
+
+It does not review a whole session for things worth banking; that is `handoff`. It does not build bots; that is `bot-builder`. It catches one reaction and puts it where the system will always see it.
+
+## Changelog
+
+- 2026-09-14 · v1.

package/assets/skills/segment-grid/README.md

@@ -0,0 +1,45 @@
+# Segment Grid Kit
+
+Build a segment map (outcomes × demographics × facets) with Claude Code, then push it into Exodus. Serene Herbs (a fictional brand) and its Nervous Balance Drops are the worked example.
+
+## What's in this folder
+
+- `SKILL.md` — the method. Tell Claude Code "build the segment grid" and it walks you through it one axis at a time. The `odf` skill is the newer, fuller version of the same method; this one stays for the hand-off doc.
+
+## How to run it
+
+1. The skill is installed with Exodus. Start Claude Code in your workspace folder.
+2. Give Claude what you have: product facts and formula, current ads and results, competitor ads, reviews, comments. More human language = better facets.
+3. Say "build the segment grid". Answer in short lists. One or two words per item. Let it stress-test.
+4. When the grid is agreed, Claude writes `segment-grid.md`.
+
+## Push it into Exodus
+
+Exodus keeps the map under Plan → Map. The CLI is the edit surface:
+
+```
+npx @aicopycoders/exodus segment export --out segments.json   # pull the current map (empty is fine)
+# edit segments.json
+npx @aicopycoders/exodus segment import segments.json          # dry-runs first, then applies
+npx @aicopycoders/exodus segment show                          # verify
+```
+
+The JSON shape:
+
+```json
+{
+  "brand": "Your Brand",
+  "product": "Your Product",
+  "outcomes": [ { "name": "Sleep", "subs": [ { "name": "3AM" }, { "name": "Racing mind" } ] } ],
+  "demos":    [ { "name": "Age", "values": [ { "name": "45–60" } ] } ],
+  "facets":   [ { "name": "State", "values": [ { "name": "On HRT and still" } ] } ],
+  "personas": []
+}
+```
+
+Things to know:
+
+- Import is a full replace, matched by name. Names missing from the file get deleted; personas they orphan get archived. If anything would be deleted the CLI refuses without `--yes`.
+- The dashboard keeps exactly five demographic rows: Buyer, Gender, Age, Race / Ethnicity, Identity. Extra demo groups are dropped silently. Put life stage under Age, occupation under Identity, medical conditions under the State facet.
+- Facet families are Belief, Identity, State, Value, Occasion.
+- Make sure the right brand is active first: `npx @aicopycoders/exodus brand current`.

package/assets/skills/segment-grid/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: segment-grid
+description: Build a segment grid for a product before writing personas or ads. Outcomes (1–2 words, with sub-outcomes) × Demographics × Identity × Facets (belief, state, value, occasion), stress-tested against ads, competitors, reviews, comments and logic. Use when someone says "map the segments", "who are we selling to", "build the grid", or before any persona or creative-strategy work. Works with no tools: a conversation, whatever data they have, this file.
+---
+
+# Segment Grid
+
+Think first, build second. This runs as a short back-and-forth: propose a list, get it argued down, move to the next axis. Every list item is one or two words. No documents until the grid is agreed.
+
+## The four axes
+
+1. **Outcomes** — what the buyer wants fixed. The spine. Each outcome has sub-outcomes (the different humans inside it).
+2. **Demographics** — what you could tick from across the room: gender, age band, race, buying for whom, occupation, life stage, medical identity.
+3. **Identity** — who they *say* they are ("the one who holds everyone together", "not a pill person", "the researcher").
+4. **Facets** — why they're here, invisible from across the room, in four families: **Belief** (what they think causes it), **State** (what they're on or have tried), **Value** (what they prefer), **Occasion** (something that happened; it has a date).
+
+A segment = one outcome × one demographic × one or two facets. A persona is a segment named as a human. This skill stops at the grid.
+
+## Steps
+
+1. **Load what they have.** Product and its fixed formula or spec, what it sells today, who buys now, what's winning and fatiguing, the other SKUs it must not collide with. Say it back in one paragraph.
+2. **Outcomes first.** Ask for their starting list. Sort each item into what it actually is: an outcome, a mechanism (cortisol), a demographic (menopause), or a copy line (brain fog). Propose additions from the data. Get to 6–10 outcomes, one or two words each.
+3. **Sub-outcomes.** Under each outcome, 3–5 sub-outcomes, one or two words each. Use the five lenses to find them: type (which kind), location (where it shows), function (what stops working), moment (when it hits), severity (how bad). Then stress-test (rules below).
+4. **Demographics.** Gender, age bands, race, buying-for, occupation, life stage, medical. Include the groups the product isn't for yet; mark exclusions.
+5. **Identity.** Pull from comments, reviews, the brand's own cast, and the ads that got the best hold. Include the other gender's versions.
+6. **Facets by family.** Belief, State, Value, Occasion. Check both genders. Sources: reviews ("what I tried", "what I replaced"), Reddit, comments, competitor ads (what they name and disqualify), logic (the conditions the category obviously has: shift worker, on a GLP-1, on an SSRI, postpartum).
+7. **Write the grid.** One markdown file: the four axes, the agreed focus order, and an empty coverage grid (outcomes × primary demographic columns) to fill with persona names later.
+
+## Stress-test rules
+
+- **One word or two per item.** If it needs a sentence it isn't an item yet.
+- **Different human, not a synonym.** Two sub-outcomes that describe the same person get merged.
+- **Nothing in two rows.** A symptom lives in one outcome (3AM lives in Sleep, not in Menopause or Cortisol).
+- **States are facets, not outcomes.** "On HRT", "off an SSRI", "tried everything" go under State.
+- **Occasions are facets, not outcomes.** "Doctor shrugged" goes under Occasion.
+- **Mechanisms are not outcomes** unless the market has adopted the word as the problem (cortisol qualifies; its row holds the visible symptoms).
+- **Life stages can be outcomes** when buyers name the stage as the problem ("my peri symptoms"). Keep it also as a layer over the other rows.
+- **The AI-artifact test.** A phrase that appears in many ads and few human mouths ("2PM crash", "wired but tired", "brain fog") is a copy line, not a segment. Count it in reviews and comments, not in ads.
+- **Formula fit.** Drop outcomes the product can't honestly touch (for a calming formula: hot flashes, libido, weight loss as the outcome).
+- **Compliance-hot words** (anxiety, panic, disease names) can be sub-outcomes but not headline outcomes; mark them.
+- **Exclusions are not segments.** A contraindication (SSRI + a serotonergic herb) goes in the medical list marked as an exclusion.
+
+## Evidence strength (when arguing an item)
+
+Own winning ad > long-running competitor ad > comment under a running ad > review or Reddit quote > logic. Mark pure logic as HYPOTHESIS.
+
+## Output template
+
+```
+# <Brand> — <Product> — Segment Grid (v1, <date>)
+
+## OUTCOMES
+| # | Outcome | Sub-outcomes |
+| 1 | <word> | <a> · <b> · <c> |
+
+## DEMOGRAPHICS
+| Gender | ... | Age | ... | Race | ... | Buying for | ... | Occupation | ... | Life stage | ... | Medical | ... (exclusions marked) |
+
+## IDENTITY
+<a> · <b> · <c> ...
+
+## FACETS
+| Belief | ... |
+| State | ... |
+| Value | ... |
+| Occasion | ... |
+
+## FOCUS ORDER
+1. <outcome → sub-outcome · demographic · facet> — one-line argument
+2. ...
+Hold: ...
+
+## COVERAGE GRID
+| Outcome | <demo col 1> | <demo col 2> | ... |
+(blank cells = gaps; fill with persona names later)
+```
+
+## How to run it in conversation
+
+- Propose, don't ask. Put a list down, let them cut it.
+- One axis per message. Outcomes → sub-outcomes → demographics → identity → facets → focus.
+- When they say "stress test", apply the rules above and show only what moved and why.
+- When they ask "are we missing anything", check the data for the biggest themes not on the list (fatigue and energy is the usual one) and name at most three.
+- Only write the file when the grid is agreed.

package/assets/skills/thinking-vs-build/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: thinking-vs-build
+description: The two working modes the user runs in and how to tell which one a message is in. The goal of both is a tight feedback loop with the expert: make it as easy as possible for them to apply light steering and thinking, so the work compounds toward something great instead of drifting. Think mode (the default) is short lists, one axis per message, one or two words per item, propose then they cut, no files. Build mode (only on a build cue) is the full thing, run comprehensively without check-ins, written to three homes. Load this at the start of every working session and whenever a request could be read either way: "let's look at", "dial in", "basic list", "what do you think" versus "build", "make", "write the doc", "put that in", "rip", "scrape", "let it rip", "go for it". Also governs the checkpoint moves: saying the plan back before spending, reporting spend, "note your place", and switching back to think mode when a build burst ends. The method skills (positioning-spiral, odf, mechanism, find-competitors, patterns-and-gaps, anatomy-of-ads, copy-instincts, bot-builder, handoff) assume this one is loaded; the exodus-* pipeline skills keep the exodus-strategist posture.
+---
+
+# Thinking vs Build
+
+## The goal
+
+The point of both modes is a tight feedback loop with the expert, the user. They have the instincts; the job is to put them to work with the least friction possible. Sometimes that means ripping through a build on their say-so. Far more often it means making it super simple for them to apply light steering and thinking: a short list they can cut in ten seconds, one decision at a time, the raw material within reach so they can read it themselves, and a checkpoint whenever the wheel should go back to them. Every rule below exists to serve that loop. If a move makes their next steer harder (a document where a list would do, a menu where a recommendation would do, a run that spends before they have said go), it is the wrong move even if the output is good.
+
+The loop looks like this: propose → they cut or redirect in a line → apply → propose the next axis. Each turn should cost them a few seconds of judgment, not minutes of reading. The compounding comes from how many of those turns happen, not from how big each one is.
+
+Two modes serve that loop. Getting the mode wrong is the most common failure in this folder, in both directions. The correction that created this skill, verbatim, from Luke's own sessions:
+
+> "Okay lets stay really small just give me basic stuff again you have a tendency to just build a bunch of shit when i dont need that... sometimes I want to THINK with you first and quickly to plan things... and then we'll build the full thing"
+
+And the confirmation, once it was fixed:
+
+> "okay this is great... i love this new you... with basic lists and answers and simple talking before building lets keep that and make sure we continue to do all that please"
+
+The opposite failure is real too. Once the user has said go, process talk is friction:
+
+> "btw you can also just find another way to scrape idc about process i just want the full transcript / video transcript / headline / body text"
+
+## The rule underneath both modes
+
+Ask what kind of work the message is about.
+
+- **Deciding** what we are going to do (segments, outcomes, mechanisms, focus order, which skill to build, what a doc should contain, whether an idea holds): **think mode.** Go narrow, check in every axis.
+- **Gathering** what is out there (rip these ads, scrape these reviews, pull competitor pages, transcribe, count mentions, analyse a corpus): **build mode.** Go wide, do not check in until done or until a checkpoint they asked for.
+
+Research inside a decision is a build burst. Decisions inside a build are still decisions: stop and ask the two or three that change the work, then continue.
+
+## Reading the cue
+
+**Think cues.** "Let's think", "dial in", "basic list", "simple", "just give me", "what do you think", "options", "should we", "does it make sense to", "stress test this", "are we missing anything", any question, any message that names one axis ("just the core outcomes"), "first confirm you understand".
+
+**Build cues.** "Build", "make", "write", "the doc", "the report", "put that in", "throw those in", "full thing", "rip", "scrape", "pull", "go", "let it rip", "let's go for it", "do whatever you need to do", "don't stop", "be comprehensive", "in batches so I can start working".
+
+**Ambiguous.** Default to think mode. Put the shortest useful answer down and end with the decision that would unlock the build. Ask only when the two readings lead to materially different work, and then ask one question, not a menu.
+
+**Mode carries forward** until a cue changes it. "Okay this is good" after a think message is not a build cue. "Yes" after a plan-back is.
+
+## Think mode
+
+This is where most of the loop lives. Optimise every message for how fast the user can steer it.
+
+- Short prose or a short list. No headers under about 500 words. No document, no artifact, no file.
+- One axis per message. Outcomes, then sub-outcomes, then demographics. Never the whole grid at once.
+- One or two words per item. If it needs a sentence it is not an item yet.
+- Propose, do not ask. Put a list down and let the user cut it. They decide every item, by name or by number, fast.
+- Give a recommendation, not a survey. If there are three options, say which and why in one line.
+- Be honest about thin evidence. "Backed by reviews" gets a count. Logic alone gets marked HYPOTHESIS. The user accepts "thin" when told plainly.
+- End with the one thing needed from the user, or with nothing. Never a closing offer to build something they did not ask for.
+- When the user says "stress test", show only what moved and why.
+- When the user says "are we missing anything", check the data for the biggest themes not on the list and name at most three.
+- When the user says "confirm you understand", say the plan back in a few lines and stop.
+
+## Build mode
+
+The loop does not stop in build mode; it gets longer. The user steers at the plan-back, at each batch, and at the end. Design the build so those three steers are easy.
+
+- **Say the plan back first**, in two or three lines, when the build spends money, touches a paid tool, or runs long. Wait for the go. After the go, outcome over method: do not narrate, do not ask again.
+- **Comprehensive.** "Best first, but get everything." Order by value, still finish.
+- **Batches.** Hand over the first usable slice fast and keep going. The user starts working on batch one while batch two runs.
+- **Write files early.** A fan-out writes each result to disk as it lands. A spend-limit cut or a dropped connection loses only what is in flight.
+- **Report spend** per batch so the user can stop it. They do not set budgets up front; they expect to be told.
+- **Log tool gaps as they are hit**, in one place, per the Tool Feedback Protocol.
+- **Three homes for anything agreed.** The folder (the archive), the system (Exodus, or the live bank or board), and a shareable place (a Drive subfolder or a published page). Plus a reusable skill when the method should travel.
+- **Shareable by default.** After publishing a page, say it is private until shared and where the Share menu is. Every bank or board will be handed to someone else.
+- **Plain language** for anything a collaborator will read. No jargon that needs explaining. Do not call anyone a junior.
+- **Keep the where-it-lives index** current from the first output, so the session scrape at the end is mechanical.
+- **No NDA leakage** in anything reusable: skills and examples use fictional brands.
+- When another session or person has edited a file in the folder, say so and re-read before building on it.
+
+## Switching
+
+- **Build burst ends → think mode.** Come back with what the new data changed, in a few lines, not the data itself. Then the next axis.
+- **Exit test passes → build cue is the user's**, not yours. Say it is coherent, offer the build in one line, wait.
+- **"Note your place"** (or "pause", or after a usage limit): what is done, what is missing, what is next, in that order, then stop. No automatic resume. Once the base is built the user takes the wheel.
+- **Interrupted mid-build**: report what landed on disk and what was lost in flight.
+
+## Reply shapes
+
+Think reply:
+
+```
+<one or two lines of read-back, if the ask was new>
+<the list, one axis, 1–2 words per item, with the one-line argument where the user asked for one>
+<the single decision needed, or nothing>
+```
+
+Plan-back before a build:
+
+```
+Plan: <what, from where, with which tool, in what batches>. Cost: <estimate or "none">. Outputs land in <path>. Go?
+```
+
+Note your place:
+
+```
+Done: <a> · <b>
+Missing: <c>
+Next: <d>, then <e>
+```
+
+## Two examples from the sessions
+
+**Wrong mode.** The user asked to "start to break down these different segments/mechanisms" and shared an ODF skill. The response was a full ODF map with quote banks, tagged ads, and a numbered review. That was a decision ask handled as a build. The fix was the correction above, and every axis afterwards went one message at a time.
+
+**Right mode.** "Okay lets go and scrape a bunch of those comments now prioritize the best ones in batches but let's be comprehensive." Plan said back (which actor, cost per review, three batches by value), go received, three batches run, spend reported after each, files written as each batch landed, plain-text dump offered so the user could read raw. No check-ins in between.
+
+## What this skill is not
+
+It does not decide what to build or how to think about a product; the other skills do that. It governs the method skills only: when an `exodus-*` pipeline runs, `exodus-strategist` leads (state the strategy call, menu only the run's knobs). It decides how much to put on the page, and when, so that the user's steering stays light and the loop stays tight.
+
+## Standards
+
+Before producing anything, read `STANDARDS.md` at the workspace root (and the section for this output type). Grade the draft against it before showing it; rewrite failures first. When the user reacts with a judgment, a banking phrase, or the same note twice, hand the reaction to `remember-that`. At the end of the session, `handoff` scrapes the chat and proposes entries.

package/assets/templates/STANDARDS.md

@@ -0,0 +1,49 @@
+# Standards
+
+Your taste, written where the system always reads it. Every skill in this folder reads this file before it produces anything and grades its draft against it before you see it. `exodus update` never touches this file.
+
+One entry per line. Dated. The raw thing you said or did sits under it in a quote, so the rule can be traced back to the moment. Entries are added by the `remember-that` skill (mid-session) and proposed by the `handoff` skill (end of session). Nothing is added without your yes.
+
+Rungs, from the Standards Ladder: **taste** (in your head) → **note** (said once) → **rule** (written here) → **tool** (enforced in code) → **skill** (runs itself). Saying "remember that" climbs a rung. Saying the same note twice climbs it for you. Saying "make sure this never happens again" asks for a tool.
+
+## How I give feedback
+
+The skills read this first and behave accordingly. Change it and they change.
+
+- Capture: inline when I say "remember that"; a proposal sweep at the end of every session; a review read every 10 sessions or when I ask.
+- The AI may propose entries from my edits and my picks. It never writes one without a yes.
+- Winning lines (a hook, a headline, a body I approved) push to the matching Exodus bank automatically. Style rules that would change a workflow or a primer are offered, not pushed.
+- Files I have hand-edited are read-only to the system.
+- Sections in this file split into their own files under `standards/` when they pass a page. The skill does it and tells me where things moved.
+
+## Hooks
+
+(Rules for how hooks are written and judged. Empty until you react to one.)
+
+## Copy
+
+(Voice, structure, what to cut, what to keep. Empty until you react to one.)
+
+## Statics
+
+(Image and template rules.)
+
+## Workflows
+
+(How runs should behave: checkpoints, batch sizes, what to ask before spending.)
+
+## Skills
+
+(Changes you have asked for in how the skills themselves work.)
+
+## Gnomes
+
+(AI tells for this market. Phrases the bots over-use that a real person here would never say. Appended as found.)
+
+## Tools
+
+(Standards enforced in code. One line each: what it guarantees, the script that does it.)
+
+## Log
+
+(Every banked reaction: date · the raw quote · the rung · where it landed. Newest first.)

package/dist/commands/init.d.ts

@@ -4,6 +4,7 @@ export interface InitResult {
     envCreated: boolean;
     skills: string[];
     docs: string[];
+    standardsCreated: boolean;
 }
 export declare function scaffoldInit(root: string): InitResult;
 export declare function syncBrands(root: string): Promise<{

package/dist/commands/init.js

@@ -1,6 +1,6 @@
 import fs from "node:fs";
 import path from "node:path";
-import { writeEnvScaffold, ensureGitignore, writeSkills, writeReferences, writeDocs, ensureBaseDirs, } from "../lib/scaffold.js";
+import { writeEnvScaffold, ensureGitignore, writeSkills, writeReferences, writeDocs, writeStandards, ensureBaseDirs, } from "../lib/scaffold.js";
 import { loadWorkspaceEnv } from "../lib/load-env.js";
 import { ensureBrandDir } from "../lib/layout.js";
 import { pkgRef } from "../lib/channel.js";
@@ -14,9 +14,10 @@ Usage:
   npx ${pkgRef()} init --root <dir>   Target a specific folder
 
 Run this in a fresh, empty folder. It creates the workspace layout, writes the
-Exodus + Genesis skills into .claude/skills/, scaffolds a comment-only .env, and
-prints the dashboard paste step. Safe to re-run: it never overwrites your .env
-or brand folders — re-running refreshes the skills and catches up new brands.
+Exodus + Genesis skills into .claude/skills/, scaffolds a comment-only .env,
+creates STANDARDS.md (your taste file) the first time, and prints the dashboard
+paste step. Safe to re-run: it never overwrites your .env, your STANDARDS.md or
+your brand folders — re-running refreshes the skills and catches up new brands.
 `.trim();
 export function scaffoldInit(root) {
     const existing = fs.existsSync(path.join(root, ".env"));
@@ -26,8 +27,9 @@ export function scaffoldInit(root) {
     const skills = writeSkills(root);
     writeReferences(root);
     const docs = writeDocs(root);
+    const { created: standardsCreated } = writeStandards(root);
     setScaffoldVersion(getVersion(), root);
-    return { existing, envCreated, skills, docs };
+    return { existing, envCreated, skills, docs, standardsCreated };
 }
 export async function syncBrands(root) {
     loadWorkspaceEnv(root);
@@ -56,6 +58,9 @@ export async function run(flags) {
     if (r.docs.length) {
         console.log(`  Installed workspace docs: ${r.docs.join(", ")}`);
     }
+    if (r.standardsCreated) {
+        console.log("  Created STANDARDS.md — your taste, read by every skill before it produces");
+    }
     const brands = await syncBrands(root);
     if ("synced" in brands && brands.synced.length) {
         console.log(`  Synced ${brands.synced.length} brand folder(s): ${brands.synced.join(", ")}`);

package/dist/commands/update.js

@@ -8,7 +8,7 @@ exodus update — refresh this workspace from the installed CLI (alias of init)
 
 Re-runs the init refresh: rewrites .claude/skills/, the workspace docs
 (CLAUDE.md, PIPELINES.md), and syncs brand folders from the package you
-invoked. Your .env, state/, and outputs are left untouched.
+invoked. Your .env, your STANDARDS.md, state/, and outputs are left untouched.
 
 Usage:
   exodus update

package/dist/commands/video.d.ts

@@ -8,6 +8,7 @@ export interface ClipWord {
 export interface ClipQc {
     verdict: "pass" | "fail";
     attempts: number;
+    neighbours?: number[];
 }
 export interface ClipFinding {
     check: string;
@@ -36,6 +37,8 @@ export type ArtifactSubset = {
     words?: ClipWord[];
     qc?: ClipQc;
     final?: boolean;
+    revoiced?: boolean;
+    speechTrimmed?: boolean;
 } | {
     type: "audio";
     sceneIndex?: number;
@@ -158,10 +161,13 @@ export interface ManifestScene {
     voice: string | null;
     keyframe: string | null;
     qc: ClipQc | null;
+    revoiced: boolean | null;
+    speechTrimmed: boolean | null;
     clipStatus: string;
     error: string | null;
     flagged: boolean;
     findings: ClipFinding[];
+    keyframeFindings: ClipFinding[];
 }
 export interface PullFailure {
     file: string;