@event4u/agent-config 1.9.1

package/.agent-src/skills/aws-infrastructure/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: aws-infrastructure
+description: "Use when working with AWS resources — ECS Fargate, ECR, EFS, Secrets Manager, gomplate templates, multi-env deployments — even when the user says 'deploy to staging' without naming AWS."
+source: package
+---
+
+# aws-infrastructure
+
+## When to use
+
+Use this skill when working with AWS infrastructure, deployment configurations, ECS task definitions, or environment-specific settings.
+
+Do NOT use when:
+- Local development setup (use `docker` skill)
+- Application code changes
+
+## Procedure: Modify AWS infrastructure
+
+1. Read the `.aws/` directory (or equivalent) for environment configs and templates.
+2. Read CI/CD workflows (e.g., `.github/workflows/`) for the deployment pipeline.
+3. Check the environment-specific vars files.
+4. **Read project-level overrides** — check `agents/overrides/skills/aws-infrastructure.md` for project-specific service names, prefixes, and infrastructure details.
+
+## Architecture overview
+
+### Environments (typical setup)
+
+| Environment | Trigger | Notes |
+|---|---|---|
+| Review | PR with label | Ephemeral, per-branch |
+| Stage | Push to `main` | Persistent, pre-production |
+| Production | Release tag | Persistent, live |
+
+### Common AWS services
+
+| Service | Purpose |
+|---|---|
+| **ECS Fargate** | Container orchestration (no EC2 instances) |
+| **ECR** | Docker image registry |
+| **EFS** | Shared filesystem (private + public access points) |
+| **Secrets Manager** | `.env` file storage per environment |
+| **IAM Roles** | OIDC-based GitHub Actions authentication |
+| **VPC** | Networking (security groups, subnets) |
+
+### Vars file structure
+
+Environment-specific config files (e.g., `.aws/*.vars.yaml`) typically contain:
+
+```yaml
+AWS:
+  GlobalPrefix: {project}-{env}     # Resource naming prefix
+  Region: eu-central-1              # AWS region
+  RoleArn: arn:aws:iam::...        # GitHub Actions OIDC role
+  ECS:
+    Cluster: {project}-{env}       # ECS cluster name
+  VPC:
+    SecurityGroups: [...]
+    Subnets: [...]
+  EFS:
+    FileSystemId: fs-...
+```
+
+Read the actual vars files in the project for concrete values.
+
+### Template structure
+
+Templates commonly use **gomplate** for rendering. Typical templates:
+
+| Template | Purpose |
+|---|---|
+| `task-definition-web.tpl.yaml` | Web server (app + reverse proxy) |
+| `task-definition-worker.tpl.yaml` | Queue worker |
+| `task-definition-scheduler.tpl.yaml` | Task scheduler (cron) |
+| `task-definition-migrations.tpl.yaml` | One-shot migration runner |
+
+Template variables:
+- `{{ .Env.DockerImage }}` — Full ECR image URI with tag
+- `{{ .Env.CommitHash }}` — Git commit SHA
+- `{{ (ds "Vars").AWS.* }}` — Values from the vars file
+
+## Deployment flow
+
+### Standard (Stage/Production)
+
+1. **Build**: Docker image → ECR (tag: SHA + `latest`)
+2. **Migrations**: Run as ECS task (one-shot), wait for completion
+3. **Deploy Services**: Update ECS services with new task definitions
+
+### Review environments
+
+1. **Build**: Docker image → ECR (tag: SHA + branch-hash)
+2. **Deploy**: Create or update single ECS service (combined task)
+3. **Comment**: Post deployment URL on PR
+
+## Conventions
+
+### Authentication
+
+- GitHub Actions uses **OIDC** (no long-lived AWS credentials).
+- Role ARN is per-environment in the vars file.
+- `aws-actions/configure-aws-credentials` handles the OIDC exchange.
+
+### Image tagging
+
+- Primary tag: `sha-<full-commit-sha>` (immutable)
+- Secondary tag: `latest` (Stage/Production) or `<review-env-name>` (Review)
+
+### Secrets
+
+- `.env` files are stored in **AWS Secrets Manager**.
+- Naming convention: `<GlobalPrefix>-dotenv`.
+
+### Platform
+
+- Check the project's architecture target (`linux/arm64` for Graviton, `linux/amd64` for x86).
+- Ensure CI runners match the target architecture.
+
+## Infrastructure as Code
+
+The underlying AWS resources (ECS clusters, ALBs, RDS, Redis, IAM roles, security groups, etc.)
+are typically managed via **Terraform + Terragrunt** in a separate infrastructure repository.
+
+See the `terraform` and `terragrunt` skills for general IaC conventions.
+
+## Output format
+
+1. Modified infrastructure config/template files
+2. Environment-specific changes clearly separated
+3. Summary of what changed and which environments are affected
+
+## Auto-trigger keywords
+
+- AWS
+- ECS Fargate
+- ECR
+- EFS
+- Secrets Manager
+- deployment
+
+## Gotcha
+
+- Never hardcode AWS credentials — always use Secrets Manager or environment variables.
+- ECS task definitions are immutable — you create new revisions, not edit existing ones.
+- gomplate templates use `{{ }}` which conflicts with other template engines — escape carefully.
+
+## Do NOT
+
+- Do NOT change VPC/subnet/security group IDs without infrastructure team approval.
+- Do NOT modify IAM role ARNs — they are managed via Terraform.
+- Do NOT hardcode AWS account IDs in templates.
+- Do NOT change the `GlobalPrefix` — it's used for resource naming across AWS.
+- Do NOT switch platform architecture without updating all runners and ECS configs.

package/.agent-src/skills/blade-ui/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: blade-ui
+description: "Use when creating or editing Blade views, components, partials, layouts, or view logic — even when the user says 'add a new page' or 'render this data' without naming Blade."
+source: package
+---
+
+# blade-ui
+
+## When to use
+
+Use when creating or editing Blade views, components, partials, layouts, or forms.
+
+Do NOT use when:
+- API-only endpoints (use `api-endpoint` skill)
+- Livewire components (use `livewire` skill)
+- Flux UI components (use `flux` skill)
+
+## Procedure: Create Blade view or component
+
+### Step 0: Inspect
+
+1. Confirm Blade is used — check `resources/views`, components, layouts.
+2. Inspect existing UI patterns — layouts, partials, component naming, CSS conventions.
+3. Check form handling style — old input, validation errors, session flashes, reusable field partials.
+4. Inspect neighboring templates — match indentation, directives, slot usage, classes.
+5. Determine data flow — what belongs in controller/view model vs. template.
+
+### Step 1: Create the template
+
+1. Use the project's existing layout system.
+2. Keep template presentation-focused — no business logic, no DB queries.
+3. Extract repeated sections into partials or components.
+
+### Step 2: Handle forms (if applicable)
+
+1. Follow project's form style for labels, inputs, validation messages.
+2. Use CSRF protection correctly.
+3. Render validation errors consistently.
+4. Preserve user input with `old()` or project conventions.
+5. Reuse existing field components — don't duplicate.
+
+### Step 3: Validate
+
+1. Check escaping — `{{ }}` by default, `{!! !!}` only when explicitly safe.
+2. Check styling — Tailwind utility classes, not inline styles.
+3. Check accessibility — labels for form fields, semantic HTML.
+
+## Conventions
+
+→ See guideline `php/blade-ui.md` for full conventions.
+
+## Output format
+
+1. Blade view or component file(s) following project conventions
+2. Component class (if applicable) with typed props
+
+## Gotcha
+
+- `@include` shares parent scope — components don't. Know the difference.
+- Always use Tailwind utility classes — not inline styles.
+- Don't put business logic in templates — use view composers or Livewire.
+
+## Do NOT
+
+- Do NOT use `{!! !!}` with user input — XSS risk.
+- Do NOT put business logic in Blade templates — use Livewire or view composers.
+- Do NOT use inline styles — use Tailwind utility classes.
+
+## Auto-trigger keywords
+
+- Blade template
+- Blade component
+- Laravel view
+- partial
+- view logic

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

@@ -0,0 +1,185 @@
+---
+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."
+source: package
+---
+
+# 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 dependencies
+
+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`](../../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 dependencies 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 dependencies that grep did not find
+6. You have NOT merged direct and indirect dependencies — 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 dependencies** — grouped by class, each with file:line citations and exact counts
+3. **Indirect dependencies** — 2nd-order only, bounded
+4. **Reach summary** — counts per reach level
+5. **Risk surfaces** — dependencies 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 dependencies 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/bug-analyzer/SKILL.md

@@ -0,0 +1,256 @@
+---
+name: bug-analyzer
+description: "Use when the user shares a Sentry error, Jira bug ticket, or error description and wants root cause analysis. Also for proactive bug hunting and code audits for hidden bugs."
+source: package
+---
+
+# bug-analyzer
+
+## When to use
+
+**Reactive mode:** User reports a bug, shares a Sentry issue, or asks to investigate an error.
+**Proactive mode:** User asks to audit code for hidden bugs, edge cases, or risky patterns.
+
+Do NOT use when:
+
+* Feature development — route to [`feature-planning`](../feature-planning/SKILL.md)
+* Code style or refactoring — route to [`code-refactoring`](../code-refactoring/SKILL.md)
+* Performance issues — route to [`performance-analysis`](../performance-analysis/SKILL.md)
+* Security vulnerabilities — route to [`security-audit`](../security-audit/SKILL.md)
+* You need to trace how one data element flows through the code — route to
+  [`data-flow-mapper`](../data-flow-mapper/SKILL.md)
+* You need to enumerate every call site / consumer affected by a planned fix —
+  route to [`blast-radius-analyzer`](../blast-radius-analyzer/SKILL.md)
+
+## Input sources
+
+Bugs can come from multiple sources — gather as many as available:
+
+| Source | What it provides |
+|---|---|
+| **Branch name** | Auto-detected ticket ID (e.g., `fix/DEV-1234/...`) |
+| **Jira ticket** | Description, acceptance criteria, comments, priority |
+| **Sentry issue URL** | Stacktrace, affected users/environments, frequency, tags |
+| **Sentry event ID** | Specific occurrence with full context |
+| **Error message** | String to search in codebase |
+| **User description** | Reproduction steps, expected vs. actual behavior |
+
+### Branch ticket detection
+
+Always check the current branch for ticket IDs:
+
+```
+git branch --show-current
+```
+
+Pattern matching:
+- `fix/DEV-1234/description` → extract `DEV-1234`
+- `fix/PROJ-567-some-bug` → extract `PROJ-567`
+- `hotfix/DEV-999` → extract `DEV-999`
+- Regex: `[A-Z]+-[0-9]+`
+
+If found, auto-fetch the ticket and confirm with the user.
+
+## The Iron Law
+
+```
+NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
+```
+
+If you haven't completed Phase 1, you cannot propose fixes. Random fixes waste time and
+create new bugs. Quick patches mask underlying issues.
+
+### Red flags — STOP immediately
+
+- "Quick fix for now, investigate later"
+- "Just try changing X and see if it works"
+- "It's probably X, let me fix that"
+- Proposing solutions before tracing data flow
+- "One more fix attempt" (when already tried 2+)
+
+## Procedure: Analyze a bug
+
+### Phase 1: Root Cause Investigation
+
+Gather all available evidence before forming any hypothesis:
+
+- **Sentry URL** → use `get_issue_details` to fetch stacktrace, tags, environments, frequency.
+- **Sentry issue** → use `get_issue_tag_values` for browser, URL, environment distribution.
+- **Jira ticket** → fetch via Jira API, read description, comments, linked issues.
+- **Error message** → search the codebase for the message string.
+- **Branch name** → auto-detect ticket ID, fetch if found.
+- **Stacktrace** → start from top frame (crash site), trace down to entry point.
+- Use `codebase-retrieval` to find the relevant code.
+- Read each file in the call chain to understand the data flow.
+- Check existing context docs (`agents/contexts/`) for the affected area.
+- **Consult engineering memory.** Via
+  [`memory-access`](../../guidelines/agent-infra/memory-access.md) call
+  `retrieve(types=["historical-patterns", "incident-learnings"],
+  keys=[<error class>, <affected file paths>], limit=3)`. A prior
+  matching pattern or incident is the single most reliable accelerator
+  for root-cause analysis. Cite `id` and `path` verbatim so the user
+  can verify the precedent.
+
+#### Multi-component diagnostics
+
+When the system has multiple layers (Controller → Service → Repository → DB, or multi-tenant
+DB switching), add diagnostic instrumentation **before** proposing fixes:
+
+```
+For EACH component boundary:
+  - Log what data enters the component
+  - Log what data exits the component
+  - Verify environment/config propagation (e.g. DB connection, tenant context)
+  - Check state at each layer
+
+Run once → gather evidence → identify WHICH layer breaks → investigate that layer.
+```
+
+This is especially important for:
+- Multi-tenant database switching (wrong DB selected)
+- Queue jobs that lose tenant context
+- API → Service → Repository chains with data transformation
+- External service integrations (ProBauS, GPS, etc.)
+
+### Phase 2: Pattern Analysis
+
+- Find **working examples** of similar code paths in the codebase.
+- Compare the broken path against the working reference.
+- Identify the **specific difference** that causes the failure.
+- Check if the issue is isolated or part of a broader pattern.
+
+### Phase 3: Hypothesis and Testing
+
+- Form a **single hypothesis** based on evidence from Phase 1 and 2.
+- Test the hypothesis minimally — don't change multiple things at once.
+- If the hypothesis is wrong, go back to Phase 1 with new evidence.
+- **3-Strikes Rule:** If 3+ fix attempts fail, STOP. This signals an architectural problem,
+  not a bug. Discuss with the user before attempting more fixes. Signs:
+  - Each fix reveals new shared state or coupling in a different place.
+  - Fixes require "massive refactoring" to implement.
+  - Each fix creates new symptoms elsewhere.
+- Common root causes in this project:
+  - **Missing validation** on external sync data (CSV, XML, JSON imports).
+  - **Null values** from optional DB columns not handled.
+  - **Type mismatches** between legacy DB columns and PHP code.
+  - **Race conditions** in multi-tenant database switching.
+  - **Missing fallbacks** when external services are unavailable.
+
+### Phase 4: Implementation
+
+- Present the root cause and proposed fix **before implementing**.
+- Create a **failing test** that reproduces the bug.
+- Implement a **single, focused fix** — not multiple changes.
+- Consider side effects — does the fix affect other code paths?
+- Check if similar patterns exist elsewhere that need the same fix.
+- Add validation/monitoring (e.g. `MonitoringHelper::captureException()`) for data quality issues.
+- Verify the fix with the test from step 1.
+
+## Proactive mode (bug hunting)
+
+When asked to audit code for hidden bugs, use this workflow instead of the 4 phases above:
+
+### 1. Execution tracing
+
+Trace the actual code path step by step:
+- Follow data through each function call
+- Track state mutations and side effects
+- Note where exceptions are caught or swallowed
+- Identify where assumptions are made but not validated
+
+### 2. Edge case analysis
+
+For each code path, test these scenarios mentally:
+
+| Category | What to check |
+|---|---|
+| **Null/empty** | Null inputs, empty arrays, empty strings, missing keys |
+| **Boundaries** | Zero, negative, max int, first/last element |
+| **Type coercion** | String "0" vs int 0, loose comparison bugs |
+| **Timing** | Race conditions, stale cache, concurrent writes |
+| **State** | Uninitialized state, partial updates, rollback failures |
+| **External** | Network timeout, API errors, malformed responses |
+
+### 3. Known bug patterns (PHP/Laravel)
+
+- N+1 queries hidden in loops or accessors
+- Missing `->fresh()` after update when using same instance
+- Eloquent lazy loading in queued jobs (serialization issues)
+- `now()` timezone mismatches
+- Missing FK constraints allowing orphaned records
+- `DB::transaction()` with external side effects (emails, API calls)
+- Model events firing during seeding or migration
+- Off-by-one errors in pagination or date ranges
+- Silent exception swallowing (`catch (\Exception $e) {}`)
+- Floating point comparison for money/quantities
+
+### 4. Output format (proactive mode)
+
+For each bug found: **Bug** → **Location** → **Severity** → **Root Cause** → **Trigger** → **Fix** → **Confidence**
+
+## Commands
+
+| Command | Purpose |
+|---|---|
+| `bug-investigate` | Gather context from all sources, analyze, identify root cause |
+| `bug-fix` | Plan the fix, implement, verify with tests and quality tools |
+
+## Project awareness
+
+Read `AGENTS.md` and `./agents/` for project-specific architecture, business rules, and domain docs.
+Detect the project from the repo name (see `rules/architecture.md`).
+Check for existing contexts in `agents/contexts/` or module `agents/contexts/`.
+
+
+## Adversarial review
+
+Before implementing a fix, run the **`adversarial-review`** skill.
+Focus on the "Bug fixes" attack questions: Is this the root cause or a symptom? Will the fix break something else?
+
+## Auto-trigger keywords
+
+- bug investigation
+- error analysis
+- Sentry error
+- stacktrace
+- root cause
+
+## Rationalization prevention
+
+| Excuse | Reality |
+|---|---|
+| "Should work now" | RUN the verification — confidence ≠ evidence |
+| "It's probably X, let me fix that" | "Probably" = guessing. Complete Phase 1 first |
+| "Quick fix for now" | Quick fixes mask root causes and create technical debt |
+| "I'll investigate later" | Later never comes. Investigate now |
+| "One more fix attempt" (after 2+) | 3+ failures = architectural problem. Stop and discuss |
+| "Issue is simple, don't need process" | Simple issues have root causes too. Process is fast for simple bugs |
+| "Emergency, no time for process" | Systematic debugging is FASTER than guess-and-check thrashing |
+
+## Output format
+
+1. Root cause analysis with evidence trail
+2. Fix implementation or fix plan with specific files and changes
+3. Regression test covering the failure scenario
+
+## Gotcha
+
+- Don't assume the stacktrace shows the root cause — it often shows the symptom. Trace backwards.
+- Sentry groups similar errors — check if the "latest event" is actually representative of the issue.
+- The model tends to suggest fixes without verifying the fix doesn't break other code paths.
+
+## Do NOT
+
+- Do NOT start fixing before understanding the root cause.
+- Do NOT commit or push without permission.
+- Do NOT ignore Sentry data if available — it provides real-world context.
+- Do NOT fix only the symptom — trace to the root cause.
+- Do NOT attempt fix #4 without discussing the architecture with the user.
+
+## References
+
+- **Chain-of-Verification (CoVe)** — [arxiv.org/abs/2309.11495](https://arxiv.org/abs/2309.11495)
+  Generate candidate answers, then verify each with follow-up
+  questions. This skill adapts CoVe by verifying stacktrace-derived
+  hypotheses against Sentry data and surrounding code before fixing.
+