课程与场次
课程介绍、讲师、一次具体开课时间和容量。
可能功能：建课、排期、上下架。
一条可跟做的路线：目标太大先用 wayfinder 建决策票；澄清后进入 to-spec 和 to-tickets；每张实现票用 implement（内部 TDD），再按固定比较点执行 code-review。不同阶段的结论分别写回术语、ADR、规格与票据。
大项目用法
大项目不是把整条流程只跑一次，也不是每个页面都从头跑一遍
正确理解是“分层重复”：项目规则只配置一次；大目标各建一张决策地图；每个功能或重要变更重复规格流程；每张票单独实现和审查。
① 仓库 / 项目级通常只做 1 次
用什么：setup-matt-pocock-skills
解决什么：票据放哪里、项目使用单上下文还是多上下文、AI 应读哪些规则。只有切换票据系统或重做布局才重跑。
② 大目标级每个大目标 1 张地图
用什么：wayfinder
解决什么：“完成培训小程序第一版”“增加付费课程体系”这类一个会话想不完的目标。一次只解决一张决策票。
③ 业务上下文级按业务语言划分
用什么：domain-modeling + CONTEXT-MAP.md
解决什么：报名、支付、学习进度等业务含义明显不同且规则很多时，各有术语表和局部 ADR。不是每个页面一个上下文。
④ 功能 / 变更级每次重要需求都重复
用什么：grill-with-docs → to-spec → to-tickets
解决什么：新增签到、修改退款、增加证书等。旧系统已经存在也一样先明确“改什么、不改什么”。
⑤ 票据级每张票重复
用什么：implement → tdd → code-review
解决什么：一张票对应一个清晰的实现边界，小步实现、测试、审查。小功能可留在当前任务；需要隔离或并行时再开新任务。
⑥ 故障 / 维护级事件发生时触发
用什么：diagnosing-bugs、triage、improve-codebase-architecture
解决什么：它们从事故、反馈或维护入口进入，不要求重新走完整个项目设计。
培训小程序应该怎样拆？先分“业务上下文”，再分“功能”
报名与签到
名额、候补、取消、二维码签到和出勤。
可能功能：报名、补位、签到。
支付与退款
订单、支付状态、退款规则、对账。
可能功能：下单、回调、退款。
学习与证书
学习进度、作业、完成条件、证书资格。
可能功能：进度、作业、发证。
不要按菜单或页面机械分模块。“首页、我的、管理后台”是界面位置，可能同时调用多个业务上下文。是否需要独立
CONTEXT.md，看它是否拥有一套独立而容易混淆的业务语言、规则和决策，而不是看它有没有单独文件夹。第一次做整个培训小程序：不是一场对话设计完
第一次：项目建制
setup 只跑一次。
如果项目明显很大，用 wayfinder 把“可交付第一版规格”设为目的地。
→
N 次：逐个消除未知
一场会话只解决一张决策票，例如“免费还是付费”“报名与订单是什么关系”。
用 research、prototype 或 grilling；结论实时进入术语表和 ADR。
→
N × M 次：逐功能交付
地图清晰后，为每个可交付功能走 spec → tickets。
每张票再单独 implement → review，直到第一版完成。
文档怎样组织，后面改了才不会互相打架？
培训小程序仓库/
├─ AGENTS.md # AI 的全项目工作规则
├─ CONTEXT-MAP.md # 只做导航：去哪找各业务语言
├─ docs/adr/ # 影响全系统的决策
├─ src/course/
│ ├─ CONTEXT.md # 课程/场次术语
│ └─ docs/adr/ # 课程局部决策
├─ src/enrollment/
│ ├─ CONTEXT.md # 报名/候补/签到术语
│ └─ docs/adr/
├─ src/payment/
│ ├─ CONTEXT.md # 订单/退款/对账术语
│ └─ docs/adr/
└─ issue tracker # 地图、规格、票据与历史
每类文档只回答一种问题
AGENTS.md：AI 在这个仓库必须遵守什么工作规则？
CONTEXT-MAP.md：哪个业务上下文的共同语言放在哪里？它是目录，不复制内容。
CONTEXT.md：“课程、场次、报名、订单”分别是什么意思？只放术语，不放实现方案。
ADR：为什么做了一个难逆转、令人意外且存在真实取舍的决定？
Spec：这一次功能或变更应该表现成什么样？
Ticket：这次具体交付哪一个可独立验收的切片？
后来要修改系统时，应该改哪里？
| 变化场景 | 从哪里进入 | 更新哪些文档 | 不用动什么 |
|---|---|---|---|
| 只修一个确定的 Bug | diagnosing-bugs | 回归测试；若暴露出术语或既有决策错误，再更新对应文档 | 不重跑 setup，不重做整个项目规格 |
| 增加“课后评价” | grill-with-docs → to-spec | 新功能规格和票据；出现新业务词时更新对应 CONTEXT.md | 不改无关模块的术语表 |
| 把免费课程改为付费 | wayfinder（若跨报名/订单/退款且未知多） | 跨模块决策票；根 ADR 或相关上下文 ADR；各功能的新规格 | 不在旧票据里偷偷改历史 |
| 只重构内部代码，不改行为 | improve-codebase-architecture 或明确的重构规格 | 测试、必要的模块接口说明；若架构取舍满足 ADR 三条件才写 ADR | 不要把实现细节写进 CONTEXT.md |
| “报名”一词定义改变 | domain-modeling | 报名上下文的 CONTEXT.md；检查受影响规格与代码，必要时开变更票 | 不能只改代码而留下旧定义 |
| 切换整个票据平台 | setup-matt-pocock-skills | docs/agents/issue-tracker.md 与根规则 | 无需重新设计全部功能 |
保证文档统一的 6 条纪律
先读后改
每次开始功能前，先读根规则、CONTEXT-MAP、当前上下文术语、相关 ADR 和父规格。
一条事实一个家
术语只在 CONTEXT 定义；决策详情只在 ADR；地图只链接摘要，避免复制后产生多个版本。
结论当场落档
grill-with-docs 决定了新词或改变了定义，就在当前对话立刻更新，不能等项目结束再补。
变更开新记录
需求改变时创建新的变更规格/票据并引用旧记录，不把已经执行过的历史悄悄改成“从来如此”。
审查文档影响
在 AGENTS.md 写入完成条件：代码审查必须回答“是否需要更新 CONTEXT、ADR、Spec 或 Runbook”。
证据与状态分开
对话、测试通过、代码合并、已部署、线上验证是不同状态；文档只能声明已有证据支持的状态。
这套技能能做什么，不能自动保证什么？
能：用 wayfinder 跨多任务规划；用 CONTEXT-MAP 支持多业务上下文；把术语、决策、规格和票据放在各自位置；在确有可携带上下文需求时用 handoff 交接。
不能自动保证：它不会自己判断所有模块边界都正确，也不会自动发现每份文档已过期，更不会替代产品路线图、版本发布、权限安全和线上监控。要靠 AGENTS.md 的完成规则、code-review 的 Standards 轴以及人工验收持续执行。
四种你最常遇到的走法
培训小程序从 0 到 1
setup（一次）→ wayfinder（项目第一版地图）→ 决策票 × N → 各功能 spec → tickets → implement × N
报名模块增加二维码签到
读报名 CONTEXT/ADR → grill-with-docs → 更新新术语 → to-spec → to-tickets → implement × N
免费培训改成付费培训
wayfinder → 支付/报名/退款决策票 → 系统级 ADR → 多个关联 spec → 按依赖实施
付款成功却没有报名成功
diagnosing-bugs → 跨支付/报名追踪反馈回路 → 修复与回归测试 → review → 受控发布与监控
文档与项目记忆
AI 为什么能在下一次任务里接着做？因为结论进了“有地址的文档”
对话不是项目数据库。要让你和 AI 都能找回来，必须同时知道：权威入口、文档路径、阅读时机和更新责任。
先记结论
项目规则和业务事实放仓库；规格与任务放票据系统；未完成的临时现场才放 handoff。下一任务永远先从仓库根目录的 AGENTS.md 和 docs/agents/ 找入口。
一条开发任务，文档是这样接力的
1 项目入口
AGENTS.md告诉 AI 先读什么、票据在哪、完成要交什么证据。2 共同语言
CONTEXT.md把“课程、场次、报名、候补”等词说成同一个意思。3 决策理由
docs/adr/保存重要取舍，避免以后不知原因地改回去。4 本次工作
Spec + Ticket说明这次做什么、不做什么，以及每张票怎样验收。5 真实证据
代码 + 测试 + Git证明实际做到了什么；票据状态只能按证据更新。路径不一定在所有项目里完全相同。setup 会先决定你使用 GitHub、GitLab 还是本地 Markdown，并把权威位置写入
docs/agents/issue-tracker.md；单上下文还是多上下文则写入 docs/agents/domain.md。所以不要死记所有路径，先记住这两个“地图文件”。文档总账：放在哪里、用来干嘛、谁什么时候读
| 文档 / 记录 | 默认或示例路径 | 由谁产生或更新 | AI 什么时候读 | 你什么时候必须看 | 功能完成后是否变化 |
|---|---|---|---|---|---|
| 项目工作规则 | 项目根目录/AGENTS.md | setup 初次写入；规则改变时更新 | 每个新任务开头都应读 | 通常不用逐次读；当工作流程、完成标准或安全边界改变时看 | 普通功能通常不改；只有全项目规则改变才改 |
| 票据位置说明 | docs/agents/issue-tracker.md | setup | 找规格、票据、状态前读 | 首次 setup 后确认一次；切换票据平台时再看 | 普通功能不改；GitHub/GitLab/本地模式变化才改 |
| 业务文档导航 | docs/agents/domain.mdCONTEXT-MAP.md（多上下文时） | setup / domain-modeling | 判断该去读哪个业务模块前 | 新增、合并或拆分业务上下文时看 | 模块边界没变就不改；新增“支付”等独立上下文才改 |
| 业务术语表 | 小项目：CONTEXT.md大项目示例： src/enrollment/CONTEXT.md | grill-with-docs 内的 domain-modeling | 设计或实现所属模块前必须读 | 新词、定义、状态含义改变时必须确认 | 只有业务词义或规则发生变化才改；普通代码重构不改 |
| 架构决策记录 ADR | 全局：docs/adr/0001-*.md局部示例： src/payment/docs/adr/ | grill-with-docs / domain-modeling | 设计或修改相关行为前读 | 难逆转、意外、存在真实取舍的决定必须看 | 不是每票都改；重大决策改变时新增 ADR，并标明旧 ADR 被替代 |
| 决策地图、规格、票据 | 远程模式：GitHub/GitLab Issue 链接 本地模式：通常在 .scratch/<feature>/，票据示例为 issues/NN-slug.md | wayfinder、to-spec、to-tickets | 领取任务前读父规格、当前票据和依赖 | 规格的 User Stories / Out of Scope，以及票据粒度和依赖必须确认 | 实现后更新票据状态和证据；需求变化要开新变更规格，不偷偷重写已执行历史 |
| 研究与原型 | 研究：由任务指定仓库内 Markdown 路径 原型：独立目录或分支，路径不固定 | research / prototype | 相关事实或设计仍被引用时读 | 只看结论、证据和未确定项；原型需亲手试用 | 结论应回写正式规格/ADR；原型本身不是长期事实来源 |
| 临时交接单 | 系统临时目录/...handoff....md | handoff | 未完成工作换任务时，新 Agent 第一次读 | 确认目标、未提交改动、测试状态和下一步是否准确 | 只记录未完成现场；任务完成后不继续维护，也不能代替项目文档 |
| 发布运行手册 | 项目自定，建议 docs/runbooks/<topic>.md | 项目团队；这 25 个技能不会自动补齐 | 发布、排障、回滚前读 | 首次上线、发布方式变化、真实故障后必须看 | 发布步骤、监控或回滚方式改变时更新 |
“项目根目录”是什么？就是最外层的项目文件夹，通常能看到 AGENTS.md、src/、package.json 或 .git/。表里的路径都是从这里开始算的“相对路径”。
本地票据路径仍不确定怎么办？不要猜。让 AI 先读 docs/agents/issue-tracker.md 并回报它找到的实际目录和第一张可执行票据。
不是所有文档都需要你亲自逐字读
AI 负责读全套“执行上下文”
- 每个任务先读 AGENTS.md。
- 按 docs/agents 的导航找到正确 CONTEXT、ADR、规格和票据。
- 检查依赖、当前代码、Git 状态和测试结果。
- 结束时列出本次改了哪些文档、为什么改。
你重点读“业务与风险决策”
- CONTEXT 中新增或改变的业务定义。
- ADR 中的选择、替代方案和后果。
- Spec 的 User Stories 与 Out of Scope。
- code-review 的 Spec 轴、人工验收项、未验证风险。
你的最低阅读责任：确认“词是什么意思、这次做什么和不做什么、重大选择会带来什么后果、最终行为是不是你要的”。编码规范、文件组织、类型错误等技术细节可以让 AI 主查，但它必须给你结果和证据。
一个功能开发完，哪些东西会变化？
普通功能实现
通常变化：代码、测试、当前票据状态、提交记录。
可能不变：AGENTS、CONTEXT、ADR。没有新规则就不要为了“留痕”乱改。
业务定义或重大决策改变
必须变化：对应 CONTEXT 或新增/替代 ADR，再建立新的变更规格和票据。
你要看：新旧含义差异、影响模块、迁移和兼容风险。
发布到真实用户
通常还要变化：Runbook、部署/迁移记录、监控与回滚证据。
你要看：线上验证结果；只有“测试通过”不能写成“已发布成功”。
任务很多、隔了很久、忘记做到哪：用“恢复四步”
1 锁定项目
先把任务放进正确项目目录。没有项目路径，AI 可能会在错误仓库里找。
2 找权威入口
读 AGENTS.md、docs/agents/issue-tracker.md、domain.md 和 CONTEXT-MAP.md。
3 用证据还原
查开放票据、父规格、Git 状态/近期提交、相关测试；不要只靠旧对话摘要。
4 输出恢复报告
让 AI 分成：已完成、进行中、被阻塞、下一张可做票、找不到的内容。
AI 能不能自己找到？
能找到的前提：它进入了正确项目目录，入口文档存在，票据系统可访问，而且结论已经写入仓库、Issue 或 Git。
找不到的情况：信息只存在旧对话、临时 handoff 已被清理、远程 Issue 无权限、文件命名混乱或你换了项目却没告诉它。此时不能让 AI 猜；让它列出已搜索位置和缺口，你再提供票据链接/关键词，或重新确认那条业务决定。
隔了一个月回来，可直接复制这段
我隔了一段时间，已经忘记这个项目做到哪里。先不要写代码，也不要根据旧对话猜测。
请从当前项目根目录开始：
1. 读取 AGENTS.md、docs/agents/issue-tracker.md、docs/agents/domain.md；如果存在 CONTEXT-MAP.md，再按它找到相关 CONTEXT.md 和 ADR。
2. 找出当前大目标的决策地图、父规格、所有未完成票据及 blocked by 依赖。
3. 检查 Git 状态、最近相关提交和测试结果，用真实文件与代码核对票据状态。
4. 输出“项目恢复报告”：已完成、进行中、被阻塞、下一张可执行票、需要我确认的业务问题、你搜索过但没找到的内容。
5. 告诉我每项证据的实际路径或链接。得到我确认前不要开始 implement。
Agent 对话实操
在 Agent 里到底怎么一步一步使用？
把“项目文件”当长期记忆，把“当前对话”当临时工作台，把 handoff 当未完成工作换班时的交接单。三者不是一回事。
一个目标
一条上下文主线
一条上下文主线
同一任务中：连续完成彼此依赖、需要共享刚才讨论内容的步骤；长时间相关工作优先继续在这里。
新任务中：处理可独立并行的工作，或领取已经自包含、写入范围不重叠的票据。
本地 handoff 技能：只在内容必须跨工具、跨目录、交给同事，或中途分叉到另一执行环境时生成可携带 Markdown。
先分清 4 个动作：它们不是同一件事
| 动作 | 发生了什么 | 什么时候用 | 之后回哪里 |
|---|---|---|---|
| 调用 Skill | 当前 Agent 读取一套工作说明并执行。 | 当前阶段需要一套可复用流程。 | 回到当前任务继续；无需人工“移交给下一个技能”。 |
| 调用下一个 Skill | 同一个 Agent 在满足前一阶段结束条件后切换流程。 | 例如需求已确认后，从 grill-with-docs 进入 to-spec。 | 通常仍在当前任务；你可以一次说明顺序和每阶段停止条件。 |
| 委派子智能体 | 主 Agent 把独立、边界清楚的工作放进另一个上下文并汇总结果。 | 适合研究、探索、测试、分流、双轴审查；写同一文件时要谨慎。 | 结果回主任务，由主 Agent 综合；不是把主任务永久交出去。 |
| 新任务 / 环境移交 | 建立独立任务，或把 Codex 任务在本地检出与工作树之间移动。 | 任务可独立并行、需要干净上下文，或需要换运行环境。 | 在新任务或新环境继续；这和本地 handoff Skill 的 Markdown 交接单不同。 |
多票大功能的隔离走法：设计阶段 → 实现 T1 → 实现 T2
需求做到“可交接”
同一对话连续：grill-with-docs
↓to-spec
↓to-tickets
原因：to-spec 要综合刚才聊清楚的内容。to-tickets 可以继续使用同一上下文。
通常不用
handoff规格和票据已经持久化
handoff规格和票据已经持久化
只领取第一张票
按规模选择：可在当前任务继续，也可用干净任务引用 T1、父规格和相关上下文，再调用 implement。
implement 内部走 TDD、检查和 code-review。结束时提交证据并关闭/更新 T1。
先看依赖相关就继续；独立才新开
读取持久产物继续
引用 T2，先读 AGENTS、CONTEXT、ADR、父规格和 T1 的已落地代码。
继续 implement → code-review；是否新开任务取决于并行、上下文与写入冲突。
哪些技能适合放在同一个对话？
| 步骤 | 建议 | 为什么 | 结束条件 |
|---|---|---|---|
| setup | 可单独一个对话 | 它是仓库一次性建制，不依赖某个功能的详细讨论。 | docs/agents 和根规则已经写入。 |
| grill-with-docs → to-spec | 尽量同一对话 | to-spec 的职责是综合“刚才已经讨论”的内容，而不是重新采访。 | 规格已保存到票据系统，并得到你的确认。 |
| to-spec → to-tickets | 小中型功能可继续 | 上下文仍清晰时直接切票最自然。 | 票据粒度和依赖已确认并发布。 |
| to-tickets → implement T1 | 按规模决定 | 小功能可在当前任务继续；多票构建可按技能包原设计，让每张自包含票据使用干净上下文。 | T1 的范围、依赖、测试接缝和验收条件已明确。 |
| implement T1 → T2 | 相关就继续，独立才新开 | 若 T2 强依赖刚完成的实现判断，留在当前任务；若票据自包含且需要并行或隔离上下文，再开新任务。 | 上一票已提交并留下可核验的持久证据。 |
| wayfinder | 建图一个对话；每张决策票一个对话 | 大型目标故意不在一次对话里解决。地图负责跨会话衔接。 | 本次只关闭一张决策票，并更新地图。 |
| 未完成的半张票 | 视情况 handoff | 如果必须换对话，而中间状态尚未进入规格、票据、提交或测试记录，就需要交接单。 | 新对话已能从明确检查点继续。 |
要不要 handoff？用红绿灯判断
绿灯：继续当前任务
下一阶段仍需要刚才的完整讨论；工作相关且写入同一批文件；当前上下文仍足够清楚。
做法：直接说“接下来使用 to-spec/implement”，并写清输入与停止条件。
黄灯：才考虑 handoff
需要跨 Codex/其他工具、跨目录或仓库、交给同事，或中途分叉一个需要可携带上下文的任务。
做法：先把稳定事实写进项目，再用 handoff 引用它们，只保存剩余现场。
红灯：不要把“太长”当唯一理由
同一工具、同一目录、相关工作只是上下文较长时，优先在阶段边界继续，或使用产品提供的压缩/目标机制。
做法：只有确实需要“可携带文件”时才 handoff；混乱现场先整理证据。
关键区别：
handoff 文件保存在系统临时目录，适合“换班”，不是项目的长期事实来源。长期事实仍必须进入仓库里的 CONTEXT、ADR、规格、票据、提交和测试记录。已经在这些地方保存的内容，handoff 只引用，不重复粘贴。handoff 之后，下一任务第一句话怎么说？
你 · 旧对话
请使用 handoff。下一任务要继续实现“候补自动补位”票据。请引用已有规格、票据和提交，只记录尚未完成的状态、当前测试结果、下一步与建议技能。
Agent · 旧对话
生成交接单，并告诉你文件路径。交接单不复制已有规格，只说明例如：“失败测试已写；补位事务尚未实现；工作区有两处未提交修改。”
你 · 新对话
请读取交接单
[粘贴 handoff 路径]，以及票据 [票据路径/链接]。再读取 AGENTS.md、对应 CONTEXT/ADR 和父规格。确认当前代码与交接单一致后，使用 implement 从未完成检查点继续。不要重做已完成步骤；完成后运行 code-review，并分别报告代码、测试、文档影响和未验证项。Agent · 新对话
先核对交接单与真实工作区。如果不一致，以代码、Git 状态、测试和项目文档等当前证据为准，并向你说明差异，再继续。
一张票做完以后，固定执行这 5 步
1 验证相关测试、类型检查和必要的全量测试通过。
2 审查code-review 的 Standards 与 Spec 两轴问题处理完。
3 同步文档回答 CONTEXT、ADR、Spec、Runbook 是否需要更新。
4 固化状态提交代码，更新或关闭票据，记录真实证据。
5 决定下一步取下一张未阻塞票；相关就继续，需并行或隔离时新开任务。
在 Codex 里怎样“调用技能”？
最稳妥：在提示词里直接点名
例如：“请使用 grill-with-docs，先不要写代码。”或“请使用 implement，只实现票据 T2。”
部分界面可能提供斜杠命令或技能选择器，但自然语言点名更容易连同范围、输入和完成条件一起说清楚。
不要只发一个技能名
最好同时给出：对象（哪个项目/票据）、目标、范围、参考材料和停止条件。
Codex 的项目级 AGENTS.md 会提供跨任务持续规则，而技能负责可重复流程；两者是互补关系。
下面三段按需展开；一次只复制与你当前场景对应的一段。
A｜功能设计对话
这是一个功能设计对话。请使用 grill-with-docs，先不要写正式代码。先读取项目的 AGENTS.md、docs/agents/issue-tracker.md 与 docs/agents/domain.md；再按导航读取 CONTEXT-MAP.md、相关 CONTEXT.md 与 ADR。请先回报你实际找到的路径，再把需求决策树走完；术语或重要决策确定时立即更新正确文档。
当我确认需求已经清楚后，在同一对话使用 to-spec 形成规格并让我确认测试接缝；随后使用 to-tickets 拆成每张可在新会话独立完成的垂直切片。票据发布完成后停止，不要在这个对话继续实现。
B｜新会话实现一张票
这是一个全新的实现对话。请使用 implement，只实现票据：[粘贴票据路径或链接]。
先读取 AGENTS.md、docs/agents/issue-tracker.md、docs/agents/domain.md，再按导航读取父规格、CONTEXT-MAP.md、所属上下文的 CONTEXT.md 与 ADR，并检查所有 blocked by 依赖已经完成。请先列出本票使用的实际文档路径，复述范围和验收条件后再开始；不要实现下一票。
完成时运行 TDD/测试/类型检查和 code-review。分别报告：代码与测试证据、票据状态、CONTEXT/ADR/Spec/Runbook 是否需要更新及原因、需要我阅读确认的文档、仍未验证的风险。提交并更新票据状态后停止。
C｜未完成工作需要换对话
当前任务尚未完成，但我必须切换到新对话。请使用 handoff，目标是让新 Agent 继续当前票据。
先把已经稳定的术语、决策和规格分别写回项目正式文档；handoff 只记录尚未完成的中间状态。必须包含：当前目标、票据与父规格引用、已完成证据、未提交改动、最近一次测试结果、阻塞问题、下一条具体命令/动作、建议调用的技能，并删除密钥和个人信息。最后给我交接单路径。
Codex 里的推荐组织方式：同一个长期项目放在同一项目目录/项目空间里；相关工作优先留在同一任务，以保留上下文。只有票据真正自包含、需要并行或需要隔离写入范围时才开新任务。项目规则通过 AGENTS.md 持续生效，每个任务仍应引用具体规格和票据。参见 OpenAI 官方的 长时间运行的工作、子智能体与Build skills。
贯穿案例
贯穿案例：做一个“社区 AI 课程预约系统”
同一个项目走完整条主干。重点不是看代码，而是观察每一步如何减少下一步犯错的空间。
项目起点
你告诉 AI：“帮我做一个社区 AI 课程预约网页，居民能报名，管理员能看名单。”这句话能做演示，但离生产需求还很远：谁能报名、能否重复报名、满员怎么办、个人信息保存多久，全都没有定义。
本案例约束：每期 30 人；手机号验证码登录；满员进入候补；开课前 24 小时可取消；管理员只能看自己负责的课程；名单导出必须留审计记录。
真实用户居民、授课老师、运营管理员
核心风险重复占位、越权看名单、手机号泄露
成功证据报名、候补、取消、补位均可测试
生产差距短信、隐私、监控、回滚仍需补齐
setup
你说：“在这个项目启用技能流程，票据先用本地 Markdown。”
得到：docs/agents/，以后 AI 知道票据放哪。
grill-with-docs
AI 追问：“30 个名额是按课程还是按场次？候补如何补位？”
得到：CONTEXT.md 定义“场次/名额/候补”；ADR 记录取消规则。
prototype
不确定：候补用户在页面上该看到第几位，还是只显示“已候补”？
得到：两个可点版本；用户测试后选择显示排位与预计机会。
to-spec
规格行为：第 31 人进入候补；有人取消后，第一候补自动转正并收到通知。
得到：明确范围、异常情况、API 接缝和验收条件。
to-tickets
切票：T1 报名；T2 候补；T3 取消补位；T4 管理名单；T5 审计导出。
得到：每张票都能单独演示，并写清依赖。
implement + tdd
先红：测试证明第 31 人当前错误地报名成功；再写最少代码让其进入候补。
得到：实现、回归测试、类型检查和全量测试证据。
code-review
Spec 轴发现：实现了候补，却漏掉“转正通知”；Standards 轴发现权限判断散落三处。
得到：补齐遗漏并收敛权限接口；仍不能直接宣称已上线。
Vibe Coding 式验收
“页面能打开，报名按钮能点，AI 说测试通过，所以发布吧。”
隐藏风险：第 31 人可能超卖；普通老师可能看到别人的名单；短信失败无人知道；数据库变更无法回滚。
生产式验收
“规格中的正常、边缘和权限行为都有证据；安全、部署、监控、回滚分别检查；人工在预发布环境走完居民与管理员流程。”
结论边界：只有线上健康检查和关键指标正常后，才能说发布成功。
异常恢复
结果不符合预期：回到最近一个有证据的检查点
不要重新跑完整流程掩盖问题。先保留现场并说明失败位置，再执行最窄的恢复动作。
| 异常 | 立即动作 | 恢复后才可继续的条件 |
|---|---|---|
| 技能不可见、入口或项目位置不明 | 停止写入；核对技能列表、项目根、AGENTS/CLAUDE 和 docs/agents。 | 目标技能、真实项目和权威入口都已确认。 |
| 文档、代码、票据和用户说法冲突 | 并列给出冲突证据，不替用户做业务选择。 | 用户确认当前规则，并同步文档或建立变更规格。 |
| 权限、网络、CLI 或外部系统失败 | 保留本地草稿和失败输出；不声称已发布、评论、更新或关闭。 | 权限恢复后重新读取真实远程状态，或用户确认改用本地流程。 |
| 测试、类型检查或反馈回路失败 | 保持任务进行中，记录原始命令、环境和失败输出。 | 原始失败信号消失，回归测试与必要全量检查通过。 |
| 结果超范围或方向不符合预期 | 对照规格和 diff，停止未授权方向，回到澄清或规格阶段。 | 范围、Out of Scope、验收行为和写入权限重新一致。 |
| 产物没有路径、链接或证据 | 视为未交付，要求回报绝对路径或真实 Issue/Git 位置。 | 使用者能打开结果，并验证它与配置和当前状态一致。 |
生产差距
重要：代码写完，不等于可以上线
原技能体系擅长需求、实现、测试与审查，但“正式生产”还需要部署、安全、监控和回滚。下面红色关卡需要项目自己的证据。真实环境验收必须单独完成。
1 需求边界谁用、解决什么、不做什么。由 grill-with-docs / to-spec 覆盖。
2 小步实现切票、TDD、类型检查、全量测试。由 implement 覆盖。
3 代码审查是否符合规范、是否符合规格。由 code-review 覆盖。
4 安全检查权限、密钥、依赖漏洞、输入校验、隐私。需要项目另配清单或技能。
5 发布流程预发布环境、数据库迁移、自动部署、审批。需要项目自己的 Runbook。
6 线上观察日志、指标、告警、错误追踪。没有它就不知道用户是否正在受影响。
7 回滚与复盘出事如何恢复旧版本，事后如何防止再犯。上线前必须演练。
这 25 个技能直接覆盖生产项目需要额外补齐
你的生产验收口令：“不要只告诉我测试通过。请分别给出：安全风险、发布步骤、线上验证、失败回滚方案；没有证据的项目标为未验证。”