القائمة
技术文章对外写作：从内部实践到读者能代入的叙事。 Use when: 写技术博客、公众号文章、社区分享、对外 longform、技术文章 review、写推广语。 Not for: 内部文档/spec（直接写）、PPT（用 ppt-forge）。 Output: 有呼吸感的技术文章 + 读者反馈聚类分析。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
约定图发现方法论：进一个 repo 先识别 repo-specific conventions，再定义 domain/extractor 接 Convention Graph 引擎。Use when: 进入陌生 repo、要画约定图、要找“改 X 影响谁”的约定层关联、 F242/Convention Graph Layer 工作。Not for: 普通符号跳转/LSP、文档索引检索、记忆图谱、直接使用 codegraph/GitNexus。Output: domain 定义 + extractor 计划 + gap/freshness/provenance 报告。 GOTCHA: 沉淀的是“怎么画图”的方法，不是把 cat-cafe 的 extractor 硬搬到所有 repo。
跨 thread 协同：发现平行 session → 通知（3+2 件套）→ 争用协调 → 确认。 Use when: 平行 session 之间需要协同、收到跨线程消息、通知改动影响、共享文件争用。 Not for: 跨猫工作交接（用 cross-cat-handoff）、需要新建 thread 时（用 propose_thread / thread-orchestration）。 GOTCHA: 收到跨线程 ACTION 不等于接活；先做 thread/feat ownership gate，不属于当前 thread 就 cross-post 退回。 Boundary with F128: 发现跨 scope 问题 → 先 list_threads 查有没有已有 thread → 有 = 本 skill（cross_post）→ 没有 = propose_thread。 Output: cross-post 通知 + 争用协调完成。
Feature 立项、讨论、完成的全生命周期管理。 Use when: 开个新功能、new feature、F0xx、立项、feature 完成、验收通过、讨论新功能需求。 Not for: 代码实现、review、merge（那些有专门的 skill）。 Output: Feature 聚合文件 + BACKLOG 索引 + 真相源同步。
明星开源项目拆解：从宣传/PPT/README 进入源码，验证真实架构、明星特性、算法含量、营销水分、可学习点和不 follow 的 tradeoff。 Use when: operator要求拆解热门 GitHub 项目、竞品 agent/runtime、外部 skill/tool 框架，或问“它到底有什么真本事/我们能学什么”。 Not for: 普通资料搜索（用 deep-research）、社区 issue/PR 运营（用 opensource-ops）、只需要架构头脑风暴（用 collaborative-thinking）。 Output: feature-discussions/YYYY-MM-DD-{project}-deep-dive/ 下的代码证据报告 + 对比结论 + 候选 lesson/skill。 GOTCHA: 不许只看 README 下判断；每个明星特性必须追到代码路径、状态突变点、反馈闭环和算法输入输出。
开发完成后的自检门禁：愿景对照 + spec 合规 + 验证。 Use when: 开发完了准备提 review、声称完成了、准备交付。 Not for: 收到 review 反馈（用 receive-review）、merge（用 merge-gate）。 Output: Spec 合规报告（含愿景覆盖度）。
接球前真相核验三问：claim → resolver → verdict (sourceTier T0/T1/T2 + actionFamily)， 防止把传球者当无审视真相源（F167 Phase O 第一性原理）。 Use when: 即将调 hold_ball / register_pr_tracking / register_issue_tracking / merge / takeover / 改 owner / 任何 irreversible action / 基于 "operator signoff" 或 "你是 owner" 类 claim 行动之前。 Not for: 纯阅读 cross_post（无 actionFamily 后续）；本 thread 日常 @mention 无副作用； implementation continuation（自检通过的下一步）。 Output: claim grounding verdict (verified/mismatch/insufficient) + 接球决策 (proceed / block / push back to source thread)。
| name | tech-writing |
| description | 技术文章对外写作：从内部实践到读者能代入的叙事。 Use when: 写技术博客、公众号文章、社区分享、对外 longform、技术文章 review、写推广语。 Not for: 内部文档/spec（直接写）、PPT（用 ppt-forge）。 Output: 有呼吸感的技术文章 + 读者反馈聚类分析。 |
| triggers | ["写文章","技术分享","博客","longform","公众号","对外发布","社区分享","推广语"] |
不要学 AI 的平滑，要学人的“颗粒度”：
cat-cafe-tutorials/docs/lessons/12-no-boss-agent.md：看它如何用“读者的怀疑”当小标题，把争议变成共鸣。cat-cafe-tutorials/docs/lessons/01-sdk-to-cli.md：看它如何还原“当时炸了”的瞬间，让读者跟着猫一起出冷汗。AI 写作像是在发送一个逻辑自洽的压缩包。读者没有经历过那 100 天，收到的是一个打不开的结论。
好的写作是“解压过程”：给证据锚点，不给干巴巴的结论。
不要介绍一个系统的终态。要讲它怎么长出来的。
每篇文章沿着一条链：方案 → 方案撞墙 → 新方案。系列文章之间，上一篇撞的墙就是下一篇的起点。
以记忆系统为例：
读者跟着的不是一张完美的架构图，而是一条连续剧。进化天然有挣扎，设计天然平滑——所以进化链天然没有 AI 味。
与 Phase 0 的关系：进化链管选题和系列连接；Phase 0 管单篇内部的节奏。
写文章前，先在心里画出这条弧线：
开篇锁预期：弧线画完后，在文章前 3 段内给出核心观点的一句话摘要。读者有了锚点才不会歪楼——场景钩子拉进来，核心命题马上锁住方向。
铁律：先场景，后概念。 故事是藤蔓，概念是果实。没有藤蔓，果实就是悬空的。
以下手法从范本提炼——不是”不要做什么”，是怎么做：
给质感（让读者相信真的发生过）：
造紧张（让读者想继续读）：
交付结论（让读者拿得走）：
内部黑话是叙事的毒药。翻译句 = 读者能看懂的类比。
不要只用 grep 数排比，要用耳朵听节奏。
refs/ai-taste-checklist.md。门禁：写摘要前必须重新“解压”全文。 禁止直接罗列标题。
| 反馈 | 视觉把关猫的翻译 |
|---|---|
| “读不懂” | 文章的 UI 坏了，得修修类比和结构。 |
| “AI味重” | 故事写得太顺了，没把踩坑时的狼狈写出来。重写第二章。 |
| “这就是一堆 Prompt” | 我们没把“为什么这堆 Prompt 能跑通”的证据链展示清楚。 |
写完一章 → 听听有没有“呼吸感” → 过 Phase 3 门禁 → 给operator审“钩子” → 发布