# starworkKnowledge

> Create, inspect, and maintain a local StarWork project knowledge base with `starwork knowledge`, focused on long-term stable project knowledge.

- Skill: `jennie-shawn/starworkknowledge` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add jennie-shawn/starworkknowledge`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jennie-shawn/starworkknowledge/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: jennie-shawn (https://skillmd.com/u/jennie-shawn)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jennie-shawn/starworkknowledge

---


# starworkKnowledge

使用这个 skill，帮助用户开启和维护“项目知识库”。

项目知识库不是资料夹，也不是草稿区。它用于让 AI 长期整理当前项目里会反复用到的稳定理解。原始资料仍放在参考资料区，草稿和成果仍按工作台规则进入输出区。

## 主入口边界

如果用户只是询问产品总览、起步路径、安装入口或该用哪个 StarWork 能力，回到 `starwork` 主入口。普通资料整理、README 整理和阶段收尾不属于本 skill；只有长期稳定知识沉淀、知识库开启和知识库维护才使用 `starworkKnowledge`。

## 第一屏：开启或维护知识库

当用户说“开启知识库”“初始化知识库”“让 AI 记住项目知识”时，先讲清楚这一步是什么，不要直接抛 CLI 命令：

```text
项目知识库是让 AI 长期记住项目稳定理解的地方。

它不是原始资料文件夹，也不是草稿区。原始材料仍放在参考资料区，临时想法仍放在草稿区；知识库只沉淀会反复用到、已经比较稳定的判断，比如客户背景、产品规则、术语解释、长期策略和复盘结论。

接下来我会分三步带你开启：
1. 先检查当前项目是否已经有知识库；
2. 再预览 StarWork 准备创建哪些知识库文件；
3. 你确认后再正式开启，并做一次结构检查。

我不会把旧资料整包搬进知识库，也不会在你确认前改动原始资料。
```

当用户给资料、说“帮我记住”“建知识库”“这一堆材料整理一下”时，先输出：

```text
我会先帮你判断这些材料哪些适合进入长期知识库。

知识库不是把所有资料搬进去的文件夹，也不是草稿区。它只保存以后会反复用到、已经比较稳定的理解，例如项目规则、术语解释、客户背景、长期策略、阶段复盘结论。

接下来我会先做三件事：
1. 把你给的材料分成长期知识、临时资料、草稿、参考来源和待确认事实；
2. 预览我建议写入知识库的条目、来源、保存理由和位置；
3. 等你确认后，再写入正式知识文件。

在你确认前，我不会把整批资料直接搬进知识库，也不会改动已有知识文件。
```

## Skill / CLI 边界

```text
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

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

| 分类 | 用户可见解释 | 默认处理 | 能否进入知识库 |
| --- | --- | --- | --- |
| 长期知识 | 以后会反复用到、已经比较稳定的项目理解 | 候选写入 `pages/` 或 `synthesis/` | 可以，但仍需预览确认 |
| 临时资料 | 这次任务可能有用，但不一定长期复用 | 留在参考资料、任务上下文或用户指定位置 | 默认不进入 |
| 草稿 | 还在写、还没定稿、可能会大改的内容 | 留在草稿或输出流程 | 不进入，除非转化为已确认结论 |
| 参考来源 | 支撑知识判断的原始出处、链接、文件、访谈记录 | 记录到 `sources/` 或引用已有来源位置 | 可记录来源，不复制全文 |
| 待确认事实 | 看起来重要，但来源、真实性或稳定性不足 | 放入候选清单，向用户追问 | 用户确认前不写正式知识 |

判断规则：

- 来源不是知识正文；网页、PDF、会议纪要、聊天记录可以作为来源，但不能整包搬进 `pages/` 或 `synthesis/`。
- 草稿只有在用户确认某个判断已经稳定后，才能转成长期知识。
- 待确认事实不能伪装成确定结论；最多放入待确认清单或 `inbox/`，并写清楚为什么待确认。

## 写入前预览

在任何正式写入 `pages/`、`synthesis/`、`sources/`、`index.md` 或 `log.md` 前，必须先给用户看写入前预览表。

| 知识条目 | 来源 | 为什么值得长期保存 | 建议放入位置 | 是否需要用户确认 |
| --- | --- | --- | --- | --- |
| ... | ... | ... | ... | ... |

预览后必须列出本次不建议写入知识库的内容：

```text
这次我不建议写入知识库的内容：
- 原始资料全文：只作为来源保留。
- 尚未定稿的段落：仍按草稿处理。
- 来源不明确的判断：先列为待确认事实。
```

确认语必须具体：

```text
请确认：是否按上表写入这些知识条目？
如果你只想保存其中几条，也可以告诉我编号。
```

不得用“我继续整理了”“我会帮你处理好”这类模糊授权替代用户确认。

## 工作流程

### 1. 用户想开启知识库

先确认当前目录：

```bash
starwork knowledge status --json
```

如果还没开启，用人话解释，再执行：

```bash
starwork knowledge init --dry-run
```

用户确认后：

```bash
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/`

```text
pages/      = 知识卡片
synthesis/  = 思考成果
```

`pages/` 适合用户画像、标题结构、产品模块、客户需求、竞品账号。`synthesis/` 适合 30 天冷启动策略、阶段复盘、增长方法论、定位调整建议。

用户不需要理解内部目录时，可以说：

```text
我会把稳定主题放成知识卡片，把跨主题的判断放成思考成果；在你确认前，两类都不会正式写入。
```

## 禁止事项

- 不把整批资料当作知识库正文。
- 不做整包导入式整理。
- 不把原始资料整包搬进知识库。
- 不把宿主 transcript、memory、summary 直接当成知识库。
- 不把临时资料、草稿、命令输出、单次任务过程放进知识库。
- 不把草稿当长期知识。
- 不把未确认事实写成确定结论。
- 不默认提交到项目中心。
- 不自动移动、删除或改名旧 `知识/` / `knowledge/`。
- 不写没有来源、没有上下文的空泛总结。