spec-init
starsforks
How to install spec-init?
legeling/prompthub/spec-init
$npx -y skills add legeling/PromptHub --skill spec-init面向新项目或现有项目的文档驱动开发 skill。Use when the user wants to create, 补齐, 更新, or refine project specs, run a Spec Kit-inspired workflow loop, maintain workflow/knowledge/change docs, analyze consistency, converge implementation back into docs, or update README/AGENTS for a real project.
SKILL.md
| 1 | # /spec-init — Agent 驱动的文档开发 skill |
| 2 | |
| 3 | 这个 skill 不是“帮用户创建一堆空模板”的脚手架，也不是“固定 Bash 初始化器”。 |
| 4 | |
| 5 | 它的真正职责是： |
| 6 | |
| 7 | - 先理解用户目标 |
| 8 | - 先理解现有项目或上下文 |
| 9 | - 通过 agent 的分析、追问、归纳和写作，产出真正可用的 spec |
| 10 | - 用 spec 驱动后续设计、实现、测试和文档同步 |
| 11 | - 把 spec 当成持续演进的项目资产，而不是一次性启动产物 |
| 12 | |
| 13 | ## 目标 |
| 14 | |
| 15 | - 帮用户把模糊想法整理成能执行的 spec |
| 16 | - 帮已有项目补齐缺失的 intake / requirements / design / verification / tasks / rules |
| 17 | - 帮用户区分 what / why / how / verify / do-next |
| 18 | - 形成至少一条完整追踪链：`FR -> DES -> TEST -> T` |
| 19 | - 在信息不足时主动提供候选方案、对比、建议，而不是只留下空白 |
| 20 | - 帮用户逐步补全完整需求、完整设计、完整验证策略，而不是只停留在最小第一版 |
| 21 | - 帮项目把测试策略、测试标准、测试设计、用例矩阵、回归套件、测试数据和覆盖映射拆成可维护文档，而不是把测试计划平铺成一份进展报告 |
| 22 | |
| 23 | ## 核心定位 |
| 24 | |
| 25 | 默认把这个 skill 当成“agent 写 spec 的工作流”，不是“脚本生成目录”。 |
| 26 | |
| 27 | 优先级： |
| 28 | |
| 29 | 1. 理解用户和项目现状 |
| 30 | 2. 读代码 / 读文档 / 读目录结构 |
| 31 | 3. 澄清关键问题 |
| 32 | 4. 产出或更新有内容的 spec |
| 33 | 5. 必要时才借助模板或脚本补齐基础结构 |
| 34 | |
| 35 | ## 何时使用 |
| 36 | |
| 37 | - 用户说“帮我做 spec”“补需求文档”“整理设计文档”“先别写代码，先把文档理清” |
| 38 | - 用户有现成项目，想补齐或更新 `docs/`、`README.md`、`AGENTS.md` |
| 39 | - 用户想做文档驱动开发、spec-first、design-first、verification-first |
| 40 | - 用户想让 agent 帮他决定还缺哪些文档、哪些规范、哪些待确认问题 |
| 41 | |
| 42 | ## 何时不要使用 |
| 43 | |
| 44 | - 用户只想要一个临时脚本、一次性 demo 或纯代码实现 |
| 45 | - 当前任务只是修一个小 bug、补一条测试、做一次 review |
| 46 | - 用户明确不想做 spec，只要直接写代码 |
| 47 | |
| 48 | ## 两种主要场景 |
| 49 | |
| 50 | ### 场景 A：新项目 |
| 51 | |
| 52 | 用户只有一个想法、方向或需求草稿。 |
| 53 | |
| 54 | 你要做的是： |
| 55 | |
| 56 | - 先把想法拆成 intake / requirements / design / verification / tasks |
| 57 | - 如果用户不懂概念，主动给方案、对比和建议 |
| 58 | - 不要只生成空文件；至少把当前已知信息写进去 |
| 59 | |
| 60 | ### 场景 B：现有项目 |
| 61 | |
| 62 | 用户已经有代码或仓库，想完善、补齐或更新 spec。 |
| 63 | |
| 64 | 你要做的是： |
| 65 | |
| 66 | - 先读仓库结构、README、核心代码、现有 docs |
| 67 | - 找出当前真实行为、模块边界、依赖关系、缺失文档 |
| 68 | - 基于现状写 spec，而不是凭模板猜一个“理想项目” |
| 69 | - 对已有项目优先增量补文档，不要粗暴覆盖 |
| 70 | |
| 71 | ## 核心原则 |
| 72 | |
| 73 | - 不要把模板当结果，模板只是辅助。 |
| 74 | - 文档必须反映当前项目真实情况或当前轮次的明确决策。 |
| 75 | - 用户没有提到但又必须明确的内容，要主动提出候选方案和对比。 |
| 76 | - 推荐可以给，但推荐不是确认；不要替用户拍板关键决策。 |
| 77 | - 如果项目已存在，先读代码再写文档，不要反过来。 |
| 78 | - 如果信息不全，写 `[待确认]`，但不要把整份文档都留空。 |
| 79 | - spec 不是一次性文档；每轮需求变化、设计变化、实现变化后都要继续完善。 |
| 80 | |
| 81 | ## Repository Profiles |
| 82 | |
| 83 | When this skill runs inside the PromptHub repository, read and follow |
| 84 | `references/prompthub-profile.md` before choosing document paths or change |
| 85 | lifecycle semantics. The profile adapts upstream `docs/*` examples to |
| 86 | PromptHub's `spec/*` topology without weakening the upstream phase gates. |
| 87 | |
| 88 | ## 文档边界 |
| 89 | |
| 90 | 先阅读并遵循： |
| 91 | |
| 92 | - `references/doc-boundaries.md` |
| 93 | - `references/example-idea-to-docs.md` |
| 94 | |
| 95 | 边界如下： |
| 96 | |
| 97 | - `docs/workflow/00-intake/README.md`: 为什么做，谁来用，什么不做 |
| 98 | - `docs/workflow/01-requirements/README.md`: 做什么，为什么做，怎么验收 |
| 99 | - `docs/workflow/02-design/README.md`: 当前阶段怎么实现，方案对比，规范约定 |
| 100 | - `docs/knowledge/context/README.md`: 长期稳定的角色、术语、实体、业务边界 |
| 101 | - `docs/knowledge/structure/README.md`: 长期稳定的模块边界、系统结构、集成关系 |
| 102 | - `docs/knowledge/behavior/README.md`: 长期稳定的关键流程、状态流转、业务规则 |
| 103 | - `docs/knowledge/reference/README.md`: 样例、协议、schema、素材、fixtures 等固定参考资料 |
| 104 | - `docs/workflow/03-implementation/README.md`: 先做什么后做什么 |
| 105 | - `docs/workflow/04-verification/README.md`: 怎么验证完成 |
| 106 | - `docs/workflow/04-verification/01-test-strategy-and-quality-gates.md`: 长期测试策略、测试层级、质量门禁和准出标准 |
| 107 | - `docs/workflow/04-verification/02-test-standards.md`: 测试代码命名、断言、隔离、Mock、失败路径和报告规则 |
| 108 | - `docs/workflow/04-verification/03-test-design-methodology.md`: 等价类、边界值、状态机、决策表、安全、并发、契约和回归设计方法 |
| 109 | - `docs/workflow/04-verification/04-test-case-matrix.md`: 模块级测试用例矩阵、优先级、层级、自动化状态和覆盖对象 |
| 110 | - `docs/workflow/04-verification/05-regression-suite.md`: 长期回归套件、触发条件、命令登记规范和残余风险记录 |
| 111 | - `docs/workflow/04-verification/06-test-data-and-fixtures.md`: 测试数据、fixtures、H2/Redis/外部依赖替身和脱敏规范 |
| 112 | - `docs/workflow/04-verification/07-coverage-map.md`: 模块、需求、设计、测试资产和已知缺口之间的覆盖映射 |
| 113 | - `docs/workflow/05-tasks/README.md`: 现在具体做什么动作 |
| 114 | - `docs/issues/README.md`: 尚未解决的问题、阻塞项、风险和技术债 |
| 115 | - `docs/changes/`: 这次为什么变、影响什么、同步了哪些文档和测试 |
| 116 | - `docs/releases/`: 某个版本最终对外交付了什么 |
| 117 | - `docs/archive/README.md`: 已归档、已替代、已废弃但仍需保留历史的文档 |
| 118 | - `docs/adr/`: 关键架构或技术决策为什么改变 |
| 119 | - `docs/rules/`: 默认工程规则 |
| 120 | |
| 121 | ## Spec Kit 借鉴的阶段循环 |
| 122 | |
| 123 | 这个 skill 保留自己的 layered docs 拓扑，但执行节奏借鉴 Spec Kit 的阶段化工作流： |
| 124 | |
| 125 | | 阶段 | spec-init 落点 | 目标 | |
| 126 | |---|---|---| |
| 127 | | specify | `docs/workflow/00-intake/README.md`, `docs/workflow/01-requirements/README.md` | 把想法变成用户、边界、FR/NFR/AC | |
| 128 | | clarify | intake / requirements 的待确认区，必要时更新 `docs/issues/` | 只澄清会影响范围、架构、数据、权限、测试的关键问题 | |
| 129 | | plan | `docs/workflow/02-design/README.md`, `docs/workflow/03-implementation/README.md`, `docs/workflow/04-verification/README.md`, `docs/knowledge/` | 形成设计、实施顺序、验证策略和长期真相 | |
| 130 | | tasks | `docs/workflow/05-tasks/README.md`, `docs/changes/active/<change-key>/tasks.md` | 拆成可执行、可验证、可追踪的任务 | |
| 131 | | analyze | tasks 完成后、实现前，检查 requirements / design / verification / tasks / changes 是否冲突 | 找孤立 ID、缺失映射、未确认阻塞项和文档边界错误 | |
| 132 | | implement | 代码、测试、脚本、迁移等真实改动 | 只执行已能回链到 `FR -> DES -> TEST -> T` 的工作 | |
| 133 | | converge | 完成后回写 workflow、knowledge、changes、issues、releases、archive、README、AGENTS | 让代码现状、当前真相和历史变更记录重新一致 | |
| 134 | |
| 135 | 不要把这些阶段理解成必须生成 `specs/` 目录。`spec-init` 的长期文档源仍是当前项目的 `docs/` 拓扑。 |
| 136 | |
| 137 | ## 默认工作流 |
| 138 | |
| 139 | ### Step 0: 判断是“新项目”还是“现有项目” |
| 140 | |
| 141 | 先判断： |
| 142 | |
| 143 | - 当前目录是否已有代码、配置、README、docs、测试 |
| 144 | - 用户是要从零梳理，还是基于现状补齐 spec |
| 145 | |
| 146 | 如果是现有项目： |
| 147 | |
| 148 | - 先读目录结构 |
| 149 | - 先读 README / docs / 关键入口代码 |
| 150 | - 先梳理真实调用链和模块边界 |
| 151 | |
| 152 | 如果是新项目： |
| 153 | |
| 154 | - 先整理用户目标和约束 |
| 155 | - 再建立最小 spec 结构 |
| 156 | |
| 157 | ### Step 0.1: 识别本轮意图 |
| 158 | |
| 159 | 先判断这次请求更接近哪一类： |
| 160 | |
| 161 | - 继续实施：主要推进 `tasks / verification / implementation` |
| 162 | - 新需求引入：主要更新 `requirements / design / knowledge |
People who liked this also viewed
6 picksType
- lark-drive飞书云空间（云盘/云存储）：管理 Drive 文件和文件夹，包含上传/下载、创建文件夹、复制/移动/删除、查看元数据、评论/权限/订阅、标题、版本、飞书文档密级标签（secure labels）和本地文件导入。用户需要整理云盘目录、处理云空间资源 URL/token、判断链接类型/真实 token/标题，或导入 Word/Markdown/Excel/CSV/PPTX/.base 为 docx/sSkillsJul 2026
- lark-sharedUse for lark-cli setup/auth tasks: auth login/status/logout, user vs bot identity, business-domain permissions (--domain, including all/docs/drive), missing scopes, revoking authorization, or handlingSkillsJul 2026
- lark-whiteboard飞书画板：查询和编辑飞书云文档中的画板。支持导出画板为预览图片、导出原始节点结构、使用多种格式更新画板内容。 当用户需要查看画板内容、导出画板图片、编辑画板时使用此 skill。不负责：飞书云文档内容编辑（lark-doc）、文档内嵌电子表格/Base（lark-sheets / lark-base）。SkillsJul 2026
- lark-task飞书任务：管理任务、清单和任务智能体。创建待办任务、查看和更新任务状态、拆分子任务、组织任务清单、分配协作成员、上传任务附件、注册或注销任务智能体、更新任务智能体的主页数据、写入智能体任务记录。当用户需要创建待办事项、查看任务列表、跟踪任务进度、管理项目清单或给他人分配任务、为任务上传附件文件、注册注销任务智能体、更新智能体主页数据、写入任务记录时使用。SkillsJul 2026
- lark-attendance飞书考勤打卡：查询自己的考勤打卡记录SkillsJul 2026
- lark-apps妙搭（Spark/Miaoda）应用开发与托管：应用创建、本地全栈开发、云端生成迭代、创意设计（UI mockup / 可交互原型 / 线框图 / 落地页 / 仪表盘 / 幻灯片 deck / 视觉探索）、AI相关能力和飞书平台能力或者其他外部能力集成、日志/Trace/监控指标/PV/UV 查询、环境变量管理、应用角色与成员管理、自动化触发器（定时/记录变更/Webhook/飞书审批）。当用户要SkillsJul 2026
