القائمة
在进行任何创意性工作之前必须使用此技能 — 创建功能、构建组件、添加功能、实现需求或修改行为。在实现前探索用户意图、需求和设计。用户说"头脑风暴"或类似的表达时，应触发此技能。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
在当前会话中执行包含若干独立任务的实现计划时使用
Kimi WebBridge lets AI control the user's real browser — navigate, click, type, read, screenshot, and interact with any website using the user's actual login sessions. Use this skill whenever the user wants to interact with websites, automate browser tasks, scrape web content, or perform any action requiring a real browser. Also use when the user mentions "browser", "webpage", "open URL", "screenshot", or asks to read/interact with any website. Use even for simple-sounding browser requests — the daemon handles all complexity.
对 PostgreSQL 数据库执行只读检查时使用。优先读 doc/db/quick-guide 匹配场景，表结构按需 docker exec psql 查询；查库后评估是否沉淀 quick-guide。触发词：查数据库、检查表、行数、数据覆盖、schema、docker exec psql、DB 状态、doc/db、快捷检索指南、quick-guide。
调用 DeepSeek API（/chat/completions）的强制查阅规范，覆盖思考模式（reasoning_content / thinking / reasoning_effort）与多轮对话上下文拼接。**任何**涉及 DeepSeek API 的代码编写、修改、排错前必须先调用本 skill。触发词：DeepSeek、deepseek、deepseek-v4-pro、reasoning_content、思考模式、thinking mode、reasoning_effort、deepseek 多轮、deepseek chat completions、api.deepseek.com。
当面临 2 个以上可独立执行、无共享状态或顺序依赖的任务时使用
手动触发
| name | brainstorming |
| description | 在进行任何创意性工作之前必须使用此技能 — 创建功能、构建组件、添加功能、实现需求或修改行为。在实现前探索用户意图、需求和设计。用户说"头脑风暴"或类似的表达时，应触发此技能。 |
通过自然的协作对话，把想法转化成完整成型的设计与 spec。
先理解当前项目上下文，然后一次问一个问题逐步打磨想法。一旦弄清楚要构建什么，就把设计提出来并获得用户批准。
在你把设计提出来并获得用户批准之前，禁止调用任何实现类 skill、写任何代码、搭任何项目骨架或采取任何实现动作。该规则对**每一个**项目都适用，无论看起来多简单。你必须使用 TodoWrite 为下列每一项创建一个 Todo ，并按顺序完成：
必须通过 SubAgent 执行代码库调查，主 Agent 自身禁止直接 Glob/Grep/Read 大批文件做摸底。SubAgent 返回结构化结论后，由主 Agent 汇总。
Agent 工具（优先 subagent_type=Explore，需要跨模块综合分析时用 general-purpose）让子代理去翻文件、读文档、看 git log，并要求其返回："相关文件路径 + 关键片段摘录 + 现有模式/约定总结"。主 Agent 不在主上下文直接做大范围 Glob/Grep/Read，只接收 SubAgent 的结构化结论用于后续提问与设计。一次一个，理解目的 / 约束 / 成功标准。
附权衡分析与你的推荐。
按各部分复杂度分段呈现，每段都获得用户批准。
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md（用户对 spec 位置的偏好可覆盖此默认值）(Get-Content file | Measure-Object -Line).Lines），若 spec 单文件 > 300 行：
docs/superpowers/specs/YYYY-MM-DD-<topic>-design/；NN-<subtopic>.md，每份必须 < 300 行；切分边界优先沿用 spec 自身的一级 / 二级标题，不要机械按行切；index.md，包含：① 项目背景与目标摘要（≤ 50 行）；② 子文档清单（一行说明 + 相对链接）；③ 建议阅读顺序；④ 跨文档引用约定（统一用相对路径 + 锚点，例如 ./02-data-model.md#schema）；YYYY-MM-DD-<topic>-design.md 默认删除，由该目录的 index.md 取代为入口；若特殊原因需保留，则改为指向 ./<同名目录>/index.md 的一行 redirect；写完 spec 后，主 Agent 禁止自查自审，必须派发 SubAgent 以"独立审阅者"身份检查写好的 spec 文件。
派发时给 SubAgent 的 prompt 必须显式要求覆盖下列 6 项检查，并要求其返回**"是否通过 / 问题清单（含文件位置与建议修订）"**：
index.md 是否齐备（摘要 / 子文档清单 / 阅读顺序 / 引用约定）；③ 子文档间相对链接与锚点是否有效；④ 是否存在重复内容或被切碎到无法独立理解的段落。主 Agent 收到 SubAgent 的问题清单后，逐条 inline 修订 spec 文件；修订后若改动较大，可再派发一次 SubAgent 复查，否则不再循环，直接进入用户审阅环节。
在 spec 审阅循环通过之后，请用户在继续之前审阅写好的 spec：
"Spec 已写入并提交到
<path>请审阅，告诉我是否需要修改后再进入后续开发。"
等待用户回复。如果用户提出修改，先改完再重跑 spec 审阅循环。只有在用户批准后才继续。
用户批准 spec 后，先基于 spec 内容判断是否值得、是否适合 SubAgent 并行开发——不要不经评估直接向用户抛「是/否」。
适合并行开发的信号（须同时满足多数）：
不适合时（例如单文件小改、任务强耦合、需频繁共享中间状态、边界切不清）：说明理由，建议串行实现或用户自行选择其它方式；不得强行编排并行方案。
若判断适合，在询问用户之前须先 编排并行开发方案 并呈现，至少包含：
呈现后询问用户是否采用该方案：
"基于 spec，我建议按下列 wave 并行开发：[方案摘要]。是否按此方案执行 SubAgent 并行开发？（是 / 否 / 需调整）"
当 brainstorming / spec 需要表达布局、流程、状态机、组件层级、数据流等结构性信息时，一律用 ASCII / Unicode 制表符直接在对话或 Markdown 中呈现，不要外链图片、不要调浏览器。
何时画：
┌─┐│└┘ 或 +--+| |+--+）。─▶ ▼ ◀─ 或 --> | <--）。├─ └─ 缩进树。怎么画：
─│┌┐└┘├┤┬┴┼▶◀▲▼），ASCII 退化方案 -|+><^v 仅在不支持 Unicode 的输出场景使用。``` 代码块（无语言标记或标 text），避免 Markdown 渲染破坏对齐。图 1 / 图 2）并在 spec 正文交叉引用。示例（页面布局）：
┌──────────────────────────────────────────┐
│ 顶部筛选区 [日期] [门店] [角色] [导出] │
├──────────────┬───────────────────────────┤
│ │ ┌───────────┐ ┌────────┐ │
│ 左侧导航树 │ │ KPI 卡 ×4 │ │ 趋势图 │ │
│ │ └───────────┘ └────────┘ │
│ │ 明细表（虚拟滚动） │
└──────────────┴───────────────────────────┘
绝对禁止：