@baselane/packs 0.1.5 → 0.1.6

package/packs/full-harness/rendered/.claude/skills/benchmark-methodology/SKILL.md

@@ -0,0 +1,185 @@
+---
+name: benchmark-methodology
+description: >-
+---
+
+# Benchmark Methodology
+
+Use this skill to turn a scoped competitor set into **comparable, defensible
+scores**. Each competitor is assessed on the same nine dimensions, with
+explicit 1–5 rubrics, then captured in a uniform profile card. Consistency is
+the point: scores are only useful if the same evidence would earn the same
+number for any competitor.
+
+## When to Activate
+
+- A scoped, tiered competitor set from competitive-platform-analysis is ready to score.
+- Need comparable, evidence-anchored scores across competitors — not gut-feel rankings.
+- Client's strategic tension (the paired axes defining their target white-space) has been established.
+- Preparing to produce profile cards for assembly in competitive-report-structure.
+
+## Client positioning brief (establish first)
+
+Before scoring, establish the client's positioning brief. It supplies:
+
+- **Strategic tension** — the two axes (e.g., memorability × hireability) whose
+  intersection marks the client's target white-space. Dimension 9 is always
+  the client's named tension; report both poles separately, never averaged.
+- **Differentiator** — what makes the client's moat. This informs which
+  dimensions matter most for the client's positioning argument.
+- **Brand balance** — the intended mix of distinct strategic emphases. Strategic
+  recommendations must not break this balance without flagging it.
+
+## Why these dimensions
+
+The client competes on a **specific tension held across two poles**, not on
+service breadth. The dimensions are weighted to reflect that moat. Two
+dimensions — the tension poles — are scored **separately and never averaged
+together**, because the client's strategic question is precisely whether a rival
+achieves both simultaneously.
+
+## The nine dimensions (with weights)
+
+Weights guide synthesis emphasis, not a single blended score (avoid a false
+composite — see Bias controls). Sum = 100%.
+
+1. **Positioning clarity & distinctiveness** (18%) — Is the studio's position
+   sharp, ownable, and instantly legible? Or generic?
+2. **Brand voice / verbal distinctiveness** (15%) — Does the copy have an
+   ownable register, or is it interchangeable agency-speak?
+3. **Visual identity & site craft** (15%) — Quality and ownership of the visual
+   system; site as proof-of-craft.
+4. **Service offer & packaging** (12%) — Productized and legible (named
+   sprints/audits) vs vague. Packaging maturity.
+5. **Evidence & credibility** (12%) — Named clients, quantified outcomes,
+   case-study depth. Proof beyond assertion.
+6. **Enterprise-readiness / commercial maturity** (10%) — Signals they can land
+   and hold SaaS/fintech/B2B/enterprise work (process, logos, scale, contracts).
+7. **Thought leadership / content presence** (8%) — Owned POV: writing, talks,
+   newsletters, frameworks. Depth over volume.
+8. **Pricing transparency & engagement model** (5%) — Is pricing/engagement
+   legible? Productized vs bespoke vs opaque.
+9. **[Client's strategic tension]** (5% as a flag; **score BOTH poles,
+   report separately**) — Read the tension name and axis descriptions from the
+   client's positioning brief. Plot both; the gap is the insight. The client's
+   target quadrant is the single most important finding: who else is already
+   there?
+
+## Scoring rubric (1–5, applies to dimensions 1–8)
+
+Anchor every score to observable evidence. Generic descriptors below; adapt the
+specifics per dimension but keep the level meaning constant.
+
+- **1 — Absent / generic.** No discernible position or craft; indistinguishable
+  from a template. Active liability.
+- **2 — Below par.** Some intent but inconsistent, derivative, or unconvincing.
+  Wouldn't survive a side-by-side.
+- **3 — Competent / table-stakes.** Solid, professional, unremarkable. Meets
+  expectation, ownable by nobody.
+- **4 — Strong / distinctive.** Clearly above peers; a real strength a buyer
+  would notice and cite.
+- **5 — Category-defining.** Best-in-class, ownable, hard to imitate. Sets the
+  bar others react to.
+
+### Tension axes (dimension 9) — score each 1–5
+
+Read the axis labels and their 1/3/5 anchors from the client's positioning
+brief. Example anchors for a memorability × credibility tension:
+
+- **Memorability** — 1: forgotten instantly · 3: recognizable in context ·
+  5: unforgettable, talked-about, distinctively owned.
+- **Credibility** — 1: feels risky/amateur · 3: safe, competent,
+  unexciting · 5: enterprise-trusted, obvious safe choice.
+
+Plot competitors on the tension 2×2. The client's target quadrant is named in
+the positioning brief. Who else occupies that quadrant is the single most
+important finding of the benchmark.
+
+## How to collect the data
+
+For each competitor, work the dimensions in this order (cheapest signal first):
+
+1. **Competitor's own site** — positioning, voice, offer packaging, pricing
+   posture, named clients, manifesto/POV. Screenshot the homepage + one case
+   study.
+2. **Case studies / work** — evidence depth, quantified outcomes, client names.
+   Distinguish *asserted* ("we delivered X") from *proven* (metrics, named,
+   verifiable).
+3. **Review directories** — corroborate clients, project size, engagement model
+   → credibility & enterprise-readiness (e.g. Clutch.co or the niche equivalent).
+4. **LinkedIn** — team size/model, founder narrative, content cadence →
+   thought leadership, model.
+5. **Portfolio / craft platforms** — craft register (use the showcase native to
+   the niche: design boards, showreels, published samples, etc.).
+6. **Content channels** — newsletter/talks/writing → thought-leadership depth.
+
+**What to record per dimension:** the score, one-line justification, and the
+source link/screenshot that earned it. No score without evidence.
+
+## Bias controls
+
+- **No single composite score.** Report dimension scores and the tension plot
+  separately. A weighted average hides the asymmetry that matters.
+- **Asserted vs proven.** Downgrade credibility/evidence scores for
+  self-reported claims with no corroboration. Site copy is marketing, not fact.
+- **Aesthetic affinity bias.** Reviewers may over-score studios whose aesthetic
+  they share and under-score rivals' commercial strength. Score craft and
+  credibility independently; a "boring" site may be winning bigger clients.
+- **Recency / flashiness bias.** Award-winning, showpiece work dazzles but may
+  lack commercial depth — verify with directories/clients before scoring
+  credibility.
+- **Survivorship.** The visible, well-marketed studios aren't the whole market;
+  note strong-but-quiet operators found via directories/reviews.
+- **Calibrate across the set, not in isolation.** Before finalizing, re-read
+  scores side-by-side — a "4" must mean the same thing for every competitor.
+  Adjust outliers.
+
+## Competitor profile card (output format)
+
+Produce one card per profiled competitor — the atomic unit the report assembles
+from:
+
+```
+## <Competitor name>
+- **Profile / Tier:** <positioning stance · specialization · size band> / <Direct | Adjacent | Aspirational>
+- **One-liner:** <how they position themselves, in their words>
+- **Model / size / geography:** <solo|micro|boutique> · <region> · <pricing/engagement model>
+- **Notable clients / evidence:** <named, with proven/asserted tag>
+
+### Dimension scores
+| Dimension | Score (1–5) | Justification (1 line) | Source |
+|---|---|---|---|
+| Positioning clarity & distinctiveness | | | |
+| Brand voice / verbal distinctiveness | | | |
+| Visual identity & site craft | | | |
+| Service offer & packaging | | | |
+| Evidence & credibility | | | |
+| Enterprise-readiness / commercial maturity | | | |
+| Thought leadership / content presence | | | |
+| Pricing transparency & engagement model | | | |
+
+### Tension plot
+- **[Axis 1 from positioning brief]:** <1–5> — <why>
+- **[Axis 2 from positioning brief]:** <1–5> — <why>
+- **Quadrant:** <high/high | high-1/low-2 | low-1/high-2 | low/low>
+
+### Read for [client]
+- **Strength to learn from:** <…>
+- **Weakness to exploit / white-space it exposes:** <…>
+- **Threat to [client]:** <…>
+```
+
+Hand the completed cards plus the tension plot to `competitive-report-structure`.
+
+## Anti-Patterns
+
+- **Averaging the tension axes.** The two poles of the client's strategic tension must be scored and reported separately. Averaging destroys the insight — the gap between poles is the finding.
+- **Scoring without evidence.** Every score requires a one-line justification and a source link. A score without evidence is an opinion, not a benchmark.
+- **Creating a single composite score.** Report dimension scores individually. A weighted average hides the asymmetric strengths that matter for positioning.
+- **Applying generic rubric anchors without adapting.** The 1–5 anchors must be calibrated to the specific dimension and competitor set. The generic descriptions are a starting point, not a fixed standard.
+- **Running before the competitor set is scoped.** Use competitive-platform-analysis first to produce a tiered, pruned set. Scoring an unscoped list wastes effort on irrelevant competitors.
+
+## Related Skills
+
+- `competitive-platform-analysis` — the prerequisite; produces the tiered competitor set this skill scores.
+- `competitive-report-structure` — the next step; assembles the scored profile cards into a client-deliverable report.

package/packs/full-harness/rendered/.claude/skills/benchmark-optimization-loop/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: benchmark-optimization-loop
+description: Use when the user asks to make something faster, try many variants, run recursive optimization, benchmark latency/throughput/cost, or choose the best implementation by repeated measured tests.
+---
+
+# Benchmark Optimization Loop
+
+Use this skill to convert "make it 20x faster" or "try 50 recursive
+optimizations" into a bounded measured loop that can actually improve a system.
+
+## Required Baseline
+
+Do not optimize until these exist:
+
+- the operation being optimized;
+- the correctness gate that must stay green;
+- the metric: wall time, p95 latency, rows/sec, cost/run, memory, error rate;
+- the current baseline;
+- the search budget: max variants, max time, max spend, max data impact.
+
+If the user asks for an unrealistic target, keep the ambition but make the loop
+bounded and measurable.
+
+## Loop
+
+1. Measure the baseline.
+2. Identify bottlenecks from evidence.
+3. Generate variants that test one hypothesis each.
+4. Run variants with the same input shape.
+5. Reject variants that fail correctness, safety, or reproducibility.
+6. Promote the fastest safe variant.
+7. Codify the winning path in a script, command, test, config, or doc.
+8. Rerun the baseline and winner to confirm the delta.
+
+## Variant Table
+
+Track variants like this:
+
+```text
+Variant | Hypothesis | Command | Time | Correct? | Notes
+baseline | current path | npm run job | 120s | yes | stable
+batch-500 | fewer round trips | npm run job -- --batch 500 | 42s | yes | winner
+parallel-8 | more workers | npm run job -- --workers 8 | 31s | no | rate limited
+```
+
+## Recursive Search
+
+For recursive or hyperparameter work:
+
+- persist every run to a ledger;
+- compare against the prior accepted winner, not only the previous run;
+- keep a holdout or replay check;
+- stop when improvement is within noise, correctness fails, cost exceeds the
+  budget, or the search starts changing more variables than it can explain.
+
+Use phrases like "best measured safe variant" instead of "global optimum" unless
+the search space was actually exhaustive.
+
+## Promotion Gate
+
+A variant cannot become the new default until:
+
+- correctness tests pass;
+- the performance delta is repeated or explained;
+- rollback is obvious;
+- the change is encoded in source control or a durable runbook;
+- the final summary includes exact commands and measurements.

package/packs/full-harness/rendered/.claude/skills/blender-motion-state-inspection/SKILL.md

@@ -0,0 +1,162 @@
+---
+name: blender-motion-state-inspection
+description: Use this skill when inspecting Blender characters, rigs, poses, animation retargeting, ground contact, facing direction, or model-vs-motion alignment where screenshots alone are not enough.
+---
+
+# Blender Motion State Inspection
+
+## When to Use
+
+- A Blender character looks twisted, mirrored, flattened, offset, or foot-sliding in an animation.
+- A user asks whether an imported avatar, armature, or retargeted motion matches an expected pose.
+- You need to compare rendered evidence with structured facts such as bones, bounding boxes, contacts, and facing vectors.
+- A workflow depends on deciding whether a model is a character, prop, proxy mesh, control rig, or broken import.
+
+## Core Principle
+
+Do not judge animated 3D assets only from screenshots. Screenshots are review evidence, but they hide axis conventions, bone names, object scale, local transforms, parented meshes, material slots, and frame-by-frame contact state.
+
+First extract structured Blender state, then use viewport screenshots or renders to confirm what the facts imply.
+
+## How It Works
+
+1. Establish the clean scene and asset baseline before judging motion.
+2. Extract structured facts from Blender using an exporter or Blender Python run inside Blender's own interpreter.
+3. Sample the frames most likely to expose contact, orientation, scale, and retargeting errors.
+4. Compare the measured facts against the user's expected pose, direction, ground plane, and render goal.
+5. Return a concise report that separates confirmed facts, likely causes, and required fixes.
+
+## Inspection Workflow
+
+1. Inventory the scene.
+   - List meshes, armatures, empties, cameras, lights, modifiers, parent relationships, and hidden objects.
+   - Separate character meshes from helper/proxy geometry before judging the avatar.
+   - Record object-space and world-space bounding boxes.
+
+2. Identify the skeleton.
+   - Capture armature names, pose bones, bone heads/tails, roll, parent chains, constraints, and rest-pose axes.
+   - Map semantic bones such as hips, spine, neck, head, shoulders, elbows, hands, thighs, knees, ankles, and feet.
+   - Flag missing left/right pairs and unusual naming schemes.
+
+3. Determine forward, up, and side axes.
+   - Use the pelvis, spine, shoulders, hips, head, and feet together; do not rely on a single mesh normal.
+   - Compare local armature axes with world axes and imported file conventions such as glTF Y-up vs Blender Z-up.
+   - Mark likely mirrored or backwards imports when face/head/feet direction conflicts with root motion.
+
+4. Sample animation frames.
+   - Inspect first, middle, contact, airborne, and extreme frames.
+   - Record root location, root heading, pelvis height, torso lean, limb directions, foot clearance, and mesh bounds.
+   - For long or fast motion, sample more densely around flips, landings, turns, collisions, and floor contacts.
+
+5. Check model integrity before retargeting blame.
+   - Confirm the clean baseline shape before applying animation.
+   - Preserve original mesh, materials, armature, and skinning unless the user explicitly asks for repair.
+   - Treat unexplained sphere-like blobs, giant proxy meshes, or crushed bodies as import/selection issues until proven otherwise.
+
+6. Diagnose contact and motion issues.
+   - Ground penetration: compare lowest foot or shoe vertices with floor height per frame.
+   - Foot sliding: compare foot world positions across planted frames.
+   - Leg crossover: compare left/right thigh, knee, ankle, and foot side ordering.
+   - Twist damage: compare bone swing direction separately from roll/twist around the limb axis.
+   - Scale drift: compare animated mesh bounds against the clean baseline bounds.
+
+7. Report facts before opinions.
+   - Include frame numbers, object names, bone names, world coordinates, and thresholds.
+   - Separate confirmed failures from visual suspicions.
+   - Attach screenshots only after the structured state explains what to look for.
+
+## Recommended Report Shape
+
+```markdown
+## Blender Motion Inspection
+
+### Scene Inventory
+- Character candidates:
+- Armatures:
+- Helper/proxy objects:
+- Cameras/lights:
+
+### Orientation
+- World up:
+- Character forward:
+- Root heading:
+- Mirrored/backwards risk:
+
+### Baseline Integrity
+- Clean mesh bounds:
+- Animated mesh bounds:
+- Materials/skin preserved:
+- Suspicious non-character meshes:
+
+### Frame Findings
+| Frame | Finding | Evidence |
+| --- | --- | --- |
+| 1 | Clean baseline pose | hips/spine/feet aligned |
+| 96 | Foot penetrates floor | left_foot min_z = -0.04 |
+
+### Verdict
+- Pass/fail:
+- Required fix:
+- Render readiness:
+```
+
+## Examples
+
+### Walk Cycle With Foot Sliding
+
+Scenario: a retargeted character appears to skate during a walk cycle, but the front camera angle makes the foot contact hard to judge.
+
+Apply the workflow:
+- Inventory the scene: character mesh `HeroBody`, armature `HeroRig`, ground plane `Floor`, no hidden proxy meshes.
+- Identify the skeleton: semantic feet are `foot.L` and `foot.R`; hips are `pelvis`; root bone is `root`.
+- Sample animation frames: inspect frames 1, 18, 24, 30, 42, and 48 around planted-foot moments.
+- Diagnose contact and motion issues: compare world-space foot locations during planted frames.
+
+Extracted facts:
+
+| Frame | Fact | Evidence |
+| --- | --- | --- |
+| 18 | Left foot is planted | `foot.L min_z = 0.004`, toe and heel both near floor |
+| 24 | Left foot slides while planted | `foot.L x = 0.21 -> 0.28` over six frames |
+| 30 | Pelvis keeps moving forward | `pelvis y = 1.14 -> 1.31` |
+
+Verdict: fail for render readiness. The motion needs foot-lock cleanup or retargeting constraint review; the body mesh does not need proportion changes.
+
+### Backwards Imported Character
+
+Scenario: a character looks correct in a still frame, but the animation moves opposite the expected travel direction.
+
+Apply the workflow:
+- Determine forward, up, and side axes: compare head, chest, feet, and root motion.
+- Sample animation frames: inspect frame 1 and the midpoint of the travel path.
+- Report facts before opinions: include the root heading and model-facing direction separately.
+
+Extracted facts:
+
+| Frame | Fact | Evidence |
+| --- | --- | --- |
+| 1 | Character face points toward world `-Y` | head/chest vector from `neck` to `head` resolves to `-Y` |
+| 72 | Root motion travels toward world `+Y` | `root y = 0.0 -> 2.8` |
+| 72 | Feet remain visually forward-facing opposite travel | toe bones point `-Y` while displacement is `+Y` |
+
+Verdict: likely backwards import or retargeting forward-axis mismatch. Fix the import/retarget axis mapping before editing animation curves.
+
+## Practical Thresholds
+
+- Assume Blender's default meter-scale units unless the scene unit scale says otherwise.
+- Treat ground penetration above 1-2 cm as visible unless the floor is soft or intentionally stylized.
+- Treat a sudden scale change above 5% as a likely rig, constraint, or transform inheritance problem.
+- Treat left/right ankle side-order flips during airborne inverted motion as leg crossover risk even if it recovers later.
+- Treat root heading jumps above 30 degrees per frame as suspicious unless the source motion includes a snap turn.
+
+## Anti-Patterns
+
+- Do not modify body proportions to force pose matching unless the task is explicitly mesh repair.
+- Do not bake away the clean baseline before recording it.
+- Do not use one rendered camera angle as proof that a pose is correct.
+- Do not delete helper objects until you have recorded why they are not part of the character.
+- Do not assume an avatar faces +Y, -Y, +X, or -X without checking head, feet, torso, and root motion together.
+
+## Tooling Notes
+
+If a Blender state exporter is available, prefer JSON that includes meshes, armatures, pose bones, materials, contacts, bounding boxes, and sampled animation frames. If no exporter exists, run a small Blender Python script through Blender itself, for example `blender --background scene.blend --python collect_motion_state.py`, because `bpy` is not available in a normal system Python interpreter.

package/packs/full-harness/rendered/.claude/skills/blueprint/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: blueprint
+description: >-
+---
+
+# Blueprint — Construction Plan Generator
+
+Turn a one-line objective into a step-by-step construction plan that any coding agent can execute cold.
+
+## When to Use
+
+- Breaking a large feature into multiple PRs with clear dependency order
+- Planning a refactor or migration that spans multiple sessions
+- Coordinating parallel workstreams across sub-agents
+- Any task where context loss between sessions would cause rework
+
+**Do not use** for tasks completable in a single PR, fewer than 3 tool calls, or when the user says "just do it."
+
+## How It Works
+
+Blueprint runs a 5-phase pipeline:
+
+1. **Research** — Pre-flight checks (git, gh auth, remote, default branch), then reads project structure, existing plans, and memory files to gather context.
+2. **Design** — Breaks the objective into one-PR-sized steps (3–12 typical). Assigns dependency edges, parallel/serial ordering, model tier (strongest vs default), and rollback strategy per step.
+3. **Draft** — Writes a self-contained Markdown plan file to `plans/`. Every step includes a context brief, task list, verification commands, and exit criteria — so a fresh agent can execute any step without reading prior steps.
+4. **Review** — Delegates adversarial review to a strongest-model sub-agent (e.g., Opus) against a checklist and anti-pattern catalog. Fixes all critical findings before finalizing.
+5. **Register** — Saves the plan, updates memory index, and presents the step count and parallelism summary to the user.
+
+Blueprint detects git/gh availability automatically. With git + GitHub CLI, it generates full branch/PR/CI workflow plans. Without them, it switches to direct mode (edit-in-place, no branches).
+
+## Examples
+
+### Basic usage
+
+```
+/blueprint myapp "migrate database to PostgreSQL"
+```
+
+Produces `plans/myapp-migrate-database-to-postgresql.md` with steps like:
+- Step 1: Add PostgreSQL driver and connection config
+- Step 2: Create migration scripts for each table
+- Step 3: Update repository layer to use new driver
+- Step 4: Add integration tests against PostgreSQL
+- Step 5: Remove old database code and config
+
+### Multi-agent project
+
+```
+/blueprint chatbot "extract LLM providers into a plugin system"
+```
+
+Produces a plan with parallel steps where possible (e.g., "implement Anthropic plugin" and "implement OpenAI plugin" run in parallel after the plugin interface step is done), model tier assignments (strongest for the interface design step, default for implementation), and invariants verified after every step (e.g., "all existing tests pass", "no provider imports in core").
+
+## Key Features
+
+- **Cold-start execution** — Every step includes a self-contained context brief. No prior context needed.
+- **Adversarial review gate** — Every plan is reviewed by a strongest-model sub-agent against a checklist covering completeness, dependency correctness, and anti-pattern detection.
+- **Branch/PR/CI workflow** — Built into every step. Degrades gracefully to direct mode when git/gh is absent.
+- **Parallel step detection** — Dependency graph identifies steps with no shared files or output dependencies.
+- **Plan mutation protocol** — Steps can be split, inserted, skipped, reordered, or abandoned with formal protocols and audit trail.
+- **Zero runtime risk** — Pure Markdown skill. The entire repository contains only `.md` files — no hooks, no shell scripts, no executable code, no `package.json`, no build step. Nothing runs on install or invocation beyond Claude Code's native Markdown skill loader.
+
+## Installation
+
+This skill ships with Everything Claude Code. No separate installation is needed when ECC is installed.
+
+### Full ECC install
+
+If you are working from the ECC repository checkout, verify the skill is present with:
+
+```bash
+test -f skills/blueprint/SKILL.md
+```
+
+To update later, review the ECC diff before updating:
+
+```bash
+cd /path/to/everything-claude-code
+git fetch origin main
+git log --oneline HEAD..origin/main       # review new commits before updating
+git checkout <reviewed-full-sha>          # pin to a specific reviewed commit
+```
+
+### Vendored standalone install
+
+If you are vendoring only this skill outside the full ECC install, copy the reviewed file from the ECC repository into `~/.claude/skills/blueprint/SKILL.md`. Vendored copies do not have a git remote, so update them by re-copying the file from a reviewed ECC commit rather than running `git pull`.
+
+## Requirements
+
+- Claude Code (for `/blueprint` slash command)
+- Git + GitHub CLI (optional — enables full branch/PR/CI workflow; Blueprint detects absence and auto-switches to direct mode)
+
+## Source
+
+Inspired by antbotlab/blueprint — upstream project and reference design.

package/packs/full-harness/rendered/.claude/skills/brand-discovery/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: brand-discovery
+description: >-
+---
+
+# Brand Discovery
+
+Use this skill to conduct a structured, adaptive brand identity interview.
+The goal is a complete `90_SYNTHESIS.md` — a master brandbook the
+organization can use to brief designers, writers, and external
+collaborators.
+
+The interview runs across multiple sessions. Capture answers to disk as you
+go so that no elicited knowledge is lost when a conversation ends, and so a
+later session can resume from where the last one stopped.
+
+## When to Activate
+
+- A brand is being created, repositioned, or needs a written identity reference to brief collaborators.
+- Multiple sessions are expected — the conversation will span days or weeks.
+- Multiple founders or stakeholders need individual interviews before a reconciliation pass.
+- The user wants a structured, repeatable method rather than an ad-hoc chat.
+- Existing brand documentation is scattered, implicit, or founder-dependent and needs to be made explicit.
+
+## Session start protocol
+
+On every activation, perform these steps **before** asking any interview
+question:
+
+1. **Check for prior progress.** Look for an existing set of module files
+   and a `state.json` checkpoint in the project's brand-identity directory.
+   If none exists, this is a fresh start — confirm the brand name,
+   participants, and where to save the brand-identity files, then begin at
+   the first module.
+2. **Read the current module file** if one is in progress, and scan its Raw
+   section for previously captured answers.
+3. **Report to the user** in two or three sentences: which module we are
+   in, its status, and what remains. Then ask: "Continue here, or switch
+   module?"
+
+## Interview discipline
+
+Apply these rules throughout every module:
+
+1. **One question at a time.** Never present a list of questions.
+2. **After each answer:** short paraphrase → one deepening probe OR close
+   the thread if the topic is saturated. Never move on silently.
+3. **Laddering:** for every "what" answer, follow with "Why does that
+   matter to you?" until a core value surfaces (typically two to four
+   iterations).
+4. **5 Whys:** for beliefs or positioning claims — push until the root
+   reason, not the surface declaration, is on the table.
+5. **Detect thin answers:** if generic, jargon-heavy, or vague, ask for
+   one concrete example, a client story, or a number.
+6. **Projective techniques** (use once per module to break a plateau):
+   - "If the brand were a person, how would they walk into a room?"
+   - Brand obituary: "If the organization closed in five years, what would
+     customers miss? What would you regret not having said?"
+   - Competitive contrast: "Name one peer you admire but would never want
+     to become. What specifically makes them the wrong model?"
+7. **Saturation signal:** when two consecutive probes produce no new
+   information, summarise and close the module.
+8. **End of module:** write a structured module file with two sections:
+   - `## Raw` — verbatim quotes and examples.
+   - `## Synthesis` — your interpretation, three candidate formulations,
+     open questions, contradictions between participants.
+   Then update the `state.json` checkpoint (see State protocol below).
+
+## Module sequence
+
+| File | Label | Frameworks used |
+|------|-------|-----------------|
+| `10_purpose-why.md` | Purpose / Why | Sinek Golden Circle, Lencioni |
+| `20_positioning.md` | Positioning | Dunford "Obviously Awesome", Moore template |
+| `30_audience-niche.md` | Audience & Niche | Baker "Business of Expertise", ICP |
+| `40_personality-archetype.md` | Personality & Archetype | Mark & Pearson 12 archetypes, J. Aaker 5 dims |
+| `50_voice-tone.md` | Voice & Tone | Brand voice guidelines |
+| `60_narrative-story.md` | Narrative / Story | Neumeier trueline, brand story arc |
+| `70_founder-tension.md` | Founder Brands vs Studio Brand | Enns "Win Without Pitching" |
+| `90_SYNTHESIS.md` | Master Brandbook | Kapferer prism, Aaker brand system |
+
+Complete modules in order. Honour a user request to jump modules and note
+the skip in `state.json`.
+
+## State write protocol
+
+After each module reaches saturation or done status, write two files:
+
+**Module file** at `modules/{moduleFile}` — full Raw and Synthesis content.
+
+**`state.json`** — a lightweight checkpoint so a later session can resume.
+Update `completedModules`, `inProgressModule`, `nextModule`, `lastUpdated`.
+Schema:
+
+```json
+{
+  "session": "{brand_name}-brand-{YYYY-MM}",
+  "outputPath": "{path_to_brand_identity_directory}",
+  "completedModules": [],
+  "inProgressModule": "10_purpose-why.md",
+  "nextModule": "20_positioning.md",
+  "participants": ["founder-A"],
+  "lastUpdated": "{ISO-8601}"
+}
+```
+
+After writing, confirm: "Module X saved. State updated. Next: Y."
+
+**Terminal module (90_SYNTHESIS.md):** when writing the final synthesis,
+set `inProgressModule` to `"90_SYNTHESIS.md"` and `nextModule` to `null`
+in `state.json`. After writing, set `completedModules` to include
+`"90_SYNTHESIS.md"`, then set `inProgressModule` to `null` — leaving it
+populated would cause a future resumption to treat the completed brandbook
+as still in progress. Confirm: "Brandbook complete. All modules saved."
+
+## Multi-founder mode
+
+When more than one founder participates, write each founder's answers to
+`founders/{participant}.md` instead of the main module files. Validate the
+`participant` name before writing: accept only alphanumeric characters and
+hyphens (e.g. `founder-a`, `anna`); reject names containing path separators
+(`/`, `\`, `..`) or special characters. Validate `moduleFile` against the
+enumerated module sequence (10 through 90 only). Validate `outputPath` to
+ensure it is an absolute path within the project directory — reject relative
+paths and paths that escape via `..` segments. After all founders complete a
+module, run a reconciliation pass: summarise convergences and divergences in
+the module file, flag "productive tensions" for the group alignment workshop.
+
+## Anti-Patterns
+
+- **Starting without reading state first.** Every session must open by checking for existing module files and `state.json`. Skipping this loses all continuity from prior sessions.
+- **Asking multiple questions at once.** One question at a time is not optional — lists produce checklist answers, not real insight.
+- **Moving to Synthesis before saturation.** If the last two probes produced no new information, the module is done. If they did — it isn't.
+- **Skipping multi-founder reconciliation.** When multiple stakeholders are involved, individual interviews must complete before reconciliation. Discussing the brand collectively first introduces anchoring bias.
+- **Treating this as a one-shot session.** This skill is designed for multiple sessions. Rushing to `90_SYNTHESIS.md` in one conversation produces shallow output.
+
+## Related Skills
+
+- `competitive-platform-analysis` — after brand-discovery establishes the positioning brief, use this to scope and categorise the competitor set.
+- `brand-voice` (ECC) — if the brand-discovery voice-and-tone module needs a separate, source-derived writing-style profile.