@event4u/agent-config 1.20.0 → 1.22.0

package/.agent-src/contexts/execution/roadmap-process-loop.md

@@ -0,0 +1,125 @@
+# Roadmap-Process Loop
+
+Loaded by [`/roadmap:process-step`](../../commands/roadmap/process-step.md),
+[`/roadmap:process-phase`](../../commands/roadmap/process-phase.md), and
+[`/roadmap:process-full`](../../commands/roadmap/process-full.md). Holds
+the canonical autonomous-execution loop, roadmap discovery, cadence
+resolution, commit-step pre-scan, halt conditions, and archival check.
+The three command files are thin wrappers that bind only the **scope
+delta**.
+
+**Size budget:** ≤ 4,000 chars.
+
+## 1. Resolve roadmap
+
+Search both locations:
+
+- `agents/roadmaps/*.md` (project root)
+- `app/Modules/*/agents/roadmaps/*.md` (module-scoped)
+
+**Exclude** `template.md`, `archive/`, and `skipped/`.
+
+- User named one (path, partial name, title) → use it.
+- None named, single active roadmap (`count_open > 0`) → use it.
+- None named, multiple active → default = **most recently modified**;
+  surface alternatives in the pre-run summary.
+- None active → tell the user; suggest [`/roadmap:create`](../../commands/roadmap/create.md).
+
+## 2. Pre-run summary — single confirmation gate
+
+Before the loop runs, show the resolved config in the user's language:
+
+> Roadmap: `<resolved-path>`
+> Phase 1: `<name>` — 3/5 done
+> Phase 2: `<name>` — 0/4
+> Next open step: `<description>`
+> Scope: **step | phase | full**
+> AI council: **on | off** (`<member list or "no members configured">`)
+> Quality cadence: **end_of_roadmap | per_phase | per_step**
+> Commit steps in roadmap: **N** (see § 3)
+>
+> 1. Go — start processing autonomously
+> 2. Different roadmap · 3. Different scope · 4. Toggle council · 5. Abort
+
+Skip the gate when scope, roadmap, and council are all unambiguous in
+the invocation (e.g. `/roadmap:process-phase road-to-X.md with council`).
+
+## 3. Commit-step pre-scan — one upfront ask
+
+Before step 4, scan the roadmap for explicit commit steps (lines
+matching `commit:` / `git commit` / `Commit phase` patterns).
+
+- **No commit steps** → nothing to ask. Never commit, never re-ask
+  per [`commit-policy`](../../rules/commit-policy.md).
+- **Commit steps present, autonomous mode** (`personal.autonomy: on`,
+  or `auto` after opt-in) → ask **once** upfront:
+  > "Roadmap contains N commit steps. Authorize all of them for this
+  > run? (yes / no / list them)"
+  Cache the answer for the whole run; do **not** re-ask per step.
+  Hard-Floor diffs (bulk deletions, infra) still trigger the
+  per-commit gate from [`commit-mechanics`](../authority/commit-mechanics.md).
+- **Commit steps present, non-autonomous** → ask before each commit
+  step inside the loop.
+
+## 4. Resolve quality cadence
+
+Read `roadmap.quality_cadence` from `.agent-settings.yml` once:
+
+| Value | Pipeline runs |
+|---|---|
+| `end_of_roadmap` (default) | Once, before archival (§ 6) |
+| `per_phase` | At every phase boundary + § 6 |
+| `per_step` | After every step + § 6 |
+
+Missing / unreadable / unknown → fall back to `end_of_roadmap`.
+The Iron Law [`verify-before-complete`](../../rules/verify-before-complete.md)
+still mandates fresh quality output before any "complete" claim.
+
+## 5. Step loop
+
+For each open step in the working set (scope-bound — see wrapper):
+
+1. Read the step description and inline notes.
+2. Analyze the codebase for what the step requires.
+3. Decide and act — implement. **No "should I implement this?" prompt.**
+4. **Open question handling:**
+   - **Council on** → invoke per [`ai-council`](../../skills/ai-council/SKILL.md),
+     integrate convergence, proceed. Token spend was opted in.
+   - **Council off** → halt, surface once, wait. Resume on next turn.
+5. Mark the checkbox: `[x]` done · `[~]` partial · `[-]` skipped.
+6. Regenerate the dashboard — `./agent-config roadmap:progress` — in
+   the **same response** per [`roadmap-progress-sync`](../../rules/roadmap-progress-sync.md).
+7. Run quality pipeline if cadence is `per_step`.
+
+### Halt conditions
+
+- Hard-Floor trigger ([`non-destructive-by-default`](../../rules/non-destructive-by-default.md))
+- Security-sensitive path ([`security-sensitive-stop`](../../rules/security-sensitive-stop.md))
+- Step reveals work outside the roadmap's scope
+- Test failure or quality red on `per_step`
+- Council off + true ambiguity
+
+On halt: stop, surface state, do **not** auto-fix outside the failing step.
+
+## 6. Final report and archival
+
+- Summary: scope-bound (steps/phases done in this run), council
+  consultations count (if on), steps remaining, halts.
+- Final dashboard regen.
+- **If the entire roadmap reached `count_open == 0`** → run the full
+  project quality pipeline. On green → archival via the
+  [`roadmap-management`](../../skills/roadmap-management/SKILL.md) skill
+  (`git mv` to `agents/roadmaps/archive/`, regenerate dashboard). On
+  red → stop, surface failures, do **not** archive.
+
+## Scope deltas — what each wrapper binds
+
+| Wrapper | Working set | Stop after |
+|---|---|---|
+| `process-step` | Single first open step | One iteration of § 5 |
+| `process-phase` | All open steps in first phase with `count_open > 0` | Phase boundary; per-phase quality if cadence ≠ `end_of_roadmap` |
+| `process-full` | Every open step across every phase, in order | Roadmap fully closed (or halt) |
+
+`process-full` runs the per-phase quality pipeline at every phase
+boundary when cadence is `per_phase` or `per_step`; on red it halts
+before the next phase.

package/.agent-src/contexts/model-recommendations.md

@@ -91,7 +91,7 @@ produce opus-level quality by enforcing habits that weaker models skip by defaul
 - **Default to `sonnet`** — it's the cost-efficient workhorse.
 - **Escalate to `opus`** only when architecture, refactoring, or unclear debugging is involved.
 - **After Opus work** (architecture plan, refactoring design, root cause found):
-  → Recommend switching back to `sonnet` for implementation.
+  → Recommend switching back to `sonnet` for impl.
 - **Use `gpt`** for large-scale analysis, searching across many files, or automation.
 
 ## Recommendation Flow
@@ -121,7 +121,7 @@ When user says they want to continue with the current model:
 ### Downgrade reminder
 
 After completing an opus-level task (architecture plan done, refactoring complete, root cause found),
-remind the user to switch back to sonnet for the implementation phase:
+remind the user to switch back to sonnet for the impl phase:
 
 ```
 > 💡 The {architecture/debugging/design} phase is done.

package/.agent-src/contexts/override-system.md

@@ -155,7 +155,7 @@ When a project using this package wants to **optimize** a shared rule or skill:
 
 ### Anti-patterns
 
-- Keeping the override after upstream merge → causes drift
+- Keeping the override after upstream merge → → drift
 - Submitting only the compressed version → breaks source-of-truth workflow
 - Submitting project-specific behavior as universal improvement
 - Forgetting to create the PR → improvement stays siloed

package/.agent-src/contexts/skills-and-commands.md

@@ -30,7 +30,7 @@ Commands often chain together. Here are the main workflows:
 ### Feature Development
 
 ```
-/feature-explore → /feature-plan → /feature-roadmap → /roadmap-execute
+/feature-explore → /feature-plan → /feature-roadmap → /roadmap:process-phase
      ↓                  ↓                ↓                    ↓
   Brainstorm        Structure         Phases/Steps        Implement
 ```

package/.agent-src/personas/product-owner.md

@@ -52,12 +52,12 @@ Concrete and user-facing. Each finding names a missing outcome, an
 unverifiable AC, or a scope item whose removal would not hurt the
 user. When the persona proposes a rewritten AC, it is a single
 sentence in the form "the user can X when Y". Findings that are
-purely implementation concerns are out of scope — escalate to
+purely impl concerns are out of scope — escalate to
 `developer` or `senior-engineer`.
 
 ## Anti-Patterns
 
-- Do NOT write implementation details or technical designs — that
+- Do NOT write impl details or technical designs — that
   is the `developer` and `senior-engineer` space.
 - Do NOT invoke "business value" as an argument without naming the
   user and the outcome.

package/.agent-src/personas/qa.md

@@ -38,7 +38,7 @@ It is the lens that refuses to confuse coverage with confidence.
   test would catch?
 - Which assertion is missing — the one that would have caught the
   bug we just fixed, or the bug one ticket away?
-- Where is the test verifying the implementation instead of the
+- Where is the test verifying the impl instead of the
   behavior?
 - Which boundary — empty, null, max, concurrent, re-entrant — is
   not represented in the test suite for this code path?

package/.agent-src/rules/agent-authority.md

@@ -8,7 +8,7 @@ source: package
 
 # Agent Authority — Priority Index
 
-Four rules answer **"may the agent do this autonomously?"** Check bands in order; higher band wins.
+Four rules answer **"may the agent do this autonomously?"** Higher band wins.
 
 | Band | Trigger | Canonical rule |
 |---|---|---|
@@ -17,9 +17,8 @@ Four rules answer **"may the agent do this autonomously?"** Check bands in order
 | **3. Commit Default** | About to commit — never, unless one of four exceptions fires | [`commit-policy`](commit-policy.md) |
 | **4. Trivial-vs-Blocking** | Routine workflow question — act or ask | [`autonomous-execution`](autonomous-execution.md) |
 
-## Index rules
+## Rules
 
-- **Hard Floor wins, always.** No autonomy setting, roadmap step, or standing instruction lifts it.
-- **Higher band wins on conflict.** Commit exception ≠ Hard Floor override; scope permission ≠ commit override.
-- **Index never restates an Iron Law.** Iron Laws live verbatim in canonical files; this router only points.
-- **Unsure → ask.** [`ask-when-uncertain`](ask-when-uncertain.md) is the universal escape hatch.
+- Hard Floor wins, always — autonomy / roadmap / standing instruction never lift.
+- Higher band wins on conflict — commit exception ≠ Hard Floor override; scope permission ≠ commit override.
+- Unsure → [`ask-when-uncertain`](ask-when-uncertain.md).

package/.agent-src/rules/agent-docs.md

@@ -3,60 +3,18 @@ type: "auto"
 tier: "2a"
 description: "Reading, creating, or updating agent documentation, module docs, roadmaps, or AGENTS.md"
 source: package
+triggers:
+  - path_prefix: "agents/"
+  - path_prefix: ".github/copilot-instructions"
+  - keyword: "AGENTS.md"
+  - keyword: "roadmap"
+routes_to:
+  - "skill:agent-docs-writing"
 ---
 
-# Agent Documentation
+# Agent Docs
 
-## When to read agent docs
+**Iron Law.** Read agent docs (`AGENTS.md`, `agents/`, module `agents/`) before work; update them after structural changes.
 
-**Before starting ANY work**, read the relevant documentation:
-
-1. **Always read** `AGENTS.md` (if it exists in the project root) for project-level setup and conventions.
-2. **Always read** `./agents/` for project-specific architecture, guidelines, and domain docs.
-3. **If domain contexts exist** (`agents/contexts/domain/`) → read any that are relevant to the current work area.
-4. **If working on a module** → also read `app/Modules/{Module}/agents/` for module-specific docs,
-   including `agents/contexts/` within the module if it exists.
-5. **If working on a package** → read the package's `./agents/` directory.
-6. **If a roadmap exists** for the current work → read it first and follow its steps.
-
-## When to update agent docs
-
-After making changes, check if any agent docs need to be updated:
-
-- **New module created** → create `app/Modules/{Module}/agents/` with at least a module description.
-- **Database schema changed** → update `agents/docs/database-setup.md` or equivalent.
-- **New service/pattern introduced** → update relevant guideline docs.
-- **Roadmap step completed** → mark it as done in the roadmap file (`[x]`).
-- **Structural changes** (new conventions, renamed classes, moved files) → update affected docs.
-
-If unsure whether a doc needs updating, **ask the user**.
-
-## When to create roadmaps
-
-When working on a **significant change** that spans multiple steps or sessions:
-
-- Ask the user whether to create a roadmap in `agents/roadmaps/`.
-- Use the `roadmap-create` command if yes.
-- This ensures future sessions (and other agents) can pick up the work.
-
-## Roadmap lifecycle
-
-Every roadmap ends in exactly one folder — never leave stale files in `agents/roadmaps/`:
-
-- `agents/roadmaps/` — active (in progress or planned)
-- `agents/roadmaps/archive/` — finished (work happened, fully or partially)
-- `agents/roadmaps/skipped/` — not pursued (typically 0 items `[x]`, scope rejected or superseded)
-
-The `roadmap-management` skill owns the trigger matrix and user-confirmation flow.
-Never delete a roadmap — always move it.
-
-## Documentation language
-
-- All `.md` files must be written in **English**.
-- If an existing file is in German or another language, translate it to English when you touch it.
-
-## Do NOT
-
-- Do NOT create docs unless there's a real need (new module, significant change, etc.).
-- Do NOT duplicate information that's already in `AGENTS.md` or `.github/copilot-instructions.md`.
-- Do NOT write docs just to document what you did — only document things others need to know.
+Body migrated to `skill:agent-docs-writing` (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/analysis-skill-routing.md

@@ -1,49 +1,19 @@
 ---
-type: auto
+type: "auto"
 tier: "3"
 description: "When choosing an analysis skill, route to the narrowest matching skill instead of defaulting to broad analysis"
 source: package
+triggers:
+  - keyword: "analyze"
+  - keyword: "analysis"
+  - phrase: "dig into the codebase"
+routes_to:
+  - "skill:analysis-skill-router"
 ---
 
 # Analysis Skill Routing
 
-When choosing an analysis skill, always route to the narrowest skill that still matches the actual problem shape.
+**Iron Law.** Route analysis tasks to the narrowest matching `project-analysis-*` skill, not the broad fallback.
 
-Use `universal-project-analysis` only for:
-
-* full project analysis
-* deep architecture review
-* broad multi-layer debugging
-* unclear systems where the stack or boundaries must first be discovered
-
-Use framework-specific project-analysis skills only after the framework is known.
-
-Use root-cause analysis skills when the problem is concrete and hypothesis-driven.
-
-Do not use broad analysis skills for:
-
-* small isolated code questions
-* normal feature work
-* obvious local fixes
-* framework-specific issues that already have a dedicated skill
-
-Prefer:
-
-* narrow specialist skill over broad analysis skill
-* framework-specific skill over universal router when the framework is already explicit
-* root-cause skill over full-project analysis when the issue is already localized
-
-If the stack is unclear:
-
-* start broad
-* then narrow quickly
-
-## Routing quality gate
-
-Only route to the narrower skill if it still has:
-
-* executable workflow (concrete procedure steps)
-* concrete validation (specific checks, not "verify it works")
-* real decision power (not just "read the guideline")
-
-If the narrow skill is too weak or hollowed out, route through the broader skill and note the gap.
+Body migrated to `skill:analysis-skill-router` (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/architecture.md

@@ -4,6 +4,11 @@ tier: "3"
 alwaysApply: false
 description: "Architecture rules for creating new files, classes, controllers, modules, or making structural decisions about project organization"
 source: package
+triggers:
+  - keyword: "controller"
+  - keyword: "service"
+  - keyword: "module"
+  - intent: "structural decision"
 ---
 
 # Architecture Rules
@@ -11,7 +16,7 @@ source: package
 ## General Principles
 
 - **Controllers are thin** — no business logic, delegate to services.
-- **Only Single Action Controllers** — every new controller MUST use `__invoke()`. No multi-action / resource controllers. See `../../docs/guidelines/php/controllers.md` for naming conventions.
+- **Only Single Action Controllers** — every new controller MUST use `__invoke()`. No multi-action / resource controllers. See `../docs/guidelines/php/controllers.md` for naming conventions.
 - **Every controller needs a FormRequest** — never validate inline with `$request->validate()`. Use a dedicated `FormRequest` subclass.
 - **Services contain business logic** — calculations, orchestration, validation.
 - **Models have no business logic** — only relationships, scopes, accessors/mutators.

package/.agent-src/rules/artifact-drafting-protocol.md

@@ -4,6 +4,11 @@ tier: "2a"
 alwaysApply: false
 description: "Creating a new skill, rule, command, or guideline, or significantly rewriting one — runs a mandatory Understand → Research → Draft sequence before any artifact content is written."
 source: package
+triggers:
+  - intent: "create new skill"
+  - intent: "create new rule"
+  - intent: "create new command"
+  - intent: "create new guideline"
 ---
 
 # Artifact Drafting Protocol

package/.agent-src/rules/artifact-engagement-recording.md

@@ -4,75 +4,39 @@ tier: "mechanical-already"
 alwaysApply: false
 description: "After a /implement-ticket or /work phase-step (refine/memory/analyze/plan/implement/test/verify/report) or full task — emit one telemetry:record call with consulted+applied ids when enabled"
 source: package
+triggers:
+  - phrase: "/implement-ticket"
+  - phrase: "/work"
+  - keyword: "telemetry"
+routes_to:
+  - "contract:artifact-engagement-flow"
 load_context:
-  - .agent-src.uncompressed/contexts/communication/rules-auto/artifact-engagement-recording-mechanics.md
+  - "../contexts/contracts/artifact-engagement-flow.md"
 ---
 
 <!-- cloud_safe: noop -->
 
 # Artifact Engagement Recording
 
-Records which **skills, rules, commands, guidelines, personas** the agent
-actually consulted and applied during a `/implement-ticket` or `/work` run.
-Default-off; opt-in via `.agent-settings.yml`. Zero overhead when disabled.
+**Iron Law.** After a `/implement-ticket` or `/work` phase-step, emit one
+`telemetry:record` call with consulted + applied ids when telemetry is
+enabled. Default-off; opt-in via `.agent-settings.yml`. Zero overhead when
+disabled. Recording contract + privacy floor:
+[`contexts/contracts/artifact-engagement-flow.md`](../contexts/contracts/artifact-engagement-flow.md).
 
-The schema, CLI, and storage layer are owned by
-[`scripts/telemetry/`](../../../scripts/telemetry/) and the
-`./agent-config telemetry:record` / `telemetry:status` commands. The
-recording contract lives in
-[`docs/contracts/artifact-engagement-flow.md`](../../docs/contracts/artifact-engagement-flow.md).
-This rule says **when** to call the CLI, not how the file is structured.
+The schema, CLI, and storage layer are owned by `scripts/telemetry/` and
+the `./agent-config telemetry:record` / `telemetry:status` commands.
 
-## Activation gate — read settings ONCE per task, then cache
+## Activation gate — read settings ONCE per task
 
-Before the first `/implement-ticket` or `/work` step runs, read
-`telemetry.artifact_engagement.enabled` from `.agent-settings.yml`. Cache
-the value (and `granularity`) for the whole task.
+Before the first phase-step runs, read
+`telemetry.artifact_engagement.enabled`. Cache the value (and
+`granularity`) for the whole task.
 
-- `enabled: false` or section missing → rule is a **no-op**. Do not import
-  the script, do not open the log, do not mention recording. Skip the rest
-  of this rule.
-- `enabled: true` → continue with the cadence below.
+- `enabled: false` or section missing → rule is a **no-op**.
+- `enabled: true` → continue with the cadence in the contract.
 
-Use `./agent-config telemetry:status --format json` if the value is
-not already in working memory; the call is read-only and never touches
-the log file.
+## Cloud Behavior
 
-## Cadence — depends on `granularity`
-
-| `granularity` | When to emit | Coalescing |
-|---|---|---|
-| `task` *(default)* | Once, when the eight-step flow ends (success, blocked, partial — any terminal state) | All consulted/applied artefacts from refine through report merged into a single event |
-| `phase-step` | At the close of each phase-step (refine, memory, analyze, plan, implement, test, verify, report) | One event per step; per-step consulted/applied lists only |
-
-Within a single boundary, **dedupe** consulted and applied lists. A skill
-consulted three times in the same boundary records once.
-
-## What counts as consulted vs applied
-
-- **`consulted`** — the agent **read** the artefact this boundary: opened
-  its `SKILL.md`, scanned its rule body, viewed its frontmatter,
-  referenced its guideline, checked its persona contract, dispatched its
-  command. Reading does not imply behaviour change.
-- **`applied`** — the artefact **influenced the output** this boundary:
-  its instructions changed how the agent answered, what code it wrote,
-  what tools it ran, or what halt surface it produced. Applied is a
-  strict subset of consulted.
-
-When in doubt → record as `consulted` only. Over-recording `applied`
-inflates the engagement signal and defeats the purpose.
-
-## Mechanics — CLI invocation, privacy contract, failure handling
-
-The exact `telemetry:record` call shape with all flags, the privacy
-contract (what NEVER goes into a record), the failure-mode handling
-(do NOT block the user's task), and the "what this rule does NOT do"
-catalog live in
-[`contexts/communication/rules-auto/artifact-engagement-recording-mechanics.md`](../contexts/communication/rules-auto/artifact-engagement-recording-mechanics.md).
-
-## See also
-
-- [`docs/contracts/artifact-engagement-flow.md`](../../docs/contracts/artifact-engagement-flow.md) — recording contract details
-- [`/implement-ticket`](../commands/implement-ticket.md) and [`/work`](../commands/work.md) — boundary points where this rule fires
-- [`scripts/telemetry/`](../../../scripts/telemetry/) — engine source
-- [`agent-settings`](../templates/agent-settings.md) — `telemetry.artifact_engagement.*` reference
+The `cloud_safe: noop` marker keeps this rule inert on cloud surfaces
+(Claude.ai Web, Skills API). The cloud-bundle pipeline skips it.

package/.agent-src/rules/ask-when-uncertain.md

@@ -8,8 +8,7 @@ source: package
 
 # Ask When Uncertain
 
-**When in doubt, ask the user.** Do not guess, assume, or improvise.
-Asking one question too many is always better than a wrong assumption.
+**When in doubt, ask.** Don't guess, assume, or improvise. One question too many beats one wrong assumption.
 
 ## Iron Law — one question per turn, ALWAYS
 
@@ -18,22 +17,19 @@ ONE QUESTION PER TURN. NO EXCEPTIONS.
 ASK. WAIT FOR THE ANSWER. THEN ASK THE NEXT.
 ```
 
-Absolute. Not a default, not "usually". Every turn with a question
-has **exactly one**. Even if trivial, independent, or batchable.
-Self-check, ordering, handoff under [How to ask](#how-to-ask).
+Absolute. Every turn with a question has **exactly one** — even if trivial, independent, or batchable.
 
 ## When to ask
 
-- Requirement ambiguous or multi-interpretable
-- Not 100% sure which approach is correct
-- About to touch code you haven't fully understood
-- Choosing between multiple valid approaches
-- A fix "seems to work" but you can't explain why
+- Requirement ambiguous or multi-interpretable.
+- Not 100 % sure which approach is correct.
+- About to touch code you haven't fully understood.
+- Choosing between multiple valid approaches.
+- A fix "seems to work" but you can't explain why.
 
 ## Vague-request triggers — MUST ask
 
-These patterns are too vague to execute safely. Match without further
-context → ask **before** touching code:
+Match without further context → ask **before** touching code:
 
 - "improve / optimize this" — metric? speed, readability, memory?
 - "add caching" — store? scope? invalidation?
@@ -45,52 +41,33 @@ context → ask **before** touching code:
 - "handle errors properly" — which errors? log/retry/propagate?
 - "add a UI/component/tile/page" in mixed-framework repo — which stack?
 
-Example questions per pattern:
-[`asking-and-brevity-examples`](../../docs/guidelines/agent-infra/asking-and-brevity-examples.md#vague-request-triggers--example-questions).
+Examples: [`asking-and-brevity-examples § vague-triggers`](../docs/guidelines/agent-infra/asking-and-brevity-examples.md#vague-request-triggers--example-questions).
 
-**Escape hatch:** if context (ticket, open file, prior turn) makes
-the answer unambiguous, proceed — but state the assumption.
+**Escape hatch:** unambiguous from ticket / open file / prior turn → proceed, state the assumption.
 
 ## How to ask
 
-Numbered options (per `user-interaction`). Short. The Iron Law is at
-the top; this section adds self-check and ordering.
-
-The user must never track sub-numbers, scroll stacked option blocks,
-or split a reply across multiple questions. Rationale shorthand: if
-the user has to *think* about an answer, that answer almost always
-reframes the next question. Full rationale:
-[`asking-and-brevity-examples`](../../docs/guidelines/agent-infra/asking-and-brevity-examples.md#one-question-per-turn--why-serial-always-wins).
+Numbered options (per [`user-interaction`](user-interaction.md)). Short.
 
 ### Self-check before asking
 
-Before sending a turn with a question, ask yourself:
-
-1. Does this turn contain more than one `?` directed at the user?
-2. Does this turn present two or more separate numbered-option blocks?
-3. Would the user need to reply with a structured answer (`1a, 2b`)
-   instead of a single number or word?
+1. More than one `?` directed at the user this turn?
+2. Two or more separate numbered-option blocks?
+3. User would need a structured reply (`1a, 2b`) instead of a single number?
 
-If any answer is "yes" → **collapse to ONE question** and send. Hold
-every other question for its own turn. No exceptions, no "but these
-are related".
+Any "yes" → **collapse to ONE question**. Hold the rest for their own turn. Rationale: [`asking-and-brevity-examples § serial-wins`](../docs/guidelines/agent-infra/asking-and-brevity-examples.md#one-question-per-turn--why-serial-always-wins).
 
 ### Ordering & handoff
 
-- **Session handoff** (`/agent-handoff`, fresh-chat proposal): ask LAST,
-  after all domain / clarifying questions — so the user's answers can be
-  folded into the handoff prompt. Full rationale in
-  [`agent-interaction-and-decision-quality`](../../docs/guidelines/agent-infra/agent-interaction-and-decision-quality.md#handoff--model-switch-questions).
-- **Model switch**: different phase — [`model-recommendation`](model-recommendation.md)
-  triggers at task start with its own STOP-AND-WAIT gate, standalone, not
-  appended to a Q&A block. Do not conflate the two.
-- **Blocking clarification** (can't proceed without it): ask FIRST,
-  alone, before any research or planning output.
-- **Optional refinement**: don't ask at all — state the assumption
-  and proceed.
+- **Session handoff** (`/agent-handoff`, fresh-chat) — ask LAST, after domain / clarifying questions, so answers fold into the handoff. Full: [`agent-interaction-and-decision-quality § handoff`](../docs/guidelines/agent-infra/agent-interaction-and-decision-quality.md#handoff--model-switch-questions).
+- **Model switch** — [`model-recommendation`](model-recommendation.md) STOP-AND-WAIT gate is standalone, not appended.
+- **Blocking clarification** — ask FIRST, alone, before any research or planning output.
+- **Optional refinement** — don't ask; state the assumption, proceed.
 
 ## Creating new agent artifacts
 
-For skill/rule/command/guideline creation or major rewrite, follow
-[`artifact-drafting-protocol`](artifact-drafting-protocol.md) — structured
-Understand → Research → Draft. Don't improvise questions.
+Skill / rule / command / guideline creation or major rewrite → [`artifact-drafting-protocol`](artifact-drafting-protocol.md) (Understand → Research → Draft). Don't improvise questions.
+
+## Examples
+
+Pattern Memory (wrong / right / why): [`ask-when-uncertain-demos`](../docs/guidelines/agent-infra/ask-when-uncertain-demos.md). Outcome baseline: [`tests/golden/outcomes/ask_when_uncertain.json`](../../tests/golden/outcomes/ask_when_uncertain.json).