目标：每天安全同步仓库、用对 Skill、完成验证，并通过 PR 把改动交给团队。
适用仓库：Akke规范来源：CLAUDE.md + .claude/skills最后整理：2026-09-11docs/REPO-MAP.md。origin/main 开分支。src/lib/ 先看 scripts/shared-pins.json 并跑 drift 检查。当需要并行开发、同时开多个 AI 会话，或想保持主目录干净时，为任务创建独立 worktree。进入 worktree 后再开始修改；提交、推送和创建 PR 都在同一个 worktree 完成。一个目录只允许一个会话，跨仓库工作必须在对方仓库单独创建 worktree。
确认所有改动都属于当前任务；查看改动清单、格式检查结果、测试结果和当前分支状态。确认没有遗留临时文件、后台进程或未说明的改动，再进入提交 PR。
~/wecom-chat，必须在那个仓库内单独操作，不能在 Akke 目录处理。触发方式：直接说自然语言即可；命中后先打开对应 .claude/skills/<name>/SKILL.md，遵守它的边界。下面的“开始→结束”是新人记忆版，具体命令以 Skill 文件为准。
write-requirement 新需求 → 先给“做什么/场景/完成”三段 → Claude 最多追问 3 个歧义 → 补工程注记、依赖、验收和夜跑闸 → 落到 docs/requirements/。结束：确认高危路径与跨仓标记。
loop-goal-spec 需要持续执行 → 先读机制/选型/模板 → 再组装 /loop 或 /goal。结束：明确停止条件、频率、失败升级和是否通知。
find-blockers 一天收工复盘 → 运行确定性探针 → 只输出带证据的卡点归因 → 给出今晚能修的动作。只诊断，不直接改生产。
wrap-up 收尾/交接 → 先扫 worktree 与残留进程 → 检查 memory → 输出交接卡、未完成项、脏状态和下一轮提示词 → 最后一行给会话改名建议。
case-study 做客户案例 → 脚本拉真实数据 → 读 SPEC 与 living example → 生成 9 段 HTML → 加索引 → 视觉检查。结束：确认没有凭记忆编造数据。
init-tuwen 第一次接入 → 环境/设备探测 → 回答 3 个问题 → 标坐标 → dry-run → 验通路。结束：确认可以运行“周发”。
douyin-tuwen 单次图文 → 收集参考 → 备忘录风稿 → 渲染 → 两道闸自查 → 用户审 → 手机发布/定时。结束：保存素材与发布结果。
weekly-tuwen 周发 → 抽 4 题出稿 → 计算 1 个立即 + 3 个定时 → 串行发布 → 核对 4 条结果。结束：拔手机前确认队列/日志。
send-cloudpc-tuwen 云电脑图文 → 本机只 enqueue 一行 → 云电脑 agent 自动拉单 → creator.douyin.com GUI 发布 → 查日志。结束：确认手机退出，记录失败项。
prep-dm-leads 拉 leads → claim → opener 备料 → iPhone WDA 串发 → 每条 mark/discard → 释放残留。结束：不能漏 mark。
send-wda-dm 已有 opener 的 WDA 发送 → 预检/拉起 WDA → 用户确认 → 串发 → 自动 mark-contacted → discard 拒收项 → 停 WDA。
send-cloudpc-dm 云电脑 DM → 本机 claim/备料 → GUI 投递 → mark/释放 → 查 agent 日志。与 WDA 二选一。
send-cloudpc-second-touch 二次触达 → 只选已 DM、≥1 天未回的中高意向 → 点赞+评论1+评论2 → 写回状态。不要和 RC 同跑。
send-cloudpc-rc 反向评论 → 检查 DM-cap → 入队 → 云电脑执行 → 核对结果。与二触共享窗口。
cloudpc-selfdrive-ops 自动发状态 → 从 DB 反推派单/发送/额度 → 只查看与指导，不发消息。
cloudpc-dom-dm-restart DOM 自动化重启 → 给云电脑粘贴 Edge/CDP 命令 → 验登录和红点 → 验日志。Claude 不代替用户操作云电脑。
cloudpc-dm-routeb-serial 小文 DM+route-B → 启动窗口锁 → DM 优先串行 → 分别看两套日志/状态。只启动、验活、运维。
source-mining-daily 扩源 → 选词捞作者 → 富化打分 → 置信度分流 → 入库 → 回写 → Lark 汇总。结束：边缘号等点头，不冲数量。
portal-material-ingest 资料入库 → 查未入库 → 逐份看内容 → 去重分类 → 图传 R2+向量 → 回填台账 → 验召回 → 报告。
personal-daily-report 个人日报 → 拉单账号 KPI/时效/7 天走势 → 生成 HTML → 本地预览 → 可选公开发布并写 Lark 索引。
update-scrape-report 抓取时效报告 → 生成器查数据 → 补根因/方案/下一步 → 发布公开页 → 推本人 Lark。
handle-lark-requests 处理 Lark 请求 → 拉取私聊 → 按授权执行 → 以本人身份回复。涉及合 PR 时仍按本页 PR 红线。
push-conversation-summary 推对话总结 → 整理成 Lark 交互卡片 → 发 Akke Bot 群。不要把“推代码”误触发为这个 Skill。
提交前只选择本任务文件；如果发现混入无关文件，先移出再提交。
涉及模型、定时任务、数据库迁移、权限或工作流时：必须经过 PR、检查和人工评审；不要期待自动合并。
普通文档或低风险脚本也必须走 PR。符合自动管理条件的低风险 PR 可能自动合并；需要暂停时，在 PR 页面加“暂停自动合并”标记。
交接： - 完成： - PR： - 验证： - 未完成/风险： - 当前分支与脏状态： - 下一步：
自动管理流程只处理非草稿、没有待修改意见、检查通过、可以安全合并且不命中高危路径的低风险 PR。需要暂停时，在 PR 页面加上“暂停自动合并”标记。
PR 合并到主线后，才会按改动范围触发网页、worker 或数据库部署。部署完成后还要打开真实页面或接口验证，并记录部署编号；“PR 已合并”不能代替“部署已验证”。
好提示词要给：目标、范围、上下文、约束、验收。先让 AI 读状态和规则，再让它改；问题没定位前不要直接要求“重构一遍”。
目标：在<文件/模块>实现<行为>。
上下文：用户场景是<...>，相关入口是<...>。
约束：遵守 CLAUDE.md；只改<范围>；不要改<范围外>。
先做：读取相关文件、检查当前改动、列出方案。
验收：完成<验证动作>，看到<明确结果>。
现象：<完整错误>。
复现：<命令/操作>。
预期：<应该发生什么>。
已尝试：<命令>，结果是<...>。
请先判断根因并给证据，再提出最小修复；不要顺手改无关文件。
修复后请运行<测试/检查>并报告结果。
请审查当前 diff：
1. 是否越过仓库边界或高危路径规则？
2. 是否有数据丢失、重复发送、密钥泄露风险？
3. 是否缺测试、迁移回滚或错误处理？
4. 给出按 P0/P1/P2 排序的问题。
先只审查，不要直接修改。
这套方法综合了 OpenAI、Anthropic 和 GitHub 官方对编码 Agent 的建议，核心不是“把话说得很玄”，而是让 Agent 知道要改什么、不能改什么、怎样算完成。
先探索：让 Agent 先阅读项目规则、相关文件和现有实现，不要马上写代码。
再计划：让它用几句话说明准备改哪些文件、为什么这样改、有哪些风险。
小步实现：一次只完成一个明确目标，完成一块就验证一块。
最后评审：让 Agent 复查改动范围、边界情况、测试和安全风险。
目标：要解决什么问题。
范围：允许改哪些页面、接口或文件。
约束：哪些行为不能改变，哪些规则必须遵守。
验收：用户最终看到什么，必须通过哪些检查。
如果需求存在多个合理解释，让 Agent 先列出不确定点并最多提出几个关键问题。没有确认前，不要让它扩大范围或顺手重构。
请先阅读项目规则和相关文件，不要修改任何内容。
先告诉我：你理解的问题是什么、准备改哪些地方、有哪些风险、怎样验证。
等我确认方案后再开始修改。完成后请说明改了什么、验证了什么、还有什么未验证。
直接说“先暂停，当前改动超出范围”；指出哪一条目标或约束被违反；要求 Agent 回到上一个稳定状态，重新给最小方案。不要用更多长篇解释掩盖方向错误。
不要接受“应该没问题”。要求 Agent 给出实际检查结果：页面是否能打开、测试是否通过、改动是否只在目标文件、错误场景是否覆盖。验证失败就让它先解释原因，再决定是否继续。
能拆成独立目标的任务，就按“调查、实现、测试、审查”分阶段；需要多人或多个 Agent 并行时，每个任务使用独立 worktree，最后由一个人整合和复查。
参考：OpenAI：How OpenAI uses Codex · Anthropic：Claude Code Best Practices · GitHub：Coding Agent Best Practices · Anthropic：Skills、Rules、Hooks、Subagents 的分工
❌ 不直推 main；所有改动走 PR。
❌ 不在错误仓库实现企微/门店工作台需求。
❌ 不把 service-role key 放进前端，不接受客户端传入 org_id。
❌ 不跳过 claim/mark 配对就触达客户。
❌ 不在测试/评测中误用生产 LLM key；评测使用隔离 key。
❌ 不为“看起来更快”跳过测试、diff 检查或验活。