@event4u/agent-config 1.20.0 → 1.22.0

package/.agent-src/rules/roadmap-progress-sync.md

@@ -2,179 +2,16 @@
 type: "auto"
 tier: "1"
 description: "Any touch to agents/roadmaps/ — create/rename/delete/move, edit checkboxes ([x]/[~]/[-]), add/rename/remove phases — must regenerate dashboard and archive if 0 open items, same response"
-alwaysApply: false
 source: package
-load_context:
-  - .agent-src.uncompressed/contexts/communication/rules-auto/roadmap-progress-sync-mechanics.md
+triggers:
+  - path_prefix: "agents/roadmaps/"
+routes_to:
+  - "guideline:agent-infra/roadmap-progress-mechanics"
 ---
 
-<!-- cloud_safe: degrade -->
-<!-- Authoring discipline applies in cloud; local script + regen are no-ops there. -->
-
 # Roadmap Progress Sync
 
-> **Enforced by:** [`scripts/roadmap_progress_hook.py`](../../scripts/roadmap_progress_hook.py)
-> on Augment + Claude Code (`PostToolUse`). Hook is primary; the prose
-> below is the specification the hook implements and the fallback when
-> the platform has no hook surface.
-
-## Iron Law — dashboard sync
-
-```
-ANY ROADMAP TOUCH → REGENERATE THE DASHBOARD, SAME RESPONSE.
-NO EXCEPTIONS. NO "I'LL DO IT AT THE END". NO BATCHING ACROSS TURNS.
-A ROADMAP NOT IN THE DASHBOARD IS A RULE VIOLATION, NOT AN OVERSIGHT.
-```
-
-**Roadmap touch =** create the file, rename it, delete it, move it
-between `roadmaps/` ↔ `archive/` ↔ `skipped/`, add/rename/remove a
-phase, **OR** flip any checkbox (`[ ]` ↔ `[x]` ↔ `[~]` ↔ `[-]`).
-
-`agents/roadmaps-progress.md` is the read-only dashboard. Every
-unsynced edit makes it lie to the next reader. Created a roadmap
-without regenerating? The dashboard claims it does not exist. Marked
-8 steps `[x]` and forgot the regen? The dashboard says 0 done.
-
-## Iron Law — every active roadmap is trackable
-
-```
-EVERY ACTIVE ROADMAP MUST CONTAIN AT LEAST ONE TRACKABLE CHECKBOX
-(`- [ ]`) PER NON-INTRO PHASE. ROADMAPS WITHOUT EXECUTABLE STEPS
-EITHER GET A CHECKLIST OR THE `status: draft` FLAG.
-CI-ENFORCED: `scripts/check_roadmap_trackable.py` (CANNOT BE DEFERRED).
-```
-
-**Active roadmap =** any file in `agents/roadmaps/` (root, not
-`archive/` or `skipped/`) without `status: draft` frontmatter.
-
-**Trackable checkbox =** an actionable `- [ ]` line under a `## Phase N`
-or `### Phase N` heading (numeric `Phase 1`, roman `Phase II`, or
-letter-track `Phase A1` — matched by the dashboard's `PHASE_RE`).
-Tables of decisions, ICE matrices, ADR captures, and "block
-sequencing" tables are valid **rationale**, but they do not satisfy
-this rule on their own — they must be paired with at least one
-`## Phase N` section whose checkboxes execute the decision.
-Headings such as `## Phase steps`, `### Sequencing — Phase 1 …`,
-`### P0 #1 — …`, or `## Block A` do **not** count — only the
-canonical `Phase <id>` form parsed by the dashboard.
-
-**CI backstop.** `scripts/check_roadmap_trackable.py` (package-shipped,
-wire into the consumer's pre-commit / pre-push / Actions gate) fails
-when an active roadmap has zero canonical `Phase` headings or when
-any parsed phase has zero checkboxes. Last line of defence — real-time
-authoring still flips checkboxes and regenerates the dashboard the
-same response.
-
-## Status — binary `ready` (default) vs `draft`
-
-```yaml
----
-status: draft          # hidden from the dashboard until flipped
----
-```
-
-Two values, no synonyms. Anything else — no frontmatter at all,
-`status: ready`, an unknown value — counts as **ready** and lands
-in the dashboard.
-
-- **Ready** is the implicit default. New roadmaps are created
-  ready unless the user explicitly says draft. Ready roadmaps are
-  listed in the dashboard, count towards open/done totals, and
-  trip the "completed but not archived" warning when they close.
-- **Draft** hides the file from the dashboard entirely (not
-  counted, not listed). Use it while the roadmap is still being
-  authored, while waiting for upstream decisions, or as a
-  capture-only synthesis that has not yet been promoted to
-  executable phases. Flip to ready (or remove the field) the
-  moment the roadmap is ready to track.
-
-**Completion = archival, same response.** When the edit takes a
-roadmap to `count_open == 0` (every item is `[x]`, `[~]`, or `[-]`),
-`git mv` it into `agents/roadmaps/archive/` (or `skipped/` if no `[x]`
-at all) **before** regenerating the dashboard. A 100%-complete
-roadmap left under `agents/roadmaps/` is a rule violation, not an
-optional cleanup. See `roadmap-management` skill for the archive vs
-skipped decision table.
-
-## Agent-authored roadmaps — placement is mandatory
-
-```
-A FILE THE AGENT DROPS INTO agents/roadmaps/ MUST EITHER
-(a) PASS check_roadmap_trackable.py AND LAND IN THE DASHBOARD, OR
-(b) NOT BE IN agents/roadmaps/ AT ALL.
-NO "DECISION MATRIX" / "DESIGN NOTE" SHORTCUT.
-```
-
-When the agent autonomously creates a roadmap, it owns the placement
-in the **same response**:
-
-- **Phase plan** (checkboxes, multi-turn execution) → `agents/roadmaps/<name>.md`, `status: ready` (default), regen dashboard.
-- **Decision matrix / ADR / pattern / lookup** (no `Phase N`, durable rationale) → `agents/contexts/<name>.md`.
-- **Completed work snapshot** → `agents/roadmaps/archive/<name>.md`.
-
-A non-trackable file in `agents/roadmaps/` is a rule violation — the
-trackable CI fails it, the dashboard hides it. The agent that
-created it moves it the same response. If the autonomous run also
-**finishes** the roadmap within the session (every box `[x]`/`[~]`/`[-]`),
-the completion-archival rule above fires too — same response.
-
-## Autonomous execution — checkbox cadence
-
-When executing a roadmap autonomously (multi-turn, no per-step user
-prompt), the user loses progress visibility unless checkboxes flip
-**as work lands**, not in a batch at the end. Iron Law:
-
-```
-EVERY DONE STEP FLIPS [ ] → [x] IN NEXT REPLY THAT ACKNOWLEDGES IT.
-NO "I UPDATE ROADMAP AT END OF PHASE."
-NO "FOUR STEPS DONE, ONE COMMIT, ONE REGEN."
-```
-
-Step counts as completed when:
-
-- Code / docs change for that step has been **written and saved** AND
-- Verification cited in the step (project CI command, targeted test, lint) has
-  **passed in this response or an earlier one** — fresh output, not memory.
-
-Then in the **same reply**: flip the checkbox, regenerate the
-dashboard, commit if commit policy allows.
-
-**Forbidden:** four turns of step work, dashboard flat, single regen at the end.
-**Required:** each turn — implement step, flip `[x]`, regen, commit (if policy allows).
-A reply that lands a verified step without flipping its checkbox is a rule violation.
-
-**In-progress marker:** when a step takes more than one reply,
-mark it `[~]` the moment work starts on it and regenerate. The
-user sees one row move from `[ ]` to `[~]` to `[x]` instead of
-silent rows. `[~]` is treated as open for `count_open` but moves
-the phase percentage forward in the dashboard.
-
-## Mechanics — triggers, regen command, self-check, failures
-
-The triggers table, the regen command (`./agent-config roadmap:progress`),
-the mandatory pre-send self-check, the failure-mode catalog, and the
-`Do NOT` list live in
-[`contexts/communication/rules-auto/roadmap-progress-sync-mechanics.md`](../contexts/communication/rules-auto/roadmap-progress-sync-mechanics.md).
-Pull it whenever a trigger fires — the rule above is the obligation
-surface; the mechanics file is the lookup material.
-
-## Copilot fallback
-
-GitHub Copilot has no `PostToolUse` hook surface, so
-`scripts/roadmap_progress_hook.py` cannot detect roadmap-file writes
-structurally. The dashboard at `agents/roadmaps-progress.md` will
-not regenerate on its own.
-
-The cooperative path: every time a roadmap touch fires (per the
-trigger list in the mechanics context above), the agent regenerates
-the dashboard in the same response — which is the same Iron Law the
-hook enforces, just executed manually:
-
-```bash
-./agent-config roadmap:progress
-```
+**Iron Law.** Any touch to `agents/roadmaps/` regenerates the dashboard in the same response; archive the roadmap when 0 open items remain.
 
-The hook implementation is the specification; on Copilot the agent
-runs the regenerator itself after the same triggers fire. Skipping
-it is a rule violation, not a hook gap — the Iron Law on dashboard
-sync survives the missing hook surface.
+Body migrated to `guideline:agent-infra/roadmap-progress-mechanics` (per P4 of `road-to-kernel-and-router.md`).
+Trigger-set above activates this routing under the `balanced` and `full` profiles.

package/.agent-src/rules/role-mode-adherence.md

@@ -4,13 +4,17 @@ tier: "2a"
 description: "When roles.active_role is set in .agent-settings.yml — closing outputs must match the mode's contract and emit the structured mode marker"
 alwaysApply: false
 source: package
+triggers:
+  - keyword: "active_role"
+  - keyword: "role-mode"
+  - intent: "mode marker"
 ---
 
 # Role Mode Adherence
 
 Auto-activates when `.agent-settings.yml` sets `roles.active_role` to
 one of the six modes defined in
-[`role-contracts`](../../docs/guidelines/agent-infra/role-contracts.md):
+[`role-contracts`](../docs/guidelines/agent-infra/role-contracts.md):
 `developer`, `reviewer`, `tester`, `po`, `incident`, `planner`.
 
 Read `roles.active_role` from `.agent-settings.yml` at session start. Empty / missing → rule is inert; do NOT guess a mode.
@@ -47,7 +51,7 @@ Infer the mode (Phase-3 router does that). Touch `.agent-settings.yml`
 
 ## See also
 
-- [`role-contracts`](../../docs/guidelines/agent-infra/role-contracts.md)
+- [`role-contracts`](../docs/guidelines/agent-infra/role-contracts.md)
 - [`/mode`](../commands/mode.md)
 - [`ask-when-uncertain`](ask-when-uncertain.md)
 - [`scope-control`](scope-control.md)

package/.agent-src/rules/rule-type-governance.md

@@ -2,74 +2,16 @@
 type: "auto"
 tier: "2a"
 description: "Creating or editing rules, or auditing rule types — decides when a rule should be always vs auto"
-alwaysApply: false
 source: package
+triggers:
+  - path_prefix: ".agent-src.uncompressed/rules/"
+routes_to:
+  - "guideline:agent-infra/rule-type-governance"
 ---
 
-# rule-type-governance
+# Rule Type Governance
 
-## `always` = loaded every conversation
+**Iron Law.** Choose `always` vs `auto` per the governance table; over-broad `always` rules degrade the kernel budget.
 
-Use ONLY when the rule applies to virtually every interaction:
-
-- Universal agent behavior (language, tone, interaction style)
-- Safety constraints (scope control, verification before completion)
-- Token/efficiency constraints
-- First-message checks that cannot wait for auto-trigger
-
-## `auto` = loaded on demand by description match
-
-Use for everything else:
-
-- Language-specific rules (PHP, JS, SQL)
-- Tool-specific rules (Docker, Git, quality tools)
-- Workflow-specific rules (commands, skill creation, E2E testing)
-- Domain-specific rules (translations, architecture)
-
-## Decision test
-
-> "Does this rule need to be active when the user asks a simple question, reviews a PR, or discusses architecture?"
-
-- Yes → `always`
-- No → `auto` with a clear trigger description
-
-## Auto description quality
-
-The `description` field IS the trigger. It must describe **when** the rule applies, not **what** it contains.
-
-- ❌  `"PHP coding standards"` — too vague, won't match reliably
-- ✅  `"Writing or reviewing PHP code — strict types, naming, Eloquent conventions"`
-
-## Hard constraint
-
-- Default to `auto`. Justify `always`.
-- If >50% of conversations don't need a rule → it must be `auto`.
-- `optimize-agents` command checks this and suggests changes.
-
-## Hardening tier — required on new or edited rules
-
-Every new rule, and every edited rule whose body changes the trigger
-or the obligation, MUST classify itself against the hardening tiers
-documented in [`rule-trigger-matrix.md`](../../agents/contexts/rule-trigger-matrix.md):
-
-| Tier | Meaning |
-|---|---|
-| `1` | Mechanically enforceable — hook acts, rule body stays minimal. |
-| `2a` | Marker nudge — hook injects signal, agent acts on it. |
-| `2b` | Structured injection / tool-call gate — hook reads/writes state, may deny. |
-| `3` | Soft, judgment-bound — no platform surface; self-check rule. |
-| `safety-floor` | Iron-Law subset, never modified. |
-| `mechanical-already` | Precedent — script enforces, rule body documents. |
-
-Classification surface: the optional `tier:` frontmatter field
-(declared in `scripts/schemas/rule.schema.json`). Recommended for new
-rules; bulk-retrofit of existing rules is tracked separately.
-
-Tier 3 dispositions are recorded centrally in
-[`agents/contexts/tier-3-dispositions.md`](../../agents/contexts/tier-3-dispositions.md)
-with a 6-month re-audit clock. New Tier 3 rules append to that list
-on landing.
-
-The `optimize-agents` command checks the tier alongside `type`/`source`
-and suggests escalations when a rule's trigger matches a hardening
-opportunity that has shipped since the rule was authored.
+Body migrated to `guideline:agent-infra/rule-type-governance` (per P4 of `road-to-kernel-and-router.md`).
+Trigger-set above activates this routing under the `balanced` and `full` profiles.

package/.agent-src/rules/runtime-safety.md

@@ -3,6 +3,11 @@ type: auto
 tier: "2b"
 source: package
 description: "When a skill declares execution metadata — enforce safety constraints for assisted and automated execution types"
+triggers:
+  - keyword: "execution"
+  - keyword: "automated"
+  - keyword: "assisted"
+  - keyword: "handler"
 ---
 
 # Runtime Safety

package/.agent-src/rules/scope-control.md

@@ -5,7 +5,7 @@ description: "Scope control — no unsolicited architectural changes, refactors,
 alwaysApply: true
 source: package
 load_context:
-  - .agent-src.uncompressed/contexts/authority/scope-mechanics.md
+  - ../contexts/authority/scope-mechanics.md
 ---
 
 # Scope Control
@@ -14,73 +14,35 @@ load_context:
 - Do NOT replace existing patterns with alternatives.
 - Do NOT refactor existing code solely to comply with current rules.
 - Do NOT suggest new libraries unless explicitly requested.
-- Existing code should only be modified if directly related to the current change, required for bug fixes, security, or explicitly requested.
-- New or newly modified code MUST follow all coding rules.
-- Stay within the established project structure and conventions.
-- When unsure about the scope, ask the user.
+- Modify existing code only when directly related to the current change, required for bug fixes / security, or explicitly requested.
+- New / modified code MUST follow all coding rules.
+- Stay within established project structure and conventions.
+- When unsure about scope, ask the user.
 
 ## Git operations — permission-gated
 
-The user decides the git shape of the work. Never improvise.
-
-> **Commit specifics:** see the canonical [`commit-policy`](commit-policy.md)
-> rule — narrower than the general "no git ops without permission"
-> below (covers the never-ask-about-committing default and the
-> roadmap-authorized exception).
+The user decides the git shape. Never improvise. Commit specifics: canonical [`commit-policy`](commit-policy.md).
 
 - NEVER commit, push, merge, rebase, or force-push without explicit user permission.
-- NEVER create a new branch, switch to a different branch, or delete a
-  branch without explicit user permission. This includes spike, scratch,
-  throwaway, and worktree branches.
-- NEVER create, close, reopen, or change the target of a pull request
-  without explicit user permission.
-- NEVER push a tag or create a release without explicit user permission.
-- NEVER include version numbers, target releases, deprecation dates,
-  release-tied milestones, or git tags inside roadmaps, plans, tickets,
-  or any other planning artifact. Roadmaps plan **work**; releases and
-  tags are a separate decision the user makes outside the roadmap.
-  Never surface "which release should this ship in?" as an option in
-  numbered choices, ADRs, or roadmap text. If the user wants a release
-  pinned to a milestone, they will say so explicitly.
-- If a task seems to need a separate branch or PR, STOP and **brief
-  the user before asking** — see
-  [`scope-mechanics`](../contexts/authority/scope-mechanics.md)
-  § Brief-before-asking for the required Why / What / How sequence.
+- NEVER create / switch / delete a branch without explicit permission — includes spike, scratch, throwaway, worktree branches.
+- NEVER create, close, reopen, or change the target of a pull request without permission.
+- NEVER push a tag or create a release without permission.
+- NEVER include version numbers, target releases, deprecation dates, release-tied milestones, or git tags in roadmaps, plans, tickets, or any planning artifact. Roadmaps plan **work**; releases / tags are a separate decision outside the roadmap. Never surface "which release should this ship in?" as a numbered choice. User pins by saying so explicitly.
+- Task seems to need a separate branch / PR → STOP and **brief before asking** ([`scope-mechanics § Brief-before-asking`](../contexts/authority/scope-mechanics.md)).
 
-"Explicit permission" means the user said so **in this turn or in a
-standing instruction they have not revoked**. Earlier permission for a
-different operation does not carry over.
+"Explicit permission" = user said so **this turn or in a standing instruction not yet revoked**. Earlier permission for a different operation does not carry over.
 
 ## Production, infrastructure, bulk-destructive — Hard Floor
 
-A subset of the operations above is **never** autonomous and never
-auto-permitted by a standing autonomy directive. Canonical rule:
-[`non-destructive-by-default`](non-destructive-by-default.md). The
-trigger list (production-branch merges, deploys / releases, prod
-data / infra, bulk-destructive ops) and the
-"authorization is this turn, not earlier" clarification live in
-[`scope-mechanics`](../contexts/authority/scope-mechanics.md)
-§ Production, infrastructure, bulk-destructive.
+A subset is **never** autonomous and never auto-permitted by a standing autonomy directive. Canonical: [`non-destructive-by-default`](non-destructive-by-default.md). Trigger list (prod-branch merges, deploys / releases, prod data / infra, bulk-destructive ops) and the "authorization is this turn, not earlier" clarification: [`scope-mechanics § Production, infrastructure, bulk-destructive`](../contexts/authority/scope-mechanics.md).
 
 ## Decline = silence — no re-asking on the same task
 
-After the user **declines** a proposal (branch switch, PR creation,
-tag/release entry, separate worktree, version pinning in a roadmap),
-do **not** raise the same proposal again on the same task. The decline
-stands until the user reopens the topic themselves.
-
-Timing and "is this worth asking?" guidance lives in
-[`scope-mechanics`](../contexts/authority/scope-mechanics.md)
-§ Decline = silence — context.
+After the user **declines** a proposal (branch switch, PR creation, tag/release entry, separate worktree, version pinning), do **not** raise it again on the same task. Decline stands until the user reopens the topic. Timing / "is this worth asking?": [`scope-mechanics § Decline = silence`](../contexts/authority/scope-mechanics.md).
 
 ## Fenced step — user-set review gates
 
-When the user explicitly fences off the next step — *"don't implement
-yet"*, *"plan only"*, *"just write the roadmap, I'll review"*,
-*"review first"*, *"erst Roadmap, ich schau drüber"*, *"nichts
-implementieren"*, *"nur planen"*, *"erstmal nur X, dann ich"* — the
-agent's reply is **the deliverable plus a handoff**, never the
-deliverable plus *"shall we start?"*.
+User explicitly fences off the next step — *"don't implement yet"*, *"plan only"*, *"just write the roadmap, I'll review"*, *"review first"*, *"erst Roadmap, ich schau drüber"*, *"nichts implementieren"*, *"nur planen"*, *"erstmal nur X, dann ich"* — reply is **the deliverable plus a handoff**, never deliverable plus *"shall we start?"*.
 
 ```
 USER FENCED OFF EXECUTION → DELIVER + HAND BACK.
@@ -89,13 +51,6 @@ NO "READY TO IMPLEMENT?" RE-ASK.
 NO "STARTEN WIR MIT PHASE 1?" PIVOT.
 ```
 
-The fence stands until the user reopens the topic themselves, exactly
-like `Decline = silence` above. Permitted follow-up questions on the
-same turn cover **the deliverable** (adjust scope, fix wording, add a
-section), never **its execution**.
+Fence stands until the user reopens, exactly like `Decline = silence`. Permitted follow-up questions cover **the deliverable** (adjust scope, fix wording, add a section), never **its execution**.
 
-For the failure-mode catalog (Option 1 = "start now", re-asking after
-delivery, hand-off-to-execution drift, inferring acceptance from a
-thumbs-up) and the explicit bypass phrases that lift the fence, see
-[`scope-mechanics`](../contexts/authority/scope-mechanics.md)
-§ Fenced step.
+Failure-mode catalog (Option 1 = "start now", re-asking after delivery, hand-off-to-execution drift, inferring acceptance from a thumbs-up) and explicit bypass phrases: [`scope-mechanics § Fenced step`](../contexts/authority/scope-mechanics.md).

package/.agent-src/rules/security-sensitive-stop.md

@@ -4,6 +4,12 @@ tier: "2a"
 alwaysApply: false
 description: "Security-sensitive paths — auth, billing, tenant boundaries, secrets, file uploads, external integrations, webhooks, public endpoints — stop and run threat analysis BEFORE editing"
 source: package
+triggers:
+  - keyword: "auth"
+  - keyword: "billing"
+  - keyword: "tenant"
+  - keyword: "secret"
+  - keyword: "webhook"
 ---
 
 # Security-Sensitive Stop Rule
@@ -43,7 +49,7 @@ STOP writing code. Run the matching analysis skill first:
 | Wide refactor of security-sensitive code | `blast-radius-analyzer` |
 
 **Before running the analysis, consult memory for prior incidents** on
-this surface. Via [`memory-access`](../../docs/guidelines/agent-infra/memory-access.md):
+this surface. Via [`memory-access`](../docs/guidelines/agent-infra/memory-access.md):
 
 ```python
 from scripts.memory_lookup import retrieve

package/.agent-src/rules/size-enforcement.md

@@ -4,6 +4,11 @@ tier: "mechanical-already"
 description: "Creating or editing rules, skills, commands, guidelines, AGENTS.md, or copilot-instructions.md — enforce size and scope limits"
 alwaysApply: false
 source: package
+triggers:
+  - intent: "create rule"
+  - intent: "create skill"
+  - intent: "create command"
+  - intent: "create guideline"
 ---
 
 # size-enforcement
@@ -23,7 +28,7 @@ source: package
   - Rules and system instructions should stay well below 200 lines
   - Smaller (≈60 lines) is strongly preferred
 
-→ Size limits and details: `../../docs/guidelines/agent-infra/size-and-scope.md`
+→ Size limits and details: `../docs/guidelines/agent-infra/size-and-scope.md`
 
 → Frontmatter contract: schemas live in `scripts/schemas/` and are enforced by
 `python3 scripts/validate_frontmatter.py`.

package/.agent-src/rules/skill-improvement-trigger.md

@@ -2,58 +2,18 @@
 type: "auto"
 tier: "2a"
 description: "After completing a meaningful task — trigger post-task learning capture if pipelines.skill_improvement is enabled"
-alwaysApply: false
 source: package
+triggers:
+  - phrase: "after completing"
+  - keyword: "improvement"
+  - keyword: "pipeline"
+routes_to:
+  - "skill:skill-improvement-pipeline"
 ---
 
 # Skill Improvement Trigger
 
-## When to activate
+**Iron Law.** After a meaningful task, trigger the post-task learning capture if `pipelines.skill_improvement` is enabled.
 
-Read `pipelines.skill_improvement` from `.agent-settings.yml`.
-
-- **If `false` or missing** → do nothing. Stop here.
-- **If `true`** → continue.
-
-## What counts as "meaningful task"
-
-Trigger after completing tasks that involve:
-- Debugging a non-trivial bug (root cause wasn't obvious)
-- Implementing a feature that required learning something new
-- A pattern that worked well and should be remembered
-- A mistake that cost >5 minutes to diagnose
-- A workaround for a tool limitation
-
-## What does NOT trigger
-
-- Config changes, typos, docs-only edits
-- Routine tasks with no surprises
-- Tasks where the agent is just following instructions step by step
-- Tasks shorter than 3 messages
-
-## Trigger behavior
-
-After completing a qualifying task, do a **quick mental check** (not a full workflow):
-
-1. Was there a concrete, actionable learning?
-2. Is it generalizable (not project-specific one-off)?
-3. Is it NOT already covered by an existing rule or skill?
-
-If all 3 are YES → propose to the user:
-
-```
-> 💡 Learning detected: "{one-sentence summary}"
->
-> 1. Capture & improve — run the improvement pipeline
-> 2. Skip — not worth capturing
-```
-
-If user picks 1 → invoke the `skill-improvement-pipeline` skill.
-If user picks 2 → stop, do not ask again for this task.
-
-## Important
-
-- **Never auto-run the pipeline** — always ask first.
-- **Max 1 trigger per task** — don't ask repeatedly.
-- **Be honest** — if the learning is vague ("be more careful"), skip it silently.
-- **Do not interrupt the user's flow** — only trigger AFTER the task is done.
+Body migrated to `skill:skill-improvement-pipeline` (per P4 of `road-to-kernel-and-router.md`).
+Trigger-set above activates this routing under the `balanced` and `full` profiles.