jennie-shawn starworkKnowledge
使用这个 skill，帮助用户开启和维护“项目知识库”。
项目知识库不是资料夹，也不是草稿区。它用于让 AI 长期整理当前项目里会反复用到的稳定理解。原始资料仍放在参考资料区，草稿和成果仍按工作台规则进入输出区。
主入口边界
如果用户只是询问产品总览、起步路径、安装入口或该用哪个 StarWork 能力，回到 starwork 主入口。普通资料整理、README 整理和阶段收尾不属于本 skill；只有长期稳定知识沉淀、知识库开启和知识库维护才使用 starworkKnowledge。
第一屏：开启或维护知识库
当用户说“开启知识库”“初始化知识库”“让 AI 记住项目知识”时，先讲清楚这一步是什么，不要直接抛 CLI 命令：
项目知识库是让 AI 长期记住项目稳定理解的地方。
它不是原始资料文件夹，也不是草稿区。原始材料仍放在参考资料区，临时想法仍放在草稿区；知识库只沉淀会反复用到、已经比较稳定的判断，比如客户背景、产品规则、术语解释、长期策略和复盘结论。
接下来我会分三步带你开启：
1. 先检查当前项目是否已经有知识库；
2. 再预览 StarWork 准备创建哪些知识库文件；
3. 你确认后再正式开启，并做一次结构检查。
我不会把旧资料整包搬进知识库，也不会在你确认前改动原始资料。
当用户给资料、说“帮我记住”“建知识库”“这一堆材料整理一下”时，先输出：
我会先帮你判断这些材料哪些适合进入长期知识库。
知识库不是把所有资料搬进去的文件夹，也不是草稿区。它只保存以后会反复用到、已经比较稳定的理解，例如项目规则、术语解释、客户背景、长期策略、阶段复盘结论。
接下来我会先做三件事：
1. 把你给的材料分成长期知识、临时资料、草稿、参考来源和待确认事实；
2. 预览我建议写入知识库的条目、来源、保存理由和位置；
3. 等你确认后，再写入正式知识文件。
在你确认前，我不会把整批资料直接搬进知识库，也不会改动已有知识文件。
Skill / CLI 边界
starwork knowledge = 创建和检查知识库结构
starworkKnowledge skill = 判断、采访、分类、预览、整理、写入知识内容
starworkKnowledgeProject = 项目开启知识库后安装到当前项目里的维护助手
必须优先使用 CLI：
- 开启知识库：先运行
starwork knowledge init --dry-run，用户确认后再运行starwork knowledge init --yes。 - 查看状态：运行
starwork knowledge status --json。 - 检查结构：运行
starwork knowledge check。 - 涉及旧
知识/、knowledge/或定制路径：先生成starwork.knowledgeblueprint，再运行starwork knowledge apply --blueprint <file> --dry-run，用户确认后执行。
不要绕过 CLI 手写另一套目录结构。starwork knowledge init 成功后，CLI 会把 starworkKnowledgeProject 安装进当前项目。不要让用户把这个项目内业务 Skill 装到全局。
Incoming Material Classification
用户给出材料时，第一步是分类和解释，不是直接写入。一段材料可以同时包含多个分类。
| 分类 | 用户可见解释 | 默认处理 | 能否进入知识库 |
|---|---|---|---|
| 长期知识 | 以后会反复用到、已经比较稳定的项目理解 | 候选写入 pages/ 或 synthesis/ |
可以，但仍需预览确认 |
| 临时资料 | 这次任务可能有用，但不一定长期复用 | 留在参考资料、任务上下文或用户指定位置 | 默认不进入 |
| 草稿 | 还在写、还没定稿、可能会大改的内容 | 留在草稿或输出流程 | 不进入，除非转化为已确认结论 |
| 参考来源 | 支撑知识判断的原始出处、链接、文件、访谈记录 | 记录到 sources/ 或引用已有来源位置 |
可记录来源，不复制全文 |
| 待确认事实 | 看起来重要，但来源、真实性或稳定性不足 | 放入候选清单，向用户追问 | 用户确认前不写正式知识 |
判断规则：
- 来源不是知识正文；网页、PDF、会议纪要、聊天记录可以作为来源，但不能整包搬进
pages/或synthesis/。 - 草稿只有在用户确认某个判断已经稳定后，才能转成长期知识。
- 待确认事实不能伪装成确定结论；最多放入待确认清单或
inbox/，并写清楚为什么待确认。
写入前预览
在任何正式写入 pages/、synthesis/、sources/、index.md 或 log.md 前，必须先给用户看写入前预览表。
| 知识条目 | 来源 | 为什么值得长期保存 | 建议放入位置 | 是否需要用户确认 |
|---|---|---|---|---|
| ... | ... | ... | ... | ... |
预览后必须列出本次不建议写入知识库的内容：
这次我不建议写入知识库的内容：
- 原始资料全文：只作为来源保留。
- 尚未定稿的段落：仍按草稿处理。
- 来源不明确的判断：先列为待确认事实。
确认语必须具体：
请确认：是否按上表写入这些知识条目？
如果你只想保存其中几条，也可以告诉我编号。
不得用“我继续整理了”“我会帮你处理好”这类模糊授权替代用户确认。
工作流程
1. 用户想开启知识库
先确认当前目录：
starwork knowledge status --json
如果还没开启，用人话解释，再执行：
starwork knowledge init --dry-run
用户确认后：
starwork knowledge init --yes
starwork knowledge check
2. 用户给了新资料
先读 schema.md 和 index.md，理解当前知识库规则和已有地图。再做 incoming material classification，给出写入前预览表，等待用户确认。
用户确认后：
- 单个稳定主题：更新或创建
pages/。 - 跨多个主题形成的策略、复盘、方法或判断：更新或创建
synthesis/。 - 重要来源：记录到
sources/。 - 暂时无法归类或需要确认：放入
inbox/，并写清楚原因和后续确认问题。
最后更新 index.md 和 log.md。
3. 用户询问长期知识相关问题
先读 index.md，再读相关 pages/ 和 synthesis/。回答用户后，如果产生了可长期复用的新判断，先告诉用户你建议沉淀到知识库哪里；用户确认后再更新。
4. 用户要求策略、复盘或阶段判断
优先写入或更新 synthesis/。synthesis/ 应连接多个主题页、来源和项目经验。不要把一份原始资料直接改写成 synthesis。
5. 用户已有旧知识目录
如果看到旧 知识/、knowledge/、资料库/ 或类似目录，不要直接搬迁、改名或删除。先判断它更像原始资料区、旧知识草稿、旧版项目知识库、项目中心共享知识链接还是普通历史目录，然后和用户确认，再生成 blueprint。
pages/ 和 synthesis/
pages/ = 知识卡片
synthesis/ = 思考成果
pages/ 适合用户画像、标题结构、产品模块、客户需求、竞品账号。synthesis/ 适合 30 天冷启动策略、阶段复盘、增长方法论、定位调整建议。
用户不需要理解内部目录时，可以说：
我会把稳定主题放成知识卡片，把跨主题的判断放成思考成果；在你确认前，两类都不会正式写入。
禁止事项
- 不把整批资料当作知识库正文。
- 不做整包导入式整理。
- 不把原始资料整包搬进知识库。
- 不把宿主 transcript、memory、summary 直接当成知识库。
- 不把临时资料、草稿、命令输出、单次任务过程放进知识库。
- 不把草稿当长期知识。
- 不把未确认事实写成确定结论。
- 不默认提交到项目中心。
- 不自动移动、删除或改名旧
知识//knowledge/。 - 不写没有来源、没有上下文的空泛总结。