[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71DV1FSSRT8WF2KWB85Q2H7":3,"skill-same:01M71DV1FSSRT8WF2KWB85Q2H7":78},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M71DV1FSSRT8WF2KWB85Q2H7","brainstorm",null,"Compare approaches to best-in-class prior art, merge existing work, verify cruft removal, and recommend the most durable design before PRD work.","indigoai-us\u002Fhq-core","indigoai-us","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F122242446?v=4","01M71DTQ5NGD10GT1Z7E6XKWC5","HQ","01M71DTQ6BKSYYBNC9RAKT3YDK",94,"MIT","https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fbrainstorm\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"merge","register","frontmatter","live","git","recommend","edit","write","read","scripts","work","websearch","Bash","design","Art","project","mesh","bind","ls","2026-11-10 10:12:30",false,"---\nname: brainstorm\ndescription: Compare approaches to best-in-class prior art, merge existing work, verify cruft removal, and recommend the most durable design before PRD work.\nallowed-tools: Read, Write, Edit, Grep, Glob, Bash(git:*), Bash(qmd:*), Bash(ls:*), Bash(date:*), Task, Bash(bash core\u002Fscripts\u002Fwork-mesh-live-bind-trusted.sh:*), Bash(bash core\u002Fscripts\u002Fwork-mesh-project-registration-offer.sh:*), Bash(bash core\u002Fscripts\u002Fregister-project.sh:*), Bash, AskUserQuestion, WebSearch, Bash(bash core\u002Fscripts\u002Fread-policy-frontmatter.sh:*), Bash(bash core\u002Fscripts\u002Fboard-project-id.sh:*)\n---\n\n# Brainstorm - Structured Exploration\n\nThink through a problem before committing to a PRD. Research HQ context, compare approaches, surface unknowns.\n\n**Input:** The user's argument — typically `[company] \u003Cidea description or board idea ID>`.\n\n**Pipeline:** idea capture --> **brainstorm** --> PRD --> run-project\n\n## Guiding Principles\n\nThese shape every step below. When two steps pull in different directions, these win.\n\n1. **Best long-term solution wins, not least effort.** Coding agents make code nearly free to write, so code volume and build effort are not costs to minimise. Pick the solution that is the most durable, flexible, resilient, scalable, cost-efficient to run (infrastructure spend), mature, and modern. The real costs are runtime spend, operational burden, fragility, and lock-in. Elegance still matters: prefer one well-designed system that merges or replaces several existing ones, because fewer systems are more resilient and cheaper to run. Judge approaches by what exists and runs after the change, not by how much code it takes.\n2. **Find what already exists before proposing anything new.** Fast AI work produces duplicates: two skills, workers, scripts, or repos that do the same job. Step 2 sweeps for them. Every brainstorm states what it reuses, what it merges, and what it retires.\n3. **Remove cruft as part of the solution.** Out-of-date or superseded material found during the sweep goes into the recommendation as a verified removal plan. The brainstorm verifies each removal (evidence plus user confirmation); the PRD carries it out. The brainstorm itself deletes nothing.\n4. **Deeper, not bigger** (adapted from [be-ambitious](https:\u002F\u002Fgithub.com\u002FDannyMac180\u002Fskills\u002Fblob\u002Fmain\u002Fbe-ambitious\u002FSKILL.md)). Keep the user's goal fixed, and raise the standard for that outcome: what an expert in the field would do that was not asked for, the rawest primary sources, named methods and tools, and an external check with a stated pass condition. Drop side quests and extra deliverables that do not serve the goal. The solution design itself is unbounded (Principle 7).\n5. **Assume agent velocity.** A `\u002Frun-project` loop typically finishes in 1 to 3 hours what a human team once planned in months. Never shrink scope, defer the clean solution, or pick a hack because the full version \"sounds long\". Effort fields still use scope\u002Frisk sizing and session counts (policy `ai-velocity-time-sense`), never calendar estimates.\n6. **Fresh, authoritative research.** Web research prefers primary sources (official docs, changelogs, release notes, maintainer repos, standards) published in the last 60 days. Training-data knowledge of tools, models, APIs, and pricing is treated as a hypothesis until a fresh source confirms it.\n7. **Study the best, then go past them.** Research how the most advanced companies solve this problem for quality, UX, and speed: their engineering blogs, published architectures, open-source code, and shipped products. Use that as the reference bar, not the ceiling. Then design from first principles with no bounds on what is possible, and aim for a solution better than anything that exists. At least one approach is this clean-sheet design.\n\n\n## Work Mesh Live — trusted bind (do this first)\n\nAs soon as Step 0 resolves `{co}`, and before any other tool call that touches project work, bind the session per\n`.claude\u002Fskills\u002F_shared\u002Fwork-mesh-live-bind.md` (US-011):\n\n```bash\nbash core\u002Fscripts\u002Fwork-mesh-live-bind-trusted.sh \\\n  --company \"{co}\" --project \"{project}\" --task \"{task}\"\n```\n\nOmit `--task` when unknown. This writes `workspace\u002Fsessions\u002F\u003Csid>\u002Fmeta.yaml`\nand reconciles with `observation.trustedContext` (no `--trusted` CLI flag).\n\n## Step 0: Parse Input & Company Anchor\n\nCheck if the **first word** of the user's input matches a company slug in `companies\u002Fmanifest.yaml`.\n\n**How to check:** Read `companies\u002Fmanifest.yaml`. Extract top-level keys (company slugs). If the first word exactly matches one:\n\n1. **Set `{co}`** = matched slug. Strip from input — remaining text is the description\n2. **Announce:** \"Anchored on **{co}**\"\n3. **Bind the session** — run `bash core\u002Fscripts\u002Fwork-mesh-live-bind-trusted.sh --company \"{co}\"` now, before any read under `companies\u002F{co}\u002F`. The scope guard blocks company paths until the session is bound to `{co}`.\n4. **Load policies (frontmatter-only)** — Collect the eligible files for the resolved company, except `example-policy.md`, preserve their order, and split the stable file order into consecutive chunks of at most 40 files. For each chunk, run `bash core\u002Fscripts\u002Fread-policy-frontmatter.sh {file1} {file2} ...` once with each path as a separate argument. Keep each call under 30 KB of output. The first output block belongs to the chunk’s first file argument; each later block belongs to the path named by its preceding `# --- policy-file: \u003Cpath> ---` separator. Note `enforcement: hard` titles. For hard-enforcement policies only, additionally Read the `## Rule` section with a targeted range\n5. **Scope qmd searches** — If company has `qmd_collections` in manifest, use `-c {collection}`\n\n**If no match** -- full input is the description text. Company resolved later.\n\n**Board ID detection:** After company check, see if remaining args match a board.json project ID pattern (`{prefix}-proj-{NNN}`). If so, this brainstorm is expanding an existing idea — proceed to Step 1 with that ID.\n\n## Step 0.5: Mode Selection\n\nInfer the brainstorm mode from context — no question needed:\n\n- **STARTUP** — early-stage idea, no existing solution, exploring whether worth building. Default when: no existing board entry with `prd_path`, no prior art in HQ, greenfield domain\n- **BUILDER** — existing product\u002Fsystem, designing a feature or extension. Default when: expanding existing project, board entry has `prd_path`, target repo already exists\n\nAnnounce mode: `Mode: **STARTUP**` or `Mode: **BUILDER**`\n\nMode affects Steps 2-4 (premise challenge depth, question framing, research scope).\n\n## Step 1: Resolve Company + Board Idea\n\n**If board ID matched in Step 0:**\n1. If `{co}` already set: read `companies\u002F{co}\u002Fboard.json`, find entry by ID\n2. If `{co}` not set: scan all `companies\u002F*\u002Fboard.json` for the ID (use manifest `board_path` list). Once found, set `{co}` and bind the session as in Step 0 before reading further\n3. Extract the entry's `title` and `description` as starting context\n4. Set `source_idea_id` = matched ID\n\n**If no board ID and no company:** infer from cwd (`companies\u002F{slug}\u002F` --> use that slug, `repos\u002F{pub|priv}\u002F{name}` --> manifest lookup). If still ambiguous, ask the user directly in Step 3.\n\n**If input is empty:** go straight to Step 3 (full interview).\n\n## Step 1.5: Board Entry + Work Mesh Registration (at start, not at the end)\n\nThe project exists on the Board and in Work Mesh from the moment the\nbrainstorm starts, so teammates and the HQ app see it while the work is still\nin progress. Do this before any research or interview question. Skip only\nwhen the company is unknown (empty input): run it as soon as Step 3 resolves\n`{co}` and a working title.\n\nRead `companies\u002F{co}\u002Fboard.json`.\n\n**If started from existing board idea** (`source_idea_id` set): find that\nentry; set `status` to `\"exploring\"` if it is still `\"idea\"`; update\n`updated_at`. Reuse its `id` as `{board-project-id}`.\n\n**If fresh brainstorm**: get the next ID from\n`bash core\u002Fscripts\u002Fboard-project-id.sh next {co}` (the highest existing\n`{prefix}-proj-{NNN}` number + 1, zero-padded to 3 digits) and append the entry\nbelow. After writing, run `bash core\u002Fscripts\u002Fboard-project-id.sh check {co}`;\nif it exits non-zero, fix the entry you wrote before continuing:\n  ```json\n  {\n    \"id\": \"{prefix}-proj-{NNN}\",\n    \"title\": \"{concise working title}\",\n    \"description\": \"{user's description}\",\n    \"status\": \"exploring\",\n    \"scope\": \"company\",\n    \"app\": null,\n    \"initiative_id\": null,\n    \"objective_id\": null,\n    \"prd_path\": null,\n    \"brainstorm_path\": null,\n    \"created_at\": \"{ISO8601}\",\n    \"updated_at\": \"{ISO8601}\"\n  }\n  ```\n\nWrite `board.json`, re-read it, and confirm the entry exists.\n\nThen register the entry in Work Mesh. This is always-on for cloud-backed\ncompanies; there is no flag and no prompt.\n\n```bash\nbash core\u002Fscripts\u002Fwork-mesh-project-registration-offer.sh --check {co} {board-project-id}\n```\n\n- `register` → run the registration and verify its one output line:\n  ```bash\n  bash core\u002Fscripts\u002Fregister-project.sh --board {co} {board-project-id}\n  ```\n  The verify line is `registered {co}\u002F{board-project-id} thread=\u003Cid> channel=\u003Cid>`.\n  If the script exits non-zero or prints anything else, say \"registration\n  incomplete\" once, keep going with the brainstorm, and retry the same command\n  in Step 6. Do not create a replacement project.\n- `registered` → nothing to do.\n- `local` → the company is not cloud-backed; nothing to do.\n- `deferred` → the user declined registration for this entry earlier; do not\n  register it. Register only if the user asks for it in this session.\n- `missing` → the Board write above failed; fix it and re-run the check.\n\n## Step 2: HQ Research (before any questions)\n\nDo not ask questions yet. Build context from HQ first.\n\n**Hybrid search (BM25 + vector + re-ranking):**\n- If anchored + company has `qmd_collections`: `qmd query \"\u003Cdescription keywords>\" -c {collection} --json -n 10`\n- If not anchored: `qmd query \"\u003Cdescription keywords>\" --json -n 10`\n\n**Existing projects:**\n- If anchored: search `companies\u002F{co}\u002Fprojects\u002F` directly or `qmd search \"prd.json\" -c {co} --json -n 10`\n- Read top 2-3 match metadata (name, description, status) to check for overlap\n\n**Workers:**\n- Read `core\u002Fworkers\u002Fregistry.yaml` — identify workers with skills matching the description\n\n**Policies (anchored only):**\n- Already loaded in Step 0. Note any constraints that affect approach selection\n\n**Target repo (if inferable):**\n- Note existence, don't deep-read. If repo has qmd collection, run scoped search\n\n### Overlap & Cruft Sweep (always run)\n\nSearch for anything that already does part of the job, inside the company scope plus HQ core. Cover every surface, using 3 to 5 keyword variants of the idea (synonyms, the verb, the output it produces):\n\n| Surface | Where to look |\n|---|---|\n| Code and repos | the company's `repos:` list in `companies\u002Fmanifest.yaml`; `grep -rl` \u002F `qmd` inside those repos for the key nouns and verbs |\n| Infrastructure | manifest `deploy:` \u002F `vercel_projects:` \u002F `sources:`, `hq integrations list --usable`, existing deploy targets and services |\n| Workers | `core\u002Fworkers\u002Fregistry.yaml` and `companies\u002F{co}\u002Fworkers\u002F` |\n| Skills and commands | `.claude\u002Fskills\u002F`, `companies\u002F{co}\u002Fskills\u002F`, `personal\u002Fskills\u002F` (HQ work only) |\n| Projects and ideas | `companies\u002F{co}\u002Fprojects\u002F*\u002F` (brainstorm.md, prd.json status), `board.json` entries in any status, including in-flight and parked |\n| Knowledge and policies | qmd hits from above, `companies\u002F{co}\u002Fpolicies\u002F`, `core\u002Fpolicies\u002F` |\n\nWhen the surface is broad, delegate the sweep to an `Explore` subagent with the keyword list and the table above, and have it return paths plus one-line verdicts. `Explore` is read-only: it cannot create files. When a sweep must write its own research note (for example `research\u002F*.md`), dispatch it as a `general-purpose` agent instead, so the parent does not re-emit the findings by hand.\n\nGive every hit one verdict:\n\n- **Reuse** — does the job as is; the solution calls it\n- **Extend** — does most of the job; the solution builds on it\n- **Merge** — overlaps another hit or the new idea; the solution combines them into one\n- **Replace** — the new solution supersedes it; it gets retired\n- **Unrelated** — keyword match only; drop it\n\n**Cruft verification.** A hit is a removal candidate when it is superseded, duplicated, or out of date. Before listing it, collect evidence for each candidate:\n\n1. Last change: `git -C {repo} log -1 --format=%cs -- {path}` (or file mtime outside git)\n2. Live references: grep for its name or path across skills, hooks, workers, scripts, and repos; zero callers is strong evidence\n3. Status: board\u002FPRD status, deprecated markers, a newer item that does the same job\n4. Blast radius: what breaks if it goes (callers, docs, scheduled jobs, deployed services)\n\nOnly candidates with evidence go forward. Each one is confirmed with the user in Step 3 (`Q-retire`) and, once confirmed, becomes part of the recommendation's removal plan. The brainstorm never deletes anything itself (**No execution** rule).\n\nWrite the full sweep to `research\u002Fhq-landscape.md` (Step 4, Layer 1).\n\nPresent compact summary:\n```\nResearch complete:\n- Related projects: {list or \"none found\"}\n- Relevant workers: {list}\n- Existing code\u002Fskills\u002Finfra: {hits with verdict: reuse \u002F extend \u002F merge \u002F replace}\n- Removal candidates: {count, with one-line evidence each, or \"none\"}\n- Policies: {count loaded}\n- Prior art: {relevant knowledge hits or \"none\"}\n```\n\n### Premise Challenge (always run, both modes)\n\nAfter research, before asking the user anything, challenge the premise:\n\n1. **Is this the right problem?** What assumption must be true for this to matter?\n2. **What happens if we do nothing?** Is inaction a viable option?\n3. **What already exists to build on?** Check the sweep first: a Reuse or Extend hit is the foundation, and a mature external platform may beat a custom build on durability and running cost. Do not pick a smaller, weaker solution because it is quicker to build.\n\nState a position. Don't hedge. If the premise is weak, say so before exploring approaches. This may eliminate the need for a full brainstorm.\n\nPresent as:\n```\nPremise check:\n- Core assumption: {what must be true}\n- Inaction cost: {what happens if we skip this}\n- Foundation: {existing item or mature platform to build on, or \"none — clean sheet\"}\n- Verdict: {STRONG \u002F QUESTIONABLE \u002F WEAK}\n```\n\nIf verdict is WEAK: flag it and ask the user if they want to continue or reconsider.\n\n## Step 3: Interview (grilling engine, one question at a time)\n\nThis is a grilling in the wayfinder sense: the agent asks, the human answers, one question per exchange. Never stand in for the human's side of the exchange.\n\nRun the grilling engine (`.claude\u002Fskills\u002Fgrilling\u002FSKILL.md`) with:\n\n- `question_set`: `.claude\u002Fskills\u002F_shared\u002Fquestions\u002Fbrainstorm.md` (STARTUP and BUILDER sets as `depends_on` branches on the `Q-mode` fact)\n- `known_facts`: `Q-mode` from Step 0.5, `Q-company` from Step 0 or Step 1, and any question already answered by the args, the board entry, a prior turn, or Step 2 research\n- `mode`: `one-at-a-time` (one `AskUserQuestion` per question) unless the user passed `--rounds`\n\nEach question is its own `AskUserQuestion` call with 2 to 4 options pre-filled from Step 2 research. Mark the first option `(Recommended)` when research points to one answer. Never batch several decisions into one question, and never collapse the interview to a single question (`decision-queue-one-at-a-time`). If `Q-company` is still unresolved, ask it as a picker of plausible company slugs from `companies\u002Fmanifest.yaml`.\n\nWhen the sweep produced removal candidates, `Q-retire` is part of the interview: the user confirms which removals enter the plan.\n\nIf an answer opens a new decision (for example a constraint that changes the approach space), ask a follow-up the same way. The interview ends when no directional input is missing.\n\nRecord every answer in brainstorm.md under `## Interview Answers` as `Q-id: answer` lines. The plan phase (Step 8) and `\u002Fprd` load these ids as `known_facts`.\n\n### Interactive checkpoint after research (optional but encouraged)\n\nBefore starting the interview, if Step 2 surfaced a strong prior-art hit (existing project, near-duplicate worker, dead-end policy), AskUserQuestion ONCE: \"Proceed with new brainstorm \u002F Extend existing {project} \u002F Park — duplicate of {X}.\" This prevents redundant brainstorms.\n\n## Step 4: 3-Layer Landscape Research (stored to the project)\n\nResearch in layers, and **write the findings down** — every substantive research pass produces a markdown note under the project's `research\u002F` directory (wayfinder assets pattern: notes are linked from the brainstorm, not pasted into it):\n\n```\n{project_dir}\u002Fresearch\u002F\n  hq-landscape.md        # Layer 1 — prior art, related projects, workers, policy constraints\n  market-landscape.md    # Layer 2 — alternatives, comparable tools, pricing, dynamics\n  web-{topic}.md         # Layer 3 — one note per live-web investigation, with sources\n```\n\nWhere `{project_dir}` is `companies\u002F{co}\u002Fprojects\u002F{slug}\u002F` (or `personal\u002Fprojects\u002F{slug}\u002F` for personal\u002FHQ). Each note gets a one-line frontmatter-style header (`layer`, `date`, `question it answers`). Notes survive context compaction and feed `\u002Fprd` and `\u002Fdeep-plan` directly — brainstorm.md links them, it never restates them in full.\n\n**Layer 1 — HQ (always, from Step 2):**\nqmd, workers, policies, existing projects, and the Overlap & Cruft Sweep. Distil the Step 2 findings into `research\u002Fhq-landscape.md`: the hits that mattered with their verdicts, the removal candidates with evidence, and the policy constraints that shape the approach space.\n\n**Layer 2 — Reasoning (always, free):**\nCompetitive landscape, known tools, pricing, market context from training data. No API calls needed. Identify alternatives, comparable tools, known pricing tiers, and market dynamics. Write `research\u002Fmarket-landscape.md`. Training data is stale for fast-moving topics (AI models, agent tooling, SDKs, APIs, pricing): mark those claims `unverified` and check them in Layer 3.\n\n**Layer 3 — Live Web (default-on for external-facing ideas):**\nRun live web research whenever the idea touches an external API\u002Fservice, a library or model, an unfamiliar domain, a competitive market, or the user asked for research. Skip only for purely internal tooling on platforms you know cold. Announce what you'll search for and why before searching (user continuing counts as approval). Write one `research\u002Fweb-{topic}.md` per investigation, with sources cited. For deep multi-source questions, delegate to research subagents (Task\u002FAgent) and have each write its own note.\n\nFreshness and authority rules for Layer 3:\n\n- Get today's date with `date +%F` and put the current month and year in queries (\"{topic} changelog {Month YYYY}\").\n- Prefer primary sources: official docs, changelogs, release notes, maintainer repos and issues, standards bodies, vendor engineering blogs. Use aggregators and SEO listicles only to find a primary source.\n- Default window is the last 60 days. Cite every source with its publish or last-updated date. A source older than 60 days is used only when nothing newer covers the point, and is labelled `stale ({date})` in the note.\n- Where a fresh source contradicts Layer 2, the fresh source wins; record the correction.\n- Name the expert methods and tools the field uses for this problem (Guiding Principle 4), from sources, not invented.\n- Always write `research\u002Fweb-best-in-class.md` when Layer 3 runs: how the most advanced companies solve this problem (architecture, UX, speed, quality bar), each point with a dated primary source (Guiding Principle 7).\n\n**Depth guidance:** more research is better than less **as long as it is stored** — a finding that lives only in context is wasted. Stop a layer when new passes stop changing the approach comparison, not at a fixed effort cap.\n\n## Step 5: Generate brainstorm.md\n\n**Derive slug** from title (lowercase, hyphens, no special chars).\n\n**Create** `companies\u002F{co}\u002Fprojects\u002F{slug}\u002Fbrainstorm.md` (or `personal\u002Fprojects\u002F{slug}\u002Fbrainstorm.md` for personal\u002FHQ):\n\n```markdown\n---\ncompany: {slug}\ncreated_at: {ISO8601}\nstatus: exploring\npromoted_to: null\nsource_idea_id: {board ID or null}\n---\n\n# {Title}\n\n> {1-sentence problem\u002Fopportunity framing}\n\n## Context\n\n{2-4 sentences: why this matters now, what triggered the exploration, rough size of the thing}\n\n## Research\n\n\u003C!-- index of research\u002F notes — gist + link, never the full content -->\n\n- [HQ landscape](research\u002Fhq-landscape.md) — {one-line gist}\n- [Market landscape](research\u002Fmarket-landscape.md) — {one-line gist}\n- [{Web topic}](research\u002Fweb-{topic}.md) — {one-line gist} *(if Layer 3 ran)*\n\n## What We Know\n\n- {Confirmed fact from HQ research — existing projects, prior work, tech constraints}\n- {Relevant worker or knowledge base that exists}\n- ...\n\n## What We Don't Know\n\n- {Open question that would change the approach}\n- {Assumption that needs validating}\n- {Missing info that blocks confident decision-making}\n- ...\n\n## Overlap & Cruft\n\n| Existing item | Path | What it does | Verdict |\n|---|---|---|---|\n| {skill \u002F worker \u002F repo \u002F script \u002F project} | {path} | {one line} | {reuse \u002F extend \u002F merge \u002F replace} |\n\n**Removal candidates (confirmed in Q-retire):**\n- {path} — {why it is cruft: superseded by X \u002F zero callers \u002F last changed {date}} · blast radius: {callers or \"none\"}\n\n## Interview Answers\n\nQ-direction: {answer}\nQ-success: {answer}\n{one `Q-id: answer` line per Step 3 answer}\n\n## Premise Check\n\n{Position on whether the core assumption holds. State verdict: STRONG \u002F QUESTIONABLE \u002F WEAK}\n\n## Narrowest Wedge *(STARTUP mode only)*\n\n{Smallest version that delivers real value to one specific person. What's the narrowest scope — one seam, not the whole subsystem?}\n\n## Approaches\n\n### Option A: {Name}\n\n**How it works:** {2-3 sentences describing the approach}\n\n**Reuses \u002F merges \u002F retires:** {existing items it builds on, combines, or removes}\n**Systems after the change:** {what exists and runs afterwards, e.g. \"1 service replaces 2 scripts and a cron\"}\n**Scorecard:** durable {H\u002FM\u002FL} · flexible {H\u002FM\u002FL} · resilient {H\u002FM\u002FL} · scalable {H\u002FM\u002FL} · infra cost {H\u002FM\u002FL running spend} · mature {H\u002FM\u002FL} · modern {H\u002FM\u002FL}\n\n**Tradeoffs:**\n- Pro: {specific advantage}\n- Pro: {specific advantage}\n- Con: {specific cost or risk}\n\n**Effort:** {S \u002F M \u002F L \u002F XL — scope\u002Frisk} · {throughput: ~N sessions, sequential|concurrent-able}\n**When to choose this:** {specific signal or condition that makes this the right pick}\n\n---\n\n### Option B: {Name}\n\n**How it works:** {2-3 sentences}\n\n**Reuses \u002F merges \u002F retires:** {items}\n**Systems after the change:** {what exists and runs afterwards}\n**Scorecard:** durable · flexible · resilient · scalable · infra cost · mature · modern {H\u002FM\u002FL each}\n\n**Tradeoffs:**\n- Pro: {specific advantage}\n- Con: {specific cost or risk}\n\n**Effort:** {S \u002F M \u002F L \u002F XL — scope\u002Frisk} · {throughput: ~N sessions, sequential|concurrent-able}\n**When to choose this:** {condition}\n\n---\n\n### Option C: {Name} *(only if genuinely distinct from A and B)*\n\n...\n\n---\n\n## Recommendation\n\n**Preferred approach:** Option {X} — {one sentence on why}\n\n**Key condition:** {What would make you choose a different option instead}\n\n**Biggest risk:** {The one thing most likely to blow up the preferred approach}\n\n**Best-in-class reference:** {who does this best today and what they do, linked to `research\u002Fweb-best-in-class.md`}\n\n**Where we go past it:** {what the recommended design does better than the reference, from first principles}\n\n**Removal plan:** {each confirmed removal candidate, what replaces it, and the check that proves it is gone safely (zero references, tests pass), or \"none\"}\n\n### Expert standard *(deeper, not bigger)*\n\n- **Expert moves:** {2-3 things an expert would do for this same outcome that the request did not ask for}\n- **Rawest material:** {primary sources or data the build should start from}\n- **Methods and tools:** {named techniques or libraries, and why each fits}\n- **External verification:** {the check outside the model and the user, with its pass and fail condition}\n\n## Next Steps\n\n- [ ] {Specific validation task or question to resolve before starting PRD}\n- [ ] {Other prerequisite}\n- [ ] {One line per confirmed removal: \"Retire {path}, replaced by {X}\"}\n\n**Promotion path:**\n- Ready to build --> promote to a PRD with `\u002Fprd` (brainstorm.md pre-populates the interview)\n- Needs more research --> edit this file, revisit later\n- Not worth pursuing --> park as idea on the board\n```\n\n**Approach rules:**\n- Generate exactly 2 approaches if the problem is well-defined\n- Generate 3 only if there's a genuine third dimension (build vs buy, now vs later, etc.)\n- Never more than 3 — collapse similar options or pick the most distinct\n- Each option must differ on at least one of: effort, reversibility, dependency, or user experience\n- Must state a recommendation — no \"it depends\" without a stated override condition\n- When the sweep found two or more items doing related jobs, one option must merge or replace them\n- One option is always the first-principles clean-sheet design (Guiding Principle 7), set against the best-in-class reference\n- Rank options on the scorecard: durable, flexible, resilient, scalable, infra cost, mature, modern. Never rank by lines of code or build effort. Recommend the strongest scorecard unless a stated condition overrides it\n- Do not cut scope or pick a stopgap for time reasons: a `\u002Frun-project` loop clears months of former human work in 1 to 3 hours\n- T-shirt effort = scope\u002Frisk, NOT calendar time (policy `ai-velocity-time-sense`): S (one seam, low risk), M (one subsystem, modest unknowns), L (multiple seams, real unknowns), XL (cross-cutting, hard-to-reverse). If \"how long\" is needed, use sessions + concurrency (\"~2 sessions, parallel-able\"), never weeks\u002Fmonths. Be honest about breadth\n\n## Step 6: Board Integration\n\nThe Board entry and Work Mesh registration were created in Step 1.5. Here,\nmark the brainstorm as written.\n\nRead `companies\u002F{co}\u002Fboard.json`, find the entry by `{board-project-id}`, and set:\n- `status` --> `\"brainstormed\"`\n- `brainstorm_path: \"companies\u002F{co}\u002Fprojects\u002F{slug}\u002Fbrainstorm.md\"`\n- `title` --> the final title if it changed during the interview\n- `updated_at`\n\nWrite updated `board.json`.\n\nIf Step 1.5 ended with \"registration incomplete\", or Step 1.5 was skipped\nbecause the company was unknown at the time, run the registration check and\n`register-project.sh --board` now exactly as in Step 1.5. A registration that\nstill fails is reported as \"registration incomplete\" in Step 7.\n\n## Step 6.4: Open Session Journal\n\nSpec: `core\u002Fknowledge\u002Fpublic\u002Fhq-core\u002Fjournal-spec.md`. Open a session journal at the project_dir so research, decisions, and dead ends survive context compaction:\n\n```bash\n.claude\u002Fskills\u002F_shared\u002Fjournal.sh open brainstorm \"{project_dir}\"\n```\n\nWhere `{project_dir}` is `companies\u002F{co}\u002Fprojects\u002F{slug}\u002F` (or `personal\u002Fprojects\u002F{slug}\u002F` for personal\u002FHQ). The helper:\n\n- Creates `{project_dir}\u002Fjournal\u002F{ISO8601}-brainstorm.md` with frontmatter (`status: active`, `skill: brainstorm`, `summary: \"\"`)\n- Writes a session-scoped pointer at `.claude\u002Fstate\u002Factive-journal.d\u002F` so only this session's subsequent steps and autocapture hook append to this file\n- Stays open across `\u002Fprd`, `\u002Fdeep-plan` handoffs — only `\u002Fhandoff` and `\u002Fcheckpoint` close it\n\nAfter the helper returns, append a curated entry summarizing the brainstorm outcome (preferred approach, biggest risk, open questions) to the journal's `## Decisions` section. The autocapture hook will append a `## Auto-capture` line for any subsequent Agent \u002F WebFetch \u002F WebSearch \u002F AskUserQuestion calls in this session.\n\n**Skip if:** journal helper is unavailable (fail-soft, don't error).\n\n## Step 6.5: Spawn Knowledge Pulse (Background)\n\nIf `{co}` is resolved and company has a knowledge directory (not `null` in manifest):\n\nUse the background `Task` tool without worktree isolation so the child stays in this canonical HQ checkout.\n\n```\nTask({\n  subagent_type: \"general-purpose\",\n  description: \"Pulse-garden {co} knowledge\",\n  run_in_background: true,\n  prompt: \"Run the knowledge-pulse skill at .claude\u002Fskills\u002Fknowledge-pulse\u002FSKILL.md.\n    company_slug: {co}\n    knowledge_path: companies\u002F{co}\u002Fknowledge\u002F\n    policies_path: companies\u002F{co}\u002Fpolicies\u002F\n    caller: brainstorm\n    qmd_collection: {qmd_collections[0] from manifest, or omit if none}\n    search_results_summary: {condensed list of qmd hits from Step 2, max 10 items — path + title per hit}\n    discovered_facts: {any new company facts surfaced during premise check or research, or 'none'}\n    Read the skill file for full instructions.\"\n})\n```\n\nDo NOT wait for the pulse to complete — continue immediately to Step 7.\n\n**Skip if:** company has no knowledge directory.\n\n## Step 6.6: Deploy Visual Brainstorm Deck\n\nThe brainstorm is written. Automatically deploy a **visual research deck** so the findings are\nshareable, not just a markdown file — the framing, what we know \u002F don't know, the premise\nverdict, the approaches compared with their tradeoffs, and the recommendation, rendered on the\ncompany's design standards.\n\nInvoke the `project-summary` skill in **deck mode** on this brainstorm:\n`project-summary {co}\u002F{slug} --brainstorm` (for personal\u002FHQ brainstorms the path is\n`personal\u002Fprojects\u002F{slug}` and it falls back to a password gate). It reads `brainstorm.md`,\nrenders a branded deck, deploys it company-gated via hq-deploy, and returns a live URL.\n\n**Runs once per session.** Run the deck deploy after the Step 7 gate, not before it. When the gate answer is `Stop here` or `Upgrade to deep-plan`, deploy the brainstorm deck as described here. When the gate answer is `Plan it now`, defer this deploy: the project summary deploy at the end of Step 8 covers the brainstorm and the PRD, and only that one link is reported.\n\nRules for this step:\n- **Visualization only** — it reads `brainstorm.md` and writes no project files; this does not\n  violate the \"brainstorm.md + board.json are the only files written\" rule (the deck is a\n  deploy artifact under `workspace\u002F`, not a project file).\n- **Non-fatal** — if the build or deploy fails (no HQ identity, offline, etc.), log a one-line\n  note and continue. The brainstorm must never be blocked by the deck deploy.\n- Capture the returned URL (or `skipped — {reason}`, or `deferred to plan phase`) and surface it in the final summary.\n\n## Step 7: Confirm & Reindex\n\nPrint:\n```\nBrainstorm: **{title}** ({id})\nFile: companies\u002F{co}\u002Fprojects\u002F{slug}\u002Fbrainstorm.md\n\nApproaches:\n  A. {Option A name} — {effort}\n  B. {Option B name} — {effort}\n  {C. Option C name — effort, if present}\n\nRecommendation: Option {X}\n```\n\nThe project folder is delegatable as it stands: `\u002Fdelegate \u003Cwho> {slug}` hands\nover `brainstorm.md`, `research\u002F`, and the latest journal entry, tells the\nrecipient there is no PRD yet, and points them at `\u002Fprd {slug}`. No `prd.json`\nis needed first.\n\nReindex: `qmd update 2>\u002Fdev\u002Fnull || true`\n\n### Plan gate\n\nAfter the confirm, ask one `AskUserQuestion` with exactly three options, in this order:\n\n1. `Plan it now` — add `(Recommended)` when the brainstorm recommends a single approach\n2. `Upgrade to deep-plan`\n3. `Stop here`\n\nHandle the answer:\n\n- **Plan it now**: continue to Step 8 in this session.\n- **Upgrade to deep-plan**: run the Step 6.6 deck deploy, then print `Next: \u002Fdeep-plan {co} {slug} (brainstorm: {brainstorm_path})` and stop. Do not write prd.json.\n- **Stop here**: run the Step 6.6 deck deploy, print the deck URL, and stop. Board status stays `brainstormed` (the Step 6 board entry is not advanced), and prd.json is not written.\n\n## Step 8: Plan Phase (only after the gate answers Plan it now)\n\nThe plan phase is the only part of this skill that writes prd.json. It reuses the `\u002Fprd` interview and finalize steps so the user does not re-answer questions.\n\n1. **Interview.** Run the grilling engine with `question_set: .claude\u002Fskills\u002F_shared\u002Fquestions\u002Fprd.md`, `mode: one-at-a-time`, and `known_facts` loaded from the Phase B answers: every `Q-id: answer` line in brainstorm.md whose id exists in the PRD question set, plus answers the PRD set's `prefill:` hints take from brainstorm.md (Context, Recommendation, rejected approaches). Do not re-ask loaded ids as confirmations.\n2. **Generate.** Write `{project_dir}\u002Fprd.json` and `{project_dir}\u002FREADME.md` following `\u002Fprd` Step 5 (`.claude\u002Fskills\u002Fprd\u002FSKILL.md`), including `metadata.interview` from the engine count object. Every item in the brainstorm's **Removal plan** becomes its own story (or acceptance criteria on the story that replaces it), with the removal check as its acceptance test. Carry the **External verification** pass condition into the PRD's acceptance criteria. Run `bash core\u002Fscripts\u002Fprd-interview-check.sh {project_dir}\u002Fprd.json` and show any warning.\n3. **Finalize.** Follow `.claude\u002Fskills\u002F_shared\u002Fprd-finalize.md` in order as caller `\u002Fprd`. Step 5.5 sets brainstorm.md frontmatter to `status: promoted` with `promoted_to: {project_dir}\u002Fprd.json`. Step 5.6 sets the board entry to `prd_created`. Step 5.7 syncs the stories onto the Work Mesh project that Step 1.5 already registered (policy `hq-work-mesh-prd-genesis`); do not skip it.\n4. **Deploy once.** Run the project summary deploy that policy `auto-deploy-project-summary-on-brainstorm-prd` requires for a finished PRD (`project-summary {co}\u002F{slug}`). This one deploy covers the brainstorm and the PRD, because Step 6.6 was deferred. Report only this link.\n5. **Confirm.** Print the `\u002Fprd` Step 9 summary and stop. Do not start execution.\n\n## Phases\n\n| Phase | Steps | Files written |\n|-------|-------|---------------|\n| A (research) | 0 to 2, 4 | `{project_dir}\u002Fresearch\u002F*.md` |\n| B (interview) | 3 | none; answers go into brainstorm.md in Phase C |\n| C (brainstorm) | 5 to 7 | `brainstorm.md`, `board.json`, journal |\n| Plan | 8 | `prd.json`, `README.md`, `board.json`, brainstorm.md frontmatter |\n\n## Final step — auto-checkpoint \u003C!-- AUTO-CHECKPOINT-ON-COMPLETION -->\n\nOnce the gate is answered and its branch has finished, automatically save a lightweight checkpoint so the user can continue in a fresh session without a manual `\u002Fhandoff`. This only **snapshots** continuity — it does **not** close the brainstorm (which stays open across `\u002Fprd`).\n\nWrite `workspace\u002Fthreads\u002FT-{UTC YYYYMMDD-HHMMSS}-auto-brainstorm-{slug}.json` with: `thread_id`, `version: 1`, `type: \"auto-checkpoint\"`, `created_at`, `updated_at`, `workspace_root`, `cwd`, `git: { branch, current_commit, dirty }`, `conversation_summary` (topic + recommended option, one sentence), `files_touched` (include the `brainstorm.md` path, and `prd.json` and `README.md` when Step 8 ran), `phases` (a map from each touched file to the phase that produced it: `A`, `B`, `C`, or `plan`, as listed in the Phases table), `gate_answer` (`Plan it now`, `Upgrade to deep-plan`, or `Stop here`), `next_steps` (e.g. \"promote to PRD with `\u002Fprd`, or refine `brainstorm.md`\"), and `metadata: { title: \"Auto: brainstorm {slug}\", tags: [\"auto-checkpoint\", \"brainstorm\"], trigger: \"brainstorm-complete\" }`.\n\nKeep it cheap: do **not** rebuild INDEX, update `recent.md`, run `qmd update`, or write a legacy checkpoint. Then tell the user a fresh session can resume from this checkpoint (`\u002Fstartwork`).\n\n## Rules\n\n- **Scan HQ before asking anything** — research phase (Step 2) happens before the first question. Never ask for info findable in qmd, board.json, or policies\n- **Sweep for overlap every time** — no brainstorm skips the Overlap & Cruft Sweep. A recommendation that builds something HQ or the company already has is a defect\n- **Removals are verified, not assumed** — each removal candidate carries evidence (last change, live references, superseded-by) and the user's `Q-retire` confirmation before it enters the plan\n- **Quality over effort** — never recommend an option because it is less code or quicker to build. Code is cheap with coding agents; runtime cost, fragility, and lock-in are not\n- **Fresh sources for fast-moving facts** — tool, model, API, and pricing claims cite a primary source from the last 60 days, or are labelled stale or unverified\n- **One question AT A TIME, not one total** — the gate and every interview question is its own `AskUserQuestion` call (decision-queue style per `decision-queue-one-at-a-time`). Ask every unresolved field; skip any already clear from args\u002Fresearch. Never batch multiple decisions into a single combined question, and never collapse the full interview to a single question. 4–8 questions is a normal interview\n- **2-3 approaches, no more** — present distinct options, not variations. If only one reasonable path exists, say so and explain why\n- **State a recommendation** — \"it depends\" without a stated override condition is not a recommendation\n- **No execution** — brainstorm.md is the output. Do NOT write code, scaffold repos, or modify any implementation files\n- **Phases A through C never write prd.json; only the plan phase does, after the gate** — Step 8 runs only when the gate answers `Plan it now`\n- **No Linear sync** — brainstorms are pre-planning. Linear happens at PRD time\n- **No orchestrator registration** — brainstorms are not executable\n- **Research is stored, not ephemeral** — every substantive research pass writes a note under `{project_dir}\u002Fresearch\u002F`, linked from brainstorm.md. Live web research is default-on for external-facing ideas; skip only for purely internal tooling on well-known platforms\n- **board.json + brainstorm.md + research\u002F notes are the only project files written in Phases A through C** (the plan phase adds prd.json and README.md) — plus the final auto-checkpoint thread under `workspace\u002Fthreads\u002F` (see \"Final step — auto-checkpoint\"). No implementation\u002Ftarget files are modified (knowledge pulse runs as a background agent and writes its own report independently)\n- **T-shirt effort, not story points** — sized by scope\u002Frisk, not calendar time: S (one seam), M (one subsystem), L (multiple seams + unknowns), XL (cross-cutting, hard-to-reverse). See policy `ai-velocity-time-sense`\n- **Company isolation enforced** — if anchored, scope all searches to that company. Never mix company knowledge in approaches\n- **brainstorm.md is human-editable** — the user may refine it after generation. The PRD skill reads whatever is in the file, not just what was machine-generated\n- **Do not create README.md** — brainstorm.md is self-contained\n- **Anti-sycophancy** — Never say \"that's interesting,\" \"great idea,\" \"excellent question.\" Take a position immediately. If the premise is weak, say so before exploring approaches. State which approach you'd actually build and why. Brainstorm is for honest analysis, not validation\n\n## See also\n\n- `\u002Fprd` — turn the chosen approach into a PRD\n- `\u002Fidea` — capture it on the board first\n- `\u002Fwayfinder` — when the effort is too big for one brainstorm and the destination is foggy; brainstorm is its grilling engine. Interview + stored-research pattern adapted from [mattpocock\u002Fskills](https:\u002F\u002Fgithub.com\u002Fmattpocock\u002Fskills)\n","# Brainstorm - Structured Exploration\n\nThink through a problem before committing to a PRD. Research HQ context, compare approaches, surface unknowns.\n\n**Input:** The user's argument — typically `[company] \u003Cidea description or board idea ID>`.\n\n**Pipeline:** idea capture --> **brainstorm** --> PRD --> run-project\n\n## Guiding Principles\n\nThese shape every step below. When two steps pull in different directions, these win.\n\n1. **Best long-term solution wins, not least effort.** Coding agents make code nearly free to write, so code volume and build effort are not costs to minimise. Pick the solution that is the most durable, flexible, resilient, scalable, cost-efficient to run (infrastructure spend), mature, and modern. The real costs are runtime spend, operational burden, fragility, and lock-in. Elegance still matters: prefer one well-designed system that merges or replaces several existing ones, because fewer systems are more resilient and cheaper to run. Judge approaches by what exists and runs after the change, not by how much code it takes.\n2. **Find what already exists before proposing anything new.** Fast AI work produces duplicates: two skills, workers, scripts, or repos that do the same job. Step 2 sweeps for them. Every brainstorm states what it reuses, what it merges, and what it retires.\n3. **Remove cruft as part of the solution.** Out-of-date or superseded material found during the sweep goes into the recommendation as a verified removal plan. The brainstorm verifies each removal (evidence plus user confirmation); the PRD carries it out. The brainstorm itself deletes nothing.\n4. **Deeper, not bigger** (adapted from [be-ambitious](https:\u002F\u002Fgithub.com\u002FDannyMac180\u002Fskills\u002Fblob\u002Fmain\u002Fbe-ambitious\u002FSKILL.md)). Keep the user's goal fixed, and raise the standard for that outcome: what an expert in the field would do that was not asked for, the rawest primary sources, named methods and tools, and an external check with a stated pass condition. Drop side quests and extra deliverables that do not serve the goal. The solution design itself is unbounded (Principle 7).\n5. **Assume agent velocity.** A `\u002Frun-project` loop typically finishes in 1 to 3 hours what a human team once planned in months. Never shrink scope, defer the clean solution, or pick a hack because the full version \"sounds long\". Effort fields still use scope\u002Frisk sizing and session counts (policy `ai-velocity-time-sense`), never calendar estimates.\n6. **Fresh, authoritative research.** Web research prefers primary sources (official docs, changelogs, release notes, maintainer repos, standards) published in the last 60 days. Training-data knowledge of tools, models, APIs, and pricing is treated as a hypothesis until a fresh source confirms it.\n7. **Study the best, then go past them.** Research how the most advanced companies solve this problem for quality, UX, and speed: their engineering blogs, published architectures, open-source code, and shipped products. Use that as the reference bar, not the ceiling. Then design from first principles with no bounds on what is possible, and aim for a solution better than anything that exists. At least one approach is this clean-sheet design.\n\n\n## Work Mesh Live — trusted bind (do this first)\n\nAs soon as Step 0 resolves `{co}`, and before any other tool call that touches project work, bind the session per\n`.claude\u002Fskills\u002F_shared\u002Fwork-mesh-live-bind.md` (US-011):\n\n```bash\nbash core\u002Fscripts\u002Fwork-mesh-live-bind-trusted.sh \\\n  --company \"{co}\" --project \"{project}\" --task \"{task}\"\n```\n\nOmit `--task` when unknown. This writes `workspace\u002Fsessions\u002F\u003Csid>\u002Fmeta.yaml`\nand reconciles with `observation.trustedContext` (no `--trusted` CLI flag).\n\n## Step 0: Parse Input & Company Anchor\n\nCheck if the **first word** of the user's input matches a company slug in `companies\u002Fmanifest.yaml`.\n\n**How to check:** Read `companies\u002Fmanifest.yaml`. Extract top-level keys (company slugs). If the first word exactly matches one:\n\n1. **Set `{co}`** = matched slug. Strip from input — remaining text is the description\n2. **Announce:** \"Anchored on **{co}**\"\n3. **Bind the session** — run `bash core\u002Fscripts\u002Fwork-mesh-live-bind-trusted.sh --company \"{co}\"` now, before any read under `companies\u002F{co}\u002F`. The scope guard blocks company paths until the session is bound to `{co}`.\n4. **Load policies (frontmatter-only)** — Collect the eligible files for the resolved company, except `example-policy.md`, preserve their order, and split the stable file order into consecutive chunks of at most 40 files. For each chunk, run `bash core\u002Fscripts\u002Fread-policy-frontmatter.sh {file1} {file2} ...` once with each path as a separate argument. Keep each call under 30 KB of output. The first output block belongs to the chunk’s first file argument; each later block belongs to the path named by its preceding `# --- policy-file: \u003Cpath> ---` separator. Note `enforcement: hard` titles. For hard-enforcement policies only, additionally Read the `## Rule` section with a targeted range\n5. **Scope qmd searches** — If company has `qmd_collections` in manifest, use `-c {collection}`\n\n**If no match** -- full input is the description text. Company resolved later.\n\n**Board ID detection:** After company check, see if remaining args match a board.json project ID pattern (`{prefix}-proj-{NNN}`). If so, this brainstorm is expanding an existing idea — proceed to Step 1 with that ID.\n\n## Step 0.5: Mode Selection\n\nInfer the brainstorm mode from context — no question needed:\n\n- **STARTUP** — early-stage idea, no existing solution, exploring whether worth building. Default when: no existing board entry with `prd_path`, no prior art in HQ, greenfield domain\n- **BUILDER** — existing product\u002Fsystem, designing a feature or extension. Default when: expanding existing project, board entry has `prd_path`, target repo already exists\n\nAnnounce mode: `Mode: **STARTUP**` or `Mode: **BUILDER**`\n\nMode affects Steps 2-4 (premise challenge depth, question framing, research scope).\n\n## Step 1: Resolve Company + Board Idea\n\n**If board ID matched in Step 0:**\n1. If `{co}` already set: read `companies\u002F{co}\u002Fboard.json`, find entry by ID\n2. If `{co}` not set: scan all `companies\u002F*\u002Fboard.json` for the ID (use manifest `board_path` list). Once found, set `{co}` and bind the session as in Step 0 before reading further\n3. Extract the entry's `title` and `description` as starting context\n4. Set `source_idea_id` = matched ID\n\n**If no board ID and no company:** infer from cwd (`companies\u002F{slug}\u002F` --> use that slug, `repos\u002F{pub|priv}\u002F{name}` --> manifest lookup). If still ambiguous, ask the user directly in Step 3.\n\n**If input is empty:** go straight to Step 3 (full interview).\n\n## Step 1.5: Board Entry + Work Mesh Registration (at start, not at the end)\n\nThe project exists on the Board and in Work Mesh from the moment the\nbrainstorm starts, so teammates and the HQ app see it while the work is still\nin progress. Do this before any research or interview question. Skip only\nwhen the company is unknown (empty input): run it as soon as Step 3 resolves\n`{co}` and a working title.\n\nRead `companies\u002F{co}\u002Fboard.json`.\n\n**If started from existing board idea** (`source_idea_id` set): find that\nentry; set `status` to `\"exploring\"` if it is still `\"idea\"`; update\n`updated_at`. Reuse its `id` as `{board-project-id}`.\n\n**If fresh brainstorm**: get the next ID from\n`bash core\u002Fscripts\u002Fboard-project-id.sh next {co}` (the highest existing\n`{prefix}-proj-{NNN}` number + 1, zero-padded to 3 digits) and append the entry\nbelow. After writing, run `bash core\u002Fscripts\u002Fboard-project-id.sh check {co}`;\nif it exits non-zero, fix the entry you wrote before continuing:\n  ```json\n  {\n    \"id\": \"{prefix}-proj-{NNN}\",\n    \"title\": \"{concise working title}\",\n    \"description\": \"{user's description}\",\n    \"status\": \"exploring\",\n    \"scope\": \"company\",\n    \"app\": null,\n    \"initiative_id\": null,\n    \"objective_id\": null,\n    \"prd_path\": null,\n    \"brainstorm_path\": null,\n    \"created_at\": \"{ISO8601}\",\n    \"updated_at\": \"{ISO8601}\"\n  }\n  ```\n\nWrite `board.json`, re-read it, and confirm the entry exists.\n\nThen register the entry in Work Mesh. This is always-on for cloud-backed\ncompanies; there is no flag and no prompt.\n\n```bash\nbash core\u002Fscripts\u002Fwork-mesh-project-registration-offer.sh --check {co} {board-project-id}\n```\n\n- `register` → run the registration and verify its one output line:\n  ```bash\n  bash core\u002Fscripts\u002Fregister-project.sh --board {co} {board-project-id}\n  ```\n  The verify line is `registered {co}\u002F{board-project-id} thread=\u003Cid> channel=\u003Cid>`.\n  If the script exits non-zero or prints anything else, say \"registration\n  incomplete\" once, keep going with the brainstorm, and retry the same command\n  in Step 6. Do not create a replacement project.\n- `registered` → nothing to do.\n- `local` → the company is not cloud-backed; nothing to do.\n- `deferred` → the user declined registration for this entry earlier; do not\n  register it. Register only if the user asks for it in this session.\n- `missing` → the Board write above failed; fix it and re-run the check.\n\n## Step 2: HQ Research (before any questions)\n\nDo not ask questions yet. Build context from HQ first.\n\n**Hybrid search (BM25 + vector + re-ranking):**\n- If anchored + company has `qmd_collections`: `qmd query \"\u003Cdescription keywords>\" -c {collection} --json -n 10`\n- If not anchored: `qmd query \"\u003Cdescription keywords>\" --json -n 10`\n\n**Existing projects:**\n- If anchored: search `companies\u002F{co}\u002Fprojects\u002F` directly or `qmd search \"prd.json\" -c {co} --json -n 10`\n- Read top 2-3 match metadata (name, description, status) to check for overlap\n\n**Workers:**\n- Read `core\u002Fworkers\u002Fregistry.yaml` — identify workers with skills matching the description\n\n**Policies (anchored only):**\n- Already loaded in Step 0. Note any constraints that affect approach selection\n\n**Target repo (if inferable):**\n- Note existence, don't deep-read. If repo has qmd collection, run scoped search\n\n### Overlap & Cruft Sweep (always run)\n\nSearch for anything that already does part of the job, inside the company scope plus HQ core. Cover every surface, using 3 to 5 keyword variants of the idea (synonyms, the verb, the output it produces):\n\n| Surface | Where to look |\n|---|---|\n| Code and repos | the company's `repos:` list in `companies\u002Fmanifest.yaml`; `grep -rl` \u002F `qmd` inside those repos for the key nouns and verbs |\n| Infrastructure | manifest `deploy:` \u002F `vercel_projects:` \u002F `sources:`, `hq integrations list --usable`, existing deploy targets and services |\n| Workers | `core\u002Fworkers\u002Fregistry.yaml` and `companies\u002F{co}\u002Fworkers\u002F` |\n| Skills and commands | `.claude\u002Fskills\u002F`, `companies\u002F{co}\u002Fskills\u002F`, `personal\u002Fskills\u002F` (HQ work only) |\n| Projects and ideas | `companies\u002F{co}\u002Fprojects\u002F*\u002F` (brainstorm.md, prd.json status), `board.json` entries in any status, including in-flight and parked |\n| Knowledge and policies | qmd hits from above, `companies\u002F{co}\u002Fpolicies\u002F`, `core\u002Fpolicies\u002F` |\n\nWhen the surface is broad, delegate the sweep to an `Explore` subagent with the keyword list and the table above, and have it return paths plus one-line verdicts. `Explore` is read-only: it cannot create files. When a sweep must write its own research note (for example `research\u002F*.md`), dispatch it as a `general-purpose` agent instead, so the parent does not re-emit the findings by hand.\n\nGive every hit one verdict:\n\n- **Reuse** — does the job as is; the solution calls it\n- **Extend** — does most of the job; the solution builds on it\n- **Merge** — overlaps another hit or the new idea; the solution combines them into one\n- **Replace** — the new solution supersedes it; it gets retired\n- **Unrelated** — keyword match only; drop it\n\n**Cruft verification.** A hit is a removal candidate when it is superseded, duplicated, or out of date. Before listing it, collect evidence for each candidate:\n\n1. Last change: `git -C {repo} log -1 --format=%cs -- {path}` (or file mtime outside git)\n2. Live references: grep for its name or path across skills, hooks, workers, scripts, and repos; zero callers is strong evidence\n3. Status: board\u002FPRD status, deprecated markers, a newer item that does the same job\n4. Blast radius: what breaks if it goes (callers, docs, scheduled jobs, deployed services)\n\nOnly candidates with evidence go forward. Each one is confirmed with the user in Step 3 (`Q-retire`) and, once confirmed, becomes part of the recommendation's removal plan. The brainstorm never deletes anything itself (**No execution** rule).\n\nWrite the full sweep to `research\u002Fhq-landscape.md` (Step 4, Layer 1).\n\nPresent compact summary:\n```\nResearch complete:\n- Related projects: {list or \"none found\"}\n- Relevant workers: {list}\n- Existing code\u002Fskills\u002Finfra: {hits with verdict: reuse \u002F extend \u002F merge \u002F replace}\n- Removal candidates: {count, with one-line evidence each, or \"none\"}\n- Policies: {count loaded}\n- Prior art: {relevant knowledge hits or \"none\"}\n```\n\n### Premise Challenge (always run, both modes)\n\nAfter research, before asking the user anything, challenge the premise:\n\n1. **Is this the right problem?** What assumption must be true for this to matter?\n2. **What happens if we do nothing?** Is inaction a viable option?\n3. **What already exists to build on?** Check the sweep first: a Reuse or Extend hit is the foundation, and a mature external platform may beat a custom build on durability and running cost. Do not pick a smaller, weaker solution because it is quicker to build.\n\nState a position. Don't hedge. If the premise is weak, say so before exploring approaches. This may eliminate the need for a full brainstorm.\n\nPresent as:\n```\nPremise check:\n- Core assumption: {what must be true}\n- Inaction cost: {what happens if we skip this}\n- Foundation: {existing item or mature platform to build on, or \"none — clean sheet\"}\n- Verdict: {STRONG \u002F QUESTIONABLE \u002F WEAK}\n```\n\nIf verdict is WEAK: flag it and ask the user if they want to continue or reconsider.\n\n## Step 3: Interview (grilling engine, one question at a time)\n\nThis is a grilling in the wayfinder sense: the agent asks, the human answers, one question per exchange. Never stand in for the human's side of the exchange.\n\nRun the grilling engine (`.claude\u002Fskills\u002Fgrilling\u002FSKILL.md`) with:\n\n- `question_set`: `.claude\u002Fskills\u002F_shared\u002Fquestions\u002Fbrainstorm.md` (STARTUP and BUILDER sets as `depends_on` branches on the `Q-mode` fact)\n- `known_facts`: `Q-mode` from Step 0.5, `Q-company` from Step 0 or Step 1, and any question already answered by the args, the board entry, a prior turn, or Step 2 research\n- `mode`: `one-at-a-time` (one `AskUserQuestion` per question) unless the user passed `--rounds`\n\nEach question is its own `AskUserQuestion` call with 2 to 4 options pre-filled from Step 2 research. Mark the first option `(Recommended)` when research points to one answer. Never batch several decisions into one question, and never collapse the interview to a single question (`decision-queue-one-at-a-time`). If `Q-company` is still unresolved, ask it as a picker of plausible company slugs from `companies\u002Fmanifest.yaml`.\n\nWhen the sweep produced removal candidates, `Q-retire` is part of the interview: the user confirms which removals enter the plan.\n\nIf an answer opens a new decision (for example a constraint that changes the approach space), ask a follow-up the same way. The interview ends when no directional input is missing.\n\nRecord every answer in brainstorm.md under `## Interview Answers` as `Q-id: answer` lines. The plan phase (Step 8) and `\u002Fprd` load these ids as `known_facts`.\n\n### Interactive checkpoint after research (optional but encouraged)\n\nBefore starting the interview, if Step 2 surfaced a strong prior-art hit (existing project, near-duplicate worker, dead-end policy), AskUserQuestion ONCE: \"Proceed with new brainstorm \u002F Extend existing {project} \u002F Park — duplicate of {X}.\" This prevents redundant brainstorms.\n\n## Step 4: 3-Layer Landscape Research (stored to the project)\n\nResearch in layers, and **write the findings down** — every substantive research pass produces a markdown note under the project's `research\u002F` directory (wayfinder assets pattern: notes are linked from the brainstorm, not pasted into it):\n\n```\n{project_dir}\u002Fresearch\u002F\n  hq-landscape.md        # Layer 1 — prior art, related projects, workers, policy constraints\n  market-landscape.md    # Layer 2 — alternatives, comparable tools, pricing, dynamics\n  web-{topic}.md         # Layer 3 — one note per live-web investigation, with sources\n```\n\nWhere `{project_dir}` is `companies\u002F{co}\u002Fprojects\u002F{slug}\u002F` (or `personal\u002Fprojects\u002F{slug}\u002F` for personal\u002FHQ). Each note gets a one-line frontmatter-style header (`layer`, `date`, `question it answers`). Notes survive context compaction and feed `\u002Fprd` and `\u002Fdeep-plan` directly — brainstorm.md links them, it never restates them in full.\n\n**Layer 1 — HQ (always, from Step 2):**\nqmd, workers, policies, existing projects, and the Overlap & Cruft Sweep. Distil the Step 2 findings into `research\u002Fhq-landscape.md`: the hits that mattered with their verdicts, the removal candidates with evidence, and the policy constraints that shape the approach space.\n\n**Layer 2 — Reasoning (always, free):**\nCompetitive landscape, known tools, pricing, market context from training data. No API calls needed. Identify alternatives, comparable tools, known pricing tiers, and market dynamics. Write `research\u002Fmarket-landscape.md`. Training data is stale for fast-moving topics (AI models, agent tooling, SDKs, APIs, pricing): mark those claims `unverified` and check them in Layer 3.\n\n**Layer 3 — Live Web (default-on for external-facing ideas):**\nRun live web research whenever the idea touches an external API\u002Fservice, a library or model, an unfamiliar domain, a competitive market, or the user asked for research. Skip only for purely internal tooling on platforms you know cold. Announce what you'll search for and why before searching (user continuing counts as approval). Write one `research\u002Fweb-{topic}.md` per investigation, with sources cited. For deep multi-source questions, delegate to research subagents (Task\u002FAgent) and have each write its own note.\n\nFreshness and authority rules for Layer 3:\n\n- Get today's date with `date +%F` and put the current month and year in queries (\"{topic} changelog {Month YYYY}\").\n- Prefer primary sources: official docs, changelogs, release notes, maintainer repos and issues, standards bodies, vendor engineering blogs. Use aggregators and SEO listicles only to find a primary source.\n- Default window is the last 60 days. Cite every source with its publish or last-updated date. A source older than 60 days is used only when nothing newer covers the point, and is labelled `stale ({date})` in the note.\n- Where a fresh source contradicts Layer 2, the fresh source wins; record the correction.\n- Name the expert methods and tools the field uses for this problem (Guiding Principle 4), from sources, not invented.\n- Always write `research\u002Fweb-best-in-class.md` when Layer 3 runs: how the most advanced companies solve this problem (architecture, UX, speed, quality bar), each point with a dated primary source (Guiding Principle 7).\n\n**Depth guidance:** more research is better than less **as long as it is stored** — a finding that lives only in context is wasted. Stop a layer when new passes stop changing the approach comparison, not at a fixed effort cap.\n\n## Step 5: Generate brainstorm.md\n\n**Derive slug** from title (lowercase, hyphens, no special chars).\n\n**Create** `companies\u002F{co}\u002Fprojects\u002F{slug}\u002Fbrainstorm.md` (or `personal\u002Fprojects\u002F{slug}\u002Fbrainstorm.md` for personal\u002FHQ):\n\n```markdown\n---\ncompany: {slug}\ncreated_at: {ISO8601}\nstatus: exploring\npromoted_to: null\nsource_idea_id: {board ID or null}\n---\n\n# {Title}\n\n> {1-sentence problem\u002Fopportunity framing}\n\n## Context\n\n{2-4 sentences: why this matters now, what triggered the exploration, rough size of the thing}\n\n## Research\n\n\u003C!-- index of research\u002F notes — gist + link, never the full content -->\n\n- [HQ landscape](research\u002Fhq-landscape.md) — {one-line gist}\n- [Market landscape](research\u002Fmarket-landscape.md) — {one-line gist}\n- [{Web topic}](research\u002Fweb-{topic}.md) — {one-line gist} *(if Layer 3 ran)*\n\n## What We Know\n\n- {Confirmed fact from HQ research — existing projects, prior work, tech constraints}\n- {Relevant worker or knowledge base that exists}\n- ...\n\n## What We Don't Know\n\n- {Open question that would change the approach}\n- {Assumption that needs validating}\n- {Missing info that blocks confident decision-making}\n- ...\n\n## Overlap & Cruft\n\n| Existing item | Path | What it does | Verdict |\n|---|---|---|---|\n| {skill \u002F worker \u002F repo \u002F script \u002F project} | {path} | {one line} | {reuse \u002F extend \u002F merge \u002F replace} |\n\n**Removal candidates (confirmed in Q-retire):**\n- {path} — {why it is cruft: superseded by X \u002F zero callers \u002F last changed {date}} · blast radius: {callers or \"none\"}\n\n## Interview Answers\n\nQ-direction: {answer}\nQ-success: {answer}\n{one `Q-id: answer` line per Step 3 answer}\n\n## Premise Check\n\n{Position on whether the core assumption holds. State verdict: STRONG \u002F QUESTIONABLE \u002F WEAK}\n\n## Narrowest Wedge *(STARTUP mode only)*\n\n{Smallest version that delivers real value to one specific person. What's the narrowest scope — one seam, not the whole subsystem?}\n\n## Approaches\n\n### Option A: {Name}\n\n**How it works:** {2-3 sentences describing the approach}\n\n**Reuses \u002F merges \u002F retires:** {existing items it builds on, combines, or removes}\n**Systems after the change:** {what exists and runs afterwards, e.g. \"1 service replaces 2 scripts and a cron\"}\n**Scorecard:** durable {H\u002FM\u002FL} · flexible {H\u002FM\u002FL} · resilient {H\u002FM\u002FL} · scalable {H\u002FM\u002FL} · infra cost {H\u002FM\u002FL running spend} · mature {H\u002FM\u002FL} · modern {H\u002FM\u002FL}\n\n**Tradeoffs:**\n- Pro: {specific advantage}\n- Pro: {specific advantage}\n- Con: {specific cost or risk}\n\n**Effort:** {S \u002F M \u002F L \u002F XL — scope\u002Frisk} · {throughput: ~N sessions, sequential|concurrent-able}\n**When to choose this:** {specific signal or condition that makes this the right pick}\n\n---\n\n### Option B: {Name}\n\n**How it works:** {2-3 sentences}\n\n**Reuses \u002F merges \u002F retires:** {items}\n**Systems after the change:** {what exists and runs afterwards}\n**Scorecard:** durable · flexible · resilient · scalable · infra cost · mature · modern {H\u002FM\u002FL each}\n\n**Tradeoffs:**\n- Pro: {specific advantage}\n- Con: {specific cost or risk}\n\n**Effort:** {S \u002F M \u002F L \u002F XL — scope\u002Frisk} · {throughput: ~N sessions, sequential|concurrent-able}\n**When to choose this:** {condition}\n\n---\n\n### Option C: {Name} *(only if genuinely distinct from A and B)*\n\n...\n\n---\n\n## Recommendation\n\n**Preferred approach:** Option {X} — {one sentence on why}\n\n**Key condition:** {What would make you choose a different option instead}\n\n**Biggest risk:** {The one thing most likely to blow up the preferred approach}\n\n**Best-in-class reference:** {who does this best today and what they do, linked to `research\u002Fweb-best-in-class.md`}\n\n**Where we go past it:** {what the recommended design does better than the reference, from first principles}\n\n**Removal plan:** {each confirmed removal candidate, what replaces it, and the check that proves it is gone safely (zero references, tests pass), or \"none\"}\n\n### Expert standard *(deeper, not bigger)*\n\n- **Expert moves:** {2-3 things an expert would do for this same outcome that the request did not ask for}\n- **Rawest material:** {primary sources or data the build should start from}\n- **Methods and tools:** {named techniques or libraries, and why each fits}\n- **External verification:** {the check outside the model and the user, with its pass and fail condition}\n\n## Next Steps\n\n- [ ] {Specific validation task or question to resolve before starting PRD}\n- [ ] {Other prerequisite}\n- [ ] {One line per confirmed removal: \"Retire {path}, replaced by {X}\"}\n\n**Promotion path:**\n- Ready to build --> promote to a PRD with `\u002Fprd` (brainstorm.md pre-populates the interview)\n- Needs more research --> edit this file, revisit later\n- Not worth pursuing --> park as idea on the board\n```\n\n**Approach rules:**\n- Generate exactly 2 approaches if the problem is well-defined\n- Generate 3 only if there's a genuine third dimension (build vs buy, now vs later, etc.)\n- Never more than 3 — collapse similar options or pick the most distinct\n- Each option must differ on at least one of: effort, reversibility, dependency, or user experience\n- Must state a recommendation — no \"it depends\" without a stated override condition\n- When the sweep found two or more items doing related jobs, one option must merge or replace them\n- One option is always the first-principles clean-sheet design (Guiding Principle 7), set against the best-in-class reference\n- Rank options on the scorecard: durable, flexible, resilient, scalable, infra cost, mature, modern. Never rank by lines of code or build effort. Recommend the strongest scorecard unless a stated condition overrides it\n- Do not cut scope or pick a stopgap for time reasons: a `\u002Frun-project` loop clears months of former human work in 1 to 3 hours\n- T-shirt effort = scope\u002Frisk, NOT calendar time (policy `ai-velocity-time-sense`): S (one seam, low risk), M (one subsystem, modest unknowns), L (multiple seams, real unknowns), XL (cross-cutting, hard-to-reverse). If \"how long\" is needed, use sessions + concurrency (\"~2 sessions, parallel-able\"), never weeks\u002Fmonths. Be honest about breadth\n\n## Step 6: Board Integration\n\nThe Board entry and Work Mesh registration were created in Step 1.5. Here,\nmark the brainstorm as written.\n\nRead `companies\u002F{co}\u002Fboard.json`, find the entry by `{board-project-id}`, and set:\n- `status` --> `\"brainstormed\"`\n- `brainstorm_path: \"companies\u002F{co}\u002Fprojects\u002F{slug}\u002Fbrainstorm.md\"`\n- `title` --> the final title if it changed during the interview\n- `updated_at`\n\nWrite updated `board.json`.\n\nIf Step 1.5 ended with \"registration incomplete\", or Step 1.5 was skipped\nbecause the company was unknown at the time, run the registration check and\n`register-project.sh --board` now exactly as in Step 1.5. A registration that\nstill fails is reported as \"registration incomplete\" in Step 7.\n\n## Step 6.4: Open Session Journal\n\nSpec: `core\u002Fknowledge\u002Fpublic\u002Fhq-core\u002Fjournal-spec.md`. Open a session journal at the project_dir so research, decisions, and dead ends survive context compaction:\n\n```bash\n.claude\u002Fskills\u002F_shared\u002Fjournal.sh open brainstorm \"{project_dir}\"\n```\n\nWhere `{project_dir}` is `companies\u002F{co}\u002Fprojects\u002F{slug}\u002F` (or `personal\u002Fprojects\u002F{slug}\u002F` for personal\u002FHQ). The helper:\n\n- Creates `{project_dir}\u002Fjournal\u002F{ISO8601}-brainstorm.md` with frontmatter (`status: active`, `skill: brainstorm`, `summary: \"\"`)\n- Writes a session-scoped pointer at `.claude\u002Fstate\u002Factive-journal.d\u002F` so only this session's subsequent steps and autocapture hook append to this file\n- Stays open across `\u002Fprd`, `\u002Fdeep-plan` handoffs — only `\u002Fhandoff` and `\u002Fcheckpoint` close it\n\nAfter the helper returns, append a curated entry summarizing the brainstorm outcome (preferred approach, biggest risk, open questions) to the journal's `## Decisions` section. The autocapture hook will append a `## Auto-capture` line for any subsequent Agent \u002F WebFetch \u002F WebSearch \u002F AskUserQuestion calls in this session.\n\n**Skip if:** journal helper is unavailable (fail-soft, don't error).\n\n## Step 6.5: Spawn Knowledge Pulse (Background)\n\nIf `{co}` is resolved and company has a knowledge directory (not `null` in manifest):\n\nUse the background `Task` tool without worktree isolation so the child stays in this canonical HQ checkout.\n\n```\nTask({\n  subagent_type: \"general-purpose\",\n  description: \"Pulse-garden {co} knowledge\",\n  run_in_background: true,\n  prompt: \"Run the knowledge-pulse skill at .claude\u002Fskills\u002Fknowledge-pulse\u002FSKILL.md.\n    company_slug: {co}\n    knowledge_path: companies\u002F{co}\u002Fknowledge\u002F\n    policies_path: companies\u002F{co}\u002Fpolicies\u002F\n    caller: brainstorm\n    qmd_collection: {qmd_collections[0] from manifest, or omit if none}\n    search_results_summary: {condensed list of qmd hits from Step 2, max 10 items — path + title per hit}\n    discovered_facts: {any new company facts surfaced during premise check or research, or 'none'}\n    Read the skill file for full instructions.\"\n})\n```\n\nDo NOT wait for the pulse to complete — continue immediately to Step 7.\n\n**Skip if:** company has no knowledge directory.\n\n## Step 6.6: Deploy Visual Brainstorm Deck\n\nThe brainstorm is written. Automatically deploy a **visual research deck** so the findings are\nshareable, not just a markdown file — the framing, what we know \u002F don't know, the premise\nverdict, the approaches compared with their tradeoffs, and the recommendation, rendered on the\ncompany's design standards.\n\nInvoke the `project-summary` skill in **deck mode** on this brainstorm:\n`project-summary {co}\u002F{slug} --brainstorm` (for personal\u002FHQ brainstorms the path is\n`personal\u002Fprojects\u002F{slug}` and it falls back to a password gate). It reads `brainstorm.md`,\nrenders a branded deck, deploys it company-gated via hq-deploy, and returns a live URL.\n\n**Runs once per session.** Run the deck deploy after the Step 7 gate, not before it. When the gate answer is `Stop here` or `Upgrade to deep-plan`, deploy the brainstorm deck as described here. When the gate answer is `Plan it now`, defer this deploy: the project summary deploy at the end of Step 8 covers the brainstorm and the PRD, and only that one link is reported.\n\nRules for this step:\n- **Visualization only** — it reads `brainstorm.md` and writes no project files; this does not\n  violate the \"brainstorm.md + board.json are the only files written\" rule (the deck is a\n  deploy artifact under `workspace\u002F`, not a project file).\n- **Non-fatal** — if the build or deploy fails (no HQ identity, offline, etc.), log a one-line\n  note and continue. The brainstorm must never be blocked by the deck deploy.\n- Capture the returned URL (or `skipped — {reason}`, or `deferred to plan phase`) and surface it in the final summary.\n\n## Step 7: Confirm & Reindex\n\nPrint:\n```\nBrainstorm: **{title}** ({id})\nFile: companies\u002F{co}\u002Fprojects\u002F{slug}\u002Fbrainstorm.md\n\nApproaches:\n  A. {Option A name} — {effort}\n  B. {Option B name} — {effort}\n  {C. Option C name — effort, if present}\n\nRecommendation: Option {X}\n```\n\nThe project folder is delegatable as it stands: `\u002Fdelegate \u003Cwho> {slug}` hands\nover `brainstorm.md`, `research\u002F`, and the latest journal entry, tells the\nrecipient there is no PRD yet, and points them at `\u002Fprd {slug}`. No `prd.json`\nis needed first.\n\nReindex: `qmd update 2>\u002Fdev\u002Fnull || true`\n\n### Plan gate\n\nAfter the confirm, ask one `AskUserQuestion` with exactly three options, in this order:\n\n1. `Plan it now` — add `(Recommended)` when the brainstorm recommends a single approach\n2. `Upgrade to deep-plan`\n3. `Stop here`\n\nHandle the answer:\n\n- **Plan it now**: continue to Step 8 in this session.\n- **Upgrade to deep-plan**: run the Step 6.6 deck deploy, then print `Next: \u002Fdeep-plan {co} {slug} (brainstorm: {brainstorm_path})` and stop. Do not write prd.json.\n- **Stop here**: run the Step 6.6 deck deploy, print the deck URL, and stop. Board status stays `brainstormed` (the Step 6 board entry is not advanced), and prd.json is not written.\n\n## Step 8: Plan Phase (only after the gate answers Plan it now)\n\nThe plan phase is the only part of this skill that writes prd.json. It reuses the `\u002Fprd` interview and finalize steps so the user does not re-answer questions.\n\n1. **Interview.** Run the grilling engine with `question_set: .claude\u002Fskills\u002F_shared\u002Fquestions\u002Fprd.md`, `mode: one-at-a-time`, and `known_facts` loaded from the Phase B answers: every `Q-id: answer` line in brainstorm.md whose id exists in the PRD question set, plus answers the PRD set's `prefill:` hints take from brainstorm.md (Context, Recommendation, rejected approaches). Do not re-ask loaded ids as confirmations.\n2. **Generate.** Write `{project_dir}\u002Fprd.json` and `{project_dir}\u002FREADME.md` following `\u002Fprd` Step 5 (`.claude\u002Fskills\u002Fprd\u002FSKILL.md`), including `metadata.interview` from the engine count object. Every item in the brainstorm's **Removal plan** becomes its own story (or acceptance criteria on the story that replaces it), with the removal check as its acceptance test. Carry the **External verification** pass condition into the PRD's acceptance criteria. Run `bash core\u002Fscripts\u002Fprd-interview-check.sh {project_dir}\u002Fprd.json` and show any warning.\n3. **Finalize.** Follow `.claude\u002Fskills\u002F_shared\u002Fprd-finalize.md` in order as caller `\u002Fprd`. Step 5.5 sets brainstorm.md frontmatter to `status: promoted` with `promoted_to: {project_dir}\u002Fprd.json`. Step 5.6 sets the board entry to `prd_created`. Step 5.7 syncs the stories onto the Work Mesh project that Step 1.5 already registered (policy `hq-work-mesh-prd-genesis`); do not skip it.\n4. **Deploy once.** Run the project summary deploy that policy `auto-deploy-project-summary-on-brainstorm-prd` requires for a finished PRD (`project-summary {co}\u002F{slug}`). This one deploy covers the brainstorm and the PRD, because Step 6.6 was deferred. Report only this link.\n5. **Confirm.** Print the `\u002Fprd` Step 9 summary and stop. Do not start execution.\n\n## Phases\n\n| Phase | Steps | Files written |\n|-------|-------|---------------|\n| A (research) | 0 to 2, 4 | `{project_dir}\u002Fresearch\u002F*.md` |\n| B (interview) | 3 | none; answers go into brainstorm.md in Phase C |\n| C (brainstorm) | 5 to 7 | `brainstorm.md`, `board.json`, journal |\n| Plan | 8 | `prd.json`, `README.md`, `board.json`, brainstorm.md frontmatter |\n\n## Final step — auto-checkpoint \u003C!-- AUTO-CHECKPOINT-ON-COMPLETION -->\n\nOnce the gate is answered and its branch has finished, automatically save a lightweight checkpoint so the user can continue in a fresh session without a manual `\u002Fhandoff`. This only **snapshots** continuity — it does **not** close the brainstorm (which stays open across `\u002Fprd`).\n\nWrite `workspace\u002Fthreads\u002FT-{UTC YYYYMMDD-HHMMSS}-auto-brainstorm-{slug}.json` with: `thread_id`, `version: 1`, `type: \"auto-checkpoint\"`, `created_at`, `updated_at`, `workspace_root`, `cwd`, `git: { branch, current_commit, dirty }`, `conversation_summary` (topic + recommended option, one sentence), `files_touched` (include the `brainstorm.md` path, and `prd.json` and `README.md` when Step 8 ran), `phases` (a map from each touched file to the phase that produced it: `A`, `B`, `C`, or `plan`, as listed in the Phases table), `gate_answer` (`Plan it now`, `Upgrade to deep-plan`, or `Stop here`), `next_steps` (e.g. \"promote to PRD with `\u002Fprd`, or refine `brainstorm.md`\"), and `metadata: { title: \"Auto: brainstorm {slug}\", tags: [\"auto-checkpoint\", \"brainstorm\"], trigger: \"brainstorm-complete\" }`.\n\nKeep it cheap: do **not** rebuild INDEX, update `recent.md`, run `qmd update`, or write a legacy checkpoint. Then tell the user a fresh session can resume from this checkpoint (`\u002Fstartwork`).\n\n## Rules\n\n- **Scan HQ before asking anything** — research phase (Step 2) happens before the first question. Never ask for info findable in qmd, board.json, or policies\n- **Sweep for overlap every time** — no brainstorm skips the Overlap & Cruft Sweep. A recommendation that builds something HQ or the company already has is a defect\n- **Removals are verified, not assumed** — each removal candidate carries evidence (last change, live references, superseded-by) and the user's `Q-retire` confirmation before it enters the plan\n- **Quality over effort** — never recommend an option because it is less code or quicker to build. Code is cheap with coding agents; runtime cost, fragility, and lock-in are not\n- **Fresh sources for fast-moving facts** — tool, model, API, and pricing claims cite a primary source from the last 60 days, or are labelled stale or unverified\n- **One question AT A TIME, not one total** — the gate and every interview question is its own `AskUserQuestion` call (decision-queue style per `decision-queue-one-at-a-time`). Ask every unresolved field; skip any already clear from args\u002Fresearch. Never batch multiple decisions into a single combined question, and never collapse the full interview to a single question. 4–8 questions is a normal interview\n- **2-3 approaches, no more** — present distinct options, not variations. If only one reasonable path exists, say so and explain why\n- **State a recommendation** — \"it depends\" without a stated override condition is not a recommendation\n- **No execution** — brainstorm.md is the output. Do NOT write code, scaffold repos, or modify any implementation files\n- **Phases A through C never write prd.json; only the plan phase does, after the gate** — Step 8 runs only when the gate answers `Plan it now`\n- **No Linear sync** — brainstorms are pre-planning. Linear happens at PRD time\n- **No orchestrator registration** — brainstorms are not executable\n- **Research is stored, not ephemeral** — every substantive research pass writes a note under `{project_dir}\u002Fresearch\u002F`, linked from brainstorm.md. Live web research is default-on for external-facing ideas; skip only for purely internal tooling on well-known platforms\n- **board.json + brainstorm.md + research\u002F notes are the only project files written in Phases A through C** (the plan phase adds prd.json and README.md) — plus the final auto-checkpoint thread under `workspace\u002Fthreads\u002F` (see \"Final step — auto-checkpoint\"). No implementation\u002Ftarget files are modified (knowledge pulse runs as a background agent and writes its own report independently)\n- **T-shirt effort, not story points** — sized by scope\u002Frisk, not calendar time: S (one seam), M (one subsystem), L (multiple seams + unknowns), XL (cross-cutting, hard-to-reverse). See policy `ai-velocity-time-sense`\n- **Company isolation enforced** — if anchored, scope all searches to that company. Never mix company knowledge in approaches\n- **brainstorm.md is human-editable** — the user may refine it after generation. The PRD skill reads whatever is in the file, not just what was machine-generated\n- **Do not create README.md** — brainstorm.md is self-contained\n- **Anti-sycophancy** — Never say \"that's interesting,\" \"great idea,\" \"excellent question.\" Take a position immediately. If the premise is weak, say so before exploring approaches. State which approach you'd actually build and why. Brainstorm is for honest analysis, not validation\n\n## See also\n\n- `\u002Fprd` — turn the chosen approach into a PRD\n- `\u002Fidea` — capture it on the board first\n- `\u002Fwayfinder` — when the effort is too big for one brainstorm and the destination is foggy; brainstorm is its grilling engine. Interview + stored-research pattern adapted from [mattpocock\u002Fskills](https:\u002F\u002Fgithub.com\u002Fmattpocock\u002Fskills)\n",{"name":5,"description":7,"allowed-tools":48},"Read, Write, Edit, Grep, Glob, Bash(git:*), Bash(qmd:*), Bash(ls:*), Bash(date:*), Task, Bash(bash core\u002Fscripts\u002Fwork-mesh-live-bind-trusted.sh:*), Bash(bash core\u002Fscripts\u002Fwork-mesh-project-registration-offer.sh:*), Bash(bash core\u002Fscripts\u002Fregister-project.sh:*), Bash, AskUserQuestion, WebSearch, Bash(bash core\u002Fscripts\u002Fread-policy-frontmatter.sh:*), Bash(bash core\u002Fscripts\u002Fboard-project-id.sh:*)","main","205cf61728a27ef15e9153aa38df5856fc8d82f5",".claude\u002Fskills\u002Fbrainstorm",18,"https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core","https:\u002F\u002Fgithub.com\u002Findigoai-us","https:\u002F\u002Fhqforwork.com\u002F","The AI Context Layer for Teams","2026-11-09 23:36:37",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add indigoai-us\u002Fhq-core --skill brainstorm",{"tool":64,"command":65},"bunx","bunx skills add indigoai-us\u002Fhq-core --skill brainstorm",{"tool":67,"command":68},"pnpm","pnpm dlx skills add indigoai-us\u002Fhq-core --skill brainstorm","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fbrainstorm\u002FSKILL.md",true,[72],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"agents\u002Fopenai.yaml","REFERENCE","参考文档",124,"https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fbrainstorm\u002Fagents\u002Fopenai.yaml",[79,97,125,146,157,167],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":43},"01M71E4MQ04WPK1EVDS7VKJ3E8","social-graphic","Generate 1080x1080 HTML social graphics for HQ update posts.","https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002Fcore\u002Fworkers\u002Fpublic\u002Fsocial-strategist\u002Fskills\u002Fsocial-graphic\u002FSKILL.md",[],[86,87,36,88,30,31,32,89,90,91,92,93,94,95,96],"social","social graphic","html","update","generate","graphics","browser","open","agent-browser","for","posts",{"skillNo":98,"name":94,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":108,"publishedAt":43},"01M71E4H33K4P5H5M7ENPTMFSC","Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to \"open a website\", \"fill out a form\", \"click a button\", \"take a screenshot\", \"scrape data from a page\", \"test this web app\", \"login to a site\", \"automate browser actions\", or any task requiring programmatic web interaction.","https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002Fcore\u002Fworkers\u002Fpublic\u002Fqa-tester\u002Fskills\u002Fagent-browser\u002FSKILL.md",[102,105],{"categoryNo":103,"categoryName":104,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":106,"categoryName":107,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[109,92,110,111,112,113,36,114,115,116,117,118,93,119,94,120,121,122,123,124],"agent browser","click","ai agents","app","scrape","when","apps","actions","extracting","take a screenshot","testing","programmatic","browser automation","website","cli","interaction",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":43},"01M71E4FDBD7J8Y45JJ9KMMYGN","work-mesh","Work Mesh Live — automatic presence via hq mesh daemon; context reconcile\u002Forganize; manual session task-status, blocked, and note only.","https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fwork-mesh\u002FSKILL.md",[],[132,34,40,36,133,134,135,27,136,137,138,139,140,141,32,142,143,144,145],"work mesh","status","context","note","presence","automatic","reconcile","only","organize","task","session","manual","daemon","via",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":43},"01M71E4EGHNAAGWAPV6KGBMQ9W","review","Parity worker review skill (materialization fixture).","https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002Fcore\u002Fscripts\u002Ftests\u002Ffixtures\u002Fagent-session\u002Fworker-materialization\u002Fparity-worker\u002Fskills\u002Freview\u002FSKILL.md",[],[148,153,154,155,156],"review skill","fixture","parity","worker",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":163,"publishedAt":43},"01M71E4D1FZDJPDC15DRERKX8Y","run","Run or list HQ workers (parity fixture).","https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002Fcore\u002Fscripts\u002Ftests\u002Ffixtures\u002Fagent-session\u002Fskills\u002Frun\u002FSKILL.md",[],[159,164,165,155,166,154],"parity fixture","workers","list",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":173,"publishedAt":43},"01M71E4BF4MV5SEWZJZ4T1QPQW","handoff","Preserve session state for a follow-up agent (parity fixture).","https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002Fcore\u002Fscripts\u002Ftests\u002Ffixtures\u002Fagent-session\u002Fskills\u002Fhandoff\u002FSKILL.md",[],[169,164,174,175,142,176,95,155,177,178,154],"up","preserve","session state","follow-up","state"]