@bonesofspring/ai-rules 0.2.19 → 0.2.20

package/CHANGELOG.md

@@ -2,8 +2,22 @@
 
 ## Unreleased
 
+### Superpowers B1–B5 (all installable stacks)
+
+- All 10 stacks (Cursor + Claude): **verification-before-completion** lineage snippet on `build-verifier` / `feature-developer` only. `debugger` keeps inline 3-fix + `fixApplied` re-run (skill cross-ref) — not the verification stem. **receiving-code-review** embed on `code-review` skill; implementer one-liner on `feature-developer`, `debugger`, and `ci-investigator` (where those agents exist). Debug skill 4-phase + 3-fix architecture gate; task-analyst/router classify spike / bounded / architectural onto **existing** pipeline profiles.
+- Drift CI: `quality/debug-investigation.md` is **embed** (skill body = core + `## Stack notes`). `verification-before-completion`, `receiving-code-review`, and `task-classification` are **lineage** (section snippets in fat agents — whole-file embed would fail). `mcp-ts` has no `debugger` / `code-reviewer` / `ci-investigator` agents; B1/B2 via skill + `feature-developer` (+ `build-verifier` for B1); B3 via `debug-investigation` skill; B4 on task-analyst/router.
+- Skill-authoring craft (SDO, positive recipes, ~500-line cap) lives in `docs/PRESET-CONTRIBUTION.md` (not installed by `init`).
+- No 4th always-on rule; `anti-sycophancy-discipline` core body unchanged (promote receiving-CR there in a later 10-stack PR).
+- Consumers: re-run `npx @bonesofspring/ai-rules init cursor|claude --preset <stack>` after publish.
+
 Grouping for the next npm cut: **(A)** post-`0.2.18` delta — MCP merge, spec P0/P1, hook-only lifecycle, and the review follow-up below; **(B)** sections after MCP (UX, mockup reviewer, product-specs, android-kotlin, nuxt/svelte/php-laravel, …) were already Unreleased **on the `v0.2.18` tag** and were never versioned.
 
+### Follow-up: Superpowers B1–B5 review alignment
+
+- CHANGELOG/SoT match PRESET-CONTRIBUTION: verification lineage is `build-verifier` + `feature-developer`; debugger 3-fix stays inline (no verification marker).
+- receiving-CR implementer one-liner extended to `debugger` and `ci-investigator` (9 stacks × 2; mcp-ts has neither).
+- Backend `debugger` agents (`go` / `java` / `php-hexagonal` / `php-laravel`, Cursor + Claude) now load `debug-investigation` at the top, matching UI/mobile.
+
 ### Follow-up: review fixes (lifecycle, MCP merge, docs)
 
 - Hook-only lifecycle sweep: 22 ios-swift agents, 8 next/nuxt/svelte/ios `code-review` skills, 5 Claude `feature-continue` commands, Claude Playwright generators, and backend `code-review` skills upsert `artifact-manifest.json` receipts and must not mutate `status.json`. New hard gate `check:hook-only-lifecycle` (wired into `check:preset-structure`).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bonesofspring/ai-rules",
-  "version": "0.2.19",
+  "version": "0.2.20",
   "description": "Presets of Cursor and Claude rules/commands for Revy Ross personal use",
   "license": "MIT",
   "author": "Revy Ross",

package/presets/_shared/README.md

@@ -36,10 +36,10 @@ Do **not** expect lineage adapters to byte-match core. Embed adapters should mat
 
 | Dir | Contents |
 |-----|----------|
-| `core/quality/` | Boy-scout + Principles (always-on slim); requestable `anti-sycophancy-discipline` (~17 rules); requestable `design-guidance` (smells ≤12 + GoF ≤8); requestable `mcp-usage` (Context7 + local overlay MCP) |
-| `core/agent-team/` | Orchestrator + intake (pipeline language) |
+| `core/quality/` | Boy-scout + Principles (always-on slim); requestable `anti-sycophancy-discipline` (~17 rules); requestable `design-guidance` (smells ≤12 + GoF ≤8); requestable `mcp-usage`; embed `debug-investigation`; lineage `verification-before-completion` |
+| `core/agent-team/` | Orchestrator + intake (pipeline language); lineage `task-classification` |
 | `core/architecture/` | Feature-delivery abstract + reference-features template + product-specs (+ product-specs-authoring) + assets/docs-specs templates |
-| `core/review/` | Code-review MR + technical-retro alias + mockup-review checklist + ux-design checklist |
+| `core/review/` | Code-review MR + technical-retro alias + mockup-review checklist + ux-design checklist; lineage `receiving-code-review` |
 | `core/meta/` | Author-facing preset meta-rules |
 
 ## CLI note

package/presets/_shared/core/agent-team/task-classification.md

@@ -0,0 +1,21 @@
+# Task classification (spike / bounded / architectural)
+
+Stack-agnostic. Classify **before** decomposing work or expanding a pipeline. This maps onto existing `pipeline.json` **profiles** (`light` / `standard` / `full`) and intents — do **not** invent a second orchestrator.
+
+## Classes
+
+| Class | Signals | Pipeline posture |
+|-------|---------|------------------|
+| **Spike** | Research, estimate, "can we", no ship | Existing `spike` intent: analyst → architect (or analyst-only). No `feature-developer` until a later task. |
+| **Bounded** | One layer or file, explicit AC, typo / small fix | Existing `light` (or skip analyst fan-out). Do **not** invent a full types/api/store/ui task table. |
+| **Architectural** | New subsystem, public contract, cross-layer | Existing `full`. Add `solution-architect` when boundaries are unclear. |
+
+Ratchet **up** if bounded work reveals architectural scope. Do not ratchet **down** to skip a needed verification gate (`build-verifier` after code changes still applies).
+
+## Clarification
+
+Prefer **one** unblocking question per message when a single decision unblocks DoR. Never more than **3** questions per iteration (existing analyst cap).
+
+## Router
+
+`task-router` already chooses profiles from complexity signals. Use this table to **name** the class in `routingReasons` / brief assumptions — do not add parallel step lists that contradict the intent table.

package/presets/_shared/core/quality/debug-investigation.md

@@ -0,0 +1,24 @@
+# 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`).

package/presets/_shared/core/quality/verification-before-completion.md

@@ -0,0 +1,25 @@
+# Verification before completion
+
+Stack-agnostic evidence gate. Requestable via agents (`feature-developer`, `build-verifier`, `debugger`) — **not** always-on.
+
+Do not claim done, fixed, passing, or verified without **fresh command evidence in the same turn**.
+
+## Gate (in order)
+
+1. **IDENTIFY** the command that would falsify the claim (test, lint, type-check, or the preset-structure script named in the task).
+2. **RUN** it now. Do not reuse a previous agent's "it passed" as proof.
+3. **READ** the full output and the exit code.
+4. **VERIFY** the output matches the claim (count failures; do not skim).
+5. **THEN claim** — name the command and the result. If it failed, report the actual state.
+
+## Forbidden
+
+- Success words (`done`, `all fixed`, `looks good`, `should pass`) without output in the same message.
+- Treating lint as a substitute for tests when the claim is behavioral.
+- Skipping the failing check after a bugfix.
+
+## Who runs what
+
+- **feature-developer:** scoped checks named in the task (changed-file lint/tests). Full-project gates belong to `build-verifier`.
+- **build-verifier:** the pipeline commands; record exit codes in `validation-report.md`.
+- **debugger:** re-run the failing check after a minimal fix before `fixApplied: true`.

package/presets/_shared/core/review/receiving-code-review.md

@@ -0,0 +1,24 @@
+# Receiving code review
+
+Stack-agnostic. For **implementers** acting on feedback (human comments or pipeline `changes_requested`). Distinct from **issuing** a review (`code-review` skill / `code-reviewer` agent).
+
+Complements `quality/anti-sycophancy-discipline.md` §11 and §17. Do **not** duplicate this essay into always-on rules.
+
+## Process
+
+1. Read the complete feedback before changing code.
+2. Restate each item as a technical requirement. If any item is unclear, ask — do not implement a guess.
+3. Verify the claim against the codebase. Reviewers can be wrong (wrong file, stale API, YAGNI expansion).
+4. Push back with evidence when a suggestion adds unused abstraction or contradicts stack boundaries.
+5. Implement agreed items one at a time; keep tests green per item when the change is logic.
+
+## Forbidden
+
+Performative agreement: `You're absolutely right!`, `Great point!`, `Thanks for catching that!`
+
+Respond with what changed (`path:line`) or a factual disagreement. No gratitude theater.
+
+## Sources
+
+- **Human partner:** clarify, then act.
+- **Pipeline / automated review:** the same verification bar; do not rubber-stamp.

package/presets/claude/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/claude/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/claude/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 `tooling-and-review/code-review.md` checklist. Also weigh `architecture/boundaries.md`, `stack/kotlin-conventions.md`, `ui-and-accessibility/compose.md`, `api-and-data/networking.md`, `testing/unit.md`, `testing/ui.md`.
 
+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/claude/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/claude/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/claude/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 `.claude/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/claude/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/claude/android-kotlin/skills/code-review/SKILL.md

@@ -34,6 +34,12 @@ Lead with findings ordered by severity. Required shape (also in `code-review`):
 
 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/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 (`tooling-and-review/gradle-tooling.md`).
 
-## Artifacts
+### Artifacts
 
 For agent team tasks, write `.claude/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/claude/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/claude/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/claude/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/claude/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 `.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/go/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/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/claude/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/claude/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/claude/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/claude/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/claude/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/claude/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 `tooling-and-review/code-review.md` checklist. Also weigh `architecture/boundaries.md`, `stack/swift-conventions.md`, `ui-and-accessibility/swiftui.md`, `api-and-data/networking.md`, `testing/unit.md`, `testing/ui.md`.
 
+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/claude/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/claude/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/claude/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 `.claude/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/claude/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/claude/ios-swift/skills/code-review/SKILL.md

@@ -34,6 +34,12 @@ Lead with findings ordered by severity. Required shape (also in `code-review`):
 
 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.