Skip to content
cccskills
FreePublished on GitHub

brainstorm

Use when the user wants to explore options, weigh approaches, or think through uncertainty before committing to a direction. Collaborative brainstorming and rubber ducking — divergence-first thinking partner.

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md3.4 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Brainstorming

Thinking partner mode. Explore ideas, don't implement them.

Two Modes

Rubber ducking — the user is thinking out loud. Reflect back what they said, challenge assumptions, ask what problem this solves. You are a mirror that talks back. The user does the thinking.

Structured ideation — the problem is clear, the user wants options. Generate diverse approaches, explore tradeoffs. You amplify the user's creativity, not replace it. The user evaluates and selects.

The modes are fluid. Don't announce them. Follow the user's energy.

Principles

  • Diverge before converging. Generate breadth first. Don't evaluate during generation.
  • Counter the median. Your default is conventional ideas. Include deliberately diverse options — wild, unconventional, or even ones that might not work. Diverse idea galleries outperform curated ones.
  • Low fidelity. Rough ideas, not polished proposals. Specificity constrains creativity early on.
  • User controls convergence. Don't narrow until the user signals readiness ("I think...", repeated themes, narrowing language).
  • Ideas over implementation. Read code for context, but focus on exploring — follow the user's lead if they want to transition to building.
  • No forced artifact. Brainstorming may produce a decision, better questions, or a decision NOT to build. All valid.

Voice

Diverge on ideas, converge on proposals. Generate breadth, but each idea is a concrete sketch — not a fragment.

  • Concrete, not rambling. "Low fidelity" means rough and bounded, not vague. "Use a state machine here" beats "maybe some kind of stateful thing." A short concrete sketch reads as an idea; a long conversational ramble reads as filler.
  • Batch the options. When generating, drop 3-5 candidates in one breath — not one at a time waiting for reaction. The user scans a gallery, not a parade.
  • Mirror plus add. Even rubber-ducking, never reflect alone — reflect and contribute a challenge, surfaced assumption, or angle the user didn't name. Open questions live inside the contribution.

Brainstorm is the explicit escape hatch from "commit to one path" — not from "be specific."

When You Notice Convergence

Offer a lightweight check-in: "Sounds like we're converging on X — want me to pull this together?"

If yes → transition to SAFEWORD.md's understanding flow (scope / out of scope / done when). If no → keep exploring.

Anti-Patterns

Don'tDo
Summarize unpromptedLet the user pull the trigger
Announce frameworks ("let me apply 5 Whys")Just ask the questions the framework would produce
Jump to implementation unpromptedStay in ideas until the user signals readiness
Evaluate during divergenceGenerate first, evaluate after
Produce only safe ideasInclude at least one unconventional option

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

audit

Free

Run comprehensive code audit for architecture, dead code, and test quality. Use when reviewing overall codebase health, checking for architectural violations, or before marking a feature complete.

The English summary is being prepared. Showing the original description.

TheMostlyGreat/mythos19Updated Jun 14, 2026

bdd

Free

Behavior-first feature development — use when building new capabilities, continuing feature work, or when work introduces new state or multiple user flows. Discovers desired behavior through examples and scenarios before implementation. Do NOT use for bug fixes, typos, or small isolated changes.

The English summary is being prepared. Showing the original description.

TheMostlyGreat/mythos19Updated Jun 14, 2026

Kill zombie dev servers and test processes. Use when ports are blocked, processes are hanging, or test runners won't start.

The English summary is being prepared. Showing the original description.

TheMostlyGreat/mythos19Updated Jun 14, 2026

debug

Free

Root cause debugging before fixes. Use when investigating bugs, diagnosing test failures, troubleshooting unexpected behavior, or when previous fix attempts failed. Enforces investigate-first discipline.

The English summary is being prepared. Showing the original description.

TheMostlyGreat/mythos19Updated Jun 14, 2026

elicit

Free

Extract tacit knowledge through non-obvious microquestions — things only the user knows that can't be found in code, docs, or research. Use when you're about to guess at intent, context, or constraints during SAFEWORD's understanding flow. Also use when user says 'ask me', 'what do you need to know', or when another skill (bdd, brainstorm, debug) needs user context before proceeding. Do NOT use for questions answerable by reading the codebase or searching the web.

The English summary is being prepared. Showing the original description.

TheMostlyGreat/mythos19Updated Jun 14, 2026

Explore and debate options with fresh documentation and research before committing. Use when facing a real decision with multiple plausible approaches — library/framework choice, architecture call, API or schema design, algorithm selection, or any communication / strategy call where being wrong has cost. Enumerates relevant research domains, looks up current docs and evidence-based methods, weighs options on correctness and elegance, resists bloat. Do NOT use for divergent ideation (brainstorm), extracting user intent (elicit), or reviewing already-written code (quality-review).

The English summary is being prepared. Showing the original description.

TheMostlyGreat/mythos19Updated Jun 14, 2026

See all skills by TheMostlyGreat

Report a problem with this skill