agentleFS
Sign inStart free
xenitV1xenitV1/Antigravity-Workflows/skills/brainstorming/SKILL.md

brainstorming

Skill130 starsChanged 10 months agoMITView on GitHub

Socratic questioning protocol + user communication. MANDATORY for complex requests, new features, or unclear requirements. Includes progress reporting and error handling.

We split this skill into the rules it gives an agent

2 rules. 0 are common, 1 is distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 174 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    STOP: - Do NOT start coding

    line 26
  2. Very specific:

    ⛔ NEVER use static templates: Read dynamic-questioning.md for principles.

    line 37

“Common” is measured: kept by at least 6 in 10 of the 174 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 & Communication Protocol

MANDATORY: Use for complex/vague requests, new features, updates.

🛑 SOCRATIC GATE (ENFORCEMENT)

When to Trigger

PatternAction
"Build/Create/Make [thing]" without details🛑 ASK 3 questions
Complex feature or architecture🛑 Clarify before implementing
Update/change request🛑 Confirm scope
Vague requirements🛑 Ask purpose, users, constraints

🚫 MANDATORY: 3 Questions Before Implementation

  1. STOP - Do NOT start coding
  2. ASK - Minimum 3 questions:
    • 🎯 Purpose: What problem are you solving?
    • 👥 Users: Who will use this?
    • 📦 Scope: Must-have vs nice-to-have?
  3. WAIT - Get response before proceeding

🧠 Dynamic Question Generation

⛔ NEVER use static templates. Read dynamic-questioning.md for principles.

Core Principles

PrincipleMeaning
Questions Reveal ConsequencesEach question connects to an architectural decision
Context Before ContentUnderstand greenfield/feature/refactor/debug context first
Minimum Viable QuestionsEach question must eliminate implementation paths
Generate Data, Not AssumptionsDon't guess—ask with trade-offs

Question Generation Process

1. Parse request → Extract domain, features, scale indicators
2. Identify decision points → Blocking vs. deferable
3. Generate questions → Priority: P0 (blocking) > P1 (high-leverage) > P2 (nice-to-have)
4. Format with trade-offs → What, Why, Options, Default

Question Format (MANDATORY)

### [PRIORITY] **[DECISION POINT]**

**Question:** [Clear question]

**Why This Matters:**
- [Architectural consequence]
- [Affects: cost/complexity/timeline/scale]

**Options:**
| Option | Pros | Cons | Best For |
|--------|------|------|----------|
| A | [+] | [-] | [Use case] |

**If Not Specified:** [Default + rationale]

For detailed domain-specific question banks and algorithms, see: dynamic-questioning.md

Progress Reporting (PRINCIPLE-BASED)

PRINCIPLE: Transparency builds trust. Status must be visible and actionable.

Status Board Format

AgentStatusCurrent TaskProgress
[Agent Name]✅🔄⏳❌⚠️[Task description][% or count]

Status Icons

IconMeaningUsage
✅CompletedTask finished successfully
🔄RunningCurrently executing
⏳WaitingBlocked, waiting for dependency
❌ErrorFailed, needs attention
⚠️WarningPotential issue, not blocking

Error Handling (PRINCIPLE-BASED)

PRINCIPLE: Errors are opportunities for clear communication.

Error Response Pattern

1. Acknowledge the error
2. Explain what happened (user-friendly)
3. Offer specific solutions with trade-offs
4. Ask user to choose or provide alternative

Error Categories

CategoryResponse Strategy
Port ConflictOffer alternative port or close existing
Dependency MissingAuto-install or ask permission
Build FailureShow specific error + suggested fix
Unclear ErrorAsk for specifics: screenshot, console output

Completion Message (PRINCIPLE-BASED)

PRINCIPLE: Celebrate success, guide next steps.

Completion Structure

1. Success confirmation (celebrate briefly)
2. Summary of what was done (concrete)
3. How to verify/test (actionable)
4. Next steps suggestion (proactive)

Communication Principles

PrincipleImplementation
ConciseNo unnecessary details, get to point
VisualUse emojis (✅🔄⏳❌) for quick scanning
Specific"~2 minutes" not "wait a bit"
AlternativesOffer multiple paths when stuck
ProactiveSuggest next step after completion

Anti-Patterns (AVOID)

Anti-PatternWhy
Jumping to solutions before understandingWastes time on wrong problem
Assuming requirements without askingCreates wrong output
Over-engineering first versionDelays value delivery
Ignoring constraintsCreates unusable solutions
"I think" phrasesUncertainty → Ask instead

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.

Check your setup, free