# Archive Project

> 项目知识回流中央 HRIS 知识库的统一入口。用于用户明确要求将项目知识沉淀、入库或归档到中央知识库的请求；普通阶段总结或项目复盘不自动触发跨仓流程。明确入库范围后协调证据提炼、确认、Wiki 同步及按授权推送，无需逐个调用底层 Skill。

- Skill: `sleevesun/archive-project` (Agent Skill)
- Install (CLI): `npx skillmds@latest add sleevesun/archive-project`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sleevesun/archive-project/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: sleevesun (https://skillmd.com/u/sleevesun)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sleevesun/archive-project

---


# archive-project · 项目知识闭环

把任意项目中的可靠知识提炼后回流到中央 HRIS 知识库，并确保核心 Repo Wiki 同步。用户侧只呈现“提炼 → 入库 → Wiki 同步 → 发布”四个阶段，不要求用户记忆底层 Skill 名称或手工续跑命令。

## 角色边界

- 本 Skill 是自然语言入口和总编排器。
- `submit-knowledge` 是中央仓事务守门员，负责合规、源知识 commit、Wiki 同步编排和最终 push。
- `update-repowiki` 是派生同步层，只维护 `.qoder/repowiki` 与 `.agent-wiki`，永不自行 push。
- 原始项目是证据源；`HR系统知识库/` 是权威知识源；`.qoder/repowiki/` 是由权威知识派生的导航与 Agent 知识卡片。

## 中央知识库身份

按以下顺序定位，任何候选都必须验证：

1. 环境变量 `HRIS_KNOWLEDGE_REPO` 指向的目录；
2. 本机默认路径 `/Users/xianer/Documents/HR 系统/HR系统文档-面向HR开放等14个文件`；
3. 当前工作区其他根目录。

有效中央仓必须同时满足：

- 存在 `HR系统知识库/`、`.qoder/repowiki/` 和 `scripts/update_repowiki.py`；
- `git remote -v` 至少有一个远端 URL 包含 `cnb.cool/Chordsun/HRIS`。

从 `git remote -v` 解析匹配 URL 对应的真实远端名，记为 `<HRIS_REMOTE>`。当前常见值是 `cnb`，不得写死为 `origin`。

## 适用范围与预览

只有用户明确指定中央知识库为交付目标时，才使用以下入库流程。普通“阶段总结”“项目复盘”“总结当前进展”默认在当前任务交付，不增加跨仓写入或发布审批。下表的模式示例仅在中央知识库目标已经明确后用于分类。

用户要求“先看结果”“先预览”时，只生成总结和拟变更预览，不修改中央仓、不 commit、不 push。“仅本地”禁止 push；具体本地写入和提交仍按用户已明确批准的范围执行。

## 总结模式

| 模式 | 触发示例 | 产出 |
|---|---|---|
| 增量更新 | “更新项目知识”“同步最近变化” | 只提炼上次基线后的新增、修正与失效知识 |
| 阶段总结 | “总结当前进展”“里程碑总结” | 阶段报告，项目状态保持进行中 |
| 结项归档 | “项目归档”“上线后复盘” | 完整复盘，更新结项状态和历史归档 |

无法从请求和证据判断模式时，只询问业务范围，不询问用户该调用哪个 Skill。

## 闭环清单

```text
- [ ] 1. 确定模式、范围和上一知识基线
- [ ] 2. 扫描项目证据并提炼知识
- [ ] 3. 展示总结、中央仓落点和发布范围，取得一次确认
- [ ] 4. 定位中央仓并读取最新状态
- [ ] 5. 写入权威知识文件和总结报告
- [ ] 6. 交由中央入库事务完成双 commit 与 Wiki 同步
- [ ] 7. 汇报源知识 commit、Wiki commit 和 CNB 推送结果
```

## Step 1：扫描证据与基线

按优先级读取：

1. 项目仓 `.knowledge/` 中的决策、口径和阶段记录；
2. 适用的 `AGENTS.md`、`CLAUDE.md`、README、架构报告；
3. PRD、会议纪要、方案、配置、测试与实际代码；
4. 上一份阶段总结、复盘报告和中央知识库现有条目；
5. Git 提交与差异，用于确定增量范围。

文档说明预期，代码和配置说明实现，运行结果说明实际行为。出现冲突时保留差异，不自行选择方便的结论。

## Step 2：生成知识产物

增量更新使用：

```markdown
# <项目名> 知识更新

## 更新范围
- 时间或提交范围：
- 涉及系统：
- 当前状态：

## 新增知识
## 修正或失效知识
## 关键决策与原因
## 口径、配置与权限变化
## 遗留问题
## 来源索引
```

阶段总结或结项归档使用：

```markdown
# <项目名> <阶段总结/复盘报告>

## 基本信息
- 项目周期：
- 涉及系统：
- 项目状态：
- 本阶段范围：

## 项目背景
## 关键决策
| 决策 | 原因 | 放弃的备选方案 |
|---|---|---|

## 口径与配置变化
## 时间节点
| 日期 | 事件 |
|---|---|

## 遗留问题与后续计划
## 经验教训
## 来源索引
```

只写有证据支持的内容。缺失信息标记“待补充”，不得编造。

### 知识提炼防衰减【硬约束】

知识在“一手材料 → 提炼”环节最容易衰减：主语丢失、动作被改成被动句、流程被压缩。已发生案例：“HRBP 在 4.5 个月节点开启评价”被提炼成“入职满 4.5 个月时开启评价”，下游查询 Agent 据此答成“系统自动开启”。提炼时必须：

- 动作、责任、触发方式类内容必须保留操作主体：谁发起、谁审批、谁执行、是否系统自动。禁止把带主语的动作提炼成无主语被动句——被动句会被下游读者当成“系统自动触发”；
- 流程类知识按四要素记录：状态、触发条件、操作主体、出口动作。缺哪项标“待补充”，禁止靠语感补齐；
- 流程箭头节点（如“目标设定 → 上级确认 → 开启评价”）是主语流失高发区：其他节点主语自明时，被省略主体的节点恰恰最容易丢主语。提炼后逐节点自问“这一步谁做”，答不出即回一手材料核对。

## Step 3：一次业务确认

向用户展示：

- 总结全文或关键增量；
- 关键口径对照表：时间规则、流程节点、责任角色类提炼句与一手材料原句并排展示，逐条确认操作主体与数值未衰减；
- 将修改的中央知识库文件；
- 是否会创建源知识 commit、Wiki commit；
- 目标远端 `cnb.cool/Chordsun/HRIS` 的 `main` 分支。

展示具体文件范围、远端和分支，并明确区分本地写入、source commit、Wiki commit 与 push；只有用户明确批准的动作才视为已授权。该确认可一次覆盖所展示且获批准的本轮范围，底层 Skill 继承对应授权，无需逐个再问。推送仍以敏感扫描和相关校验通过为前提。

用户说“先看结果”“先预览”时，只交付总结与拟变更预览，不修改中央仓、不 commit、不 push。用户说“仅本地”时不 push；本地写入和提交仅在已获明确授权时执行。

## Step 4：定位并更新中央仓

进入已验证的中央仓，先记录 HEAD、检查分支、工作区和远端，再决定是否更新基线：

```bash
git status --porcelain
git branch --show-current
git remote -v
git rev-parse HEAD
```

存在非本轮改动时先核实归属并隔离，不得混入、reset、覆盖或为同步而自动 stash。已授权中央仓本地写入、目标分支正确且工作区干净时，可 fetch 匹配远端并检查分叉；只有可快进且不会覆盖既有改动时才用 `git merge --ff-only <HRIS_REMOTE>/main` 更新基线。已是最新则继续；存在未发布提交时核实其归属和最终推送范围。需要 rebase 或其他历史改写时，先核对已有授权是否覆盖具体提交和影响，缺少授权则暂停该同步步骤并说明，不自动改写。无法安全隔离时只暂停中央仓写入，保留已完成的总结预览。

## Step 5：按知识落点写入

| 知识类型 | 中央仓落点 |
|---|---|
| 系统功能与业务规则 | `HR系统知识库/02-功能模块详解/` |
| 操作经验与 FAQ | `HR系统知识库/03-操作指南与FAQ/` |
| 项目状态和里程碑 | `HR系统知识库/04-项目进度与里程碑/` |
| 权限与角色 | `HR系统知识库/05-权限配置与角色定义/` |
| 上线与变更事件 | `HR系统知识库/06-系统变更历史/` |
| 数据口径与配置 | `HR系统知识库/07-配置参数与数据口径/` |
| 阶段报告 | `进行中项目文档/<项目名>/` |
| 结项报告 | `各系统历史文档/<年月-项目名>/` |
| 无法判断 | `收集箱/`，并在汇报中说明 |

修改知识文件时同步维护来源索引、口径变更记录、相关双向链接和模块导航。提炼产物与一手权威材料同批回流：业务规则、时间口径、流程状态的唯一权威源（PRD、方案、口径定义等）必须随提炼知识一起进入 `进行中项目文档/<项目名>/`，保证库内条目可溯源到一手材料——Repo Wiki 只能从库内文件派生，权威源不在库里，知识衰减就无法在库内被发现。一般过程文件仍不搬运；用户明确要求归档原件时再按入库规则处理。

## Step 6：交给中央入库事务

写入完成后，读取并执行 `submit-knowledge` 的“知识闭环模式”。传递以下上下文：

- 项目名与总结模式；
- 原项目路径和来源范围；
- 本轮允许提交的中央仓路径清单；
- 总结报告路径；
- 用户是否授权 push。

此时不要先行 commit 或 push。`submit-knowledge` 必须按以下事务顺序完成：

1. 合规与关联检查；
2. 创建仅含权威知识源的 source commit；
3. 调用 `update-repowiki` 生成并校验独立 Wiki commit；
4. 对派生 Wiki 再做敏感复核；
5. 按授权一次 push 两个 commit。

## Step 7：最终汇报

必须区分并报告：

- 原项目证据范围；
- 写入的权威知识文件；
- 总结报告位置；
- source commit hash；
- Wiki commit hash，或无 Wiki 变更的原因；
- `validate` 结果；
- 推送远端、分支和结果。

## 中途失败

保留已生成的报告、文件改动和本地 commit，不自动回滚。明确标注停在“提炼、入库校验、源知识 commit、Wiki 校验、推送”中的哪一步；恢复时从该断点继续，不重新生成已确认内容。