playbooks

home / skills / vudovn / antigravity-kit / brainstorming

brainstorming skill

/.agent/skills/brainstorming

This skill guides complex requests through Socratic questioning and clear communication, ensuring scope, risks, and user needs are understood before

npx playbooks add skill vudovn/antigravity-kit --skill brainstorming

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
4.6 KB
---
name: brainstorming
description: Socratic questioning protocol + user communication. MANDATORY for complex requests, new features, or unclear requirements. Includes progress reporting and error handling.
allowed-tools: Read, Glob, Grep
---

# Brainstorming & Communication Protocol

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

---

## 🛑 SOCRATIC GATE (ENFORCEMENT)

### When to Trigger

| Pattern | Action |
|---------|--------|
| "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

| Principle | Meaning |
|-----------|---------|
| **Questions Reveal Consequences** | Each question connects to an architectural decision |
| **Context Before Content** | Understand greenfield/feature/refactor/debug context first |
| **Minimum Viable Questions** | Each question must eliminate implementation paths |
| **Generate Data, Not Assumptions** | Don'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)

```markdown
### [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

| Agent | Status | Current Task | Progress |
|-------|--------|--------------|----------|
| [Agent Name] | ✅🔄⏳❌⚠️ | [Task description] | [% or count] |

### Status Icons

| Icon | Meaning | Usage |
|------|---------|-------|
| ✅ | Completed | Task finished successfully |
| 🔄 | Running | Currently executing |
| ⏳ | Waiting | Blocked, waiting for dependency |
| ❌ | Error | Failed, needs attention |
| ⚠️ | Warning | Potential 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

| Category | Response Strategy |
|----------|-------------------|
| **Port Conflict** | Offer alternative port or close existing |
| **Dependency Missing** | Auto-install or ask permission |
| **Build Failure** | Show specific error + suggested fix |
| **Unclear Error** | Ask 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

| Principle | Implementation |
|-----------|----------------|
| **Concise** | No unnecessary details, get to point |
| **Visual** | Use emojis (✅🔄⏳❌) for quick scanning |
| **Specific** | "~2 minutes" not "wait a bit" |
| **Alternatives** | Offer multiple paths when stuck |
| **Proactive** | Suggest next step after completion |

---

## Anti-Patterns (AVOID)

| Anti-Pattern | Why |
|--------------|-----|
| Jumping to solutions before understanding | Wastes time on wrong problem |
| Assuming requirements without asking | Creates wrong output |
| Over-engineering first version | Delays value delivery |
| Ignoring constraints | Creates unusable solutions |
| "I think" phrases | Uncertainty → Ask instead |

---

Overview

This skill enforces a Socratic brainstorming and communication protocol for complex, vague, or new-feature requests. It prevents premature implementation by requiring targeted questions, progress reporting, and structured error handling. The goal is clearer requirements, faster decisions, and fewer reworks.

How this skill works

When a qualifying request arrives, the skill halts implementation and generates at least three focused, dynamic questions that expose consequences and decision points. It classifies questions by priority, presents trade-offs and defaults, and waits for user responses. It also maintains an explicit status board and uses a principled error-response pattern to surface and resolve issues.

When to use it

  • Requests that say “build/create/make” without sufficient detail
  • Design or architecture decisions for new features or significant changes
  • Any unclear or ambiguous requirements that could alter implementation
  • Updates or changes where scope might be misunderstood
  • When you need transparent progress updates and clear error handling

Best practices

  • Always stop and ask before writing code for complex or vague requests
  • Generate dynamic, non-template questions that eliminate implementation paths
  • Prioritize questions: P0 (blocking), P1 (high-leverage), P2 (nice-to-have)
  • Provide trade-offs and a default if the user does not specify
  • Keep status updates concise and use clear icons (✅🔄⏳❌⚠️)

Example use cases

  • A product request: “Build a commenting system” → skill asks about auth, moderation, scale, storage trade-offs
  • New feature in an existing app: clarifies backward-compatibility and deployment constraints
  • Refactor proposal: asks about performance targets, risk tolerance, and rollback strategy
  • Bug triage with unclear symptoms: requests logs, environment, and reproduction steps
  • Release change request: confirms scope, rollout plan, and monitoring needs

FAQ

What happens if the user ignores the three required questions?

The skill pauses implementation and reminds the user that answers are mandatory; it also supplies recommended defaults and the consequences of proceeding without clarification.

How are progress and errors communicated?

Progress is shown on a status board with icons and percent/completion counts. Errors follow a four-step pattern: acknowledge, explain, offer solutions with trade-offs, and ask the user to choose.