@pieai/pro-gov 0.4.3 → 0.4.5

package/README.md

@@ -9,10 +9,10 @@ Think of Project Governance System as a librarian, traffic desk, and inspection
 station:
 
 - `pro-gov` shows which reusable project-governance parts are present or missing;
-- `@pieai/doc-gov` checks documents, routing, links, hooks, and CI;
-- Superpowers may provide the engineering process;
-- Compound Engineering may provide the post-work learning capture tail;
-- Ponytail may provide an optional simplicity review.
+- `@pieai/doc-gov` checks documents, routing, links, guardrails, and CI;
+- the AI host and project checks own normal execution;
+- optional Matt skills trigger only when their narrow descriptions match;
+- `capture-learning` records a reusable lesson only when one exists.
 
 The current `pro-gov` release is conservative by design. Public init and sync
 commands inspect and compare; they do not silently overwrite another project's
@@ -53,7 +53,6 @@ pro-gov init --profile engineering-runtime --dry-run
 pro-gov init --profile engineering-runtime --apply
 pro-gov init --profile doc-only --dry-run
 pro-gov sync --check --profile engineering-runtime
-pro-gov sync --apply-host-hooks --profile engineering-runtime
 pro-gov doctor
 ```
 
@@ -73,7 +72,6 @@ What these commands do:
 | `init --dry-run` | Shows starter/profile files that would be needed. | No |
 | `init --apply` | Installs one profile into a fresh target; refuses the whole operation if any target file exists. Optional CI and Lefthook references are not installed. | Yes |
 | `sync --check` | Strictly compares shared core files, checks project-local seeds for presence, and leaves optional guardrail contents consumer-owned. | No |
-| `sync --apply-host-hooks` | Merges current PGS Compound Gate entries into engineering-runtime host configs while preserving consumer-owned keys and hooks. | Only the three host config files |
 | `doctor` | Checks required packaged assets and whether `doc-gov` is available. | No |
 
 ## Full Checkout Commands
@@ -129,71 +127,31 @@ the private-source and public-copy hashes recorded during promotion.
   reviewable plan in a full upstream checkout.
 - `pro-gov lens inspect|report` provides read-only inspection and an explicit
   report output.
-- `doc-gov` remains the document, router, manifest, link, hook, CI, and migration
+- `doc-gov` remains the document, router, manifest, link, CI, and migration
   validator.
 - Product truth stays in the target project.
 - `pro-gov init --apply` is intentionally fresh-target only. Existing projects
   use `--dry-run` and a deliberate migration so local truth is never overwritten.
-- Superpowers, Compound Engineering, and Ponytail are external tools, not
-  bundled runtime dependencies.
+- PGS does not require or bootstrap a workflow plugin.
 - Optional `hostTooling` entries let `portfolio doctor` verify required Codex or
   Claude Code plugins. PGS does not install or upgrade those plugins.
 
-## Recommended Companion Tools
+## Lightweight Agent Workflow
 
-Superpowers is recommended for engineering/runtime projects that need
-brainstorming, plans, TDD, debugging, verification, and worktree discipline.
+The AI host and the target project's proof commands own ordinary work. Matt
+Pocock's skills may be exposed as an optional unchanged library; each skill
+triggers from its own narrow description and does not become a mandatory
+pipeline or workflow owner.
 
-Compound Engineering is recommended for knowledge capture after verified
-engineering work. The default PGS pattern is a Compound Gate: run
-`ce-compound` when there is reusable learning, or report why compounding was
-skipped. Full CE workflows such as `ce-plan`, `ce-work`, and `lfg` remain
-explicit user choices.
-
-PGS Learning Recall is the pre-work companion to that post-work gate. Before
+Before
 non-trivial implementation, debugging, release, architecture, or portfolio-sync
 work, run `pro-gov learn recall --query "<task summary>"` and read relevant
 `docs/solutions/**` or `CONCEPTS.md` hits before changing files.
 
-Engineering-runtime starters include cross-host Stop hooks for Codex,
-Claude Code, and Antigravity. Those hooks call `pro-gov host-hook`. The starter
-default is `--compound-gate-mode off`: wiring is present, but the hook does not
-interrupt the main session. Use `--compound-gate-mode lite` for a short
-exit-door reminder, or `--compound-gate-mode strict` for the older blocking
-gate.
-
-When enabled, the hook expects the final report to include either:
-
-```text
-Compound Gate: ran ce-compound -> <path>
-Compound Gate: ran fallback capture -> <path>
-Compound Gate: skipped -> <reason>
-```
-
-Use `ran fallback capture` only when the Compound Engineering plugin or
-`ce-compound` skill is unavailable in the current host. It writes a minimal
-`docs/solutions/**` learning record through `pro-gov learn capture`; it does
-not replace or copy the full CE workflow.
-
-Use `pro-gov doctor --strict-hooks` after syncing an engineering project to
-verify that the host configs are wired. This is a wiring check: it proves the
-project calls `pro-gov host-hook` for Codex, Claude Code, and Antigravity. The
-host behavior contract is covered by PGS package tests against recorded
-per-host Stop/SubagentStop fixtures. Open a fresh AI session after installing or
-changing hooks; old sessions may not reload host configuration.
-
-Antigravity hook commands enable `PGS_HOST_HOOK_DEBUG=1` by default in PGS
-starters. The hook writes local diagnostics to `.git/pro-gov-hook-debug/` when
-it is actually invoked, including the input summary, decision, and output JSON.
-This directory lives inside Git's private metadata so it does not dirty the
-worktree. If an Antigravity test does not create a diagnostic file, inspect
-whether the host loaded `.agents/hooks.json` before changing PGS policy.
-`.pro-gov/assets.json` is only an asset-install manifest; its `host` field does
-not control runtime hook dispatch.
-
-Ponytail can be installed as an optional complexity adviser. Keep its global mode
-`off`; test `lite` in one isolated task before considering a stronger mode.
-Ponytail must not remove requested scope, tests, safety, accessibility, or proof.
+After verified work, use the small `capture-learning` skill only when the result
+will help future work. It calls `pro-gov learn capture` and writes a compact
+`docs/solutions/**` record. PGS does not install Stop/SubagentStop reminder
+hooks or require a completion ceremony.
 
 Read the
 [full project introduction](https://github.com/PieAIStudio/ProjectGovernanceSystem#readme)

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

@@ -22,11 +22,10 @@ related:
 
 Use this when a project wants to migrate into the Project Governance System.
 
-Before choosing external AI workflow tools, read
+Before choosing optional AI skills, read
 `docs/reference/adoption/recommended-agent-tooling.md`. It explains which PGS
-packages are required, when Superpowers is recommended, how Compound
-Engineering's `ce-compound` fits as a post-work learning tail, and why Ponytail
-should remain globally `off` until it is tested in an isolated task.
+packages are required, how Matt skills remain trigger-based, and how the small
+native learning-capture path works.
 
 ## The Short Version
 
@@ -79,8 +78,7 @@ Current package-based method:
   merge local truth deliberately instead of asking PGS to overwrite it
 - run `pro-gov sync --check --profile <profile>` to compare shared core files;
   project-local router, policy, documentation map, and current-work files are
-  checked for presence rather than byte equality; host configs are compared by
-  PGS-owned entries rather than whole-file equality
+  checked for presence rather than byte equality
 - run `pro-gov assets discover --target <path>` and
   `pro-gov assets recommend --target <path>` to collect local project signals
   and suggested agent-asset bundles without changing the project
@@ -93,20 +91,8 @@ Current package-based method:
 - copy `starter/lefthook.template.yml` to `lefthook.yml` and
   `starter/.github/workflows/docs-check.yml` to `.github/workflows/docs-check.yml`
   when the target project is ready for standard guardrails
-- for an `engineering-runtime` target, install the three host-hook starter files
-  or merge their Stop/SubagentStop entries into the target's existing host
-  config:
-  - `.codex/hooks.json`
-  - `.claude/settings.json`
-  - `.agents/hooks.json`
-- prefer `pro-gov sync --apply-host-hooks --profile engineering-runtime` for
-  that merge; it preserves consumer `PreToolUse`, other events, other top-level
-  keys, and non-PGS Stop/SubagentStop entries
 - run `doc-gov doctor` after wiring guardrails to verify they are actually
   connected
-- run `pro-gov doctor --strict-hooks` after wiring host hooks to prove the
-  target has the expected host-hook configuration for Codex, Claude Code, and
-  Antigravity
 - treat the npm package as the CLI source and the local `docs/governance/`
   files as the project's checked-in governance contract
 
@@ -116,7 +102,6 @@ pnpm pro-gov init --profile engineering-runtime --dry-run
 pnpm pro-gov init --profile engineering-runtime --apply
 pnpm doc-gov scan
 pnpm pro-gov sync --check --profile engineering-runtime
-pnpm pro-gov sync --apply-host-hooks --profile engineering-runtime
 ```
 
 Use `--apply` only for a fresh target. Existing projects normally already own
@@ -211,13 +196,10 @@ The project must define local lanes and proof commands.
 Do not copy the upstream root `integrations/` directory into target projects by default.
 If a project needs local external-workflow guidance, keep it thin in `AGENTS.md` or put project-specific notes under `docs/reference/integrations/`.
 
-For engineering projects, keep Superpowers as the default engineering workflow.
-Use Compound Engineering by default only as the post-work Compound Gate:
-`ce-compound` captures reusable lessons when they exist; otherwise the agent
-reports a skip reason. If the current host cannot load the CE plugin, use
-`pro-gov learn capture` as the fallback capture path and report
-`Compound Gate: ran fallback capture -> <path>`. Full CE workflows require an
-explicit user request.
+For engineering projects, normal execution belongs to the AI host and the
+project's own proof commands. Matt Pocock's skills remain available as a
+lightweight library and trigger only when their narrow descriptions match; they
+are not a mandatory pipeline or workflow owner.
 
 Use PGS Learning Recall before non-trivial work:
 
@@ -225,22 +207,10 @@ Use PGS Learning Recall before non-trivial work:
 pro-gov learn recall --query "<task summary>"
 ```
 
-This reads the project's existing `docs/solutions/**` and `CONCEPTS.md` records
-so prior lessons can shape the work without making Compound Engineering the
-default execution workflow.
-
-The host-hook gate is deliberately small. It does not make Compound Engineering
-the main workflow. Starter hooks default to `--compound-gate-mode off`, so they
-prove the wiring without interrupting the main session. Switch a target to
-`--compound-gate-mode lite` for a short reminder, or `--compound-gate-mode
-strict` when a project intentionally wants the old blocking exit gate. In
-`lite` or `strict`, the hook checks whether a completion report says one of:
-
-```text
-Compound Gate: ran ce-compound -> <path>
-Compound Gate: ran fallback capture -> <path>
-Compound Gate: skipped -> <reason>
-```
+This reads the project's existing `docs/solutions/**` and `CONCEPTS.md` records.
+After verified work, use `capture-learning` only when the result is genuinely
+reusable. The skill calls `pro-gov learn capture`; no exit hook or completion
+ceremony is required.
 
 ### Doc-Only
 
@@ -251,15 +221,9 @@ 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 Superpowers TDD or Directed Development by default.
-
-Do not add the Compound Engineering main workflow by default. If CE is installed
-in the AI host, doc-only projects should use it only for a real reusable
-learning that belongs in that workspace.
-
-Ponytail is also optional. If it is installed, keep its global mode `off` and
-activate it only for a bounded task or review after reading
-`integrations/ponytail.md`.
+Do not add engineering test workflow plugins by default.
+Use `capture-learning` only for a real reusable lesson that belongs in that
+workspace.
 
 ## Step 6: Create Current Work
 
@@ -301,7 +265,7 @@ For the v0.9 structural migration, use
 Minimum:
 
 ```bash
-pnpm pro-gov doctor --strict-hooks
+pnpm pro-gov doctor
 pnpm doc-gov check
 pnpm doc-gov router-check
 pnpm doc-gov scan --check
@@ -311,22 +275,6 @@ pnpm doc-gov doctor
 git diff --check
 ```
 
-Use `pro-gov doctor --strict-hooks` for engineering-runtime projects. Doc-only
-projects may omit strict host hooks unless they intentionally adopt the
-engineering runtime profile.
-
-`pro-gov doctor --strict-hooks` is a wiring check, not a live host simulation.
-It proves the project has hook files that call `pro-gov host-hook`; PGS package
-tests prove the expected Stop/SubagentStop behavior for `off`, `lite`, and
-`strict` modes across the supported host schemas. After installing or changing
-hooks, validate from a fresh AI session.
-For Antigravity, a real invocation writes diagnostics under
-`.git/pro-gov-hook-debug/` because the starter hook command sets
-`PGS_HOST_HOOK_DEBUG=1`. Absence of a diagnostic file after a fresh
-Antigravity session usually means the host did not load or run
-`.agents/hooks.json`. The `.pro-gov/assets.json` `host` field records asset
-placement only; it does not control runtime hook dispatch.
-
 Engineering projects should also run their local verification ladder.
 
 ## Example: Migrating A Runtime Product

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

@@ -6,14 +6,12 @@ status: stable
 canonical: true
 owner: human
 created: 2026-06-21
-last_reviewed: 2026-06-21
+last_reviewed: 2026-07-12
 domain: adoption
 tags:
   - adoption
   - tooling
-  - superpowers
-  - compound-engineering
-  - ponytail
+  - skills
 pinned: false
 related:
   - REF-ADOPTION-PLAYBOOK
@@ -23,130 +21,35 @@ related:
 
 # Recommended Agent Tooling
 
-This page separates what a project needs from what may help it.
+PGS keeps the default path small: Codex and the project router execute normal
+work; tools and skills add capabilities only when their narrow trigger matches.
 
-## The Beginner Version
+| Tool | Default | Purpose |
+| --- | --- | --- |
+| `@pieai/pro-gov` | required | Profiles, assets, learning recall/capture, portfolio checks |
+| `@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 | 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 |
 
-Imagine a school workshop:
-
-- PGS labels the shelves, routes each job, and checks that the record is complete.
-- Superpowers gives the class a reliable build-and-test routine.
-- Compound Engineering keeps the class notebook of hard-won lessons.
-- Ponytail is the adviser who asks, "Can we make this with fewer unnecessary
-  parts?"
-
-Installing every tool does not mean every tool should run all the time.
-
-## Recommendation Table
-
-| Tool | Recommendation | Best fit | Default behavior |
-| --- | --- | --- | --- |
-| `@pieai/pro-gov` | Required for package-based PGS adoption | Projects adopting PGS starter/profile assets | Use its read-only discovery, init, sync, doctor, and Lens commands. |
-| `@pieai/doc-gov` | Required for package-based PGS adoption | All governed PGS projects | Run document, router, manifest, link, hook, and CI checks. |
-| Superpowers | Recommended for engineering/runtime projects | Apps, games, services, browser products, and other code-heavy work | Use the matching workflow when the selected PGS lane requires it. |
-| Compound Engineering | Recommended for knowledge capture | Engineering projects that benefit from reusable learnings | Default to `ce-compound` as the post-work Compound Gate; use full CE workflows only when explicit. |
-| Ponytail | Recommended as an installed, optional adviser | Projects that need help resisting unnecessary complexity | Keep the global mode `off`; activate it explicitly for a bounded task or review. |
-
-## Superpowers
-
-Superpowers owns engineering workflow discipline:
-
-- brainstorming before creative implementation;
-- implementation plans;
-- test-driven development;
-- systematic debugging;
-- verification before completion;
-- isolated worktree usage.
-
-PGS routes the task first. Superpowers then runs inside the selected lane.
-
-Engineering/runtime projects usually benefit from Superpowers. Doc-only
-projects should not inherit the full engineering ceremony unless their current
-task actually involves runtime or code behavior.
-
-Read `integrations/superpowers.md` for the exact boundary.
-
-## Compound Engineering
-
-Compound Engineering is useful for preserving lessons that should make future
-work easier. In PGS-governed projects, its default role is the post-work
-Compound Gate:
-
-```text
-Superpowers completes verified work
--> decide with CE criteria whether reusable learning exists
--> run ce-compound or report a skip reason
--> if CE is unavailable in this host, run pro-gov learn capture as fallback
-```
-
-PGS Learning Recall is the matching pre-work step:
+Before non-trivial work:
 
 ```bash
 pro-gov learn recall --query "<task summary>"
 ```
 
-It searches `docs/solutions/**` and `CONCEPTS.md` so agents can reuse prior
-lessons without making Compound Engineering the default execution workflow.
-
-The fallback path is deliberately smaller than CE:
+After verified work, `capture-learning` first checks for an existing lesson and
+then calls this only when a new reusable lesson exists:
 
 ```bash
 pro-gov learn capture --title "<learning title>" --summary "<reusable lesson>"
 ```
 
-Use it only when the CE plugin or skill is unavailable in the current host. It
-keeps the lesson searchable by Learning Recall without copying CE's full
-workflow into PGS.
-
-Do not make routine tasks choose between Superpowers and Compound Engineering as
-competing default engineering processes. Use CE's full `ce-plan`, `ce-work`, or
-`lfg` flow only when the user explicitly asks for it.
-
-Read `integrations/compound-engineering.md` for artifact ownership and Doc Gov
-compatibility.
-
-## Ponytail
-
-Ponytail advises the AI to prefer smaller, less speculative solutions. That can
-reduce unnecessary code, files, dependencies, and abstractions.
-
-Keep its global mode `off`. When a low-risk task needs a simplicity comparison,
-test `lite` in an isolated session first. Use `full` only as an optional stress
-test after checking that requirements, tests, verification, security,
-accessibility, and durable evidence remain intact.
-
-Ponytail is not a replacement for PGS or Superpowers. Shorter work is valuable
-only when it is still the complete, proven work the project asked for.
-
-Read `integrations/ponytail.md` for the mode policy and comparison protocol.
-
-## A Practical Default
-
-For an engineering/runtime project:
-
-```text
-install PGS packages
--> keep Superpowers available for engineering workflows
--> run pro-gov learn recall before non-trivial work
--> use Compound Engineering's ce-compound as the post-work learning tail
--> install Ponytail but keep global mode off
--> activate Ponytail only when a bounded simplicity review would help
-```
-
-For a doc-only project:
-
-```text
-install PGS packages
--> use doc-only routing and evidence rules
--> add engineering workflow tools only for a real engineering task
--> keep Ponytail optional and off by default
-```
-
-## What PGS Does Not Do
+Do not add Stop/SubagentStop workflow reminder hooks. Verification belongs in
+the task and the project's real command ladder.
 
-PGS does not automatically install, enable, update, or remove these external
-plugins in another person's AI host. It documents the recommended boundary and
-lets each project or user adopt tools deliberately. A user-owned portfolio may
-declare required Codex or Claude Code plugin ids in `hostTooling`; `portfolio
-doctor` then verifies installed/enabled state and reports observed versions.
-The host's native plugin manager remains the installation and update authority.
+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.

package/assets/integrations/mattpocock-skills.md

@@ -1,143 +1,40 @@
 # mattpocock/skills Integration
 
-mattpocock/skills is an external npx skill pack. This repository may install
-the pack unchanged, but it does not vendor, rewrite, or fork the skill bodies.
+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.
 
-## The Beginner Version
+## Trigger Rule
 
-Think of the project as a workshop:
+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.
 
-- PGS is the traffic desk and filing cabinet.
-- Superpowers is the default construction process for engineering work.
-- mattpocock/skills is a set of sharp workshop tools for grilling ideas,
-  modeling domain language, turning decisions into PRDs/issues, and running
-  specific implementation flows.
-- Compound Engineering is the verified-learning notebook written after the work.
+Examples:
 
-Installing a box of tools does not mean every tool runs by itself. PGS decides
-the lane first. Superpowers remains the default engineering workflow. Matt
-skills may add useful artifacts and focused flows when their trigger fits.
+- 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.
 
-## Default Rule
+Skills that require subagents must respect the user's current delegation rule.
 
-For PGS-governed engineering/runtime projects, mattpocock/skills is optional
-capability inside the selected lane. It is not the default workflow owner.
+## Artifact Boundary
 
-Use this order:
+Matt-native artifacts remain external to Doc Gov by default:
 
-1. PGS routes the task and selects the project lane.
-2. For non-trivial engineering work, run Learning Recall.
-3. Superpowers owns the normal engineering workflow when that lane needs one.
-4. Matt skills may run when the user explicitly invokes a Matt flow or when an
-   active Matt flow calls one of its helper skills.
-5. The Compound Gate still runs before final reporting.
+- `CONTEXT.md` and `CONTEXT-MAP.md`;
+- `docs/agents/**` and `docs/adr/**`;
+- `.scratch/**`;
+- GitHub/GitLab issues.
 
-Do not make routine work choose between Superpowers and Matt. The useful split
-is simpler:
+Promote durable truth intentionally into `docs/decisions/**`, `docs/specs/**`,
+`docs/plans/**`, `docs/canon/**`, or `docs/reference/**`.
 
-- Superpowers owns default engineering discipline.
-- Matt owns demand shaping, domain modeling, PRD/issues generation, triage, and
-  explicitly requested Matt implementation flows.
-- CE owns post-work reusable learning.
+## Distribution
 
-## Trigger Boundary
-
-User-invoked Matt skills, such as `/grill-with-docs`, `/to-prd`,
-`/to-issues`, `/implement`, `/triage`, and `/ask-matt`, require an explicit
-user request or an already active Matt flow that named them.
-
-Model-invoked Matt helper skills, such as `domain-modeling`, `tdd`,
-`code-review`, `research`, and `prototype`, may run only when they support the
-current selected lane and do not replace the current workflow owner.
-
-If a Matt helper and a Superpowers skill both fit, keep the current workflow
-owner unless the user explicitly switches. For example:
-
-- normal feature implementation -> Superpowers remains the default;
-- user says `/implement issue 123` -> Matt `/implement` owns that flow;
-- user says "grill this idea and make docs" -> Matt `/grill-with-docs` owns
-  that shaping flow;
-- user says "use CE full workflow" -> CE owns the explicitly requested flow.
-
-## PGS Central Setup
-
-The PGS central repository uses these Matt setup choices:
-
-| Setup item | PGS central value |
-| --- | --- |
-| Issue tracker | GitHub Issues for `PieAIStudio/ProjectGovernanceSystem` |
-| External PRs as request surface | No by default |
-| Triage labels | Default Matt labels: `needs-triage`, `needs-info`, `ready-for-agent`, `ready-for-human`, `wontfix` |
-| Domain docs layout | Single-context: root `CONTEXT.md` and `docs/adr/**` when Matt creates them |
-
-The setup files live under `docs/agents/**`. They are Matt-owned external
-configuration files, not PGS canonical product truth.
-
-## Matt-Owned Artifacts
-
-The following outputs are Matt-owned external artifacts:
-
-| Path or surface | Owner | Rule |
-| --- | --- | --- |
-| `CONTEXT.md` | Matt | Domain glossary/context. Helpful input, not a replacement for `docs/canon/**`. |
-| `CONTEXT-MAP.md` | Matt | Multi-context map when a project opts into that layout. |
-| `docs/agents/**` | Matt | Per-repo Matt setup: issue tracker, triage labels, domain docs. |
-| `docs/adr/**` | Matt | Matt-generated ADRs. Promote manually to `docs/decisions/**` if they become PGS-governed decisions. |
-| `.scratch/**` | Matt | Local issue tracker or temporary work surface. Keep project-specific. |
-| GitHub/GitLab issues | Matt/project | PRDs, issue breakdowns, triage state. They are work-tracking artifacts, not doc-gov records by themselves. |
-
-Doc Gov must ignore `docs/agents/**` and `docs/adr/**` as external artifacts.
-When a Matt artifact becomes durable PGS truth, promote it into the normal
-governed layer:
-
-- decisions -> `docs/decisions/**`
-- specs -> `docs/specs/**`
-- plans -> `docs/plans/**`
-- canon -> `docs/canon/**`
-- references -> `docs/reference/**`
-
-Do not try to make one file satisfy both Matt's native artifact contract and a
-PGS governed document contract.
-
-## Downstream Install Rule
-
-Install or update Matt skills in downstream repositories through the PGS asset
-workflow. Do not run `npx skills add mattpocock/skills` inside every downstream
-project as an unmanaged one-off.
-
-The central intake flow is:
-
-```bash
-pro-gov assets npx add mattpocock/skills --plan --root agent-assets/skills/npx-skills
-```
-
-Review the plan, then install into the PGS central npx skill root. Downstream
-projects receive managed symlinks through the private PGS asset bundle
-`mattpocock-skills` and project-local Matt setup files according to their
-selected profile and host support.
-
-## Verification
-
-Central verification:
-
-```bash
-node packages/doc-gov/dist/cli.js router-check
-node packages/doc-gov/dist/cli.js check
-node packages/doc-gov/dist/cli.js scan --check
-git diff --check
-```
-
-Matt install verification:
-
-```bash
-test -f agent-assets/skills/npx-skills/skills-lock.json
-find agent-assets/skills/npx-skills/.agents/skills -maxdepth 2 -name SKILL.md
-```
-
-Downstream verification must prove:
-
-- the target's project router points to its selected profile;
-- Matt skills are linked from the managed PGS asset source;
-- `docs/agents/**` exists when Matt engineering skills are enabled;
-- Doc Gov ignores Matt-owned external artifacts;
-- Superpowers, Matt, and CE each keep their documented ownership.
+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/profiles/doc-only/manifest.yml

@@ -8,10 +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:
-  compound_engineering: false
-  directed_development: false
-  superpowers: false
 project_local_required:
   - docs/policy/best-practice-for-this-project.md
   - canon/provenance/approval boundaries
@@ -19,5 +15,4 @@ project_local_required:
 not_included:
   - engineering-runtime agents routing
   - behavior-critical code lanes
-  - Superpowers TDD workflow
-  - Compound Engineering main workflow
+  - engineering workflow plugins

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

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

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

@@ -9,10 +9,7 @@ required:
   agents_routing: docs/governance/agents-routing/engineering-runtime-v0.9.md
   current_work: docs/reference/execution/current-work.md
 optional:
-  compound_engineering: integrations/compound-engineering.md
-  directed_development: integrations/directed-development.md
   mattpocock_skills: integrations/mattpocock-skills.md
-  superpowers: integrations/superpowers.md
 project_local_required:
   - docs/policy/best-practice-for-this-project.md
   - AGENTS.md lane summary
@@ -21,5 +18,4 @@ project_local_required:
 not_included:
   - product canon
   - project-specific runtime rules
-  - Superpowers plugin body
-  - Compound Engineering plugin body
+  - external workflow plugin bodies