@event4u/agent-config 5.10.1 → 6.1.0

package/.agent-src/skills/tailwind-engineer/SKILL.md

@@ -1,148 +0,0 @@
----
-model_tier: medium
-name: tailwind-engineer
-description: "Use when writing or reviewing Tailwind CSS — utility-first, design-token discipline, no inline-style drift, responsive variants, dark mode — even on 'style this' or 'mach das hübsch'."
-personas:
-  - frontend-engineer
-domain: engineering
-workspaces:
-  - engineering
-packs:
-  - engineering-base
----
-
-# tailwind-engineer
-
-> Apply utility-first discipline. Reach for design tokens before
-> arbitrary values, compose with `@apply` only where it earns its
-> keep, and reject inline `style=` drift. The skill is the **how**
-> for any Tailwind-stack screen; pair with
-> [`existing-ui-audit`](../existing-ui-audit/SKILL.md) for the **what
-> already exists** and [`fe-design`](../fe-design/SKILL.md) for the
-> **why**.
-
-## When to use
-
-- Writing or reviewing Tailwind classes in Blade, Livewire, or React
-  components.
-- A diff introduces inline `style=` for dynamic values, hex codes
-  not in `tailwind.config`, or `!important`.
-- Class lists balloon past ~12 utilities and the component is
-  hard to read or duplicate.
-- German triggers: "stile mit Tailwind", "design tokens nutzen",
-  "warum nicht inline?".
-
-Do NOT use when:
-
-- The stack is not Tailwind (vanilla CSS, CSS-in-JS, MUI) — skip.
-- The question is component shape, not styling — route to
-  [`ui-component-architect`](../ui-component-architect/SKILL.md).
-- An accessibility issue is the symptom (focus ring, contrast, hit
-  area) — route to [`accessibility-auditor`](../accessibility-auditor/SKILL.md).
-
-## Procedure
-
-### 1. Resolve to design tokens first
-
-Inspect `tailwind.config.{js,ts}` (or the equivalent `@theme` block)
-and identify the configured tokens. Map every requested colour,
-radius, spacing, shadow, font-size to a configured token. If the design hands you `#3B82F6`, use
-`bg-blue-500` (or the project's named token). Arbitrary values
-(`bg-[#3B82F6]`, `mt-[17px]`) are a smell — accept only with a
-one-line comment naming the design source.
-
-### 2. Compose, don't inline
-
-Inline `style="..."` is allowed only for **runtime-computed values**
-the build cannot know (server-pushed colour, animated transform
-target). Static values inline are a regression — replace with a
-utility, an arbitrary value, or a token extension.
-
-### 3. Order classes for scan-ability
-
-Group by axis: layout → box-model → typography → colour → state
-→ responsive. Most projects pin this with `prettier-plugin-tailwindcss`;
-if the plugin is configured, run it; if not, follow the order
-manually. Reviewer should read intent in one pass.
-
-### 4. Extract only when duplicated ≥ 3 times
-
-The first two repetitions are noise; the third is a pattern.
-Extract via:
-
-| Mechanism | When |
-|---|---|
-| Component (Blade/Livewire/React) | Different content, same shell |
-| Class string constant | Same shell, different consumers in same file |
-| `@apply` in CSS | Cross-file shared visual primitive (button, badge) |
-| Tailwind plugin | Tokens or variants, not classes |
-
-`@apply` for a one-off is a regression — keep utilities inline
-until the third use earns extraction.
-
-### 5. Responsive + dark + state in that order
-
-Class order within an axis: base → `sm:` → `md:` → `lg:` → `xl:` →
-`dark:` → state (`hover:`, `focus:`, `disabled:`, `aria-*:`).
-Mixing the order makes diffs noisy. State on top of dark on top
-of responsive matches Tailwind's cascade and reads top-down.
-
-## Output format
-
-When reviewing or proposing styles, return:
-
-1. Token map — every colour, spacing, radius, shadow, font-size mapped
-   to its configured token; arbitrary values flagged with the design
-   source they cite.
-2. Class list — ordered (layout → box-model → typography → colour →
-   state → responsive); inline-style use justified per element.
-3. Extraction + risk call-out — component / constant / `@apply` / none
-   with reason; risks named (arbitrary values, `!important`, dark-mode
-   gaps, non-token references).
-
-Concrete shape:
-
-```
-Element:        <selector or component name>
-Token map:      <colour/spacing/etc → config token>
-Class list:     <ordered classes>
-Inline style:   <only if runtime-computed; else "none">
-Extraction:     <component | constant | @apply | none — reason>
-Risks:          <arbitrary values, !important, dark-mode gaps>
-```
-
-## Gotcha
-
-- `space-x-*` / `space-y-*` collide with `flex-wrap` and RTL — use
-  `gap-*` on the flex/grid parent unless the design demands otherwise.
-- `dark:` variants need a token map in both modes; one-sided dark
-  styling is half a feature.
-- Arbitrary values (`mt-[17px]`) survive Tailwind upgrades but
-  break the design system; they accumulate silently.
-- `@apply` inside component CSS interacts with PurgeCSS — keep it
-  in files Tailwind scans, not in vendor CSS.
-- **Anti-AI-slop: gradients.** Unless audit-pinned or brief-explicit,
-  avoid the default purple-to-blue / cyan-to-pink gradients on white —
-  they read as auto-generated. Reach for a single accent from the
-  token map, or a duotone built from configured tokens.
-- **Anti-AI-slop: typography.** Unless audit-pinned, avoid surfacing
-  the system stack (`font-sans` fallback to Arial / Helvetica / Inter
-  via system defaults) as the *visible* body face. If `tailwind.config`
-  pins a font family, use it; if not, treat the missing token as a
-  gap to flag, not a license to ship the OS default.
-- **Anti-AI-slop: layout.** Unless audit-pinned, the centered hero +
-  3-column features + CTA stack is the AI-template tell. Break the
-  grid intentionally (asymmetric column split, overlap, diagonal
-  flow) when the brief allows; cite the design brief's `aesthetic:`
-  line if `fe-design`'s aesthetic-direction section produced one.
-
-## Do NOT
-
-- Do NOT add `!important` to win a specificity fight; restructure
-  the cascade or extract the conflicting style.
-- Do NOT introduce a new colour outside `tailwind.config` without
-  also adding the token; one-off hex codes drift the system.
-- Do NOT use `@apply` to avoid utility verbosity inside a single
-  component — extract the component instead.
-- Do NOT ship `style=` for static values; that is a CSS regression
-  the linter will not catch.

package/.agent-src/skills/technical-specification/SKILL.md

@@ -1,251 +0,0 @@
----
-model_tier: inherit
-name: technical-specification
-description: "Use when the user says "write a spec", "create RFC", "write a PRD", or "document this decision". Writes technical specifications, PRDs, RFCs, and ADRs with clear structure."
-domain: product
-council_depth: deep
-workspaces:
-  - product
-packs:
-  - product-basic
-trust:
-  level: professional
-install:
-  removable: true
----
-
-# technical-specification
-
-## When to use
-
-Use this skill when:
-- Writing a technical specification for a new feature or system
-- Writing a Product Requirements Document (PRD) when user pain leads and solution shape follows
-- Creating an architecture decision record (ADR)
-- Documenting a technical RFC (Request for Comments)
-- Planning a significant technical change that needs team review
-
-Do NOT use when:
-- Trivial changes (a good PR description is enough)
-- Implementation work (use `feature-planning` or `php-coder` skill)
-
-## Procedure: Write a spec
-
-### Technical Specification (full)
-
-For complex features or systems. Stored in `agents/features/` or module `agents/features/`.
-
-```markdown
-# Technical Specification: {Title}
-
-## Status
-{ Draft | In Review | Approved | Implemented | Superseded }
-
-## Summary
-{2-3 sentences explaining what this spec proposes and why.}
-
-## Problem
-{What pain point or limitation does this address?}
-
-## Goals
-- {Specific, measurable goal}
-- {Another goal}
-
-## Non-Goals
-- {What this spec explicitly does NOT cover}
-
-## Proposed Solution
-
-### Overview
-{High-level description of the approach.}
-
-### Detailed Design
-{Technical details — data models, APIs, algorithms, flows.}
-
-### Alternatives Considered
-| Alternative | Pros | Cons | Why rejected |
-|---|---|---|---|
-
-## Migration Plan
-{How to transition from current state to the proposed solution.}
-
-## Risks and Mitigations
-| Risk | Likelihood | Impact | Mitigation |
-|---|---|---|---|
-
-## Open Questions
-- [ ] {Unresolved question}
-
-## References
-- {Links to related docs, tickets, or external resources}
-```
-
-### Product Requirements Document (PRD)
-
-For features whose **shape is product-driven** rather than implementation-driven —
-when "what users get" matters more than "how the code is wired". Use a PRD
-when a Technical Specification would over-index on internals and under-index
-on user value. Stored in `agents/features/` next to the technical spec when
-both exist.
-
-```markdown
-# PRD: {Title}
-
-## Status
-{ Draft | In Review | Approved | Shipped | Parked }
-
-## Problem
-{The user-visible pain. One paragraph. Cite evidence — support tickets,
-analytics, user quotes — not assumptions.}
-
-## Success Criteria
-- {Measurable outcome with a number and a timeframe}
-- {Another measurable outcome}
-
-## Non-Goals
-- {What this PRD explicitly does NOT cover — protect scope}
-
-## User Stories
-- As a {role}, I want to {action}, so that {outcome}.
-- As a {role}, I want to {action}, so that {outcome}.
-
-## Major Modules
-{The 3-7 functional building blocks the feature decomposes into. One
-sentence each — what it does, not how. Implementation lives in the
-technical spec, not here.}
-
-- **{Module name}** — {one-sentence responsibility}
-- **{Module name}** — {one-sentence responsibility}
-
-## Open Questions
-- [ ] {Unresolved product question — pricing, permission, copy, edge case}
-
-## References
-- {Links to research, related PRDs, technical spec when it exists}
-```
-
-**PRD vs Technical Specification — when to pick which:**
-
-- **PRD first** when the user pain is clear but the solution shape is not
-  ("users can't share dashboards" → PRD scopes the problem; spec follows).
-- **Spec first** when the solution shape is clear but the implementation
-  is non-trivial ("rebuild auth on OAuth2" → spec leads; PRD often skipped).
-- **Both** when the feature is large enough that product and engineering
-  decisions belong in different artifacts.
-
-### Architecture Decision Record (ADR)
-
-For significant technical decisions. Stored in `agents/decisions/`.
-
-```markdown
-# ADR-{number}: {Title}
-
-## Status
-{ Proposed | Accepted | Deprecated | Superseded by ADR-{N} }
-
-## Context
-{What is the issue? What forces are at play?}
-
-## Decision
-{What is the change that we're proposing or have agreed to implement?}
-
-## Consequences
-
-### Positive
-- {Benefit}
-
-### Negative
-- {Drawback or tradeoff}
-
-### Neutral
-- {Other notable consequences}
-```
-
-### Lightweight RFC
-
-For smaller decisions that need team input. Can be a PR description or a short doc.
-
-```markdown
-# RFC: {Title}
-
-## Proposal
-{What do you want to do?}
-
-## Why
-{Why is this needed?}
-
-## How
-{Brief technical approach.}
-
-## Impact
-{What does this change? Who is affected?}
-
-## Open for feedback until: {date}
-```
-
-## Writing guidelines
-
-### Be specific, not vague
-
-```
-❌ "The system should be fast"
-✅ "API response time should be < 200ms at p95 for list endpoints"
-```
-
-### Include constraints
-
-- Performance requirements (latency, throughput)
-- Compatibility requirements (PHP version, browser support)
-- Security requirements (authentication, data sensitivity)
-- Scale requirements (data volume, concurrent users)
-
-### Show your reasoning
-
-Don't just present the solution — show **why** it was chosen over alternatives.
-The "Alternatives Considered" section is often the most valuable part.
-
-### Keep it actionable
-
-A spec should be implementable by someone who wasn't in the original discussion.
-If a developer reads only this document, they should be able to build it.
-
-## Integration with other systems
-
-- **Feature plans** reference specs when technical depth is needed.
-- **Roadmaps** are generated from specs after approval.
-- **ADRs** are referenced from `AGENTS.md` or module docs for historical context.
-- **Sessions** link to the spec being implemented.
-
-## Output format
-
-1. Technical specification document with architecture decisions
-2. API contracts, data models, and sequence diagrams
-3. Implementation plan with dependencies
-
-## Auto-trigger keywords
-
-- technical spec
-- PRD
-- product requirements
-- RFC
-- ADR
-- architecture decision
-
-### Validate
-
-- Verify every section of the spec template is filled in (no placeholders left).
-- Confirm constraints and limitations are explicit, not implied.
-- Check that the spec answers: What, Why, How, What not, and When.
-
-## Gotcha
-
-- A spec without constraints is fiction — always include technical limitations, timeline, and scope boundaries.
-- The model tends to write specs that describe the ideal solution without acknowledging existing code.
-- Don't write specs for trivial features — a spec is overhead that's only worth it for complex changes.
-
-## Do NOT
-
-- Do NOT write specs without researching the codebase first.
-- Do NOT present only one option — always consider alternatives.
-- Do NOT leave specs in "Draft" forever — push for a decision.
-- Do NOT implement before the spec is reviewed (for significant changes).

package/.agent-src/skills/testing-anti-patterns/SKILL.md

@@ -1,164 +0,0 @@
----
-model_tier: medium
-name: testing-anti-patterns
-description: "Use BEFORE writing or changing tests, adding mocks, or putting test-only methods on production classes — five Iron Laws and gates against mocking-the-mock, production pollution, silent partial mocks."
-domain: quality
-workspaces:
-  - engineering
-packs:
-  - engineering-base
----
-
-# testing-anti-patterns
-
-Tests must verify real behavior, not mock behavior. Mocks isolate; they are not the thing under test. This skill is the **prevention** layer; [`judge-test-coverage`](../judge-test-coverage/SKILL.md) catches what slips through afterwards.
-
-For the **process / rationalization** failure modes that fire *before* a
-test is written (the urges to skip TDD, keep code "as reference", patch
-without a regression test), see the sibling reference table in
-[`process-anti-patterns.md`](process-anti-patterns.md). Both layers are
-required — a correctly-mocked test that was written *after* the code is
-still test-after-the-fact.
-
-## When to use
-
-- About to write a new test that mocks a collaborator.
-- Tempted to add a method to a production class purely for test cleanup.
-- Mock setup is becoming longer than the test logic itself.
-- A test passes but you cannot explain *what real behavior* it verified.
-- Code review of a diff that adds mocks — run the gates below before approving.
-
-Do NOT use when:
-
-- You need to *write* tests (no anti-pattern present yet) — route to [`pest-testing`](../pest-testing/SKILL.md) or [`test-driven-development`](../test-driven-development/SKILL.md).
-- The test failure is a real bug — route to [`systematic-debugging`](../systematic-debugging/SKILL.md).
-- You need overall coverage assessment of a finished diff — route to [`judge-test-coverage`](../judge-test-coverage/SKILL.md).
-
-## The Iron Laws
-
-```
-1. NEVER test mock behavior — assert on real component behavior.
-2. NEVER add test-only methods to production classes — put them in test utilities.
-3. NEVER mock without understanding the dependency chain — observe first, mock minimally.
-4. NEVER ship partial mocks — mirror the real response shape completely.
-5. NEVER treat tests as an afterthought — write the failing test first.
-```
-
-## Procedure: Run the gate before each anti-pattern
-
-### 1. Inspect the diff before any new mock
-
-Before writing or extending a test, **inspect** the code under test and identify which collaborators are real, which are mocked, and which produce side effects the assertion depends on. Open the file, read the dependency chain, and write the chain down. Do not start mocking until the chain is on paper.
-
-### Anti-Pattern 1 — Asserting on mock elements
-
-Symptom: `expect(screen.getByTestId('sidebar-mock')).toBeInTheDocument()` or `$this->assertSee('mock-sidebar')`. Test passes when the mock is present, fails when it is not — proves nothing about the component.
-
-Gate:
-
-```
-BEFORE asserting on any mocked element / id / class:
-  Ask: "Am I asserting that the mock exists, or that the component behaves correctly?"
-
-  IF asserting that the mock exists:
-    STOP — delete the assertion or unmock the dependency.
-    Replace with a behavior assertion (role, output, side effect).
-```
-
-### Anti-Pattern 2 — Test-only methods in production classes
-
-Symptom: `Session::destroy()` only ever called from `tearDown`. Production class polluted with code dangerous in production.
-
-Gate:
-
-```
-BEFORE adding any method to a production class:
-  Ask: "Is this only used by tests?"
-  IF yes:
-    STOP — move it to a test utility / trait / helper.
-  Ask: "Does this class own this resource's lifecycle?"
-  IF no:
-    STOP — wrong class for this method.
-```
-
-Replacement: a `tests/Support/cleanupSession.php` helper or a trait used only by test classes.
-
-### Anti-Pattern 3 — Mocking without understanding
-
-Symptom: A mocked method had a side effect the test depended on (e.g. wrote config). Mock kills the side effect; the test passes for the wrong reason or fails mysteriously.
-
-Gate:
-
-```
-BEFORE mocking any method:
-  STOP — do not mock yet.
-  1. List the side effects the real method produces.
-  2. List which of those side effects the test actually depends on.
-  3. If the test depends on any of them, mock at a *lower* level (the slow / external bit), preserving the necessary behavior.
-  IF unsure:
-    Run the test with the real implementation FIRST. Observe what fails.
-    THEN mock minimally, just below the failing seam.
-
-  Red flags:
-    - "I'll mock this just to be safe."
-    - "This might be slow, better mock it."
-    - You cannot draw the dependency chain.
-```
-
-### Anti-Pattern 4 — Partial / incomplete mocks
-
-Symptom: Mock returns only the fields the immediate test reads. Downstream code accesses an absent field and the test passes; integration breaks.
-
-Iron Rule: mock the **complete** response shape that the real API returns, not just the fields your assertion uses. If you cannot enumerate the shape, you should not mock.
-
-```
-BEFORE creating a mock response object:
-  1. Examine the real response (docs, recorded fixture, type definition).
-  2. Include EVERY documented field — even ones the test does not read.
-  3. If the shape is unknown, capture a real response into `tests/fixtures/` instead of inventing one.
-```
-
-**Concrete capture tools** for recording the real shape: `curl -s <url> | jq '.'` against a staging endpoint, Postman's "Save Response", Laravel's `Http::fake()` in record mode, or a Playwright network-trace export. Filter the captured payload with `jq` / `grep` to keep only the fields your fixture documents — **do not** dump unredacted secrets into `tests/fixtures/`.
-
-### Anti-Pattern 5 — Tests as an afterthought
-
-Symptom: "Implementation complete, ready for testing." Implementation went in without tests. TDD was skipped, anti-patterns 1–4 are now likely.
-
-Gate: a feature is not complete until a failing-then-passing test cycle ran for it. Route to [`test-driven-development`](../test-driven-development/SKILL.md).
-
-## Output format
-
-1. The mocking decision recorded as a one-line comment in the test file (`// mock at <seam>: <reason>`).
-2. The replacement test (or refactor) once an anti-pattern is identified.
-3. If a test-only method moved out of production, the diff must show both the deletion and the test-utility addition.
-
-## Gotcha
-
-- Vague-test asserts (`assertTrue($result)`) hide mock-behavior assertions — flag any test where the assertion does not name an observable behavior.
-- A "complete" mock that mirrors a v1 API silently rots when v2 ships — link mock fixtures to a real recorded response and re-record on schema changes.
-- Layer 3 environment guards from [`defense-in-depth`](../defense-in-depth/SKILL.md) often expose anti-pattern 2: if a production guard fires only in tests, the test setup is wrong, not the guard.
-- Long mock setups (> 50% of the test) are a signal that integration tests would be simpler — consider it before piling on more mocks.
-- **Diagnose, do not brute-force.** If a test fails after a mock change, **never guess** at another mock tweak — drop a debugger / Xdebug breakpoint at the seam, observe the real call shape, then mock minimally. Two retries without a root-cause hypothesis = STOP and rethink.
-
-## Do NOT
-
-- Do NOT add `*-mock` test ids to production templates.
-- Do NOT extend a production class to expose internals "just for testing".
-- Do NOT mock a method whose side effects the test depends on without reading the implementation.
-- Do NOT invent mock data shapes from memory — record from the real source.
-- Do NOT mark a story complete until at least one test was watched failing first.
-
-## Auto-trigger keywords
-
-- testing anti-patterns
-- mock behavior
-- test-only method
-- partial mock
-- mock without understanding
-
-## Provenance
-
-- Adopted from: `Microck/ordinary-claude-skills@8f5c83174f7aa683b4ddc7433150471983b93131:skills_all/testing-anti-patterns/SKILL.md` (MIT, © 2025 Microck).
-- Cross-linked: [`pest-testing`](../pest-testing/SKILL.md), [`test-driven-development`](../test-driven-development/SKILL.md), [`judge-test-coverage`](../judge-test-coverage/SKILL.md).
-- Provenance registry: `agents/settings/contexts/skills-provenance.yml` (entry: `testing-anti-patterns`).
-- Iron-Law floor: `verify-before-complete`, `skill-quality`.

package/.agent-src/skills/testing-anti-patterns/process-anti-patterns.md

@@ -1,67 +0,0 @@
-# Testing process anti-patterns — reference table
-
-Sibling reference for [`testing-anti-patterns`](SKILL.md) and
-[`test-driven-development`](../test-driven-development/SKILL.md).
-
-`testing-anti-patterns/SKILL.md` covers **mock-isolation** failure modes
-(mocking-the-mock, production pollution, partial mocks). This doc covers
-the **process / rationalization** failure modes — the urges that fire
-*before* the test is written and convince you to skip TDD entirely.
-
-Both layers are required. A correctly-mocked test that was written *after*
-the code is still test-after-the-fact. A TDD-first test that mocks itself
-is still mocking the mock.
-
-## The Iron Law (delete-and-restart)
-
-```
-WHEN YOU FIND YOURSELF KEEPING UNTESTED CODE "AS REFERENCE" WHILE WRITING
-A TEST FOR IT — DELETE THE CODE. WRITE THE TEST. THEN REIMPLEMENT.
-```
-
-The cheap path is one extra round-trip. The expensive path is a test that
-silently encodes the bug it was supposed to catch.
-
-## 12-row anti-rationalization table
-
-The urge to skip TDD is strongest on tasks where TDD matters most. Name
-the rationalization, then reject it:
-
-| # | Thought | Reality |
-|---|---|---|
-| 1 | "This is too simple to need a test" | Simple code still breaks. A test takes less time than one debug cycle. |
-| 2 | "I'll add the test after the code works" | A test written after code that passed first try has never failed. It does not prove the code is correct. |
-| 3 | "I already ran it manually" | Manual runs are not repeatable. The next edit breaks it silently. |
-| 4 | "Deleting code I just wrote is wasteful" | Sunk cost. The cheap path: delete, write the test, reimplement minimally. |
-| 5 | "I'll keep the code as reference while I write the test" | You will read it and adapt to it. That is test-after-the-fact with extra steps. Delete it. |
-| 6 | "I just need to explore the API first" | Spike on a throwaway branch. Then delete the spike and restart with TDD. |
-| 7 | "The test is too hard to write" | That signals a design problem in the code, not the test. Listen to it — refactor the seam, then test. |
-| 8 | "This bug is urgent, no time for a test" | The test **is** the fastest path to a verified fix. Guessing takes longer and re-occurs. |
-| 9 | "CI is red — patch first, test later" | A red CI is the cheapest moment to write the regression test. The patch without the test invites the same bug back. |
-| 10 | "The test is just proof-of-work for the PR review" | A test that exists to placate review is not a test — it is theater. Either it asserts behavior or delete it. |
-| 11 | "The dependency is too awkward to seam" | The seam discomfort *is* the design feedback. A constructor-injection refactor pays for itself the second time you change the dependency. |
-| 12 | "We'll add the test in a follow-up PR" | Follow-up PRs that add tests to merged code arrive 0% of the time. The test ships with the change or never. |
-
-## When to use this doc
-
-- Reviewing your own draft before writing a test — read the table, check
-  none of the 12 are firing in your head.
-- Reviewing a teammate's PR — if the PR description matches one of the 12
-  patterns, surface the row number in the review.
-- Onboarding — pair with [`test-driven-development`](../test-driven-development/SKILL.md)
-  to give new devs the *why* behind the discipline.
-
-## Cross-references
-
-- Mock-specific anti-patterns: [`testing-anti-patterns`](SKILL.md)
-- TDD discipline: [`test-driven-development`](../test-driven-development/SKILL.md)
-- Coverage hygiene on a finished diff: [`judge-test-coverage`](../judge-test-coverage/SKILL.md)
-- Pest conventions: [`pest-testing`](../pest-testing/SKILL.md)
-- Quality tooling: [`quality-tools`](../quality-tools/SKILL.md)
-
-## Provenance
-
-- Adapted from `obra/superpowers@v5.1.0` `testing/anti-patterns.md`.
-- Council convergence (anthropic/claude-sonnet-4-5 + openai/gpt-4o,
-  2026-05-07): both members ADOPT — the catalogue surfaces specific
-  rationalization patterns that would otherwise leak past code review.