@pieai/pro-gov 0.7.2 → 0.8.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pieai/pro-gov",
-  "version": "0.7.2",
+  "version": "0.8.0",
   "description": "Project-level distribution kit for Project Governance System.",
   "keywords": [
     "ai-agents",
@@ -35,7 +35,7 @@
     "access": "public"
   },
   "dependencies": {
-    "@pieai/doc-gov": "^0.7.2"
+    "@pieai/doc-gov": "^0.8.0"
   },
   "devDependencies": {
     "@pieai/swimmer-ui-kit": "1.1.0",

package/assets/integrations/mattpocock-skills.md

@@ -1,42 +0,0 @@
-# mattpocock/skills Integration
-
-mattpocock/skills is the optional shared engineering skill library for
-PGS-governed projects. PGS does not vendor or rewrite their bodies; it installs
-the upstream skills unchanged through managed symlinks.
-
-## Trigger Rule
-
-There is no bootstrap skill and no default workflow owner. Let each skill's own
-narrow description decide when it applies. User-named skills always take
-priority; otherwise invoke a skill only when its documented trigger directly
-matches the task.
-
-Examples:
-
-- a reported hard bug may trigger `diagnosing-bugs`;
-- an explicit branch review may trigger `code-review`;
-- a request for a PRD may trigger `to-prd`;
-- ordinary implementation does not automatically trigger `implement`, `tdd`,
-  `grill-me`, or a multi-agent flow.
-
-Skills that require subagents must respect the user's current delegation rule.
-
-## Artifact Boundary
-
-Matt-native artifacts remain external to Doc Gov by default:
-
-- `CONTEXT.md` and `CONTEXT-MAP.md`;
-- `docs/agents/**` and `docs/adr/**`;
-- `.scratch/**`;
-- GitHub/GitLab issues.
-
-`docs/adr/**` is the only durable decision surface. Do not copy or promote an
-ADR into a second PGS decision directory. Product truth, requirements,
-implementation plans, and reusable references still belong in
-`docs/canon/**`, `docs/specs/**`, `docs/plans/**`, and `docs/reference/**`.
-
-## Distribution
-
-Maintain the canonical third-party source under
-`agent-assets/skills/npx-skills` and distribute managed symlinks through the
-`mattpocock-skills` asset bundle. Do not install project-local copies.

package/assets/public-agent-assets/skills/pie-skills/doc-cross-validator/SKILL.md

@@ -1,194 +0,0 @@
----
-name: doc-cross-validator
-description: >
-  交叉验证文档内容是否符合真实系统。对照源代码、配置文件、真实数据结构验证文档中的每一个事实性声明。
-  当用户说"验证一下文档""对照系统检查""这个文档说的对不对""确认文档准确性""交叉验证"
-  "别瞎编""写的对不对""有没有错""跟代码对得上吗""事实核查""fact check"时，使用本技能。
-  当用户要求写完文档之后，也应当自动触发本技能做最终验证。
-  即使用户只是说"检查一下""核实一下""是这样吗"——只要上下文中涉及文档与系统的对照关系，
-  也应当触发本技能。
-  本技能验证文档并产出审计报告；发现教程/创作类文档（人写的内容）有错时默认直接修正，并在报告里列清改了哪几处、依据何在；但绝不手改系统自己生成的状态文件（那类只报告、交由对应命令重新生成）。
-  与 beginner-friendly-docs 技能配合使用：那个技能写，这个技能验。
----
-
-# 文档交叉验证技能
-
-验证文档内容是否与真实系统行为一致。杜绝"想当然"、"凭印象"、"差不多"。
-
-## 核心理念
-
-文档的最大敌人不是"写得不好看"，而是"写的不对"。
-
-一个用词优美但流程错误的文档，比一个丑但准确的文档更危险——它会误导读者建立错误的心智模型。
-
-**本技能只做一件事：确认文档说的跟系统做的是一致的。**
-
-## 验证流程
-
-### 第一步：标记所有事实性声明
-
-逐段扫描文档，把所有可以验证的事实性声明提取出来。
-
-事实性声明包括：
-- **流程描述**：说某个操作之后会发生什么（如"检查通过后系统会更新记忆"）
-- **数据结构**：说系统有哪些文件、文件夹、配置项
-- **检查项**：说系统会检查哪些东西
-- **状态描述**：说系统有哪些状态、状态之间怎么转换
-- **前置条件**：说做某件事之前需要满足什么条件
-- **术语定义**：给系统术语的解释
-
-**不需要验证的内容**：
-- 比喻和类比（它们是教学工具，不是事实描述）
-- 建议和最佳实践（主观判断）
-- 虚拟人物的对话（教学示例）
-
-### 第二步：逐项对照验证
-
-对每个事实性声明，找到系统中的对应真相来源。
-
-#### 验证的真相来源（按优先级排序）
-
-1. **源代码**——实际的实现逻辑。这是最终真相。
-2. **配置文件和 JSON 结构**——如 `book.json`、`gate-result.json`、`accepted-commit.json`
-3. **真实的目录结构**——用 `list_dir` 或 `ls` 检查实际存在的文件和文件夹
-4. **CLI 帮助信息**——用 `--help` 看命令实际支持哪些选项
-5. **系统的规范文档**——如 `AGENTS.md`、`SKILL.md` 等定义行为的文件
-6. **测试代码**——测试用例描述了系统的预期行为
-
-**不可以作为真相来源的**：
-- 之前版本的文档（可能过时）
-- AI 的"记忆"或"知识"（可能不准确）
-- 其他 AI 写的文档（可能也有错）
-
-#### 验证的方法
-
-对于每个事实性声明：
-
-1. **定位真相来源**——找到系统中能验证这个声明的具体文件或代码
-2. **读取真相**——实际打开文件，读取内容
-3. **对比**——声明 vs 真相，一致还是不一致？
-4. **分类**：
-   - ✅ **准确**：完全一致
-   - ⚠️ **简化但不误导**：声明省略了细节，但核心意思正确，不会导致误解
-   - 🔶 **简化但可能误导**：声明省略的细节可能让读者建立错误理解
-   - ❌ **错误**：声明与真相不一致
-   - 🔍 **无法验证**：找不到对应的真相来源
-
-### 第三步：判断简化的合理性
-
-对于"简化"类的声明，需要判断简化是否合理。
-
-#### 合理的简化
-
-- 省略了初学者不需要知道的高级功能
-- 用通用名称替代了具体的技术标识符（如"大纲"代替"plots.md"）
-- 合并了多个概念为一个更好理解的概念
-- 省略了边缘情况（只要不影响核心理解）
-
-#### 不合理的简化
-
-- 把可选步骤说成必须步骤，或反过来
-- 遗漏了会影响用户决策的重要概念
-- 把两个独立的概念混为一谈
-- 错误地简化了流程的先后顺序或因果关系
-- 完全省略了一个重要的系统组件
-
-### 第四步：输出审计报告
-
-生成一份结构化的审计报告。
-
-#### 报告格式
-
-```markdown
-# 文档交叉验证报告
-
-## 验证范围
-- 文档：[文档名]
-- 验证日期：[日期]
-- 对照的真相来源：[列出检查了哪些源文件]
-
-## 验证结果摘要
-
-| 分类 | 数量 |
-| --- | --- |
-| ✅ 准确 | N |
-| ⚠️ 简化但不误导 | N |
-| 🔶 简化但可能误导 | N |
-| ❌ 错误 | N |
-| 🔍 无法验证 | N |
-
-## 需要修正的问题
-
-### ❌ 错误 1：[简要描述]
-- **文档原文**："..."
-- **实际情况**："..."
-- **真相来源**：[文件路径]
-- **建议修正**："..."
-
-### 🔶 可能误导 1：[简要描述]
-- **文档原文**："..."
-- **实际情况**：完整描述是"..."
-- **误导风险**：读者可能会以为"..."
-- **建议**：补充说明"..."
-
-## ⚠️ 合理简化（不需要修正，但记录在案）
-
-- [声明]：省略了[什么]，对初学者不影响理解
-- ...
-
-## 验证通过的声明（抽样展示）
-
-- ✅ "检查通过后才能更新记忆" → 符合 AGENTS.md 第 151 行
-- ✅ "文件改了之后检查结果自动过期" → 符合 gate-result.json 的 inputHashes 机制
-- ...
-```
-
-### 第五步：修正文档（默认直接改"可改的内容"，改完报告改了什么）
-
-发现 ❌ 错误和 🔶 可能误导后，**默认直接动手修正**——但动手前先分清这块内容属于哪一类，因为不是所有东西都能手改。
-
-**可以直接改：人写的创作/教学类内容。** 教程正文、说明文档、大纲、草稿、设定等。发现错就改，改完务必在报告里附一份**改动清单**：改了哪几处、原文 →新文、依据哪个真相来源。这样用户既拿到干净的文档，又能一眼看到你动了什么、为什么动——这就是"改完报告"，不是"偷偷改"。
-
-**绝不手改：系统自己生成的硬状态文件。** 像 `gate-result.json`、`accepted-commit.json`、evidence、memory、`story_graph.json` 这类由命令或流程产出的产物，记录的是"系统算出来的事实"。手改会让数据对不上、还可能被系统的保护机制（hook）直接拦下。这类即使发现不对，也**只在报告里指出**，并说明应该去改它的源头、或用对应命令重新生成（如重跑 `gate run` / `memory update`），而不是直接编辑这个文件。
-
-> 一句话口诀：**这个文件是人写的，还是系统生成的？** 人写的——直接改 + 报告；系统生成的——只报告、不碰。
-
-修正"可改内容"时遵循：
-- **尽量在不破坏可读性的前提下修正**——不要为了准确而牺牲初学者的理解
-- **重要的细节补进正文；次要的细节用引用块（`>`）补充**
-- **改完重新走一遍验证**，确认没有引入新的错误
-- **在报告里保留改动清单**，方便用户复核
-
-> 例外：如果用户明确说"只检查别改""先别动我的文档"，那就只出报告、不动手——尊重用户当下的意图。
-
-## 常见的"想当然"陷阱
-
-以下是写文档时最容易出现的"想当然"错误，验证时要特别注意：
-
-| 陷阱 | 描述 | 怎么避免 |
-| --- | --- | --- |
-| 编造检查项 | 说系统检查 X，但实际没有 | 读 gate-result.json 的 checks 数组 |
-| 编造流程步骤 | 说操作后会自动做 Y，但实际需要手动 | 读源代码或跑一次实际命令 |
-| 张冠李戴 | 把 A 功能的特性说成 B 的 | 分别查看 A 和 B 的实现代码 |
-| 遗漏前置条件 | 说"做完 X 就可以 Y"，但实际还需要 Z | 读 CLI 代码中的校验逻辑 |
-| 简化过度 | 说"系统有两个状态"，但实际有五个 | 读枚举定义或状态机代码 |
-| 旧信息 | 引用的流程已经在新版本中改了 | 对照当前代码，而不是旧文档 |
-
-## 与其他技能的配合
-
-- **beginner-friendly-docs**：那个技能负责写，这个技能负责验。写完后调用本技能做验证。
-- 如果在 chapter-doctor 管道中使用，本技能位于写作之后、发布之前。
-
-## 适用范围
-
-本技能适用于任何"文档描述了一个系统"的场景：
-- 软件产品的用户指南
-- API 文档
-- 开发者文档
-- 教学文档
-- 系统架构说明
-
-不适用于：
-- 纯文学创作（没有"系统"可以验证）
-- 观点类文章（不存在客观的"对错"）
-- 营销文案（允许适度夸张）