codeply-cli 0.5.1 → 0.5.2

package/skills/blueprint/SKILL.md

@@ -1,106 +1,106 @@
----
-name: blueprint
-description: >-
-  Turn a one-line objective into a step-by-step construction plan for
-  multi-session, multi-agent engineering projects. Each step has a
-  self-contained context brief so a fresh agent can execute it cold.
-  Includes adversarial review gate, dependency graph, parallel step
-  detection, anti-pattern catalog, and plan mutation protocol.
-  TRIGGER when: user requests a plan, blueprint, or roadmap for a
-  complex multi-PR task, or describes work that needs multiple sessions.
-  DO NOT TRIGGER when: task is completable in a single PR or fewer
-  than 3 tool calls, or user says "just do it".
-metadata:
-  origin: community
----
-
-# 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.
+---
+name: blueprint
+description: >-
+  Turn a one-line objective into a step-by-step construction plan for
+  multi-session, multi-agent engineering projects. Each step has a
+  self-contained context brief so a fresh agent can execute it cold.
+  Includes adversarial review gate, dependency graph, parallel step
+  detection, anti-pattern catalog, and plan mutation protocol.
+  TRIGGER when: user requests a plan, blueprint, or roadmap for a
+  complex multi-PR task, or describes work that needs multiple sessions.
+  DO NOT TRIGGER when: task is completable in a single PR or fewer
+  than 3 tool calls, or user says "just do it".
+metadata:
+  origin: community
+---
+
+# 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/skills/brand-discovery/SKILL.md

@@ -1,145 +1,145 @@
----
-name: brand-discovery
-description: >-
-  Use when a brand needs to discover or articulate its identity through
-  structured multi-session interviews. Covers purpose, positioning, audience,
-  personality, voice, narrative, and founder-brand tension across 8 modules
-  using laddering, 5 Whys, and projective techniques. Produces a resumable
-  session with disk-persisted state and a master brandbook (90_SYNTHESIS.md).
----
-
-# 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.
+---
+name: brand-discovery
+description: >-
+  Use when a brand needs to discover or articulate its identity through
+  structured multi-session interviews. Covers purpose, positioning, audience,
+  personality, voice, narrative, and founder-brand tension across 8 modules
+  using laddering, 5 Whys, and projective techniques. Produces a resumable
+  session with disk-persisted state and a master brandbook (90_SYNTHESIS.md).
+---
+
+# 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.

package/skills/brand-discovery/references/10_purpose-why.md

@@ -1,40 +1,40 @@
-# Module 10 — Purpose / Why
-
-> **Frameworks:** Sinek Golden Circle · Lencioni organisational purpose
->
-> **Goal:** Surface the brand's core belief — the Why that exists independently
-> of what the organisation sells or how it delivers. Captures the founding
-> conviction, not the elevator pitch.
-
----
-
-## Raw
-
-<!-- Verbatim quotes, stories, and examples captured during the interview.
-     Record exact language — paraphrase belongs in Synthesis, not here.
-     Include speaker attribution if multi-founder session. -->
-
-### Core belief (why does this exist?)
-
-### The behavioural How (values in action, not poster slogans)
-
-### What the brand refuses to be or do
-
-### Founder quotes strong enough to become internal anchors
-
----
-
-## Synthesis
-
-<!-- Your interpretation of the raw material.
-     Write three sections: formulations, open questions, contradictions. -->
-
-### Candidate Why formulations (offer 2–3 versions, vary register and specificity)
-
-1.
-2.
-3. ### Open questions / threads to pursue in later modules
-
-### Contradictions or tensions between participants (multi-founder only)
-
-### How does this Why constrain or enable positioning? (bridge to Module 20)
+# Module 10 — Purpose / Why
+
+> **Frameworks:** Sinek Golden Circle · Lencioni organisational purpose
+>
+> **Goal:** Surface the brand's core belief — the Why that exists independently
+> of what the organisation sells or how it delivers. Captures the founding
+> conviction, not the elevator pitch.
+
+---
+
+## Raw
+
+<!-- Verbatim quotes, stories, and examples captured during the interview.
+     Record exact language — paraphrase belongs in Synthesis, not here.
+     Include speaker attribution if multi-founder session. -->
+
+### Core belief (why does this exist?)
+
+### The behavioural How (values in action, not poster slogans)
+
+### What the brand refuses to be or do
+
+### Founder quotes strong enough to become internal anchors
+
+---
+
+## Synthesis
+
+<!-- Your interpretation of the raw material.
+     Write three sections: formulations, open questions, contradictions. -->
+
+### Candidate Why formulations (offer 2–3 versions, vary register and specificity)
+
+1.
+2.
+3. ### Open questions / threads to pursue in later modules
+
+### Contradictions or tensions between participants (multi-founder only)
+
+### How does this Why constrain or enable positioning? (bridge to Module 20)