@event4u/agent-config 1.33.0 → 1.35.0

package/.agent-src/skills/launch-readiness/SKILL.md

@@ -0,0 +1,156 @@
+---
+name: launch-readiness
+description: "Use before merging a release-shaped PR — pre-merge checklist, rollout plan, rollback criteria, ops handoff. Triggers on 'ready to ship', 'launch checklist', 'rollout plan for X'."
+status: active
+tier: senior
+source: package
+domain: process
+context_spine: [team, product]
+---
+
+# launch-readiness
+
+## When to use
+
+- A change is about to merge that crosses a release boundary (new feature on `main`, version bump, public-facing comms attached).
+- An ops handoff is implied — the on-call rotation, support team, or downstream consumers need to know.
+- A rollback criterion has not been written down yet.
+
+Do NOT use for routine internal merges
+([`finishing-a-development-branch`](../finishing-a-development-branch/SKILL.md))
+or for the comms text itself ([`release-comms`](../release-comms/SKILL.md)).
+This skill produces the **decision** to ship and the rollback contract.
+
+## Cognition cluster
+
+- **Mental model 10 — Reversible vs irreversible.** Map every step
+  of the rollout to a reversibility class; the rollback criteria
+  must name the irreversible steps and the abort threshold for each.
+  See [`docs/contracts/mental-models.md`](../../../docs/contracts/mental-models.md) § 10.
+- **Mental model 29 — Pre-mortems.** Imagine the rollout failed in
+  six hours; what failed first? The pre-mortem becomes the rollback
+  criteria, not a separate document. See `mental-models.md` § 29.
+- **Mental model 4 — Second-order thinking.** Enumerate what
+  becomes harder *after* the launch (rollback cost, contributor
+  ergonomics, doc churn). See `mental-models.md` § 4.
+- **Team + product context-spine slots.** Read **team** for the
+  on-call rotation and ops handoff path; read **product** for the
+  segment / cohort exposure of the rollout. See
+  [`context-spine`](../../../docs/contracts/context-spine.md).
+
+## Procedure
+
+### 1. Identify the launch shape
+
+One sentence: *"This change ships **X** to **segment Y** behind
+**rollout mechanism Z**."* If you cannot, the change is not
+release-shaped; route to `finishing-a-development-branch`.
+
+### 2. Inspect the pre-merge checklist
+
+Walk the diff with the following gates:
+
+- Tests green on the integration suite (cite the run).
+- Quality gates green (PHPStan / linters / type-checks).
+- Migrations are reversible OR the irreversibility is explicit.
+- Feature flag / kill switch named, default off unless intended.
+- Doc / changelog / release notes present (hand off to
+  [`release-comms`](../release-comms/SKILL.md) for the prose).
+- Rollback path tested at least mentally; named in step 4.
+
+Cells without evidence block the launch — surface, do not
+hand-wave.
+
+### 3. Plan the rollout
+
+- **Mechanism** — flag, canary cohort, blue-green, immediate.
+- **Order** — internal → trusted segment → general; cite the
+  segment per stage from the **product** spine slot.
+- **Telemetry** — the metric that **proves** rollout health.
+- **Owner** — named role per stage (not name); from the **team**
+  spine slot.
+
+### 4. Write rollback criteria
+
+For each stage:
+
+- **Trip wire** — the metric value that fires rollback.
+- **Decision window** — how long the trip wire must hold.
+- **Abort path** — what the on-call does (revert PR, flip flag,
+  drain queue), pre-rehearsed.
+- **Irreversible steps** — explicit list; if any irreversible step
+  is in scope, the launch needs a written sign-off, not implicit.
+
+Pre-mortem rule: every trip wire must answer *"what would have
+caused this in six hours?"* If you cannot, the trip wire is wrong.
+
+### 5. Ops handoff
+
+- Who is paged on which alert (from **team** spine slot).
+- Where the rollback runbook lives (link).
+- Date / time of the handoff conversation; sign-off from the
+  receiving role.
+
+### 6. Hand back
+
+Hand the artefact below to whoever requested the launch decision;
+route comms to [`release-comms`](../release-comms/SKILL.md) and
+post-launch metrics tracking to the team's monitoring stack.
+
+## Related Skills
+
+**WHEN to use this**
+
+- A release-shaped PR is about to merge.
+- Rollback criteria need to land in writing before the merge button
+  is pressed.
+- Ops handoff is implied and not yet executed.
+
+**WHEN NOT to use this**
+
+- The change is internal and routine — route to
+  [`finishing-a-development-branch`](../finishing-a-development-branch/SKILL.md).
+- The output is the public comms — route to
+  [`release-comms`](../release-comms/SKILL.md).
+- The rollout decision involves stakeholder conflict — route to
+  [`stakeholder-tradeoff`](../stakeholder-tradeoff/SKILL.md) first.
+- The decision is reversible-and-cheap — write a one-line note,
+  skip the full artefact.
+
+## When the agent should load this
+
+- "Sind wir launch-ready?"
+- "Bau mir die Rollback-Kriterien für Phase X."
+- "Ops-Handoff für die Release morgen."
+- "Was bricht, wenn wir den Flag flippen?"
+- "Pre-merge-Checklist für PR #N."
+
+## Output
+
+1. **Launch shape** — one-sentence statement of the change.
+2. **Pre-merge checklist** — gate · status · evidence (citation).
+3. **Rollout plan** — stages × mechanism · order · telemetry · owner.
+4. **Rollback contract** — per stage: trip wire · decision window ·
+   abort path · irreversible steps.
+5. **Ops handoff** — pager mapping · runbook link · sign-off.
+6. **Outstanding** — anything blocking the launch; explicit, not
+   collapsed.
+
+## Gotcha
+
+- A checklist with all green and no citations is theatre; every
+  green needs an artefact.
+- A trip wire without a decision window is unactionable — *"if
+  errors spike"* is not a trigger; *"5xx > 2% for 10 min"* is.
+- Irreversible steps without written sign-off are the most common
+  post-mortem ancestor — surface, do not skip.
+
+## Do NOT
+
+- Do NOT write the comms text here — that is `release-comms`.
+- Do NOT lock the rollback contract verbally — it lives in the
+  output block, citable.
+- Do NOT let any stage own itself — every stage names a role from
+  the **team** spine slot.
+- Do NOT hand the artefact to a receiver who has not signed off on
+  ops handoff.

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