القائمة
Use when receiving an ambiguous feature request, when scope is unclear, or before writing any plan
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when a feature, bugfix, or refactoring step is completed and needs review, or before merging to main, or when user says "review", "审查", "帮我看看代码"
Use after verification-before-completion passes and code review is clean, to close out the development branch
Use when executing git commit, creating or naming branches, writing PR titles/descriptions, or asking about commit message format, branch naming, or version numbering in this project
Use when writing or reviewing .ets/.ts files in this project, or when seeing any, unknown, obj['key'] index access, destructuring assignment, var declarations,
Use when user asks to create a version release ticket, says "帮我建个发版任务", "建个 Jira", "创建发版单", or needs to track an SDK release in Jira
Use when user mentions "发布 SDK"、"ohpm 发布"、"打包发布"、"上传 har"、"publish"、"发版"、"release"、"发布" or "上传" in the context of this SDK
| name | brainstorming |
| description | Use when receiving an ambiguous feature request, when scope is unclear, or before writing any plan |
Type: Pattern | Discipline: Flexible
把模糊需求通过"一次一个问题"的方式，收敛成一份可用于 writing-plans 的设计规格。
必须走本流程：
不走本流程：
docs/sdk-engineering-guide.md 索引、近 3 次 commit、相关模块 docindex.ets 导出符号）？ignoreField 枚举）docs/specs/YYYY-MM-DD-<topic>.mdTODO、有无自相矛盾、范围是否闭合User request
│
▼
Explore project context (guide index + recent commits + module docs)
│
▼
Scope sanity check ── 需求过大？─YES→ 先拆子项目，只对第一个子项目继续
│ NO
▼
Ask clarifying questions (one at a time, multiple-choice preferred)
│
▼
Propose 2–3 approaches with trade-offs
│
▼
Present design in sections → per-section approval
│
▼
Write spec to docs/specs/YYYY-MM-DD-<topic>.md
│
▼
Self-review (placeholders / contradictions / scope)
│
▼
User reviews spec file ── approved? ─NO→ revise
│ YES
▼
回到主流程 → Read relevant docs → Planning Gate（统一判定）
每个改动都走流程。简单改动的规格可以只有几行，但必须写下来并拿批准。"简单"是最常出错的地方——你以为的简单通常是"我忽略了若干假设"。
一次一个问题。多问 = 用户挑 1–2 个回答，其余遗漏。多选题 > 开放题。
| 借口 | 现实 |
|---|---|
| "我已经懂了需求" | 你懂的是字面，规格是把假设写下来让用户挑错 |
| "用户会觉得啰嗦" | 比事后返工友好 10 倍 |
| "先写 plan 再说" | plan 以规格为输入；输入错，plan 全错 |
| "bug 修复不用走" | 是，但得先确认 root cause，否则这是个伪装成 bug 的需求 |
brainstorming 收敛规格并拿到用户确认后，不自行判定影响面，直接回到主流程：
规格确认 → Read relevant docs → Planning Gate（统一判定）
影响面判定权归 Planning Gate 一处（using-growingio-sdk-skills meta-skill），brainstorming 不重复判定、不自行分叉。