头脑超级风暴

在任何创造性工作之前必须使用 - 创建功能、构建组件、添加新功能或修改行为。通过协作对话探索用户意图、需求和设计。

Security Scan

Skill appears to do what it says (brainstorming + producing design docs) but its runtime instructions expect repository file access and a required sub-skill without declaring those dependencies or credential needs.

Purpose & Capability

The name/description (brainstorming and design) match the instructions: asking questions, proposing options, and producing design docs is coherent. However the SKILL.md explicitly requires reading '当前项目状态（文件、文档、最近提交）' and committing documents to git, yet the skill metadata declares no required config paths, no required env vars, and does not list the declared REQUIRED sub-skill (core-writing-plans) as a dependency. That mismatch (undeclared dependency and implicit repo access) is an inconsistency users should be aware of.

Instruction Scope

The instructions direct the agent to read project files, documentation, and recent commits, then write design files to docs/plans/YYYY-MM-DD-<topic>-design.md and commit them to git. Those actions are within the stated purpose (context-aware brainstorming and producing plans), but they involve file I/O and git operations on the user's repository. The SKILL.md does not instruct contacting external endpoints beyond using sub-skills; no exfiltration endpoints are present.

Install Mechanism

Instruction-only skill with no install spec and no code files. This minimizes installation risk because nothing is downloaded or written by the installer.

Credentials

The skill declares no environment variables or credentials, which is reasonable for a pure brainstorming skill. However, the instructions expect the ability to read repository content and perform git commits. If the agent environment requires credentials to push or commit (e.g., remote pushes), those credentials are not declared or explained. The missing declaration of the REQUIRED sub-skill (core-writing-plans) is another proportionality gap: it may need additional permissions or envs that are not surfaced.

Persistence & Privilege

always is false and the skill does not request persistent installation or system-wide configuration changes. It does instruct writing files into the repo and committing them, which is normal for a planning workflow but requires file-system and git access at runtime.

What to consider before installing

This skill is largely coherent with its stated purpose, but pay attention before enabling it: - It will read your project files, documentation, and git history and will write plan files under docs/plans/ and commit them — ensure you are comfortable granting the agent access to the repository and workspace. - The SKILL.md names a REQUIRED sub-skill (core-writing-plans) but the registry metadata does not declare that dependency; confirm that sub-skill exists and review its permissions. - If your environment requires git credentials to push commits, those credentials are not declared by the skill; consider whether you want the agent to perform commits automatically or prefer to review changes and commit manually. - Review your repo for secrets or sensitive data before giving the agent broad file access. If you need higher assurance, request the author to (a) declare required sub-skills and any credential needs, and (b) provide an explicit option to produce files without performing automated git commits so you can review and push changes yourself.

2026年4月16日

Brainstorming - 将想法转化为设计

概述

通过自然的协作对话，帮助将模糊的想法转化为完整的设计和规格说明。

首先了解当前项目上下文，然后逐个提问来完善想法。一旦理解了要构建的内容，以小节形式（200-300字）呈现设计，每节后确认是否正确。

流程

理解想法

• 首先查看当前项目状态（文件、文档、最近提交）
• 逐个提问来完善想法
• 尽可能使用选择题，开放题也可以
• 每条消息只问一个问题 - 如果需要更多探索，分多个问题
• 聚焦于理解：目的、约束、成功标准

探索方案

• 提出 2-3 种不同方案及其权衡
• 以对话方式呈现选项，包括推荐和理由
• 优先展示推荐方案并解释原因

呈现设计

• 确信理解了要构建的内容后，呈现设计
• 分成 200-300 字的小节
• 每节后询问是否正确
• 涵盖：架构、组件、数据流、错误处理、测试
• 准备好返回澄清不清楚的地方

设计完成后

文档输出

• 将验证通过的设计写入 docs/plans/YYYY-MM-DD-<topic>-design.md
• 提交设计文档到 git

继续实施（如果需要）

• 询问：「准备好开始实施了吗？」
• REQUIRED SUB-SKILL: 使用 core-writing-plans 创建详细实施计划

领域扩展钩子

如果是嵌入式项目：

• RECOMMENDED: 使用 embedded-datasheet-analysis 分析硬件数据手册
• RECOMMENDED: 使用 embedded-feasibility-assessment 评估硬件约束
• RECOMMENDED: 使用 embedded-platform-selection 选择合适平台

如果是仿真项目：

• RECOMMENDED: 使用 simulation-requirements 分析仿真需求
• RECOMMENDED: 使用 simulation-architecture 设计仿真架构

核心原则

• 一次一个问题 - 不要用多个问题压垮用户
• 首选选择题 - 比开放题更容易回答
• YAGNI 原则 - 从所有设计中移除不必要的功能
• 探索替代方案 - 在确定之前始终提出 2-3 种方案
• 增量验证 - 分节呈现设计，验证每节
• 保持灵活 - 当某些内容不清楚时返回澄清