@bonesofspring/ai-rules 0.2.19 → 0.2.20

package/presets/claude/svelte/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:
 
@@ -28,7 +45,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.
 
@@ -39,6 +56,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/cursor/android-kotlin/agents/build-verifier.md

@@ -25,6 +25,12 @@ You **validate** Android/Kotlin implementation quality — do not edit productio
 
 Never require Playwright, XCUITest, `xcodebuild`, or yarn `lint:js`/`lint:css` for Android app work.
 
+## 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 **android-kotlin preset** changes (or `scope: preset-structure-validation`), **also** run these checks. Skip Gradle app builds if there are **no** Android app changes.

package/presets/cursor/android-kotlin/agents/ci-investigator.md

@@ -80,3 +80,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/cursor/android-kotlin/agents/code-reviewer.md

@@ -16,6 +16,8 @@ You are a senior Android / Kotlin / Jetpack Compose code reviewer. You may write
 
 Apply the **`code-review` skill** and `code-review-mr.mdc` checklist. Also weigh `architecture-boundaries.mdc`, `kotlin-conventions.mdc`, `compose-ui.mdc`, `networking-data.mdc`, `tests-unit.mdc`, `tests-ui.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 (Android)
 
 - 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/cursor/android-kotlin/agents/debugger.md

@@ -58,6 +58,10 @@ fixApplied: false
 Write the owned terminal receipt described under **Artifact contract**.
 
 
+## 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.
@@ -83,3 +87,4 @@ Do not perform formal code review or write Android instrumentation plans — tho
 ## 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/cursor/android-kotlin/agents/feature-developer.md

@@ -54,6 +54,13 @@ Emit the owned implementation receipt with outcome `completed`. Handoff by layer
 ## 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`.
 
 ## UX design (behavioral)
 

package/presets/cursor/android-kotlin/agents/task-analyst.md

@@ -7,6 +7,16 @@ model: fast
 
 You are a senior analyst for an **Android Kotlin** team. Reach **Definition of Ready** before implementation. Write only `.cursor/team/**`. Do **not** write production code.
 
+## 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
 
 Ask only blocking questions (AC gaps, Feature scope, platforms, offline/auth, API ownership). Prefer short lists.

package/presets/cursor/android-kotlin/agents/task-router.md

@@ -35,6 +35,20 @@ You are a task router for an **Android Kotlin/Jetpack Compose** agent team. You
 | `retro` | “retro”, “postmortem” | (orchestrator → `/technical-retro`) |
 
 **Never schedule Playwright agents** (`playwright-test-*`). If a next template mentions them, put in `skipped` with reason "Android uses Android instrumentation" and use instrumentation-test trio.
+## 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:** `mockup-review` → only `mockup-reviewer` (`model: "strong"`, never `cheap`). `ux-design` → only `task-analyst` (skill `ux-design`; analyst default model, not `strong`). Classify `mockup-review` **before** `ux-design` **before** `review-only`. A `figma.com` URL with review-not-implement language remains `mockup-review` even if the user said «ревью UX». <!-- i18n-keep: E4 -->
 **Embed UX:** on `feature` / `refactor` / `spike` / `spec-gen` with required-signal or advisory UI AC, instruct **task-analyst** to load skill `ux-design` (no new pipeline step).
 

package/presets/cursor/android-kotlin/skills/code-review/SKILL.md

@@ -34,6 +34,12 @@ Lead with findings ordered by severity. Required shape (also in `code-review-mr`
 
 For agent team tasks, write `.cursor/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/cursor/android-kotlin/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 (Android)
+<!-- 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: Android Studio / AGP console, lldb backtrace, crash log, failing JUnit/Android instrumentation output, Profiler 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 JUnit when the behavior is domain/VM logic or likely to recur.
 7. Run the narrow failing check first (`./gradlew test` for the affected target), then broader build validation if needed (`gradle-tooling.mdc`).
 
-## Artifacts
+### Artifacts
 
 For agent team tasks, write `.cursor/team/tasks/<slug>/debug-report.md` with:
 
@@ -30,13 +58,13 @@ Upsert the owned terminal receipt in `artifact-manifest.json` when complete; do
 Do not use browser e2e tooling — this is an Android Studio / AGP 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/cursor/go/agents/build-verifier.md

@@ -17,6 +17,12 @@ You are the build verifier for **Go hexagonal** services (and for **ai-rules pre
 
 **Never** require Playwright, XCUITest, `lint:js`/`lint:css`, or `xcodebuild`/`SwiftLint` as the Go 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/cursor/go/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/cursor/go/agents/code-reviewer.md

@@ -16,6 +16,8 @@ You are a senior Go 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`, `go-conventions.mdc`, `tests-unit.mdc`, `tests-integration.mdc`, `security-go.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 (Go 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/cursor/go/agents/debugger.md

@@ -6,6 +6,8 @@ readonly: false
 
 Investigate with **runtime evidence**: failing `go test` output, logs, stack traces, minimal repro.
 
+Use the **`debug-investigation` skill** for the investigation loop.
+
 ## Approach
 
 1. Reproduce with `go test` / focused package tests.
@@ -21,6 +23,10 @@ Investigate with **runtime evidence**: failing `go test` output, logs, stack tra
 Write `.cursor/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/cursor/go/agents/feature-developer.md

@@ -45,6 +45,13 @@ Update `.cursor/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/cursor/go/agents/task-analyst.md

@@ -7,6 +7,16 @@ model: fast
 
 Analyze and decompose work for **Go 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/cursor/go/agents/task-router.md

@@ -39,6 +39,20 @@ You are a task router for a **Go hexagonal backend** agent team. You **do not**
 
 **Never skip `build-verifier`** after developer when Go 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/cursor/go/skills/code-review/SKILL.md

@@ -20,6 +20,12 @@ description: Reviews pull requests and branch diffs for Go hexagonal services us
 
 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/cursor/go/skills/debug-investigation/SKILL.md

@@ -3,21 +3,49 @@ name: debug-investigation
 description: Investigates bugs, failing tests, and unexpected behavior in Go services with runtime evidence before applying minimal fixes. Use for bugfix tasks, debugger agent runs, or regressions.
 ---
 
-# Debug investigation (Go)
+<!-- 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 `go 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/cursor/ios-swift/agents/build-verifier.md

@@ -24,6 +24,12 @@ You **validate** iOS implementation quality — do not edit production code or t
 
 Never require yarn/`lint:js`/Playwright for iOS app work.
 
+## 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 **ios-swift preset** changes (or `scope: preset-structure-validation` / `preset-artifacts-only`), **also** run these checks. Skip xcodebuild if there are **no** Swift app changes.

package/presets/cursor/ios-swift/agents/ci-investigator.md

@@ -74,3 +74,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/cursor/ios-swift/agents/code-reviewer.md

@@ -16,6 +16,8 @@ You are a senior iOS / Swift / SwiftUI code reviewer. You may write only review
 
 Apply the **`code-review` skill** and `code-review-mr.mdc` checklist. Also weigh `architecture-boundaries.mdc`, `swift-conventions.mdc`, `swiftui-ui.mdc`, `networking-services.mdc`, `tests-unit.mdc`, `tests-ui.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 (iOS)
 
 - 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/cursor/ios-swift/agents/debugger.md

@@ -63,6 +63,10 @@ Handoff summary: root cause, recommended fix, files touched (if any), `fixApplie
 Do not perform formal code review or write XCUITest plans — those are separate agents.
 
 
+## 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.
@@ -77,3 +81,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/cursor/ios-swift/agents/feature-developer.md

@@ -54,6 +54,13 @@ Emit the owned implementation receipt with outcome `completed`. Handoff by layer
 ## 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`.
 
 ## UX design (behavioral)
 

package/presets/cursor/ios-swift/agents/task-analyst.md

@@ -7,6 +7,16 @@ model: fast
 
 You are a senior analyst for an **iOS Swift** team. Reach **Definition of Ready** before implementation. Write only `.cursor/team/**`. Do **not** write production code.
 
+## 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
 
 Ask only blocking questions (AC gaps, Feature scope, platforms, offline/auth, API ownership). Prefer short lists.

package/presets/cursor/ios-swift/agents/task-router.md

@@ -35,6 +35,20 @@ You are a task router for an **iOS Swift/SwiftUI** agent team. You **do not** im
 | `retro` | “retro”, “postmortem” | (orchestrator → `/technical-retro`) |
 
 **Never schedule Playwright agents** (`playwright-test-*`). If a next template mentions them, put in `skipped` with reason "iOS uses XCUITest" and use xcuitest trio.
+## 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:** `mockup-review` → only `mockup-reviewer` (`model: "strong"`, never `cheap`). `ux-design` → only `task-analyst` (skill `ux-design`; analyst default model, not `strong`). Classify `mockup-review` **before** `ux-design` **before** `review-only`. A `figma.com` URL with review-not-implement language remains `mockup-review` even if the user said «ревью UX». <!-- i18n-keep: E4 -->
 **Embed UX:** on `feature` / `refactor` / `spike` / `spec-gen` with required-signal or advisory UI AC, instruct **task-analyst** to load skill `ux-design` (no new pipeline step).
 

package/presets/cursor/ios-swift/skills/code-review/SKILL.md

@@ -34,6 +34,12 @@ Lead with findings ordered by severity. Required shape (also in `code-review-mr`
 
 For agent team tasks, write `.cursor/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/cursor/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 (`xcode-tooling.mdc`).
 
-## Artifacts
+### Artifacts
 
 For agent team tasks, write `.cursor/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/cursor/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/cursor/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.