What makes ia-brainstorming notable?

2.6K downloads. Trust evidence available

How should ia-brainstorming be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

Claim this agent

agentCLAWHUBUnverified

ia-brainstorming

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

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

2.6k

Updated

Oct 9, 2026

Version

5.0.1

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 2.6K downloads reported by the source. Last updated 10/9/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 9, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 9, 2026
Adoption signal: 2.6K downloadsadoption · observed Oct 9, 2026
Latest release: 5.0.1release · observed Oct 3, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s17bcar8wq0xhegs0ny6f57ypd8484bw:compound-eng-brainstorming

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: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-iliaal-compound-eng-brainstorming/snapshot"

Documentation

CLAWHUB

144,796 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: ia-brainstorming
class: workflow
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).
---

# Brainstorming

Clarify what to build before planning how to implement it.

## Scope and interaction

Produce 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.

Use 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.

## Process

1. **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.
2. **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.
3. **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.
4. **Choose an approach.** Compare two to three concrete alternatives with descriptions, pros, cons, and best-use conditions. Lead with the recommendat

_meta.json

{
  "ownerId": "kn715jrbbh71q9zncr0bqdkr8n848q1a",
  "slug": "compound-eng-brainstorming",
  "version": "5.0.1",
  "publishedAt": 1791046957068
}

references/deep-interview.md

# Deep Interview Layer

Apply 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).

**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.

**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]?"

**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.

**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?"

**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.

**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.

**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.

**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?"

## Rigor Probes for Ambiguous Gaps

When 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:

- **Evidence:** "What's the most concrete thing someone's already done about this? Paid for it, built a workaround, quit a tool over it?"
- **Specificity:** "Can you name a team you've actually watched hit this, or are you reasoning?"
- **Counterfactual:** "Wh

references/design-and-handoff.md

# Design capture and handoff

Read when writing or reviewing a durable design. The entry point’s authority boundary also applies to commits and handoff.

### Phase 3: Capture the Design

Summarize 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.

**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.

**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.

### Phase 3b: Spec Self-Review

Run this checklist before presenting the design doc. Any failure returns to Phase 2 or Phase 3, not Phase 4.

- **Placeholder scan**: no TBD, "figure out later", "appropriate error handling", bracketed gaps, or tasks without concrete criteria.
- **Internal consistency**: names, types, and verbs match across sections (no `createOrder()` in one place and `placeOrder()` in another).
- **Scope containment**: every decision traces back to a stated goal; otherwise cut or surface as explicit scope expansion.
- **Ambiguity sweep**: each Key Decision survives "could a reasonable implementer interpret this two ways?"
- **Assumption validation**: every assumption names its validation method ("we assume X; we'll confirm by Y").
- **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.
- **Non-goals present**: the explicit "Not Doing" list exists and is specific.

Silent pass is valid. Clean draft → move to Phase 4.

### Phase 4: Review and

references/interview-and-approaches.md

# Interview and approach selection

Read when requirements need dialogue or multiple approaches need comparison. Headless execution follows the entry point’s caller-delegated decision scope.

### Phase 1: Understand the Idea

**User context calibration (before diving into the idea):**

Read signals from the user's first message to calibrate communication register:
- **Vocabulary**: Are they using technical terms (API, schema, migration) or describing experiences (it's slow, it breaks when...)?
- **Framing**: Are they describing a solution ("build a dashboard") or a problem ("I can't see what's happening")?
- **References**: Are they pointing to code, files, and patterns, or to analogies and comparisons ("something like Notion")?

Adjust 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.

**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.

Ask 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.

**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.

**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.

**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.

Example after a spec dump:

```
Before I propose app

Github ReposUpdated 6mo agoRank 70

activepieces

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

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

AionUi

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!

MCPOPENCLAW

Github ReposUpdated 7mo agoRank 70

CopilotKit

The Frontend for Agents & Generative UI. React + Angular

OPENCLAW

Machine-readable data

The same record, as JSON, for agents and crawlers.

{
  "facts": [
    {
      "factKey": "vendor",
      "category": "vendor",
      "label": "Vendor",
      "value": "Clawhub",
      "href": "https://clawhub.ai/iliaal/skills/compound-eng-brainstorming",
      "sourceUrl": "https://clawhub.ai/iliaal/skills/compound-eng-brainstorming",
      "sourceType": "profile",
      "confidence": "medium",
      "observedAt": "2026-10-09T13:18:17.909Z",
      "isPublic": true
    },
    {
      "factKey": "protocols",
      "category": "compatibility",
      "label": "Protocol compatibility",
      "value": "OpenClaw",
      "href": "https://www.xpersona.co/api/v1/agents/clawhub-iliaal-compound-eng-brainstorming/contract",
      "sourceUrl": "https://www.xpersona.co/api/v1/agents/clawhub-iliaal-compound-eng-brainstorming/contract",
      "sourceType": "contract",
      "confidence": "medium",
      "observedAt": "2026-10-09T13:18:17.909Z",
      "isPublic": true
    },
    {
      "factKey": "traction",
      "category": "adoption",
      "label": "Adoption signal",
      "value": "2.6K downloads",
      "href": "https://clawhub.ai/iliaal/compound-eng-brainstorming",
      "sourceUrl": "https://clawhub.ai/iliaal/compound-eng-brainstorming",
      "sourceType": "profile",
      "confidence": "medium",
      "observedAt": "2026-10-09T13:18:17.909Z",
      "isPublic": true
    },
    {
      "factKey": "latest_release",
      "category": "release",
      "label": "Latest release",
      "value": "5.0.1",
      "href": "https://clawhub.ai/iliaal/compound-eng-brainstorming",
      "sourceUrl": "https://clawhub.ai/iliaal/compound-eng-brainstorming",
      "sourceType": "release",
      "confidence": "medium",
      "observedAt": "2026-10-03T17:02:37.068Z",
      "isPublic": true
    },
    {
      "factKey": "handshake_status",
      "category": "security",
      "label": "Handshake status",
      "value": "UNKNOWN",
      "href": "https://www.xpersona.co/api/v1/agents/clawhub-iliaal-compound-eng-brainstorming/trust",
      "sourceUrl": "https://www.xpersona.co/api/v1/agents/clawhub-iliaal-compound-eng-brainstorming/trust",
      "sourceType": "trust",
      "confidence": "medium",
      "observedAt": null,
      "isPublic": true
    }
  ],
  "events": [
    {
      "eventType": "release",
      "title": "Release 5.0.1",
      "description": "v5.0.1",
      "href": "https://clawhub.ai/iliaal/compound-eng-brainstorming",
      "sourceUrl": "https://clawhub.ai/iliaal/compound-eng-brainstorming",
      "sourceType": "release",
      "confidence": "medium",
      "observedAt": "2026-10-03T17:02:37.068Z",
      "isPublic": true
    }
  ]
}

Record generated Oct 9, 2026.

About

Avoid when

Public facts

Install and run

Documentation

Extracted files

SKILL.md

_meta.json

references/deep-interview.md

references/design-and-handoff.md

references/interview-and-approaches.md

Related agents

activepieces

cherry-studio

AionUi

CopilotKit

Machine-readable data