@event4u/agent-config 1.20.0 → 1.21.0

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.

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

@@ -2,122 +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
-
-## Senior-Tier Required Structure
-
-Skills with `tier: senior` in YAML frontmatter MUST carry four named
-blocks beyond the standard required sections:
-
-| # | Block | Heading / Location | Standard |
-|---|---|---|---|
-| 1 | Context-First lead | Frontmatter `description` | First sentence anchors the cognition cluster (domain + senior role); second sentence names the trigger. |
-| 2 | Related Skills | `## Related Skills` | Two-list pattern — `**WHEN to use this**` (situations this skill resolves) + `**WHEN NOT to use this**` (route-elsewhere peers, named). |
-| 3 | Proactive Triggers | `## When the agent should load this` | 3–5 concrete user-prompt patterns (paraphrases users actually type), not abstract categories. |
-| 4 | Output Artifacts | `## Output` | 1–4 named artifacts with shape (file path, table, markdown structure) — orchestrator-citable identifier each. |
-
-**Forward-only.** `scripts/skill_linter.py` enforces these blocks for
-`tier: senior` skills only; mid-tier and untiered skills skip the
-check. No retrofit pass on existing Wing-1 skills.
-
-Subsection specs (≤ 6-line spec + 1 reference example each), good /
-bad pattern pairs, and the WHEN-NOT routing peer rules live in
-[`contexts/communication/rules-auto/skill-quality-mechanics.md`](../contexts/communication/rules-auto/skill-quality-mechanics.md)
-§ Senior-tier patterns.
-
-## Structural Malice Floor
-
-`scripts/skill_linter.py` runs five regex patterns against every
-skill / rule / command body — credential exfiltration, remote
-execution, force-push to a protected ref, world-readable secret
-files, and shell-injection in subprocess calls. A match emits
-``Issue("error", "malice:<pattern>", "<line>:<matched>")`` and the
-linter exits with code **3** (security-failure), distinct from
-exit 2 (build-failure) so CI surfaces can split the two.
-
-The check is **structural**, not semantic — it catches the shapes
-the [`tool-safety`](tool-safety.md) rule denies in prose: hidden
-credentials, arbitrary execution, write-without-approval. Fixtures
-and the exit-code-3 contract live in
-[`tests/test_skill_linter_malice.py`](../../tests/test_skill_linter_malice.py).
-
-## Confidence Tagging
-
-Senior-tier procedure steps MAY append `[CONFIDENCE: high|medium|low]`
-at the end of multi-step chains where the agent's evidence varies
-across steps. Optional but recommended when a step's output feeds a
-downstream decision.
-
-Text-tag form is deliberate. Emoji 🟢 / 🟡 / 🔴 is **not** allowed —
-collides with [`direct-answers`](direct-answers.md) § Emoji scope
-(functional markers only). Linter does not enforce the tag itself;
-the rule documents the placement so authors converge on one form.
+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.