用途：将已敲定的对话与仓库上下文合成为一份 spec，并发布到 Workplan。调用本身即授权发布，不进行访谈或审批轮次；若缺少必要意图，应报告缺失输入，而不是编造或创建不完整的工作项。
前置条件：使用 wp 前需先加载 ai-workplan 技能；若不可用，应停止并提示用户先安装。随后遵循其指向的机器输出契约与工作项命令参考，它们是信封、分页、校验、类型化错误和命令标志的权威来源。
流程：先探索仓库，阅读适用的领域术语表与 ADR，检查实现区域、最接近的先例及其测试；spec 中使用术语表词汇并遵循 ADR 决策；选择能证明所需行为的最高现有测试接缝，仅当更高接缝无法使行为可观察时才引入更低接缝。解析来源谱系：仅当调用或对话明确指明来源工作项时才设置 source，并将其解析为 wp --json 输出中的一个精确 slug；无法唯一解析时应询问；当前主题、相似标题和近期工作项不构成谱系证据；未明确时保持 source 缺失。派生标识：从已确定功能写简洁标题，标题去空格后非空且不含 ASCII 控制字符；由标题和仓库术语派生 ASCII 基础 slug（小写、将 a-z 与 0-9 之外的连续字符替换为单个连字符、去除边缘连字符、最多 63 字节且不留边缘连字符）；若规范化产生空 slug，则使用更具体的已确定术语。通过 wp --json workplan list 列出工作项并跟随所有游标，因为 slug 跨类型全局唯一；将返回的每个 slug 视为已占用；基础可用则用基础，否则从 -2 起测试数字后缀并选第一个可用候选，每个后缀需预留其字节、将基础截断至 63 字节限制的剩余部分并去除尾部连字符后再拼接；若后缀导致没有非空且准确的基础，则在写入前停止。现有工作项是不可变输入，绝不更新、删除、恢复或复用以腾出候选。
撰写 spec：生成一个 Markdown 值，包含 Problem statement、Solution、User stories（编号列表，形式为 As an <actor>, I want <feature>, so that <benefit>，覆盖所有已确定行为与失败边界且不虚构范围）、Implementation decisions（记录已确定的模块、接口、架构、schema 与交互决策，除非原型片段是最清晰记录否则不用文件路径或代码片段）、Testing decisions（命名外部行为、最高有用测试接缝、覆盖模块与最接近测试先例）、Out of scope、Further notes。Markdown 需陈述已确定行为、决策、测试接缝、失败边界与排除项，无占位符或未决猜测；保留最终字节含行尾与尾随换行。
发布：创建一个私有临时 .md 文件并写入最终 Markdown，将其作为显式内容输入；仅对第 2 步解析出的来源包含 --source： wp --json workplan create --type spec --slug <candidate> --title <title> [--source <source-slug>] --content <temporary-file> 遇到 already_exists 时，将该候选标记为已占用，按第 3 步算法选择下一候选，并以相同标题、来源选择和临时文件重试创建；这是唯一重试路径，不重复仓库探索、来源解析、列表或起草。遇到 database_busy 或任何其他错误时停止，不再调用跟踪器。无论结果如何，返回前删除临时文件；不使用 stdin、编辑器或第二个临时文件。冲突或失败后所有现有工作项保持不变。
返回结果：检查 schema_version，忽略附加的未知字段，并按类型化错误码分支。成功时验证 type 为 spec、slug 为最终候选、标题匹配、content_markdown 与草稿完全一致、source_workplan 匹配显式来源或在未给来源时为 null；返回规范创建资源与 slug。失败时在清理后返回类型化代码及其安全详情。绝不将创建失败替换为更新或内容写入。