code-to-spec

分类: 工具与效率 | 上传者: MoeGolibrary | 下载: 0 | 版本: v1.0（最新）

Triggered when user asks to write a SPEC or module specification. Generates SPEC.md for UI components, hooks/utilities, scripts/toolchains, and business modules. --- # SPEC 编写 为项目中的模块编写 SPEC.md——让 AI 或新开发者仅凭此文件 + 项目级上下文即可从零还原实现。 SPEC 不是使用文档（Storybook / README 的职责），也不是 API 参考（TypeScript 类型的职责）。 ## 模块类型 本 SKILL 支持四种模块类型，每种类型有独立的配置文件： | 类型 | 配置文件 | 典型目标 | | ----------- | ------------------------------------- | ---------------------------------------- | | UI 组件 | `references/type-ui-component.md` | Button, Modal, Cascader | | Hook/工具 | `references/type-hook-utility.md` | useControllableState, filterDOMProps, cn | | 脚本/工具链 | `references/type-script-toolchain.md` | gen-tokens, build-entry, create-comp | | 业务模块 | `references/type-business-module.md` | MCP server, analytics module | 类型配置文件包含：Research 必读文件、复杂度分级标准、章节模板、逆向工程示例表、Verify 额外过滤项、内容取舍补充。 ## 流程 ### Step 0: Classify（类型识别） 在 Research 之前，先识别目标代码的模块类型： ```text 目标代码是否有 UI 渲染（JSX/TSX 输出，面向终端用户的视觉界面）？ ├─ 是 → UI 组件 └─ 否 → 是否是可复用的函数或 hook（被其他模块导入调用）？ ├─ 是 → Hook/工具 └─ 否 → 是否是独立可运行的脚本或 CLI（有明确的执行入口）？ ├─ 是 → 脚本/工具链 └─ 否 → 业务模块 ``` 识别结果决定后续每个步骤的差异化配置。如果边界模糊，选择主要职责对应的类型，并在 SPEC 开头注明。 **识别完成后，阅读对应的类型配置文件。** ### Step 1: Research（阅读源码） 按类型配置文件中的"Research 必读文件"列表和优先级阅读。 阅读时重点关注： - 子模块组成及依赖关系 - 状态/数据流的层级和传递方式 - 与其他模块的复用模式及边界 - 非常规实现选择及原因 - 标记为 deprecated 的内容应完全忽略，SPEC 只描述当前有效的设计 - 通过导出入口确认公共 API 边界——未导出的模块不应在 SPEC 中作为使用者可用的功能描述 ### Step 2: 复杂度分级 按类型配置文件中的"复杂度分级"标准判断，校准后续写作的粒度和结构。 ### Step 3: Draft（撰写初稿） 按类型配置文件中的"章节模板"和文件位置规则创建 SPEC.md。各章节写作要点见 `references/writing-guide.md`。 写作时始终保持"预先设计"视角——假设代码尚不存在，你是架构师在做设计。写每条约束时即时自检："如果我没看过源码，我能写出这句话吗？"如果答案是否，立即将其提升到设计意图层面或删除，不要留到 Refine 阶段再处理。 对"关键设计约束"章节的每一条，完成写作后执行来源标注自检：回顾这条约束的信息来源是"设计意图推导"还是"源码观察"。如果来源是源码观察，必须改写为设计意图表述或删除。 典型的源码观察信号： - 正在用代码中的术语描述一个转换过程 → 应只描述对外暴露的语义 - 正在指明某个参数映射到哪个具体的实现机制 → 应描述这个参数的行为效果 - 正在描述多个值的合并/计算顺序 → 应描述优先级关系 常见的即时自检失败信号： - 正在描述"什么时候传什么值" → 调用指南，不是设计

更新日志: Source: GitHub https://github.com/MoeGolibrary/moego-ai-plugin