메뉴
Use when the user wants to write a blog post (技术博客或思考随笔) for their personal blog. Triggers on: 写博客、写篇文章、blog post、写一篇关于XX的文章、继续写博客系列. Not for 公众号长文 (→ khazix-writer), not for 深度研究报告 (→ hv-analysis), not for 短内容 (小红书/推特/朋友圈).
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when starting an existing-code bug audit on a repository or large directory tree. First detects project language + architecture (e.g. C/C++ embedded SOA, Python web service, frontend SPA), proposes a tailored review checklist (scenario-specific bug categories) for user confirmation, then slices the codebase into modules within a per-module token budget. Produces plan.json with profile + review_checklist + modules that downstream audit-reviewer consumes module-by-module. Not for PR diff review (use hf-code-review) or for actually finding bugs (use audit-reviewer).
Use as the FINAL stage of the code-audit pipeline. Reads confirmed.json (output of audit-verifier) and renders a self-contained single-file HTML report (always) and optionally an Excel workbook. The HTML contains summary stats by severity/category/module, filterable finding cards with code snippets and audit trails (reviewer + verifier). Not for emitting findings (use audit-reviewer) or verifying findings (use audit-verifier).
Use when scanning an existing-code module for bugs and emitting finding drafts. Reads source files within one module from the plan.json produced by audit-planner, walks files line-by-line, emits findings/<module>.json with file path, line numbers, category, severity, confidence, code snippet evidence, and reasoning. The set of allowed finding categories is sourced from plan.json's review_checklist (scenario preset such as c-cpp-embedded-soa / python-web-service / frontend-spa / generic) rather than a fixed taxonomy — keep findings scoped to the user-confirmed checklist. This is the PRIMARY (first-stage) reviewer in the two-agent confirmation pipeline; downstream audit-verifier independently confirms each finding. Not for PR diff review (use hf-code-review) or for verifying findings (use audit-verifier).
Use as the SECOND-STAGE independent confirmer in the two-agent code-audit pipeline. Reads finding drafts produced by audit-reviewer and independently re-examines each one against the actual source code, writes verifications/<module>.json with status (confirmed/rejected/upgrade/downgrade/needs_more_evidence), reason, and evidence_check. Operates with FRESH context — does not see reviewer's internal reasoning beyond what is recorded in the finding's description+evidence fields, to enable independent judgement. Not for emitting new findings (use audit-reviewer) or rendering the report (use audit-reporter).
Use when hf-test-driven-dev finishes GREEN on a frontend-touching active task whose spec declares a UI surface, and fresh browser runtime evidence (screenshot / console log / network trace) is required for downstream gates. Not for issuing verdicts (gates do that), not for replacing hf-test-review's test-quality review, not for backend-only tasks.
适用于 test review 通过后评审代码质量、用户要求 code review 的场景。不适用于评审测试（→ hf-test-review）、写/修代码（→ hf-test-driven-dev）、阶段不清（→ hf-workflow-router）。
| name | blog-writing |
| description | Use when the user wants to write a blog post (技术博客或思考随笔) for their personal blog. Triggers on: 写博客、写篇文章、blog post、写一篇关于XX的文章、继续写博客系列. Not for 公众号长文 (→ khazix-writer), not for 深度研究报告 (→ hv-analysis), not for 短内容 (小红书/推特/朋友圈). |
从主题到成稿，按用户个人风格撰写技术博客或思考随笔，输出 Markdown 文件到 Garage 仓库。
适用：
不适用 → reroute：
khazix-writerhv-analysisweb 工具直接搜索与相邻 skill 的区别：
khazix-writer：固定卡兹克文风，公众号格式，无 frontmatterhv-analysis：横纵双轴研究，输出 PDF 报告，万字起步用户的典型输入是灵感驱动、碎片化的——讲了一段经历或见闻，说了想写什么，但未必有完整结构。这一步的核心工作是：把碎片整理成清晰的写作意图。
先接收，再补全：
用户可能给的东西：
需要帮用户理清的问题：
如果用户已经说得足够清楚，不要机械追问，直接进入下一步。如果信息有缺口，补问以下关键项（不要一次全问，挑最缺的问）：
输出：把用户的碎片输入整理成一句清晰的主题陈述，确认后再进入调研。
如果主题需要外部素材：
web 搜索收集引用、数据、案例browser 抓取用户提供的链接内容调研方法（WSL 环境）：
curl "https://html.duckduckgo.com/html/?q=..." class="result__a" 取链接，class="result__snippet" 取摘要，URL 需从 uddg= 参数解码--proxy "http://127.0.0.1:9567"（WSL 镜像模式，Windows 代理）根据内容类型选择文章原型：
| 原型 | 适合 | 结构重心 |
|---|---|---|
| 经验分享型 | 编程心得、踩坑总结 | 个人经历→提炼规律→给建议 |
| 方法论型 | 实践方法、工作流 | 理论→案例→可执行步骤 |
| 观点论述型 | 行业观察、技术判断 | 现象→分析→立场 |
| 系列续写型 | 延续已有系列 | 承接前文→新维度→预告后文 |
确定章节结构（3-5 个大章节，带编号子节），输出大纲给用户确认后再写。
严格遵循用户的写作风格（见下方 Style Guide）。
关键要求：
对初稿执行三级检查并修改：
L1 硬性规则：
L2 风格一致性：
sed 脚本批量去加粗比 patch 逐个操作更可靠加粗精简的技术陷阱：
read_file 有缓存机制——如果文件被 write_file 写坏后再 git checkout -- 恢复，read_file 可能仍返回缓存的坏内容。解法：用带 offset 参数的调用强制重新读取，或直接用 terminal("grep ...") 操作execute_code + write_file 做批量文本替换风险极高（一次替换错误可能清空所有加粗）。优先用 sed -i 脚本批量处理，出错后 git checkout -- 即可恢复L3 内容质量：
L4 Humanizer-zh 去AI味检查（推荐）：
L1-L3 通过后，用 humanizer-zh skill 对全文做一轮扫描，重点关注：
execute_code 跑正则扫描，按类别统计，报告给用户后批量修改如果通过子代理或外部评审拿到了量化评分报告（如 humanizer-zh 的 5 维度评分），按以下流程修订：
1. 创建优先级 TODO：
2. 批量指标修订用 execute_code，不用逐个 patch：
3. 结构性合并直接用 patch：
4. 每轮修订后统计关键指标：
# 字数
python3 -c "import re; text=open('FILE').read(); cn=len(re.findall(r'[\u4e00-\u9fff]',text)); en=len(re.findall(r'[a-zA-Z]+',text)); print(f'~{cn+en}字')"
# 破折号
grep -o '——' FILE | wc -l
# "不是…而是"
grep -o '不是.*而是' FILE | wc -l
经验教训：
V3→V4 迭代的关键教训（精炼度仍是最大短板时）：
当破折号和结构已优化但精炼度分数仍没提升时，问题出在语义层面的重复而非表面修辞。这类修改更大胆：
V1→V4 全流程迭代经验（第5篇博客实战）：
| 版本 | 分数 | 核心改动 | 教训 |
|---|---|---|---|
| V1 初稿 | — | 5800字 | 初稿不必追求完美，先出骨架 |
| V2 | 37 | 扩展到7600字，丰富案例 | 字数膨胀不等于质量提升 |
| V3 | 36 | 破折号73→29，章节合并 | 表面修辞优化对精炼度帮助有限 |
| V4 定稿 | 35 | 删§5.1整段、删§4.4整段，字数7200→6700 | 整段删除比修修补补更有效，但精炼度仍卡在6 |
| V5 融合 | 33 | 借鉴卡兹克版亮点融合进V4 | 风格融合不解决精炼度，反而引入新问题 |
| V5+对齐 | — | 骑马→摄影器材、成就拆散、术语中文化 | 风格一致性验证是定稿前必做步骤 |
核心结论：
read_file 返回带行号的内容，用 Python open() 直接读才不会匹配失败。文件被写坏后 git checkout -- 恢复，但 read_file 可能返回缓存旧内容---
title: "文章标题"
date: YYYY-MM-DD
tags: [tag1, tag2]
series: "系列名称" # 如果属于系列
series_index: N # 系列中的第几篇
draft: true # 初稿默认 draft
---
将 frontmatter + 正文写入 Garage 仓库的 .garage/blog/ 目录。
文件命名：YYYY-MM-DD-标题slug.md
路径示例：/mnt/e/workspace/Garage/.garage/blog/2026-04-17-ai-coding-workflow.md
如果目录不存在，先创建。
写完后把文件发给用户审阅（飞书发文件）：
~/.hermes/.env 获取 FEISHU_APP_ID 和 FEISHU_APP_SECRETPOST https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internalPOST https://open.feishu.cn/open-apis/im/v1/files（file_type=stream）POST https://open.feishu.cn/open-apis/im/v1/messages?receive_id_type=chat_id（msg_type=file）/mnt/e/workspace/Garage/.garage/blog/ 目录YYYY-MM-DD-标题slug.md当用户想借鉴另一种写作风格（如 khazix-writer）的亮点来改进自己的定稿时，用「风格融合」而非整体重写。
用户喜欢用不同写作 skill 生成同一篇文章的多个版本进行对比。同一主题不同风格的文件用后缀区分（如 -khazix），放在同一目录。
适用场景：
操作步骤：
-v5.md），不覆盖原定稿关键约束：
风格融合的实际教训（V5 实验）：
V5 融合版评分 33/50，比 V4 定稿（35/50）反而低了 2 分。原因：
结论：风格融合解决的是「真实性/信任度」维度，不解决「精炼度」。如果定稿的精炼度已经卡在瓶颈，融合不会提升总分，反而可能引入新问题。
当博客属于已有系列时，初稿完成后应与前文做风格一致性对比。这是 L2 风格检查的补充步骤，特别适合系列续写。
方法： 用子代理抓取前文内容，逐维度对比一致性。
10 个对比维度：
| 维度 | 检查要点 |
|---|---|
| 开头风格 | 是否延续系列惯用开场（自嘲/轶事/他人视角）？ |
| 自嘲谦逊度 | 自嘲是否"同一味道"——不回避失败、带点苦笑？ |
| 成就引用 | 是否"顺带一提"而非"集中检阅"？不要在同一段亮出多个资历 |
| 隐喻类比 | 是否只用自己真正懂的领域做类比？不要用个人经验外的隐喻 |
| 三层递进 | 理论→实践→哲学的结构是否保持？ |
| 格言式总结 | 金句风格是否一致——短句、反转、实用主义底色？ |
| 中英混用 | 英文术语密度是否与前文一致？首次出现中文注释，后续用中文 |
| 章节结构 | 编号+描述性副标题的模式是否一致？ |
| 交叉引用 | "之前聊过的"式回扣是否自然、贯穿全文？ |
| 结尾风格 | 是否延续"一句话留白"而非过度总结？ |
评分判断标准：
最关键的 3 个 AI 痕迹检测点：
发现偏差后的修改原则：
实际验证案例（第5篇 vs 前4篇）：
对齐修改实例（17处替换，从33分偏差回升）：
git checkout -- 回退到上一版，从那个版本重新改，不要在错误基础上继续改当文章涉及介绍自己做的框架、工具或工作流时，不要列功能清单或分层架构。那是 README 干的事，不是博客该写的。
核心原则：讲"在什么方法论指引下设计出来的"和"怎么把经典方法封装进框架"，而不是讲框架本身的约束机制、结构细节。
正确做法：讲方法论的设计故事。
素材来源优先级：
反面模式：
以下风格特征提取自用户"写代码的一点心得"系列，写作时必须贯穿。
重要补充：本节是初稿写作指南，但初稿和用户真正发布稿之间还有一道"人味儿"鸿沟，详见下方「发布前定稿（用户改稿规律）」章节，那里有从第5篇博客「初稿 → 茶思屋发布稿」对比中提炼的 12 条具体改稿清单。生成初稿时就应主动按那套清单写。
() 补充说明或自嘲（"当然，也可能是我太菜了"）AI 初稿和用户最终发布稿之间，永远有一道"人味儿"的鸿沟。下面是从第5篇博客的「初稿 → 茶思屋发布稿」对比中提炼出的用户改稿规律，生成初稿时就应主动按这套规律写，避免等用户大改。
用户改稿做的就一件事：把"AI 写得规整的文章"改回"老程序员茶歇时跟同事吐槽的文章"。具体表现为四种力的叠加：松→更松、稳→更稳、狠→更狠、土→更土。
**核心是**式宣告）1. 加粗几乎全删，只留 2-5 处真正的金句
2. 加"咱们"代替"我们/前文"
3. 网络口语词替代规范词
4. 重复词强化语气（不是病句，是节奏）
5. 省略号 …… 替代部分句号
…… 表达"无奈/欲言又止/苦笑"6. 引用大师后立刻自己加吐槽（括号补刀）
7. 章节编号用 1. 而非 1、
1.1 1.2 风格统一8. 删除全部图片占位与示意图引用（发布平台前）
9. 总结段不要"逐篇 bullet 回顾"
10. 章节末加"生活化锚点"
11. 引言后立刻加 GitHub/资源链接（"太长不想看"）
12. 生活场景细节加得更密
3.x 实操路线段落：每条路线后加"成本吐槽"
5.x 框架介绍段落：避免"框架功能列表"
1.x 现象描述段落：用"暗病/慢性消耗"等病理化词
写完初稿后，按下面 6 个 grep/check 项过滤一遍：
FILE="article.md"
# 1. 加粗数量：超过 5 处就要砍
grep -o '\*\*' "$FILE" | wc -l # 除以 2 = 加粗数量
# 2. 是否引入了"咱们"：至少 5 处
grep -c '咱们' "$FILE"
# 3. 省略号密度：每千字 1-2 处
grep -o '……' "$FILE" | wc -l
# 4. AI 套话残留
grep -nE '综上所述|不难发现|值得注意的是|首先.*其次.*最后|本质上|赋能|抓手|范式' "$FILE"
# 5. 是否还有图片占位（发布版应为 0）
grep -c '!\[' "$FILE"
# 6. 章节编号格式：应是 1. 不是 1、
grep -E '^# [0-9]+、' "$FILE"
任何一项不达标，回头改。
如果你写的某句话，让你想象中的"用户本人"忍不住想加个括号补刀、加个"……"叹气、或者把整个加粗去掉——那这句话就还没改到位。
用户的写作不是"清晰传达观点"，是"老朋友坐你对面，端着茶杯吐槽"。每次想用 AI 式的修辞强化时，问自己：茶歇时会这么说吗？