REQUIRED Phase 1 of /dev workflow. Uses Socratic questioning to understand requirements before exploration.
Installation
Details
Usage
After installing, this skill will be available to your AI coding assistant.
Verify installation:
npx agent-skills-cli listSkill Instructions
name: dev-brainstorm description: "REQUIRED Phase 1 of /dev workflow. Uses Socratic questioning to understand requirements before exploration."
Announce: "I'm using dev-brainstorm (Phase 1) to gather requirements."
Contents
- The Iron Law of Brainstorming
- What Brainstorm Does
- Process
- Red Flags - STOP If You're About To
- Output
Brainstorming (Questions Only)
Refine vague ideas into clear requirements through Socratic questioning. NO exploration, NO approaches - just questions and requirements.
<EXTREMELY-IMPORTANT> ## The Iron Law of BrainstormingASK QUESTIONS BEFORE ANYTHING ELSE. This is not negotiable.
Before exploring codebase, before proposing approaches, you MUST:
- Ask clarifying questions using AskUserQuestion
- Understand what the user actually wants
- Define success criteria
Approaches come later (in /dev-design) after exploring the codebase.
If you catch yourself about to explore the codebase before asking questions, STOP. </EXTREMELY-IMPORTANT>
What Brainstorm Does
| DO | DON'T |
|---|---|
| Ask clarifying questions | Explore codebase |
| Understand requirements | Spawn explore agents |
| Define success criteria | Look at existing code |
| Write draft SPEC.md | Propose approaches (that's design) |
| Identify unknowns | Create implementation tasks |
Brainstorm answers: WHAT do we need and WHY Explore answers: WHERE is the code (next phase) Design answers: HOW to build it (after exploration)
Process
1. Ask Questions First
Use AskUserQuestion immediately:
- One question at a time - never batch
- Multiple-choice preferred - easier to answer
- Focus on: purpose, constraints, success criteria
Example questions:
- "What problem does this solve?"
- "Who will use this feature?"
- "What's the most important requirement?"
- "Any constraints (performance, compatibility)?"
2. Define Success Criteria
After understanding requirements:
- Turn requirements into measurable criteria
- Use checkboxes for clear pass/fail
- Confirm with user
3. Write Draft SPEC.md
Write initial spec to .claude/SPEC.md:
# Spec: [Feature Name]
> **For Claude:** After writing this spec, use `Skill(skill="workflows:dev-explore")` for Phase 2.
## Problem
[What problem this solves]
## Requirements
- [Requirement 1]
- [Requirement 2]
## Success Criteria
- [ ] Criterion 1
- [ ] Criterion 2
## Constraints
- [Any limitations or boundaries]
## Automated Testing (MANDATORY)
> **For Claude:** Use `Skill(skill="workflows:dev-test")` for automation options.
- **Framework:** [pytest / playwright / jest / etc.]
- **Command:** [e.g., `pytest tests/ -v`]
- **Core functionality to verify:** [what MUST be tested automatically]
### What Counts as a Real Automated Test
| ✅ REAL TEST (execute + verify) | ❌ NOT A TEST (never acceptable) |
|---------------------------------|----------------------------------|
| pytest calls function, checks return value | grep/ast-grep finds function exists |
| Playwright clicks button, verifies result | Check logs say "success" |
| ydotool simulates user, screenshot verifies | Read source code structure |
| API call returns expected response | "Code looks correct" |
| CLI invocation produces expected output | Structural pattern matching |
**THE TEST MUST EXECUTE THE CODE AND VERIFY RUNTIME BEHAVIOR.**
Grepping is not testing. Log checking is not testing. Code review is not testing.
## Open Questions
- [Questions to resolve during exploration]
Note: No "Chosen Approach" yet - that comes after exploration and design phases.
Red Flags - STOP If You're About To:
| Action | Why It's Wrong | Do Instead |
|---|---|---|
| Spawn explore agent | Exploring before understanding | Ask questions first |
| Read source files | Looking at code before requirements | Ask what user wants |
| Propose approaches | Too early - need to explore first | Save for /dev-design |
| Create task list | Planning before understanding | Finish brainstorm first |
Output
Brainstorm complete when:
- Problem is clearly understood
- Requirements defined
- Success criteria defined
.claude/SPEC.mdwritten (draft)- Open questions identified for exploration
Phase Complete
REQUIRED SUB-SKILL: After completing brainstorm, IMMEDIATELY invoke:
Skill(skill="workflows:dev-explore")
More by edwinhu
View allThis skill should be used when the user asks to "search Google Scholar", "find academic papers", "scholar search", "lookup papers", "find citations", "academic search", "search for papers by author", "find journal articles", "get BibTeX", "cite this paper", "download paper", or needs to search Google Scholar for academic literature via the scholar CLI tool.
REQUIRED Phase 5 of /ds workflow (final). Checks reproducibility and requires user acceptance.
This skill should be used when the user asks to "debug notebook", "inspect notebook outputs", "find notebook error", "read traceback from ipynb", "why did notebook fail", or needs to understand runtime errors in executed Jupyter notebooks from any source (marimo, jupytext, papermill).
Internal skill for Strunk & White writing rules. Loaded by /writing for quick edits or as base layer for domain skills.
