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。

闭环清单

- [ ] 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：生成知识产物

增量更新使用：

# <项目名> 知识更新

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

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

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

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

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

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

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

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

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

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

知识在“一手材料 → 提炼”环节最容易衰减：主语丢失、动作被改成被动句、流程被压缩。已发生案例：“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、检查分支、工作区和远端，再决定是否更新基线：

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：按知识落点写入

修改知识文件时同步维护来源索引、口径变更记录、相关双向链接和模块导航。提炼产物与一手权威材料同批回流：业务规则、时间口径、流程状态的唯一权威源（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 校验、推送”中的哪一步；恢复时从该断点继续，不重新生成已确认内容。