StarworkKnowledge

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.knowledge blueprint，再运行 starwork knowledge apply --blueprint <file> --dry-run，用户确认后执行。

不要绕过 CLI 手写另一套目录结构。starwork knowledge init 成功后，CLI 会把 starworkKnowledgeProject 安装进当前项目。不要让用户把这个项目内业务 Skill 装到全局。

Incoming Material Classification

用户给出材料时，第一步是分类和解释，不是直接写入。一段材料可以同时包含多个分类。

判断规则：

• 来源不是知识正文；网页、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/。
• 不写没有来源、没有上下文的空泛总结。