[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71GJS87JCDFPZM6TV8FYP8F":3,"skill-same:01M71GJS87JCDFPZM6TV8FYP8F":103},{"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":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":6,"updatedAt":59,"install":60,"resources":72},"01M71GJS87JCDFPZM6TV8FYP8F","guild-brainstorm",null,"Socratic clustered-question flow that turns a vague user brief into an approved `.guild\u002Fspec\u002F\u003Cslug>.md`. Captures the seven planning-contract fields — goal, audience, success criteria, non-goals, constraints, autonomy policy, and known risks\u002Frollback — plus an eighth assumptions-vs-blocking-unknowns roll-up. TRIGGER on \"let's plan X\", \"help me scope this feature\", \"what are we actually building\", \"start a new Guild task\", \"I have a vague idea for …\", or any `\u002Fguild` invocation with a brief shorter than the planning-contract checklist. Supports a `--skip` escape hatch (for users who already have a clear spec); in that mode the skill validates the supplied spec and flags gaps instead of asking the full question set. DO NOT TRIGGER for implementation requests (hand off to `guild:execute-plan`), team composition (hand off to `guild:team-compose`), direct code or file edits, or micro-tasks like typo fixes and branch pushes.","lookatitude\u002Fguild","lookatitude","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F524917?v=4","01M71GJ2KGXFSJZKAZC5P1ZXXM","Miguel Pinto","01M71GJ2MH4SH9WJKP8M7XZZ0P",8,"MIT","https:\u002F\u002Fgithub.com\u002Flookatitude\u002Fguild\u002Fblob\u002Fmain\u002Fskills\u002Fmeta\u002Fbrainstorm\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"guild","guild brainstorm","brainstorm","hand","team","vague","tasks","code","when","question","new","up","Meta","mode","\u003Cslug>","scope","Composition","branch","brief","SET","2026-11-10 10:12:30",false,"---\nname: guild-brainstorm\ndescription: Socratic clustered-question flow that turns a vague user brief into an approved `.guild\u002Fspec\u002F\u003Cslug>.md`. Captures the seven planning-contract fields — goal, audience, success criteria, non-goals, constraints, autonomy policy, and known risks\u002Frollback — plus an eighth assumptions-vs-blocking-unknowns roll-up. TRIGGER on \"let's plan X\", \"help me scope this feature\", \"what are we actually building\", \"start a new Guild task\", \"I have a vague idea for …\", or any `\u002Fguild` invocation with a brief shorter than the planning-contract checklist. Supports a `--skip` escape hatch (for users who already have a clear spec); in that mode the skill validates the supplied spec and flags gaps instead of asking the full question set. DO NOT TRIGGER for implementation requests (hand off to `guild:execute-plan`), team composition (hand off to `guild:team-compose`), direct code or file edits, or micro-tasks like typo fixes and branch pushes.\nwhen_to_use: First step of the `\u002Fguild` lifecycle. Fires when a user invokes `\u002Fguild` with a vague brief, or when a specialist downstream needs the user's intent clarified before `guild:team-compose` can run.\ntype: meta\nindexed: true\n---\n\n# guild:brainstorm\n\nThis is the first step of every `\u002Fguild` task — ambiguity is front-loaded here so downstream specialists work from a single, approved spec instead of re-asking the user across every handoff. The spec produced here is the planning contract all downstream skills consume.\n\n## What you do\n\nRun a short Socratic conversation organized into **clusters** — not a flat questionnaire. Each cluster groups related §8.1 fields so the user answers one coherent set at a time (e.g. goal + audience + outcome together, constraints + autonomy + risks together). Reflect back each cluster in one sentence before moving on, so the user can correct drift early. When every §8.1 field has a confirmed answer (or an explicit assumption), write `.guild\u002Fspec\u002F\u003Cslug>.md` and hand off to `guild:team-compose`.\n\n## Knowledge-binding — min-build resolver (run FIRST, deterministic)\n\nIdeation's required upstream is an init wiki. Before the Socratic flow, run the\n**deterministic** resolver — never eyeball whether init ran:\n\n```bash\nnode ${GUILD_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-$HOME\u002F.local\u002Fshare\u002Fguild\u002Fdist\u002Fclaude-code}}\u002Fruntime\u002Fscripts\u002Fideation-min-build-cli.js --cwd \"$(pwd)\" [--description \"\u003Cone-line brief>\"]\n```\n\n- `{\"needsMinBuild\": false}` → an init wiki exists; proceed normally.\n- `{\"needsMinBuild\": true, \"spec\": …, \"frontmatter\": …}` → **no init wiki**. Do\n  **not** refuse and do **not** silently invent project knowledge. Instead, this\n  is the `build-minimal` continuity case (lifecycle §\"A min-build spec\"): seed\n  the spec from the resolver baseline (its `goal`\u002F`audience`\u002F`constraints` are\n  clearly-marked placeholders to confirm with the user during the clusters), and\n  **stamp the spec frontmatter** with the returned `frontmatter` block —\n  `grounded_in: init_minimal`, `resolver_built: true`, the `gap` notice, and\n  `resolved_at`. **Surface the `gap` to the user verbatim** (\"this spec was\n  resolver-built and lacks real project knowledge; run `\u002Fguild:init` to replace\n  it\"). The G-knowledge-binding step is non-blocking — it marks the missing-init\n  risk, it does not stop ideation. A later `\u002Fguild:init` replaces the baseline; it\n  is never a silent substitute for real project knowledge.\n\n## Required capture (per §8.1)\n\nThe spec is not approved until every item below is either answered or explicitly converted to an assumption:\n\n1. **Goal and user-visible outcome** — what changes for the end user when this is done.\n2. **Target audience or operator** — who experiences the outcome or runs the artifact.\n3. **Success criteria and acceptance tests** — measurable conditions the task must meet. Vague vibes (\"feels better\") are rejected.\n4. **Non-goals** — explicit list of things the task is *not* doing, to stop scope creep downstream.\n5. **Constraints** — time, budget, stack, platform, legal\u002Fcompliance, brand, security. Anything that bounds the solution space.\n6. **Autonomy policy** — what Guild may do without asking, what requires confirmation, what is forbidden. This becomes the specialists' permission contract.\n7. **Known risks and rollback\u002Frelease expectations** — what could go wrong and how the user expects to back out if it does.\n8. **Assumptions vs. blocking unknowns** — per §8.1, blocking unknowns must be answered or explicitly converted into assumptions recorded in `.guild\u002Fruns\u002F\u003Crun-id>\u002Fassumptions.md`. Low-significance uncertainty also goes in that file for end-of-task review.\n\n## Output contract\n\nWrite `.guild\u002Fspec\u002F\u003Cslug>.md` with YAML frontmatter + a markdown body. Minimal template:\n\n```markdown\n---\ntype: spec\nowner: orchestrator\nconfidence: medium\nsource_refs: []\ncreated_at: 2026-04-24\nupdated_at: 2026-04-24\n---\n\n# \u003CTask title>\n\n## Goal & outcome\n\u003Cone or two sentences>\n\n## Audience \u002F operator\n\u003Cwho>\n\n## Success criteria\n- \u003Cmeasurable criterion 1>\n- \u003Cmeasurable criterion 2>\n\n## Non-goals\n- \u003Cexplicit out-of-scope 1>\n\n## Constraints\n- time: \u003C...>\n- stack: \u003C...>\n- legal\u002Fbrand\u002Fsecurity: \u003C...>\n\n## Autonomy policy\n- may act without asking: \u003C...>\n- requires confirmation: \u003C...>\n- forbidden: \u003C...>\n\n## Risks & rollback\n- \u003Crisk> → \u003Crollback plan>\n\n## Assumptions (from brainstorm)\n- \u003Cassumption, with \"user explicitly agreed\" or \"inferred, low-significance\">\n```\n\nBlocking unknowns: if the user explicitly chooses to convert a blocking unknown into an assumption rather than answer it, record it in both the spec's **Assumptions** section *and* `.guild\u002Fruns\u002F\u003Crun-id>\u002Fassumptions.md` so it surfaces at `guild:verify-done`. Frontmatter `confidence` drops to `low` whenever ≥ 1 blocking unknown is assumed-through.\n\n## --skip escape hatch\n\nIf the user invokes `\u002Fguild ... --skip` *and* supplies a spec (pasted text or a path), **do not run the Socratic flow**. Instead:\n\n1. Parse the supplied spec.\n2. Check each of the 8 capture items above. Missing items are listed back to the user in a single consolidated question — not a new full question flow.\n3. If the user confirms \"proceed anyway\" for any gap, record that gap as an assumption (see Output contract) and drop `confidence` to `low`.\n4. Write `.guild\u002Fspec\u002F\u003Cslug>.md` and hand off.\n\nRed flag: do **not** auto-fill missing fields from training-data priors. A missing field is either answered by the user in the consolidated follow-up, or recorded as an explicit assumption — never silently synthesized.\n\n## Adversarial review — G-spec (broker, when policy fires)\n\nG-spec is a **skill-internal gate** (`docs\u002Fv2\u002Fadversarial-review.html §Gate ownership`): it fires here inside `guild:brainstorm` at the spec→approval boundary, not from a command — which is why it doesn't appear in `build`'s skill row. Wire the **review broker** at this boundary, **not** `guild:codex-review` directly: the broker is the host-agnostic front door, and `guild:codex-review` survives only as the internal Codex adapter the broker dispatches to (`docs\u002Fv2\u002Fadversarial-review.html §The review broker`).\n\nAfter writing the spec and **before** asking the user for approval, invoke `guild:review-broker`:\n\n```\nSkill: guild-review-broker\nargs: gate=G-spec artifact_path=.guild\u002Fspec\u002F\u003Cslug>.md run_id=\u003Crun-id> author_host=\u003Crun author host>\n```\n\nThe broker is **policy-gated** (`docs\u002Fv2\u002Fadversarial-review.html §The review broker`): it fires only when `risk ≥ high`, `review: cross` \u002F `--review=cross` is set, or project config requires it — otherwise it resolves `status: \"skipped\"` and the gate passes with no reviewer. Self-build runs treat cross-host review as always-on. `author_host` is the host that produced the spec (resolved from the run-start preflight snapshot; `claude` on a Claude-hosted run).\n\nIf the broker returns `status: \"rework\"`, loop back to the spec revision flow with the findings as context. On `\"satisfied\"`, `\"skipped\"`, or `\"force_passed\"`, proceed to the user-approval question normally.\n\nThe gate runs between spec write and user-approval. It does not replace user approval — both must complete before handoff to `guild:team-compose`.\n\n**The reviewer slot is a phase participant — sequence the gate BEFORE the broker.** A cross-host G-spec reviewer is a dispatchable participant of the `ideate` phase (`participation_kind: reviewer_cross_host`), so its dispatch rides the phase's `guild.team_proposal.v2` → `guild.team_decision.v1` gate. Operational order inside this skill: (1) write the draft spec; (2) **resolve the broker policy first, without dispatching** — the fire\u002Fskip predicate (`risk ≥ high` \u002F `review: cross` \u002F `--review=cross` \u002F config; self-build = always-on) is a deterministic read of run posture + config, so evaluate it before composing anything: if it resolves to no-fire, record `status: \"skipped\"`, compose NO proposal, and go straight to spec user-approval (nothing dispatches); (3) if it fires, compose the **minimal ideate-phase proposal** (typically the single reviewer slot; `spec_ref` = the just-written draft spec bytes — an *early-phase* proposal per `guild:team-compose §\"Team decision gate\"`); (4) hold for the user's `approve`; (5) only then invoke the broker; (6) proceed to spec user-approval. The full spec-driven composition still happens later at `guild:team-compose` for the plan phase. An advisory\u002Freview label never bypasses the gate.\n\n## Learning checkpoint (step 7.5 — advisory, no new gate)\n\nAfter the G-spec review and before handoff, fire the per-phase LearningCheckpoint with `phase=ideation` and `.guild\u002Fspec\u002F\u003Cslug>.md` as `evidence_ref`. Invoke `guild:learning-checkpoint` to classify the already-written spec\u002Fassumptions into the 12-target verdict, then emit via the hook — the full call signature + `GUILD_PHASE` mapping are canonical in `skills\u002Fmeta\u002Freflect\u002Freferences\u002Flearning-checkpoint.md §\"How a phase skill fires the checkpoint\"` (do not re-spell). It rides this existing boundary, defaults to all-`none` (a near-zero-token no-op), asks no new prompt, and adds no new gate; non-`none` verdicts route only to `.guild\u002Freflections\u002F\u003Crun-id>.md`.\n\n## Handoff\n\nOnce the spec is written **and the user has explicitly approved it** (not just \"looks fine\" — the word \"approved\" or an equivalent affirmative), invoke `guild:team-compose` with the spec path as its argument. Do not continue into team composition on your own; `guild:team-compose` is a separate skill with its own responsibilities.\n\nHandoff receipt should list: `spec_path`, `assumptions_count`, `blocking_unknowns_converted` (boolean), and `confidence` from the spec frontmatter.\n\n## Chapters\n\nThree-stage disclosure (KTD25): this file is the assembler. Each row below is an\nL3 chapter that stays on disk until a request matches it. Compose by pointer —\nread the one chapter you were routed to, and never inline a chapter here.\n\n| Chapter | Covers |\n|---|---|\n| `references\u002Fio-contract.md` | reference material for this assembler |\n| `references\u002Floop-clarify.md` | F-1 adversarial pre-spec clarification driver — wraps `guild:brainstorm`, runs an architect↔researcher loop where the architect proposes scope and the researcher fact-checks, surfaces gaps, and either signals satisfaction with the literal sentinel `## NO MORE QUESTIONS` or returns more questions |\n| `references\u002Floop-mechanics.md` | reference material for this assembler |\n| `references\u002Fproduct-explore.md` | Product-loop EXPLORE producer — turns a vague product idea into a typed, fail-closed `guild.explore.v1` artifact before any engineering scoping |\n\n## Chapter pointers (resolve before you dispatch)\n\nThese names appear in the body as if they were skills. They are NOT — the\nT03 fold (KTD25\u002FKTD59) made each one an L3 chapter. Read `guild:\u003Cname>` below\nas \"load this file and run it in place\"; never try to dispatch it as a skill.\n\n| Named in this body | Lives under | Load |\n|---|---|---|\n| `guild:codex-review` | `review` | `..\u002Freview\u002Freferences\u002Fcodex-review.md` |\n| `guild:learning-checkpoint` | `reflect` | `..\u002Freflect\u002Freferences\u002Flearning-checkpoint.md` |\n| `guild:review-broker` | `review` | `..\u002Freview\u002Freferences\u002Freview-broker.md` |\n| `guild:verify-done` | `quality` | `..\u002F..\u002Fquality\u002Freferences\u002Fverify-done.md` |\n","# guild:brainstorm\n\nThis is the first step of every `\u002Fguild` task — ambiguity is front-loaded here so downstream specialists work from a single, approved spec instead of re-asking the user across every handoff. The spec produced here is the planning contract all downstream skills consume.\n\n## What you do\n\nRun a short Socratic conversation organized into **clusters** — not a flat questionnaire. Each cluster groups related §8.1 fields so the user answers one coherent set at a time (e.g. goal + audience + outcome together, constraints + autonomy + risks together). Reflect back each cluster in one sentence before moving on, so the user can correct drift early. When every §8.1 field has a confirmed answer (or an explicit assumption), write `.guild\u002Fspec\u002F\u003Cslug>.md` and hand off to `guild:team-compose`.\n\n## Knowledge-binding — min-build resolver (run FIRST, deterministic)\n\nIdeation's required upstream is an init wiki. Before the Socratic flow, run the\n**deterministic** resolver — never eyeball whether init ran:\n\n```bash\nnode ${GUILD_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-$HOME\u002F.local\u002Fshare\u002Fguild\u002Fdist\u002Fclaude-code}}\u002Fruntime\u002Fscripts\u002Fideation-min-build-cli.js --cwd \"$(pwd)\" [--description \"\u003Cone-line brief>\"]\n```\n\n- `{\"needsMinBuild\": false}` → an init wiki exists; proceed normally.\n- `{\"needsMinBuild\": true, \"spec\": …, \"frontmatter\": …}` → **no init wiki**. Do\n  **not** refuse and do **not** silently invent project knowledge. Instead, this\n  is the `build-minimal` continuity case (lifecycle §\"A min-build spec\"): seed\n  the spec from the resolver baseline (its `goal`\u002F`audience`\u002F`constraints` are\n  clearly-marked placeholders to confirm with the user during the clusters), and\n  **stamp the spec frontmatter** with the returned `frontmatter` block —\n  `grounded_in: init_minimal`, `resolver_built: true`, the `gap` notice, and\n  `resolved_at`. **Surface the `gap` to the user verbatim** (\"this spec was\n  resolver-built and lacks real project knowledge; run `\u002Fguild:init` to replace\n  it\"). The G-knowledge-binding step is non-blocking — it marks the missing-init\n  risk, it does not stop ideation. A later `\u002Fguild:init` replaces the baseline; it\n  is never a silent substitute for real project knowledge.\n\n## Required capture (per §8.1)\n\nThe spec is not approved until every item below is either answered or explicitly converted to an assumption:\n\n1. **Goal and user-visible outcome** — what changes for the end user when this is done.\n2. **Target audience or operator** — who experiences the outcome or runs the artifact.\n3. **Success criteria and acceptance tests** — measurable conditions the task must meet. Vague vibes (\"feels better\") are rejected.\n4. **Non-goals** — explicit list of things the task is *not* doing, to stop scope creep downstream.\n5. **Constraints** — time, budget, stack, platform, legal\u002Fcompliance, brand, security. Anything that bounds the solution space.\n6. **Autonomy policy** — what Guild may do without asking, what requires confirmation, what is forbidden. This becomes the specialists' permission contract.\n7. **Known risks and rollback\u002Frelease expectations** — what could go wrong and how the user expects to back out if it does.\n8. **Assumptions vs. blocking unknowns** — per §8.1, blocking unknowns must be answered or explicitly converted into assumptions recorded in `.guild\u002Fruns\u002F\u003Crun-id>\u002Fassumptions.md`. Low-significance uncertainty also goes in that file for end-of-task review.\n\n## Output contract\n\nWrite `.guild\u002Fspec\u002F\u003Cslug>.md` with YAML frontmatter + a markdown body. Minimal template:\n\n```markdown\n---\ntype: spec\nowner: orchestrator\nconfidence: medium\nsource_refs: []\ncreated_at: 2026-04-24\nupdated_at: 2026-04-24\n---\n\n# \u003CTask title>\n\n## Goal & outcome\n\u003Cone or two sentences>\n\n## Audience \u002F operator\n\u003Cwho>\n\n## Success criteria\n- \u003Cmeasurable criterion 1>\n- \u003Cmeasurable criterion 2>\n\n## Non-goals\n- \u003Cexplicit out-of-scope 1>\n\n## Constraints\n- time: \u003C...>\n- stack: \u003C...>\n- legal\u002Fbrand\u002Fsecurity: \u003C...>\n\n## Autonomy policy\n- may act without asking: \u003C...>\n- requires confirmation: \u003C...>\n- forbidden: \u003C...>\n\n## Risks & rollback\n- \u003Crisk> → \u003Crollback plan>\n\n## Assumptions (from brainstorm)\n- \u003Cassumption, with \"user explicitly agreed\" or \"inferred, low-significance\">\n```\n\nBlocking unknowns: if the user explicitly chooses to convert a blocking unknown into an assumption rather than answer it, record it in both the spec's **Assumptions** section *and* `.guild\u002Fruns\u002F\u003Crun-id>\u002Fassumptions.md` so it surfaces at `guild:verify-done`. Frontmatter `confidence` drops to `low` whenever ≥ 1 blocking unknown is assumed-through.\n\n## --skip escape hatch\n\nIf the user invokes `\u002Fguild ... --skip` *and* supplies a spec (pasted text or a path), **do not run the Socratic flow**. Instead:\n\n1. Parse the supplied spec.\n2. Check each of the 8 capture items above. Missing items are listed back to the user in a single consolidated question — not a new full question flow.\n3. If the user confirms \"proceed anyway\" for any gap, record that gap as an assumption (see Output contract) and drop `confidence` to `low`.\n4. Write `.guild\u002Fspec\u002F\u003Cslug>.md` and hand off.\n\nRed flag: do **not** auto-fill missing fields from training-data priors. A missing field is either answered by the user in the consolidated follow-up, or recorded as an explicit assumption — never silently synthesized.\n\n## Adversarial review — G-spec (broker, when policy fires)\n\nG-spec is a **skill-internal gate** (`docs\u002Fv2\u002Fadversarial-review.html §Gate ownership`): it fires here inside `guild:brainstorm` at the spec→approval boundary, not from a command — which is why it doesn't appear in `build`'s skill row. Wire the **review broker** at this boundary, **not** `guild:codex-review` directly: the broker is the host-agnostic front door, and `guild:codex-review` survives only as the internal Codex adapter the broker dispatches to (`docs\u002Fv2\u002Fadversarial-review.html §The review broker`).\n\nAfter writing the spec and **before** asking the user for approval, invoke `guild:review-broker`:\n\n```\nSkill: guild-review-broker\nargs: gate=G-spec artifact_path=.guild\u002Fspec\u002F\u003Cslug>.md run_id=\u003Crun-id> author_host=\u003Crun author host>\n```\n\nThe broker is **policy-gated** (`docs\u002Fv2\u002Fadversarial-review.html §The review broker`): it fires only when `risk ≥ high`, `review: cross` \u002F `--review=cross` is set, or project config requires it — otherwise it resolves `status: \"skipped\"` and the gate passes with no reviewer. Self-build runs treat cross-host review as always-on. `author_host` is the host that produced the spec (resolved from the run-start preflight snapshot; `claude` on a Claude-hosted run).\n\nIf the broker returns `status: \"rework\"`, loop back to the spec revision flow with the findings as context. On `\"satisfied\"`, `\"skipped\"`, or `\"force_passed\"`, proceed to the user-approval question normally.\n\nThe gate runs between spec write and user-approval. It does not replace user approval — both must complete before handoff to `guild:team-compose`.\n\n**The reviewer slot is a phase participant — sequence the gate BEFORE the broker.** A cross-host G-spec reviewer is a dispatchable participant of the `ideate` phase (`participation_kind: reviewer_cross_host`), so its dispatch rides the phase's `guild.team_proposal.v2` → `guild.team_decision.v1` gate. Operational order inside this skill: (1) write the draft spec; (2) **resolve the broker policy first, without dispatching** — the fire\u002Fskip predicate (`risk ≥ high` \u002F `review: cross` \u002F `--review=cross` \u002F config; self-build = always-on) is a deterministic read of run posture + config, so evaluate it before composing anything: if it resolves to no-fire, record `status: \"skipped\"`, compose NO proposal, and go straight to spec user-approval (nothing dispatches); (3) if it fires, compose the **minimal ideate-phase proposal** (typically the single reviewer slot; `spec_ref` = the just-written draft spec bytes — an *early-phase* proposal per `guild:team-compose §\"Team decision gate\"`); (4) hold for the user's `approve`; (5) only then invoke the broker; (6) proceed to spec user-approval. The full spec-driven composition still happens later at `guild:team-compose` for the plan phase. An advisory\u002Freview label never bypasses the gate.\n\n## Learning checkpoint (step 7.5 — advisory, no new gate)\n\nAfter the G-spec review and before handoff, fire the per-phase LearningCheckpoint with `phase=ideation` and `.guild\u002Fspec\u002F\u003Cslug>.md` as `evidence_ref`. Invoke `guild:learning-checkpoint` to classify the already-written spec\u002Fassumptions into the 12-target verdict, then emit via the hook — the full call signature + `GUILD_PHASE` mapping are canonical in `skills\u002Fmeta\u002Freflect\u002Freferences\u002Flearning-checkpoint.md §\"How a phase skill fires the checkpoint\"` (do not re-spell). It rides this existing boundary, defaults to all-`none` (a near-zero-token no-op), asks no new prompt, and adds no new gate; non-`none` verdicts route only to `.guild\u002Freflections\u002F\u003Crun-id>.md`.\n\n## Handoff\n\nOnce the spec is written **and the user has explicitly approved it** (not just \"looks fine\" — the word \"approved\" or an equivalent affirmative), invoke `guild:team-compose` with the spec path as its argument. Do not continue into team composition on your own; `guild:team-compose` is a separate skill with its own responsibilities.\n\nHandoff receipt should list: `spec_path`, `assumptions_count`, `blocking_unknowns_converted` (boolean), and `confidence` from the spec frontmatter.\n\n## Chapters\n\nThree-stage disclosure (KTD25): this file is the assembler. Each row below is an\nL3 chapter that stays on disk until a request matches it. Compose by pointer —\nread the one chapter you were routed to, and never inline a chapter here.\n\n| Chapter | Covers |\n|---|---|\n| `references\u002Fio-contract.md` | reference material for this assembler |\n| `references\u002Floop-clarify.md` | F-1 adversarial pre-spec clarification driver — wraps `guild:brainstorm`, runs an architect↔researcher loop where the architect proposes scope and the researcher fact-checks, surfaces gaps, and either signals satisfaction with the literal sentinel `## NO MORE QUESTIONS` or returns more questions |\n| `references\u002Floop-mechanics.md` | reference material for this assembler |\n| `references\u002Fproduct-explore.md` | Product-loop EXPLORE producer — turns a vague product idea into a typed, fail-closed `guild.explore.v1` artifact before any engineering scoping |\n\n## Chapter pointers (resolve before you dispatch)\n\nThese names appear in the body as if they were skills. They are NOT — the\nT03 fold (KTD25\u002FKTD59) made each one an L3 chapter. Read `guild:\u003Cname>` below\nas \"load this file and run it in place\"; never try to dispatch it as a skill.\n\n| Named in this body | Lives under | Load |\n|---|---|---|\n| `guild:codex-review` | `review` | `..\u002Freview\u002Freferences\u002Fcodex-review.md` |\n| `guild:learning-checkpoint` | `reflect` | `..\u002Freflect\u002Freferences\u002Flearning-checkpoint.md` |\n| `guild:review-broker` | `review` | `..\u002Freview\u002Freferences\u002Freview-broker.md` |\n| `guild:verify-done` | `quality` | `..\u002F..\u002Fquality\u002Freferences\u002Fverify-done.md` |\n",{"name":5,"type":49,"indexed":50,"description":7,"when_to_use":51},"meta",true,"First step of the `\u002Fguild` lifecycle. Fires when a user invokes `\u002Fguild` with a vague brief, or when a specialist downstream needs the user's intent clarified before `guild:team-compose` can run.","main","2e58b0360ca51ca3c96ca8e015ef5aba5738803d","skills\u002Fmeta\u002Fbrainstorm",0,"https:\u002F\u002Fgithub.com\u002Flookatitude\u002Fguild","https:\u002F\u002Fgithub.com\u002Flookatitude","https:\u002F\u002Flookatitude.com","2026-11-06 03:55:18",{"source":8,"skillName":5,"commands":61,"prompt":71,"zipAvailable":50},[62,65,68],{"tool":63,"command":64},"npx","npx skills add lookatitude\u002Fguild --skill guild-brainstorm",{"tool":66,"command":67},"bunx","bunx skills add lookatitude\u002Fguild --skill guild-brainstorm",{"tool":69,"command":70},"pnpm","pnpm dlx skills add lookatitude\u002Fguild --skill guild-brainstorm","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Flookatitude\u002Fguild\u002Fblob\u002Fmain\u002Fskills\u002Fmeta\u002Fbrainstorm\u002FSKILL.md",[73,79,83,87,91,95,99],{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"evals.json","REFERENCE","参考文档",966,"https:\u002F\u002Fgithub.com\u002Flookatitude\u002Fguild\u002Fblob\u002Fmain\u002Fskills\u002Fmeta\u002Fbrainstorm\u002Fevals.json",{"path":80,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fio-contract.md",2102,"https:\u002F\u002Fgithub.com\u002Flookatitude\u002Fguild\u002Fblob\u002Fmain\u002Fskills\u002Fmeta\u002Fbrainstorm\u002Freferences\u002Fio-contract.md",{"path":84,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":85,"sourceHtmlUrl":86},"references\u002Floop-clarify.evals.json",573,"https:\u002F\u002Fgithub.com\u002Flookatitude\u002Fguild\u002Fblob\u002Fmain\u002Fskills\u002Fmeta\u002Fbrainstorm\u002Freferences\u002Floop-clarify.evals.json",{"path":88,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Floop-clarify.md",7217,"https:\u002F\u002Fgithub.com\u002Flookatitude\u002Fguild\u002Fblob\u002Fmain\u002Fskills\u002Fmeta\u002Fbrainstorm\u002Freferences\u002Floop-clarify.md",{"path":92,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":93,"sourceHtmlUrl":94},"references\u002Floop-mechanics.md",6666,"https:\u002F\u002Fgithub.com\u002Flookatitude\u002Fguild\u002Fblob\u002Fmain\u002Fskills\u002Fmeta\u002Fbrainstorm\u002Freferences\u002Floop-mechanics.md",{"path":96,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":97,"sourceHtmlUrl":98},"references\u002Fproduct-explore.evals.json",859,"https:\u002F\u002Fgithub.com\u002Flookatitude\u002Fguild\u002Fblob\u002Fmain\u002Fskills\u002Fmeta\u002Fbrainstorm\u002Freferences\u002Fproduct-explore.evals.json",{"path":100,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":101,"sourceHtmlUrl":102},"references\u002Fproduct-explore.md",5398,"https:\u002F\u002Fgithub.com\u002Flookatitude\u002Fguild\u002Fblob\u002Fmain\u002Fskills\u002Fmeta\u002Fbrainstorm\u002Freferences\u002Fproduct-explore.md",[104,116,126,144,162,173],{"skillNo":105,"name":106,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":44},"01M71GQQ1ZAND0XQBS4GTSWYFK","technical-writer-user-manual","https:\u002F\u002Fgithub.com\u002Flookatitude\u002Fguild\u002Fblob\u002Fmain\u002Fskills\u002Fspecialists\u002Ftechnical-writer-user-manual\u002FSKILL.md",[],[110,111,112,113,114,115],"writer","technical","technical writer","technical writer user manual","manual","user",{"skillNo":117,"name":118,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":121,"publishedAt":44},"01M71GQMQ71DQNH4A7REXRVFCB","technical-writer-release-notes","https:\u002F\u002Fgithub.com\u002Flookatitude\u002Fguild\u002Fblob\u002Fmain\u002Fskills\u002Fspecialists\u002Ftechnical-writer-release-notes\u002FSKILL.md",[],[122,110,123,124,125,111,112],"release","notes","technical writer release notes","release notes",{"skillNo":127,"name":128,"nameZh":6,"description":6,"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":139,"publishedAt":44},"01M71GQJQT9G8QHE0A9SN01VE4","technical-writer-api-docs","https:\u002F\u002Fgithub.com\u002Flookatitude\u002Fguild\u002Fblob\u002Fmain\u002Fskills\u002Fspecialists\u002Ftechnical-writer-api-docs\u002FSKILL.md",[131,136],{"categoryNo":132,"categoryName":133,"taxonomyType":134,"taxonomyTypeDesc":135},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":137,"categoryName":138,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师",[140,111,112,141,142,143,110],"technical writer api docs","docs","api docs","api",{"skillNo":145,"name":146,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":155,"publishedAt":44},"01M71GQH3T5F23M2M298WXVAQ5","social-media-platform-post","https:\u002F\u002Fgithub.com\u002Flookatitude\u002Fguild\u002Fblob\u002Fmain\u002Fskills\u002Fspecialists\u002Fsocial-media-platform-post\u002FSKILL.md",[149,152],{"categoryNo":150,"categoryName":151,"taxonomyType":134,"taxonomyTypeDesc":135},"01JBSEEDCAT000000000000019","营销推广",{"categoryNo":153,"categoryName":154,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000035","市场营销",[156,157,158,159,160,161],"social media platform post","post","Media","platform","social","social media",{"skillNo":163,"name":164,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":169,"publishedAt":44},"01M71GQFS4MJ4S8ZRK7KQNNPJE","social-media-engagement-templates","https:\u002F\u002Fgithub.com\u002Flookatitude\u002Fguild\u002Fblob\u002Fmain\u002Fskills\u002Fspecialists\u002Fsocial-media-engagement-templates\u002FSKILL.md",[167,168],{"categoryNo":150,"categoryName":151,"taxonomyType":134,"taxonomyTypeDesc":135},{"categoryNo":153,"categoryName":154,"taxonomyType":21,"taxonomyTypeDesc":22},[160,170,158,171,172,161],"engagement","social media engagement templates","templates",{"skillNo":174,"name":175,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":183,"publishedAt":44},"01M71GQEPZ5GX6NBFQ9H0W5E0C","social-media-content-calendar","https:\u002F\u002Fgithub.com\u002Flookatitude\u002Fguild\u002Fblob\u002Fmain\u002Fskills\u002Fspecialists\u002Fsocial-media-content-calendar\u002FSKILL.md",[178,179,180],{"categoryNo":150,"categoryName":151,"taxonomyType":134,"taxonomyTypeDesc":135},{"categoryNo":153,"categoryName":154,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":181,"categoryName":182,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000036","内容创作者",[184,185,160,161,186,187,158],"calendar","content calendar","social media content calendar","content"]