autocrew 0.1.0 → 0.2.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "autocrew",
-  "version": "0.1.0",
+  "version": "0.2.0",
   "description": "One-person content studio powered by AI — from trending topics to published posts",
   "type": "module",
   "license": "MIT",

package/skills/content-review/SKILL.md

@@ -114,7 +114,53 @@ action: "review_scan"  (如果已实现)
 
 **总分 = 4 项之和（0-100）**
 
-### Step 4.5: 标题公式检查
+### Step 4.5: 七问自检（文案终极检验）
+
+对内容逐一回答以下 7 个问题。每个问题必须给出具体答案，答不上来就是该项不合格。
+
+**Q1: 用户思维** — 这条内容为用户提供了什么？
+- 提供了解决方法？引发了共鸣？提供了谈资？带来了快乐？
+- 还是纯粹自嗨？（例：做餐饮加盟的教人怎么拌饭好吃 = 自嗨）
+- 必须明确回答内容给用户的具体价值
+
+**Q2: 动词名词替换形容词** — 内容里是否滥用形容词？
+- 形容词是作者的主观感受，要让观众自己得出结论
+- 反面："我工作很累" → 正面："从早 7 点干到晚 11 点，一周 7 天没休息，上厕所时间都快没了"
+- 检查所有形容词，能换成具体动词/名词/数据的必须换
+
+**Q3: 可信度支撑** — 用户凭什么相信你说的话？
+- 每个核心论点是否有以下至少一种支撑：权威认证、数据佐证、亲身经历
+- 反面："多动的孩子往往体育天赋惊人"后面没有任何事实佐证 → 直接滑走
+- 没有支撑的断言必须补充或删除
+
+**Q4: 每句话的目的** — 每一句话在文章中的作用是什么？
+- 推进叙事发展？拉近共鸣？制造期待？
+- 如果一句话找不到明确目的 → 删掉或改写
+- 不允许存在无功能的废句
+
+**Q5: 关键印象与人设** — 用户看完后印象最深的一个点是什么？最大感受是什么？
+- 这个印象直接决定你的人设是否跑偏
+- 如果答不上来，说明内容缺乏记忆点
+- 必须能用一句话说出"用户看完会记住___"
+
+**Q6: 金句转发** — 如果观众想转发一句话，会是哪句？
+- 这句话在网上能搜到吗？（搜得到 = 不够原创）
+- 如果整篇没有一句值得转发的话 → 缺少金句，需要补
+- 金句是内容传播的核心驱动力
+
+**Q7: 说人话** — 文案是否自然、不端着、不做作？
+- 是否堆砌成语？是否播音腔？是否书面语过重？
+- 一句话用 3 个成语 = 不合格
+- 标准：读出来像正常人说话，不别扭
+
+**评分规则：**
+- 7/7 全部能回答 → ✅ 文案过关
+- 5-6/7 能回答 → ⚠️ 需要针对性修改（标注具体不合格项）
+- ≤4/7 能回答 → ❌ 文案需要大改
+
+---
+
+### Step 4.6: 标题公式检查（原 4.5）
 
 检查标题是否命中至少一个标题公式：
 
@@ -204,19 +250,23 @@ AI 味评分：{score}/100
 - CTA 清晰度：{n}/25
 - 可读性：{n}/25
 
-### 5. 标题公式 {✅/⚠️}
+### 5. 七问自检 {✅/⚠️/❌}
+通过：{n}/7
+{逐条列出每个问题的回答或不合格原因}
+
+### 6. 标题公式 {✅/⚠️}
 {详细结果}
 
-### 6. 评论触发点 {✅/⚠️}
+### 7. 评论触发点 {✅/⚠️}
 {详细结果}
 
-### 7. 完播率微操 {✅/⚠️/❌}
+### 8. 完播率微操 {✅/⚠️/❌}
 {详细结果}
 
-### 8. 流量假设 {✅/⚠️}
+### 9. 流量假设 {✅/⚠️}
 {详细结果}
 
-### 9. 内容支柱对齐 {✅/⚠️/❌/跳过}
+### 10. 内容支柱对齐 {✅/⚠️/❌/跳过}
 {详细结果}
 
 ### 📌 审核结论

package/skills/feature-triage/SKILL.md

@@ -0,0 +1,335 @@
+---
+name: feature-triage
+description: |
+  Evaluate whether a proposed feature belongs in AutoCrew and in what form.
+  Activate when user explicitly proposes adding a new feature, capability,
+  or integration. Triggers: "我想加" / "能不能做一个" / "想增加" /
+  "加个功能" / "接入一个" / "想做一个" / "I want to add".
+---
+
+# Feature Triage
+
+> Orchestrator skill. Leads a structured decision dialogue to evaluate feature proposals
+> against AutoCrew's architecture, roadmap, and creator needs. Outputs a decision report.
+> Does NOT implement — terminates at a decision.
+
+## Persona
+
+You are AutoCrew's co-founder and product architect. You deeply understand:
+- AutoCrew's 18 tools, 5-stage pipeline (intel → topics → drafting → production → published), and skill system
+- Real workflows of Chinese social media content creators (Xiaohongshu, Douyin, WeChat, Bilibili)
+- The difference between indie creators and team creators: different needs, different constraints
+- The codebase: `src/tools/`, `src/storage/`, `src/modules/`, `skills/`, pipeline-store semantics
+
+Your decision biases (make these explicit when they influence your reasoning):
+- Prefer composing existing pipeline components over adding new modules
+- Fill current-level gaps before building higher-level features
+- A feature not built is better than a feature built badly
+- Every new module is a maintenance commitment — weigh ongoing cost, not just build cost
+
+## Inputs
+
+| Parameter | Source | Required | Description |
+|-----------|--------|----------|-------------|
+| feature_idea | User message | Yes | The proposed feature, in any level of detail |
+
+## Pre-Flight: Complexity Assessment
+
+Before engaging in discussion, silently evaluate complexity based on these signals:
+
+```
+□ Introduces a new external dependency or third-party API?
+□ Changes existing data flow or pipeline stage semantics?
+□ Affects 3+ existing skills or tools?
+□ Estimated implementation exceeds 500 lines of new code?
+```
+
+| Yes count | Complexity | Rounds | Framework handling |
+|-----------|------------|--------|--------------------|
+| 0-1       | 轻量       | 2-3    | Merge Phase 2+3 into one round |
+| 2         | 中等       | 3-4    | Per-framework, standard depth |
+| 3-4       | 重度       | 4-6    | Fully expanded, each framework gets its own round |
+
+Display to user at the start:
+> 复杂度评估：{轻量/中等/重度}，预计 {N} 轮讨论。
+
+## Discussion Flow
+
+### Phase 1 — 🔍 苏格拉底提问（理解本质）
+
+**Goal:** Through targeted questioning, strip away the surface request and uncover the
+fundamental problem the user is trying to solve.
+
+**Technique — Socratic Elicitation:**
+
+Do not accept the feature description at face value. The user describes a SOLUTION;
+your job is to excavate the PROBLEM. Ask questions that peel layers:
+
+<prompt-template>
+You are investigating the real need behind a feature proposal. Apply Socratic questioning:
+
+Layer 1 — Current state: "你现在没有这个功能时，怎么完成这件事的？"
+Layer 2 — Pain frequency: "这个问题多久遇到一次？上一次具体是什么场景？"
+Layer 3 — Alternative paths: "如果 AutoCrew 永远不加这个功能，你的 plan B 是什么？"
+Layer 4 — Essence: "如果把这个想法压缩成一句话的需求，是什么？"
+
+Rules:
+- ONE question per message. Wait for the answer before asking the next.
+- Prefer concrete questions over abstract ones. "上次你做这个花了多久" > "你觉得这个重要吗"
+- When the user's answer reveals a deeper need than the original proposal, name it:
+  "听起来你真正需要的不是 X，而是 Y。对吗？"
+- This phase ends when you can state the root problem in one sentence and the user confirms.
+</prompt-template>
+
+**Deliverable:** One-sentence root problem statement, confirmed by user.
+
+---
+
+### Phase 2 — 🧱 第一性原理（拆解需求真伪）
+
+**Goal:** Decompose the idea into irreducible capability units. For each unit, determine
+whether it's a genuine gap or already covered by AutoCrew's existing architecture.
+
+**Technique — First-Principles Decomposition:**
+
+<prompt-template>
+Take the confirmed root problem from Phase 1 and decompose into capability units.
+
+For EACH unit, evaluate using this chain-of-thought structure:
+
+前提：{what you know about AutoCrew's current capabilities relevant to this unit}
+推导：{logical chain from premise to conclusion — if any step relies on an assumption
+       rather than verified fact, tag it as [假设]}
+结论：{this unit is: ✅ genuine gap / ⚠️ partially covered / ❌ already solved}
+
+Then check for "borrowing bias":
+- Did this idea originate from seeing someone else's product (e.g., "Karpathy has a knowledge
+  base, so we should too")?
+- If yes: what is DIFFERENT about AutoCrew's context that makes this relevant here, specifically?
+- If nothing is different: flag it as borrowing bias.
+
+Present to user:
+- List of capability units with verdicts
+- Any borrowing bias detected
+- Which units (if any) represent genuine gaps worth filling
+</prompt-template>
+
+**Deliverable:** Capability unit table with genuine-gap / already-covered verdicts.
+
+---
+
+### Phase 3 — 🪒 奥卡姆剃刀（砍复杂度）
+
+**Goal:** If genuine gaps exist from Phase 2, find the simplest possible form to fill them.
+
+**Technique — Minimal Viable Form:**
+
+<prompt-template>
+For each genuine-gap capability unit from Phase 2, answer these questions in order:
+
+1. Can this be solved by COMBINING existing tools/skills with no new code?
+   → If yes: describe the composition. Stop here for this unit.
+
+2. Can this be solved by EXTENDING an existing tool/skill (adding an action, a step)?
+   → If yes: name the tool/skill and the extension. Stop here.
+
+3. Does this require a NEW skill (orchestration logic only, no new tool)?
+   → If yes: describe the skill's steps using existing tools.
+
+4. Does this require a NEW tool (new data storage, new API integration)?
+   → If yes: this is the most expensive option. Justify why 1-3 don't work.
+
+For each unit, also apply the YAGNI check:
+- "如果砍掉这个单元，剩下的部分还能独立产生价值吗？"
+- If yes → this unit is a candidate for deferral.
+
+Present to user:
+- Recommended form per unit (compose / extend / new skill / new tool)
+- What was cut and why
+- The minimum viable scope
+</prompt-template>
+
+**Deliverable:** Minimum viable form recommendation per capability unit.
+
+---
+
+### Phase 4 — 📊 马斯洛需求分析（定位价值层级）
+
+**Goal:** Position this feature in the creator's need hierarchy. Determine if it fills
+a current-level gap or skips levels.
+
+**Technique — Creator Maslow Mapping:**
+
+<prompt-template>
+Map the proposed feature (in its trimmed Phase 3 form) to the creator need hierarchy:
+
+| Level | Need | AutoCrew coverage | Examples |
+|-------|------|-------------------|----------|
+| 1. 生存 | Can publish, avoid violations | autocrew_review, sensitive-word check | 敏感词检测、基础发布 |
+| 2. 效率 | Faster output, less repetition | spawn-writer, pipeline, humanize | 自动去AI味、批量改写 |
+| 3. 质量 | Better content, competitive edge | research, references, teardowns | 信息源调研、竞品拆解 |
+| 4. 增长 | Followers, monetization, moats | hypothesis testing, performance data | 流量假说、数据驱动优化 |
+| 5. 自我实现 | Unique methodology, industry leadership | content pillars, style calibration | 个人方法论、风格体系 |
+
+Evaluate:
+1. Which level does this feature serve?
+2. Which is the LOWEST level where AutoCrew still has meaningful gaps?
+3. Does this feature fill a gap at that level, or does it skip to a higher level?
+
+If the feature skips levels (e.g., building Level 4 when Level 2 has holes):
+- Flag it explicitly: "这个功能在第 {N} 层，但第 {M} 层还有明显缺口：{gap}。建议先补 {M} 层。"
+- This is not a veto — the user decides. But make the trade-off visible.
+
+Priority recommendation:
+- 填补当前层缺口 → 立即做
+- 填补下一层 (当前层已完善) → 下个里程碑
+- 跳级或锦上添花 → 放入 backlog
+</prompt-template>
+
+**Deliverable:** Value-level positioning and priority recommendation.
+
+---
+
+## Red Team Self-Check
+
+**Before writing the final conclusion, you MUST run this check:**
+
+<prompt-template>
+Switch to red team perspective:
+
+If your conclusion is "做":
+1. List 3 strongest reasons NOT to build this.
+2. For each, attempt a rebuttal.
+3. If any rebuttal is weak (you wouldn't bet money on it), revise your conclusion.
+
+If your conclusion is "不做":
+1. List 3 strongest reasons TO build this.
+2. For each, attempt a rebuttal.
+3. If any rebuttal is weak, revise your conclusion.
+
+If your conclusion is "改形式再做":
+1. List 2 reasons the original form was actually better.
+2. List 2 reasons to just not build it at all.
+3. Attempt rebuttals for all 4.
+
+Display the red team exchange to the user. Transparency builds trust.
+</prompt-template>
+
+## Few-Shot Decision Examples
+
+Use these as calibration anchors for discussion depth and output quality.
+
+### Example A — "做" (Omni 视频拆解)
+
+> **提案：** 用户发送对标账号视频，Omni 自动分析优缺点、可借鉴点，形成索引，后续持续关注。
+>
+> **🔍 苏格拉底：** 根本问题不是"分析视频"，而是"创作者缺少结构化的学习输入"。
+> 看了 100 个对标视频，脑子里一锅粥，写的时候还是凭感觉。
+>
+> **🧱 第一性原理：**
+> - 视频内容提取 → 需要多模态能力 [genuine gap]
+> - 结构化拆解模板 → 可复用 teardown 框架 [partially covered]
+> - 索引 + 持续关注 → intel 模块可扩展 [partially covered]
+> - 供 reference 引用 → references/ 工作流已有 [covered]
+>
+> **🪒 奥卡姆：** 不需要新 tool。扩展 `autocrew_intel` 加 `source: "video_teardown"`，
+> 新建一个 skill 编排"输入视频 → 多模态分析 → 写入 intel + references"流程。
+>
+> **📊 马斯洛：** 质量层（Level 3），当前恰好在补这层缺口（刚加了 references 调研流程）。
+> 契合度高。
+>
+> **结论：做。** 以 skill + intel 扩展形式，不新建 tool。
+
+### Example B — "不做" (AI 自动生成封面)
+
+> **提案：** AutoCrew 内置 AI 画图能力，自动生成封面。
+>
+> **🔍 苏格拉底：** 根本问题是"封面制作耗时"，但追问后发现用户已经用 Canva/MidJourney，
+> 痛点其实是"封面和内容不匹配"而不是"没有画图工具"。
+>
+> **🧱 第一性原理：**
+> - 画图能力 → 已有大量成熟外部工具 [covered externally]
+> - 封面与内容匹配度检查 → `autocrew_cover_review` 已存在 [covered]
+> - 封面候选生成 → cover-generator skill 已存在 [covered]
+>
+> **🪒 奥卡姆：** 所有能力单元已覆盖或有外部替代。内置画图引擎是巨大维护负担。
+>
+> **📊 马斯洛：** 效率层（Level 2），但该层已有充分覆盖。
+>
+> **结论：不做。** 封面审核 + 候选管理已有，画图本身交给专业工具。
+
+## Decision Report Template
+
+After completing all phases + red team check, generate and save the report:
+
+**File path:** `docs/decisions/YYYY-MM-DD-{feature-slug}.md`
+
+```markdown
+# 功能决策：{feature name}
+
+## 结论
+{做 / 不做 / 改形式再做}
+{一句话理由}
+
+## 提案原始描述
+{用户原话或整理后的描述}
+
+## 分析过程
+
+### 🔍 苏格拉底提问 — 本质问题
+- 根本问题：{一句话}
+- 关键追问与回答：{2-3 条核心 Q&A 摘要}
+
+### 🧱 第一性原理 — 需求拆解
+| 能力单元 | 判定 | 理由 |
+|----------|------|------|
+| {unit} | ✅/⚠️/❌ | {reason} |
+
+- 借鉴偏差检测：{有/无，说明}
+
+### 🪒 奥卡姆剃刀 — 最简形式
+- 推荐形式：{compose / extend / new skill / new tool / 不做}
+- 砍掉的部分：{列表 + 理由}
+- 最小可行范围：{具体描述}
+
+### 📊 马斯洛需求分析 — 价值定位
+- 需求层级：{Level N — 名称}
+- 当前缺口匹配度：{填补当前缺口 / 跳级 / 锦上添花}
+- 优先级建议：{立即做 / 下个里程碑 / 放入 backlog}
+
+### 🔴 红队自检
+{展示红队正反论点和反驳过程}
+
+## 实现建议（仅当结论为"做"时）
+- 形式：{skill / tool action / module}
+- 依赖的现有组件：{列表}
+- 主要风险：{列表}
+- 建议下一步：{具体 action}
+
+## 元数据
+- 日期：{YYYY-MM-DD}
+- 提案人：user
+- 复杂度评估：{轻量/中等/重度}
+```
+
+## Error Handling
+
+| Situation | Action |
+|-----------|--------|
+| User gives vague one-liner ("加个知识库") | Start Phase 1 with broad Socratic question to ground the idea |
+| User wants to skip discussion ("直接做就行") | Acknowledge urgency, compress to 2 rounds but still run Phase 2 + red team |
+| User disagrees with "不做" conclusion | Respect user's final call. Log dissent in report: "用户决定override，理由：{reason}" |
+| Feature overlaps with in-progress work | Flag overlap, suggest checking `docs/decisions/` for prior decisions on similar topics |
+| Conclusion is "改形式再做" | Clearly describe the alternative form and what changes from the original proposal |
+
+## What This Skill Does NOT Do
+
+- Does NOT implement anything — no code, no scaffolding, no file creation beyond the decision report
+- Does NOT chain into brainstorming, writing-plans, or any implementation skill
+- Does NOT make the final decision — the user always has override authority
+- Does NOT evaluate bugs, refactors, or small adjustments to existing features
+
+## Changelog
+
+- 2026-04-06: v1 — Initial design. Four-framework decision dialogue with adaptive complexity,
+  red team self-check, few-shot examples, structured decision reports.

package/skills/knowledge-sync/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: knowledge-sync
+description: |
+  Synchronize the knowledge wiki with new intel and references. Auto-triggered after
+  intel pull/ingest, or manually via "同步知识库" / "整理 wiki" / "sync knowledge base".
+---
+
+# Knowledge Sync
+
+> Executor skill. Reads new intel items and project references, synthesizes wiki pages,
+> maintains cross-references, regenerates index, and runs lint checks.
+
+## Prerequisites
+
+Before syncing, verify:
+- `~/.autocrew/data/pipeline/wiki/` exists (if not, it will be created by initPipeline)
+- At least one intel item exists in the library
+
+## Steps
+
+1. **Determine what's new:**
+
+   a. Read `~/.autocrew/data/pipeline/wiki/log.md` to find the last sync timestamp.
+      If log.md doesn't exist, treat everything as new.
+
+   b. Call `autocrew_intel` with `action: "list"` to get all intel items.
+      Filter to items with `collectedAt` after the last sync timestamp.
+
+   c. Glob all project `references/` folders:
+      `~/.autocrew/data/pipeline/drafting/*/references/*.md`
+      Filter to files modified after last sync timestamp.
+
+   d. If nothing new → respond "知识库已是最新，无新素材需要消化。" and stop.
+
+2. **Analyze and cluster new items:**
+
+   For each new intel/reference item:
+   - Extract key entities (company names, people, products, tools)
+   - Extract key concepts (methodologies, patterns, trends)
+   - Identify potential comparison pairs (X vs Y signals)
+
+   Group items by entity/concept relevance.
+
+3. **Update or create wiki pages:**
+
+   Read `~/.autocrew/data/pipeline/wiki/index.md` to get existing pages.
+
+   For each entity/concept cluster:
+
+   a. **If a wiki page already exists** (match by slug or aliases):
+      - Read the existing page
+      - INCREMENTALLY update: append new facts to "Key Facts", add new source
+        to frontmatter `sources[]`, update `updated` date
+      - Do NOT rewrite the page. Preserve all existing content.
+      - Add the new information in context with what already exists.
+
+   b. **If no page exists AND ≥2 items reference this entity/concept:**
+      - Create a new wiki page with the unified format:
+        ```
+        ---
+        type: entity | concept | comparison
+        title: {Title}
+        aliases: [{alternative names}]
+        related: [{related page slugs}]
+        sources: [{intel file paths that inform this page}]
+        created: {today}
+        updated: {today}
+        ---
+
+        # {Title}
+
+        {2-4 paragraphs synthesizing all source material}
+
+        ## Key Facts
+        - {concrete facts with sources}
+
+        ## Related
+        - [[{related-slug}]] — {one-line relationship description}
+        ```
+
+   c. **If no page exists AND only 1 item references this:** skip. Single-source
+      entities stay in the intel library until more evidence accumulates.
+
+4. **Update cross-references:**
+
+   After all page creates/updates, scan all wiki pages:
+   - For each page, check if its `related[]` field is complete
+   - If page A mentions page B's title/aliases in its body but B is not in A's `related[]`, add it
+   - Ensure bidirectional: if A relates to B, B should relate to A
+   - Write updated pages back to disk
+
+5. **Regenerate index.md:**
+
+   Rebuild `~/.autocrew/data/pipeline/wiki/index.md` from all pages,
+   grouped by type (Entities / Concepts / Comparisons), sorted alphabetically,
+   one line per entry with title + first-sentence summary.
+
+6. **Append to log.md:**
+
+   ```
+   ## [YYYY-MM-DD] sync | {N} new items processed
+   - Created: {list of new pages}
+   - Updated: {list of updated pages}
+   - Skipped: {count of single-source items not worth a page yet}
+   - Lint: {summary}
+   ```
+
+7. **Lint check (silent — findings go to log only):**
+
+   - **Contradiction:** same fact has conflicting numbers/claims across pages
+     → log: "⚠️ Contradiction: {page A} says X, {page B} says Y"
+   - **Orphan:** page with zero inbound `related[]` references from other pages
+     → log: "⚠️ Orphan: {page} has no inbound links"
+   - **Stale:** page's `sources[]` contains intel files that have been archived (expired)
+     → log: "⚠️ Stale: {page} references expired intel {source}"
+
+8. **Report to user:**
+
+   > 知识库同步完成：
+   > - 新增页面：{list}
+   > - 更新页面：{list}
+   > - 当前 wiki 共 {N} 页
+   > - Lint 问题：{count}（详见 log.md）
+
+## Error Handling
+
+| Failure | Action |
+|---------|--------|
+| No new items since last sync | Report "已是最新" and stop |
+| Wiki directory missing | Call initPipeline to create it |
+| Intel list returns empty | Report "情报库为空，请先运行情报采集" |
+| Page write fails | Log error, continue with remaining pages |
+| Lint finds contradictions | Log to log.md, do not auto-resolve (user decides) |
+
+## Changelog
+
+- 2026-04-06: v1 — Initial version. Incremental sync, cross-references, lint.

package/skills/onboarding/SKILL.md

@@ -86,13 +86,16 @@ onboarding 完成后，**不要停在引导页面**，直接继续用户最初
 - 完成 onboarding 后，自动执行 research skill
 - 用户感知是"回答了几个问题后就开始找选题了"，而不是"被拦截做了一堆设置"
 
-**实现方式**：onboarding skill 结束时，输出一行提示：
+**实现方式**：onboarding skill 结束时，输出引导：
 <output_template lang="zh-CN">
 ```
-✅ 初始化完成！现在继续你的请求...
+初始化完成！你可以：
+1. 说"找选题"— 我帮你搜热门话题
+2. 给我一个主题 — 我按你的风格写初稿
+3. 说"风格校准"— 深度设置写作风格（推荐首次使用）
 ```
 </output_template>
-然后立即执行用户原始请求对应的 skill/tool。
+如果用户有原始请求（比如说"帮我找选题"触发了 onboarding），直接继续执行原始请求，不要停在引导页。
 
 ## 关键原则
 

package/skills/setup/SKILL.md

@@ -301,9 +301,11 @@ A 和 B，哪个更像你？
 
 3. **调用 `autocrew_memory` 的 `capture_feedback`** 记录校准完成事件
 
+**⚠️ 不要在这里停下来等用户回复。风格保存后必须立即进入 Phase 4 生成选题。**
+
 ---
 
-## Phase 4: 首个交付物 —— 3 个选题
+## Phase 4: 首个交付物 —— 3 个选题（必须执行，不可跳过）
 
 > 目标：校准完立刻产出价值，不要让用户空手离开。
 
@@ -318,9 +320,12 @@ A 和 B，哪个更像你？
 4. 询问用户：
 
 ```
-这是基于你的品牌定位生成的 3 个选题，已经存到选题库了。
+设置完成！这是基于你的品牌定位生成的 3 个选题，已经存到选题库了。
 
-想试着写哪个？我可以按你的风格先写个初稿。
+你可以：
+1. 选一个让我写初稿（告诉我序号）
+2. 说"找选题"让我搜更多热门话题
+3. 直接给我一个主题，我按你的风格写
 ```
 
 ---

package/skills/spawn-writer/SKILL.md

@@ -38,7 +38,9 @@ description: |
    IF user adjusts → update parameters.
 
 4. Execute the write-script workflow:
-   - Follow all steps in the `write-script` skill
+   - Follow all steps in the `write-script` skill **including Step 5.5 (research → references)**.
+     Do not skip research for "simple" topics — the references folder must have ≥3 relevant
+     source files before writing begins. A draft without references is a bug.
    - Save the result using `autocrew_content` tool
    - Link to topic_id if available
 
@@ -48,6 +50,14 @@ description: |
    > 2. 改一改 — 告诉我哪里要调整
    > 3. 重写 — 换个角度再来一版
 
+6. **Handle revisions via `write-script` Step 11.**
+   If the user picks option 2 or 3, or gives any revision feedback in the same conversation,
+   you MUST follow `write-script` Step 11 — rewrite the full body and persist it via
+   `autocrew_content` with `action: "update"` (passing the original `content_id` and a
+   `diff_note`). Revisions that only appear in the chat window are a bug: the `draft.md`
+   in the pipeline must always reflect the latest version. Keep the `content_id` from
+   Step 4's save result in working memory for this purpose.
+
 ## Error Handling
 
 | Failure | Action |