用途：将当前对话上下文与对代码库的理解综合为一份 spec，并发布到项目 issue tracker。明确要求不要访谈用户，只综合已知信息。
前提：issue tracker 与 triage 标签词表应已提供，否则运行 /setup-matt-pocock-skills。
流程：探索仓库以了解代码库现状；在 spec 中沿用项目领域术语表词汇，并遵守相关区域的 ADR；规划测试接缝（seam），优先复用现有接缝，使用尽可能高的接缝，若需新接缝则在最高点提出，接缝越少越好，理想为一个；与用户确认这些接缝符合预期；按模板撰写 spec 并发布到 issue tracker，打上 ready-for-agent 标签，无需额外 triage。
模板结构：问题陈述（从用户视角描述问题）、解决方案（从用户视角描述解决方式）、用户故事（长篇编号列表，格式为 As a ... I want ... so that ...，覆盖功能各方面）、实现决策（要构建或修改的模块、被修改的接口、开发者的技术澄清、架构决策、schema 变更、API 契约、具体交互；不要包含具体文件路径或代码片段，例外是原型产生的能更精确表达决策的片段，如状态机、reducer、schema、类型形状，可内联并简述来自原型，只保留决策密集部分）、测试决策（好测试的标准：只测外部行为而非实现细节；哪些模块会被测试；测试的先例，即代码库中类似测试）、超出范围（本 spec 不涵盖的内容）、补充说明。
限制：资料未提供该技能所属平台、安装方式、价格、支持语言及实际发布效果等信息。