t1k:brainstorm

Auto-generated

🔒 Auto-generated from The1Studio/[email protected] — edit the source kit, not this page.

Field	Value
Module	t1k-extended
Version	3.5.0
Effort	medium
Tools	Agent, AskUserQuestion, Bash, Edit, Glob, Grep, Read, Skill, Task, Write

Keywords: alternatives, approach, explore, ideas, ideation, options

How to invoke

/t1k:brainstorm
[topic or problem] [--advice]

---

TheOneKit Brainstorm — Generic Ideation

Context-aware brainstorming. Routes to registered t1k-brainstormer agent via routing protocol.

Principles: YAGNI, KISS, DRY | Token efficiency | Concise reports

Tool guard — AskUserQuestion is deferred

AskUserQuestion is a deferred tool: its name appears in the deferred-tools system-reminder but its schema is NOT loaded at session start. Direct invocation fails with InputValidationError.

Operational pre-step (mandatory before drafting any structured multi-option question):

1. Verify AskUserQuestion is in the loaded tool list. If not, run:

   ToolSearch(query="select:AskUserQuestion", max_results=1)

2. THEN draft and invoke the tool with batched options.

Failure mode this guard prevents: assistant remembers the rule, drafts the question correctly in its head, then because the tool isn’t loaded, falls back to “I’ll just write the options as prose, and call the tool next time.” Drafting prose bullets first is a violation — see rules/always-ask-on-unresolved.md “Forbidden prose” table. Especially relevant in brainstorm endgame: “Open questions before I write the plan” lists are the canonical violation pattern.

Advisory supervision (--advice)

Full contract: skills/t1k-cook/references/advisory-supervision.md — invocation, forward-carry, PR gate, empty-counsel fallback, and the “never bypasses a gate” clause. Read it before firing the first checkpoint.

Brainstorm-specific checkpoints, on top of the three universal ones:

• After the option set is generated, before ranking — pass every option with its tradeoff row; ask which option is missing and which is weaker than it looks.
• Before presenting the design for approval — pass the recommended option and its rationale; ask what would change the recommendation. Counsel informs the recommendation; the HARD-GATE still requires the user’s approval before any implementation action.

Forward-carry --advice into the /t1k:plan or /t1k:cook handoff so supervision survives it.

Related but distinct: /t1k:advise interviews the user one question at a time to reframe a fuzzy problem; --advice here supervises this skill’s own option generation without a user round-trip.

Agent Routing

Follow protocol: skills/t1k-cook/references/routing-protocol.md This command uses role: t1k-brainstormer

Skill Activation

Follow protocol: skills/t1k-cook/references/activation-protocol.md

Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY brainstorming session regardless of perceived simplicity. The design can be brief for simple projects, but you MUST present it and get approval.

Anti-Rationalization

Anti-rationalization discipline: see rules/agent-anti-rationalization.md (auto-loaded).

Process Flow (Authoritative)

flowchart TD
    A[Scout Project Context] --> B[Ask Clarifying Questions]
    B --> C{Scope too large?}
    C -->|Yes| D[Decompose into Sub-Projects]
    D --> B
    C -->|No| E[Propose 2-3 Approaches]
    E --> F[Present Design Sections]
    F --> G{User Approves?}
    G -->|No| F
    G -->|Yes| H[Write Design Doc / Report]
    H --> I{Create Plan?}
    I -->|Yes| J[Invoke /t1k:plan]
    I -->|No| K[End Session]

This diagram is the authoritative workflow. If prose conflicts with this flow, follow the diagram.

Process Steps

1. Scout Phase: Use /t1k:scout to discover relevant files and code patterns, read relevant docs in <project-dir>/docs directory
2. Discovery Phase: Use AskUserQuestion to ask clarifying questions about requirements, constraints, timeline, and success criteria
3. Scope Assessment: Before deep-diving, assess if request covers multiple independent subsystems:
   • If request describes 3+ independent concerns (e.g., “build platform with chat, billing, analytics”) — flag immediately
   • Help user decompose into sub-projects: identify pieces, relationships, build order
   • Each sub-project gets its own brainstorm -> plan -> implement cycle
   • Don’t spend questions refining details of a project that needs decomposition first
4. Research Phase: Spawn t1k-researcher agents for relevant patterns and industry practices. Before the option set is produced (step 6), run the corpus sweep and emit the ## Reuse Ledger below — a capability that already ships is not an option.
5. Analysis Phase: Evaluate multiple approaches with project-specific criteria
6. Debate Phase: Present options with tradeoffs table via AskUserQuestion
7. Consensus Phase: Align on approach and document decisions
   • MANDATORY: If ANY open question remains at design-presentation time — ALWAYS invoke AskUserQuestion (batch up to 4 per call). NEVER list open questions as prose bullets followed by “pick one”. This applies to questions raised AFTER the main debate too, not just during step 6. See rules/always-ask-on-unresolved.md → “Failure mode — post-design open questions” for the exact pattern to avoid.
8. Documentation Phase: Report to plans/reports/ using naming pattern from injected context
9. Finalize Phase: Use AskUserQuestion to ask if user wants /t1k:plan
   • If Yes: Run /t1k:plan with the brainstorm summary context as the argument
   • If No: End the session

Reuse Ledger (MANDATORY)

Ideation is the moment this matters most and the one place it was missing. Before producing the option set, sweep the studio corpus for what already ships: spawn t1k-corpus-scout, or call mcp__knowledge-retrieval__doc_search directly if you hold the tool. An option that duplicates a shipped capability is not an option — it is a rebuild, and it will not be recognised as one later, because nobody proposing to build something ever says “greenfield”.

Same ruling gate as the t1k:plan skill’s ## Reuse Ledger — see skills/t1k-plan/SKILL.md for the table format, the four verdicts, and the exact reuse-search:/scope: token lines; cite it, do not restate it here. One brainstorm-specific addendum: during ideation the evidence for a REUSE row may be provisional (a capability, not yet a file:line) — but a provisional REUSE must still name the capability.

A ledger with zero REUSE/EXTEND rows on a non-trivial feature is a red flag, not a result — it usually means the search was too narrow.

Evaluation Criteria (apply to every idea)

• Reusability: shared library vs project-only code?
• Maintainability: does this reduce or increase complexity?
• Testability: can this be unit-tested?

Output Requirements

When brainstorming concludes with agreement, create a detailed summary report including:

• Problem statement and requirements
• Evaluated approaches with pros/cons
• Final recommended solution with rationale
• Implementation considerations and risks
• Success metrics and validation criteria
• Next steps and dependencies

Sacrifice grammar for the sake of concision when writing outputs.

Skill Inventory Injection (if installedModules or modules present in metadata.json)

Same pattern as /t1k:plan:

1. Read .claude/metadata.json -> installed modules
2. Read ALL t1k-activation-*.json -> skill names grouped by module
3. Inject inventory into t1k-brainstormer prompt (names only, not activation)

When brainstorming, check inventory for:

• Existing solutions (skill already covers this -> reuse)
• Module gaps (no skill for this domain -> suggest new skill)
• Cross-module opportunities (spans 2+ modules -> flag boundary decision)

Module-Aware Feasibility (if installedModules or modules present in metadata.json)

• Check if installed module already provides this capability
• Check if AVAILABLE (not installed) module solves this
• If proposing new skills, identify which module they belong to

Subagent Skill Injection (if installedModules present in metadata.json)

Follow protocol: skills/t1k-cook/references/subagent-injection-protocol.md Before spawning t1k-brainstormer agent, inject module context.

Critical Constraints

• DO NOT implement — brainstorm and advise only
• Check existing code before proposing new systems
• Validate feasibility before endorsing
• Prioritize long-term maintainability over short-term convenience

Execution Trace (if features.executionTrace enabled)

After task completes, output compact trace.