agentleFS
supper-skillssupper-skills/develpment-skills/skills/brainstorming/SKILL.md

brainstorming

Skill2 starsChanged 8 months agoMITView on GitHub

Execute before any creative work — including creating features, building components, adding functionality, or modifying behavior. Explore user intent, requirements, and design solutions before implementation. Transform ideas into complete design specifications through natural collaborative dialogue. Activate when user mentions "new feature", "build", "create component", "add functionality", "implement", or starts any development work. This skill automatically invokes the project-context skill to obtain user profile and workflow path recommendations.

191 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use chinese-code-review, chinese-commit-conventions and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • Leodorareluctant259Skill

    chinese-code-review

    中文代码审查规范——在保持专业严谨的同时,用符合国内团队文化的方式给出有效反馈

    Also in 8 projects that use this

  • Leodorareluctant259Skill

    chinese-commit-conventions

    中文 Git 提交规范 — 适配国内团队的 commit message 规范和 changelog 自动化

    Also in 8 projects that use this

  • ryanportfolioSkill

    addskill

    Create, import, update, or install repo or personal skills: runtime ownership, resources, discovery checks.

    Also in 6 projects that use this

  • ryanportfolioSkill

    apply-firmware

    Bring current folder (plain folder, existing repo, old or partial firmware copy) up to full Harness Firmware in place. Mirror external repo → adopt-repo.

    Also in 6 projects that use this

  • +2 more from Leodorareluctant259
  • +6 more from ryanportfolio

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. 0 are common, 12 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 172 edited versions we read keep these.

  • 12

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before user approval of the design document, do NOT:

    line 19
  2. Distinctive:

    Use a unified session state file to track progress:

    line 28
  3. Distinctive:

    After user confirmation → Update state file

    line 36
  4. Very specific:

    Read project context (if exists): design/context/project-context.md

    line 55
  5. Distinctive:

    Check project file structure

    line 56
  6. Distinctive:

    If request involves multiple independent subsystems, assist user in breaking down into sub-projects

    line 62
  7. Distinctive:

    Ask only one question per message

    line 75
  8. Distinctive:

    Goal: Write validated design into specification document.

    line 109
  9. Very specific:

    Create specification document: design/specs/YYYY-MM-DD-<topic>-design.md

    line 113
  10. Distinctive:

    Ensure no TODOs, TBDs, or placeholders

    line 115
  11. Distinctive:

    Completion Criteria: Document written to specified path, no placeholder content

    line 130
  12. Distinctive:

    If user approves, invoke writing-plan skill

    line 144
  13. Distinctive:

    Termination: After this phase completes, this skill ends.

    line 156
  14. Distinctive:

    Start brainstorming for the first sub-project

    line 185
  15. Very specific:

    Read session state file design/.session-state.md

    line 192

“Common” is measured: kept by at least 6 in 10 of the 172 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Brainstorming Skill

This skill is a required step before any creative work, transforming ideas into complete design specifications through collaborative dialogue.


Core Principles

Design First

Before user approval of the design document, do NOT:

  • Invoke any implementation skills
  • Write any code
  • Set up project scaffolding
  • Take any implementation actions

Session State Management

Use a unified session state file to track progress:

  • Path: design/.session-state.md
  • Template: references/session-state-template.md

When to Operate:

  • Skill activation → Create state file
  • After user confirmation → Update state file
  • At the start of each dialogue round → Read state file to restore context
  • After each phase completion → Update state file

Termination Condition

The only way to terminate this skill is to invoke the writing-plan skill and pass the specification document path.


Workflow

Phase 1: Explore Background

Goal: Understand current project status and assess requirement scope.

Actions:

  1. Invoke project-context skill to get user profile
  2. Read project context (if exists): design/context/project-context.md
  3. Check project file structure
  4. Assess if requirements involve multiple independent subsystems
  5. Proactively update user profile (if new preferences or technical background identified)

Scope Check:

  • If request involves multiple independent subsystems, assist user in breaking down into sub-projects
  • Each sub-project undergoes brainstorming independently

Completion Criteria: Project tech stack and existing structure understood, requirement scope confirmed, user profile updated (if changed)


Phase 2: Confirm Requirements

Goal: Understand goals, constraints, and success criteria one by one.

Rules:

  • Ask only one question per message
  • Prefer multiple-choice format

Core Question List (in order):

#Question TypeExample Question
1Goal Positioning"Who are the primary users of this feature?"
2Constraints"Are there any time or tech stack limitations?"
3Success Criteria"How do we determine if this feature is successfully delivered?"
4Edge Cases"Are there any edge cases that need special handling?"

Completion Criteria: Goal positioning clear, constraints identified, success criteria verifiable


Phase 3: Solution Selection

Goal: Provide 2-3 different solutions with trade-off analysis.

Actions:

  1. Propose 2-3 different solutions
  2. Explain pros and cons of each solution
  3. Provide recommended solution with reasoning

Completion Criteria: User has selected a solution

Reference: references/tech-selection-guide.md


Phase 4: Design Document

Goal: Write validated design into specification document.

Actions:

  1. Create specification document: design/specs/YYYY-MM-DD-<topic>-design.md
  2. Include all confirmed content
  3. Ensure no TODOs, TBDs, or placeholders

Document Structure:

SectionContent Requirements
OverviewFeature goals, background context
Goal PositioningPrimary users and use cases
ConstraintsTechnical, time, resource limitations
Success CriteriaVerifiable delivery standards
Architecture DesignSystem structure and component division
Data FlowHow data flows
Error HandlingException handling strategies
Testing StrategyHow to verify feature correctness

Completion Criteria: Document written to specified path, no placeholder content

Reference: references/spec-template.md


Phase 5: Handover

Goal: Obtain user approval, invoke writing-plan skill.

Actions:

  1. Present specification document path to user
  2. Request user review and confirmation
  3. If user approves, invoke writing-plan skill

Standard Phrase:

"The specification document has been written and submitted to <path>. Please review it. Once confirmed, I will begin creating the implementation plan."

Invocation Format:

Invoke writing-plan skill, specification document path: <path>

Termination: After this phase completes, this skill ends.


Reference Guide

Reference DocumentPurpose
references/session-state-template.mdSession state file template
references/spec-template.mdSpecification document template
references/tech-selection-guide.mdTechnology selection guide
references/risk-assessment-template.mdRisk assessment template

FAQ

User insists on skipping design and implementing directly?

Response:

"I understand you want to move quickly. The design document can be brief, but it needs to be documented and approved by you. This ensures we have consensus on the goals and avoids rework later."

What if the project scope is too large?

Handling:

  1. Mark as multi-subsystem project
  2. Assist user in breaking down into independent sub-projects
  3. Start brainstorming for the first sub-project
  4. Each sub-project goes through specification → planning → implementation cycle independently

How to recover after dialogue interruption?

Handling:

  1. Read session state file design/.session-state.md
  2. Continue execution based on "Next Step"

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.