@event4u/agent-config 5.10.1 → 6.1.0

package/.agent-src/skills/blast-radius-analyzer/SKILL.md

@@ -1,192 +0,0 @@
----
-model_tier: high
-name: blast-radius-analyzer
-description: "Use BEFORE editing shared code — enumerates every call site, event consumer, queue worker, API client, migration, and test that a planned change will touch, with a file:line citation per dependency."
-personas:
-  - backend-architect
-domain: discovery
-workspaces:
-  - engineering
-packs:
-  - engineering-base
----
-
-# blast-radius-analyzer
-
-> You are an analyst specialized in **change-impact analysis**.
-> Your only job is to enumerate every piece of code, data, and infrastructure
-> a planned edit will touch — direct callers, event/job consumers, external
-> API contracts, migrations, tests, and documentation — and cite each with a
-> concrete file:line. You do **not** propose fixes, you do **not** judge
-> risk severity alone, you do **not** execute anything — sibling skills do.
-
-## When to use
-
-* Before editing a method, class, or DB column used by more than one caller
-* Before changing an event payload, queue job shape, or scheduled command
-* Before renaming, deleting, or changing the signature of any public API
-* Before altering a migration, seeder, or shared factory/fixture
-* When the implementer says *"just a quick rename"* of something non-local
-
-Do NOT use when:
-
-* The target is a truly local symbol (private method called in one file) —
-  skip, it has no blast radius
-* You need to trace how one data element flows — route to
-  [`data-flow-mapper`](../data-flow-mapper/SKILL.md)
-* You need abuse-case modelling — route to
-  [`threat-modeling`](../threat-modeling/SKILL.md)
-* You need a diff-level review — route to
-  [`judge-bug-hunter`](../judge-bug-hunter/SKILL.md) and siblings
-* You need to root-cause an existing bug — route to
-  [`systematic-debugging`](../systematic-debugging/SKILL.md)
-
-## Procedure
-
-### 1. Pin the change under analysis
-
-Name the exact symbol, column, or contract under change — e.g. *"rename
-`Order::grandTotal()` to `Order::totalCents()`"* or *"drop column
-`users.legacy_ref`"*. If the change is unclear, stop and ask. Do not map
-an imagined refactor.
-
-### 2. Identify direct dependencies
-
-Run grep/search for the exact symbol, column, or event name. Enumerate:
-
-| Dependency class | What to collect |
-|---|---|
-| Call sites | Every invocation: `file:line` + containing function/class |
-| Overrides | Subclasses, trait users, interface implementations |
-| Tests | Tests that exercise the symbol directly |
-| Factories / seeders | Code that constructs or populates the target |
-| DB references | Foreign keys, indexes, views, triggers on the column |
-| Config / docs | YAML, JSON, Markdown that name the symbol |
-
-### 3. Inspect indirect deps
-
-For each direct dependency, identify second-order fan-out:
-
-- Events emitted by the changed code → listeners and queued jobs
-- Jobs dispatched → workers, failed-job handlers, schedulers
-- API responses → OpenAPI spec, resource classes, external clients
-- DB schema → migrations that assume the column exists, seeders, reports
-
-Stop at second order unless a caller is itself heavily fanned-out (call it
-out explicitly — don't silently chase cascades).
-
-### 4. Score reach and surface risks
-
-For every dependency, mark:
-
-- **Reach:** `local` (≤3 sites) · `module` (one module/bounded context) ·
-  `cross-module` (multiple bounded contexts) · `external` (public API, queue
-  consumer, other service, persisted data)
-- **Risk type:** signature break · behavior change · data migration ·
-  contract change · flaky test surface · none
-- **Owner hint:** module path, codeowner, or team if discoverable
-
-### 5. Consult engineering memory
-
-Via [`memory-access`](../../../docs/guidelines/agent-infra/memory-access.md) call
-`retrieve(types=["architecture-decisions", "ownership"],
-keys=<changed paths + changed symbol>, limit=5)`. Surface:
-
-- **Architecture decisions** that constrain the planned change — cite
-  `id` and the decision verbatim so the report is self-auditing.
-- **Ownership** matches — add these as `owner hint` candidates when
-  the direct grep had no result.
-
-Memory entries are supplementary, never authoritative: a grep miss is
-still a grep miss. Do not infer deps from memory alone.
-
-## Validation
-
-Before finalizing the report, confirm:
-
-1. Every listed dependency has a file:line citation — no bare filenames
-2. Call-site count is exact — the output says `7 call sites`, not `several`
-3. Second-order fan-out is bounded — any runaway chain is flagged, not expanded
-4. Every `external` reach has at least one named owner hint or an explicit
-   "owner unknown — ask"
-5. You have NOT invented deps that grep did not find
-6. You have NOT merged direct and indirect deps — they are listed separately
-
-## Output format
-
-```
-Skill:   blast-radius-analyzer
-Change:  <one-line description of the planned edit>
-
-Direct dependencies (N total):
-  - Call sites (N):
-      <file:line>  <containing function/class>  reach: <local|module|cross-module|external>
-      ...
-  - Overrides (N):
-      <file:line>  <subclass/trait/impl>
-  - Tests (N):   <file:line list>
-  - Factories / seeders (N):   <file:line list>
-  - DB refs (N):   <file:line or schema object>
-  - Config / docs (N):   <file:line list>
-
-Indirect dependencies (2nd order, bounded):
-  - Events → listeners:   <event name> → <listener file:line>
-  - Jobs → workers:       <job name>   → <worker file:line>
-  - API → clients:        <endpoint>   → <resource/spec file:line>
-
-Reach summary:
-  local: N · module: N · cross-module: N · external: N
-
-Risk surfaces:
-  - Signature break:   <list>
-  - Behavior change:   <list>
-  - Data migration:    <list>
-  - Contract change:   <list>
-
-Open questions:
-  - <anything grep could not resolve or owners unknown>
-```
-
-Required fields (ordered):
-
-1. **Skill** and **Change** — one-line edit summary
-2. **Direct deps** — grouped by class, each with file:line citations and exact counts
-3. **Indirect deps** — 2nd-order only, bounded
-4. **Reach summary** — counts per reach level
-5. **Risk surfaces** — deps grouped by risk type
-6. **Open questions** — unresolved items with grep evidence
-
-Runtime confirmation (e.g. *"actually run the test suite to see what breaks"*,
-*"diff the OpenAPI spec"*) is a follow-up for the implementer — **this skill
-does not execute code, run tests, or touch the network**.
-
-## Gotcha
-
-* **Reflection / string-based dispatch** — `call_user_func`, event names as
-  strings, Laravel `resolve($classString)`. Grep the string too, not just the symbol.
-* **Dynamic column access** — `$model->{$field}` or query builder `->get([...])`
-  with variable arrays. A column rename can leak through these.
-* **Trait / mixin fan-out** — overriding a method pulled in via trait affects
-  every class using the trait. Enumerate trait users.
-* **Migration ordering** — the column exists in migration X; migration Y later
-  renames it. Both must change together.
-* **Stopping at first order** — renaming an event without updating the queued
-  job class-name serializer silently drops jobs. Always check event/job fan-out.
-* **Counting fuzzily** — `"about 10 callers"` is not a blast radius. Count exact.
-
-## Do NOT
-
-* NEVER return `safe` out of politeness when external reach exists — mark it clearly
-* NEVER silently fall back to "module-level impact" when grep shows cross-module callers
-* NEVER claim a dependency without a file:line citation from grep output
-* NEVER chase deps past 2nd order without explicit scope approval — flag and stop
-
-## References
-
-- **Martin Fowler — "Refactoring: Improving the Design of Existing Code"** (2018)
-  — chapters on *Moving Features Between Objects* and *Organizing Data*
-  define safe rename/move sequences that map onto the reach levels used here.
-  [martinfowler.com/books/refactoring.html](https://martinfowler.com/books/refactoring.html)
-- [`data-flow-mapper`](../data-flow-mapper/SKILL.md),
-  [`threat-modeling`](../threat-modeling/SKILL.md),
-  [`systematic-debugging`](../systematic-debugging/SKILL.md) — sibling analysis skills.

package/.agent-src/skills/character-consistency/SKILL.md

@@ -1,141 +0,0 @@
----
-model_tier: inherit
-name: character-consistency
-description: "Use when a character must stay visually identical across AI video scenes — locks identity tokens (silhouette, palette, wardrobe, prop) in JSON. Triggers 'character lock', 'same character'."
-personas:
-  - hollywood-director
-domain: product
-workspaces:
-  - small-business
-packs:
-  - ai-video
-lifecycle: experimental
-trust:
-  level: experimental
-install:
-  default: false
-  removable: true
----
-
-# character-consistency
-
-> Lock a character's visual identity into
-> `agents/reference/ai-video/<project>/characters/<id>.json` so every scene
-> reuses the **exact same tokens** verbatim. Downstream skills
-> ([`video-director`](../video-director/SKILL.md),
-> [`pixar-storyteller`](../pixar-storyteller/SKILL.md),
-> [`motion-choreographer`](../motion-choreographer/SKILL.md)) read
-> this file and never paraphrase. Verified by visual regression
-> (pixel similarity ≥ 95%, Phase 6 Step 3).
-
-## When to use
-
-- A multi-scene run names the same character on screen more than
-  once — Character Lock is mandatory before the second scene drafts.
-- A character drift bug landed (face / outfit / prop changed between
-  scenes) — re-lock and rerun the affected scenes.
-- A series, episode, or recurring ad uses the same on-screen identity.
-
-Do NOT use when:
-
-- One-shot scene with no recurring character — overhead is wasted.
-- The "character" is an object or environment, not a person /
-  creature — use a `style.json` lock pattern in the project's notes
-  instead.
-
-## Procedure
-
-### Step 0: Inspect
-
-1. Check `agents/reference/ai-video/<project>/characters/` — if a lock already
-   exists for this id, **read it, do not redraft**. Edits require an
-   explicit revision note (Phase 6 visual regression must rerun).
-2. Confirm the character will appear in ≥ 2 scenes; one-shot → skip.
-
-### Step 1: Draft identity tokens
-
-Emit a JSON file at
-`agents/reference/ai-video/<project>/characters/<character-id>.json` with the
-following fields. Every field is mandatory; missing field → fail
-the lock.
-
-```json
-{
-  "id": "kebab-case-id",
-  "name": "Display Name",
-  "silhouette": "one-line read of the body shape from 30m",
-  "palette": ["#hex1", "#hex2", "#hex3"],
-  "wardrobe": "garment list, materials, era",
-  "signature_prop": "the one object that travels with them",
-  "posture_default": "how they stand when not acting",
-  "eye_behavior": "blink rhythm, glance habit",
-  "face": "age band, skin tone, hair (length / color / texture), distinguishing marks",
-  "voice_note": "timbre + cadence for native-audio adapters; null if N/A",
-  "reference_frame": "scenes/<id>/frames/<n>.png or null",
-  "version": 1
-}
-```
-
-### Step 2: Reference frame
-
-1. After the first scene renders, copy the highest-quality frame
-   showing the character full-face and full-body to
-   `agents/reference/ai-video/<project>/characters/<id>.ref.png`.
-2. Update `reference_frame` in the JSON to point at it.
-3. Phase 6 visual regression compares every subsequent scene's
-   character frame against this reference (ImageMagick `compare`
-   ≥ 95% similarity).
-
-### Step 3: Validate
-
-1. JSON parses (`jq . characters/<id>.json` exits 0).
-2. All mandatory fields present and non-empty.
-3. Palette has ≥ 2 and ≤ 5 hex values.
-4. Downstream skills cite this file by path, never paraphrase its
-   contents.
-
-## Output format
-
-1. **`agents/reference/ai-video/<project>/characters/<id>.json`** — locked
-   identity tokens, schema above.
-2. **`agents/reference/ai-video/<project>/characters/<id>.ref.png`** —
-   reference frame (added after first render).
-3. **`agents/reference/ai-video/<project>/characters/CHANGELOG.md`** — one
-   line per revision: `v<n> · YYYY-MM-DD · reason · scenes-to-rerun`.
-
-## Gotcha
-
-- The model wants to "improve" identity tokens on each scene —
-  this is the silent drift failure. Tokens are immutable until a
-  revision note bumps `version`.
-- Palette without a count fails downstream — adapters need a small
-  closed set (2–5 hex).
-- `voice_note: null` is explicit; missing the key entirely breaks
-  the schema validator.
-- Reference frame is captured *after* the first successful render,
-  not before — bootstrap scenes have no reference and only the
-  JSON locks them.
-- A revision (`version` bumped) requires Phase 6 visual regression
-  to rerun against every prior scene that used the old version.
-
-## Do NOT
-
-- Do NOT paraphrase identity tokens when drafting scene prompts —
-  copy verbatim or break the lock.
-- Do NOT edit a locked JSON in place without bumping `version` and
-  adding a CHANGELOG line.
-- Do NOT skip the reference frame after the first render — visual
-  regression has nothing to compare against.
-- Do NOT lock a character that appears in only one scene.
-
-## Policies
-
-When a character lock would identify or render a real person, consult before emitting the JSON:
-
-- [`agents/settings/policies/media/likeness.md`](../../../agents/settings/policies/media/likeness.md) — real-person identity tokens require a cited likeness release.
-- [`agents/settings/policies/media/public-figures.md`](../../../agents/settings/policies/media/public-figures.md) — recognised public figures carry the harder gate (publicity rights + transformative-intent).
-- [`agents/settings/policies/media/voice-cloning.md`](../../../agents/settings/policies/media/voice-cloning.md) — when `voice_note` references a real person's voice.
-- [`agents/settings/policies/media/disclosure.md`](../../../agents/settings/policies/media/disclosure.md) — outputs carrying a real-person lock require the non-removable AI-generation disclosure downstream.
-
-Refuse-and-surface the file path; do not silently sanitise the prompt.
-

package/.agent-src/skills/check-refs/SKILL.md

@@ -1,96 +0,0 @@
----
-model_tier: medium
-name: check-refs
-description: "Use when verifying cross-references between skills, rules, commands, guidelines, and context documents are not broken after edits, renames, or deletions."
-domain: process
-execution:
-  type: assisted
-  handler: shell
-  timeout_seconds: 60
-  allowed_tools: []
-  command:
-    - python3
-    - scripts/check_references.py
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-
-# check-refs
-
-## When to use
-
-Use this skill when:
-
-- A skill, rule, command, guideline, or context has been renamed or deleted
-- Linking a newly added artifact from elsewhere in `.agent-src.uncondensed/`
-- Preparing a PR that touches cross-references between agent artifacts
-- CI's `check-refs` job failed and the broken reference needs to be located
-
-Do NOT use when:
-
-- Only the body of a single file changed and no names or paths were touched
-- Checking frontmatter shape or required sections — use `lint-skills` instead
-- Verifying condensed vs uncondensed pairs — use `bash scripts/condense.sh --check` instead
-
-## Procedure
-
-### 1. Inspect the scope of recent changes
-
-Identify whether any artifact was renamed, moved, or removed since the last
-clean run. Cross-reference checks are relevant only when names or paths shift;
-pure body edits cannot break references.
-
-### 2. Dispatch via the runtime layer
-
-Invoke the skill through the runtime dispatcher so the `execution:` block in
-this skill's frontmatter governs the call:
-
-```bash
-python3 scripts/runtime_dispatcher.py run --skill check-refs
-```
-
-The dispatcher resolves the request, the shell handler runs
-`python3 scripts/check_references.py`, captures stdout/stderr, and returns a
-typed `ExecutionResult`.
-
-### 3. Verify the result
-
-Check the returned `ExecutionResult`:
-
-- `exit_code: 0` → all cross-references resolve
-- `exit_code: 1` → at least one broken reference — read `stdout` for file,
-  line, and the offending ref, then fix the source or update the target
-- `status: timeout` → the checker exceeded `timeout_seconds` — investigate
-- `status: error` → interpreter or script missing — confirm `python3` and
-  `scripts/check_references.py` are available at the repository root
-
-## Output format
-
-1. One-line summary: `success | failure | timeout | error`, exit code,
-   duration in milliseconds
-2. Count of broken references found, if any
-3. First 10 broken references with `file:line → missing-target`
-4. Next action: fix references, re-run the skill, or surface `stdout` for
-   review
-
-## Gotchas
-
-- The checker is read-only — it never rewrites references, so a clean run
-  after a fix must be produced by re-invoking the skill, not by assumption
-- Running outside the agent-config repo root makes the checker inspect zero
-  files and report a false pass
-- Relative links inside comments or fenced code blocks may still be parsed as
-  references depending on the checker's current rules; do not suppress a
-  broken ref without confirming it is a genuine false positive
-
-## Do NOT
-
-- Do NOT invoke `scripts/check_references.py` directly when the intent is to
-  verify the runtime path — always go through the dispatcher so the
-  `ExecutionResult` is produced and inspectable
-- Do NOT raise `timeout_seconds` to mask a slowdown — investigate which part
-  of the tree grew large enough to push past 60 seconds
-- Do NOT add piping or redirection to `command` — the handler uses
-  `shell=False` and will refuse anything outside pure argv form

package/.agent-src/skills/code-review/SKILL.md

@@ -1,224 +0,0 @@
----
-model_tier: high
-name: code-review
-description: "Use when the user says "review this", "check my code", or wants feedback on changes. Reviews for correctness, quality, security, and coding standards."
-domain: quality
-workspaces:
-  - engineering
-packs:
-  - engineering-base
----
-
-# code-review
-
-## When to use
-
-Use this skill when:
-- Reviewing a PR (own or someone else's)
-- Self-reviewing local changes before creating a PR
-- Responding to review feedback on your PR
-- The user asks to "review", "check", or "look at" code changes
-
-## Procedure: Review code
-
-### Mindset
-
-- **Be thorough but pragmatic** — catch real bugs, not style nitpicks that tools handle.
-- **Understand intent first** — read the PR description, linked ticket, and commit messages before looking at code.
-- **Check the full picture** — a change in a service may require changes in tests, migrations, docs.
-- **Assume good intent** — suggest improvements, don't criticize.
-
-### Review order
-
-1. **Understand the goal** — what is this change trying to achieve?
-2. **Architecture** — does the approach make sense? Right layer? Right pattern?
-3. **Correctness** — does it actually work? Edge cases? Error handling?
-4. **Quality** — types, naming, readability, DRY, SOLID?
-5. **Security** — input validation, authorization, injection?
-6. **Performance** — N+1 queries, missing indexes, unbounded queries?
-7. **Tests** — are new paths covered? Are existing tests still valid?
-8. **Conventions** — does it follow project standards?
-
-## Review checklist
-
-The checks below are stack-agnostic. For framework-specific conventions (PSR-12 + `declare(strict_types=1)`, FormRequest, single-action `__invoke`, API Resources, Pest, Blade escaping, Eloquent N+1) defer to the carve-outs:
-- PHP / Laravel → [`laravel`](../laravel/SKILL.md), [`laravel-validation`](../laravel-validation/SKILL.md), [`eloquent`](../eloquent/SKILL.md), [`pest-testing`](../pest-testing/SKILL.md), [`blade-ui`](../blade-ui/SKILL.md), [`php-coder`](../php-coder/SKILL.md)
-- Symfony → [`symfony-workflow`](../symfony-workflow/SKILL.md)
-- Next.js / TS → [`nextjs-patterns`](../nextjs-patterns/SKILL.md), [`react-shadcn-ui`](../react-shadcn-ui/SKILL.md)
-
-### Code quality
-
-| Check | What to look for |
-|---|---|
-| **Type discipline** | New code is fully typed in the project's idiom (PHP typed properties + `declare(strict_types=1)`, TS strict, Python type hints, Go / Rust by construction). |
-| **Style conformance** | Matches the project's formatter / linter output — no reformatting battles, no out-of-band style. |
-| **Naming** | Clear, descriptive names; matches the dominant casing in the surrounding code (camelCase / snake_case / PascalCase per the language's idiom). |
-| **Early returns** | No deep nesting. Guard clauses at the top. |
-| **Single responsibility** | Each class / module / function does one thing. HTTP handlers stay thin. |
-| **No magic** | No reach-through to globals (`app()`, `$_GET`, ambient context). No untyped data shapes leaking out of the I/O boundary. |
-| **Doc comments** | Only where the type system is insufficient (generics, complex shapes). No redundant docblocks. |
-
-### Architecture
-
-| Check | What to look for |
-|---|---|
-| **Layer separation** | Business logic in services / use-cases, not in HTTP handlers. Domain models stay I/O-free. |
-| **Handler shape** | New handlers follow the framework's recommended shape (Laravel single-action `__invoke`, Next.js route handler, Express handler-per-route). See the stack carve-out. |
-| **Input validation** | Validated at the request boundary via the framework's primitive (Laravel `FormRequest`, Zod / class-validator, Pydantic, struct-tag validators). No ad-hoc inline `if` checks. |
-| **Response shaping** | Returns through a transformer / serializer / DTO. Never returns raw ORM entities. |
-| **DTOs / value objects** | Structured data between layers, not raw associative arrays / `any` / `dict[str, Any]`. |
-| **Dependency injection** | Constructor injection (or framework-idiomatic equivalent). No service-locator calls in business logic. |
-
-### Database & Performance
-
-| Check | What to look for |
-|---|---|
-| **N+1 queries** | Relationship / association access in loops without eager / batch loading. |
-| **Missing indexes** | New columns used in `WHERE` / `JOIN` without a supporting index. |
-| **Unbounded queries** | Full-table reads (`Model::all()`, `SELECT *` without `LIMIT`, unpaged list endpoints). |
-| **Raw SQL** | Parameterised queries only. No string concatenation with user input. |
-| **Migrations** | Reversible. Targets the right connection / schema. Idempotent where the platform supports it. |
-| **Money / precision** | Uses an exact-precision type (PHP `decimal` / `Math` helper, TS bigint / decimal lib, Python `Decimal`), never `float`. |
-
-### Security
-
-| Check | What to look for |
-|---|---|
-| **Authorization** | Authz check at every state-changing endpoint (Laravel Policy, Symfony voter, NestJS guard, framework middleware). No unprotected mutating routes. |
-| **Input validation** | All user input validated at the boundary via the framework's primitive. |
-| **Mass assignment** | No bulk-binding raw request payloads to ORM entities without an explicit allow-list (`$fillable` / `$guarded` in Laravel, DTO mapping in TS / Python). |
-| **Injection** | No raw queries / command lines / template strings with unescaped user input. |
-| **Output encoding** | Template output is escaped by default; raw / unescaped output is intentional and reviewed (Blade `{{ }}` vs `{!! !!}`, React `dangerouslySetInnerHTML`, Jinja `\|safe`). |
-| **Sensitive data** | No secrets, tokens, or passwords in code, logs, or error responses. |
-
-### Tests
-
-| Check | What to look for |
-|---|---|
-| **Coverage** | New code paths have tests. Bug fixes have regression tests (RED → GREEN). |
-| **Test quality** | Tests verify behaviour, not implementation details. |
-| **Framework idiom** | Correct conventions for the project's test framework (Pest / PHPUnit, Jest / Vitest, pytest, `go test`, `cargo test`) — see the stack carve-out for specifics. |
-| **Test data** | Provisioned via the project's idiom (seeders, factories, fixtures, builders). |
-| **Assertions** | Meaningful assertions. Not just "no exception thrown". |
-| **Flaky risks** | Time-dependent tests freeze the clock (`travel()`, `jest.useFakeTimers()`, `freezegun`). No reliance on execution speed. |
-
-## Before creating a PR
-
-1. Run the project's quality pipeline (see the stack carve-out for the exact commands — PHP: `quality-tools`).
-2. Run tests via the project's runner (`make test`, `npm test`, `pytest`, `go test ./...`, or the project's wrapper script).
-3. Ensure CI passes on the branch.
-4. Self-review the diff: `git diff origin/main..HEAD`.
-
-## Receiving feedback
-
-### The response pattern
-
-When receiving code review feedback, follow this sequence:
-
-1. **READ** — Complete feedback without reacting.
-2. **UNDERSTAND** — Restate the requirement in your own words (or ask if unclear).
-3. **VERIFY** — Check the suggestion against codebase reality.
-4. **EVALUATE** — Is it technically sound for THIS codebase?
-5. **RESPOND** — Technical acknowledgment or reasoned pushback.
-6. **IMPLEMENT** — One item at a time, test each.
-
-If **any item is unclear**, STOP — do not implement anything yet. Items may be related;
-partial understanding leads to wrong implementation.
-
-### No performative agreement
-
-- **Do NOT** reply with "Great point!", "You're absolutely right!", "Excellent catch!" or similar.
-- **Instead:** Just fix it. "Fixed." or "Updated — [brief description of what changed]."
-- Actions speak louder than words — the code itself shows you heard the feedback.
-
-### Source-specific handling
-
-**Internal team feedback** (trusted colleagues):
-- Implement after understanding — no need for deep skepticism.
-- Still ask if scope is unclear.
-- Skip to action or technical acknowledgment.
-
-**External / Copilot / bot feedback** (less context):
-- Check: Technically correct for THIS codebase?
-- Check: Does it break existing functionality?
-- Check: Is there a reason for the current implementation?
-- Check: Does the reviewer understand the full context?
-- **YAGNI check:** If the reviewer suggests "implementing properly", grep the codebase
-  for actual usage. If unused → suggest removing (YAGNI).
-- If it conflicts with existing architectural decisions → discuss with the team first.
-
-### When to push back
-
-Push back when:
-- Suggestion breaks existing functionality.
-- Reviewer lacks full context.
-- Violates YAGNI (unused feature).
-- Technically incorrect for this stack.
-- Legacy/compatibility reasons exist.
-- Conflicts with architectural decisions.
-
-How: Use technical reasoning, not defensiveness. Reference working tests/code.
-
-### Addressing PR comments systematically
-
-When working through review comments on a PR:
-
-1. **List** all comments and review threads (`gh pr view --comments`).
-2. **Categorize**: blocking → simple fixes → complex fixes.
-3. **Clarify** anything unclear BEFORE implementing.
-4. **Fix** one at a time, test each.
-5. **Reply in the thread** — not as a top-level PR comment.
-
-```bash
-# Reply to a specific review comment thread
-gh api repos/{owner}/{repo}/pulls/comments/{comment_id}/replies \
-  -f body="Fixed in latest commit."
-```
-
-## Output format
-
-When reviewing code, structure feedback by severity:
-
-```
-🔴 **Blocker** — must fix before merge
-Description of the issue and why it's critical.
-
-🟡 **Suggestion** — should fix, improves quality
-Description and suggested improvement.
-
-🟢 **Nit** — optional, minor improvement
-Description.
-```
-
-Group related findings. Don't repeat what the project's linter / type-checker already catches — focus on
-logic, architecture, and things tools can't detect.
-
-## Adversarial review
-
-Before creating a PR or presenting code changes, run the **`adversarial-review`** skill.
-Focus on the "Code changes / Refactoring" attack questions.
-
-## Auto-trigger keywords
-
-- code review
-- PR review
-- pull request
-- review checklist
-- review feedback
-- review changes
-- check my code
-
-## Gotcha
-
-- Don't rewrite code that works and is tested just because you'd write it differently.
-- The model tends to suggest changes that are out of scope — stay focused on the PR's intent.
-- "I would prefer X" is not a valid review comment unless X prevents a bug or violates a rule.
-- Always check if the PR has tests — missing tests is always worth flagging.
-
-## Do NOT
-
-- Do NOT approve without actually reading the code.
-- Do NOT agree with review comments without verifying them against the codebase.
-- Do NOT use performative language when responding to feedback ("Great point!", "Excellent catch!").
-- Do NOT nitpick style issues the project's formatter / auto-refactor (ECS, Prettier, Ruff, gofmt) handles automatically.
-- Do NOT merge without CI passing and quality checks green.