@bonesofspring/ai-rules 0.2.19 → 0.2.20

package/presets/claude/ios-swift/skills/debug-investigation/SKILL.md

@@ -3,9 +3,37 @@ name: debug-investigation
 description: Investigates bugs, failing tests, crashes, and incorrect behavior with runtime evidence before applying minimal fixes. Use for bugfix tasks, debugger agent runs, regressions, and flaky test diagnosis.
 ---
 
-# Debug Investigation (iOS)
+<!-- shared-core: quality/debug-investigation.md -->
+
+# Debug investigation
+
+Stack-agnostic root-cause loop. Consumed by skill `debug-investigation` and agent `debugger`. Platform paths, MCP, and stack commands belong in adapter **Stack notes**.
+
+## When
+
+Any bug, test failure, build failure, or unexpected behavior — **before** proposing a fix.
+
+## Phases (in order)
+
+1. **Evidence** — reproduce, or collect the closest evidence (error output, failing test, logs, user steps).
+2. **Isolate** — expected vs actual in one sentence; smallest relevant slice of the codebase.
+3. **Root cause** — name the cause before editing. One hypothesis at a time; do not stack speculative fixes.
+4. **Minimal fix + verify** — smallest change that preserves architecture and public contracts. Add a regression test when the behavior is user-facing or likely to recur. Re-run the **failing** check first, then the relevant lint/type/test slice.
+
+## 3-fix architecture gate
+
+If **three** fix attempts fail, or the same symptom returns after two supposed fixes: **STOP**. Do not attempt fix #4. Escalate — the design is likely wrong (human partner or `solution-architect`). Chasing symptoms is the failure mode.
+
+## Do not
+
+- Broad refactor during a bugfix.
+- Fix only where the error surfaces if invalid data originates elsewhere.
+- Claim `fixApplied: true` without re-running the failing check (see `quality/verification-before-completion.md`).
+
+## Stack notes
+
+### Stack process
 
-## Process
 
 1. Reproduce the issue or collect the closest available evidence: Xcode console, lldb backtrace, crash log, failing XCTest/XCUITest output, Instruments note, or user steps.
 2. Define expected vs actual behavior in one sentence.
@@ -15,7 +43,7 @@ description: Investigates bugs, failing tests, crashes, and incorrect behavior w
 6. Add or update a regression XCTest when the behavior is domain/VM logic or likely to recur.
 7. Run the narrow failing check first (`xcodebuild test` for the affected target), then broader build validation if needed (`tooling-and-review/xcode-tooling.md`).
 
-## Artifacts
+### Artifacts
 
 For agent team tasks, write `.claude/team/tasks/<slug>/debug-report.md` with:
 
@@ -30,13 +58,13 @@ Agent team: upsert the owned terminal receipt in `artifact-manifest.json`; do no
 Do not use browser/Playwright tooling — this is an Xcode stack.
 
 
-## MCP usage
+### MCP usage
 
 Load requestable rule `mcp-usage` when verifying third-party library APIs (Context7) or when a local overlay MCP is present and the task fits. Discover tools at runtime; do not invent schemas. Overlay absence is not a blocker unless the user required that MCP as source of truth.
 
 If a Sentry/Datadog (or similar) MCP is ready and the task is a production error, event, or trace, use it. Do not invent telemetry.
 
 
-## Design guidance
+### Design guidance
 
 - Load `design-guidance` (rule stem) when assessing structure, smells, or pattern fit.

package/presets/claude/java/agents/build-verifier.md

@@ -17,6 +17,12 @@ You are the build verifier for **Java hexagonal** services (and for **ai-rules p
 
 **Never** require Playwright, XCUITest, `lint:js`/`lint:css`, or `xcodebuild`/`SwiftLint` as the Java gate.
 
+## Verification before completion
+
+<!-- shared-core: quality/verification-before-completion.md -->
+
+Before writing `validation-report.md` or claiming PASS: IDENTIFY the commands, RUN them, READ exit codes, VERIFY they match the verdict, THEN claim. Do not mark PASS from memory of a prior developer run.
+
 ## Preset-structure validation (when editing `packages/ai-rules/presets/**`)
 
 From `packages/ai-rules/`:

package/presets/claude/java/agents/ci-investigator.md

@@ -27,3 +27,4 @@ If a Sentry/Datadog (or similar) MCP is ready and the task is a production error
 ## Anti-sycophancy discipline
 
 - When writing or changing code, load / follow rule `anti-sycophancy-discipline`.
+- When acting on review feedback (`changes_requested` / human comments): verify each item against the codebase before implementing; no performative agreement.

package/presets/claude/java/agents/code-reviewer.md

@@ -16,6 +16,8 @@ You are a senior Java hexagonal code reviewer. Write only review artifacts under
 
 Apply skill `code-review` and `code-review-mr.mdc`. Weigh `architecture-boundaries.mdc`, `domain-layer.mdc`, `application-usecases.mdc`, `ports-interfaces.mdc`, `adapters-driving.mdc`, `adapters-driven.mdc`, `composition-root.mdc`, `java-conventions.mdc`, `tests-unit.mdc`, `tests-integration.mdc`, `security-java.mdc`.
 
+You **issue** reviews. Implementers acting on your findings must verify each item against the codebase and must not perform agreement. Do not require gratitude in replies.
+
 ## Review focus (Java hexagonal)
 
 - If the MR touches `docs/specs/**`, load **`product-specs`** (+ **`product-specs-authoring`** when new/changed specs): **WARN** code/spec drift; **FAIL** broken INDEX `path` link or missing required frontmatter keys/arrays on touched spec files; required body headings missing → **FAIL** on touched files. Do not invent missing product behavior.

package/presets/claude/java/agents/debugger.md

@@ -6,6 +6,8 @@ readonly: false
 
 Investigate with **runtime evidence**: failing `mvn test` / `./gradlew test` output, logs, stack traces, minimal repro.
 
+Use the **`debug-investigation` skill** for the investigation loop.
+
 ## Approach
 
 1. Reproduce with `mvn test` / `./gradlew test` / focused class/package tests.
@@ -21,6 +23,10 @@ Investigate with **runtime evidence**: failing `mvn test` / `./gradlew test` out
 Write `.claude/team/tasks/<slug>/debug-report.md`.
 
 
+## 3-fix architecture gate
+
+After **three** unsuccessful fix attempts (or the same symptom returning twice): STOP. Do not attempt fix #4. Escalate architecture with the human or `solution-architect`. Follow skill `debug-investigation`. Before `fixApplied: true`, re-run the failing check.
+
 ## MCP usage
 
 Load requestable rule `mcp-usage` when verifying third-party library APIs (Context7) or when a local overlay MCP is present and the task fits. Discover tools at runtime; do not invent schemas. Overlay absence is not a blocker unless the user required that MCP as source of truth.
@@ -35,3 +41,4 @@ If a Sentry/Datadog (or similar) MCP is ready and the task is a production error
 ## Anti-sycophancy discipline
 
 - When writing or changing code, load / follow rule `anti-sycophancy-discipline`.
+- When acting on review feedback (`changes_requested` / human comments): verify each item against the codebase before implementing; no performative agreement.

package/presets/claude/java/agents/feature-developer.md

@@ -45,6 +45,13 @@ Update `.claude/team/tasks/<slug>/implementation.md` and the owned implementatio
 ## Anti-sycophancy discipline
 
 - When writing or changing code, load / follow rule `anti-sycophancy-discipline`.
+- When acting on review feedback (`changes_requested` / human comments): verify each item against the codebase before implementing; no performative agreement.
+
+## Verification before completion
+
+<!-- shared-core: quality/verification-before-completion.md -->
+
+Before handoff, IDENTIFY→RUN→READ→VERIFY the scoped checks for this WP, THEN claim. Do not say the work is done without that evidence in the same turn. Full-project lint is `build-verifier`.
 
 ## Product specs (docs/specs)
 

package/presets/claude/java/agents/task-analyst.md

@@ -7,6 +7,16 @@ model: fast
 
 Analyze and decompose work for **Java hexagonal** backends.
 
+## Classify first
+
+<!-- shared-core: agent-team/task-classification.md -->
+
+Before decomposing, name the class: **spike** / **bounded** / **architectural**. Maps to existing pipeline profiles — do not invent a second orchestrator.
+
+- **Spike** — research DoR; no implement tasks.
+- **Bounded** — few tasks, only layers actually touched; do not pad types/api/store/ui.
+- **Architectural** — full layer table; architect when boundaries are unclear.
+
 ## Deliverables
 
 - `brief.md` — goals, non-goals, AC, open questions

package/presets/claude/java/agents/task-router.md

@@ -39,6 +39,20 @@ You are a task router for a **Java hexagonal backend** agent team. You **do not*
 
 **Never skip `build-verifier`** after developer when Java sources changed.
 
+## Task class (spike / bounded / architectural)
+
+<!-- shared-core: agent-team/task-classification.md -->
+
+Name the class in `routingReasons`. Maps to profiles already in this file — do not add a parallel step table.
+
+| Class | Use existing |
+|-------|----------------|
+| Spike | intent `spike` |
+| Bounded | `profile: light` (or skip analyst when AC is complete) |
+| Architectural | `profile: full` + `solution-architect` when boundaries unclear |
+
+SoT: `agent-team/task-classification` (shared-core marker above; do not invent a second pipeline).
+
 ## Routing decision rubric
 
 Keep top-level `profile` and emit this top-level object in every new `pipeline.json`:

package/presets/claude/java/skills/code-review/SKILL.md

@@ -20,6 +20,12 @@ description: Reviews pull requests and branch diffs for Java hexagonal services
 
 Never require iOS/Next-only gates (XCUITest, Playwright, `lint:js`).
 
+## Receiving review feedback
+
+<!-- shared-core: review/receiving-code-review.md -->
+
+When **implementing** review comments (not when issuing them): verify each item against the codebase before changing code; do not perform agreement (`You're absolutely right!`). Unclear items → ask, do not guess.
+
 ## Design guidance
 
 - Load `design-guidance` (rule stem) when assessing structure, smells, or pattern fit.

package/presets/claude/java/skills/debug-investigation/SKILL.md

@@ -3,21 +3,49 @@ name: debug-investigation
 description: Investigates bugs, failing tests, and unexpected behavior in Java services with runtime evidence before applying minimal fixes. Use for bugfix tasks, debugger agent runs, or regressions.
 ---
 
-# Debug investigation (Java)
+<!-- shared-core: quality/debug-investigation.md -->
+
+# Debug investigation
+
+Stack-agnostic root-cause loop. Consumed by skill `debug-investigation` and agent `debugger`. Platform paths, MCP, and stack commands belong in adapter **Stack notes**.
+
+## When
+
+Any bug, test failure, build failure, or unexpected behavior — **before** proposing a fix.
+
+## Phases (in order)
+
+1. **Evidence** — reproduce, or collect the closest evidence (error output, failing test, logs, user steps).
+2. **Isolate** — expected vs actual in one sentence; smallest relevant slice of the codebase.
+3. **Root cause** — name the cause before editing. One hypothesis at a time; do not stack speculative fixes.
+4. **Minimal fix + verify** — smallest change that preserves architecture and public contracts. Add a regression test when the behavior is user-facing or likely to recur. Re-run the **failing** check first, then the relevant lint/type/test slice.
+
+## 3-fix architecture gate
+
+If **three** fix attempts fail, or the same symptom returns after two supposed fixes: **STOP**. Do not attempt fix #4. Escalate — the design is likely wrong (human partner or `solution-architect`). Chasing symptoms is the failure mode.
+
+## Do not
+
+- Broad refactor during a bugfix.
+- Fix only where the error surfaces if invalid data originates elsewhere.
+- Claim `fixApplied: true` without re-running the failing check (see `quality/verification-before-completion.md`).
+
+## Stack notes
+
+### Stack process
 
 1. Capture failing `mvn test` / `./gradlew test` / logs / stack traces.
 2. Hypothesize layer (domain vs adapter vs wiring).
 3. Minimal fix + regression test when appropriate.
 4. Document in `debug-report.md`.
 
-
-## MCP usage
+### MCP usage
 
 Load requestable rule `mcp-usage` when verifying third-party library APIs (Context7) or when a local overlay MCP is present and the task fits. Discover tools at runtime; do not invent schemas. Overlay absence is not a blocker unless the user required that MCP as source of truth.
 
 If a Sentry/Datadog (or similar) MCP is ready and the task is a production error, event, or trace, use it. Do not invent telemetry.
 
 
-## Design guidance
+### Design guidance
 
 - Load `design-guidance` (rule stem) when assessing structure, smells, or pattern fit.

package/presets/claude/mcp-ts/agents/build-verifier.md

@@ -18,6 +18,12 @@ You are the build verifier for **TypeScript MCP servers** (and for **ai-rules pr
 
 **Never** require Playwright, XCUITest, `lint:js`/`lint:css`, `xcodebuild`/`SwiftLint`, or Go tools (`go test` / `go vet` / `golangci-lint`) as the MCP gate.
 
+## Verification before completion
+
+<!-- shared-core: quality/verification-before-completion.md -->
+
+Before writing `validation-report.md` or claiming PASS: IDENTIFY the commands, RUN them, READ exit codes, VERIFY they match the verdict, THEN claim. Do not mark PASS from memory of a prior developer run.
+
 ## Preset-structure validation (when editing `packages/ai-rules/presets/**`)
 
 From `packages/ai-rules/`:

package/presets/claude/mcp-ts/agents/feature-developer.md

@@ -43,6 +43,13 @@ Implement MCP server features following **mcp-ts** boundaries.
 ## Design guidance / anti-sycophancy
 
 - Load `design-guidance` and `anti-sycophancy-discipline` when writing or changing code.
+- When acting on review feedback (`changes_requested` / human comments): verify each item against the codebase before implementing; no performative agreement.
+
+## Verification before completion
+
+<!-- shared-core: quality/verification-before-completion.md -->
+
+Before handoff, IDENTIFY→RUN→READ→VERIFY the scoped checks for this WP, THEN claim. Do not say the work is done without that evidence in the same turn. Full-project lint is `build-verifier`.
 
 
 ## Product specs (docs/specs)

package/presets/claude/mcp-ts/agents/task-analyst.md

@@ -6,6 +6,16 @@ readonly: false
 
 Analyze MCP server work requests for the **mcp-ts** preset.
 
+## Classify first
+
+<!-- shared-core: agent-team/task-classification.md -->
+
+Before decomposing, name the class: **spike** / **bounded** / **architectural**. Maps to existing pipeline profiles — do not invent a second orchestrator.
+
+- **Spike** — research DoR; no implement tasks.
+- **Bounded** — few tasks, only layers actually touched; do not pad types/api/store/ui.
+- **Architectural** — full layer table; architect when boundaries are unclear.
+
 ## Deliverables
 
 1. `brief.md` — goal, AC, out of scope, assumptions, risks.

package/presets/claude/mcp-ts/agents/task-router.md

@@ -46,6 +46,20 @@ Append **`security-reviewer` after `build-verifier`** for `feature` / `bugfix` /
 
 **Never skip `build-verifier`** after developer when TypeScript sources changed.
 
+## Task class (spike / bounded / architectural)
+
+<!-- shared-core: agent-team/task-classification.md -->
+
+Name the class in `routingReasons`. Maps to profiles already in this file — do not add a parallel step table.
+
+| Class | Use existing |
+|-------|----------------|
+| Spike | intent `spike` |
+| Bounded | `profile: light` (or skip analyst when AC is complete) |
+| Architectural | `profile: full` + `solution-architect` when boundaries unclear |
+
+SoT: `agent-team/task-classification` (shared-core marker above; do not invent a second pipeline).
+
 ## Routing decision rubric
 
 Keep top-level `profile` and emit this top-level object in every new `pipeline.json`:

package/presets/claude/mcp-ts/skills/code-review/SKILL.md

@@ -9,3 +9,9 @@ description: Reviews MCP TypeScript diffs for boundaries, schema contracts, capa
 2. Flag monolithic entry files, schema/protocol mismatches, unscopeed capabilities, secret leakage.
 3. Phase 1: security-reviewer covers threat model; no separate `code-reviewer` agent yet — parent may apply this skill directly.
 For agent team tasks, write the review artifact and upsert the owned terminal receipt (`completed` or `changes_requested`); do not mutate `status.json`.
+
+## Receiving review feedback
+
+<!-- shared-core: review/receiving-code-review.md -->
+
+When **implementing** review comments (not when issuing them): verify each item against the codebase before changing code; do not perform agreement (`You're absolutely right!`). Unclear items → ask, do not guess.

package/presets/claude/mcp-ts/skills/debug-investigation/SKILL.md

@@ -3,16 +3,44 @@ name: debug-investigation
 description: Investigates MCP server bugs with runtime evidence — schema failures, handler errors, transport startup. Use for failing tests or incorrect tool behavior.
 ---
 
-# Debug investigation (mcp-ts)
+<!-- shared-core: quality/debug-investigation.md -->
+
+# Debug investigation
+
+Stack-agnostic root-cause loop. Consumed by skill `debug-investigation` and agent `debugger`. Platform paths, MCP, and stack commands belong in adapter **Stack notes**.
+
+## When
+
+Any bug, test failure, build failure, or unexpected behavior — **before** proposing a fix.
+
+## Phases (in order)
+
+1. **Evidence** — reproduce, or collect the closest evidence (error output, failing test, logs, user steps).
+2. **Isolate** — expected vs actual in one sentence; smallest relevant slice of the codebase.
+3. **Root cause** — name the cause before editing. One hypothesis at a time; do not stack speculative fixes.
+4. **Minimal fix + verify** — smallest change that preserves architecture and public contracts. Add a regression test when the behavior is user-facing or likely to recur. Re-run the **failing** check first, then the relevant lint/type/test slice.
+
+## 3-fix architecture gate
+
+If **three** fix attempts fail, or the same symptom returns after two supposed fixes: **STOP**. Do not attempt fix #4. Escalate — the design is likely wrong (human partner or `solution-architect`). Chasing symptoms is the failure mode.
+
+## Do not
+
+- Broad refactor during a bugfix.
+- Fix only where the error surfaces if invalid data originates elsewhere.
+- Claim `fixApplied: true` without re-running the failing check (see `quality/verification-before-completion.md`).
+
+## Stack notes
+
+### Stack process
 
 1. Reproduce with unit/contract fixtures before changing code.
 2. Check schema validation vs handler logic vs registration wiring.
 3. Prefer repository tests over ad-hoc Inspector-only claims.
 4. Load `anti-sycophancy-discipline` — report what was verified.
 
-## MCP usage
+### MCP usage
 
 Load requestable rule `mcp-usage` when verifying third-party library APIs (Context7) or when a local overlay MCP is present and the task fits. Discover tools at runtime; do not invent schemas. Overlay absence is not a blocker unless the user required that MCP as source of truth.
 
 If a Sentry/Datadog (or similar) MCP is ready and the task is a production error, event, or trace, use it. Do not invent telemetry.
-

package/presets/claude/next/agents/build-verifier.md

@@ -25,6 +25,12 @@ Use **`rules/tooling-and-review/package-manager.md`** for the repo package manag
 
 Prefer **`lint`** (= js + css + type-check) before handoff on large changes.
 
+## Verification before completion
+
+<!-- shared-core: quality/verification-before-completion.md -->
+
+Before writing `validation-report.md` or claiming PASS: IDENTIFY the commands, RUN them, READ exit codes, VERIFY they match the verdict, THEN claim. Do not mark PASS from memory of a prior developer run.
+
 ## Preset-structure validation (when scope is preset / packages/ai-rules)
 
 When validating **preset packaging** changes (paths under `packages/ai-rules/presets/**`, or `scope: preset-structure-validation` / `preset-artifacts-only`), run these checks. Skip app lint if there are **no** app source changes.

package/presets/claude/next/agents/ci-investigator.md

@@ -66,3 +66,4 @@ Provide summary: failed check, root cause, files changed, validation commands ru
 ## Anti-sycophancy discipline
 
 - When writing or changing code, load / follow rule `anti-sycophancy-discipline`.
+- When acting on review feedback (`changes_requested` / human comments): verify each item against the codebase before implementing; no performative agreement.

package/presets/claude/next/agents/code-reviewer.md

@@ -14,6 +14,8 @@ You are a senior code reviewer. You may write only review artifacts under `.clau
 
 Apply the **`code-review` skill** and **`rules/tooling-and-review/code-review-mr.md`** checklist.
 
+You **issue** reviews. Implementers acting on your findings must verify each item against the codebase and must not perform agreement. Do not require gratitude in replies.
+
 ## Tests gate
 
 - If diff changes mappers, store reducers/thunks, or domain logic **without** new/updated `*.spec.ts` → **REQUEST_CHANGES** unless task scope explicitly excludes tests.

package/presets/claude/next/agents/debugger.md

@@ -45,6 +45,10 @@ fixApplied: false
 
 5. If fix is trivial and clearly scoped, you **may** apply the minimal fix and set `fixApplied: true` in the report. Otherwise leave implementation to **feature-developer** with `fixApplied: false`.
 
+## 3-fix architecture gate
+
+After **three** unsuccessful fix attempts (or the same symptom returning twice): STOP. Do not attempt fix #4. Escalate architecture with the human or `solution-architect`. Follow skill `debug-investigation`. Before `fixApplied: true`, re-run the failing check.
+
 
 ## MCP usage
 
@@ -75,3 +79,4 @@ Do not perform formal code review or write e2e plans — those are separate agen
 ## Anti-sycophancy discipline
 
 - When writing or changing code, load / follow rule `anti-sycophancy-discipline`.
+- When acting on review feedback (`changes_requested` / human comments): verify each item against the codebase before implementing; no performative agreement.

package/presets/claude/next/agents/feature-developer.md

@@ -46,6 +46,13 @@ Do not perform formal code review — that is the code-reviewer subagent's job.
 ## Anti-sycophancy discipline
 
 - When writing or changing code, load / follow rule `anti-sycophancy-discipline`.
+- When acting on review feedback (`changes_requested` / human comments): verify each item against the codebase before implementing; no performative agreement.
+
+## Verification before completion
+
+<!-- shared-core: quality/verification-before-completion.md -->
+
+Before handoff, IDENTIFY→RUN→READ→VERIFY the scoped checks for this WP, THEN claim. Do not say the work is done without that evidence in the same turn. Full-project lint is `build-verifier`.
 
 ## Anti-hallucination (Next / React / RTK)
 

package/presets/claude/next/agents/task-analyst.md

@@ -8,10 +8,20 @@ You are a senior business/technical analyst for a Next.js frontend team.
 
 Your job is to reach **Definition of Ready (DoR)** before any implementation starts. You may write only `.claude/team/**` artifacts. You do **not** write production code or modify application source files.
 
+## Classify first
+
+<!-- shared-core: agent-team/task-classification.md -->
+
+Before decomposing, name the class: **spike** / **bounded** / **architectural**. Maps to existing pipeline profiles — do not invent a second orchestrator.
+
+- **Spike** — research DoR; no implement tasks.
+- **Bounded** — few tasks, only layers actually touched; do not pad types/api/store/ui.
+- **Architectural** — full layer table; architect when boundaries are unclear.
+
 ## Clarification cycle (must)
 
 1. Rephrase the task in your own words (goal, user value, boundaries).
-2. Ask **1–3 questions per iteration** — never more than 3 at once.
+2. Ask questions — **prefer one** unblocking question; **never more than 3** per iteration.
 3. List explicit **assumptions** when information is missing.
 4. Do **not** decompose until acceptance criteria are **testable and unambiguous**.
 5. If critical unknowns remain, mark them in `open_questions` and ask the user before finalizing.

package/presets/claude/next/agents/task-router.md

@@ -45,6 +45,20 @@ Set optional top-level `"profile": "full" | "standard" | "light"` in `pipeline.j
 
 **Light signals:** one file, one layer, explicit AC in prompt, no architectural risk. **Never skip `build-verifier`** after developer when `app/**` changed. **Skip `code-reviewer`** in light only for non-prod preset/docs tasks — for `app/src` changes prefer standard.
 
+## Task class (spike / bounded / architectural)
+
+<!-- shared-core: agent-team/task-classification.md -->
+
+Name the class in `routingReasons`. Maps to profiles already in this file — do not add a parallel step table.
+
+| Class | Use existing |
+|-------|----------------|
+| Spike | intent `spike` |
+| Bounded | `profile: light` (or skip analyst when AC is complete) |
+| Architectural | `profile: full` + `solution-architect` when boundaries unclear |
+
+SoT: `agent-team/task-classification` (shared-core marker above; do not invent a second pipeline).
+
 **Light by intent:**
 
 | intent | light steps |

package/presets/claude/next/skills/code-review/SKILL.md

@@ -33,6 +33,12 @@ Lead with findings ordered by severity. Required shape (also in `code-review-mr`
 
 For agent team tasks, write `.claude/team/tasks/<slug>/review.md` and upsert the owned terminal receipt (`completed` or `changes_requested`); do not mutate `status.json`.
 
+## Receiving review feedback
+
+<!-- shared-core: review/receiving-code-review.md -->
+
+When **implementing** review comments (not when issuing them): verify each item against the codebase before changing code; do not perform agreement (`You're absolutely right!`). Unclear items → ask, do not guess.
+
 ## Design guidance
 
 - Load `design-guidance` (rule stem) when assessing structure, smells, or pattern fit.

package/presets/claude/next/skills/debug-investigation/SKILL.md

@@ -3,19 +3,36 @@ name: debug-investigation
 description: Investigates bugs, failing tests, crashes, and incorrect behavior with runtime evidence before applying minimal fixes. Use for bugfix tasks, debugger agent runs, regressions, and flaky test diagnosis.
 ---
 
-# Debug Investigation
+<!-- shared-core: quality/debug-investigation.md -->
 
-## Process
+# Debug investigation
 
-1. Reproduce the issue or collect the closest available evidence: error output, failing test, browser snapshot, logs, or user steps.
-2. Define expected vs actual behavior in one sentence.
-3. Trace the failing path through the smallest relevant slice of the codebase.
-4. Identify the root cause before editing. Avoid broad refactors during bugfixes.
-5. Apply the smallest fix that preserves existing architecture and public contracts.
-6. Add or update a regression test when the behavior is user-facing or likely to recur.
-7. Run the narrow failing check first, then relevant lint/type/test validation.
+Stack-agnostic root-cause loop. Consumed by skill `debug-investigation` and agent `debugger`. Platform paths, MCP, and stack commands belong in adapter **Stack notes**.
 
-## Artifacts
+## When
+
+Any bug, test failure, build failure, or unexpected behavior — **before** proposing a fix.
+
+## Phases (in order)
+
+1. **Evidence** — reproduce, or collect the closest evidence (error output, failing test, logs, user steps).
+2. **Isolate** — expected vs actual in one sentence; smallest relevant slice of the codebase.
+3. **Root cause** — name the cause before editing. One hypothesis at a time; do not stack speculative fixes.
+4. **Minimal fix + verify** — smallest change that preserves architecture and public contracts. Add a regression test when the behavior is user-facing or likely to recur. Re-run the **failing** check first, then the relevant lint/type/test slice.
+
+## 3-fix architecture gate
+
+If **three** fix attempts fail, or the same symptom returns after two supposed fixes: **STOP**. Do not attempt fix #4. Escalate — the design is likely wrong (human partner or `solution-architect`). Chasing symptoms is the failure mode.
+
+## Do not
+
+- Broad refactor during a bugfix.
+- Fix only where the error surfaces if invalid data originates elsewhere.
+- Claim `fixApplied: true` without re-running the failing check (see `quality/verification-before-completion.md`).
+
+## Stack notes
+
+### Artifacts
 
 For agent team tasks, write `.claude/team/tasks/<slug>/debug-report.md` with:
 
@@ -27,8 +44,7 @@ For agent team tasks, write `.claude/team/tasks/<slug>/debug-report.md` with:
 
 Agent team: upsert the owned terminal receipt in `artifact-manifest.json`; do not mutate `status.json`.
 
-
-## MCP usage
+### MCP usage
 
 Load requestable rule `mcp-usage` when verifying third-party library APIs (Context7) or when a local overlay MCP is present and the task fits. Discover tools at runtime; do not invent schemas. Overlay absence is not a blocker unless the user required that MCP as source of truth.
 
@@ -38,7 +54,6 @@ Shipped browser split: Playwright MCP for e2e specs/selectors; Chrome DevTools M
 
 If a Sentry/Datadog (or similar) MCP is ready and the task is a production error, event, or trace, use it. Do not invent telemetry.
 
-
-## Design guidance
+### Design guidance
 
 - Load `design-guidance` (rule stem) when assessing structure, smells, or pattern fit.

package/presets/claude/nuxt/agents/build-verifier.md

@@ -25,6 +25,12 @@ Use **`rules/tooling-and-review/package-manager.md`** for the repo package manag
 
 Prefer **`lint`** (= js + css + typecheck) before handoff on large changes.
 
+## Verification before completion
+
+<!-- shared-core: quality/verification-before-completion.md -->
+
+Before writing `validation-report.md` or claiming PASS: IDENTIFY the commands, RUN them, READ exit codes, VERIFY they match the verdict, THEN claim. Do not mark PASS from memory of a prior developer run.
+
 ## Preset-structure validation (when scope is preset / packages/ai-rules)
 
 When validating **preset packaging** changes (paths under `packages/ai-rules/presets/**`, or `scope: preset-structure-validation` / `preset-artifacts-only`), run these checks. Skip app lint if there are **no** app source changes.

package/presets/claude/nuxt/agents/ci-investigator.md

@@ -66,3 +66,4 @@ Provide summary: failed check, root cause, files changed, validation commands ru
 ## Anti-sycophancy discipline
 
 - When writing or changing code, load / follow rule `anti-sycophancy-discipline`.
+- When acting on review feedback (`changes_requested` / human comments): verify each item against the codebase before implementing; no performative agreement.

package/presets/claude/nuxt/agents/code-reviewer.md

@@ -14,6 +14,8 @@ You are a senior code reviewer. You may write only review artifacts under `.clau
 
 Apply the **`code-review` skill** and **`rules/tooling-and-review/code-review-mr.md`** checklist.
 
+You **issue** reviews. Implementers acting on your findings must verify each item against the codebase and must not perform agreement. Do not require gratitude in replies.
+
 ## Tests gate
 
 - If diff changes mappers, Pinia actions/getters, or domain logic **without** new/updated `*.spec.ts` → **REQUEST_CHANGES** unless task scope explicitly excludes tests.

package/presets/claude/nuxt/agents/debugger.md

@@ -46,6 +46,10 @@ fixApplied: false
 5. If fix is trivial and clearly scoped, you **may** apply the minimal fix and set `fixApplied: true` in the report. Otherwise leave implementation to **feature-developer** with `fixApplied: false`.
 
 
+## 3-fix architecture gate
+
+After **three** unsuccessful fix attempts (or the same symptom returning twice): STOP. Do not attempt fix #4. Escalate architecture with the human or `solution-architect`. Follow skill `debug-investigation`. Before `fixApplied: true`, re-run the failing check.
+
 ## MCP usage
 
 Load requestable rule `mcp-usage` when verifying third-party library APIs (Context7) or when a local overlay MCP is present and the task fits. Discover tools at runtime; do not invent schemas. Overlay absence is not a blocker unless the user required that MCP as source of truth.
@@ -75,3 +79,4 @@ Do not perform formal code review or write e2e plans — those are separate agen
 ## Anti-sycophancy discipline
 
 - When writing or changing code, load / follow rule `anti-sycophancy-discipline`.
+- When acting on review feedback (`changes_requested` / human comments): verify each item against the codebase before implementing; no performative agreement.

package/presets/claude/nuxt/agents/feature-developer.md

@@ -46,6 +46,13 @@ Do not perform formal code review — that is the code-reviewer subagent's job.
 ## Anti-sycophancy discipline
 
 - When writing or changing code, load / follow rule `anti-sycophancy-discipline`.
+- When acting on review feedback (`changes_requested` / human comments): verify each item against the codebase before implementing; no performative agreement.
+
+## Verification before completion
+
+<!-- shared-core: quality/verification-before-completion.md -->
+
+Before handoff, IDENTIFY→RUN→READ→VERIFY the scoped checks for this WP, THEN claim. Do not say the work is done without that evidence in the same turn. Full-project lint is `build-verifier`.
 
 ## Anti-hallucination (Vue / Nuxt / Pinia)