@event4u/agent-config 1.33.0 → 1.34.0

package/.agent-src/skills/jobs-events/SKILL.md

@@ -2,6 +2,7 @@
 name: jobs-events
 description: "Use when creating Laravel jobs, queued workflows, events, or listeners. Covers clear responsibilities, safe serialization, and retry/failure handling."
 source: package
+domain: engineering
 ---
 
 # jobs-events

package/.agent-src/skills/judge-bug-hunter/SKILL.md

@@ -2,6 +2,7 @@
 name: judge-bug-hunter
 description: "Use when a diff needs correctness review — null-safety, edge cases, off-by-one, races, error handling — dispatched by /review-changes, /do-and-judge, /judge, even without 'judge'."
 source: package
+domain: quality
 ---
 
 # judge-bug-hunter

package/.agent-src/skills/judge-code-quality/SKILL.md

@@ -2,6 +2,7 @@
 name: judge-code-quality
 description: "Use when a diff needs a readability review — naming, single-responsibility, DRY, dead code, mismatch with codebase conventions — dispatched by /review-changes, /do-and-judge, /judge."
 source: package
+domain: quality
 ---
 
 # judge-code-quality

package/.agent-src/skills/judge-security-auditor/SKILL.md

@@ -1,7 +1,10 @@
 ---
 name: judge-security-auditor
 description: "Use when a diff may introduce security risk — authZ, injection, secrets, unsafe deserialization, SSRF, XSS, mass assignment — dispatched by /review-changes, /do-and-judge, /judge."
+personas:
+  - security-engineer
 source: package
+domain: quality
 ---
 
 # judge-security-auditor

package/.agent-src/skills/judge-test-coverage/SKILL.md

@@ -4,6 +4,7 @@ description: "Use when a diff may lack tests — missing assertions, uncovered b
 personas:
   - qa
 source: package
+domain: quality
 ---
 
 # judge-test-coverage

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

@@ -2,6 +2,7 @@
 name: laravel
 description: "Writes Laravel code following framework conventions, project architecture, and modern best practices for controllers, requests, services, jobs, events, policies, and application structure."
 source: package
+domain: engineering
 ---
 
 # laravel

package/.agent-src/skills/laravel-horizon/SKILL.md

@@ -2,6 +2,7 @@
 name: laravel-horizon
 description: "Use when working with Laravel queues in production — Horizon dashboard, worker supervision, job metrics, balancing strategies — even when the user just says 'my jobs are piling up'."
 source: package
+domain: engineering
 ---
 
 # laravel-horizon

package/.agent-src/skills/laravel-mail/SKILL.md

@@ -2,6 +2,7 @@
 name: laravel-mail
 description: "Use when building Laravel emails — Mailables, Markdown templates, queued sending, attachments, previews — even when the user says 'send this as an email' without naming Mailables."
 source: package
+domain: engineering
 ---
 
 # laravel-mail

package/.agent-src/skills/laravel-middleware/SKILL.md

@@ -2,6 +2,7 @@
 name: laravel-middleware
 description: "Use when creating or modifying Laravel middleware — request/response filtering, groups, priority, terminable middleware, or route-level assignment."
 source: package
+domain: engineering
 ---
 
 # laravel-middleware

package/.agent-src/skills/laravel-notifications/SKILL.md

@@ -2,6 +2,7 @@
 name: laravel-notifications
 description: "Use when sending notifications via mail, Slack, database, or custom channels — with queuing, on-demand recipients, and notification preferences."
 source: package
+domain: engineering
 ---
 
 # laravel-notifications

package/.agent-src/skills/laravel-pennant/SKILL.md

@@ -2,6 +2,7 @@
 name: laravel-pennant
 description: "Use when working with feature flags — Laravel Pennant, gradual rollouts, A/B testing, scope-based flags — even when the user just says 'hide this behind a flag' without naming Pennant."
 source: package
+domain: engineering
 ---
 
 # laravel-pennant

package/.agent-src/skills/laravel-pulse/SKILL.md

@@ -2,6 +2,7 @@
 name: laravel-pulse
 description: "Use when setting up Laravel Pulse — real-time dashboard, built-in cards, custom recorders, performance insights — even when the user just says 'I need app monitoring' without naming Pulse."
 source: package
+domain: engineering
 ---
 
 # laravel-pulse

package/.agent-src/skills/laravel-reverb/SKILL.md

@@ -2,6 +2,7 @@
 name: laravel-reverb
 description: "Use when configuring Laravel Reverb — the first-party WebSocket server with Pusher protocol compatibility, horizontal scaling, and Pulse monitoring."
 source: package
+domain: engineering
 ---
 
 # laravel-reverb

package/.agent-src/skills/laravel-scheduling/SKILL.md

@@ -2,6 +2,7 @@
 name: laravel-scheduling
 description: "Use when configuring Laravel task scheduling — cron expressions, frequency helpers, overlap prevention, maintenance mode, or output handling."
 source: package
+domain: engineering
 ---
 
 # laravel-scheduling

package/.agent-src/skills/laravel-validation/SKILL.md

@@ -2,6 +2,7 @@
 name: laravel-validation
 description: "Use when writing validation — Form Requests, rules, custom rule objects, request-boundary design — even when the user just says 'validate this input' or 'check the request' without naming it."
 source: package
+domain: engineering
 ---
 
 # laravel-validation

package/.agent-src/skills/learning-to-rule-or-skill/SKILL.md

@@ -2,6 +2,7 @@
 name: learning-to-rule-or-skill
 description: "Use when a repeated learning, mistake, or successful pattern should be turned into a new rule or skill. Also use after completing a task to capture learnings from the work."
 source: project
+domain: process
 execution:
   type: assisted
   handler: internal

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

@@ -2,6 +2,7 @@
 name: lint-skills
 description: "Use when running the package's skill linter against all skills and rules to validate frontmatter, required sections, and execution metadata."
 source: package
+domain: process
 execution:
   type: assisted
   handler: shell

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

@@ -2,6 +2,7 @@
 name: livewire
 description: "Use when the project's frontend stack is Livewire — dispatched by `directives/ui/{apply,review,polish}.py`. Covers reactive state, events, lifecycle hooks, and component/view separation."
 source: package
+domain: engineering
 ---
 
 # livewire

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