用途
Tweet Draft Reviewer 是一个用于 Claude Code 的技能，用于审查推文草稿。它会对草稿按 8 条语气规则进行评分（1-10 分），逐条给出通过或失败及原因，并在得分低于 7 分时提供改写建议。其目标是帮助用户避免发布听起来像聊天机器人写的内容。
主要能力
- 对单条推文草稿进行评分（满分 10 分）
- 逐条分析 8 条语气规则，每条给出 ✅ PASS 或 ❌ FAIL 及一行原因
- 当得分低于 7 分时，提供修复所有失败规则的改写版本
- 支持批量扫描文件夹中的推文草稿，并输出每个文件的审查块和批量摘要
- 基于 8 条从真实内容分析中提炼的语气规则，区分高互动推文与容易被略过的推文
8 条语气规则
- No "I" opener：首词不能是独立的 "I"（不是 "In"、"It"、"If"）。
- Strong opener：第一句不能以问号结尾，也不能以 "Have you"、"Do you"、"Are you"、"What if"、"What would" 开头；应为陈述句、具体数字/事实、命名场景或情绪铺垫。
- No AI tells：不能包含 delve、certainly、game-changing、game changer、it's worth noting、invaluable、unleash、revolutionize、transformative 等词。
- No generic closers：结尾（或接近结尾处）不能是 what do you think、drop a comment、thoughts?、let me know in the comments、agree?、sound familiar?；应以陈述、指令、点睛句或线程钩子结尾。
- Corey Test（具体性）：不能使用模糊语言而无具体内容，如 "it changed how I work"、"massive results"、"so much better"；应至少包含一个具体项：数字、时间范围、命名工具或具体结果。
- Character count：280 字符以内为 PASS；超过 280 字符但分段编号（1/、2/、3/）或明显用换行分隔的线程视为 PASS；超过 280 字符且无线程格式为 FAIL。
- Single point：不能有 3 个以上不相关的独立主张且无清晰主线；应有一个核心观点，即使有 2-3 个细节支撑。
- Punchy rhythm：不能有任何超过 20 词的句子，也不能有 "I've been thinking a lot about..."、"Something I've noticed recently is..." 之类的铺垫；应句子简短、无铺垫，最迟第二行切入正题。
使用方式
单条草稿：
Review this tweet draft: [paste tweet here]
批量扫描：
Review all tweet drafts in my content/tweet-drafts/ folder.
技能执行分为四个阶段：
- PHASE 1: INTAKE：确定输入模式。模式 A 为直接粘贴草稿文本；模式 B 为文件夹扫描，运行以下命令查找未审查的草稿：
VAULT="${VAULT_PATH:-$(pwd)}"
find "$VAULT/content/tweet-drafts" -name "*.md" 2>/dev/null | while read f; do
if ! grep -q 'reviewed: true' "$f" 2>/dev/null; then
echo "UNREVIEWED:$f"
fi
done
如果未提供 vault 路径且当前目录下没有 content/tweet-drafts/，则询问：
Where is your tweet drafts folder? (full path, e.g. /root/obsidian-vault/content/tweet-drafts)
模式 C 为模糊情况，无草稿也无文件夹上下文，则询问：
Paste your tweet draft here, or tell me the path to your tweet-drafts folder and I'll scan it.
-
PHASE 2: ANALYZE：对草稿应用全部 8 条规则，记录每条规则的 ✅ PASS 或 ❌ FAIL 及一行原因。
-
PHASE 3: OUTPUT：按固定格式输出审查结果，包括得分、逐条规则分析。评分表如下：
| 通过数 | 得分 |
|---|---|
| 8 | 10/10 |
| 7 | 9/10 |
| 6 | 8/10 |
| 5 | 6/10 |
| 4 | 5/10 |
| 3 | 4/10 |
| 2 | 3/10 |
| 1 | 1/10 |
| 0 | 0/10 |
如果得分 ≥ 7：提示可发布，使用 Typefully 或调度器排队。
如果得分 < 7：添加改写建议，提供修复所有失败规则的改写推文。
- PHASE 4: SELF-CRITIQUE：交付前检查：所有 8 条规则均已评估（输出中必须有恰好 8 行规则）；得分与通过数匹配；改写质量（改写本身应通过原稿失败的规则，若改写自身低于 7 分则再次改写）；原因质量（每条规则结果必须有具体原因，不能泛泛而谈）。
批量模式输出
扫描文件夹时，每个文件输出一个审查块：
📄 content/tweet-drafts/linkedin-ai-post.md
[full review block]
📄 content/tweet-drafts/founder-ops.md
[full review block]
────────────
BATCH SUMMARY
Reviewed: 4 drafts
Ready to post (≥7): 2
Need rewrite (<7): 2
示例
输入：
I've been thinking a lot about how AI is really changing the way founders
approach content creation and productivity, and I think it's worth noting
that the teams who figure out async AI workflows are going to have a
massive advantage. What do you think about this?
输出：
TWEET REVIEW
────────────
Score: 2/10
Rule-by-Rule:
1. ❌ No "I" opener — Starts with "I've"
2. ❌ Strong opener — Slow setup, no hook, no specific fact
3. ❌ No AI tells — Contains "it's worth noting"
4. ❌ No generic closers — Ends with "What do you think about this?"
5. ❌ Corey Test — "massive advantage" is vague, no numbers or concrete outcome
6. ✅ Character count — 248 chars
7. ✅ Single point — Focused on async AI workflows
8. ❌ Punchy rhythm — Run-on sentence, preamble opener
────────────
Suggested Rewrite:
The founders winning right now aren't working harder.
They have agents running at 2am. Content drafted. Research done.
Queue processed.
By 7am they're reviewing output, not creating it.
Async AI ops is the new early morning routine.
适用场景
- 在发布前快速审查单条推文草稿
- 批量扫描推文草稿文件夹，找出未审查的草稿
- 需要按统一语气规则评估推文质量并获取改写建议
限制与要求
- 需要 Claude Code 并具备 bash 工具访问权限（用于文件夹扫描模式）
- 无外部 API，审查完全依赖 LLM 推理
- 推文草稿文件夹位于 content/tweet-drafts/（可选，直接粘贴始终可用）
- 草稿文件夹中的文件会被标记 reviewed: true，以便在后续扫描中跳过
- 关于收费、价格、平台支持等更多信息暂未提供