{"id":"0fb74c11-6853-44db-9326-2af0a40a94e8","entityType":"agent","slug":"clawhub-iliaal-compound-eng-brainstorming","name":"ia-brainstorming","canonicalUrl":"https://www.xpersona.co/agent/clawhub-iliaal-compound-eng-brainstorming","canonicalPath":"/agent/clawhub-iliaal-compound-eng-brainstorming","generatedAt":"2026-10-09T19:55:10.251Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-09T13:18:17.909Z","emptyReason":null},"description":"Pre-implementation exploration: deep interview, approach comparison, design doc. Use when exploring a vague feature idea, clarifying ambiguous requirements, or comparing approaches before coding. For the full workflow, use the ia-brainstorm command (Claude Code). Skill: ia-brainstorming Owner: iliaal Summary: Pre-implementation exploration: deep interview, approach comparison, design doc. Use when exploring a vague feature idea, clarifying ambiguous requirements, or comparing approaches before coding. For the full workflow, use the ia-brainstorm command (Claude Code). Tags: latest:5.0.1 Version history: v5.0.1 | 2026-10-03T17:02:37.068Z | user v5.0.1 v5.0.0 | 2026-09-26T23:29","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 2.6K downloads reported by the source. Last updated 10/9/2026.","installCommand":"clawhub skill install s17bcar8wq0xhegs0ny6f57ypd8484bw:compound-eng-brainstorming","sourceUrl":"https://clawhub.ai/iliaal/compound-eng-brainstorming","homepage":"https://clawhub.ai/iliaal/skills/compound-eng-brainstorming","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/iliaal/compound-eng-brainstorming","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/iliaal/skills/compound-eng-brainstorming","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":42,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Pre-implementation exploration: deep interview, approach comparison, design doc. Use when exploring a vague feature idea, clarifying ambiguous requirements, or "},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-09T13:18:17.909Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T13:18:17.909Z","emptyReason":null},"stars":null,"forks":null,"downloads":2576,"packageName":null,"latestVersion":"5.0.1","tractionLabel":"2.6K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T13:18:17.909Z","emptyReason":null},"lastUpdatedAt":"2026-10-09T13:18:17.909Z","lastCrawledAt":"2026-10-09T13:18:17.909Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-10T13:18:17.909Z","lastVerifiedAt":null,"highlights":[{"version":"5.0.1","createdAt":"2026-10-03T17:02:37.068Z","changelog":"v5.0.1","fileCount":8,"zipByteSize":17326},{"version":"5.0.0","createdAt":"2026-09-26T23:29:10.946Z","changelog":"v5.0.0","fileCount":8,"zipByteSize":17273},{"version":"4.5.3","createdAt":"2026-09-13T14:45:21.937Z","changelog":"v4.5.3","fileCount":8,"zipByteSize":17484},{"version":"4.5.2","createdAt":"2026-09-08T01:28:25.739Z","changelog":"v4.5.2","fileCount":8,"zipByteSize":17216},{"version":"4.4.3","createdAt":"2026-08-29T12:26:07.559Z","changelog":"v4.4.3","fileCount":5,"zipByteSize":14281},{"version":"4.3.2","createdAt":"2026-07-27T20:49:36.238Z","changelog":"v4.3.2","fileCount":5,"zipByteSize":14104},{"version":"4.3.1","createdAt":"2026-07-18T15:04:47.649Z","changelog":"v4.3.1","fileCount":5,"zipByteSize":14036},{"version":"4.2.1","createdAt":"2026-07-11T11:14:59.833Z","changelog":"v4.2.1","fileCount":5,"zipByteSize":13586}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17bcar8wq0xhegs0ny6f57ypd8484bw:compound-eng-brainstorming","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-iliaal-compound-eng-brainstorming/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-iliaal-compound-eng-brainstorming/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-iliaal-compound-eng-brainstorming/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-iliaal-compound-eng-brainstorming/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-iliaal-compound-eng-brainstorming/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-iliaal-compound-eng-brainstorming/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-09T19:55:10.248Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-iliaal-compound-eng-brainstorming/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-iliaal-compound-eng-brainstorming/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-iliaal-compound-eng-brainstorming/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-iliaal-compound-eng-brainstorming/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-09T13:18:17.909Z","emptyReason":null},"readme":"Skill: ia-brainstorming\n\nOwner: iliaal\n\nSummary: Pre-implementation exploration: deep interview, approach comparison, design doc. Use when exploring a vague feature idea, clarifying ambiguous requirements, or comparing approaches before coding. For the full workflow, use the ia-brainstorm command (Claude Code).\n\nTags: latest:5.0.1\n\nVersion history:\n\nv5.0.1 | 2026-10-03T17:02:37.068Z | user\n\nv5.0.1\n\nv5.0.0 | 2026-09-26T23:29:10.946Z | user\n\nv5.0.0\n\nv4.5.3 | 2026-09-13T14:45:21.937Z | user\n\nv4.5.3\n\nv4.5.2 | 2026-09-08T01:28:25.739Z | user\n\nv4.5.2\n\nv4.4.3 | 2026-08-29T12:26:07.559Z | user\n\nv4.4.3\n\nv4.3.2 | 2026-07-27T20:49:36.238Z | user\n\nv4.3.2\n\nv4.3.1 | 2026-07-18T15:04:47.649Z | user\n\nv4.3.1\n\nv4.2.1 | 2026-07-11T11:14:59.833Z | user\n\nv4.2.1\n\nv4.2.0 | 2026-07-07T18:35:38.973Z | user\n\nv4.2.0\n\nv4.0.3 | 2026-05-16T13:15:33.247Z | user\n\nv4.0.3\n\nv3.0.5 | 2026-04-30T00:01:34.020Z | user\n\nv3.0.5\n\nv3.0.4 | 2026-04-27T14:37:30.227Z | user\n\nv3.0.4\n\nv3.0.3 | 2026-04-24T12:32:25.735Z | user\n\nv3.0.3\n\nv3.0.2 | 2026-04-24T11:48:40.726Z | user\n\nv3.0.2\n\nv3.0.1 | 2026-04-24T11:29:22.952Z | user\n\nv3.0.1\n\nv3.0.0 | 2026-04-23T19:26:28.359Z | user\n\nv3.0.0\n\nv2.56.1 | 2026-04-18T13:28:43.900Z | user\n\nv2.56.1\n\nv2.56.0 | 2026-04-14T12:38:21.377Z | user\n\nv2.56.0\n\nv2.55.1 | 2026-04-12T14:29:02.887Z | user\n\nv2.55.1\n\nv2.55.0 | 2026-04-11T00:59:41.383Z | user\n\nv2.55.0\n\nv2.53.2 | 2026-04-08T14:19:20.496Z | user\n\nv2.53.2\n\nv2.53.0 | 2026-04-05T23:51:49.539Z | user\n\nv2.53.0\n\nArchive index:\n\nArchive v5.0.1: 8 files, 17326 bytes\n\nFiles: references/deep-interview.md (4978b), references/design-and-handoff.md (5056b), references/interview-and-approaches.md (6222b), references/scope-synthesis.md (5590b), skill-card.md (1899b), SKILL.md (5430b), SPEC.md (4659b), _meta.json (145b)\n\nFile v5.0.1:SKILL.md\n\n---\nname: ia-brainstorming\nclass: workflow\ndescription: >-\n  Pre-implementation exploration: deep interview, approach comparison, design\n  doc. Use when exploring a vague feature idea, clarifying ambiguous\n  requirements, or comparing approaches before coding. For the full workflow,\n  use the ia-brainstorm command (Claude Code).\n---\n\n# Brainstorming\n\nClarify what to build before planning how to implement it.\n\n## Scope and interaction\n\nProduce exploration and a design, not implementation. Obtain approval before interactive handoff. Enable headless mode only when the caller explicitly delegates non-interactive execution and its decision scope; `disable-model-invocation` is selection metadata, not approval. Replace headless confirmations with stated conservative assumptions. Return material decisions without a safe authorized default unresolved. Never label inferred choices user-approved or infer implementation, commit, or publication authority from this skill.\n\nUse the active question mechanism for material questions: AskUserQuestion in Claude Code (load via ToolSearch `select:AskUserQuestion` when needed), request_user_input in Codex where supported, otherwise chat. Return missing decisions to the parent from an unattended worker.\n\n## Process\n\n1. **Assess and ground.** For an existing project, read relevant code, documentation, constraints, and recent commits before questions. Surface contradictions between the request and observed behavior. Skip repository research for abstract topics. Brainstorm ambiguous goals, competing interpretations, unresolved trade-offs, uncertain needs, solution-framed requests, or multiple independent subsystems. If requirements are clear, suggest planning or implementation without forcing dialogue.\n2. **Right-size and decompose.** A brainstorm resolved in three messages may need only a summary; sustained architectural work needs a durable design. For multiple independent subsystems, identify boundaries and dependencies, choose build order, then give each sub-project its own design → plan → implementation cycle. Start with the first sub-project.\n3. **Understand and compare.** When dialogue or approach selection is needed, read [interview-and-approaches.md](./references/interview-and-approaches.md). Match the user's vocabulary. Normally ask one question across dimensions, or two to three within one dimension; for a substantial initial dump (>200 words), use the reference's bounded batch. Explore purpose, users, constraints, success, edge cases, patterns, and non-goals. Apply [deep-interview.md](./references/deep-interview.md) when assumptions, evidence, unfamiliar domains, or combined answers need probing; its integration check applies before interview exit. Stop questioning when clear or told to proceed. Summarize in three to five bullets and confirm in interactive mode.\n4. **Choose an approach.** Compare two to three concrete alternatives with descriptions, pros, cons, and best-use conditions. Lead with the recommendation, reference existing patterns, and expose trade-offs. If none is accepted after two rounds, ask for the preferred direction. For a wide design space, use two to three lenses from the approach reference. State the chosen approach's explicit Not Doing list and a validation method for every key assumption.\n5. **Confirm interpreted scope.** Before writing after substantive dialogue, read [scope-synthesis.md](./references/scope-synthesis.md). Separate stated requirements, inferred assumptions, and exclusions internally; present only the reference's concise scoping synthesis. Lightweight work without blocking questions uses announce-mode; Standard/Deep work or any blocking dialogue requires interactive confirmation. Re-present revisions and await confirmation. In headless mode preserve sources and unresolved assumptions without prompts. Clear requirements that skipped dialogue need no synthesis checkpoint.\n6. **Capture and self-review.** For a durable artifact, read [design-and-handoff.md](./references/design-and-handoff.md). Save `docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md` with date/topic frontmatter, What We're Building, Why This Approach, Key Decisions and rationale, Open Questions, and Next Steps. Collapse interview history in a details block. Describe each component's purpose, usage, dependencies, and testable boundary. Commit only within caller authority.\n7. **Handoff.** Preserve settled decisions and their rationale rather than repeatedly challenging them; a cold directive gets one approach challenge. Neither label suppresses concrete defect or infeasibility evidence. Require consistent terminology, concrete criteria, scope traceability, unambiguous decisions, explicit non-goals, assumption validation, and a named source for every produced value. Return failures to approach selection or drafting. Present the design for interactive approval; return caller-delegated decisions and unresolved assumptions in headless mode.\n\n## Completion\n\nReturn the scoped summary or saved design path, decisions, and open questions resolved or explicitly deferred with reasons. Interactive approval precedes handoff; a headless handoff remains within caller authority. Planning (`ia-planning`, or `/ia-plan` in Claude Code) follows design and reuses its settled requirements. For auth, payments, external APIs, or multi-tenant data, suggest an available security threat-model review before planning.\n\nFile v5.0.1:_meta.json\n\n{\n  \"ownerId\": \"kn715jrbbh71q9zncr0bqdkr8n848q1a\",\n  \"slug\": \"compound-eng-brainstorming\",\n  \"version\": \"5.0.1\",\n  \"publishedAt\": 1791046957068\n}\n\nFile v5.0.1:references/deep-interview.md\n\n# Deep Interview Layer\n\nApply the deep interview protocol on top of the baseline questions above. Assumption probing and contradiction tracking always run. Research-backed challenges and second-order effects run when the scope warrants it (multi-system changes, infrastructure decisions, technology selection).\n\n**Assumption probing:** After each substantive answer, identify what the user assumed but didn't state. \"You described X. Are you assuming Y is already in place?\" Surface hidden dependencies and unstated constraints.\n\n**Second-order effects:** For features that touch shared infrastructure or data models, ask what success creates downstream. \"If this works and gets adopted, what pressure does it put on [related system]?\"\n\n**Research-backed challenges:** Fire background research on technology choices and claims. When findings contradict, challenge directly with citation. When findings support, briefly confirm to build confidence in the decision.\n\n**Contradiction tracking:** If the user's answer contradicts something said earlier, flag it immediately: \"Earlier you said X, but this implies Y. Which takes priority?\"\n\n**Anti-requirements:** When the user rejects an approach or says \"definitely not X,\" capture the rejection and rationale inline with the related decision. Don't force this; capture organically when it surfaces.\n\n**Architecture-first ordering:** When several questions remain, ask the ones whose answers would change the *architecture* first: data model shape, service boundaries, sync vs. async, auth model, storage engine. A question whose answer only affects a label, copy string, or default value can wait or take a reasonable default. Front-loading architecture-changing questions means a redirect lands before the design is built around a wrong assumption, not after.\n\n**Question clustering:** When probing a single dimension (e.g., data model, auth flow), ask 2-3 related questions together using AskUserQuestion's multi-question support. Switch to one-at-a-time when jumping between dimensions.\n\n**Completeness assessment:** Track which dimensions have been explored. Before proposing to move to Phase 2, assess coverage and signal confidence: \"We've covered purpose, users, and constraints well. Data flow and failure modes are still thin. Want to explore those, or proceed?\"\n\n## Rigor Probes for Ambiguous Gaps\n\nWhen a user answer leaves a gap on evidence, specificity, counterfactual, or attachment, fire ONE open-ended probe per gap, *not* a multiple-choice menu (exception: territory the user can't evaluate, where menus are the right tool; see Blindspot Pass below). Menus signal which axes the agent thinks matter, biasing the user toward those axes; open-ended forces actual observation:\n\n- **Evidence:** \"What's the most concrete thing someone's already done about this? Paid for it, built a workaround, quit a tool over it?\"\n- **Specificity:** \"Can you name a team you've actually watched hit this, or are you reasoning?\"\n- **Counterfactual:** \"What do teams do today when this breaks? Who reconciles?\"\n- **Attachment:** \"What's the smallest version that would still prove the bet right, and what's excluded?\"\n\nInterleave with narrowing moves; do not stack multiple probes in one turn.\n\n## Blindspot Pass for Unfamiliar Territory\n\nWhen the user signals they *cannot evaluate* a domain, explicitly (\"I know nothing about auth\", \"no idea, you pick\") or implicitly (deferring the same judgment-domain question to the agent 2+ times), stop extracting guesses and map the decision surface for them instead.\n\nDistinguish **can't-evaluate** (no basis to choose) from **hasn't-decided** (has a basis, just hasn't picked). Only the first triggers this pass; a user who can weigh the options but is undecided gets the normal probes above. This guard keeps the pass from firing on every open question.\n\nScope the pass to the unfamiliar territory only, not the whole interview. List 3-7 decisions and hazards the user can't see, each with 2-3 concrete options and a recommended default, and present them with `AskUserQuestion` (load its schema via `ToolSearch select:AskUserQuestion` first if unavailable; in Codex use `request_user_input`; where no blocking tool exists, fall back to numbered options in chat) so the user chooses against real alternatives instead of the agent deciding silently. In a non-interactive context, treat the pass as declined and record the recommended defaults as explicit assumptions the user can override later.\n\n## Integration Check Before Phase 1 Exit\n\nBefore exiting Phase 1, mentally combine what the user has stated so far. If stated-A + stated-B + agent-default-C produces a downstream effect the user is unlikely to have tracked (e.g., \"if mute lives on the rule AND we don't warn on delete, rule-delete silently loses pause state\"), fire one open probe per genuine combination. Phase 2.5's call-outs are a safety net for residuals, *not* a punt list for consequences you should have surfaced here.\n\nFile v5.0.1:references/design-and-handoff.md\n\n# Design capture and handoff\n\nRead when writing or reviewing a durable design. The entry point’s authority boundary also applies to commits and handoff.\n\n### Phase 3: Capture the Design\n\nSummarize key decisions in a structured format. For each major component, verify isolation and clarity: it must answer \"what does it do, how do you use it, what does it depend on?\" and be independently understandable and testable. If working in an existing codebase, note which existing patterns to follow and where targeted improvements fit naturally.\n\n**Design Doc:** Save to `docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md`. Required sections: What We're Building, Why This Approach, Key Decisions (with rationale), Open Questions, Next Steps. Collapse the Q&A interview log in a `<details>` block. Include YAML frontmatter with `date` and `topic`. Commit to git; design decisions are project history.\n\n**Settled vs. directive: don't re-litigate.** A decision the user made with the alternative and its trade-off in view is **settled**: record it in Key Decisions with its rationale and carry it forward. Do not re-ask it in Phase 3b, at planning, or during work. A cold **directive** (a choice asserted without anyone weighing it, e.g. \"build it with X\") earns exactly **one** in-pipeline challenge (one pass of the Phase 2 ideation lenses against that specific choice), then it too is recorded and not re-challenged at every downstream stage. A settled label never suppresses defect evidence: a real bug or infeasibility found *inside* a settled approach keeps full severity and is surfaced.\n\n### Phase 3b: Spec Self-Review\n\nRun this checklist before presenting the design doc. Any failure returns to Phase 2 or Phase 3, not Phase 4.\n\n- **Placeholder scan**: no TBD, \"figure out later\", \"appropriate error handling\", bracketed gaps, or tasks without concrete criteria.\n- **Internal consistency**: names, types, and verbs match across sections (no `createOrder()` in one place and `placeOrder()` in another).\n- **Scope containment**: every decision traces back to a stated goal; otherwise cut or surface as explicit scope expansion.\n- **Ambiguity sweep**: each Key Decision survives \"could a reasonable implementer interpret this two ways?\"\n- **Assumption validation**: every assumption names its validation method (\"we assume X; we'll confirm by Y\").\n- **Value sourcing**: enumerate every value the work must produce, compute, or display, and confirm the spec names each one's source (an input param, a stored field, a derivation from a named value, or a prior decision). A produced value with no named source is an owed design decision; surface it, don't invent it. Judge by positive enumeration, not introspection: \"show the user's local day\" that never says where the timezone comes from passes every other check yet hides an undecided source.\n- **Non-goals present**: the explicit \"Not Doing\" list exists and is specific.\n\nSilent pass is valid. Clean draft → move to Phase 4.\n\n### Phase 4: Review and Handoff\n\nPresent the design doc to the user for approval. The user explicitly confirming the design is the gate to proceed. When invoked via `/ia-brainstorm`, the command handles spec review dispatch and next-step orchestration.\n\n**Explicit headless mode:** return the design and unresolved assumptions to the caller. Handoff may continue only within the caller's delegated authority; report the design as caller-delegated, not user-approved.\n\n## Anti-Patterns to Avoid\n\n| Anti-Pattern | Better Approach |\n|--------------|-----------------|\n| Asking 5 questions at once | Ask one at a time across dimensions; cluster 2-3 within a dimension |\n| Jumping to implementation details | Stay focused on WHAT, not HOW |\n| Proposing overly complex solutions | Start simple, add complexity only if needed |\n| Ignoring existing codebase patterns | Research what exists first |\n| Making assumptions without validating | State assumptions explicitly and confirm |\n| Creating lengthy design documents | Keep it concise--details go in the plan |\n\n## Success Criteria\n\n- Design doc saved to `docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md`\n- Interactive mode: user approves the spec before handoff. Explicit headless mode: caller-delegated decisions and remaining assumptions are identified.\n- All open questions resolved or explicitly deferred with rationale\n\n## Integration\n\nBrainstorming answers WHAT to build. Planning answers HOW. When brainstorm output exists, `/ia-plan` (Claude Code) or the ia-planning skill detects it and skips idea refinement.\n\n- **Next step:** planning, always (`/ia-plan` in Claude Code; the `ia-planning` skill elsewhere)\n- **Threat modeling:** when the brainstorm involves auth, payments, external API surfaces, or multi-tenant data, suggest a read-only threat-model review before planning. Use an available security reviewer through native delegation, or review inline if none is available; surface trust-boundary gaps and unresolved risks within the caller's scope.\n- **Predecessor:** user request or ambiguous feature description\n\nFile v5.0.1:references/interview-and-approaches.md\n\n# Interview and approach selection\n\nRead when requirements need dialogue or multiple approaches need comparison. Headless execution follows the entry point’s caller-delegated decision scope.\n\n### Phase 1: Understand the Idea\n\n**User context calibration (before diving into the idea):**\n\nRead signals from the user's first message to calibrate communication register:\n- **Vocabulary**: Are they using technical terms (API, schema, migration) or describing experiences (it's slow, it breaks when...)?\n- **Framing**: Are they describing a solution (\"build a dashboard\") or a problem (\"I can't see what's happening\")?\n- **References**: Are they pointing to code, files, and patterns, or to analogies and comparisons (\"something like Notion\")?\n\nAdjust question style accordingly. Technical users get architecture-level probing. Non-technical users get experience-level probing. Don't ask about this calibration; just do it. If signals are ambiguous, default to the vocabulary the user is already using.\n\n**Explore project context first:** Before asking questions, read existing files, docs, and recent commits related to the idea. Understanding what exists prevents asking questions the codebase already answers and grounds the conversation in reality. When the user's wording conflicts with what the code verifiably does (\"the retry queue\" when nothing retries; a table or endpoint named that doesn't exist), surface the conflict before treating the wording as settled. Silently adopting either side buries a requirements error.\n\nAsk questions **one at a time** by default. When probing a single dimension (e.g., data model, auth flow), clustering 2-3 related questions together is acceptable.\n\n**Facts vs decisions (mid-interview):** before asking, classify each candidate question. A fact (which table holds the field, whether an endpoint exists, what a library supports) is answered by inspecting code or docs, or a quick background lookup, not by asking the user. Reserve the blocking question tool for genuine trade-offs and preferences.\n\n**Premature solutions:** when the user proposes a solution before the requirements are understood, acknowledge it in one line and redirect to the requirement it serves; hold it as a candidate for Phase 2 rather than adopting it. Once Phase 2 has started, evaluate it alongside the other approaches instead of redirecting.\n\n**Info-dump gate (when user offers rich context up-front):** if the user's first message is substantial (>200 words, or dumps requirements in stream-of-consciousness), resist the urge to ask questions one-at-a-time. Instead, respond with 5-10 **numbered clarifying questions** the user can answer in shorthand (`1: yes, 2: channel #ops, 3: no because backwards compat`). Pick questions that remove ambiguity, not questions that show you read the dump. Exit this batched mode when the user's answers show they can be asked about edge cases without basics being explained back to them.\n\nExample after a spec dump:\n\n```\nBefore I propose approaches, quick clarifications:\n\n1. Auth — SSO (which provider?) or username/password?\n2. Sync or async for the webhook delivery?\n3. Which of the three integrations is P0?\n4. \"Fast enough\" in the spec — what's the actual number?\n\nAnswer whichever you know; leave blanks for the rest.\n```\n\n**Question Techniques:**\n\n1. **Prefer multiple choice when natural options exist.** Good: \"Notification: (a) email, (b) in-app, (c) both?\" Avoid: \"How should users be notified?\"\n2. **Start broad, then narrow.** Core purpose → users → constraints.\n3. **Validate assumptions and probe success early.** \"I'm assuming users are logged in. Correct?\" / \"How will you know this is working?\"\n\n**Key Topics to Explore:**\n\n| Topic | Example Questions |\n|-------|-------------------|\n| Purpose | What problem does this solve? What's the motivation? |\n| Users | Who uses this? What's their context? |\n| Constraints | Any technical limitations? Timeline? Dependencies? |\n| Success | How will you measure success? What's the happy path? |\n| Edge Cases | What shouldn't happen? Any error states to consider? |\n| Existing Patterns | Are there similar features in the codebase to follow? |\n| Non-goals | What is explicitly NOT in scope? |\n\nSee [deep-interview.md](./deep-interview.md) for deep interview techniques, including **rigor probes** (evidence/specificity/counterfactual/attachment as open-ended forced production, not menus), the **blindspot pass** for domains the user can't evaluate, and the **integration check** that fires before Phase 1 exit when combining stated answers + agent defaults produces an unsurfaced downstream effect.\n\n**Exit Condition:** Continue until the idea is clear OR user says \"proceed\". Before moving to Phase 2, summarize understanding in 3-5 bullets and confirm with the user.\n\n### Phase 2: Explore Approaches\n\nAfter understanding the idea, propose 2-3 concrete approaches.\n\n**Structure for Each Approach:**\n\n```markdown\n### Approach A: [Name]\n\n[2-3 sentence description]\n\n**Pros:**\n- [Benefit 1]\n- [Benefit 2]\n\n**Cons:**\n- [Drawback 1]\n- [Drawback 2]\n\n**Best when:** [Circumstances where this approach shines]\n```\n\n**Guidelines:**\n- Lead with a recommendation and explain why\n- Be honest about trade-offs\n- Consider YAGNI--simpler is usually better\n- Reference codebase patterns when relevant\n- If no approach is accepted after 2 rounds, ask the user to describe their preferred direction directly\n\n**Ideation lenses** (use 2-3 to stress-test approaches when the design space is wide):\n- **Inversion**: What if we solved the opposite problem?\n- **Constraint removal**: What would we build if [biggest constraint] didn't exist?\n- **Simplification**: What's the version that ships in a day?\n- **10x version**: What if this needed to handle 10x the scale?\n- **Expert lens**: How would [domain expert] approach this?\n\n**\"Not Doing\" list:** Include an explicit list of what the chosen approach will NOT do. Focus is about saying no to good ideas. Make the trade-offs visible so they're a deliberate choice, not an oversight.\n\n**Assumptions with validation:** For each key assumption in the chosen approach, state how to test it. Not just \"we assume X\" but \"we assume X; we'll know by [validation method].\"\n\nFile v5.0.1:references/scope-synthesis.md\n\n# Pre-write scope synthesis\n\nRead after substantive dialogue or when documenting a Standard/Deep design. Interaction mode and authority come from the skill entry point.\n\n### Phase 2.5: Pre-Write Scope Synthesis\n\nSurface the scope interpretation so the user can correct it before Phase 3 writes the design doc. Phase 2.5 catches scope misalignment before the doc is written; Phase 3b catches drafting issues after.\n\n**Two-stage shape: internal draft, then chat-time scoping synthesis.** Compose in two stages. Stage 1 is an internal three-bucket thinking pass (Stated / Inferred / Out of scope) for full scope analysis. Stage 2 is what the user sees, shaped like what two product collaborators would confirm before writing a PRD. The internal draft never reaches the user verbatim; it routes into the Phase 3 doc body.\n\n**Stage 1: internal three-bucket draft (thinking, not output):**\n- **Stated**: what the user said directly. Explicit user-language anchors.\n- **Inferred**: gaps the agent filled with assumptions. Most actionable bucket; bets the user can correct.\n- **Out of scope**: deliberately excluded items.\n\nUse this as a thinking step. Do not paste it into chat.\n\n**Stage 2: user-facing scoping synthesis.** Up to four named sections, each render-conditional. Empty sections are omitted, not padded:\n\n1. **What we're building** (always present): 1-3 sentences. The shape that emerged from dialogue, forward-looking, plain words. Not a transcript of \"you said X\".\n2. **Key trade-offs** (conditional): 1-3 bullets, each with a brief why. Render only when real trade-offs were made.\n3. **What's not in scope** (conditional): 1-3 bullets, or fold into a sentence. Render only when deferred items would surprise a downstream reader if absent.\n4. **Call-outs** (conditional): 0-3 bullets. Residual forks the dialogue didn't resolve: post-dialogue consequences, silent agent inferences, or (in pre-loaded contexts) scope bets the user is seeing for the first time. Not \"questions the agent could have asked during Phase 1 but didn't\"; if a call-out reads like a missed dialogue question, Phase 1's integration check failed, so flag the gap.\n\nClose with: *\"Confirm and I'll write the design doc next. Or tell me what to change.\"*\n\n**Path A vs Path B gate.** Routing depends on TWO signals: (1) did any *blocking* question fire before Phase 2.5? AND (2) what tier did Phase 0 classify? Blocking questions = scope disambiguation, dialogue probes, approach selection menus. Internal classification and pressure-tests do not count.\n\n- **Path A**: Lightweight tier AND no blocking questions fired → announce-mode. Emit \"What we're building\" prose only (no other sections, no confirmation question), then proceed to Phase 3 doc-write in the same turn. Lightweight Path A docs are short; post-hoc revision is cheap.\n- **Path B**: Standard/Deep tier OR any blocking question fired → full synthesis with confirmation gate. Two scenarios fire Path B: the user invested answer-time in dialogue, or pre-loaded substantive scope content. Either way, the substance earns a real checkpoint. The tier guard catches pre-loaded Deep brainstorms that would otherwise shortcut via the no-questions branch.\n\n**Keep tests per section.** Each conditional section has its own keep test; failing items dissolve into the internal draft only.\n- **Trade-offs**: would the user be surprised if I didn't surface this acknowledgment? Mechanical or inevitable choices fail.\n- **Deferred**: is a reasonable downstream reader likely to ask \"why isn't X here?\" Mechanical excludes fail.\n- **Call-outs**: two-step test. (1) Affirmability: would the user need to read code to evaluate this? If yes, it's doc-body content; cut. (2) Keep only if it's a real scope fork, non-obvious inclusion/exclusion, cheap-now-expensive-later correction, or non-obvious consequence of combined multi-turn answers. (3) Phase 1 boundary: if the call-out depends only on Phase 1 facts (no Phase 2 approach, no later-surfaced default), Phase 1's integration check failed; cut and revisit Phase 1. Call-outs catch what Phase 1 *couldn't* surface, not what it *should have*.\n\nCut re-statements of Q&A turns, re-statements of the picked Phase 2 approach, mechanical items, and implementation choices that settle during planning.\n\n**Bullet budget across sections 2-4 combined.** Heuristic, not law; the real discipline is each section's keep test:\n\n| Tier | Typical total | Hard ceiling |\n|---|---|---|\n| Lightweight | 0-1 | 2 |\n| Standard | 2-4 | 5 |\n| Deep | 3-7 | 9 |\n\nAbove the ceiling means the synthesis is mis-shapen: re-cut at a higher level of abstraction, do not raise the cap.\n\n**Detail level: conversational, not documentary.** 1 line ideally, 2 max. Bullets that need semicolons stringing clauses or an internal list are two decisions sharing a bullet: split or drop.\n\n**Re-present after revision; write only on confirm.** If the user revises any bullet (even trivially), integrate the change, re-present, and wait for explicit confirmation. A revision is not a confirmation.\n\n**Explicit headless mode:** compose the synthesis without requesting confirmation. Route inferred items to `## Assumptions` in the Phase 3 doc with validation methods; do not label them user-approved decisions. Stated requirements and non-goals retain their source. Report any decision beyond the caller's delegated authority instead of silently choosing it.\n\nSkip Phase 2.5 entirely when Phase 0.2 detected requirements were already clear and the flow proceeded straight to summary without a Phase 1 dialogue. Path A handles every other Lightweight case.\n\nFile v5.0.1:skill-card.md\n\n## Description:\n\nHelps clarify ambiguous feature ideas through structured interviews, approach comparisons, and pre-implementation design notes.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[iliaal](https://clawhub.ai/user/iliaal)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and product teams use this skill to turn vague feature requests into a clear scope, compare approaches, and prepare a design for review before implementation.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Design notes may reflect incorrect assumptions or ambiguous requirements.\n\nMitigation: Review the proposed scope, decisions, and open questions before approving the design or handing it off.\n\nRisk: The workflow may create design files or commit them to the project.\n\nMitigation: Review proposed file changes and permit commits only when they match your workflow and explicit authorization.\n\n## Reference(s):\n\n- [ClawHub skill listing](https://clawhub.ai/iliaal/skills/compound-eng-brainstorming)\n- [Interview and approach selection](references/interview-and-approaches.md)\n- [Deep interview](references/deep-interview.md)\n- [Scope synthesis](references/scope-synthesis.md)\n- [Design capture and handoff](references/design-and-handoff.md)\n\n## Skill Output:\n\n**Output Type(s):** [Guidance, Markdown]\n\n**Output Format:** [Markdown conversation or design document]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May save a design document under docs/brainstorms/; does not implement the feature.]\n\n## Skill Version(s):\n\n5.0.1 (source: ClawHub release)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nFile v5.0.1:SPEC.md\n\n# ia-brainstorming Specification\n\n## Intent\n\n`ia-brainstorming` is a `workflow`-class skill (a multi-step process producing concrete artifacts). Pre-implementation exploration: deep interview, approach comparison, design doc. Use when exploring a vague feature idea, clarifying ambiguous requirements, or comparing approaches before coding. For the full workflow, use `/ia-brainstorm`.\n\n## Scope\n\nIn scope:\n- Behaviors described in `SKILL.md` and routed via the should_trigger phrasings in `distillery/tests/fixtures/triggers/ia-brainstorming.jsonl`.\n- Updates to runtime behavior, structure, trigger precision, references, and validation.\n\nOut of scope:\n- Acting as the runtime instructions themselves (those live in `SKILL.md`).\n- Trigger phrasings already covered by adjacent `ia-*` skills (`validate-plugin` flags >70% description overlap as DUPLICATE_TRIGGER).\n- <!-- to fill in: domain-specific exclusions when the skill drifts -->\n\n## Trigger Context\n\n- Class: `workflow`\n- Hook regex: `plugins/whetstone/hooks/skill-patterns.sh` -> `SKILL_PATTERNS[ia-brainstorming]`\n- Common requests (from fixture should_trigger):\n  - \"brainstorm ideas for the new notification system\"\n  - \"help me think through the authentication redesign\"\n  - \"I have a vague feature idea I want to explore before coding\"\n- Should not trigger for (from fixture should_not_trigger):\n  - \"add a new column to the users table\"\n  - \"fix the broken unit test in the auth module\"\n  - \"implement the feature exactly as specced\"\n\n## Source And Evidence Model\n\nAuthoritative sources:\n\n- `SKILL.md`: runtime instructions and reference routing.\n- `references/*.md`: bundled supplementary content (4 file(s)).\n- `distillery/tests/fixtures/triggers/ia-brainstorming.jsonl`: positive and negative trigger phrasings under regression test.\n- `plugins/whetstone/hooks/skill-patterns.sh`: regex pattern that fires this skill.\n- `distillery/.eval-data/ia-brainstorming/`: harvested session examples (when present).\n\nData that must not be stored in this skill or its references:\n\n- Secrets, credentials, tokens.\n- Machine-specific filesystem paths (`/home/...`, `/Users/...`, `~/ai/...`). The validator (`MACHINE_PATH_LEAK`) flags these as HIGH.\n- Private URLs, customer data, or unredacted personal information.\n\n### Coverage matrix\n\n| Dimension | Status | Evidence |\n|---|---|---|\n| Trigger fixtures | complete | distillery/tests/fixtures/triggers/ia-brainstorming.jsonl (>=5 should_trigger, >=5 should_not_trigger) |\n| Hook regex pattern | complete | plugins/whetstone/hooks/skill-patterns.sh (`SKILL_PATTERNS[ia-brainstorming]`) |\n| Reference architecture | complete | 4 file(s) under references/ |\n| Real-usage signal | <!-- populated by harvest-sessions when sessions exist --> | distillery/.eval-data/ia-brainstorming/ (created by harvest-sessions) |\n\n## Evaluation\n\nLightweight (run on every change):\n\n```bash\npython3 distillery/scripts/distiller.py validate-plugin --component ia-brainstorming\npython3 distillery/scripts/distiller.py test-triggers --skill ia-brainstorming\n```\n\nDeeper (when behavior risk warrants):\n\n```bash\npython3 distillery/scripts/distiller.py dspy-eval ia-brainstorming\npython3 distillery/scripts/distiller.py diagnose-negatives ia-brainstorming\n```\n\nAcceptance gates:\n- Headless execution requires an explicit caller delegation and decision scope; invocation metadata alone preserves interactive approval gates.\n- `validate-plugin --component ia-brainstorming` returns 0 HIGH findings.\n- `test-triggers --skill ia-brainstorming` returns F1 = 1.0 with floors of 5 should_trigger and 5 should_not_trigger.\n- For dspy-eval, the composite score does not regress against the most recent saved baseline (see `distillery/.eval-data/ia-brainstorming/history.json`).\n\n## Known Limitations\n\n<!-- to fill in over time as drift surfaces. Default rule: any time diagnose-negatives\n     surfaces a recurring failure pattern, document it here so future maintainers\n     understand the trade-off the current implementation accepts. -->\n\n## Maintenance Notes\n\n- Update `SKILL.md` when the runtime workflow, branch conditions, or output contract changes.\n- Update this `SPEC.md` when intent, scope, evidence model, evaluation gates, or maintenance expectations change.\n- Update the trigger fixture when adding new positive phrasings, removing stale ones, or expanding scope (the 5/5 floor is a hard validator gate).\n- Update the hook regex in `skill-patterns.sh` whenever fixture positives expose a missed phrasing; verify F1 = 1.0 with `eval-triggers` before committing.\n- Run the full release pipeline via `/release`; never bump versions or update CHANGELOG.md from a per-skill edit.\n\nArchive v5.0.0: 8 files, 17273 bytes\n\nFiles: references/deep-interview.md (4978b), references/design-and-handoff.md (4970b), references/interview-and-approaches.md (6222b), references/scope-synthesis.md (5590b), skill-card.md (1871b), SKILL.md (5430b), SPEC.md (4659b), _meta.json (145b)\n\nFile v5.0.0:SKILL.md\n\n---\nname: ia-brainstorming\nclass: workflow\ndescription: >-\n  Pre-implementation exploration: deep interview, approach comparison, design\n  doc. Use when exploring a vague feature idea, clarifying ambiguous\n  requirements, or comparing approaches before coding. For the full workflow,\n  use the ia-brainstorm command (Claude Code).\n---\n\n# Brainstorming\n\nClarify what to build before planning how to implement it.\n\n## Scope and interaction\n\nProduce exploration and a design, not implementation. Obtain approval before interactive handoff. Enable headless mode only when the caller explicitly delegates non-interactive execution and its decision scope; `disable-model-invocation` is selection metadata, not approval. Replace headless confirmations with stated conservative assumptions. Return material decisions without a safe authorized default unresolved. Never label inferred choices user-approved or infer implementation, commit, or publication authority from this skill.\n\nUse the active question mechanism for material questions: AskUserQuestion in Claude Code (load via ToolSearch `select:AskUserQuestion` when needed), request_user_input in Codex where supported, otherwise chat. Return missing decisions to the parent from an unattended worker.\n\n## Process\n\n1. **Assess and ground.** For an existing project, read relevant code, documentation, constraints, and recent commits before questions. Surface contradictions between the request and observed behavior. Skip repository research for abstract topics. Brainstorm ambiguous goals, competing interpretations, unresolved trade-offs, uncertain needs, solution-framed requests, or multiple independent subsystems. If requirements are clear, suggest planning or implementation without forcing dialogue.\n2. **Right-size and decompose.** A brainstorm resolved in three messages may need only a summary; sustained architectural work needs a durable design. For multiple independent subsystems, identify boundaries and dependencies, choose build order, then give each sub-project its own design → plan → implementation cycle. Start with the first sub-project.\n3. **Understand and compare.** When dialogue or approach selection is needed, read [interview-and-approaches.md](./references/interview-and-approaches.md). Match the user's vocabulary. Normally ask one question across dimensions, or two to three within one dimension; for a substantial initial dump (>200 words), use the reference's bounded batch. Explore purpose, users, constraints, success, edge cases, patterns, and non-goals. Apply [deep-interview.md](./references/deep-interview.md) when assumptions, evidence, unfamiliar domains, or combined answers need probing; its integration check applies before interview exit. Stop questioning when clear or told to proceed. Summarize in three to five bullets and confirm in interactive mode.\n4. **Choose an approach.** Compare two to three concrete alternatives with descriptions, pros, cons, and best-use conditions. Lead with the recommendation, reference existing patterns, and expose trade-offs. If none is accepted after two rounds, ask for the preferred direction. For a wide design space, use two to three lenses from the approach reference. State the chosen approach's explicit Not Doing list and a validation method for every key assumption.\n5. **Confirm interpreted scope.** Before writing after substantive dialogue, read [scope-synthesis.md](./references/scope-synthesis.md). Separate stated requirements, inferred assumptions, and exclusions internally; present only the reference's concise scoping synthesis. Lightweight work without blocking questions uses announce-mode; Standard/Deep work or any blocking dialogue requires interactive confirmation. Re-present revisions and await confirmation. In headless mode preserve sources and unresolved assumptions without prompts. Clear requirements that skipped dialogue need no synthesis checkpoint.\n6. **Capture and self-review.** For a durable artifact, read [design-and-handoff.md](./references/design-and-handoff.md). Save `docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md` with date/topic frontmatter, What We're Building, Why This Approach, Key Decisions and rationale, Open Questions, and Next Steps. Collapse interview history in a details block. Describe each component's purpose, usage, dependencies, and testable boundary. Commit only within caller authority.\n7. **Handoff.** Preserve settled decisions and their rationale rather than repeatedly challenging them; a cold directive gets one approach challenge. Neither label suppresses concrete defect or infeasibility evidence. Require consistent terminology, concrete criteria, scope traceability, unambiguous decisions, explicit non-goals, assumption validation, and a named source for every produced value. Return failures to approach selection or drafting. Present the design for interactive approval; return caller-delegated decisions and unresolved assumptions in headless mode.\n\n## Completion\n\nReturn the scoped summary or saved design path, decisions, and open questions resolved or explicitly deferred with reasons. Interactive approval precedes handoff; a headless handoff remains within caller authority. Planning (`ia-planning`, or `/ia-plan` in Claude Code) follows design and reuses its settled requirements. For auth, payments, external APIs, or multi-tenant data, suggest an available security threat-model review before planning.\n\nFile v5.0.0:_meta.json\n\n{\n  \"ownerId\": \"kn715jrbbh71q9zncr0bqdkr8n848q1a\",\n  \"slug\": \"compound-eng-brainstorming\",\n  \"version\": \"5.0.0\",\n  \"publishedAt\": 1790465350946\n}\n\nFile v5.0.0:references/deep-interview.md\n\n# Deep Interview Layer\n\nApply the deep interview protocol on top of the baseline questions above. Assumption probing and contradiction tracking always run. Research-backed challenges and second-order effects run when the scope warrants it (multi-system changes, infrastructure decisions, technology selection).\n\n**Assumption probing:** After each substantive answer, identify what the user assumed but didn't state. \"You described X. Are you assuming Y is already in place?\" Surface hidden dependencies and unstated constraints.\n\n**Second-order effects:** For features that touch shared infrastructure or data models, ask what success creates downstream. \"If this works and gets adopted, what pressure does it put on [related system]?\"\n\n**Research-backed challenges:** Fire background research on technology choices and claims. When findings contradict, challenge directly with citation. When findings support, briefly confirm to build confidence in the decision.\n\n**Contradiction tracking:** If the user's answer contradicts something said earlier, flag it immediately: \"Earlier you said X, but this implies Y. Which takes priority?\"\n\n**Anti-requirements:** When the user rejects an approach or says \"definitely not X,\" capture the rejection and rationale inline with the related decision. Don't force this; capture organically when it surfaces.\n\n**Architecture-first ordering:** When several questions remain, ask the ones whose answers would change the *architecture* first: data model shape, service boundaries, sync vs. async, auth model, storage engine. A question whose answer only affects a label, copy string, or default value can wait or take a reasonable default. Front-loading architecture-changing questions means a redirect lands before the design is built around a wrong assumption, not after.\n\n**Question clustering:** When probing a single dimension (e.g., data model, auth flow), ask 2-3 related questions together using AskUserQuestion's multi-question support. Switch to one-at-a-time when jumping between dimensions.\n\n**Completeness assessment:** Track which dimensions have been explored. Before proposing to move to Phase 2, assess coverage and signal confidence: \"We've covered purpose, users, and constraints well. Data flow and failure modes are still thin. Want to explore those, or proceed?\"\n\n## Rigor Probes for Ambiguous Gaps\n\nWhen a user answer leaves a gap on evidence, specificity, counterfactual, or attachment, fire ONE open-ended probe per gap, *not* a multiple-choice menu (exception: territory the user can't evaluate, where menus are the right tool; see Blindspot Pass below). Menus signal which axes the agent thinks matter, biasing the user toward those axes; open-ended forces actual observation:\n\n- **Evidence:** \"What's the most concrete thing someone's already done about this? Paid for it, built a workaround, quit a tool over it?\"\n- **Specificity:** \"Can you name a team you've actually watched hit this, or are you reasoning?\"\n- **Counterfactual:** \"What do teams do today when this breaks? Who reconciles?\"\n- **Attachment:** \"What's the smallest version that would still prove the bet right, and what's excluded?\"\n\nInterleave with narrowing moves; do not stack multiple probes in one turn.\n\n## Blindspot Pass for Unfamiliar Territory\n\nWhen the user signals they *cannot evaluate* a domain, explicitly (\"I know nothing about auth\", \"no idea, you pick\") or implicitly (deferring the same judgment-domain question to the agent 2+ times), stop extracting guesses and map the decision surface for them instead.\n\nDistinguish **can't-evaluate** (no basis to choose) from **hasn't-decided** (has a basis, just hasn't picked). Only the first triggers this pass; a user who can weigh the options but is undecided gets the normal probes above. This guard keeps the pass from firing on every open question.\n\nScope the pass to the unfamiliar territory only, not the whole interview. List 3-7 decisions and hazards the user can't see, each with 2-3 concrete options and a recommended default, and present them with `AskUserQuestion` (load its schema via `ToolSearch select:AskUserQuestion` first if unavailable; in Codex use `request_user_input`; where no blocking tool exists, fall back to numbered options in chat) so the user chooses against real alternatives instead of the agent deciding silently. In a non-interactive context, treat the pass as declined and record the recommended defaults as explicit assumptions the user can override later.\n\n## Integration Check Before Phase 1 Exit\n\nBefore exiting Phase 1, mentally combine what the user has stated so far. If stated-A + stated-B + agent-default-C produces a downstream effect the user is unlikely to have tracked (e.g., \"if mute lives on the rule AND we don't warn on delete, rule-delete silently loses pause state\"), fire one open probe per genuine combination. Phase 2.5's call-outs are a safety net for residuals, *not* a punt list for consequences you should have surfaced here.\n\nFile v5.0.0:references/design-and-handoff.md\n\n# Design capture and handoff\n\nRead when writing or reviewing a durable design. The entry point’s authority boundary also applies to commits and handoff.\n\n### Phase 3: Capture the Design\n\nSummarize key decisions in a structured format. For each major component, verify isolation and clarity: it must answer \"what does it do, how do you use it, what does it depend on?\" and be independently understandable and testable. If working in an existing codebase, note which existing patterns to follow and where targeted improvements fit naturally.\n\n**Design Doc:** Save to `docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md`. Required sections: What We're Building, Why This Approach, Key Decisions (with rationale), Open Questions, Next Steps. Collapse the Q&A interview log in a `<details>` block. Include YAML frontmatter with `date` and `topic`. Commit to git; design decisions are project history.\n\n**Settled vs. directive: don't re-litigate.** A decision the user made with the alternative and its trade-off in view is **settled**: record it in Key Decisions with its rationale and carry it forward. Do not re-ask it in Phase 3b, at planning, or during work. A cold **directive** (a choice asserted without anyone weighing it, e.g. \"build it with X\") earns exactly **one** in-pipeline challenge (one pass of the Phase 2 ideation lenses against that specific choice), then it too is recorded and not re-challenged at every downstream stage. A settled label never suppresses defect evidence: a real bug or infeasibility found *inside* a settled approach keeps full severity and is surfaced.\n\n### Phase 3b: Spec Self-Review\n\nRun this checklist before presenting the design doc. Any failure returns to Phase 2 or Phase 3, not Phase 4.\n\n- **Placeholder scan**: no TBD, \"figure out later\", \"appropriate error handling\", bracketed gaps, or tasks without concrete criteria.\n- **Internal consistency**: names, types, and verbs match across sections (no `createOrder()` in one place and `placeOrder()` in another).\n- **Scope containment**: every decision traces back to a stated goal; otherwise cut or surface as explicit scope expansion.\n- **Ambiguity sweep**: each Key Decision survives \"could a reasonable implementer interpret this two ways?\"\n- **Assumption validation**: every assumption names its validation method (\"we assume X; we'll confirm by Y\").\n- **Value sourcing**: enumerate every value the work must produce, compute, or display, and confirm the spec names each one's source (an input param, a stored field, a derivation from a named value, or a prior decision). A produced value with no named source is an owed design decision; surface it, don't invent it. Judge by positive enumeration, not introspection: \"show the user's local day\" that never says where the timezone comes from passes every other check yet hides an undecided source.\n- **Non-goals present**: the explicit \"Not Doing\" list exists and is specific.\n\nSilent pass is valid. Clean draft → move to Phase 4.\n\n### Phase 4: Review and Handoff\n\nPresent the design doc to the user for approval. The user explicitly confirming the design is the gate to proceed. When invoked via `/ia-brainstorm`, the command handles spec review dispatch and next-step orchestration.\n\n**Explicit headless mode:** return the design and unresolved assumptions to the caller. Handoff may continue only within the caller's delegated authority; report the design as caller-delegated, not user-approved.\n\n## Anti-Patterns to Avoid\n\n| Anti-Pattern | Better Approach |\n|--------------|-----------------|\n| Asking 5 questions at once | Ask one at a time across dimensions; cluster 2-3 within a dimension |\n| Jumping to implementation details | Stay focused on WHAT, not HOW |\n| Proposing overly complex solutions | Start simple, add complexity only if needed |\n| Ignoring existing codebase patterns | Research what exists first |\n| Making assumptions without validating | State assumptions explicitly and confirm |\n| Creating lengthy design documents | Keep it concise--details go in the plan |\n\n## Success Criteria\n\n- Design doc saved to `docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md`\n- Interactive mode: user approves the spec before handoff. Explicit headless mode: caller-delegated decisions and remaining assumptions are identified.\n- All open questions resolved or explicitly deferred with rationale\n\n## Integration\n\nBrainstorming answers WHAT to build. Planning answers HOW. When brainstorm output exists, `/ia-plan` (Claude Code) or the ia-planning skill detects it and skips idea refinement.\n\n- **Next step:** planning, always (`/ia-plan` in Claude Code; the `ia-planning` skill elsewhere)\n- **Threat modeling:** when the brainstorm involves auth, payments, external API surfaces, or multi-tenant data, suggest a `ia-security-sentinel` threat model before moving to planning. Catching trust boundary issues at the design stage prevents costly rework.\n- **Predecessor:** user request or ambiguous feature description\n\nFile v5.0.0:references/interview-and-approaches.md\n\n# Interview and approach selection\n\nRead when requirements need dialogue or multiple approaches need comparison. Headless execution follows the entry point’s caller-delegated decision scope.\n\n### Phase 1: Understand the Idea\n\n**User context calibration (before diving into the idea):**\n\nRead signals from the user's first message to calibrate communication register:\n- **Vocabulary**: Are they using technical terms (API, schema, migration) or describing experiences (it's slow, it breaks when...)?\n- **Framing**: Are they describing a solution (\"build a dashboard\") or a problem (\"I can't see what's happening\")?\n- **References**: Are they pointing to code, files, and patterns, or to analogies and comparisons (\"something like Notion\")?\n\nAdjust question style accordingly. Technical users get architecture-level probing. Non-technical users get experience-level probing. Don't ask about this calibration; just do it. If signals are ambiguous, default to the vocabulary the user is already using.\n\n**Explore project context first:** Before asking questions, read existing files, docs, and recent commits related to the idea. Understanding what exists prevents asking questions the codebase already answers and grounds the conversation in reality. When the user's wording conflicts with what the code verifiably does (\"the retry queue\" when nothing retries; a table or endpoint named that doesn't exist), surface the conflict before treating the wording as settled. Silently adopting either side buries a requirements error.\n\nAsk questions **one at a time** by default. When probing a single dimension (e.g., data model, auth flow), clustering 2-3 related questions together is acceptable.\n\n**Facts vs decisions (mid-interview):** before asking, classify each candidate question. A fact (which table holds the field, whether an endpoint exists, what a library supports) is answered by inspecting code or docs, or a quick background lookup, not by asking the user. Reserve the blocking question tool for genuine trade-offs and preferences.\n\n**Premature solutions:** when the user proposes a solution before the requirements are understood, acknowledge it in one line and redirect to the requirement it serves; hold it as a candidate for Phase 2 rather than adopting it. Once Phase 2 has started, evaluate it alongside the other approaches instead of redirecting.\n\n**Info-dump gate (when user offers rich context up-front):** if the user's first message is substantial (>200 words, or dumps requirements in stream-of-consciousness), resist the urge to ask questions one-at-a-time. Instead, respond with 5-10 **numbered clarifying questions** the user can answer in shorthand (`1: yes, 2: channel #ops, 3: no because backwards compat`). Pick questions that remove ambiguity, not questions that show you read the dump. Exit this batched mode when the user's answers show they can be asked about edge cases without basics being explained back to them.\n\nExample after a spec dump:\n\n```\nBefore I propose approaches, quick clarifications:\n\n1. Auth — SSO (which provider?) or username/password?\n2. Sync or async for the webhook delivery?\n3. Which of the three integrations is P0?\n4. \"Fast enough\" in the spec — what's the actual number?\n\nAnswer whichever you know; leave blanks for the rest.\n```\n\n**Question Techniques:**\n\n1. **Prefer multiple choice when natural options exist.** Good: \"Notification: (a) email, (b) in-app, (c) both?\" Avoid: \"How should users be notified?\"\n2. **Start broad, then narrow.** Core purpose → users → constraints.\n3. **Validate assumptions and probe success early.** \"I'm assuming users are logged in. Correct?\" / \"How will you know this is working?\"\n\n**Key Topics to Explore:**\n\n| Topic | Example Questions |\n|-------|-------------------|\n| Purpose | What problem does this solve? What's the motivation? |\n| Users | Who uses this? What's their context? |\n| Constraints | Any technical limitations? Timeline? Dependencies? |\n| Success | How will you measure success? What's the happy path? |\n| Edge Cases | What shouldn't happen? Any error states to consider? |\n| Existing Patterns | Are there similar features in the codebase to follow? |\n| Non-goals | What is explicitly NOT in scope? |\n\nSee [deep-interview.md](./deep-interview.md) for deep interview techniques, including **rigor probes** (evidence/specificity/counterfactual/attachment as open-ended forced production, not menus), the **blindspot pass** for domains the user can't evaluate, and the **integration check** that fires before Phase 1 exit when combining stated answers + agent defaults produces an unsurfaced downstream effect.\n\n**Exit Condition:** Continue until the idea is clear OR user says \"proceed\". Before moving to Phase 2, summarize understanding in 3-5 bullets and confirm with the user.\n\n### Phase 2: Explore Approaches\n\nAfter understanding the idea, propose 2-3 concrete approaches.\n\n**Structure for Each Approach:**\n\n```markdown\n### Approach A: [Name]\n\n[2-3 sentence description]\n\n**Pros:**\n- [Benefit 1]\n- [Benefit 2]\n\n**Cons:**\n- [Drawback 1]\n- [Drawback 2]\n\n**Best when:** [Circumstances where this approach shines]\n```\n\n**Guidelines:**\n- Lead with a recommendation and explain why\n- Be honest about trade-offs\n- Consider YAGNI--simpler is usually better\n- Reference codebase patterns when relevant\n- If no approach is accepted after 2 rounds, ask the user to describe their preferred direction directly\n\n**Ideation lenses** (use 2-3 to stress-test approaches when the design space is wide):\n- **Inversion**: What if we solved the opposite problem?\n- **Constraint removal**: What would we build if [biggest constraint] didn't exist?\n- **Simplification**: What's the version that ships in a day?\n- **10x version**: What if this needed to handle 10x the scale?\n- **Expert lens**: How would [domain expert] approach this?\n\n**\"Not Doing\" list:** Include an explicit list of what the chosen approach will NOT do. Focus is about saying no to good ideas. Make the trade-offs visible so they're a deliberate choice, not an oversight.\n\n**Assumptions with validation:** For each key assumption in the chosen approach, state how to test it. Not just \"we assume X\" but \"we assume X; we'll know by [validation method].\"\n\nFile v5.0.0:references/scope-synthesis.md\n\n# Pre-write scope synthesis\n\nRead after substantive dialogue or when documenting a Standard/Deep design. Interaction mode and authority come from the skill entry point.\n\n### Phase 2.5: Pre-Write Scope Synthesis\n\nSurface the scope interpretation so the user can correct it before Phase 3 writes the design doc. Phase 2.5 catches scope misalignment before the doc is written; Phase 3b catches drafting issues after.\n\n**Two-stage shape: internal draft, then chat-time scoping synthesis.** Compose in two stages. Stage 1 is an internal three-bucket thinking pass (Stated / Inferred / Out of scope) for full scope analysis. Stage 2 is what the user sees, shaped like what two product collaborators would confirm before writing a PRD. The internal draft never reaches the user verbatim; it routes into the Phase 3 doc body.\n\n**Stage 1: internal three-bucket draft (thinking, not output):**\n- **Stated**: what the user said directly. Explicit user-language anchors.\n- **Inferred**: gaps the agent filled with assumptions. Most actionable bucket; bets the user can correct.\n- **Out of scope**: deliberately excluded items.\n\nUse this as a thinking step. Do not paste it into chat.\n\n**Stage 2: user-facing scoping synthesis.** Up to four named sections, each render-conditional. Empty sections are omitted, not padded:\n\n1. **What we're building** (always present): 1-3 sentences. The shape that emerged from dialogue, forward-looking, plain words. Not a transcript of \"you said X\".\n2. **Key trade-offs** (conditional): 1-3 bullets, each with a brief why. Render only when real trade-offs were made.\n3. **What's not in scope** (conditional): 1-3 bullets, or fold into a sentence. Render only when deferred items would surprise a downstream reader if absent.\n4. **Call-outs** (conditional): 0-3 bullets. Residual forks the dialogue didn't resolve: post-dialogue consequences, silent agent inferences, or (in pre-loaded contexts) scope bets the user is seeing for the first time. Not \"questions the agent could have asked during Phase 1 but didn't\"; if a call-out reads like a missed dialogue question, Phase 1's integration check failed, so flag the gap.\n\nClose with: *\"Confirm and I'll write the design doc next. Or tell me what to change.\"*\n\n**Path A vs Path B gate.** Routing depends on TWO signals: (1) did any *blocking* question fire before Phase 2.5? AND (2) what tier did Phase 0 classify? Blocking questions = scope disambiguation, dialogue probes, approach selection menus. Internal classification and pressure-tests do not count.\n\n- **Path A**: Lightweight tier AND no blocking questions fired → announce-mode. Emit \"What we're building\" prose only (no other sections, no confirmation question), then proceed to Phase 3 doc-write in the same turn. Lightweight Path A docs are short; post-hoc revision is cheap.\n- **Path B**: Standard/Deep tier OR any blocking question fired → full synthesis with confirmation gate. Two scenarios fire Path B: the user invested answer-time in dialogue, or pre-loaded substantive scope content. Either way, the substance earns a real checkpoint. The tier guard catches pre-loaded Deep brainstorms that would otherwise shortcut via the no-questions branch.\n\n**Keep tests per section.** Each conditional section has its own keep test; failing items dissolve into the internal draft only.\n- **Trade-offs**: would the user be surprised if I didn't surface this acknowledgment? Mechanical or inevitable choices fail.\n- **Deferred**: is a reasonable downstream reader likely to ask \"why isn't X here?\" Mechanical excludes fail.\n- **Call-outs**: two-step test. (1) Affirmability: would the user need to read code to evaluate this? If yes, it's doc-body content; cut. (2) Keep only if it's a real scope fork, non-obvious inclusion/exclusion, cheap-now-expensive-later correction, or non-obvious consequence of combined multi-turn answers. (3) Phase 1 boundary: if the call-out depends only on Phase 1 facts (no Phase 2 approach, no later-surfaced default), Phase 1's integration check failed; cut and revisit Phase 1. Call-outs catch what Phase 1 *couldn't* surface, not what it *should have*.\n\nCut re-statements of Q&A turns, re-statements of the picked Phase 2 approach, mechanical items, and implementation choices that settle during planning.\n\n**Bullet budget across sections 2-4 combined.** Heuristic, not law; the real discipline is each section's keep test:\n\n| Tier | Typical total | Hard ceiling |\n|---|---|---|\n| Lightweight | 0-1 | 2 |\n| Standard | 2-4 | 5 |\n| Deep | 3-7 | 9 |\n\nAbove the ceiling means the synthesis is mis-shapen: re-cut at a higher level of abstraction, do not raise the cap.\n\n**Detail level: conversational, not documentary.** 1 line ideally, 2 max. Bullets that need semicolons stringing clauses or an internal list are two decisions sharing a bullet: split or drop.\n\n**Re-present after revision; write only on confirm.** If the user revises any bullet (even trivially), integrate the change, re-present, and wait for explicit confirmation. A revision is not a confirmation.\n\n**Explicit headless mode:** compose the synthesis without requesting confirmation. Route inferred items to `## Assumptions` in the Phase 3 doc with validation methods; do not label them user-approved decisions. Stated requirements and non-goals retain their source. Report any decision beyond the caller's delegated authority instead of silently choosing it.\n\nSkip Phase 2.5 entirely when Phase 0.2 detected requirements were already clear and the flow proceeded straight to summary without a Phase 1 dialogue. Path A handles every other Lightweight case.\n\nFile v5.0.0:skill-card.md\n\n## Description:\n\nGuides pre-implementation brainstorming through requirements interviews, approach comparison, and design documentation.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[iliaal](https://clawhub.ai/user/iliaal)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and product collaborators use this skill to clarify uncertain feature ideas, compare possible solutions, and agree on a design before implementation.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Repository context may be read during brainstorming.\n\nMitigation: Limit repository access to relevant project context and avoid including sensitive material in the resulting design.\n\nRisk: A design document may be written and committed when authorized.\n\nMitigation: Review the proposed design before implementation and require explicit authority before writing or committing it.\n\n## Reference(s):\n\n- [Interview and approaches](references/interview-and-approaches.md)\n- [Deep interview](references/deep-interview.md)\n- [Scope synthesis](references/scope-synthesis.md)\n- [Design and handoff](references/design-and-handoff.md)\n- [ClawHub skill listing](https://clawhub.ai/iliaal/skills/compound-eng-brainstorming)\n\n## Skill Output:\n\n**Output Type(s):** [Guidance, Markdown]\n\n**Output Format:** [Conversational text and optional Markdown design document]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May save a design document under docs/brainstorms when appropriate and authorized.]\n\n## Skill Version(s):\n\n5.0.0 (source: ClawHub release)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nFile v5.0.0:SPEC.md\n\n# ia-brainstorming Specification\n\n## Intent\n\n`ia-brainstorming` is a `workflow`-class skill (a multi-step process producing concrete artifacts). Pre-implementation exploration: deep interview, approach comparison, design doc. Use when exploring a vague feature idea, clarifying ambiguous requirements, or comparing approaches before coding. For the full workflow, use `/ia-brainstorm`.\n\n## Scope\n\nIn scope:\n- Behaviors described in `SKILL.md` and routed via the should_trigger phrasings in `distillery/tests/fixtures/triggers/ia-brainstorming.jsonl`.\n- Updates to runtime behavior, structure, trigger precision, references, and validation.\n\nOut of scope:\n- Acting as the runtime instructions themselves (those live in `SKILL.md`).\n- Trigger phrasings already covered by adjacent `ia-*` skills (`validate-plugin` flags >70% description overlap as DUPLICATE_TRIGGER).\n- <!-- to fill in: domain-specific exclusions when the skill drifts -->\n\n## Trigger Context\n\n- Class: `workflow`\n- Hook regex: `plugins/whetstone/hooks/skill-patterns.sh` -> `SKILL_PATTERNS[ia-brainstorming]`\n- Common requests (from fixture should_trigger):\n  - \"brainstorm ideas for the new notification system\"\n  - \"help me think through the authentication redesign\"\n  - \"I have a vague feature idea I want to explore before coding\"\n- Should not trigger for (from fixture should_not_trigger):\n  - \"add a new column to the users table\"\n  - \"fix the broken unit test in the auth module\"\n  - \"implement the feature exactly as specced\"\n\n## Source And Evidence Model\n\nAuthoritative sources:\n\n- `SKILL.md`: runtime instructions and reference routing.\n- `references/*.md`: bundled supplementary content (4 file(s)).\n- `distillery/tests/fixtures/triggers/ia-brainstorming.jsonl`: positive and negative trigger phrasings under regression test.\n- `plugins/whetstone/hooks/skill-patterns.sh`: regex pattern that fires this skill.\n- `distillery/.eval-data/ia-brainstorming/`: harvested session examples (when present).\n\nData that must not be stored in this skill or its references:\n\n- Secrets, credentials, tokens.\n- Machine-specific filesystem paths (`/home/...`, `/Users/...`, `~/ai/...`). The validator (`MACHINE_PATH_LEAK`) flags these as HIGH.\n- Private URLs, customer data, or unredacted personal information.\n\n### Coverage matrix\n\n| Dimension | Status | Evidence |\n|---|---|---|\n| Trigger fixtures | complete | distillery/tests/fixtures/triggers/ia-brainstorming.jsonl (>=5 should_trigger, >=5 should_not_trigger) |\n| Hook regex pattern | complete | plugins/whetstone/hooks/skill-patterns.sh (`SKILL_PATTERNS[ia-brainstorming]`) |\n| Reference architecture | complete | 4 file(s) under references/ |\n| Real-usage signal | <!-- populated by harvest-sessions when sessions exist --> | distillery/.eval-data/ia-brainstorming/ (created by harvest-sessions) |\n\n## Evaluation\n\nLightweight (run on every change):\n\n```bash\npython3 distillery/scripts/distiller.py validate-plugin --component ia-brainstorming\npython3 distillery/scripts/distiller.py test-triggers --skill ia-brainstorming\n```\n\nDeeper (when behavior risk warrants):\n\n```bash\npython3 distillery/scripts/distiller.py dspy-eval ia-brainstorming\npython3 distillery/scripts/distiller.py diagnose-negatives ia-brainstorming\n```\n\nAcceptance gates:\n- Headless execution requires an explicit caller delegation and decision scope; invocation metadata alone preserves interactive approval gates.\n- `validate-plugin --component ia-brainstorming` returns 0 HIGH findings.\n- `test-triggers --skill ia-brainstorming` returns F1 = 1.0 with floors of 5 should_trigger and 5 should_not_trigger.\n- For dspy-eval, the composite score does not regress against the most recent saved baseline (see `distillery/.eval-data/ia-brainstorming/history.json`).\n\n## Known Limitations\n\n<!-- to fill in over time as drift surfaces. Default rule: any time diagnose-negatives\n     surfaces a recurring failure pattern, document it here so future maintainers\n     understand the trade-off the current implementation accepts. -->\n\n## Maintenance Notes\n\n- Update `SKILL.md` when the runtime workflow, branch conditions, or output contract changes.\n- Update this `SPEC.md` when intent, scope, evidence model, evaluation gates, or maintenance expectations change.\n- Update the trigger fixture when adding new positive phrasings, removing stale ones, or expanding scope (the 5/5 floor is a hard validator gate).\n- Update the hook regex in `skill-patterns.sh` whenever fixture positives expose a missed phrasing; verify F1 = 1.0 with `eval-triggers` before committing.\n- Run the full release pipeline via `/release`; never bump versions or update CHANGELOG.md from a per-skill edit.\n\nArchive v4.5.3: 8 files, 17484 bytes\n\nFiles: references/deep-interview.md (5003b), references/design-and-handoff.md (4985b), references/interview-and-approaches.md (6231b), references/scope-synthesis.md (5656b), skill-card.md (2250b), SKILL.md (5430b), SPEC.md (4671b), _meta.json (145b)\n\nFile v4.5.3:SKILL.md\n\n---\nname: ia-brainstorming\nclass: workflow\ndescription: >-\n  Pre-implementation exploration: deep interview, approach comparison, design\n  doc. Use when exploring a vague feature idea, clarifying ambiguous\n  requirements, or comparing approaches before coding. For the full workflow,\n  use the ia-brainstorm command (Claude Code).\n---\n\n# Brainstorming\n\nClarify what to build before planning how to implement it.\n\n## Scope and interaction\n\nProduce exploration and a design, not implementation. Obtain approval before interactive handoff. Enable headless mode only when the caller explicitly delegates non-interactive execution and its decision scope; `disable-model-invocation` is selection metadata, not approval. Replace headless confirmations with stated conservative assumptions. Return material decisions without a safe authorized default unresolved. Never label inferred choices user-approved or infer implementation, commit, or publication authority from this skill.\n\nUse the active question mechanism for material questions: AskUserQuestion in Claude Code (load via ToolSearch `select:AskUserQuestion` when needed), request_user_input in Codex where supported, otherwise chat. Return missing decisions to the parent from an unattended worker.\n\n## Process\n\n1. **Assess and ground.** For an existing project, read relevant code, documentation, constraints, and recent commits before questions. Surface contradictions between the request and observed behavior. Skip repository research for abstract topics. Brainstorm ambiguous goals, competing interpretations, unresolved trade-offs, uncertain needs, solution-framed requests, or multiple independent subsystems. If requirements are clear, suggest planning or implementation without forcing dialogue.\n2. **Right-size and decompose.** A brainstorm resolved in three messages may need only a summary; sustained architectural work needs a durable design. For multiple independent subsystems, identify boundaries and dependencies, choose build order, then give each sub-project its own design → plan → implementation cycle. Start with the first sub-project.\n3. **Understand and compare.** When dialogue or approach selection is needed, read [interview-and-approaches.md](./references/interview-and-approaches.md). Match the user's vocabulary. Normally ask one question across dimensions, or two to three within one dimension; for a substantial initial dump (>200 words), use the reference's bounded batch. Explore purpose, users, constraints, success, edge cases, patterns, and non-goals. Apply [deep-interview.md](./references/deep-interview.md) when assumptions, evidence, unfamiliar domains, or combined answers need probing; its integration check applies before interview exit. Stop questioning when clear or told to proceed. Summarize in three to five bullets and confirm in interactive mode.\n4. **Choose an approach.** Compare two to three concrete alternatives with descriptions, pros, cons, and best-use conditions. Lead with the recommendation, reference existing patterns, and expose trade-offs. If none is accepted after two rounds, ask for the preferred direction. For a wide design space, use two to three lenses from the approach reference. State the chosen approach's explicit Not Doing list and a validation method for every key assumption.\n5. **Confirm interpreted scope.** Before writing after substantive dialogue, read [scope-synthesis.md](./references/scope-synthesis.md). Separate stated requirements, inferred assumptions, and exclusions internally; present only the reference's concise scoping synthesis. Lightweight work without blocking questions uses announce-mode; Standard/Deep work or any blocking dialogue requires interactive confirmation. Re-present revisions and await confirmation. In headless mode preserve sources and unresolved assumptions without prompts. Clear requirements that skipped dialogue need no synthesis checkpoint.\n6. **Capture and self-review.** For a durable artifact, read [design-and-handoff.md](./references/design-and-handoff.md). Save `docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md` with date/topic frontmatter, What We're Building, Why This Approach, Key Decisions and rationale, Open Questions, and Next Steps. Collapse interview history in a details block. Describe each component's purpose, usage, dependencies, and testable boundary. Commit only within caller authority.\n7. **Handoff.** Preserve settled decisions and their rationale rather than repeatedly challenging them; a cold directive gets one approach challenge. Neither label suppresses concrete defect or infeasibility evidence. Require consistent terminology, concrete criteria, scope traceability, unambiguous decisions, explicit non-goals, assumption validation, and a named source for every produced value. Return failures to approach selection or drafting. Present the design for interactive approval; return caller-delegated decisions and unresolved assumptions in headless mode.\n\n## Completion\n\nReturn the scoped summary or saved design path, decisions, and open questions resolved or explicitly deferred with reasons. Interactive approval precedes handoff; a headless handoff remains within caller authority. Planning (`ia-planning`, or `/ia-plan` in Claude Code) follows design and reuses its settled requirements. For auth, payments, external APIs, or multi-tenant data, suggest an available security threat-model review before planning.\n\nFile v4.5.3:_meta.json\n\n{\n  \"ownerId\": \"kn715jrbbh71q9zncr0bqdkr8n848q1a\",\n  \"slug\": \"compound-eng-brainstorming\",\n  \"version\": \"4.5.3\",\n  \"publishedAt\": 1789310721937\n}\n\nFile v4.5.3:references/deep-interview.md\n\n# Deep Interview Layer\n\nApply the deep interview protocol on top of the baseline questions above. Assumption probing and contradiction tracking always run. Research-backed challenges and second-order effects run when the scope warrants it (multi-system changes, infrastructure decisions, technology selection).\n\n**Assumption probing:** After each substantive answer, identify what the user assumed but didn't state. \"You described X -- are you assuming Y is already in place?\" Surface hidden dependencies and unstated constraints.\n\n**Second-order effects:** For features that touch shared infrastructure or data models, ask what success creates downstream. \"If this works and gets adopted, what pressure does it put on [related system]?\"\n\n**Research-backed challenges:** Fire background research on technology choices and claims. When findings contradict, challenge directly with citation. When findings support, briefly confirm to build confidence in the decision.\n\n**Contradiction tracking:** If the user's answer contradicts something said earlier, flag it immediately: \"Earlier you said X, but this implies Y. Which takes priority?\"\n\n**Anti-requirements:** When the user rejects an approach or says \"definitely not X,\" capture the rejection and rationale inline with the related decision. Don't force this -- capture organically when it surfaces.\n\n**Architecture-first ordering:** When several questions remain, ask the ones whose answers would change the *architecture* first -- data model shape, service boundaries, sync vs. async, auth model, storage engine. A question whose answer only affects a label, copy string, or default value can wait or take a reasonable default. Front-loading architecture-changing questions means a redirect lands before the design is built around a wrong assumption, not after.\n\n**Question clustering:** When probing a single dimension (e.g., data model, auth flow), ask 2-3 related questions together using AskUserQuestion's multi-question support. Switch to one-at-a-time when jumping between dimensions.\n\n**Completeness assessment:** Track which dimensions have been explored. Before proposing to move to Phase 2, assess coverage and signal confidence: \"We've covered purpose, users, and constraints well. Data flow and failure modes are still thin -- want to explore those, or proceed?\"\n\n## Rigor Probes for Ambiguous Gaps\n\nWhen a user answer leaves a gap on evidence, specificity, counterfactual, or attachment, fire ONE open-ended probe per gap — *not* a multiple-choice menu (exception: territory the user can't evaluate, where menus are the right tool — see Blindspot Pass below). Menus signal which axes the agent thinks matter, biasing the user toward those axes; open-ended forces actual observation:\n\n- **Evidence:** \"What's the most concrete thing someone's already done about this — paid for it, built a workaround, quit a tool over it?\"\n- **Specificity:** \"Can you name a team you've actually watched hit this, or are you reasoning?\"\n- **Counterfactual:** \"What do teams do today when this breaks — who reconciles?\"\n- **Attachment:** \"What's the smallest version that would still prove the bet right, and what's excluded?\"\n\nInterleave with narrowing moves; do not stack multiple probes in one turn.\n\n## Blindspot Pass for Unfamiliar Territory\n\nWhen the user signals they *cannot evaluate* a domain — explicit (\"I know nothing about auth\", \"no idea, you pick\") or implicit (deferring the same judgment-domain question to the agent 2+ times) — stop extracting guesses and map the decision surface for them instead.\n\nDistinguish **can't-evaluate** (no basis to choose) from **hasn't-decided** (has a basis, just hasn't picked). Only the first triggers this pass; a user who can weigh the options but is undecided gets the normal probes above. This guard keeps the pass from firing on every open question.\n\nScope the pass to the unfamiliar territory only, not the whole interview. List 3-7 decisions and hazards the user can't see, each with 2-3 concrete options and a recommended default, and present them with `AskUserQuestion` (load its schema via `ToolSearch select:AskUserQuestion` first if unavailable; in Codex use `request_user_input`; where no blocking tool exists, fall back to numbered options in chat) so the user chooses against real alternatives instead of the agent deciding silently. In a non-interactive context, treat the pass as declined and record the recommended defaults as explicit assumptions the user can override later.\n\n## Integration Check Before Phase 1 Exit\n\nBefore exiting Phase 1, mentally combine what the user has stated so far. If stated-A + stated-B + agent-default-C produces a downstream effect the user is unlikely to have tracked (e.g., \"if mute lives on the rule AND we don't warn on delete, rule-delete silently loses pause state\"), fire one open probe per genuine combination. Phase 2.5's call-outs are a safety net for residuals — *not* a punt list for consequences you should have surfaced here.\n\nFile v4.5.3:references/design-and-handoff.md\n\n# Design capture and handoff\n\nRead when writing or reviewing a durable design. The entry point’s authority boundary also applies to commits and handoff.\n\n### Phase 3: Capture the Design\n\nSummarize key decisions in a structured format. For each major component, verify isolation and clarity: it must answer \"what does it do, how do you use it, what does it depend on?\" and be independently understandable and testable. If working in an existing codebase, note which existing patterns to follow and where targeted improvements fit naturally.\n\n**Design Doc:** Save to `docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md`. Required sections: What We're Building, Why This Approach, Key Decisions (with rationale), Open Questions, Next Steps. Collapse the Q&A interview log in a `<details>` block. Include YAML frontmatter with `date` and `topic`. Commit to git -- design decisions are project history.\n\n**Settled vs. directive — don't re-litigate.** A decision the user made with the alternative and its trade-off in view is **settled**: record it in Key Decisions with its rationale and carry it forward — do not re-ask it in Phase 3b, at planning, or during work. A cold **directive** (a choice asserted without anyone weighing it — \"build it with X\") earns exactly **one** in-pipeline challenge (one pass of the Phase 2 ideation lenses against that specific choice), then it too is recorded and not re-challenged at every downstream stage. A settled label never suppresses defect evidence — a real bug or infeasibility found *inside* a settled approach keeps full severity and is surfaced.\n\n### Phase 3b: Spec Self-Review\n\nRun this checklist before presenting the design doc. Any failure returns to Phase 2 or Phase 3, not Phase 4.\n\n- **Placeholder scan**: no TBD, \"figure out later\", \"appropriate error handling\", bracketed gaps, or tasks without concrete criteria.\n- **Internal consistency**: names, types, and verbs match across sections (no `createOrder()` in one place and `placeOrder()` in another).\n- **Scope containment**: every decision traces back to a stated goal; otherwise cut or surface as explicit scope expansion.\n- **Ambiguity sweep**: each Key Decision survives \"could a reasonable implementer interpret this two ways?\"\n- **Assumption validation**: every assumption names its validation method (\"we assume X — we'll confirm by Y\").\n- **Value sourcing**: enumerate every value the work must produce, compute, or display, and confirm the spec names each one's source (an input param, a stored field, a derivation from a named value, or a prior decision). A produced value with no named source is an owed design decision — surface it, don't invent it. Judge by positive enumeration, not introspection: \"show the user's local day\" that never says where the timezone comes from passes every other check yet hides an undecided source.\n- **Non-goals present**: the explicit \"Not Doing\" list exists and is specific.\n\nSilent pass is valid. Clean draft → move to Phase 4.\n\n### Phase 4: Review and Handoff\n\nPresent the design doc to the user for approval. The user explicitly confirming the design is the gate to proceed. When invoked via `/ia-brainstorm`, the command handles spec review dispatch and next-step orchestration.\n\n**Explicit headless mode:** return the design and unresolved assumptions to the caller. Handoff may continue only within the caller's delegated authority; report the design as caller-delegated, not user-approved.\n\n## Anti-Patterns to Avoid\n\n| Anti-Pattern | Better Approach |\n|--------------|-----------------|\n| Asking 5 questions at once | Ask one at a time across dimensions; cluster 2-3 within a dimension |\n| Jumping to implementation details | Stay focused on WHAT, not HOW |\n| Proposing overly complex solutions | Start simple, add complexity only if needed |\n| Ignoring existing codebase patterns | Research what exists first |\n| Making assumptions without validating | State assumptions explicitly and confirm |\n| Creating lengthy design documents | Keep it concise--details go in the plan |\n\n## Success Criteria\n\n- Design doc saved to `docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md`\n- Interactive mode: user approves the spec before handoff. Explicit headless mode: caller-delegated decisions and remaining assumptions are identified.\n- All open questions resolved or explicitly deferred with rationale\n\n## Integration\n\nBrainstorming answers WHAT to build. Planning answers HOW. When brainstorm output exists, `/ia-plan` (Claude Code) or the ia-planning skill detects it and skips idea refinement.\n\n- **Next step:** planning, always (`/ia-plan` in Claude Code; the `ia-planning` skill elsewhere)\n- **Threat modeling:** when the brainstorm involves auth, payments, external API surfaces, or multi-tenant data, suggest a `ia-security-sentinel` threat model before moving to planning. Catching trust boundary issues at the design stage prevents costly rework.\n- **Predecessor:** user request or ambiguous feature description\n\nFile v4.5.3:references/interview-and-approaches.md\n\n# Interview and approach selection\n\nRead when requirements need dialogue or multiple approaches need comparison. Headless execution follows the entry point’s caller-delegated decision scope.\n\n### Phase 1: Understand the Idea\n\n**User context calibration (before diving into the idea):**\n\nRead signals from the user's first message to calibrate communication register:\n- **Vocabulary**: Are they using technical terms (API, schema, migration) or describing experiences (it's slow, it breaks when...)?\n- **Framing**: Are they describing a solution (\"build a dashboard\") or a problem (\"I can't see what's happening\")?\n- **References**: Are they pointing to code, files, and patterns, or to analogies and comparisons (\"something like Notion\")?\n\nAdjust question style accordingly. Technical users get architecture-level probing. Non-technical users get experience-level probing. Don't ask about this calibration -- just do it. If signals are ambiguous, default to the vocabulary the user is already using.\n\n**Explore project context first:** Before asking questions, read existing files, docs, and recent commits related to the idea. Understanding what exists prevents asking questions the codebase already answers and grounds the conversation in reality. When the user's wording conflicts with what the code verifiably does (\"the retry queue\" when nothing retries; a table or endpoint named that doesn't exist), surface the conflict before treating the wording as settled -- silently adopting either side buries a requirements error.\n\nAsk questions **one at a time** by default. When probing a single dimension (e.g., data model, auth flow), clustering 2-3 related questions together is acceptable.\n\n**Facts vs decisions (mid-interview):** before asking, classify each candidate question. A fact (which table holds the field, whether an endpoint exists, what a library supports) is answered by inspecting code or docs, or a quick background lookup, not by asking the user. Reserve the blocking question tool for genuine trade-offs and preferences.\n\n**Premature solutions:** when the user proposes a solution before the requirements are understood, acknowledge it in one line and redirect to the requirement it serves; hold it as a candidate for Phase 2 rather than adopting it. Once Phase 2 has started, evaluate it alongside the other approaches instead of redirecting.\n\n**Info-dump gate (when user offers rich context up-front):** if the user's first message is substantial (>200 words, or dumps requirements in stream-of-consciousness), resist the urge to ask questions one-at-a-time. Instead, respond with 5-10 **numbered clarifying questions** the user can answer in shorthand (`1: yes, 2: channel #ops, 3: no because backwards compat`). Pick questions that remove ambiguity, not questions that show you read the dump. Exit this batched mode when the user's answers show they can be asked about edge cases without basics being explained back to them.\n\nExample after a spec dump:\n\n```\nBefore I propose approaches, quick clarifications:\n\n1. Auth — SSO (which provider?) or username/password?\n2. Sync or async for the webhook delivery?\n3. Which of the three integrations is P0?\n4. \"Fast enough\" in the spec — what's the actual number?\n\nAnswer whichever you know; leave blanks for the rest.\n```\n\n**Question Techniques:**\n\n1. **Prefer multiple choice when natural options exist.** Good: \"Notification: (a) email, (b) in-app, (c) both?\" Avoid: \"How should users be notified?\"\n2. **Start broad, then narrow.** Core purpose → users → constraints.\n3. **Validate assumptions and probe success early.** \"I'm assuming users are logged in — correct?\" / \"How will you know this is working?\"\n\n**Key Topics to Explore:**\n\n| Topic | Example Questions |\n|-------|-------------------|\n| Purpose | What problem does this solve? What's the motivation? |\n| Users | Who uses this? What's their context? |\n| Constraints | Any technical limitations? Timeline? Dependencies? |\n| Success | How will you measure success? What's the happy path? |\n| Edge Cases | What shouldn't happen? Any error states to consider? |\n| Existing Patterns | Are there similar features in the codebase to follow? |\n| Non-goals | What is explicitly NOT in scope? |\n\nSee [deep-interview.md](./deep-interview.md) for deep interview techniques, including **rigor probes** (evidence/specificity/counterfactual/attachment as open-ended forced production, not menus), the **blindspot pass** for domains the user can't evaluate, and the **integration check** that fires before Phase 1 exit when combining stated answers + agent defaults produces an unsurfaced downstream effect.\n\n**Exit Condition:** Continue until the idea is clear OR user says \"proceed\". Before moving to Phase 2, summarize understanding in 3-5 bullets and confirm with the user.\n\n### Phase 2: Explore Approaches\n\nAfter understanding the idea, propose 2-3 concrete approaches.\n\n**Structure for Each Approach:**\n\n```markdown\n### Approach A: [Name]\n\n[2-3 sentence description]\n\n**Pros:**\n- [Benefit 1]\n- [Benefit 2]\n\n**Cons:**\n- [Drawback 1]\n- [Drawback 2]\n\n**Best when:** [Circumstances where this approach shines]\n```\n\n**Guidelines:**\n- Lead with a recommendation and explain why\n- Be honest about trade-offs\n- Consider YAGNI--simpler is usually better\n- Reference codebase patterns when relevant\n- If no approach is accepted after 2 rounds, ask the user to describe their preferred direction directly\n\n**Ideation lenses** (use 2-3 to stress-test approaches when the design space is wide):\n- **Inversion**: What if we solved the opposite problem?\n- **Constraint removal**: What would we build if [biggest constraint] didn't exist?\n- **Simplification**: What's the version that ships in a day?\n- **10x version**: What if this needed to handle 10x the scale?\n- **Expert lens**: How would [domain expert] approach this?\n\n**\"Not Doing\" list:** Include an explicit list of what the chosen approach will NOT do. Focus is about saying no to good ideas. Make the trade-offs visible so they're a deliberate choice, not an oversight.\n\n**Assumptions with validation:** For each key assumption in the chosen approach, state how to test it. Not just \"we assume X\" but \"we assume X -- we'll know by [validation method].\"\n\nFile v4.5.3:references/scope-synthesis.md\n\n# Pre-write scope synthesis\n\nRead after substantive dialogue or when documenting a Standard/Deep design. Interaction mode and authority come from the skill entry point.\n\n### Phase 2.5: Pre-Write Scope Synthesis\n\nSurface the scope interpretation so the user can correct it before Phase 3 writes the design doc. Phase 2.5 catches scope misalignment before the doc is written; Phase 3b catches drafting issues after.\n\n**Two-stage shape: internal draft, then chat-time scoping synthesis.** Compose in two stages. Stage 1 is an internal three-bucket thinking pass (Stated / Inferred / Out of scope) for comprehensive scope analysis. Stage 2 is what the user sees — shaped like what two product collaborators would confirm before writing a PRD. The internal draft never reaches the user verbatim; it routes into the Phase 3 doc body.\n\n**Stage 1 — internal three-bucket draft (thinking, not output):**\n- **Stated** — what the user said directly. Explicit user-language anchors.\n- **Inferred** — gaps the agent filled with assumptions. Most actionable bucket; bets the user can correct.\n- **Out of scope** — deliberately excluded items.\n\nUse this as a thinking step. Do not paste it into chat.\n\n**Stage 2 — user-facing scoping synthesis.** Up to four named sections, each render-conditional. Empty sections are omitted, not padded:\n\n1. **What we're building** (always present) — 1-3 sentences. The shape that emerged from dialogue, forward-looking, plain words. Not a transcript of \"you said X\".\n2. **Key trade-offs** (conditional) — 1-3 bullets, each with a brief why. Render only when real trade-offs were made.\n3. **What's not in scope** (conditional) — 1-3 bullets, or fold into a sentence. Render only when deferred items would surprise a downstream reader if absent.\n4. **Call-outs** (conditional) — 0-3 bullets. Residual forks the dialogue didn't resolve: post-dialogue consequences, silent agent inferences, or — in pre-loaded contexts — scope bets the user is seeing for the first time. Not \"questions the agent could have asked during Phase 1 but didn't\" — if a call-out reads like a missed dialogue question, Phase 1's integration check failed; flag the gap.\n\nClose with: *\"Confirm and I'll write the design doc next. Or tell me what to change.\"*\n\n**Path A vs Path B gate.** Routing depends on TWO signals: (1) did any *blocking* question fire before Phase 2.5? AND (2) what tier did Phase 0 classify? Blocking questions = scope disambiguation, dialogue probes, approach selection menus. Internal classification and pressure-tests do not count.\n\n- **Path A** — Lightweight tier AND no blocking questions fired → announce-mode. Emit \"What we're building\" prose only (no other sections, no confirmation question), then proceed to Phase 3 doc-write in the same turn. Lightweight Path A docs are short; post-hoc revision is cheap.\n- **Path B** — Standard/Deep tier OR any blocking question fired → full synthesis with confirmation gate. Two scenarios fire Path B: the user invested answer-time in dialogue, or pre-loaded substantive scope content. Either way, the substance earns a real checkpoint. The tier guard catches pre-loaded Deep brainstorms that would otherwise shortcut via the no-questions branch.\n\n**Keep tests per section.** Each conditional section has its own keep test; failing items dissolve into the internal draft only.\n- **Trade-offs**: would the user be surprised if I didn't surface this acknowledgment? Mechanical or inevitable choices fail.\n- **Deferred**: is a reasonable downstream reader likely to ask \"why isn't X here?\" Mechanical excludes fail.\n- **Call-outs**: two-step test. (1) Affirmability: would the user need to read code to evaluate this? If yes, it's doc-body content — cut. (2) Keep only if it's a real scope fork, non-obvious inclusion/exclusion, cheap-now-expensive-later correction, or non-obvious consequence of combined multi-turn answers. (3) Phase 1 boundary: if the call-out depends only on Phase 1 facts (no Phase 2 approach, no later-surfaced default), Phase 1's integration check failed — cut and revisit Phase 1. Call-outs catch what Phase 1 *couldn't* surface, not what it *should have*.\n\nCut re-statements of Q&A turns, re-statements of the picked Phase 2 approach, mechanical items, and implementation choices that settle during planning.\n\n**Bullet budget across sections 2-4 combined.** Heuristic, not law — the real discipline is each section's keep test:\n\n| Tier | Typical total | Hard ceiling |\n|---|---|---|\n| Lightweight | 0-1 | 2 |\n| Standard | 2-4 | 5 |\n| Deep | 3-7 | 9 |\n\nAbove the ceiling means the synthesis is mis-shapen — re-cut at a higher level of abstraction, do not raise the cap.\n\n**Detail level: conversational, not documentary.** 1 line ideally, 2 max. Bullets that need semicolons stringing clauses or an internal list are two decisions sharing a bullet — split or drop.\n\n**Re-present after revision; write only on confirm.** If the user revises any bullet (even trivially), integrate the change, re-present, and wait for explicit confirmation. A revision is not a confirmation.\n\n**Explicit headless mode:** compose the synthesis without requesting confirmation. Route inferred items to `## Assumptions` in the Phase 3 doc with validation methods; do not label them user-approved decisions. Stated requirements and non-goals retain their source. Report any decision beyond the caller's delegated authority instead of silently choosing it.\n\nSkip Phase 2.5 entirely when Phase 0.2 detected requirements were already clear and the flow proceeded straight to summary without a Phase 1 dialogue. Path A handles every other Lightweight case.\n\nFile v4.5.3:skill-card.md\n\n## Description:\n\nGuides pre-implementation exploration through deep interview, approach comparison, and design documentation for vague feature ideas or ambiguous requirements.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[iliaal](https://clawhub.ai/user/iliaal)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineering or product collaborators use this workflow to clarify ambiguous feature ideas, compare implementation approaches, and capture design decisions before planning or coding.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Generated design notes may carry incorrect or misleading requirements into downstream planning or implementation.\n\nMitigation: Review scoped summaries and design documents before handoff; use explicit approval or caller-delegated headless scope for material decisions.\n\nRisk: The workflow may inspect project context and create persistent design notes, and may commit only when that authority is granted.\n\nMitigation: Limit the delegated scope, review generated files before downstream use, and only authorize commits when that matches the release workflow.\n\n## Reference(s):\n\n- [ClawHub Skill Page](https://clawhub.ai/iliaal/skills/compound-eng-brainstorming)\n- [ia-brainstorming Specification](SPEC.md)\n- [Deep Interview Layer](references/deep-interview.md)\n- [Design capture and handoff](references/design-and-handoff.md)\n- [Interview and approach selection](references/interview-and-approaches.md)\n- [Pre-write scope synthesis](references/scope-synthesis.md)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, guidance]\n\n**Output Format:** [Markdown with structured summaries and design documents]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May save a design document under docs/brainstorms/ and report decisions, assumptions, next steps, or unresolved questions.]\n\n## Skill Version(s):\n\n4.5.3 (source: server release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nFile v4.5.3:SPEC.md\n\n# ia-brainstorming Specification\n\n## Intent\n\n`ia-brainstorming` is a `workflow`-class skill (a multi-step process producing concrete artifacts). Pre-implementation exploration: deep interview, approach comparison, design doc. Use when exploring a vague feature idea, clarifying ambiguous requirements, or comparing approaches before coding. For the full workflow, use `/ia-brainstorm`.\n\n## Scope\n\nIn scope:\n- Behaviors described in `SKILL.md` and routed via the should_trigger phrasings in `distillery/tests/fixtures/triggers/ia-brainstorming.jsonl`.\n- Updates to runtime behavior, structure, trigger precision, references, and validation.\n\nOut of scope:\n- Acting as the runtime instructions themselves (those live in `SKILL.md`).\n- Trigger phrasings already covered by adjacent `ia-*` skills (`validate-plugin` flags >70% description overlap as DUPLICATE_TRIGGER).\n- <!-- to fill in: domain-specific exclusions when the skill drifts -->\n\n## Trigger Context\n\n- Class: `workflow`\n- Hook regex: `plugins/whetstone/hooks/skill-patterns.sh` -> `SKILL_PATTERNS[ia-brainstorming]`\n- Common requests (from fixture should_trigger):\n  - \"brainstorm ideas for the new notification system\"\n  - \"help me think through the authentication redesign\"\n  - \"I have a vague feature idea I want to explore before coding\"\n- Should not trigger for (from fixture should_not_trigger):\n  - \"add a new column to the users table\"\n  - \"fix the broken unit test in the auth module\"\n  - \"implement the feature exactly as specced\"\n\n## Source And Evidence Model\n\nAuthoritative sources:\n\n- `SKILL.md` -- runtime instructions and reference routing.\n- `references/*.md` -- bundled supplementary content (1 file(s)).\n- `distillery/tests/fixtures/triggers/ia-brainstorming.jsonl` -- positive and negative trigger phrasings under regression test.\n- `plugins/whetstone/hooks/skill-patterns.sh` -- regex pattern that fires this skill.\n- `distillery/.eval-data/ia-brainstorming/` -- harvested session examples (when present).\n\nData that must not be stored in this skill or its references:\n\n- Secrets, credentials, tokens.\n- Machine-specific filesystem paths (`/home/...`, `/Users/...`, `~/ai/...`). The validator (`MACHINE_PATH_LEAK`) flags these as HIGH.\n- Private URLs, customer data, or unredacted personal information.\n\n### Coverage matrix\n\n| Dimension | Status | Evidence |\n|---|---|---|\n| Trigger fixtures | complete | distillery/tests/fixtures/triggers/ia-brainstorming.jsonl (>=5 should_trigger, >=5 should_not_trigger) |\n| Hook regex pattern | complete | plugins/whetstone/hooks/skill-patterns.sh (`SKILL_PATTERNS[ia-brainstorming]`) |\n| Reference architecture | complete | 1 file(s) under references/ |\n| Real-usage signal | <!-- populated by harvest-sessions when sessions exist --> | distillery/.eval-data/ia-brainstorming/ (created by harvest-sessions) |\n\n## Evaluation\n\nLightweight (run on every change):\n\n```bash\npython3 distillery/scripts/distiller.py validate-plugin --component ia-brainstorming\npython3 distillery/scripts/distiller.py test-triggers --skill ia-brainstorming\n```\n\nDeeper (when behavior risk warrants):\n\n```bash\npython3 distillery/scripts/distiller.py dspy-eval ia-brainstorming\npython3 distillery/scripts/distiller.py diagnose-negatives ia-brainstorming\n```\n\nAcceptance gates:\n- Headless execution requires an explicit caller delegation and decision scope; invocation metadata alone preserves interactive approval gates.\n- `validate-plugin --component ia-brainstorming` returns 0 HIGH findings.\n- `test-triggers --skill ia-brainstorming` returns F1 = 1.0 with floors of 5 should_trigger and 5 should_not_trigger.\n- For dspy-eval, the composite score does not regress against the most recent saved baseline (see `distillery/.eval-data/ia-brainstorming/history.json`).\n\n## Known Limitations\n\n<!-- to fill in over time as drift surfaces. Default rule: any time diagnose-negatives\n     surfaces a recurring failure pattern, document it here so future maintainers\n     understand the trade-off the current implementation accepts. -->\n\n## Maintenance Notes\n\n- Update `SKILL.md` when the runtime workflow, branch conditions, or output contract changes.\n- Update this `SPEC.md` when intent, scope, evidence model, evaluation gates, or maintenance expectations change.\n- Update the trigger fixture when adding new positive phrasings, removing stale ones, or expanding scope (the 5/5 floor is a hard validator gate).\n- Update the hook regex in `skill-patterns.sh` whenever fixture positives expose a missed phrasing; verify F1 = 1.0 with `eval-triggers` before committing.\n- Run the full release pipeline via `/release` -- never bump versions or update CHANGELOG.md from a per-skill edit.\n\nArchive v4.5.2: 8 files, 17216 bytes\n\nFiles: references/deep-interview.md (5003b), references/design-and-handoff.md (4985b), references/interview-and-approaches.md (5559b), references/scope-synthesis.md (5656b), skill-card.md (2385b), SKILL.md (5430b), SPEC.md (4671b), _meta.json (145b)\n\nFile v4.5.2:SKILL.md\n\n---\nname: ia-brainstorming\nclass: workflow\ndescription: >-\n  Pre-implementation exploration: deep interview, approach comparison, design\n  doc. Use when exploring a vague feature idea, clarifying ambiguous\n  requirements, or comparing approaches before coding. For the full workflow,\n  use the ia-brainstorm command (Claude Code).\n---\n\n# Brainstorming\n\nClarify what to build before planning how to implement it.\n\n## Scope and interaction\n\nProduce exploration and a design, not implementation. Obtain approval before interactive handoff. Enable headless mode only when the caller explicitly delegates non-interactive execution and its decision scope; `disable-model-invocation` is selection metadata, not approval. Replace headless confirmations with stated conservative assumptions. Return material decisions without a safe authorized default unresolved. Never label inferred choices user-approved or infer implementation, commit, or publication authority from this skill.\n\nUse the active question mechanism for material questions: AskUserQuestion in Claude Code (load via ToolSearch `select:AskUserQuestion` when needed), request_user_input in Codex where supported, otherwise chat. Return missing decisions to the parent from an unattended worker.\n\n## Process\n\n1. **Assess and ground.** For an existing project, read relevant code, documentation, constraints, and recent commits before questions. Surface contradictions between the request and observed behavior. Skip repository research for abstract topics. Brainstorm ambiguous goals, competing interpretations, unresolved trade-offs, uncertain needs, solution-framed requests, or multiple independent subsystems. If requirements are clear, suggest planning or implementation without forcing dialogue.\n2. **Right-size and decompose.** A brainstorm resolved in three messages may need only a summary; sustained architectural work needs a durable design. For multiple independent subsystems, identify boundaries and dependencies, choose build order, then give each sub-project its own design → plan → implementation cycle. Start with the first sub-project.\n3. **Understand and compare.** When dialogue or approach selection is needed, read [interview-and-approaches.md](./references/interview-and-approaches.md). Match the user's vocabulary. Normally ask one question across dimensions, or two to three within one dimension; for a substantial initial dump (>200 words), use the reference's bounded batch. Explore purpose, users, constraints, success, edge cases, patterns, and non-goals. Apply [deep-interview.md](./references/deep-interview.md) when assumptions, evidence, unfamiliar domains, or combined answers need probing; its integration check applies before interview exit. Stop questioning when clear or told to proceed. Summarize in three to five bullets and confirm in interactive mode.\n4. **Choose an approach.** Compare two to three concrete alternatives with descriptions, pros, cons, and best-use conditions. Lead with the recommendation, reference existing patterns, and expose trade-offs. If none is accepted after two rounds, ask for the preferred direction. For a wide design space, use two to three lenses from the approach reference. State the chosen approach's explicit Not Doing list and a validation method for every key assumption.\n5. **Confirm interpreted scope.** Before writing after substantive dialogue, read [scope-synthesis.md](./references/scope-synthesis.md). Separate stated requirements, inferred assumptions, and exclusions internally; present only the reference's concise scoping synthesis. Lightweight work without blocking questions uses announce-mode; Standard/Deep work or any blocking dialogue requires interactive confirmation. Re-present revisions and await confirmation. In headless mode preserve sources and unresolved assumptions without prompts. Clear requirements that skipped dialogue need no synthesis checkpoint.\n6. **Capture and self-review.** For a durable artifact, read [design-and-handoff.md](./references/design-and-handoff.md). Save `docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md` with date/topic frontmatter, What We're Building, Why This Approach, Key Decisions and rationale, Open Questions, and Next Steps. Collapse interview history in a details block. Describe each component's purpose, usage, dependencies, and testable boundary. Commit only within caller authority.\n7. **Handoff.** Preserve settled decisions and their rationale rather than repeatedly challenging them; a cold directive gets one approach challenge. Neither label suppresses concrete defect or infeasibility evidence. Require consistent terminology, concrete criteria, scope traceability, unambiguous decisions, explicit non-goals, assumption validation, and a named source for every produced value. Return failures to approach selection or drafting. Present the design for interactive approval; return caller-delegated decisions and unresolved assumptions in headless mode.\n\n## Completion\n\nReturn the scoped summary or saved design path, decisions, and open questions resolved or explicitly deferred with reasons. Interactive approval precedes handoff; a headless handoff remains within caller authority. Planning (`ia-planning`, or `/ia-plan` in Claude Code) follows design and reuses its settled requirements. For auth, payments, external APIs, or multi-tenant data, suggest an available security threat-model review before planning.\n\nFile v4.5.2:_meta.json\n\n{\n  \"ownerId\": \"kn715jrbbh71q9zncr0bqdkr8n848q1a\",\n  \"slug\": \"compound-eng-brainstorming\",\n  \"version\": \"4.5.2\",\n  \"publishedAt\": 1788830905739\n}\n\nFile v4.5.2:references/deep-interview.md\n\n# Deep Interview Layer\n\nApply the deep interview protocol on top of the baseline questions above. Assumption probing and contradiction tracking always run. Research-backed challenges and second-order effects run when the scope warrants it (multi-system changes, infrastructure decisions, technology selection).\n\n**Assumption probing:** After each substantive answer, identify what the user assumed but didn't state. \"You described X -- are you assuming Y is already in place?\" Surface hidden dependencies and unstated constraints.\n\n**Second-order effects:** For features that touch shared infrastructure or data models, ask what success creates downstream. \"If this works and gets adopted, what pressure does it put on [related system]?\"\n\n**Research-backed challenges:** Fire background research on technology choices and claims. When findings contradict, challenge directly with citation. When findings support, briefly confirm to build confidence in the decision.\n\n**Contradiction tracking:** If the user's answer contradicts something said earlier, flag it immediately: \"Earlier you said X, but this implies Y. Which takes priority?\"\n\n**Anti-requirements:** When the user rejects an approach or says \"definitely not X,\" capture the rejection and rationale inline with the related decision. Don't force this -- capture organically when it surfaces.\n\n**Architecture-first ordering:** When several questions remain, ask the ones whose answers would change the *architecture* first -- data model shape, service boundaries, sync vs. async, auth model, storage engine. A question whose answer only affects a label, copy string, or default value can wait or take a reasonable default. Front-loading architecture-changing questions means a redirect lands before the design is built around a wrong assumption, not after.\n\n**Question clustering:** When probing a single dimension (e.g., data model, auth flow), ask 2-3 related questions together using AskUserQuestion's multi-question support. Switch to one-at-a-time when jumping between dimensions.\n\n**Completeness assessment:** Track which dimensions have been explored. Before proposing to move to Phase 2, assess coverage and signal confidence: \"We've covered purpose, users, and constraints well. Data flow and failure modes are still thin -- want to explore those, or proceed?\"\n\n## Rigor Probes for Ambiguous Gaps\n\nWhen a user answer leaves a gap on evidence, specificity, counterfactual, or attachment, fire ONE open-ended probe per gap — *not* a multiple-choice menu (exception: territory the user can't evaluate, where menus are the right tool — see Blindspot Pass below). Menus signal which axes the agent thinks matter, biasing the user toward those axes; open-ended forces actual observation:\n\n- **Evidence:** \"What's the most concrete thing someone's already done about this — paid for it, built a workaround, quit a tool over it?\"\n- **Specificity:** \"Can you name a team you've actually watched hit this, or are you reasoning?\"\n- **Counterfactual:** \"What do teams do today when this breaks — who reconciles?\"\n- **Attachment:** \"What's the smallest version that would still prove the bet right, and what's excluded?\"\n\nInterleave with narrowing moves; do not stack multiple probes in one turn.\n\n## Blindspot Pass for Unfamiliar Territory\n\nWhen the user signals they *cannot evaluate* a domain — explicit (\"I know nothing about auth\", \"no idea, you pick\") or implicit (deferring the same judgment-domain question to the agent 2+ times) — stop extracting guesses and map the decision surface for them instead.\n\nDistinguish **can't-evaluate** (no basis to choose) from **hasn't-decided** (has a basis, just hasn't picked). Only the first triggers this pass; a user who can weigh the options but is undecided gets the normal probes above. This guard keeps the pass from firing on every open question.\n\nScope the pass to the unfamiliar territory only, not the whole interview. List 3-7 decisions and hazards the user can't see, each with 2-3 concrete options and a recommended default, and present them with `AskUserQuestion` (load its schema via `ToolSearch select:AskUserQuestion` first if unavailable; in Codex use `request_user_input`; where no blocking tool exists, fall back to numbered options in chat) so the user chooses against real alternatives instead of the agent deciding silently. In a non-interactive context, treat the pass as declined and record the recommended defaults as explicit assumptions the user can override later.\n\n## Integration Check Before Phase 1 Exit\n\nBefore exiting Phase 1, mentally combine what the user has stated so far. If stated-A + stated-B + agent-default-C produces a downstream effect the user is unlikely to have tracked (e.g., \"if mute lives on the rule AND we don't warn on delete, rule-delete silently loses pause state\"), fire one open probe per genuine combination. Phase 2.5's call-outs are a safety net for residuals — *not* a punt list for consequences you should have surfaced here.\n\nFile v4.5.2:references/design-and-handoff.md\n\n# Design capture and handoff\n\nRead when writing or reviewing a durable design. The entry point’s authority boundary also applies to commits and handoff.\n\n### Phase 3: Capture the Design\n\nSummarize key decisions in a structured format. For each major component, verify isolation and clarity: it must answer \"what does it do, how do you use it, what does it depend on?\" and be independently understandable and testable. If working in an existing codebase, note which existing patterns to follow and where targeted improvements fit naturally.\n\n**Design Doc:** Save to `docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md`. Required sections: What We're Building, Why This Approach, Key Decisions (with rationale), Open Questions, Next Steps. Collapse the Q&A interview log in a `<details>` block. Include YAML frontmatter with `date` and `topic`. Commit to git -- design decisions are project history.\n\n**Settled vs. directive — don't re-litigate.** A decision the user made with the alternative and its trade-off in view is **settled**: record it in Key Decisions with its rationale and carry it forward — do not re-ask it in Phase 3b, at planning, or during work. A cold **directive** (a choice asserted without anyone weighing it — \"build it with X\") earns exactly **one** in-pipeline challenge (one pass of the Phase 2 ideation lenses against that specific choice), then it too is recorded and not re-challenged at every downstream stage. A settled label never suppresses defect evidence — a real bug or infeasibility found *inside* a settled approach keeps full severity and is surfaced.\n\n### Phase 3b: Spec Self-Review\n\nRun this checklist before presenting the design doc. Any failure returns to Phase 2 or Phase 3, not Phase 4.\n\n- **Placeholder scan**: no TBD, \"figure out later\", \"appropriate error handling\", bracketed gaps, or tasks without concrete criteria.\n- **Internal consistency**: names, types, and verbs match across sections (no `createOrder()` in one place and `placeOrder()` in another).\n- **Scope containment**: every decision traces back to a stated goal; otherwise cut or surface as explicit scope expansion.\n- **Ambiguity sweep**: each Key Decision survives \"could a reasonable implementer interpret this two ways?\"\n- **Assumption validation**: every assumption names its validation method (\"we assume X — we'll confirm by Y\").\n- **Value sourcing**: enumerate every value the work must produce, compute, or display, and confirm the spec names each one's source (an input param, a stored field, a derivation from a named value, or a prior decision). A produced value with no named source is an owed design decision — surface it, don't invent it. Judge by positive enumeration, not introspection: \"show the user's local day\" that never says where the timezone comes from passes every other check yet hides an undecided source.\n- **Non-goals present**: the explicit \"Not Doing\" list exists and is specific.\n\nSilent pass is valid. Clean draft → move to Phase 4.\n\n### Phase 4: Review and Handoff\n\nPresent the design doc to the user for approval. The user explicitly confirming the design is the gate to proceed. When invoked via `/ia-brainstorm`, the command handles spec review dispatch and next-step orchestration.\n\n**Explicit headless mode:** return the design and unresolved assumptions to the caller. Handoff may continue only within the caller's delegated authority; report the design as caller-delegated, not user-approved.\n\n## Anti-Patterns to Avoid\n\n| Anti-Pattern | Better Approach |\n|--------------|-----------------|\n| Asking 5 questions at once | Ask one at a time across dimensions; cluster 2-3 within a dimension |\n| Jumping to implementation details | Stay focused on WHAT, not HOW |\n| Proposing overly complex solutions | Start simple, add complexity only if needed |\n| Ignoring existing codebase patterns | Research what exists first |\n| Making assumptions without validating | State assumptions explicitly and confirm |\n| Creating lengthy design documents | Keep it concise--details go in the plan |\n\n## Success Criteria\n\n- Design doc saved to `docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md`\n- Interactive mode: user approves the spec before handoff. Explicit headless mode: caller-delegated decisions and remaining assumptions are identified.\n- All open questions resolved or explicitly deferred with rationale\n\n## Integration\n\nBrainstorming answers WHAT to build. Planning answers HOW. When brainstorm output exists, `/ia-plan` (Claude Code) or the ia-planning skill detects it and skips idea refinement.\n\n- **Next step:** planning, always (`/ia-plan` in Claude Code; the `ia-planning` skill elsewhere)\n- **Threat modeling:** when the brainstorm involves auth, payments, external API surfaces, or multi-tenant data, suggest a `ia-security-sentinel` threat model before moving to planning. Catching trust boundary issues at the design stage prevents costly rework.\n- **Predecessor:** user request or ambiguous feature description\n\nFile v4.5.2:references/interview-and-approaches.md\n\n# Interview and approach selection\n\nRead when requirements need dialogue or multiple approaches need comparison. Headless execution follows the entry point’s caller-delegated decision scope.\n\n### Phase 1: Understand the Idea\n\n**User context calibration (before diving into the idea):**\n\nRead signals from the user's first message to calibrate communication register:\n- **Vocabulary**: Are they using technical terms (API, schema, migration) or describing experiences (it's slow, it breaks when...)?\n- **Framing**: Are they describing a solution (\"build a dashboard\") or a problem (\"I can't see what's happening\")?\n- **References**: Are they pointing to code, files, and patterns, or to analogies and comparisons (\"something like Notion\")?\n\nAdjust question style accordingly. Technical users get architecture-level probing. Non-technical users get experience-level probing. Don't ask about this calibration -- just do it. If signals are ambiguous, default to the vocabulary the user is already using.\n\n**Explore project context first:** Before asking questions, read existing files, docs, and recent commits related to the idea. Understanding what exists prevents asking questions the codebase already answers and grounds the conversation in reality. When the user's wording conflicts with what the code verifiably does (\"the retry queue\" when nothing retries; a table or endpoint named that doesn't exist), surface the conflict before treating the wording as settled -- silently adopting either side buries a requirements error.\n\nAsk questions **one at a time** by default. When probing a single dimension (e.g., data model, auth flow), clustering 2-3 related questions together is acceptable.\n\n**Info-dump gate (when user offers rich context up-front):** if the user's first message is substantial (>200 words, or dumps requirements in stream-of-consciousness), resist the urge to ask questions one-at-a-time. Instead, respond with 5-10 **numbered clarifying questions** the user can answer in shorthand (`1: yes, 2: channel #ops, 3: no because backwards compat`). Pick questions that remove ambiguity, not questions that show you read the dump. Exit this batched mode when the user's answers show they can be asked about edge cases without basics being explained back to them.\n\nExample after a spec dump:\n\n```\nBefore I propose approaches, quick clarifications:\n\n1. Auth — SSO (which provider?) or username/password?\n2. Sync or async for the webhook delivery?\n3. Which of the three integrations is P0?\n4. \"Fast enough\" in the spec — what's the actual number?\n\nAnswer whichever you know; leave blanks for the rest.\n```\n\n**Question Techniques:**\n\n1. **Prefer multiple choice when natural options exist.** Good: \"Notification: (a) email, (b) in-app, (c) both?\" Avoid: \"How should users be notified?\"\n2. **Start broad, then narrow.** Core purpose → users → constraints.\n3. **Validate assumptions and probe success early.** \"I'm assuming users are logged in — correct?\" / \"How will you know this is working?\"\n\n**Key Topics to Explore:**\n\n| Topic | Example Questions |\n|-------|-------------------|\n| Purpose | What problem does this solve? What's the motivation? |\n| Users | Who uses this? What's their context? |\n| Constraints | Any technical limitations? Timeline? Dependencies? |\n| Success | How will you measure success? What's the happy path? |\n| Edge Cases | What shouldn't happen? Any error states to consider? |\n| Existing Patterns | Are there similar features in the codebase to follow? |\n| Non-goals | What is explicitly NOT in scope? |\n\nSee [deep-interview.md](./deep-interview.md) for deep interview techniques, including **rigor probes** (evidence/specificity/counterfactual/attachment as open-ended forced production, not menus), the **blindspot pass** for domains the user can't evaluate, and the **integration check** that fires before Phase 1 exit when combining stated answers + agent defaults produces an unsurfaced downstream effect.\n\n**Exit Condition:** Continue until the idea is clear OR user says \"proceed\". Before moving to Phase 2, summarize understanding in 3-5 bullets and confirm with the user.\n\n### Phase 2: Explore Approaches\n\nAfter understanding the idea, propose 2-3 concrete approaches.\n\n**Structure for Each Approach:**\n\n```markdown\n### Approach A: [Name]\n\n[2-3 sentence description]\n\n**Pros:**\n- [Benefit 1]\n- [Benefit 2]\n\n**Cons:**\n- [Drawback 1]\n- [Drawback 2]\n\n**Best when:** [Circumstances where this approach shines]\n```\n\n**Guidelines:**\n- Lead with a recommendation and explain why\n- Be honest about trade-offs\n- Consider YAGNI--simpler is usually better\n- Reference codebase patterns when relevant\n- If no approach is accepted after 2 rounds, ask the user to describe their preferred direction directly\n\n**Ideation lenses** (use 2-3 to stress-test approaches when the design space is wide):\n- **Inversion**: What if we solved the opposite problem?\n- **Constraint removal**: What would we build if [biggest constraint] didn't exist?\n- **Simplification**: What's the version that ships in a day?\n- **10x version**: What if this needed to handle 10x the scale?\n- **Expert lens**: How would [domain expert] approach this?\n\n**\"Not Doing\" list:** Include an explicit list of what the chosen approach will NOT do. Focus is about saying no to good ideas. Make the trade-offs visible so they're a deliberate choice, not an oversight.\n\n**Assumptions with validation:** For each key assumption in the chosen approach, state how to test it. Not just \"we assume X\" but \"we assume X -- we'll know by [validation method].\"\n\nFile v4.5.2:references/scope-synthesis.md\n\n# Pre-write scope synthesis\n\nRead after substantive dialogue or when documenting a Standard/Deep design. Interaction mode and authority come from the skill entry point.\n\n### Phase 2.5: Pre-Write Scope Synthesis\n\nSurface the scope interpretation so the user can correct it before Phase 3 writes the design doc. Phase 2.5 catches scope misalignment before the doc is written; Phase 3b catches drafting issues after.\n\n**Two-stage shape: internal draft, then chat-time scoping synthesis.** Compose in two stages. Stage 1 is an internal three-bucket thinking pass (Stated / Inferred / Out of scope) for comprehensive scope analysis. Stage 2 is what the user sees — shaped like what two product collaborators would confirm before writing a PRD. The internal draft never reaches the user verbatim; it routes into the Phase 3 doc body.\n\n**Stage 1 — internal three-bucket draft (thinking, not output):**\n- **Stated** — what the user said directly. Explicit user-language anchors.\n- **Inferred** — gaps the agent filled with assumptions. Most actionable bucket; bets the user can correct.\n- **Out of scope** — deliberately excluded items.\n\nUse this as a thinking step. Do not paste it into chat.\n\n**Stage 2 — user-facing scoping synthesis.** Up to four named sections, each render-conditional. Empty sections are omitted, not padded:\n\n1. **What we're building** (always present) — 1-3 sentences. The shape that emerged from dialogue, forward-looking, plain words. Not a transcript of \"you said X\".\n2. **Key trade-offs** (conditional) — 1-3 bullets, each with a brief why. Render only when real trade-offs were made.\n3. **What's not in scope** (conditional) — 1-3 bullets, or fold into a sentence. Render only when deferred items would surprise a downstream reader if absent.\n4. **Call-outs** (conditional) — 0-3 bullets. Residual forks the dialogue didn't resolve: post-dialogue consequences, silent agent inferences, or — in pre-loaded contexts — scope bets the user is seeing for the first time. Not \"questions the agent could have asked during Phase 1 but didn't\" — if a call-out reads like a missed dialogue question, Phase 1's integration check failed; flag the gap.\n\nClose with: *\"Confirm and I'll write the design doc next. Or tell me what to change.\"*\n\n**Path A vs Path B gate.** Routing depends on TWO signals: (1) did any *blocking* question fire before Phase 2.5? AND (2) what tier did Phase 0 classify? Blocking questions = scope disambiguation, dialogue probes, approach selection menus. Internal classification and pressure-tests do not count.\n\n- **Path A** — Lightweight tier AND no blocking questions fired → announce-mode. Emit \"What we're building\" prose only (no other sections, no confirmation question), then proceed to Phase 3 doc-write in the same turn. Lightweight Path A docs are short; post-hoc revision is cheap.\n- **Path B** — Standard/Deep tier OR any blocking question fired → full synthesis with confirmation gate. Two scenarios fire Path B: the user invested answer-time in dialogue, or pre-loaded substantive scope content. Either way, the substance earns a real checkpoint. The tier guard catches pre-loaded Deep brainstorms that would otherwise shortcut via the no-questions branch.\n\n**Keep tests per section.** Each conditional section has its own keep test; failing items dissolve into the internal draft only.\n- **Trade-offs**: would the user be surprised if I didn't surface this acknowledgment? Mechanical or inevitable choices fail.\n- **Deferred**: is a reasonable downstream reader likely to ask \"why isn't X here?\" Mechanical excludes fail.\n- **Call-outs**: two-step test. (1) Affirmability: would the user need to read code to evaluate this? If yes, it's doc-body content — cut. (2) Keep only if it's a real scope fork, non-obvious inclusion/exclusion, cheap-now-expensive-later correction, or non-obvious consequence of combined multi-turn answers. (3) Phase 1 boundary: if the call-out depends only on Phase 1 facts (no Phase 2 approach, no later-surfaced default), Phase 1's integration check failed — cut and revisit Phase 1. Call-outs catch what Phase 1 *couldn't* surface, not what it *should have*.\n\nCut re-statements of Q&A turns, re-statements of the picked Phase 2 approach, mechanical items, and implementation choices that settle during planning.\n\n**Bullet budget across sections 2-4 combined.** Heuristic, not law — the real discipline is each section's keep test:\n\n| Tier | Typical total | Hard ceiling |\n|---|---|---|\n| Lightweight | 0-1 | 2 |\n| Standard | 2-4 | 5 |\n| Deep | 3-7 | 9 |\n\nAbove the ceiling means the synthesis is mis-shapen — re-cut at a higher level of abstraction, do not raise the cap.\n\n**Detail level: conversational, not documentary.** 1 line ideally, 2 max. Bullets that need semicolons stringing clauses or an internal list are two decisions sharing a bullet — split or drop.\n\n**Re-present after revision; write only on confirm.** If the user revises any bullet (even trivially), integrate the change, re-present, and wait for explicit confirmation. A revision is not a confirmation.\n\n**Explicit headless mode:** compose the synthesis without requesting confirmation. Route inferred items to `## Assumptions` in the Phase 3 doc with validation methods; do not label them user-approved decisions. Stated requirements and non-goals retain their source. Report any decision beyond the caller's delegated authority instead of silently choosing it.\n\nSkip Phase 2.5 entirely when Phase 0.2 detected requirements were already clear and the flow proceeded straight to summary without a Phase 1 dialogue. Path A handles every other Lightweight case.\n\nFile v4.5.2:skill-card.md\n\n## Description:\n\nia-brainstorming guides pre-implementation exploration through deep interviews, approach comparison, and design-document capture for vague feature ideas, ambiguous requirements, or approach decisions before coding.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[iliaal](https://clawhub.ai/user/iliaal)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and product engineers use this skill to clarify vague feature ideas, compare implementation approaches, and produce a durable design artifact before planning or coding. It is suited to ambiguous requirements, competing interpretations, unresolved trade-offs, and multi-system feature exploration.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may preserve brainstorming output in the repository and may create a git commit when delegated.\n\nMitigation: Use it when a durable design artifact is intended, and delegate headless or commit authority only with a clear decision scope.\n\nRisk: Brainstorming output can turn unresolved assumptions into downstream planning or implementation direction.\n\nMitigation: Review the scoped summary, explicit assumptions, open questions, and design artifact before handing off to planning or coding.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/iliaal/skills/compound-eng-brainstorming)\n- [Deep Interview Layer](artifact/references/deep-interview.md)\n- [Interview and approach selection](artifact/references/interview-and-approaches.md)\n- [Pre-write scope synthesis](artifact/references/scope-synthesis.md)\n- [Design capture and handoff](artifact/references/design-and-handoff.md)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Files, Shell commands, Guidance]\n\n**Output Format:** [Markdown prose with optional saved design documents and shell commands]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May preserve brainstorming output in docs/brainstorms and may commit only when caller authority explicitly permits it.]\n\n## Skill Version(s):\n\n4.5.2 (source: server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nFile v4.5.2:SPEC.md\n\n# ia-brainstorming Specification\n\n## Intent\n\n`ia-brainstorming` is a `workflow`-class skill (a multi-step process producing concrete artifacts). Pre-implementation exploration: deep interview, approach comparison, design doc. Use when exploring a vague feature idea, clarifying ambiguous requirements, or comparing approaches before coding. For the full workflow, use `/ia-brainstorm`.\n\n## Scope\n\nIn scope:\n- Behaviors described in `SKILL.md` and routed via the should_trigger phrasings in `distillery/tests/fixtures/triggers/ia-brainstorming.jsonl`.\n- Updates to runtime behavior, structure, trigger precision, references, and validation.\n\nOut of scope:\n- Acting as the runtime instructions themselves (those live in `SKILL.md`).\n- Trigger phrasings already covered by adjacent `ia-*` skills (`validate-plugin` flags >70% description overlap as DUPLICATE_TRIGGER).\n- <!-- to fill in: domain-specific exclusions when the skill drifts -->\n\n## Trigger Context\n\n- Class: `workflow`\n- Hook regex: `plugins/whetstone/hooks/skill-patterns.sh` -> `SKILL_PATTERNS[ia-brainstorming]`\n- Common requests (from fixture should_trigger):\n  - \"brainstorm ideas for the new notification system\"\n  - \"help me think through the authentication redesign\"\n  - \"I have a vague feature idea I want to explore before coding\"\n- Should not trigger for (from fixture should_not_trigger):\n  - \"add a new column to the users table\"\n  - \"fix the broken unit test in the auth module\"\n  - \"implement the feature exactly as specced\"\n\n## Source And Evidence Model\n\nAuthoritative sources:\n\n- `SKILL.md` -- runtime instructions and reference routing.\n- `references/*.md` -- bundled supplementary content (1 file(s)).\n- `distillery/tests/fixtures/triggers/ia-brainstorming.jsonl` -- positive and negative trigger phrasings under regression test.\n- `plugins/whetstone/hooks/skill-patterns.sh` -- regex pattern that fires this skill.\n- `distillery/.eval-data/ia-brainstorming/` -- harvested session examples (when present).\n\nData that must not be stored in this skill or its references:\n\n- Secrets, credentials, tokens.\n- Machine-specific filesystem paths (`/home/...`, `/Users/...`, `~/ai/...`). The validator (`MACHINE_PATH_LEAK`) flags these as HIGH.\n- Private URLs, customer data, or unredacted personal information.\n\n### Coverage matrix\n\n| Dimension | Status | Evidence |\n|---|---|---|\n| Trigger fixtures | complete | distillery/tests/fixtures/triggers/ia-brainstorming.jsonl (>=5 should_trigger, >=5 should_not_trigger) |\n| Hook regex pattern | complete | plugins/whetstone/hooks/skill-patterns.sh (`SKILL_PATTERNS[ia-brainstorming]`) |\n| Reference architecture | complete | 1 file(s) under references/ |\n| Real-usage signal | <!-- populated by harvest-sessions when sessions exist --> | distillery/.eval-data/ia-brainstorming/ (created by harvest-sessions) |\n\n## Evaluation\n\nLightweight (run on every change):\n\n```bash\npython3 distillery/scripts/distiller.py validate-plugin --component ia-brainstorming\npython3 distillery/scripts/distiller.py test-triggers --skill ia-brainstorming\n```\n\nDeeper (when behavior risk warrants):\n\n```bash\npython3 distillery/scripts/distiller.py dspy-eval ia-brainstorming\npython3 distillery/scripts/distiller.py diagnose-negatives ia-brainstorming\n```\n\nAcceptance gates:\n- Headless execution requires an explicit caller delegation and decision scope; invocation metadata alone preserves interactive approval gates.\n- `validate-plugin --component ia-brainstorming` returns 0 HIGH findings.\n- `test-triggers --skill ia-brainstorming` returns F1 = 1.0 with floors of 5 should_trigger and 5 should_not_trigger.\n- For dspy-eval, the composite score does not regress against the most recent saved baseline (see `distillery/.eval-data/ia-brainstorming/history.json`).\n\n## Known Limitations\n\n<!-- to fill in over time as drift surfaces. Default rule: any time diagnose-negatives\n     surfaces a recurring failure pattern, document it here so future maintainers\n     understand the trade-off the current implementation accepts. -->\n\n## Maintenance Notes\n\n- Update `SKILL.md` when the runtime workflow, branch conditions, or output contract changes.\n- Update this `SPEC.md` when intent, scope, evidence model, evaluation gates, or maintenance expectations change.\n- Update the trigger fixture when adding new positive phrasings, removing stale ones, or expanding scope (the 5/5 floor is a hard validator gate).\n- Update the hook regex in `skill-patterns.sh` whenever fixture positives expose a missed phrasing; verify F1 = 1.0 with `eval-triggers` before committing.\n- Run the full release pipeline via `/release` -- never bump versions or update CHANGELOG.md from a per-skill edit.\n\nArchive v4.4.3: 5 files, 14281 bytes\n\nFiles: references/deep-interview.md (5003b), skill-card.md (2080b), SKILL.md (18406b), SPEC.md (4527b), _meta.json (145b)\n\nFile v4.4.3:SKILL.md\n\n---\nname: ia-brainstorming\nclass: workflow\ndescription: >-\n  Pre-implementation exploration: deep interview, approach comparison, design\n  doc. Use when exploring a vague feature idea, clarifying ambiguous\n  requirements, or comparing approaches before coding. For the full workflow,\n  use the ia-brainstorm command (Claude Code).\n---\n\n# Brainstorming\n\nClarify **WHAT** to build before **HOW** to build it.\n\n## Hard Gate\n\n**No implementation until the design is approved.** Brainstorming produces a design document, not code. Do not invoke implementation skills, write production code, or create files outside `docs/brainstorms/` until the user explicitly approves the design and moves to planning.\n\n## Core Process\n\n### Phase 0: Assess and Ground\n\nBefore diving into questions, do two things:\n\n**Ground in the codebase (when applicable).** If the brainstorm relates to existing code, read the relevant modules, patterns, and constraints before generating options. This prevents suggesting approaches that conflict with the actual architecture. Skip for purely abstract brainstorms (tech choices, product direction) where no codebase context applies.\n\n**Right-size the artifact.** Match ceremony to problem size. If the brainstorm resolves in 3 messages, don't force a formal design doc -- a summary comment is enough. If it spans multiple sessions and touches architecture, write the full Phase 3 doc. No ceremony tax.\n\n**Assess whether brainstorming is needed.** Brainstorm when any of these fire: vague terms (\"make it better\", \"add something like\"), multiple reasonable interpretations, undiscussed trade-offs, user uncertainty, solution-framing instead of problem-framing (\"build a dashboard\"), or request spanning multiple independent subsystems (decompose first — see Scope Decomposition below). Otherwise, requirements are clear — suggest: \"Your requirements seem clear. Consider proceeding directly to planning or implementation.\"\n\n### Scope Decomposition Gate\n\nIf the request describes multiple independent subsystems (e.g., \"build a platform with chat, file storage, billing, and analytics\"), flag this immediately. Don't spend questions refining details of a project that needs decomposition first.\n\n1. Identify the independent pieces and how they relate\n2. Determine build order (dependencies, shared infrastructure first)\n3. Brainstorm the first sub-project through the normal Phase 1-3 flow\n4. Each sub-project gets its own spec -> plan -> implementation cycle\n\n### Phase 1: Understand the Idea\n\n**User context calibration (before diving into the idea):**\n\nRead signals from the user's first message to calibrate communication register:\n- **Vocabulary**: Are they using technical terms (API, schema, migration) or describing experiences (it's slow, it breaks when...)?\n- **Framing**: Are they describing a solution (\"build a dashboard\") or a problem (\"I can't see what's happening\")?\n- **References**: Are they pointing to code, files, and patterns, or to analogies and comparisons (\"something like Notion\")?\n\nAdjust question style accordingly. Technical users get architecture-level probing. Non-technical users get experience-level probing. Don't ask about this calibration -- just do it. If signals are ambiguous, default to the vocabulary the user is already using.\n\n**Explore project context first:** Before asking questions, read existing files, docs, and recent commits related to the idea. Understanding what exists prevents asking questions the codebase already answers and grounds the conversation in reality. When the user's wording conflicts with what the code verifiably does (\"the retry queue\" when nothing retries; a table or endpoint named that doesn't exist), surface the conflict before treating the wording as settled -- silently adopting either side buries a requirements error.\n\nAsk questions **one at a time** by default. When probing a single dimension (e.g., data model, auth flow), clustering 2-3 related questions together is acceptable.\n\n**Info-dump gate (when user offers rich context up-front):** if the user's first message is substantial (>200 words, or dumps requirements in stream-of-consciousness), resist the urge to ask questions one-at-a-time. Instead\n\nArchive v4.3.2: 5 files, 14104 bytes\n\nFiles: references/deep-interview.md (5003b), skill-card.md (1896b), SKILL.md (18127b), SPEC.md (4527b), _meta.json (145b)\n\nArchive v4.3.1: 5 files, 14036 bytes\n\nFiles: references/deep-interview.md (5003b), skill-card.md (1863b), SKILL.md (18005b), SPEC.md (4527b), _meta.json (145b)\n\nArchive v4.2.1: 5 files, 13586 bytes\n\nFiles: references/deep-interview.md (5003b), skill-card.md (2071b), SKILL.md (16807b), SPEC.md (4527b), _meta.json (145b)\n\nArchive v4.2.0: 5 files, 12905 bytes\n\nFiles: references/deep-interview.md (3648b), skill-card.md (2014b), SKILL.md (16746b), SPEC.md (4527b), _meta.json (145b)\n\nArchive v4.0.3: 5 files, 12479 bytes\n\nFiles: references/deep-interview.md (3184b), skill-card.md (1678b), SKILL.md (16527b), SPEC.md (4527b), _meta.json (145b)","readmeExcerpt":"Skill: ia-brainstorming Owner: iliaal Summary: Pre-implementation exploration: deep interview, approach comparison, design doc. Use when exploring a vague feature idea, clarifying ambiguous requirements, or comparing approaches before coding. For the full workflow, use the ia-brainstorm command (Claude Code). Tags: latest:5.0.1 Version history: v5.0.1 | 2026-10-03T17:02:37.068Z | user v5.0.1 v5.0.0 | 2026-09-26T23:29","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"Before I propose approaches, quick clarifications:\n\n1. Auth — SSO (which provider?) or username/password?\n2. Sync or async for the webhook delivery?\n3. Which of the three integrations is P0?\n4. \"Fast enough\" in the spec — what's the actual number?\n\nAnswer whichever you know; leave blanks for the rest."},{"language":"markdown","snippet":"### Approach A: [Name]\n\n[2-3 sentence description]\n\n**Pros:**\n- [Benefit 1]\n- [Benefit 2]\n\n**Cons:**\n- [Drawback 1]\n- [Drawback 2]\n\n**Best when:** [Circumstances where this approach shines]"},{"language":"bash","snippet":"python3 distillery/scripts/distiller.py validate-plugin --component ia-brainstorming\npython3 distillery/scripts/distiller.py test-triggers --skill ia-brainstorming"},{"language":"bash","snippet":"python3 distillery/scripts/distiller.py dspy-eval ia-brainstorming\npython3 distillery/scripts/distiller.py diagnose-negatives ia-brainstorming"},{"language":"text","snippet":"Before I propose approaches, quick clarifications:\n\n1. Auth — SSO (which provider?) or username/password?\n2. Sync or async for the webhook delivery?\n3. Which of the three integrations is P0?\n4. \"Fast enough\" in the spec — what's the actual number?\n\nAnswer whichever you know; leave blanks for the rest."},{"language":"markdown","snippet":"### Approach A: [Name]\n\n[2-3 sentence description]\n\n**Pros:**\n- [Benefit 1]\n- [Benefit 2]\n\n**Cons:**\n- [Drawback 1]\n- [Drawback 2]\n\n**Best when:** [Circumstances where this approach shines]"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: ia-brainstorming\nclass: workflow\ndescription: >-\n  Pre-implementation exploration: deep interview, approach comparison, design\n  doc. Use when exploring a vague feature idea, clarifying ambiguous\n  requirements, or comparing approaches before coding. For the full workflow,\n  use the ia-brainstorm command (Claude Code).\n---\n\n# Brainstorming\n\nClarify what to build before planning how to implement it.\n\n## Scope and interaction\n\nProduce exploration and a design, not implementation. Obtain approval before interactive handoff. Enable headless mode only when the caller explicitly delegates non-interactive execution and its decision scope; `disable-model-invocation` is selection metadata, not approval. Replace headless confirmations with stated conservative assumptions. Return material decisions without a safe authorized default unresolved. Never label inferred choices user-approved or infer implementation, commit, or publication authority from this skill.\n\nUse the active question mechanism for material questions: AskUserQuestion in Claude Code (load via ToolSearch `select:AskUserQuestion` when needed), request_user_input in Codex where supported, otherwise chat. Return missing decisions to the parent from an unattended worker.\n\n## Process\n\n1. **Assess and ground.** For an existing project, read relevant code, documentation, constraints, and recent commits before questions. Surface contradictions between the request and observed behavior. Skip repository research for abstract topics. Brainstorm ambiguous goals, competing interpretations, unresolved trade-offs, uncertain needs, solution-framed requests, or multiple independent subsystems. If requirements are clear, suggest planning or implementation without forcing dialogue.\n2. **Right-size and decompose.** A brainstorm resolved in three messages may need only a summary; sustained architectural work needs a durable design. For multiple independent subsystems, identify boundaries and dependencies, choose build order, then give each sub-project its own design → plan → implementation cycle. Start with the first sub-project.\n3. **Understand and compare.** When dialogue or approach selection is needed, read [interview-and-approaches.md](./references/interview-and-approaches.md). Match the user's vocabulary. Normally ask one question across dimensions, or two to three within one dimension; for a substantial initial dump (>200 words), use the reference's bounded batch. Explore purpose, users, constraints, success, edge cases, patterns, and non-goals. Apply [deep-interview.md](./references/deep-interview.md) when assumptions, evidence, unfamiliar domains, or combined answers need probing; its integration check applies before interview exit. Stop questioning when clear or told to proceed. Summarize in three to five bullets and confirm in interactive mode.\n4. **Choose an approach.** Compare two to three concrete alternatives with descriptions, pros, cons, and best-use conditions. Lead with the recommendat"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn715jrbbh71q9zncr0bqdkr8n848q1a\",\n  \"slug\": \"compound-eng-brainstorming\",\n  \"version\": \"5.0.1\",\n  \"publishedAt\": 1791046957068\n}"},{"path":"references/deep-interview.md","content":"# Deep Interview Layer\n\nApply the deep interview protocol on top of the baseline questions above. Assumption probing and contradiction tracking always run. Research-backed challenges and second-order effects run when the scope warrants it (multi-system changes, infrastructure decisions, technology selection).\n\n**Assumption probing:** After each substantive answer, identify what the user assumed but didn't state. \"You described X. Are you assuming Y is already in place?\" Surface hidden dependencies and unstated constraints.\n\n**Second-order effects:** For features that touch shared infrastructure or data models, ask what success creates downstream. \"If this works and gets adopted, what pressure does it put on [related system]?\"\n\n**Research-backed challenges:** Fire background research on technology choices and claims. When findings contradict, challenge directly with citation. When findings support, briefly confirm to build confidence in the decision.\n\n**Contradiction tracking:** If the user's answer contradicts something said earlier, flag it immediately: \"Earlier you said X, but this implies Y. Which takes priority?\"\n\n**Anti-requirements:** When the user rejects an approach or says \"definitely not X,\" capture the rejection and rationale inline with the related decision. Don't force this; capture organically when it surfaces.\n\n**Architecture-first ordering:** When several questions remain, ask the ones whose answers would change the *architecture* first: data model shape, service boundaries, sync vs. async, auth model, storage engine. A question whose answer only affects a label, copy string, or default value can wait or take a reasonable default. Front-loading architecture-changing questions means a redirect lands before the design is built around a wrong assumption, not after.\n\n**Question clustering:** When probing a single dimension (e.g., data model, auth flow), ask 2-3 related questions together using AskUserQuestion's multi-question support. Switch to one-at-a-time when jumping between dimensions.\n\n**Completeness assessment:** Track which dimensions have been explored. Before proposing to move to Phase 2, assess coverage and signal confidence: \"We've covered purpose, users, and constraints well. Data flow and failure modes are still thin. Want to explore those, or proceed?\"\n\n## Rigor Probes for Ambiguous Gaps\n\nWhen a user answer leaves a gap on evidence, specificity, counterfactual, or attachment, fire ONE open-ended probe per gap, *not* a multiple-choice menu (exception: territory the user can't evaluate, where menus are the right tool; see Blindspot Pass below). Menus signal which axes the agent thinks matter, biasing the user toward those axes; open-ended forces actual observation:\n\n- **Evidence:** \"What's the most concrete thing someone's already done about this? Paid for it, built a workaround, quit a tool over it?\"\n- **Specificity:** \"Can you name a team you've actually watched hit this, or are you reasoning?\"\n- **Counterfactual:** \"Wh"},{"path":"references/design-and-handoff.md","content":"# Design capture and handoff\n\nRead when writing or reviewing a durable design. The entry point’s authority boundary also applies to commits and handoff.\n\n### Phase 3: Capture the Design\n\nSummarize key decisions in a structured format. For each major component, verify isolation and clarity: it must answer \"what does it do, how do you use it, what does it depend on?\" and be independently understandable and testable. If working in an existing codebase, note which existing patterns to follow and where targeted improvements fit naturally.\n\n**Design Doc:** Save to `docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md`. Required sections: What We're Building, Why This Approach, Key Decisions (with rationale), Open Questions, Next Steps. Collapse the Q&A interview log in a `<details>` block. Include YAML frontmatter with `date` and `topic`. Commit to git; design decisions are project history.\n\n**Settled vs. directive: don't re-litigate.** A decision the user made with the alternative and its trade-off in view is **settled**: record it in Key Decisions with its rationale and carry it forward. Do not re-ask it in Phase 3b, at planning, or during work. A cold **directive** (a choice asserted without anyone weighing it, e.g. \"build it with X\") earns exactly **one** in-pipeline challenge (one pass of the Phase 2 ideation lenses against that specific choice), then it too is recorded and not re-challenged at every downstream stage. A settled label never suppresses defect evidence: a real bug or infeasibility found *inside* a settled approach keeps full severity and is surfaced.\n\n### Phase 3b: Spec Self-Review\n\nRun this checklist before presenting the design doc. Any failure returns to Phase 2 or Phase 3, not Phase 4.\n\n- **Placeholder scan**: no TBD, \"figure out later\", \"appropriate error handling\", bracketed gaps, or tasks without concrete criteria.\n- **Internal consistency**: names, types, and verbs match across sections (no `createOrder()` in one place and `placeOrder()` in another).\n- **Scope containment**: every decision traces back to a stated goal; otherwise cut or surface as explicit scope expansion.\n- **Ambiguity sweep**: each Key Decision survives \"could a reasonable implementer interpret this two ways?\"\n- **Assumption validation**: every assumption names its validation method (\"we assume X; we'll confirm by Y\").\n- **Value sourcing**: enumerate every value the work must produce, compute, or display, and confirm the spec names each one's source (an input param, a stored field, a derivation from a named value, or a prior decision). A produced value with no named source is an owed design decision; surface it, don't invent it. Judge by positive enumeration, not introspection: \"show the user's local day\" that never says where the timezone comes from passes every other check yet hides an undecided source.\n- **Non-goals present**: the explicit \"Not Doing\" list exists and is specific.\n\nSilent pass is valid. Clean draft → move to Phase 4.\n\n### Phase 4: Review and "},{"path":"references/interview-and-approaches.md","content":"# Interview and approach selection\n\nRead when requirements need dialogue or multiple approaches need comparison. Headless execution follows the entry point’s caller-delegated decision scope.\n\n### Phase 1: Understand the Idea\n\n**User context calibration (before diving into the idea):**\n\nRead signals from the user's first message to calibrate communication register:\n- **Vocabulary**: Are they using technical terms (API, schema, migration) or describing experiences (it's slow, it breaks when...)?\n- **Framing**: Are they describing a solution (\"build a dashboard\") or a problem (\"I can't see what's happening\")?\n- **References**: Are they pointing to code, files, and patterns, or to analogies and comparisons (\"something like Notion\")?\n\nAdjust question style accordingly. Technical users get architecture-level probing. Non-technical users get experience-level probing. Don't ask about this calibration; just do it. If signals are ambiguous, default to the vocabulary the user is already using.\n\n**Explore project context first:** Before asking questions, read existing files, docs, and recent commits related to the idea. Understanding what exists prevents asking questions the codebase already answers and grounds the conversation in reality. When the user's wording conflicts with what the code verifiably does (\"the retry queue\" when nothing retries; a table or endpoint named that doesn't exist), surface the conflict before treating the wording as settled. Silently adopting either side buries a requirements error.\n\nAsk questions **one at a time** by default. When probing a single dimension (e.g., data model, auth flow), clustering 2-3 related questions together is acceptable.\n\n**Facts vs decisions (mid-interview):** before asking, classify each candidate question. A fact (which table holds the field, whether an endpoint exists, what a library supports) is answered by inspecting code or docs, or a quick background lookup, not by asking the user. Reserve the blocking question tool for genuine trade-offs and preferences.\n\n**Premature solutions:** when the user proposes a solution before the requirements are understood, acknowledge it in one line and redirect to the requirement it serves; hold it as a candidate for Phase 2 rather than adopting it. Once Phase 2 has started, evaluate it alongside the other approaches instead of redirecting.\n\n**Info-dump gate (when user offers rich context up-front):** if the user's first message is substantial (>200 words, or dumps requirements in stream-of-consciousness), resist the urge to ask questions one-at-a-time. Instead, respond with 5-10 **numbered clarifying questions** the user can answer in shorthand (`1: yes, 2: channel #ops, 3: no because backwards compat`). Pick questions that remove ambiguity, not questions that show you read the dump. Exit this batched mode when the user's answers show they can be asked about edge cases without basics being explained back to them.\n\nExample after a spec dump:\n\n```\nBefore I propose app"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Pre-implementation exploration: deep interview, approach comparison, design doc. Use when exploring a vague feature idea, clarifying ambiguous requirements, or comparing approaches before coding. For the full workflow, use the ia-brainstorm command (Claude Code). Skill: ia-brainstorming Owner: iliaal Summary: Pre-implementation exploration: deep interview, approach comparison, design doc. Use when exploring a vague feature idea, clarifying ambiguous requirements, or comparing approaches before coding. For the full workflow, use the ia-brainstorm command (Claude Code). Tags: latest:5.0.1 Version history: v5.0.1 | 2026-10-03T17:02:37.068Z | user v5.0.1 v5.0.0 | 2026-09-26T23:29","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":2079,"uniquenessScore":50,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-09T13:18:17.909Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-09T13:18:17.909Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-09T19:55:10.251Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}