@pieai/pro-gov 0.4.2 → 0.4.4

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/integrations/ponytail.md

@@ -1,161 +1,9 @@
-# Ponytail Integration
+# Ponytail Integration (Retired)
 
-Ponytail is an external plugin that asks an AI to prefer the smallest solution
-that still works. Project Governance System does not vendor, rewrite, or require
-the Ponytail plugin.
+PGS no longer requires or configures the Ponytail plugin.
 
-## The Beginner Version
+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.
 
-Think of an AI project as a building site:
-
-- PGS is the traffic desk and inspection station.
-- Superpowers is the construction process.
-- Ponytail is the cost and complexity adviser.
-
-The adviser can stop the team from buying unnecessary materials. The adviser
-cannot cancel the fire exit, the safety inspection, or a room the owner
-explicitly requested.
-
-## Safe Default
-
-Keep the global Ponytail mode `off`.
-
-`off` does not mean Ponytail is useless. It means Ponytail is available when a
-task needs a simplicity review without silently influencing every project and
-every answer.
-
-Do not describe `lite` as "almost off." In Ponytail 4.7.0, `lite` still injects
-the shared minimalism rules into the active AI context. Its mode-specific line
-is gentler than `full`, but the same AI still sees rules about fewer files,
-fewer abstractions, shorter diffs, and avoiding speculative work.
-
-## Mode Policy
-
-| Mode | Governed use |
-| --- | --- |
-| `off` | Recommended global default. Ponytail does not inject its active ruleset. |
-| `lite` | First mode to test in one isolated task or session. Complete the requested work, while surfacing a simpler option. |
-| `full` | Optional stress test after `lite`. Use only in an isolated task to see whether stronger minimalism harms scope or proof. |
-| `ultra` | Not part of the recommended PGS workflow. It is too aggressive for a default governed engineering lane. |
-
-Return to `off` after every comparison.
-
-## Comparison Protocol
-
-Use the same bounded, low-risk task in separate sessions or worktrees:
-
-```text
-baseline with off
--> repeat with lite
--> compare scope, proof, complexity, and clarity
--> optionally repeat with full
--> return global mode to off
-```
-
-Compare:
-
-- whether every requested requirement was delivered;
-- whether Superpowers brainstorming, planning, TDD, debugging, and verification
-  gates were preserved;
-- whether tests, security, accessibility, validation, and data-loss prevention
-  remained intact;
-- files, dependencies, abstractions, and lines changed;
-- whether the explanation and durable evidence stayed understandable;
-- token and time measurements only when the AI host exposes trustworthy data.
-
-A shorter answer or smaller diff is not automatically a better result.
-
-## Priority And Boundary
-
-Use this priority order:
-
-1. User instructions and project safety requirements.
-2. PGS routing, governance boundaries, and required evidence.
-3. Superpowers workflow gates.
-4. Ponytail complexity and cost advice.
-
-Ponytail may:
-
-- question speculative scope;
-- prefer the standard library or an already-installed dependency;
-- suggest fewer files, dependencies, and abstractions;
-- identify code or structure that can be removed safely.
-
-Ponytail may not:
-
-- remove an explicit requirement;
-- bypass PGS routing or document placement;
-- skip required brainstorming, plans, TDD, debugging, or verification;
-- weaken security, accessibility, trust-boundary validation, error handling, or
-  data-loss protection;
-- replace proof with "the code is shorter";
-- silently change the user's global Ponytail configuration.
-
-## Recommended Workflow
-
-```mermaid
-flowchart TD
-  A["Task arrives"] --> B["PGS selects the project lane"]
-  B --> C["Superpowers runs the required workflow"]
-  C --> D{"Would a simplicity review help?"}
-  D -- "no" --> E["Implement and verify normally"]
-  D -- "yes" --> F["Use Ponytail explicitly for this task"]
-  F --> G["Keep requirements and proof intact"]
-  G --> E
-```
-
-For normal engineering, Ponytail is a scoped adviser, not a second workflow
-engine and not a replacement for Superpowers.
-
-## ProjectLens Audit Use
-
-When ProjectLens and Ponytail are used together for a target-project audit,
-ProjectLens owns the audit package contract. Ponytail acts as an independent
-senior engineering reviewer whose simplicity, YAGNI, dependency, abstraction,
-and rewrite judgment can challenge ProjectLens recommendations.
-
-For this combined workflow, "read-only project audit" means the target
-repository must not be modified. It does not mean "do not write the PGS audit
-package." The audit package is the required owner-facing evidence record.
-
-Use this order:
-
-1. The main agent establishes target path, goal, current phase, target commit or
-   working state, then creates the package with
-   `pro-gov lens audit init --target <path> --out audits/<target>/<date>`.
-2. ProjectLens gathers local evidence and writes its own raw artifacts under
-   `raw/project-lens/`.
-3. Ponytail runs independently and writes its own raw artifacts under
-   `raw/ponytail/`. For initial whole-project audits, preserve at least
-   `ponytail-audit`, `ponytail-debt`, and `ponytail-gain` outputs when the
-   plugin can produce them.
-4. The target command log records Project Lens and Ponytail method sources.
-5. The main agent writes `synthesis/decision-index.md` and
-   `synthesis/handoff-for-implementation-ai.md`, then runs
-   `pro-gov lens audit check --dir audits/<target>/<date>`.
-
-Use subagents for the ProjectLens/Ponytail raw passes when the AI host exposes
-them and the user has authorized subagent or parallel agent work. If host rules
-block subagents, preserve the same raw-output separation with serial passes and
-record the fallback in the audit package. Do not claim that subagents were used
-when they were not. The manifest must include `Subagent trace:` with each pass
-role, execution mode, final status, and raw artifact path; if durable subagent
-IDs are unavailable, record that limitation.
-
-Do not blur a fresh audit with a reuse verification. For a fresh ProjectLens plus
-Ponytail audit, run `pro-gov lens audit check --dir <audit-dir> --mode fresh`.
-If an existing package is reused because the target commit and package check are
-still valid, label the result as reuse and run `--mode reuse`.
-
-Do not blend Ponytail findings into ProjectLens files. Do not suppress Ponytail
-to make ProjectLens look correct. Preserve material disagreements in the raw
-artifacts and let the synthesis state which judgment won and why. The shared
-boundary is evidence, user intent, project safety, explicit product-line
-direction, and PGS's technology-governance protocol. If a stack direction
-exists, Ponytail may challenge migration scope, timing, and complexity, while
-ProjectLens records the direction as the product group's stated intent and PGS
-classifies the execution posture.
-
-Use `ponytail-review` later for implementation diffs or PR-style changes. For
-initial read-only project audits, prefer the whole-repo Ponytail modes above so
-the audit starts from system shape instead of line-level patch review.
+This file remains only as a stable target for historical links.

package/assets/integrations/superpowers.md

@@ -1,107 +1,12 @@
-# Superpowers Integration
+# Superpowers Integration (Retired)
 
-Superpowers is an external plugin/system. This repository does not vendor or rewrite it.
+PGS no longer requires or routes through the Superpowers plugin.
 
-## The Beginner Version
+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.
 
-Think of an AI project as a building site:
-
-- PGS is the traffic desk and inspection station.
-- Superpowers is the construction process.
-- `pro-gov learn recall` is the pre-work lookup for reusable lessons.
-- Compound Engineering's `ce-compound` is the knowledge-capture tail.
-- Ponytail is an optional cost and complexity adviser.
-
-PGS chooses the lane. Superpowers makes sure the work follows the right
-engineering process. Learning Recall checks prior lessons before work starts.
-Compound Engineering records reusable lessons after verified work. Ponytail may
-suggest a leaner implementation, but it cannot cancel the process or the final
-inspection.
-
-## Boundary
-
-Superpowers owns engineering workflows such as:
-
-- brainstorming
-- writing plans
-- TDD
-- debugging
-- verification before completion
-- worktree usage
-
-Superpowers 6.x for Codex is skill-routed, not hook-driven. The plugin manifest
-does not need a SessionStart hook for PGS to make use of it. The startup
-behavior comes from the `using-superpowers` skill description, which tells the
-host to check relevant skills at the start of a conversation and before acting.
-Do not add a PGS hook just to force Superpowers startup unless a future
-Superpowers release explicitly requires one.
-
-Project Governance System owns:
-
-- documentation lifecycle
-- agents routing
-- current work index conventions
-- pre-work learning recall through `pro-gov learn recall`
-- the governed location and boundary for externally sourced AI evidence rules
-
-Ponytail, when explicitly enabled for a task, may advise on:
-
-- speculative scope;
-- unnecessary dependencies;
-- avoidable files and abstractions;
-- simpler implementation choices.
-
-Compound Engineering, by default, owns:
-
-- post-work knowledge capture through `ce-compound`;
-- fallback capture through `pro-gov learn capture` only when CE is unavailable;
-- `docs/solutions/**` learning records and their CE frontmatter;
-- CE-owned external artifacts when the user explicitly invokes CE workflows.
-
-## Rule
-
-Use Superpowers inside the selected project lane. Do not let Superpowers create a separate durable document tree unless the project explicitly adopts one.
-
-Durable outputs should map back to the project's doc-gov layers:
-
-- specs -> `docs/specs/**`
-- plans -> `docs/plans/**`
-- durable references -> `docs/reference/**`
-
-## Execution Order
-
-Agents routing classifies first. For non-trivial work, Learning Recall checks
-prior `docs/solutions/**` and `CONCEPTS.md` records before files change.
-Superpowers executes inside the selected lane. Optional Ponytail advice may run
-after those responsibilities are known. It may make the implementation leaner,
-but it must not remove explicit requirements or reduce how correctness is
-proven. The Compound Gate runs near the end, before final reporting, to decide
-whether verified work produced reusable learning.
-
-```mermaid
-flowchart TD
-  A["Task arrives"] --> B["Read project router and current work"]
-  B --> C["Classify profile and lane"]
-  C --> R["Run Learning Recall for non-trivial work"]
-  R --> D{"Does this lane need a Superpowers workflow?"}
-  D -- "yes" --> E["Use the matching Superpowers skill"]
-  D -- "no" --> F["Use the local non-Superpowers lane rules"]
-  E --> G{"Would an explicit simplicity review help?"}
-  F --> G
-  G -- "yes" --> H["Use Ponytail without dropping workflow gates"]
-  G -- "no" --> I["Pass the Compound Gate"]
-  H --> I
-  I --> J["Write durable outputs into doc-gov layers"]
-```
-
-If Superpowers suggests a default location such as `docs/superpowers/**`, project instructions may override that location. The durable project record should still land in the governed doc-gov layer unless the project has explicitly adopted a separate Superpowers document tree.
-
-Host-specific files such as `CLAUDE.md` may include Superpowers skill routing
-text. That text is an adapter. It must not replace the project `AGENTS.md`
-router or run before the Project Governance System routing block.
-
-For Ponytail mode policy and the isolated comparison protocol, read
-`integrations/ponytail.md`.
-
-For Compound Engineering's knowledge-capture boundary, read
-`integrations/compound-engineering.md`.
+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.

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

@@ -9,9 +9,7 @@ required:
   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 +17,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

@@ -15,7 +15,7 @@ Use for non-runtime projects: IP development, AI media production, research vaul
 
 - engineering-runtime agents routing
 - Directed Development
-- Superpowers TDD
+- engineering TDD workflow plugins
 - behavior-critical code lanes
 
 ## Requires Project-Local Rules
@@ -34,4 +34,6 @@ This profile is a human/AI adoption contract. `doc-gov` validates the resulting
 project shape. `pro-gov init --apply` can install it into a fresh target, but
 refuses all writes when any destination already exists. `sync --check` compares
 shared core files while leaving project-local router, policy, and current-work
-content under the target project's ownership.
+content under the target project's ownership. Optional Lefthook and CI
+guardrails are also consumer-owned when installed; `doc-gov doctor` checks that
+their required governance commands remain present.

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

@@ -9,10 +9,8 @@ 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 +19,4 @@ project_local_required:
 not_included:
   - product canon
   - project-specific runtime rules
-  - Superpowers plugin body
-  - Compound Engineering plugin body
+  - external workflow plugin bodies

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

@@ -9,8 +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/superpowers.md`
-- `integrations/compound-engineering.md`
 - `integrations/directed-development.md`
 - `integrations/mattpocock-skills.md`
 - starter `docs/governance/` and `docs/policy/` templates
@@ -30,8 +28,7 @@ Each project must define:
 - product canon
 - stack-specific rules
 - game/app-specific lane wording
-- Superpowers plugin body
-- Compound Engineering plugin body
+- external workflow plugin bodies
 - mattpocock/skills body
 
 ## Automation Boundary
@@ -40,16 +37,11 @@ This profile is a human/AI adoption contract. `doc-gov` validates the resulting
 project shape. `pro-gov init --apply` can install it into a fresh target, but
 refuses all writes when any destination already exists. `sync --check` compares
 shared core files while leaving project-local router, policy, and current-work
-content under the target project's ownership.
-
-Engineering-runtime starters also include Codex, Claude Code, and Antigravity
-Stop hooks that call `pro-gov host-hook`. Use `pro-gov doctor --strict-hooks`
-after sync to confirm the host configs are wired. The starter default is
-`--compound-gate-mode off`, so the hook does not interrupt the main session
-unless the project explicitly switches to `lite` or `strict`. Even when enabled,
-the hook does not replace verification, tests, or `ce-compound` itself.
+content under the target project's ownership. Optional Lefthook and CI
+guardrails are also consumer-owned when installed; `doc-gov doctor` checks that
+their required governance commands remain present.
 
 For non-trivial engineering work, run `pro-gov learn recall --query "<task
 summary>"` before changing files so existing `docs/solutions/**` and
-`CONCEPTS.md` lessons can shape the work without enabling a second default
-workflow.
+`CONCEPTS.md` lessons can shape the work. After verified work, use the
+`capture-learning` skill only when a reusable lesson exists.

package/assets/starter/AGENTS.template.md

@@ -40,13 +40,11 @@
 
 - Name this project's adopted profile: `engineering-runtime` or `doc-only`.
 - Point to the chosen agents-routing file from `docs/governance/agents-routing/`.
-- Engineering projects may use Superpowers, Directed Development, GStack, or other external workflows only inside the selected lane; do not copy upstream integration guides into the target project by default.
-- For engineering projects, Superpowers is the default engineering workflow. Compound Engineering is used by default only as the post-work Compound Gate through `ce-compound`; full CE workflows require an explicit user request.
-- For engineering projects, PGS Learning Recall is the pre-work companion to that post-work gate: recall existing lessons first, then do the work, then decide whether a new lesson should be compounded.
-- Engineering projects should have PGS Stop hooks wired for Codex, Claude Code, and Antigravity. Starter hooks default to `--compound-gate-mode off`; opt into `lite` or `strict` only when this project wants runtime exit-gate reminders. Before final reporting after completed engineering work, report `Compound Gate: ran ce-compound -> <path>`, `Compound Gate: ran fallback capture -> <path>`, or `Compound Gate: skipped -> <reason>`.
-- Use fallback capture only when the current host cannot load Compound Engineering; run `pro-gov learn capture --title "<learning title>" --summary "<reusable lesson>"` so Learning Recall can find the lesson later.
-- Doc-only projects should say that Superpowers TDD and Directed Development are not enabled by default.
-- External workflow systems such as Superpowers or GStack run inside the lane selected by this router. They must not replace this project router.
+- 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.
+- Do not install Stop/SubagentStop workflow reminder hooks.
+- Doc-only projects should say that engineering TDD and Directed Development are not enabled by default.
 
 <!-- PGS-ROUTER:END -->
 

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

@@ -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 Superpowers TDD or Directed Development by default.
+This route does not use engineering TDD or Directed Development by default.
 
 ## Core Flow
 
@@ -78,6 +78,6 @@ unless the project explicitly opts them into doc-gov.
 
 ## External Workflow Boundary
 
-This route runs before external workflow systems such as Superpowers or GStack.
+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

@@ -36,7 +36,7 @@ flowchart TD
   D -- "yes" --> E["Use Directed Development to split ordered DD Blocks"]
   E --> C
   D -- "no" --> F["Enter local lane"]
-  F --> G["Use matching Superpowers workflow if applicable"]
+  F --> G["Use a narrowly matched skill only when helpful"]
   G --> H["Use AI-in-the-Loop evidence cycle"]
   H --> I["Record evidence in doc-gov"]
 ```
@@ -70,9 +70,10 @@ But the shared router must not define project-specific lanes.
 
 ## External Workflow Boundary
 
-This route runs before external workflow systems such as Superpowers or GStack.
-Those systems may provide skills, reviews, browser workflows, or shipping gates,
-but they execute **inside** the lane selected by this route.
+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-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/boundary.md

@@ -45,8 +45,7 @@ project-specific AI development habits live.
 - Product canon, runtime truth, or content truth.
 - Product prompts, generated media notes, or project-package workbench files.
 - Current project plans or active specs.
-- Superpowers plugin content.
-- Compound Engineering plugin content.
+- External workflow plugin content.
 
 ## Put Those Elsewhere
 
@@ -60,7 +59,7 @@ project-specific AI development habits live.
 | Product or world truth | `docs/canon/` |
 | Active implementation work | `docs/plans/active/` |
 | Completed proof records | `docs/plans/completed/` |
-| Compound Engineering learnings | `docs/solutions/**` as CE-owned external artifacts |
+| Reusable project learnings | `docs/solutions/**` as learning artifacts |
 | Product artifacts outside governed docs | Project package, workbench, assets, runtime config, or source tree |
 
 When unsure, ask this question: is this rule about how the document system works,
@@ -77,7 +76,5 @@ product packages, workbenches, prompt libraries, source folders, or asset
 folders can be product artifacts. Keep those files where the product package
 expects them unless a project explicitly opts them into doc-gov.
 
-Compound Engineering external artifacts under `docs/solutions/**`,
-`docs/brainstorms/**`, `docs/pulse-reports/**`, and CE-native root files under
-`docs/plans/*` are not governed docs by default. They remain valid project
-artifacts, but their frontmatter belongs to Compound Engineering, not Doc Gov.
+Learning artifacts under `docs/solutions/**` are not governed docs by default.
+They remain searchable project artifacts with their own lightweight metadata.