@pieai/pro-gov 0.4.4 → 0.4.6

package/assets/docs/reference/adoption/adoption-playbook.md

@@ -221,7 +221,7 @@ Add:
 - AI-in-the-Loop rules linked from the project's external shared-rule source
 - canon/provenance/archive rules in `docs/policy/best-practice-for-this-project.md`
 
-Do not add engineering TDD workflow plugins or Directed Development by default.
+Do not add engineering test workflow plugins by default.
 Use `capture-learning` only for a real reusable lesson that belongs in that
 workspace.
 

package/assets/docs/reference/adoption/recommended-agent-tooling.md

@@ -30,9 +30,9 @@ work; tools and skills add capabilities only when their narrow trigger matches.
 | `@pieai/doc-gov` | required | Governed-document and router validation |
 | mattpocock/skills | available | Optional specialist toolbox; no bootstrap or workflow owner |
 | `capture-learning` | available | Save a verified reusable lesson after completed work |
-| Superpowers | not installed | Retired mandatory workflow plugin |
-| Compound Engineering | not installed | Retired; native PGS capture keeps the useful learning loop |
-| Ponytail | not installed | Retired global mode/hooks; ordinary engineering judgment stays lean |
+| Superpowers | do not install | Retired mandatory workflow plugin |
+| Compound Engineering | do not install | Retired; native PGS capture keeps the useful learning loop |
+| Ponytail | do not install | Retired global mode/hooks; ordinary engineering judgment stays lean |
 
 Before non-trivial work:
 
@@ -53,3 +53,41 @@ the task and the project's real command ladder.
 Host plugins that provide external capabilities—such as GitHub, Vercel,
 Supabase, browsers, documents, or device control—remain independent choices.
 PGS does not require them unless a portfolio manifest explicitly declares one.
+
+## Who Owns Verification
+
+The AI agent executing the task owns verification. Tests do not act on their
+own, and no workflow plugin is required to make the agent run them.
+
+Use the target project's real command ladder as evidence: unit tests, type
+checks, builds, browser checks, deployment checks, or documentation checks as
+appropriate. A narrow skill may help when its trigger matches—such as `tdd` for
+an explicitly test-first request or `diagnosing-bugs` for a hard failure—but no
+skill owns ordinary implementation.
+
+Beginner version: removing the driving instructor does not remove the car's
+brakes or the driver's duty to check them. Superpowers' mandatory ceremony is
+gone; project-specific verification remains because it proves the change works.
+
+## Skill Lifecycle Vocabulary
+
+These states are different. Do not use “installed” as a shortcut for all of
+them.
+
+| State | Meaning | Context/runtime effect |
+| --- | --- | --- |
+| marketplace-listed | The host can offer the plugin for installation. | None until installed. |
+| cached | Source bytes exist locally for reuse or marketplace display. | Not necessarily enabled or discoverable. |
+| registered | PGS knows the asset id, source, scope, and placement. | Inventory only. |
+| bundled | A reviewed PGS bundle names the asset. | Still not installed in a target. |
+| installed | A host plugin record or managed project/user link exists. | May become discoverable, depending on placement and enablement. |
+| enabled | The host is allowed to load an installed plugin. | Plugin components may be exposed to sessions. |
+| discoverable | The host exposes a skill's name and description to the model. | Small catalog/context cost. |
+| model-invoked | The skill description may trigger automatically on a matching task. | Body loads only when selected. |
+| user-invoked | The user or an explicit flow must request the skill. | No automatic skill-body load. |
+| loaded | The host has read the skill body for the current task. | Full skill instructions affect the current turn. |
+
+User-scoped skills are linked once under supported user roots. Project-scoped
+skills are installed through a reviewed asset plan and recorded in the target's
+asset lock. Marketplace catalogs and retired-plugin archives are not installed
+skills.

package/assets/profiles/doc-only/manifest.yml

@@ -8,8 +8,6 @@ required:
     source: external shared-rule SSOT
   agents_routing: docs/governance/agents-routing/doc-only-v0.9.md
   current_work: docs/reference/execution/current-work.md
-optional:
-  directed_development: false
 project_local_required:
   - docs/policy/best-practice-for-this-project.md
   - canon/provenance/approval boundaries

package/assets/profiles/doc-only/profile.md

@@ -14,7 +14,6 @@ Use for non-runtime projects: IP development, AI media production, research vaul
 ## Does Not Include By Default
 
 - engineering-runtime agents routing
-- Directed Development
 - engineering TDD workflow plugins
 - behavior-critical code lanes
 

package/assets/profiles/engineering-runtime/manifest.yml

@@ -9,7 +9,6 @@ required:
   agents_routing: docs/governance/agents-routing/engineering-runtime-v0.9.md
   current_work: docs/reference/execution/current-work.md
 optional:
-  directed_development: integrations/directed-development.md
   mattpocock_skills: integrations/mattpocock-skills.md
 project_local_required:
   - docs/policy/best-practice-for-this-project.md

package/assets/profiles/engineering-runtime/profile.md

@@ -9,7 +9,6 @@ Use for code-heavy projects: apps, games, runtimes, services, browser products,
 - `docs/governance/ssot-v0.9.md`
 - external AI-in-the-Loop policy linked by target projects under `docs/policy/shared-rules/ai-in-the-loop.md`
 - `docs/governance/agents-routing/engineering-runtime-v0.9.md`
-- `integrations/directed-development.md`
 - `integrations/mattpocock-skills.md`
 - starter `docs/governance/` and `docs/policy/` templates
 

package/assets/starter/AGENTS.template.md

@@ -11,40 +11,35 @@
 1. All Markdown files under `docs/policy/**/*.md`, including files in
    subdirectories and symlinked shared-rule files.
 2. `docs/governance/boundary.md`
-3. `docs/governance/ssot-v0.9.md`
-4. `docs/governance/doc-agent-rules.md`
-5. `docs/governance/doc-types.md`
-6. The selected agents routing file:
+3. The selected agents routing file:
    - `docs/governance/agents-routing/engineering-runtime-v0.9.md`, or
    - `docs/governance/agents-routing/doc-only-v0.9.md`
-7. `docs/reference/execution/current-work.md`
-8. Before non-trivial implementation, debugging, release, architecture, or
+4. `docs/reference/execution/current-work.md`
+5. Before non-trivial implementation, debugging, release, architecture, or
    migration work, run `pro-gov learn recall --query "<task summary>"` and read
    any relevant prior-learning hits before changing files.
 
+When the task creates, edits, moves, deletes, or governs documentation, also
+read `docs/governance/ssot-v0.9.md`,
+`docs/governance/doc-agent-rules.md`, and `docs/governance/doc-types.md` before
+changing governed files.
+
 ## Governance
 
 - Use doc-gov for governed Markdown.
 - Governed Markdown lives under `docs/**` by default.
 - Product artifacts outside `docs/**` are not governed docs unless this project explicitly opts them in.
 - Before creating docs: `pnpm doc-gov find <topic>`.
-- Before claiming doc work complete:
-  - `pnpm doc-gov router-check`
-  - `pnpm doc-gov check`
-  - `pnpm doc-gov scan --check`
-  - `pnpm doc-gov links`
-  - `pnpm doc-gov audit`
-  - `pnpm doc-gov doctor`
+- Before claiming doc work complete, run `pnpm doc-gov router-check`, `pnpm
+  doc-gov check`, `pnpm doc-gov scan --check`, `pnpm doc-gov links`, `pnpm
+  doc-gov audit`, and `pnpm doc-gov doctor`.
 
 ## Routing
 
 - Name this project's adopted profile: `engineering-runtime` or `doc-only`.
-- Point to the chosen agents-routing file from `docs/governance/agents-routing/`.
-- Codex and this router own normal execution. Optional skills run only when their own narrow trigger directly matches the selected lane.
-- mattpocock/skills may remain available as an unchanged shared toolbox; there is no bootstrap skill or mandatory workflow owner.
-- Before non-trivial work, use Learning Recall. After verified work, use `capture-learning` only when a non-obvious reusable lesson exists.
+- After verified work, use `capture-learning` only when a non-obvious reusable lesson exists.
 - Do not install Stop/SubagentStop workflow reminder hooks.
-- Doc-only projects should say that engineering TDD and Directed Development are not enabled by default.
+- PROFILE_WORKFLOW_NOTE
 
 <!-- PGS-ROUTER:END -->
 

package/assets/starter/docs/governance/agents-routing/doc-only-v0.9.md

@@ -6,7 +6,7 @@ status: stable
 canonical: true
 owner: human
 created: 2026-05-09
-last_reviewed: 2026-05-09
+last_reviewed: 2026-07-12
 domain: agents-routing
 tags:
   - agents-routing
@@ -24,7 +24,7 @@ superseded_by: null
 
 Shared routing algorithm for non-runtime projects such as AI media, IP development, research, and asset governance workspaces.
 
-This route does not use engineering TDD or Directed Development by default.
+This route does not use engineering test workflows by default.
 
 ## Core Flow
 
@@ -51,8 +51,6 @@ flowchart TD
 
 ## Rules
 
-- Do not ask whether the task needs TDD unless the project has actual runtime code.
-- Do not trigger Directed Development unless the project explicitly opts in.
 - Prefer SSOT, provenance, and approval clarity over engineering ceremonies.
 - Use AI-in-the-Loop for evidence: inspect source, change one thing, verify the target document or asset path.
 
@@ -76,8 +74,7 @@ written as Markdown. Governed docs record decisions, plans, references, policies
 and workspace truth. Product artifacts stay in the project package or workbench
 unless the project explicitly opts them into doc-gov.
 
-## External Workflow Boundary
+## Host Adapter Boundary
 
-This route runs before optional skill packs.
 Host-specific adapters such as `CLAUDE.md` may adapt the route for a specific AI
 client, but they must not replace the project `AGENTS.md` route.

package/assets/starter/docs/governance/agents-routing/engineering-runtime-v0.9.md

@@ -32,12 +32,8 @@ This file decides **how to choose a workflow**, not what the project is currentl
 flowchart TD
   A["Task arrives"] --> B["Read project router and current work"]
   B --> C["Classify with local lane profile"]
-  C --> D{"Mixed / cross-domain / interdependent product work?"}
-  D -- "yes" --> E["Use Directed Development to split ordered DD Blocks"]
-  E --> C
-  D -- "no" --> F["Enter local lane"]
-  F --> G["Use a narrowly matched skill only when helpful"]
-  G --> H["Use AI-in-the-Loop evidence cycle"]
+  C --> F["Enter local lane"]
+  F --> H["Use AI-in-the-Loop evidence cycle"]
   H --> I["Record evidence in doc-gov"]
 ```
 
@@ -45,16 +41,6 @@ flowchart TD
 
 Use this router only to pick depth and workflow. Do not use it as a project roadmap.
 
-## DD Trigger
-
-Use Directed Development only when all are true:
-
-- the task is product work
-- it crosses local lanes or shared contracts
-- sequencing risk makes a flat plan unsafe
-
-Do not trigger DD for broad mechanical edits, renames, formatting, or ordinary docs migration.
-
 ## Project-Local Lane Profile
 
 Every engineering project must define its own lane profile in `AGENTS.md` or `docs/policy/best-practice-for-this-project.md`.
@@ -68,12 +54,7 @@ Typical lanes:
 
 But the shared router must not define project-specific lanes.
 
-## External Workflow Boundary
-
-This route runs before optional skill packs such as mattpocock/skills. Skills
-may provide reviews, browser workflows, PRD/issue shaping, or domain-modeling
-artifacts, but their own narrow trigger must match the selected lane. No skill
-pack owns every engineering task.
+## Host Adapter Boundary
 
 Host-specific adapters such as `CLAUDE.md` may adapt the route for a specific AI
 client, but they must not replace the project `AGENTS.md` route.

package/dist/cli.js

@@ -93,6 +93,7 @@ function createNpxSkillsMaintenancePlan(options) {
   if (options.operation === "update") {
     assertNoReportedPartialUpdateFailure(result.stdout, result.stderr);
   }
+  assertNoDeprecatedMattSkills(tempRoot);
   const after = snapshotFiles(tempRoot);
   const changes = diffSnapshots(before, after);
   return {
@@ -117,6 +118,16 @@ ${stderr}`.replace(/\u001B\[[0-?]*[ -/]*[@-~]/g, "");
     throw new Error(`npx skills update reported a partial failure: ${failure[0]}`);
   }
 }
+function assertNoDeprecatedMattSkills(npxRoot) {
+  const lockPath = join3(npxRoot, "skills-lock.json");
+  const lock = JSON.parse(readFileSync2(lockPath, "utf8"));
+  const deprecated = Object.entries(lock.skills ?? {}).filter(
+    ([, entry]) => entry.source === "mattpocock/skills" && entry.skillPath?.startsWith("skills/deprecated/")
+  ).map(([name]) => name).sort();
+  if (deprecated.length > 0) {
+    throw new Error(`npx skills plan contains deprecated mattpocock skills: ${deprecated.join(", ")}`);
+  }
+}
 function assertNativeNpxRoot(npxRoot) {
   if (!existsSync3(join3(npxRoot, "skills-lock.json"))) {
     throw new Error(`npx skills root is missing skills-lock.json: ${npxRoot}`);
@@ -1790,13 +1801,14 @@ function applyStarterFiles(files, profile) {
 }
 function renderAgentsTemplate(template, projectName, profile) {
   const selectedRoute = `docs/governance/agents-routing/${profile}-v0.9.md`;
+  const profileWorkflowNote = profile === "doc-only" ? "- Engineering test workflows are not enabled by default for this doc-only project." : "";
   return template.replace("# PROJECT_NAME AI Router", `# ${projectName} AI Router`).replace(
-    /6\. The selected agents routing file:\n   - `docs\/governance\/agents-routing\/engineering-runtime-v0\.9\.md`, or\n   - `docs\/governance\/agents-routing\/doc-only-v0\.9\.md`/,
-    `6. The selected agents routing file: \`${selectedRoute}\``
+    /\d+\. The selected agents routing file:\n   - `docs\/governance\/agents-routing\/engineering-runtime-v0\.9\.md`, or\n   - `docs\/governance\/agents-routing\/doc-only-v0\.9\.md`/,
+    `3. The selected agents routing file: \`${selectedRoute}\``
   ).replace(
     "- Name this project's adopted profile: `engineering-runtime` or `doc-only`.",
     `- This project adopts the \`${profile}\` profile.`
-  );
+  ).replace("- PROFILE_WORKFLOW_NOTE", profileWorkflowNote).replace(/\n{3,}/g, "\n\n");
 }
 function readFlag(args, flag) {
   const index = args.indexOf(flag);
@@ -2441,6 +2453,10 @@ function formatProjectLensAuditCheckText(result) {
 function formatProjectLensInspection(report) {
   return [
     `target: ${report.targetDir}`,
+    `scan-scope: ${report.scanScope.mode}`,
+    `candidate-files: ${report.scanScope.candidateFileCount}`,
+    `included-files: ${report.scanScope.includedFileCount}`,
+    `excluded-files: ${report.scanScope.excludedFileCount}`,
     `ai-entry-files: ${formatList(report.aiEntryFiles)}`,
     `ai-config-files: ${formatList(report.aiConfigFiles)}`,
     `package-scripts: ${formatList(report.packageJson?.scripts ?? [])}`,
@@ -2462,6 +2478,10 @@ function renderProjectLensMarkdownReport(report) {
     `- Target: \`${report.targetDir}\``,
     `- Generated: ${(/* @__PURE__ */ new Date()).toISOString()}`,
     "- Scope: local read-only evidence for AI-assisted project review",
+    `- Evidence mode: ${report.scanScope.mode}`,
+    `- Candidate files: ${report.scanScope.candidateFileCount}`,
+    `- Included files: ${report.scanScope.includedFileCount}`,
+    `- Excluded vendor/cache files: ${report.scanScope.excludedFileCount}`,
     "",
     "## AI Entry Files",
     "",
@@ -2522,11 +2542,20 @@ var ignoredDirectories = /* @__PURE__ */ new Set([
 ]);
 function scanProjectLensTarget(targetDir, options = {}) {
   const largeFileBytes = options.largeFileBytes ?? 5e4;
-  const files = listProjectFiles(targetDir);
-  const markdownFiles = files.filter((file) => file.endsWith(".md"));
+  const candidateFiles = listProjectFiles(targetDir);
+  const files = candidateFiles.filter(isFirstPartyEvidenceFile);
+  const markdownFiles = files.filter(
+    (file) => file.startsWith("docs/") && file.endsWith(".md")
+  );
   const packageJson = readPackageJson(targetDir);
   return {
     targetDir,
+    scanScope: {
+      mode: "first-party",
+      candidateFileCount: candidateFiles.length,
+      includedFileCount: files.length,
+      excludedFileCount: candidateFiles.length - files.length
+    },
     aiEntryFiles: ["AGENTS.md", "CLAUDE.md"].filter(
       (file) => existsSync17(join17(targetDir, file))
     ),
@@ -2575,10 +2604,31 @@ function runGit(targetDir, args) {
   return { ok: true, stdout: result.stdout.trim() };
 }
 function listProjectFiles(targetDir) {
+  const gitFiles = runGit(targetDir, [
+    "ls-files",
+    "--cached",
+    "--others",
+    "--exclude-standard",
+    "-z"
+  ]);
+  if (gitFiles.ok) {
+    return gitFiles.stdout.split("\0").filter(Boolean).map(toUnixPath4).filter((file) => existsSync17(join17(targetDir, file))).sort();
+  }
   const files = [];
   collectFiles2(targetDir, targetDir, files);
   return files.sort();
 }
+var excludedEvidencePrefixes = [
+  ".agents/manual-skills/",
+  ".agents/skills/",
+  "agent-assets/skills/npx-skills/",
+  "third-party/",
+  "third_party/",
+  "vendor/"
+];
+function isFirstPartyEvidenceFile(file) {
+  return !excludedEvidencePrefixes.some((prefix) => file.startsWith(prefix));
+}
 function collectFiles2(rootDir, currentDir, files) {
   if (!existsSync17(currentDir)) return;
   for (const entry of readdirSync7(currentDir, { withFileTypes: true })) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pieai/pro-gov",
-  "version": "0.4.4",
+  "version": "0.4.6",
   "description": "Project-level distribution kit for Project Governance System.",
   "keywords": [
     "ai-agents",
@@ -35,7 +35,7 @@
     "access": "public"
   },
   "dependencies": {
-    "@pieai/doc-gov": "^0.4.4"
+    "@pieai/doc-gov": "^0.4.6"
   },
   "devDependencies": {
     "@types/node": "24.13.2",

package/assets/docs/reference/adoption/agent-workflow-methodology-comparison.md

@@ -1,339 +0,0 @@
----
-id: REF-AGENT-WORKFLOW-METHODOLOGY-COMPARISON
-title: Agent Workflow Methodology Comparison
-type: reference
-status: superseded
-canonical: false
-owner: project
-created: 2026-07-06
-last_reviewed: 2026-07-06
-domain: adoption
-tags:
-  - agent-workflows
-  - superpowers
-  - compound-engineering
-  - mattpocock-skills
-  - wayfinder
-pinned: false
-related:
-  - REF-PUBLIC-RELEASE-CHECKLIST
-  - REF-DOWNSTREAM-PROJECT-REGISTRY
-superseded_by: REF-RECOMMENDED-AGENT-TOOLING
----
-
-# Agent Workflow Methodology Comparison
-
-> Historical snapshot only. The current decision is documented in
-> [Recommended Agent Tooling](recommended-agent-tooling.md): Superpowers,
-> Compound Engineering, and Ponytail are retired from the installed PGS stack;
-> Matt skills remain a trigger-based library, and `capture-learning` preserves
-> the small reusable-learning loop. The older analysis below is retained as
-> decision history, not current guidance.
-
-本文比较 4 套 AI agent 工作方法，观察时间点是 2026-07-06：
-
-1. **Superpowers**
-2. **Compound Engineering**
-3. **Matt Pocock skills 主流程**
-4. **Matt Pocock Wayfinder**
-
-小学生版本：这 4 套东西都不是“更聪明的魔法咒语”。它们更像 4 个不同的帮手。
-
-- Superpowers 像工地施工队长。
-- Compound Engineering 像厨师的复盘菜谱本。
-- Matt 主流程像采访员、产品经理、拆票员三个人排队帮你。
-- Wayfinder 像走进大雾森林前的画地图的人。
-
-## 版本和证据
-
-这是一个时间点快照，不是永久真理。Wayfinder 现在变化尤其快。
-
-| 系统 | 本次观察到的版本或来源 | 证据 |
-| --- | --- | --- |
-| PGS | 本地 package 版本 `0.4.0` | `package.json`，2026-07-06 检查 |
-| Superpowers | 本机 Codex 插件 `6.1.1` | 本地 `.codex/plugins/cache/superpowers-dev/superpowers/6.1.1`；上游项目：[obra/superpowers](https://github.com/obra/superpowers) |
-| Compound Engineering | 本机插件 `3.18.0` | 本地 `.codex/plugins/cache/compound-engineering-plugin/compound-engineering/3.18.0`；上游项目：[EveryInc/compound-engineering-plugin](https://github.com/EveryInc/compound-engineering-plugin) |
-| Matt Pocock skills | PGS 本地 lock 记录 GitHub 来源和 hash，不记录 semver | 上游项目：[mattpocock/skills](https://github.com/mattpocock/skills)；Skill Vault 在 2026-07-05 显示 `1.0.31`、commit `66f92b6` |
-| Wayfinder | 属于 `mattpocock/skills`，2026-07-06 仍在 `skills/in-progress/wayfinder` | 上游文件：[Wayfinder SKILL.md](https://github.com/mattpocock/skills/blob/main/skills/in-progress/wayfinder/SKILL.md)；GitHub Actions 显示 Wayfinder 已连续多次发布到 Release #46 |
-
-重要提醒：PGS 本地 `wayfinder` 已在 2026-07-07 通过 `pro-gov assets npx update --skill wayfinder --plan` 更新到包含 **"Plan, don't do"** 和 destination 说明的新版。Wayfinder 仍处在高流动期，后续如果继续升级，需要重新复查这篇文档。
-
-## 一句话结论
-
-PGS 最稳的组合是：
-
-- **Superpowers** 继续当默认工程流程负责人。
-- **Compound Engineering** 继续当默认复利记录和经验沉淀工具。
-- **Matt 主流程** 用在“想法还模糊，需要问清楚、写 PRD、拆 issue”的时候。
-- **Wayfinder** 只用在“大到一个 session 装不下、前路还在雾里”的任务上。
-
-Wayfinder 暂时不应该自动启动。它很有潜力，但现在更像侦察兵，不像自动驾驶车。要用它，最好满足 4 个条件：用户明确叫它、目的地说清楚、issue tracker 支持它的地图/子票规则、关键节点有人类确认。
-
-## 两个贯穿例子
-
-为了更好懂，下面一直用两个例子：
-
-- **小安要开发一个 App。** 可能只是一个习惯打卡小工具，也可能是一个很大的 EMS 管理系统。
-- **小宁要写一本小说。** 可能只是一本短篇推理，也可能是一个多卷本奇幻系列。
-
-## Superpowers：工地施工队长
-
-Superpowers 像工地施工队长。施工队长不会一上来就让人搬砖。他会先问：要建什么？图纸在哪里？怎么验收？有没有安全检查？
-
-小安做 App 时，Superpowers 会帮：
-
-- 问清楚这个功能到底要解决什么问题。
-- 写计划。
-- 尽量用 TDD，先写测试再实现。
-- 完工前检查测试、review、分支状态。
-
-小宁写小说时，Superpowers 也能帮一点，比如安排写作计划。但它脑子里更多是“软件工程施工”。如果小宁只是想探索人物和情绪，Superpowers 可能显得有点硬。
-
-最适合：工程实现、调 bug、测试验证、分支收尾。
-
-PGS 判断：Superpowers 继续做默认工程流程负责人。PGS 已在 [integrations/superpowers.md](../../../integrations/superpowers.md) 里这样定位。
-
-## Compound Engineering：厨师的复盘菜谱本
-
-Compound Engineering 像厨师的菜谱本。厨师这次做菜发现“火候应该小一点”“这个酱汁可以提前一天做”，就记下来。下次做同类菜，就不用重新踩坑。
-
-小安做 App 时，CE 会帮：
-
-- 修完一个难部署 bug 后，把可复用经验记下来。
-- 下次遇到类似问题，AI 可以先读以前的经验。
-- CE 也有计划、review、debug 等完整流程，但 PGS 默认不让它接管整条开发线。
-
-小宁写小说时，CE 可以记录写作经验，比如“多卷本小说需要先做时间线表”。但如果只是自由创作，完整 CE 流程可能也会显得太工程化。
-
-最适合：把一次工作变成下一次工作的优势。
-
-PGS 判断：默认只用 **Compound Gate** 做经验沉淀。完整 CE 流程必须用户明确要求。见 [integrations/compound-engineering.md](../../../integrations/compound-engineering.md)。
-
-## Matt 主流程：采访员 + 产品经理 + 拆票员
-
-Matt 主流程像 3 个人接力：
-
-1. 采访员先不停追问，把模糊想法问清楚。
-2. 产品经理把答案整理成 PRD。
-3. 拆票员把 PRD 切成一个个能独立完成的小 issue。
-
-小安做 App 时：
-
-- `/grill-with-docs` 像采访员，边问边更新项目上下文。
-- `/to-prd` 像产品经理，把讨论整理成 PRD。
-- `/to-issues` 像拆票员，把 PRD 拆成竖切 issue。
-- `/implement` 像工程执行员，拿一个 issue 做 TDD、review、commit。
-
-小宁写小说时：
-
-- `/grill-me` 可以问清楚题材、主角、冲突、结尾。
-- `/to-prd` 可以变成故事圣经或写作 brief。
-- `/to-issues` 可以变成章节卡、设定任务、资料研究任务。
-- 但它的形状还是偏“产品开发”，所以对纯文学创作可能有点像用项目管理工具写诗。
-
-最适合：把模糊需求变成可保存、可拆分、可执行的东西。
-
-PGS 判断：Matt skills 可以完整安装、原样使用，但它产生的原生产物不应该被 PGS 乱改。PGS 不应该为了 Doc Gov 给它的产物硬加 frontmatter。正确做法是：Matt 产物保留原味；只有当人明确决定“这个东西要升级为 PGS 治理真相”时，才另建或更新 PGS 文档。见 [integrations/mattpocock-skills.md](../../../integrations/mattpocock-skills.md)。
-
-## Wayfinder：大雾森林里的画地图的人
-
-Wayfinder 像你站在一片大雾森林前。你知道森林另一边可能有城堡，但不知道路在哪里，也不知道哪些桥断了。这时最聪明的事不是冲进去盖房子，而是先画地图。
-
-小安做一个小习惯 App：
-
-- 不建议用 Wayfinder。太重了。Matt 主流程或 Superpowers 就够。
-
-小安做一个大型 EMS 系统：
-
-- Wayfinder 可以创建一个 map issue。
-- 然后创建子票，比如“决定权限模型”“研究 EMS 审计要求”“原型验证派单时间线 UI”“追问升级规则”。
-- 每个 session 只解决一个票，把答案记回地图。
-
-小宁写短篇推理：
-
-- 一般不需要 Wayfinder。
-
-小宁写多卷奇幻系列：
-
-- Wayfinder 很可能有用。它可以画出“魔法规则是否影响经济”“第二卷由谁推动主线”“结局前必须先决定哪些世界观问题”等地图。
-- 每张票解决一个大问题。
-
-最适合：很大、很模糊、一个 session 装不下、下一步不清楚的工作。
-
-PGS 判断：Wayfinder 只能显式调用。用户说 `/wayfinder`，或者清楚表达“我要为一个大而不清楚的任务画地图”，再用。
-
-## 总对比表
-
-| 维度 | Superpowers | Compound Engineering | Matt 主流程 | Wayfinder |
-| --- | --- | --- | --- | --- |
-| 小学生比喻 | 施工队长 | 复盘菜谱本 | 采访员 + 产品经理 + 拆票员 | 大雾地图师 |
-| 主要工作 | 把代码小心做出来 | 让下一次工作更容易 | 把想法变成 PRD / issue / code | 在未知里找到路线 |
-| 最适合规模 | 小到大的工程任务 | 重复出现的工程经验 | 中等复杂产品/功能 | 超大、模糊、多 session |
-| 主要产物 | 计划、测试、review、分支收尾 | `docs/solutions/**` 等经验文档 | `CONTEXT.md`、ADR、PRD、issue | 一个 map issue + 多个 child ticket |
-| 如何启动 | skill routing / session startup | 显式 CE skill 或 PGS Compound Gate | 通常显式 slash command | 显式 `/wayfinder` |
-| 人类角色 | 批准计划和关键选择 | 判断什么值得沉淀 | 回答采访、批准 issue 颗粒度 | 批准目的地、地图、下一步 |
-| 自主程度 | 中等 | PGS 默认低；完整 CE 时较高 | 中等 | 如果不设边界会偏高 |
-| 停止条件 | 测试、review、分支完成 | 学习记录完成或跳过 | PRD / issue / implementation 完成 | 路线清楚，没有更多必须先决定的问题 |
-| 最大优点 | 工程纪律强 | 真正复利 | 需求澄清和竖切很强 | 不假装大雾已经清楚 |
-| 最大风险 | 小任务可能仪式太重 | 用多了会变流程负担 | 可能偏重、偏线性 | 可能造太多票，或选错下一步 |
-| PGS 默认态度 | 默认工程负责人 | 默认复利尾巴 | 可选工具箱 | 显式侦察兵 |
-
-## 外部证据和评论
-
-### Wayfinder
-
-一手来源：Wayfinder 自己说，它处理的是“一个 session 太大、路还在雾里”的工作。它会在 issue tracker 上建共享地图，然后一个 ticket 一个 ticket 解决，直到目的地路线清楚。最新版上游还明确说默认是 **Plan, don't do**：默认产出决策，不产出最终交付物，除非 map Notes 明确允许执行。来源：[Wayfinder SKILL.md](https://github.com/mattpocock/skills/blob/main/skills/in-progress/wayfinder/SKILL.md)。
-
-GitHub Actions 显示 Wayfinder 近期更新非常密集，包括 destination/purpose、deferred section、native blocking、assignment claiming、plan big work 等。来源：[mattpocock/skills Actions](https://github.com/mattpocock/skills/actions)。
-
-GitHub issue #450 报告了一个真实风险：Wayfinder 在 work-through-map 时没有充分追问资源冲突，导致一个部署任务影响了另一个已存在服务。来源：[Issue #450](https://github.com/mattpocock/skills/issues/450)。
-
-用户提供的 2026-07-06 X 截图也显示两面性：有人觉得 Wayfinder 很震撼，但也观察到它可能继续执行错误的下一张票；Matt 回复说这不应该发生，听起来像 bug。这个证据说明：它很有潜力，但还不能当稳定自动驾驶。
-
-PGS 解释：Wayfinder 是侦察兵，不是总司令。
-
-### Matt 主流程
-
-一手来源：Matt README 说这些 skills 是小而可组合、可改造、用于真实工程，不是 vibe coding。它把 `/grill-with-docs`、`CONTEXT.md`、`/to-prd`、`/to-issues`、`/tdd`、`/code-review` 组合成一个流程。来源：[mattpocock/skills](https://github.com/mattpocock/skills)。
-
-公开 `to-issues` 指南说，它会把 PRD 拆成可独立抓取的竖切 issue，并让用户批准颗粒度和依赖。来源：[AI Hero to-issues guide](https://www.aihero.dev/skills-to-issues)。
-
-外部评论是“有用但可能重”。有 Reddit 用户说 Matt 风格的 GitHub issues / TDD / audit loop 质量好，但也担心每个小 issue 都耗时较多。来源：[Reddit discussion](https://www.reddit.com/r/PiCodingAgent/comments/1t2tm5c/am_i_overengineering_matt_pococks_ai_coding/)。
-
-另一个公开写法认为，这套流程适合触达多个模块的 feature/refactor，但不能替代人的判断。来源：[Danny Shmueli writeup](https://dannyshmueli.com/2026/04/29/Matt-Pocock-Skills-Hermes-Subagents-Feature-Work/)。
-
-PGS 解释：Matt 主流程适合“把话问明白、把需求切小”。但不要为了治理洁癖去改它原生输出。
-
-### Superpowers
-
-一手来源：Superpowers 自称是基于 composable skills 和启动指令的软件开发方法论，覆盖 brainstorming、worktree、planning、subagent execution、TDD、debugging、review、verification。来源：[obra/superpowers](https://github.com/obra/superpowers)。
-
-Superpowers 6 发布说明称，它在作者测试中更快、更省 token，并支持或改进了多个 coding agent，包括 Codex。来源：[Superpowers 6 announcement](https://blog.fsck.com/2026/06/15/Superpowers-6/)。
-
-社区评论也分两面。有些用户喜欢它前半段：澄清假设、写 spec、识别风险、做计划。也有人认为它对小任务会太重，甚至更耗用量。来源：[Reddit ClaudeCode thread](https://www.reddit.com/r/ClaudeCode/comments/1uk7dzk/fable_5_and_superpowers_plugin/) 和 [Reddit Codex thread](https://www.reddit.com/r/codex/comments/1sp7di6/have_any_of_you_guys_been_using_the_superpower/)。
-
-PGS 解释：Superpowers 仍然是最适合当默认工程负责人的，因为它端到端纪律强。但 PGS 需要保留轻量路径，小事不要被拖进大仪式。
-
-### Compound Engineering
-
-一手来源：CE 插件强调“每一次工程工作都应该让下一次更容易”，提供 `/ce-brainstorm`、`/ce-plan`、`/ce-code-review`、`/ce-compound` 等技能。来源：[EveryInc/compound-engineering-plugin](https://github.com/EveryInc/compound-engineering-plugin)。
-
-Every 的 Compound Engineering 指南强调 safety nets、agent-native environment、parallel work、plan as artifact。来源：[Compound Engineering guide](https://every.to/guides/compound-engineering)。
-
-Will Larson 的评论认为它是一个便宜、有用、值得试的实验，同时也提醒有些实践未来可能会被 agent harness 吸收。来源：[Lethain review](https://lethain.com/everyinc-compound-engineering/)。
-
-PGS 解释：CE 最珍贵的是“把经验留下来”。但如果 CE 和 Superpowers 同时想当整个流程的老板，AI 就像同时听两个教练喊口令，会乱。PGS 因此让 Superpowers 默认负责施工，让 CE 默认负责复盘。
-
-## 用 Loopy 外骨骼检查
-
-`loopy` 技能说，一个好 loop 应该有 6 步：观察、选择、行动、验证、记录、重复或停止。它还要求有明确终点，比如成功、阻塞、需要批准、用尽、停滞。
-
-把 4 套方法放进去看：
-
-| 系统 | 观察 | 选择 | 行动 | 验证 | 记录 | 停止 |
-| --- | --- | --- | --- | --- | --- | --- |
-| Superpowers | 强：会问、会读代码 | 强：会写计划 | 强：会实现 | 强：测试/review | 中：计划和 review 记录 | 强，但要真的跑验证 |
-| CE | 中：读任务上下文 | 中：CE plan/review | 中：可执行但 PGS 默认不用 | 中：review/check | 强：复利文档 | capture 很清楚，完整流程较重 |
-| Matt 主流程 | 强：grilling/docs | 强：PRD/issues | 强：implement | 强：TDD/code review | 强：context/ADR/PRD/issues | 中：依赖 smart context hygiene |
-| Wayfinder | 强：map/fog/tickets | 如果 frontier 对，就强 | 默认低：应该 plan，不应该 do | 中：依赖 ticket resolution 质量 | 强：map 和 resolution comments | 需要特别小心：一 session 一票 |
-
-Loopy 角度的 PGS 结论：Wayfinder 最大问题不是“不聪明”，而是“权限和刹车”。地图必须写清楚什么时候问人、什么时候停、什么时候绝对不执行。
-
-## 五轮真实评估迭代
-
-### 第 1 轮：先看 PGS 边界
-
-问题：PGS 能不能引入 Wayfinder，而不让 4 套方法互相打架？
-
-判断：可以，但每套方法要分工清楚。
-
-- Superpowers 负责默认工程施工。
-- CE 负责默认经验复利。
-- Matt 主流程负责需求澄清、PRD、issue 拆分。
-- Wayfinder 负责大雾任务的地图。
-
-我否掉的方案：让 Wayfinder 自动替代 Matt 旧流程。这太激进，像把整个施工队换成一张地图。
-
-### 第 2 轮：看 Wayfinder 上游原意
-
-问题：Wayfinder 自己到底说它是什么？
-
-判断：它不是更强的 `/implement`。它更像“路线发现”和“决策地图”。上游最新版还明确写了默认 plan，不默认 do。
-
-这改变了推荐：Wayfinder 不应该直接拿来替代实现流程。
-
-### 第 3 轮：看外部评论是不是只有夸
-
-问题：大家是在无脑夸，还是有真实问题？
-
-判断：两者都有。
-
-- 夸：有人觉得它能做以前不敢交给 AI 的大规划。
-- 风险：GitHub issue #450 和用户截图都说明，它可能在下一步选择或冲突追问上出错。
-
-这让 PGS 不应该过早自动化采用。
-
-### 第 4 轮：用 Loopy 查循环质量
-
-问题：4 套方法哪个循环最完整？
-
-判断：
-
-- Superpowers 和 Matt 主流程的“构建循环”更成熟。
-- CE 的“记录/复利循环”最强。
-- Wayfinder 的“观察/记录”很强，但“谁决定下一步”和“什么时候停止”需要额外护栏。
-
-结论：Wayfinder 必须一 session 一票，chart map 后要人工确认，默认只做决策，不做执行。
-
-### 第 5 轮：看 PGS 最小采用方式
-
-问题：最小、稳妥、有价值的采用方式是什么？
-
-判断：先写边界文档，不急着改运行规则。
-
-如果后续要真正 operationalize Wayfinder，需要：
-
-1. 保持 Matt skill pack 更新到包含最新版 Wayfinder 文案的版本。
-2. 保持 PGS 中央 `docs/agents/issue-tracker.md` 有 Wayfinding operations。
-3. 保持 Matt 原生产物不被 PGS 修改。
-4. Doc Gov 继续忽略 Matt 原生产物，除非人工提升为治理文档。
-5. 本地主控 AI 保留最终 merge / commit / push 权限。
-
-## PGS 推荐路由
-
-| 场景 | 推荐用什么 |
-| --- | --- |
-| 小而明确的代码修复 | Superpowers，必要时直接 TDD |
-| 难 bug | Superpowers systematic debugging；有复用经验再 CE capture |
-| 现有 repo 里的模糊功能想法 | Matt `/grill-with-docs`，然后可能 `/to-prd`、`/to-issues` |
-| 已经有 PRD，需要拆票 | Matt `/to-issues` |
-| 单个 issue 要实现 | Matt `/implement` 或 Superpowers 实现流程，看用户怎么叫 |
-| 巨大、模糊、多 session 的任务 | Wayfinder |
-| 工作结束后有可复用经验 | CE `/ce-compound` 或 PGS fallback capture |
-| 小说、课程、非代码创作 | Matt grilling 或 Wayfinder；不要默认套 Superpowers 工程仪式 |
-
-## 采用 Wayfinder 的护栏
-
-如果 PGS 以后真正启用 Wayfinder，请保留这些护栏：
-
-1. **只能显式启动。** 用户说 `/wayfinder`，或清楚要求“给大任务画地图”。
-2. **必须说清目的地。** 没有目的地的地图，只是一堆便利贴。
-3. **一个 session 只解决一张票。** 这样不会跑飞，也保护上下文。
-4. **默认只计划，不执行。** 除非 map Notes 明确写这个 effort 包含执行。
-5. **第一次 chart map 后要人工确认。** 不要一口气造几十张票然后自动往下冲。
-6. **Matt 原生产物保持原味。** 不要为了 PGS Doc Gov 给 map tickets、PRD、scratch、context docs 硬加 frontmatter。
-7. **要升级为 PGS 真相时，另行提升。** 也就是新建或更新受治理的 PGS 文档，而不是改原生产物。
-8. **issue tracker 必须保留规则。** PGS 中央的 `docs/agents/issue-tracker.md` 必须包含 Wayfinding operations；正式跑之前先检查它还在。
-
-## 最终建议
-
-PGS 应该支持 Wayfinder，但不要把它封王。
-
-最好的搭配是：
-
-- **Superpowers**：平时工程施工。
-- **Matt 主流程**：把模糊想法问清楚、写成 PRD、拆成 issue。
-- **Wayfinder**：遇到巨大迷雾任务时先画地图。
-- **CE**：工作结束后把可复用经验存下来。
-
-用小孩能懂的话说：Superpowers 帮你盖树屋，Matt 主流程问清楚你想要什么树屋，Wayfinder 在你连哪棵树能爬都不知道时先画森林地图，CE 把“梯子怎么做更结实”记进小本本，下次少摔一次。

package/assets/integrations/compound-engineering.md

@@ -1,11 +0,0 @@
-# Compound Engineering Integration (Retired)
-
-PGS no longer requires the Compound Engineering plugin or a Compound Gate.
-
-The retained idea is small: verified work sometimes produces a reusable lesson.
-The PGS-owned `capture-learning` skill decides whether a lesson is worth keeping,
-checks for duplicates, and writes it through `pro-gov learn capture`. There are
-no Stop hooks, modes, plugin configuration, or mandatory final-report ceremony.
-
-Historical `docs/solutions/**` records remain valid inputs to
-`pro-gov learn recall`.

package/assets/integrations/directed-development.md

@@ -1,44 +0,0 @@
-# Directed Development Integration
-
-Directed Development is an optional workflow for mixed, cross-domain, interdependent product work.
-
-It is not the default for every task.
-
-It is a small PGS routing rule for cases where product work must be split into
-ordered dependency-aware Blocks before execution.
-
-## Boundary
-
-Directed Development may define:
-
-- ordered DD Blocks
-- dependencies between Blocks
-- BDD-style acceptance scenarios
-- verification gates
-
-Directed Development must not define:
-
-- artifact locations
-- optional skill invocation rules
-- project document paths
-- project lane names
-- runtime truth
-
-Those remain owned by the project and doc-gov.
-
-Agents routing decides whether this workflow applies. Directed Development does
-not replace the project router.
-
-BDD-style scenarios are allowed only as acceptance language for a DD Block. They
-do not turn Directed Development into a default BDD ceremony and do not replace
-project-specific testing, debugging, or verification.
-
-## Trigger
-
-Use Directed Development only when all are true:
-
-- the task is product work
-- it crosses local lanes or shared contracts
-- sequencing risk makes a flat plan unsafe
-
-Doc-only projects do not use Directed Development unless explicitly opted in.

package/assets/integrations/ponytail.md

@@ -1,9 +0,0 @@
-# Ponytail Integration (Retired)
-
-PGS no longer requires or configures the Ponytail plugin.
-
-Prefer the smallest correct implementation, reuse mature tools, and avoid
-speculative abstractions as ordinary engineering judgment. A global mode and
-prompt/session hooks are unnecessary for those principles.
-
-This file remains only as a stable target for historical links.

package/assets/integrations/superpowers.md

@@ -1,12 +0,0 @@
-# Superpowers Integration (Retired)
-
-PGS no longer requires or routes through the Superpowers plugin.
-
-The useful principles—understand before editing, diagnose root causes, verify
-before claiming completion, and use tests proportionate to risk—are already part
-of Codex and project-level engineering rules. Keeping a mandatory bootstrap
-workflow duplicated those responsibilities and made small tasks unnecessarily
-ceremonial.
-
-This file remains only so historical decisions and links have a stable target.
-Do not add Superpowers startup instructions or make it a portfolio requirement.