@event4u/agent-config 1.32.0 → 1.34.0

package/.agent-src/skills/livewire-architect/SKILL.md

@@ -0,0 +1,158 @@
+---
+name: livewire-architect
+description: "Use when shaping a Livewire component before code — full-page vs partial, parent/child split, event flow, state-vs-props boundary, hydration cost — even on 'add this Livewire component'."
+personas:
+  - frontend-engineer
+source: package
+domain: engineering
+---
+
+# livewire-architect
+
+> Architectural lens **above** the existing tactical [`livewire`](../livewire/SKILL.md)
+> skill. Decides component shape, lifecycle ownership, and the
+> full-page-vs-partial split *before* the first `mount()` is written.
+> The `livewire` skill handles Flux-component patterns and hydration
+> debugging once the shape is locked.
+
+## When to use
+
+- A Livewire feature is about to be built and the boundary between
+  components is unclear (one big component vs nested children?).
+- An existing component is "doing too much" — multiple unrelated
+  concerns, large `$listeners`, props bag growing turn over turn.
+- A page mixes Livewire + Blade partials and the data flow is
+  ambiguous (who owns `$user`, who emits, who listens?).
+- German triggers: "wie schneide ich das?", "Vollseite oder
+  Teilkomponente?", "wer feuert das Event?".
+
+Do NOT use when:
+
+- The shape is already locked and the question is mechanical
+  (Flux variant, `wire:model` modifier, `@entangle`) — route to
+  [`livewire`](../livewire/SKILL.md).
+- The page has no Livewire — pure Blade or Inertia/React — route
+  to [`blade-ui`](../blade-ui/SKILL.md) or [`react-shadcn-ui`](../react-shadcn-ui/SKILL.md).
+- The bug is a runtime hydration error — debug with `livewire`,
+  not redesign with this skill.
+
+## Procedure
+
+### 1. Analyze the existing screen — before designing anything
+
+Inspect the route and read the existing Blade / Livewire files to
+understand what's already there. List every dynamic surface on the
+page (form, table row, modal, nav badge). Mark each: **shared
+state** (other surfaces re-render on change), **local state** (only
+this surface cares), **server state** (must hit DB / queue). This
+analysis feeds every later step — do NOT skip ahead before the
+inventory is on paper.
+
+### 2. Choose the component shape
+
+Pick one **before** writing code:
+
+| Shape | When | Cost |
+|---|---|---|
+| Full-page component | Route owns the whole screen, single backing model, ≤ 3 related actions | Cheapest; one mount, one render |
+| Parent + nested children | Two or more independent state islands on one route | Two mounts; coordinate via events, not props churn |
+| Partial component on Blade | Mostly static page, one reactive island | Cheap; component sees the world via props only |
+| Stack of full-page components | Wizard / multi-step flow with own URL per step | Expensive; pick only when URL semantics matter |
+
+Rule: if a child needs ≥ 4 props from the parent and emits ≥ 3
+events back, the boundary is wrong — collapse or re-cut.
+
+### 3. Lock the state-vs-props boundary
+
+For each piece of data the component reads, mark **public property**
+(reactive, persisted in payload, expensive to dehydrate) or
+**computed / method-local** (cheap, recomputed on render). Public
+properties are the budget — keep ≤ 8 per component; more means
+the component is doing two jobs.
+
+### 4. Map the event flow
+
+Draw the events: `dispatch('foo')` → who listens? Cross-component
+events use `dispatch()`; parent ↔ child stays on `$parent.method()`
+when the child is owned. Avoid global events for parent-owned
+children — they break the ownership story.
+
+### 5. Lifecycle ownership
+
+For each side-effect (DB write, queue dispatch, redirect, flash),
+name the lifecycle hook: `mount` (one-time setup), `boot` (every
+request, idempotent), action method (user-initiated), `updated*`
+(reactive on property change). One hook per side-effect; if two
+hooks fire the same write, the design is wrong.
+
+### 6. Validate the design — before any code is written
+
+Walk the design back through these checks; every "no" means
+re-cut, not push forward:
+
+- Each component owns ≤ 8 public properties.
+- No child needs ≥ 4 props *and* emits ≥ 3 events back.
+- Every event has exactly one named listener.
+- Each side-effect maps to exactly one lifecycle hook.
+- The component shape table is filled in (no `<TBD>` cells).
+
+If any check fails, return to the relevant step and re-cut. The
+design must be approved by the user before handing off to
+`/livewire` for implementation.
+
+## Output format
+
+Return:
+
+1. Component shape decision — full-page / parent+children / partial /
+   stack — with the one-sentence trade-off rationale.
+2. Component inventory — for each: public props (≤ 8), state islands
+   owned, events listened/dispatched, side-effects on mount and action.
+3. Boundary-risk list and tactical follow-up — prop bags > 8, event
+   chains > 3 hops, shared mutable state, and the next handoff.
+
+Concrete shape:
+
+```
+Screen:           <route or feature>
+Component shape:  <full-page | parent+children | partial | stack>
+Why:              <one sentence — the trade-off chosen>
+
+Components:
+  - <Name> (full-page | partial)
+      Public props: [a, b, c]   (≤ 8)
+      Owns:         <state islands>
+      Listens to:   [event1, event2]
+      Dispatches:   [event3]
+      Side-effects: mount=<...>, action=<...>
+
+Boundary risks:
+  - <prop bag > 8 / event chain > 3 hops / shared mutable state>
+
+Tactical follow-up:
+  Hand off to /livewire for Flux variant + hydration check.
+```
+
+## Gotcha
+
+- Livewire 3 reactive props are not free — every public property
+  ships in the payload. Big arrays / DTOs as public state are a
+  performance bug waiting to fire under load.
+- Parent-owned children and global events do not mix; pick one
+  ownership story per component tree.
+- "Just one more public property" is the smell that turns a partial
+  into a god-component over three tickets.
+- Full-page component + Flux modal stack: the modal owns its own
+  mount cycle; do not push modal state into the page component.
+
+## Do NOT
+
+- Do NOT write `mount()` / Blade partials before the shape table is
+  filled in — picking the shape after coding is the most common
+  source of refactor debt.
+- Do NOT cite this skill alongside [`livewire`](../livewire/SKILL.md)
+  in the same step — they sit at different tiers; pick one per phase.
+- Do NOT design Inertia / React components with this skill — the
+  state-vs-props axis differs; route to the matching stack skill.
+- Do NOT push the architecture into the tracker as code AC — output
+  is a design note for refinement, not implementation steps.

package/.agent-src/skills/logging-monitoring/SKILL.md

@@ -2,6 +2,7 @@
 name: logging-monitoring
 description: "Use when working with logging or monitoring — Sentry error tracking, Grafana/Loki log aggregation, structured logging channels, or monitoring helpers."
 source: package
+domain: devops
 ---
 
 # logging-monitoring

package/.agent-src/skills/markitdown/SKILL.md

@@ -4,6 +4,7 @@ description: "Use when converting PDF, DOCX, XLSX, PPTX, EPUB, images, or audio
 status: active
 tier: senior
 source: package
+domain: process
 ---
 
 > **Pinned upstream:** `markitdown-mcp@0.0.1a4` (PyPI, released 2025-05-23, MIT, Beta). Re-verify per minor bump.

package/.agent-src/skills/mcp/SKILL.md

@@ -2,6 +2,7 @@
 name: mcp
 description: "Use when working with MCP (Model Context Protocol) servers — their tools, capabilities, and best practices for effective agent workflows."
 source: package
+domain: process
 ---
 
 # MCP Skill

package/.agent-src/skills/mcp-builder/SKILL.md

@@ -2,6 +2,7 @@
 name: mcp-builder
 description: "Use when building an MCP server in Python (FastMCP) or Node/TypeScript (MCP SDK) — agent-centric tool design, input schemas, error handling, and the 10-question evaluation harness."
 source: package
+domain: process
 ---
 
 # mcp-builder

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

@@ -2,6 +2,7 @@
 name: md-language-check
 description: "Use BEFORE saving any .md under .augment/, .agent-src*/, or agents/ — scans umlauts, German function words, and quoted German phrases outside DE:/EN: anchor blocks. Hard gate per language-and-tone."
 source: package
+domain: process
 execution:
   type: assisted
   handler: shell

package/.agent-src/skills/merge-conflicts/SKILL.md

@@ -2,6 +2,7 @@
 name: merge-conflicts
 description: "Use when the user has merge conflicts or says "resolve conflicts". Understands conflict markers, resolution strategies, and verification workflow."
 source: package
+domain: process
 ---
 
 # merge-conflicts

package/.agent-src/skills/migration-architect/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: migration-architect
+description: "Use when shaping a non-trivial migration — rollout phases, dual-write windows, cutover sequencing, deprecation cycles — hands off to `migration-creator` for DDL once locked."
+personas:
+  - backend-architect
+  - senior-engineer
+source: package
+domain: process
+---
+
+# migration-architect
+
+> Shape the **rollout strategy** for a migration before any DDL or
+> code is written. Plans phases, dual-write windows, cutover
+> sequencing, deprecation cycles, and cross-service coordination.
+> Hands off to [`migration-creator`](../migration-creator/SKILL.md)
+> for tactical DDL once the plan is locked.
+
+## When to use
+
+- A schema change spans more than one deploy.
+- A change requires a dual-write or backfill window.
+- The migration touches multiple services, queues, or consumers
+  whose order of update matters.
+- A column / table / API is being deprecated and the cycle needs
+  shape (announce → soft-fail → hard-fail → remove).
+
+Do NOT use when:
+
+- The change is a single additive migration safe in one deploy →
+  route to [`migration-creator`](../migration-creator/SKILL.md).
+- The decision is *whether* to migrate at all → route to
+  [`decision-record`](../decision-record/SKILL.md) first.
+- The concern is data correctness during the migration → route to
+  [`data-flow-mapper`](../data-flow-mapper/SKILL.md) and feed
+  findings back here.
+
+## Procedure
+
+### 1. Anchor on the goal
+
+Write one sentence: *"State X must become state Y across systems Z
+without breaking consumers W."* If you cannot, the migration is not
+ripe — stop.
+
+### 2. Identify the participating systems
+
+List every service, queue, batch job, third-party consumer, and
+client that reads or writes the affected schema. A system you
+forget is a cutover surprise.
+
+### 3. Pick a rollout shape
+
+| Shape | When to pick |
+|---|---|
+| Expand → migrate → contract | Schema additive first, code switches reads, then drop old shape |
+| Dual-write + backfill | Both shapes written for a window; backfill closes the gap |
+| Strangler fig | New path runs alongside old; traffic ramps over time |
+| Big-bang cutover | Rare; only when downtime is acceptable AND coordination cost is trivial |
+
+State *why* the shape fits — not just which one was picked.
+
+### 4. Sequence the phases
+
+For each phase, list:
+
+- **Trigger** — what condition starts it.
+- **Actions** — DDL, code deploy, feature flag, traffic shift.
+- **Reversibility** — can we abort here, and how?
+- **Exit gate** — what proves we can move to the next phase
+  (metric, sign-off, soak time).
+
+A phase without an exit gate is a wish; reject.
+
+### 5. Plan the deprecation cycle
+
+For anything being removed:
+
+- Announce window — comms cadence, who is told.
+- Soft-fail window — log + warn, do not break.
+- Hard-fail window — return errors.
+- Removal — DDL drop, code delete.
+
+Each window has a duration and a metric that justifies moving on.
+
+## Output format
+
+```
+Migration Architect
+Goal:     <one sentence>
+Systems:  <list>
+Shape:    expand-migrate-contract | dual-write | strangler | big-bang
+Reason:   <why this shape>
+
+Phases:
+  1. <name>  Trigger: <cond>  Exit: <gate>  Reversible: yes | costly | no
+       Actions: ...
+  2. ...
+
+Deprecation cycle (if any):
+  Announce <duration>  →  soft-fail <duration>  →  hard-fail <duration>  →  remove
+
+Next: /migration-creator for the DDL of phase 1
+```
+
+## Gotcha
+
+- The riskiest phase is the one with no rollback. Surface it
+  explicitly even if the user did not ask.
+- Soak times in hours when interest is in days are a smell. Match
+  the soak to the actual blast radius.
+
+## Do NOT
+
+- Do NOT write DDL — that is `migration-creator`'s job.
+- Do NOT collapse phases to "ship it" because the user is impatient;
+  surface the risk and let the user decide.
+- Do NOT skip the deprecation cycle because nobody is using the old
+  shape "for sure" — verify before skipping.

package/.agent-src/skills/migration-creator/SKILL.md

@@ -2,6 +2,7 @@
 name: migration-creator
 description: "Use when the user says "create migration", "add column", or "new table". Creates migrations with correct table prefixes, column naming, and multi-tenant awareness."
 source: package
+domain: engineering
 ---
 
 # migration-creator

package/.agent-src/skills/mobile-e2e-strategy/SKILL.md

@@ -2,6 +2,7 @@
 name: mobile-e2e-strategy
 description: "Use when picking a mobile E2E framework — Detox / Appium / Maestro / XCUITest / Espresso — or planning iOS Simulator / Android Emulator coverage in CI for RN, Expo, or native apps."
 source: package
+domain: quality
 ---
 
 # mobile-e2e-strategy
@@ -27,7 +28,7 @@ source: package
 
 ## Procedure
 
-1. **Classify the app.** Is it native iOS, native Android, React Native, Expo, Flutter, or a web view inside a shell?
+1. **Inspect and classify the app.** Identify the stack: native iOS, native Android, React Native, Expo, Flutter, or a web view inside a shell?
 2. **Classify the goal.** Smoke (boots + login + key flow), regression (every release), visual diff, accessibility audit, or performance baseline.
 3. **Pick the framework** using the decision matrix below.
 4. **Confirm host availability.** macOS for iOS Simulator (mandatory); any OS for Android Emulator.

package/.agent-src/skills/module-management/SKILL.md

@@ -2,6 +2,7 @@
 name: module-management
 description: "Use when the user says "create module", "explore module", or works within app/Modules/. Understands module structure, auto-loading, route registration, and namespace conventions."
 source: package
+domain: process
 ---
 
 # module

package/.agent-src/skills/multi-tenancy/SKILL.md

@@ -2,6 +2,7 @@
 name: multi-tenancy
 description: "Use when working with the multi-tenant architecture — customer DB switching, FQDN routing, tenant isolation, or cross-tenant operations."
 source: package
+domain: engineering
 ---
 
 # multi-tenancy

package/.agent-src/skills/okr-tree-modeling/SKILL.md

@@ -4,6 +4,7 @@ description: "Use when decomposing a company objective into team OKRs, auditing
 status: active
 tier: senior
 source: package
+domain: product
 ---
 
 # okr-tree-modeling

package/.agent-src/skills/openapi/SKILL.md

@@ -2,6 +2,7 @@
 name: openapi
 description: "Use when documenting APIs — OpenAPI/Swagger, PHP attributes, Redocly validation, versioned specs — even when the user just says 'document this endpoint' without naming OpenAPI."
 source: package
+domain: engineering
 ---
 
 # openapi

package/.agent-src/skills/override-management/SKILL.md

@@ -2,6 +2,7 @@
 name: override-management
 description: "Creates and manages project-level overrides for shared skills, rules, and commands — extending or replacing originals from .augment/ with project-specific behavior in agents/overrides/."
 source: package
+domain: process
 execution:
   type: assisted
   handler: internal

package/.agent-src/skills/performance/SKILL.md

@@ -2,6 +2,7 @@
 name: performance
 description: "Use when optimizing application performance — caching strategies, eager loading, query optimization, Redis patterns, or background job design."
 source: package
+domain: engineering
 ---
 
 # performance

package/.agent-src/skills/performance-analysis/SKILL.md

@@ -2,6 +2,7 @@
 name: performance-analysis
 description: "ONLY when user explicitly requests: performance audit, bottleneck analysis, or N+1 query detection. NOT for regular feature work."
 source: package
+domain: discovery
 ---
 
 # performance-analysis

package/.agent-src/skills/persona-writing/SKILL.md

@@ -2,6 +2,7 @@
 name: persona-writing
 description: "Use when creating or editing a persona in .agent-src.uncompressed/personas/ — voice / focus / unique questions / output expectations — even when the user just says 'add a reviewer voice for X'."
 source: package
+domain: process
 ---
 
 <!-- cloud_safe: degrade -->

package/.agent-src/skills/pest-testing/SKILL.md

@@ -2,6 +2,7 @@
 name: pest-testing
 description: "Use when writing, generating, or improving Pest tests for Laravel — clear intent, good coverage, maintainable structure, and alignment with project testing conventions."
 source: package
+domain: quality
 ---
 
 # pest-testing

package/.agent-src/skills/php-coder/SKILL.md

@@ -2,6 +2,7 @@
 name: php-coder
 description: "Writes or edits PHP code — controllers, classes, type hints, SOLID refactors, modern idioms — even without naming PHP. NOT for writing tests (use pest-testing) or explaining PHP concepts."
 source: package
+domain: engineering
 ---
 
 # coder

package/.agent-src/skills/php-debugging/SKILL.md

@@ -2,6 +2,7 @@
 name: php-debugging
 description: "Use when debugging PHP with Xdebug — breakpoints, step-through, dual-container setup, IDE configuration, header-based routing — even when the user just says 'why does this blow up on request X'."
 source: package
+domain: engineering
 ---
 
 # php-debugging

package/.agent-src/skills/php-service/SKILL.md

@@ -2,6 +2,7 @@
 name: php-service
 description: "Use when the user says 'create service', 'new service class', or needs a PHP service following SOLID principles with proper DI and repository usage."
 source: package
+domain: engineering
 ---
 
 # php-service

package/.agent-src/skills/playwright-architect/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: playwright-architect
+description: "Use when shaping a Playwright suite — locator strategy, Page Object boundaries, fixture composition, flake-prevention architecture, CI-vs-local split — even on 'design our E2E tests'."
+personas:
+  - frontend-engineer
+source: package
+domain: quality
+---
+
+# playwright-architect
+
+> Architectural lens **above** the existing tactical
+> [`playwright-testing`](../playwright-testing/SKILL.md). Decides
+> locator philosophy, Page Object boundaries, fixture composition,
+> and the CI-vs-local split *before* the first test is written.
+> The `playwright-testing` skill handles concrete assertions,
+> selectors, and visual-regression mechanics once the design is
+> locked.
+
+## When to use
+
+- A new Playwright suite is starting and the directory shape, fixture
+  hierarchy, and locator strategy are unsettled.
+- An existing suite has flake > 2 % runs, slow CI (> 10 min), or a
+  god-test file mixing unrelated journeys.
+- A second app / surface (admin, mobile-web, embedded widget) needs
+  to share fixtures with the main suite.
+- German triggers: "Playwright Setup planen", "Page Objects schneiden",
+  "warum flaket der Test?".
+
+Do NOT use when:
+
+- A single test fails and the question is the assertion or selector
+  — route to [`playwright-testing`](../playwright-testing/SKILL.md).
+- The platform is mobile-native (Detox, Appium, Maestro) — route to
+  [`mobile-e2e-strategy`](../mobile-e2e-strategy/SKILL.md).
+- Unit / component tests are the question — Playwright is the wrong
+  tool; route to the stack-specific testing skill.
+
+## Procedure
+
+### 1. Inspect the suite, pick the locator philosophy
+
+Review existing tests for current locator patterns; the established
+strategy wins unless it is the "last resort" tier. One philosophy
+per suite, written into `CONTRIBUTING-tests.md`:
+
+| Strategy | When |
+|---|---|
+| `getByRole` + accessible name | Default — couples tests to the user contract, not markup |
+| `data-testid` | Legacy markup, third-party widgets, hash-suffixed CSS modules |
+| Text content (`getByText`) | Static marketing pages, copy-stable surfaces |
+| CSS / XPath | Last resort — every use is a debt entry |
+
+Mixing strategies inside one test file is the smell — pick one and
+fall back only with comment.
+
+### 2. Cut Page Object boundaries
+
+A Page Object owns: (a) one URL or one logical surface (modal,
+drawer), (b) the locators on that surface, (c) the **actions** a
+user can perform there. It does NOT own assertions about other
+surfaces or test setup. Boundary rule: if two POs need to call
+each other, introduce a **flow object** (`SignupFlow`) above them.
+
+### 3. Compose fixtures, don't inherit
+
+Playwright fixtures stack via `test.extend()`. Three layers max:
+
+| Layer | Owns |
+|---|---|
+| Base | Browser, context, storageState, network mocks |
+| Auth | Logged-in user states (admin, member, guest) |
+| Domain | Pre-seeded entities for a journey |
+
+Deeper stacks become un-debuggable; flatten by extracting helpers.
+
+### 4. Plan flake prevention before the first failure
+
+Bake in: auto-retry on network idle, soft assertions for parallel
+checks, deterministic seed data, time freezing (`page.clock`),
+explicit `expect.poll()` for eventual consistency, no
+`waitForTimeout` ever. If a test needs `sleep`, the fixture is
+wrong.
+
+### 5. Split CI vs local execution
+
+Local: headed browser, single worker, slowMo enabled, video off,
+trace-on-retry. CI: headless, sharded workers (2–8), trace-on-first-retry,
+video-on-failure, Github reporter + HTML. Document both in
+`playwright.config.ts`; do not let local config leak into CI.
+
+## Output format
+
+Return:
+
+1. Locator + Page Object plan — chosen strategy, PO list with surface
+   and action count, flow objects when ≥ 2 POs collaborate.
+2. Fixture composition — base / auth / domain layer with what each
+   layer sets up.
+3. Parallelism + flake budget — worker count, shard strategy,
+   isolation, target flake ceiling, CI-vs-local config delta.
+
+Concrete shape:
+
+```
+Suite:            <name>
+Locator strategy: <getByRole | data-testid | text | mixed (justified)>
+Page Objects:     <list with surface owned + action count>
+Flow objects:     <list — only when ≥ 2 POs collaborate>
+Fixture layers:   base / auth / domain — each with what it sets up
+Parallelism:      <workers, shards, isolation strategy>
+Flake budget:     ≤ 1 % failure on green main; alert threshold
+CI-vs-local:      <key config delta, one bullet each>
+```
+
+## Gotcha
+
+- `page.waitForSelector` is almost always wrong — `expect(locator).toBeVisible()`
+  has built-in retry. The former teaches devs to think "wait, then
+  assert" instead of "auto-retry assertion".
+- Storage-state reuse across workers requires cookie domain
+  isolation; the same `auth.json` across two browsers in parallel
+  shares a session and corrupts state.
+- Visual regression in CI requires identical fonts and renderer —
+  pin the Docker image, never run visual tests against host
+  Chromium.
+- One Page Object per URL **looks** clean but creates god-objects
+  for SPA routes; cut by *user surface*, not by `pathname`.
+
+## Do NOT
+
+- Do NOT cite this skill alongside [`playwright-testing`](../playwright-testing/SKILL.md)
+  in the same step — they sit at different tiers; pick one per phase.
+- Do NOT design suites for component tests with this skill —
+  Playwright Component Testing has different fixture rules; route
+  there instead.
+- Do NOT promise zero flake; budget for ≤ 1 % and instrument the
+  metric. Zero is a goal that disguises silent retries.
+- Do NOT push the architecture into the tracker as code AC — output
+  is a design note for refinement, not implementation steps.

package/.agent-src/skills/playwright-testing/SKILL.md

@@ -2,6 +2,7 @@
 name: playwright-testing
 description: "Use when writing Playwright E2E tests — browser automation, visual regression testing, Page Objects, fixtures, and reliable test patterns."
 source: package
+domain: quality
 ---
 
 # playwright-testing