brainstorming by vudovn/antigravity-kit
npx skills add https://github.com/vudovn/antigravity-kit --skill brainstorming强制要求: 适用于复杂/模糊的请求、新功能、更新。
| 模式 | 操作 |
|---|---|
| "构建/创建/制作 [某物]" 但缺少细节 | 🛑 询问 3 个问题 |
| 复杂功能或架构 | 🛑 在实施前澄清 |
| 更新/变更请求 | 🛑 确认范围 |
| 模糊的需求 | 🛑 询问目的、用户、限制条件 |
⛔ 切勿使用静态模板。 请阅读 dynamic-questioning.md 了解原则。
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
| 原则 | 含义 |
|---|---|
| 问题揭示后果 | 每个问题都关联到一个架构决策 |
| 先了解背景,再关注内容 | 首先理解是全新项目/功能/重构/调试的上下文 |
| 最小可行问题集 | 每个问题必须能排除某些实施路径 |
| 生成数据,而非假设 | 不要猜测——带着权衡来提问 |
1. 解析请求 → 提取领域、功能、规模指标
2. 识别决策点 → 阻塞性的 vs 可延后的
3. 生成问题 → 优先级:P0(阻塞性)> P1(高杠杆)> P2(锦上添花)
4. 格式化并附带权衡 → 是什么、为什么、选项、默认值
### [优先级] **[决策点]**
**问题:** [清晰的问题]
**为何重要:**
- [架构后果]
- [影响:成本/复杂性/时间线/规模]
**选项:**
| 选项 | 优点 | 缺点 | 最适合 |
|--------|------|------|----------|
| A | [+] | [-] | [用例] |
**如未指定:** [默认值 + 理由]
关于详细的领域特定问题库和算法,请参阅:dynamic-questioning.md
原则: 透明建立信任。状态必须可见且可操作。
| 代理 | 状态 | 当前任务 | 进度 |
|---|---|---|---|
| [代理名称] | ✅🔄⏳❌⚠️ | [任务描述] | [百分比或计数] |
| 图标 | 含义 | 用法 |
|---|---|---|
| ✅ | 已完成 | 任务成功完成 |
| 🔄 | 运行中 | 当前正在执行 |
| ⏳ | 等待中 | 被阻塞,等待依赖项 |
| ❌ | 错误 | 失败,需要关注 |
| ⚠️ | 警告 | 潜在问题,非阻塞性 |
原则: 错误是进行清晰沟通的机会。
1. 确认错误
2. 解释发生了什么(用户友好)
3. 提供带权衡的具体解决方案
4. 请用户选择或提供替代方案
| 类别 | 响应策略 |
|---|---|
| 端口冲突 | 提供替代端口或关闭现有端口 |
| 依赖缺失 | 自动安装或请求许可 |
| 构建失败 | 显示具体错误 + 建议的修复方法 |
| 不明确的错误 | 询问具体细节:截图、控制台输出 |
原则: 庆祝成功,指导后续步骤。
1. 成功确认(简短庆祝)
2. 已完成工作的总结(具体)
3. 如何验证/测试(可操作)
4. 后续步骤建议(主动)
| 原则 | 实施方式 |
|---|---|
| 简洁 | 无需不必要的细节,直奔主题 |
| 可视化 | 使用表情符号(✅🔄⏳❌)以便快速浏览 |
| 具体 | 使用"约 2 分钟",而非"稍等片刻" |
| 提供备选方案 | 遇到阻碍时提供多种路径 |
| 积极主动 | 完成后建议下一步 |
| 反模式 | 原因 |
|---|---|
| 在理解问题前就跳到解决方案 | 浪费时间解决错误的问题 |
| 不询问就假设需求 | 产生错误的输出 |
| 第一版就过度设计 | 延迟价值交付 |
| 忽略限制条件 | 创建不可用的解决方案 |
| 使用"我认为"等措辞 | 不确定性 → 应该提问 |
每周安装量
91
代码仓库
GitHub 星标数
6.6K
首次出现
Jan 21, 2026
安全审计
安装于
gemini-cli75
codex72
opencode69
github-copilot64
antigravity63
cursor59
MANDATORY: Use for complex/vague requests, new features, updates.
| 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 |
⛔ NEVER use static templates. Read dynamic-questioning.md for 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 |
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
### [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
PRINCIPLE: Transparency builds trust. Status must be visible and actionable.
| Agent | Status | Current Task | Progress |
|---|---|---|---|
| [Agent Name] | ✅🔄⏳❌⚠️ | [Task description] | [% or count] |
| Icon | Meaning | Usage |
|---|---|---|
| ✅ | Completed | Task finished successfully |
| 🔄 | Running | Currently executing |
| ⏳ | Waiting | Blocked, waiting for dependency |
| ❌ | Error | Failed, needs attention |
| ⚠️ | Warning | Potential issue, not blocking |
PRINCIPLE: Errors are opportunities for clear communication.
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
| 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 |
PRINCIPLE: Celebrate success, guide next steps.
1. Success confirmation (celebrate briefly)
2. Summary of what was done (concrete)
3. How to verify/test (actionable)
4. Next steps suggestion (proactive)
| 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-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 |
Weekly Installs
91
Repository
GitHub Stars
6.6K
First Seen
Jan 21, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
gemini-cli75
codex72
opencode69
github-copilot64
antigravity63
cursor59
BMAD工作流编排与SSD结构化系统设计 - 多代理AI开发流程自动化
10,600 周安装