@event4u/agent-config 1.19.0 → 1.21.0

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.

package/.agent-src/rules/skill-quality.md

@@ -2,73 +2,16 @@
 type: "auto"
 tier: "mechanical-already"
 description: "Creating, editing, or reviewing skills — minimum quality standard, every skill must be executable, validated, and self-contained"
-alwaysApply: false
 source: package
-load_context:
-  - .agent-src.uncompressed/contexts/communication/rules-auto/skill-quality-mechanics.md
+triggers:
+  - path_prefix: ".agent-src.uncompressed/skills/"
+routes_to:
+  - "guideline:agent-infra/skill-quality-checklist"
 ---
 
 # Skill Quality
 
-## Minimum Sharpness
+**Iron Law.** Every skill must be executable, validated, and self-contained — full checklist in the guideline.
 
-Every skill must answer four questions. If ANY answer is weak, the skill is not done.
-
-| # | Question | Section | Standard |
-|---|---|---|---|
-| 1 | When should I use this? | `When to use` | Concrete trigger, not generic |
-| 2 | What exactly do I do? | `Procedure` | Executable steps with decisions |
-| 3 | How do I verify it worked? | `Procedure` (validation step) | Concrete checks, not "verify it works" |
-| 4 | What common failure must I avoid? | `Gotcha` + `Do NOT` | Real failure patterns, not platitudes |
-
-## Required Sections
-
-Every skill MUST have: `When to use`, `Procedure`, `Gotcha`, `Output format`, `Do NOT`.
-
-## Frontmatter Contract
-
-Every skill's YAML frontmatter MUST validate against `scripts/schemas/skill.schema.json`.
-Violations are reported by `scripts/skill_linter.py` as `schema_<rule>` errors
-and fail `python3 scripts/validate_frontmatter.py` and the full CI pipeline.
-
-## Description Triggering
-
-Claude routes skills by their frontmatter `description`. Pushy,
-trigger-rich descriptions are required — polite or hedged ones cause
-undertriggering. The full recipe (concrete verb phrase, ≥2 triggers,
-`even if they don't explicitly ask for …` tail, ≤200 chars,
-litmus test) lives in
-[`contexts/communication/rules-auto/skill-quality-mechanics.md`](../contexts/communication/rules-auto/skill-quality-mechanics.md)
-§ Description Triggering.
-
-## Skill Independence
-
-```
-If a skill is not executable without opening a guideline, it is broken.
-```
-
-- Skills MAY reference guidelines for detailed conventions
-- Skills MUST NOT outsource their core workflow to guidelines
-- If removing guideline references makes the skill useless → the skill is too weak
-
-**Litmus test:** Cover all guideline references in the Procedure. Is it still executable?
-If not → the skill needs more own steps, decisions, and validation — not more guideline links.
-
-## Merge & Compression Preservation
-
-When merging or compressing skills, the result MUST preserve the
-strongest validation, strongest examples, all anti-patterns, all
-decision criteria, and trigger quality. Full preservation invariants
-and "merge is invalid if …" / "compression may remove …" lists in
-[`contexts/communication/rules-auto/skill-quality-mechanics.md`](../contexts/communication/rules-auto/skill-quality-mechanics.md)
-§ Merge Preservation and § Compression Preservation.
-
-## Refactor Safety
-
-When refactoring or optimizing skills:
-
-- NEVER weaken validation to pass linter
-- NEVER remove anti-patterns to reduce size
-- NEVER replace concrete checks with "verify it works"
-- NEVER merge skills if the result is broader than either source
-- ALWAYS run linter before and after — fail count must not increase
+Body migrated to `guideline:agent-infra/skill-quality-checklist` (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/slash-command-routing-policy.md

@@ -2,71 +2,19 @@
 type: "auto"
 tier: "1"
 description: "When user types a slash command like /create-pr, /commit, or pastes command file content"
-alwaysApply: false
 source: package
-load_context:
-  - .agent-src.uncompressed/contexts/communication/rules-auto/slash-command-routing-policy-mechanics.md
+triggers:
+  - keyword: "/create-pr"
+  - keyword: "/commit"
+  - keyword: "/fix-ci"
+  - phrase: "slash command"
+routes_to:
+  - "skill:command-routing"
 ---
 
-# Commands
+# Slash Command Routing Policy
 
-When the user types a command (`/create-pr`, `# create-pr`, or pastes a command file),
-**execute it immediately**. No questions, no opinions, no summaries, no confirmations.
+**Iron Law.** On a slash-command invocation or pasted command body, route to the matching command file; never improvise.
 
-- Match the command file in `.augment/commands/` (or `agents/overrides/commands/`).
-- Read it, follow the steps in order.
-- Ask only when the command itself says "ask the user".
-- If the user pastes the **content** of a command file, treat it as an invocation — not a question.
-- **NEVER** respond with "looks good" or ask "shall I execute?" — just execute.
-- **NEVER** respond with "this is the current version" or "do you want to change something?" — just execute.
-- **NEVER** treat pasted command content as a review request — it's ALWAYS an invocation.
-- The only exception: the user's message contains an explicit instruction about the command
-  (e.g., "update this command" or "review this command"). In that case, follow the instruction instead.
-
-## Open files are irrelevant for command detection
-
-The editor may report that the user has a file open (e.g., "The user has file `compress.md` open").
-This is **irrelevant** for command detection.
-
-- If the user types `/compress`, they want to **run** the compress command — even if `compress.md` is open in the editor.
-- If command file content appears in the context alongside an open file, the **command invocation takes priority**.
-- Do NOT confuse "file is open" with "user wants to discuss this file".
-- The user's typed message determines intent — not editor state.
-
-## Read the whole prompt — command is the operator, prose is the target
-
-```
-/<command> IS THE OPERATOR.
-THE REST OF THE USER MESSAGE NAMES THE TARGET.
-NEVER ASSUME THE COMMAND NAME IS THE TARGET.
-```
-
-Slash token = **what to do**; surrounding prose = **what to do it on**.
-
-- `/council and analyse chat-history` → target is `chat-history`,
-  not `council`. Council is the *tool*, prose names the *artefact*.
-- `/work the memory bug from PROJ-123` → target is "the memory bug
-  from PROJ-123".
-- `/fix ci and then open a PR` → target is "CI failure"; trailing
-  "open a PR" is a follow-up needing separate permission (per
-  `scope-control`).
-
-### Pre-flight before expensive operations
-
-Before any operation costing real time or money — external API call,
-large codebase analysis, multi-file refactor, council run, generated
-test suite — run silently:
-
-1. Re-read the **whole** user message, not just slash + first token.
-2. Identify the target the prose actually names.
-3. Target unambiguous → execute, no question.
-4. Target **genuinely** ambiguous after re-reading (prose names *two*
-   artefacts, can't tell which is the operand) → ask ONE
-   disambiguating numbered-options question per
-   [`ask-when-uncertain`](ask-when-uncertain.md), then proceed.
-
-**Not** a license to re-introduce cheap questions (`no-cheap-questions`
-still binds). Threshold: *"would this guess waste the user's tokens,
-money, or trust?"* — not *"I'd feel safer asking"*. Single failure
-mode to avoid: spending API spend on the wrong artefact because the
-agent fixated on the command name.
+Body migrated to `skill:command-routing` (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/think-before-action.md

@@ -4,100 +4,35 @@ tier: "2b"
 description: "Before coding, modifying, or debugging — analyze first, verify with real tools, never guess or trial-and-error"
 alwaysApply: false
 source: package
+load_context:
+  - ../contexts/communication/rules-auto/think-before-action-mechanics.md
+triggers:
+  - intent: "before coding"
+  - intent: "before debugging"
+  - intent: "before modifying"
 ---
 
 # think-before-action
 
-- Always analyze before coding or modifying anything
-- Never guess behavior — verify using code, data, or tools
-- Prefer targeted inspection over brute-force trial-and-error
-- Use efficient tooling (e.g. jq, debugger, logs) instead of loading full data
-- Always verify results after changes (API calls, UI tests, etc.)
-- When behavior can be defined, prefer test-first or test-driven work
-- If requirements are unclear, ask a precise clarification question instead of making hidden assumptions
-- Refactors must preserve behavior, validation, examples, and anti-failure guidance unless there is an explicit reason to change them
-- Do NOT modify code you do not fully understand — read it first, trace the flow, then change it
-- When multiple valid frameworks/patterns already exist in the codebase (e.g. Tailwind + Flux, multiple form libraries, competing state stores), do NOT pick one silently — ask which to use. See [`no blind implementation`](../../docs/guidelines/agent-infra/agent-interaction-and-decision-quality.md#2-no-blind-implementation)
+## The Iron Law
 
-## The Developer Workflow
+```
+ANALYZE BEFORE CODING. VERIFY WITH REAL TOOLS. NEVER GUESS.
+NO BLIND TRIAL-AND-ERROR. MAX 2 RETRIES PER APPROACH.
+```
 
-Work like a real developer — not a text generator. Follow this order strictly:
+- Always analyze before coding or modifying anything.
+- Never guess behavior — verify using code, data, or tools.
+- Prefer targeted inspection (jq, debugger, logs) over brute-force.
+- Always verify results after changes (API, UI, tests).
+- When behavior can be defined → prefer test-first / TDD.
+- Unclear requirements → precise clarification question, not hidden assumptions.
+- Refactors must preserve behavior, validation, examples, and anti-failure guidance unless explicitly changed.
+- Do NOT modify code you do not fully understand — read it, trace the flow, then change it.
+- Multiple valid frameworks/patterns coexist (Tailwind + Flux, multiple form libs, competing state stores) → do NOT pick one silently — ask. See [`no blind implementation`](../docs/guidelines/agent-infra/agent-interaction-and-decision-quality.md#2-no-blind-implementation).
 
-1. **Understand** — Read the task, ticket, acceptance criteria. If unclear: ask, don't assume.
-2. **Analyze** — Read affected code, trace data flow, compare with requirements and existing patterns.
-3. **Plan** — Decide what to change, what NOT to change, and how to verify success.
-4. **Implement** — Make focused changes. Follow existing patterns. No unrelated rewrites.
-5. **Verify** — Run tests, hit the endpoint, check the UI. Real execution, not "should work".
+## Mechanics — workflow, minimum read set, verify-with-real-tools, no blind retries
 
-Skipping steps 1-3 is the #1 cause of wrong implementations and wasted retries.
-
-## Minimum read set — read before you write
-
-Before editing code, read the minimum set that defines its behavior:
-
-1. **Symbol under edit** — full method/function body, not just the planned line.
-2. **Direct callers** — one level up (`grep -rn "<symbol>"` + open the matches).
-3. **Tests** — if a test file exists, it encodes the contract.
-4. **One layer of related abstractions** — interface, parent class, or trait (one hop, not the full hierarchy).
-5. **Data changes:** the migration that created the column + any seeder/factory that references it.
-
-Stop expanding once you can explain, in your own words, what the symbol does, who calls
-it, and what breaks if you change its behavior. If you cannot → read more. Never write
-code based on guessed behavior.
-
-### Consult memory before editing
-
-Prior decisions and invariants live in the memory layer. Via
-[`memory-access`](../../docs/guidelines/agent-infra/memory-access.md), call
-`retrieve(types=["architecture-decisions", "domain-invariants"], keys=<touched paths>, limit=3)`.
-A matching `architecture-decision` explains *why* the current shape
-exists; a matching `domain-invariant` is a hard constraint you cannot
-violate. Cite the `id` if a match influences the plan.
-
-## Verify with real tools
-
-Always verify changes with actual execution — not by reading code and assuming it works.
-
-| What changed | How to verify |
-|---|---|
-| **Backend/API** | `curl`, Postman (or Postman MCP if available), test endpoint |
-| **Frontend/UI** | Playwright MCP or browser — check rendered state, interactions |
-| **Logic/flow** | Xdebug (or Xdebug MCP if available) — trace execution, inspect variables |
-| **CLI/Jobs** | Run the command, check side effects, verify exit code |
-| **Database** | Query the result, check migrations ran correctly |
-
-If a debugging/testing tool is available as MCP server — prefer it over manual alternatives.
-
-If verification is not possible (no endpoint, no UI, no test): explicitly state what is missing
-and explain how the change should be tested.
-
-## Reduce output — targeted tools over full dumps
-
-Never load full datasets into context. Extract what you need:
-
-- `jq` for JSON: `curl -s /api/users | jq '.[0] | {id, email}'` — not the full response
-- `rg` / `grep` for text: search specific patterns, not full files
-- `head`, `tail`, `cut`, `sort`, `uniq` for narrowing results
-- `--filter`, `--json`, `--format` flags on CLI tools — use them
-- Laravel: `route:list --json | jq` over raw `route:list` dump
-- Logs: filter by request ID, timestamp, or error type — not full log files
-
-## No blind retries
-
-- If something fails: **read the error**, analyze the cause, then fix it
-- Do NOT retry the same approach hoping for a different result
-- Do NOT loop through trial-and-error when one targeted inspection would reveal the cause
-- Max 2 retries for the same approach — then stop and rethink
-
-## Open files are context, not intent
-
-The editor may report that the user has a file open. This is **background context only** —
-it does NOT mean the user's message is about that file.
-
-- **The user's message determines intent** — not which file is open.
-- A user can have `README.md` open and type `/compress` — the intent is to compress, not to discuss the README.
-- A user can have `UserController.php` open and ask "how do tests work?" — the intent is testing, not the controller.
-- Only treat the open file as relevant when the user's message explicitly references it
-  (e.g., "fix this file", "what does this do?", "update the open file").
+The five-step Understand → Analyze → Plan → Implement → Verify workflow, the minimum read set (symbol, callers, tests, abstractions, data), the memory-consult step, the verification matrix, the output-reduction patterns, the no-blind-retries protocol, and the "open files are context, not intent" clause all live in [`contexts/communication/rules-auto/think-before-action-mechanics.md`](../contexts/communication/rules-auto/think-before-action-mechanics.md). The rule above is the obligation surface; the mechanics file is the lookup material.
 
 If analysis is skipped → results are unreliable.

package/.agent-src/rules/token-efficiency.md

@@ -4,6 +4,12 @@ tier: "2a"
 description: "When running CLI tools, fetching logs, or producing replies — redirect verbose output, minimize tool calls, keep replies concise"
 alwaysApply: false
 source: package
+load_context:
+  - ../contexts/communication/rules-auto/token-efficiency-mechanics.md
+triggers:
+  - intent: "verbose CLI output"
+  - intent: "fetching logs"
+  - keyword: "minimize tool calls"
 ---
 
 # Token Efficiency
@@ -19,82 +25,12 @@ NEVER call the same tool more than 2 times in a row with similar parameters.
 If you catch yourself repeating a tool call — STOP, rethink, try a different approach, or ask the user.
 ```
 
-### Anti-loop: Extended Reasoning
-
-Do NOT use extended reasoning / chain-of-thought tools for simple tasks like viewing files,
-running commands, or making straightforward edits. They are ONLY for genuinely complex
-multi-step reasoning. If you find yourself calling such tools more than once per task —
-you are looping. Stop immediately and act directly instead.
-
-### Anti-loop: "CRITICAL INSTRUCTION" and self-prompting
-
-If you find yourself generating text that starts with "CRITICAL INSTRUCTION", "I need to",
-"Let me think", "Related tools:", or similar self-directed reasoning inside a tool call
-or as a preamble before acting — **you are in a loop**. This happens after connection errors
-or when the user says something like "continue" / "mach weiter".
-
-**Immediate action:**
-
-1. STOP generating self-instructions.
-2. Read the last user message — what did they actually ask?
-3. Do that ONE thing directly. No planning monologue, no tool selection reasoning.
-4. If you don't know what the user wanted, ask: "Where were we?"
-
 ## Fresh Output Over Memory
 
-**CRITICAL**: When a tool or command returns a value (branch name, file path, PR number),
-use that EXACT value in subsequent API calls. NEVER substitute a value from earlier in
-the conversation. Context decay causes silent mismatches — fresh output is the only source of truth.
-
-## Conversation Efficiency
-
-### Act, skip narration
-
-- **Skip repeating the user's request.** They know what they asked.
-- **Just do it** — skip announcing what you're about to do.
-- **Skip explaining obvious tool calls.** Reading a file needs no justification.
-- **Report only outcomes** — skip intermediate step summaries unless the user needs them.
-
-**This rule NEVER overrides user-interaction or command rules.**
-Token efficiency means fewer *unnecessary* words — NOT skipping required questions,
-numbered options, or command steps. When a rule or command says "ask the user", you ask.
-
-### Stop early — max 2 retries
-
-- **Command fails twice with same error** → stop, rethink. Try a different approach.
-- **grep/search returns nothing after 2 attempts** → switch approach or ask the user.
-- **Max 3 diagnostic commands** per error. Read the error, think, act.
-- **One hypothesis at a time.** Pick the most likely, try it. If it fails, ask.
-
-### Keep intermediate output minimal
-
-Read `personal.minimal_output` (default: `true`) and `personal.play_by_play`
-(default: `false`) from `.agent-settings.yml`.
-
-When `personal.minimal_output: true`:
-- Multi-step work: short bullet points only, no paragraphs.
-- No thinking out loud — user doesn't need your reasoning.
-- When `personal.play_by_play: false`: silently investigate, report conclusion only.
-- When `personal.play_by_play: true`: briefly share intermediate findings.
-- At the end: concise summary — what changed, what user needs to know.
-
-### Don't re-read what you already know
-
-- Edited a file → edit tool showed result. Don't re-read.
-- Ran a command → you have output. Don't re-run to "verify".
-- File in context from recent messages → don't reload.
-
-### Minimize tool calls
-
-- Parallel reads — don't read 5 files sequentially.
-- Regex search over full file reads. View specific line ranges.
-- One codebase search call with all symbols — not 5 separate.
-- Short question → short answer. Summary tables only for 3+ items.
+When a tool or command returns a value (branch name, file path, PR number), use that EXACT value in subsequent API calls. NEVER substitute a value from earlier in the conversation. Context decay → silent mismatches — fresh output is the only source of truth.
 
-### Exceptions
+## Mechanics — anti-loop patterns, conversation efficiency, exceptions
 
-- Small output (< 30 lines): read directly.
-- Debugging: OK to read more context around one error.
-- User explicitly asks for full output: show it.
+The anti-loop patterns (extended-reasoning loops, "CRITICAL INSTRUCTION" self-prompting), the act-skip-narration / stop-early / keep-output-minimal / don't-re-read / minimize-tool-calls clauses, and the small-output / debugging / explicit-full-output exceptions all live in [`contexts/communication/rules-auto/token-efficiency-mechanics.md`](../contexts/communication/rules-auto/token-efficiency-mechanics.md). The rule above is the obligation surface; the mechanics file is the lookup material.
 
-→ Detailed patterns: `docs/guidelines/agent-infra/output-patterns.md`
+This rule NEVER overrides `user-interaction` or command rules. Token efficiency means fewer *unnecessary* words — NOT skipping required questions, numbered options, or command steps.

package/.agent-src/rules/token-optimizer-maintenance.md

@@ -0,0 +1,68 @@
+---
+type: "auto"
+tier: "2a"
+description: "Editing a token-optimizer-cited asset (cli-output-handling, rtk-output-filtering, token-efficiency, agent-handoff, direct-answers, markitdown) — keep the catalog row in sync in the same commit."
+source: package
+triggers:
+  - keyword: "cli-output-handling"
+  - keyword: "rtk-output-filtering"
+  - keyword: "token-efficiency"
+  - keyword: "agent-handoff"
+  - keyword: "markitdown"
+  - keyword: "token-optimizer"
+routes_to:
+  - "skill:token-optimizer"
+validator_ignore:
+  - type: "substring"
+    pattern: ".agent-src.uncompressed/"
+    reason: "Rule lists the authoring-tree paths that must stay in sync with the catalog."
+---
+
+# Token Optimizer Maintenance
+
+## Iron Law
+
+```
+EDIT A CITED ASSET → UPDATE THE TOKEN-OPTIMIZER ROW IN THE SAME COMMIT.
+THE CI LINK VALIDATOR IS A BACKSTOP, NOT A SUBSTITUTE FOR CARE.
+```
+
+## When this rule fires
+
+About to edit any of:
+
+- `.agent-src.uncompressed/rules/cli-output-handling.md`
+- `.agent-src.uncompressed/rules/token-efficiency.md`
+- `.agent-src.uncompressed/rules/direct-answers.md`
+- `.agent-src.uncompressed/skills/rtk-output-filtering/SKILL.md`
+- `.claude/skills/agent-handoff/SKILL.md`
+- Any other asset cited by
+  [`token-optimizer`](../skills/token-optimizer/SKILL.md) (catalog
+  table is the canonical list).
+
+## Obligation
+
+If the edit touches:
+
+- **Trigger keywords** the decision tree associates with the asset, OR
+- **What the asset does** (the one-line "what it does" summary), OR
+- **The asset's path / location** (rename, move, deletion)
+
+then in the same commit, update the matching row in
+`.agent-src.uncompressed/skills/token-optimizer/SKILL.md` —
+the catalog table AND the relevant tree leaf.
+
+## Out of scope
+
+- Whitespace, comment, formatting, or grammar edits in the cited
+  asset → no token-optimizer update required.
+- Internal restructuring that leaves trigger + summary + path
+  unchanged → no update required.
+
+## Backstop
+
+The CI pipeline runs `scripts/check_token_optimizer_freshness.py`
+after the reference checker. The validator parses the catalog,
+verifies every cited path exists, and `grep`s the trigger keywords
+against each target. A failure is a **drift signal**, not a
+substitute for keeping the catalog correct manually.

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

@@ -3,6 +3,10 @@ type: auto
 tier: "2b"
 source: package
 description: "When a skill uses external tools — enforce allowlist, deny-by-default, and no hidden credential patterns"
+triggers:
+  - keyword: "allowed_tools"
+  - keyword: "tool registry"
+  - intent: "external API"
 ---
 
 # Tool Safety