agentsclimarketplace

Code brainstorming

Skill RileyCornelius/Code-Skills/skills/code-brainstorming

Install
npx -y skills add RileyCornelius/Code-Skills --skill code-brainstorming

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Turn coding ideas into approved designs and planning-ready implementation briefs before coding starts. Use for new features, meaningful behavior changes, ambiguous implementation requests, refactors that change system shape, or early architecture and design discussions. Do not use for tiny obvious edits, isolated typo fixes, trivial null checks, or other straightforward bug fixes that do not need design work.

SKILL.md

2.4 KB, as published. Nobody here has run it

Brainstorming

Help turn ideas into fully formed designs and specs through natural collaborative dialogue.

Start by understanding the current project context, then ask questions in a numbered list to refine the idea. Once you understand what you're building, present the design and get user approval.

Hard Gate

  • Do not write code.
  • Do not scaffold files or projects.
  • Do not take implementation action until the design brief has been presented and approved.

Workflow

1. Explore context first

  • Read relevant files, docs, types, configs, and recent changes before asking intent questions.
  • Follow existing patterns instead of inventing unrelated ones.
  • Assess scope early. If the request spans multiple independent subsystems, say so and help decompose it before refining one slice.

2. Clarify intent

  • Focus on purpose, constraints, success criteria, and boundaries the user cares about.
  • Prefer concrete multiple-choice questions when they reduce ambiguity.
  • Prefer open ended question other wise.
  • Do not ask questions that the repository can answer.

3. Identify gray areas

  • Convert the request into specific decisions that will change the design.
  • Focus on behavior, interfaces, data flow, states, failure handling, and testing expectations as appropriate.
  • Keep scope fixed. If the user suggests a new capability, mark it as deferred and return to the current change.

4. Compare approaches

  • Present 2-3 viable approaches.
  • Lead with the recommended option.
  • Explain tradeoffs in terms of codebase fit, complexity, flexibility, and user goals.

Key Principles

  • Multiple choice preferred - Easier to answer than open-ended when possible
  • YAGNI ruthlessly - Remove unnecessary features from all designs
  • Explore alternatives - Propose 2-3 approaches before settling
  • Incremental validation - Present design, get approval before moving on
  • Be flexible - Go back and clarify when something doesn't make sense
  • Question - Call out assumptions explicitly

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.