@event4u/agent-config 1.33.0 → 1.35.0

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

package/.agent-src/skills/po-discovery/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: po-discovery
+description: "Use when shaping a fuzzy product ask into a refined backlog item — problem framing, user-story rewrite, AC tightening — even if the user just says 'help me write this ticket'."
+personas:
+  - product-owner
+  - stakeholder
+source: package
+domain: product
+---
+
+# po-discovery
+
+> Take a vague product request and return a **problem-framed**,
+> **user-story-shaped**, **AC-tight** backlog item ready for refinement.
+> Output is copy-paste ready; write-back to the tracker is user-gated.
+> Sibling of [`refine-ticket`](../refine-ticket/SKILL.md) — that one
+> tightens an existing ticket, this one shapes the *raw input* before
+> a ticket exists.
+
+## When to use
+
+- The user pastes a fuzzy idea ("we should let users export their data")
+  and asks to turn it into a ticket.
+- A stakeholder request arrives without a clear problem statement.
+- Acceptance criteria are missing, contradictory, or written as
+  implementation steps instead of observable outcomes.
+- German triggers: "schreib daraus ein Ticket", "ist die Story klar?",
+  "AC fehlen noch".
+
+Do NOT use when:
+
+- A ticket already exists and needs tightening — route to
+  [`refine-ticket`](../refine-ticket/SKILL.md).
+- The ask is already a clear, well-formed user story with measurable
+  AC — skip discovery and proceed to estimation.
+- The request is an engineering task with no product framing
+  ("upgrade Laravel to 11") — discovery adds noise; skip.
+
+## Procedure
+
+### 1. Capture the raw input and identify the asker
+
+Read the user's text verbatim. Do NOT rephrase yet. Identify: who is
+the asker (PO, support, eng, exec)? What artefact did they hand over
+(slack thread, screenshot, voice note transcript, free text)?
+
+### 2. Frame the problem
+
+Answer four questions, every answer cited from the input or marked
+`unknown`:
+
+| Question | Why it matters |
+|---|---|
+| Who has the problem? | Personas, segments, internal vs external |
+| What outcome do they want? | Distinguishes need from solution |
+| What is the current pain or workaround? | Sizes the gap |
+| What changes if we ship this? | Surfaces success signals |
+
+Any answer marked `unknown` blocks story shaping — surface the gap
+back to the user before continuing.
+
+### 3. Shape the user story
+
+Use the canonical form: *As a `{persona}`, I want `{capability}`, so
+that `{outcome}`*. Capability ≠ implementation. If the input says
+"add a CSV button", reframe to "I want my data in a portable format,
+so that I can use it outside the product".
+
+### 4. Tighten acceptance criteria
+
+Each AC is **observable**, **binary** (passes or fails), and **does
+not name an implementation**. Use Given / When / Then or a numbered
+list. Reject ACs that hide assumptions ("works correctly", "is fast
+enough") — replace with measurable thresholds or strike them.
+
+### 5. Surface non-functional gaps
+
+Flag anything missing that downstream skills will need: success
+metric, target users, rollout window, accessibility, security or
+privacy boundary, multi-tenant scope. Do NOT invent values — list
+them as `gap` items for the user to fill.
+
+## Output format
+
+```
+Asker:    <role / name>
+Source:   <slack / email / verbal / pasted text>
+Problem:  <one sentence — who, want, why>
+
+User story:
+  As a <persona>, I want <capability>, so that <outcome>.
+
+Acceptance criteria:
+  1. Given <state>, when <action>, then <observable result>.
+  2. ...
+
+Open gaps (block estimation):
+  - <gap 1>
+  - <gap 2>
+
+Suggested next step: /refine-ticket  |  /estimate-ticket  |  fill gaps
+```
+
+If gaps remain, surface them and stop — do NOT push to estimation.
+
+## Gotcha
+
+- If the asker is the agent itself (autopilot, roadmap), still run the
+  full procedure — the gap list is what catches the agent inventing
+  requirements.
+- "Outcome" is what the user *gets*, not what we *build*. "Faster
+  page" is an outcome; "switch to Postgres" is an implementation.
+- AC count is not a quality signal. Three sharp AC beat eight vague
+  ones; merge or split as needed.
+
+## Do NOT
+
+- Do NOT write code, plan tasks, or estimate effort — those are
+  downstream skills.
+- Do NOT silently fill gaps with plausible-looking defaults; the
+  whole point of discovery is to surface what the user has not
+  decided.
+- Do NOT rewrite the asker's wording into agent voice in the
+  Problem field — preserve their framing so they recognise it.
+- Do NOT push the rewritten ticket into Jira / Linear without the
+  user explicitly asking — output is copy-paste ready, write-back
+  is gated.

package/.agent-src/skills/project-analysis-core/SKILL.md

@@ -2,6 +2,7 @@
 name: project-analysis-core
 description: "Use for the universal deep-analysis workflow: project discovery, version resolution, docs loading, architecture mapping, execution flow, and package research."
 source: package
+domain: discovery
 ---
 
 # project-analysis-core

package/.agent-src/skills/project-analysis-hypothesis-driven/SKILL.md

@@ -2,6 +2,7 @@
 name: project-analysis-hypothesis-driven
 description: "Use when a bug has multiple plausible causes across layers — competing hypotheses, validation loops, evidence-based conclusions — even when the user just says 'why is this happening?'."
 source: package
+domain: discovery
 ---
 
 # project-analysis-hypothesis-driven

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

@@ -2,6 +2,7 @@
 name: project-analysis-laravel
 description: "Use for deep Laravel project analysis: boot flow, request lifecycle, container usage, Eloquent/data flow, async systems, and Laravel-specific failure patterns."
 source: package
+domain: discovery
 ---
 
 # project-analysis-laravel

package/.agent-src/skills/project-analysis-nextjs/SKILL.md

@@ -2,6 +2,7 @@
 name: project-analysis-nextjs
 description: "Use for deep Next.js analysis: server vs client boundaries, routing, data fetching, caching, rendering modes, and hydration/runtime issues."
 source: package
+domain: discovery
 ---
 
 # project-analysis-nextjs

package/.agent-src/skills/project-analysis-node-express/SKILL.md

@@ -2,6 +2,7 @@
 name: project-analysis-node-express
 description: "Use for deep Node.js / Express project analysis: boot flow, middleware order, async behavior, data layer, auth/security, and Node-specific runtime failure patterns."
 source: package
+domain: discovery
 ---
 
 # project-analysis-node-express

package/.agent-src/skills/project-analysis-react/SKILL.md

@@ -2,6 +2,7 @@
 name: project-analysis-react
 description: "Use for deep React analysis: component tree, state flow, props flow, hooks usage, rendering behavior, and React-specific failure patterns."
 source: package
+domain: discovery
 ---
 
 # project-analysis-react

package/.agent-src/skills/project-analysis-symfony/SKILL.md

@@ -2,6 +2,7 @@
 name: project-analysis-symfony
 description: "Use for deep Symfony project analysis: kernel/bootstrap, container wiring, routing/request flow, Doctrine, security, Messenger, and Symfony-specific failure patterns."
 source: package
+domain: discovery
 ---
 
 # project-analysis-symfony

package/.agent-src/skills/project-analysis-zend-laminas/SKILL.md

@@ -2,6 +2,7 @@
 name: project-analysis-zend-laminas
 description: "Use for deep Zend Framework or Laminas project analysis: bootstrap, config merge order, service manager, MVC flow, data layer, and migration-specific risks."
 source: package
+domain: discovery
 ---
 
 # project-analysis-zend-laminas

package/.agent-src/skills/project-analyzer/SKILL.md

@@ -2,6 +2,7 @@
 name: project-analyzer
 description: "ONLY when user explicitly requests: full project analysis, tech stack detection, or structured analysis documents for agents/analysis/. NOT for regular feature work."
 source: package
+domain: discovery
 ---
 
 # project-analyzer

package/.agent-src/skills/project-docs/SKILL.md

@@ -2,6 +2,7 @@
 name: project-docs
 description: "Use when looking for project-specific documentation. Knows which docs exist in agents/docs/ and agents/contexts/ and maps work areas to relevant docs."
 source: package
+domain: process
 ---
 
 # project-docs

package/.agent-src/skills/prompt-engineering-patterns/SKILL.md

@@ -2,6 +2,7 @@
 name: prompt-engineering-patterns
 description: "Use when designing production-LLM prompts — few-shot, chain-of-thought, system prompts, templates, self-verification — distinct from prompt-optimizer and refine-prompt."
 source: package
+domain: product
 status: active
 ---
 

package/.agent-src/skills/prompt-optimizer/SKILL.md

@@ -2,6 +2,7 @@
 name: prompt-optimizer
 description: "Use when the user wants a prompt optimized for ChatGPT, Claude, Gemini, or another AI — 'make this prompt better', 'optimize for ChatGPT', 'rewrite my prompt' — even without saying 'optimize'."
 source: package
+domain: product
 ---
 
 # prompt-optimizer

package/.agent-src/skills/quality-tools/SKILL.md

@@ -2,6 +2,7 @@
 name: quality-tools
 description: "Use when PHPStan, Rector, or ECS output appears — \"phpstan says mixed\", type errors, \"fix code style\", \"run rector\" — even when Eloquent/Laravel/model code is also mentioned."
 source: package
+domain: quality
 execution:
   type: assisted
   handler: shell

package/.agent-src/skills/react-native-setup/SKILL.md

@@ -2,6 +2,7 @@
 name: react-native-setup
 description: "Use when setting up React Native or Expo dev environments — Xcode, Android Studio, CocoaPods, EAS, Metro, New Architecture — even when the user just says 'my RN build won't start'."
 source: package
+domain: devops
 ---
 
 # react-native-setup

package/.agent-src/skills/react-shadcn-ui/SKILL.md

@@ -2,6 +2,7 @@
 name: react-shadcn-ui
 description: "Use when building React UI on shadcn/ui primitives + Tailwind — the apply/review/polish skill dispatched by `directives/ui/*` for the `react-shadcn` stack."
 source: package
+domain: engineering
 ---
 
 # react-shadcn-ui

package/.agent-src/skills/readme-reviewer/SKILL.md

@@ -2,6 +2,7 @@
 name: readme-reviewer
 description: "Use when reviewing a README for accuracy, usability, and alignment with the actual repository. Detects invented content, broken setup steps, and structural issues."
 source: package
+domain: quality
 execution:
   type: assisted
   handler: internal

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

@@ -2,6 +2,7 @@
 name: readme-writing
 description: "Use when creating, rewriting, or significantly improving a README based on the actual repository structure, commands, and intended audience."
 source: package
+domain: process
 execution:
   type: assisted
   handler: internal

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

@@ -2,6 +2,7 @@
 name: readme-writing-package
 description: "Use when creating or rewriting a README for a reusable package or library. Focus on installability, minimal usage example, compatibility, and developer onboarding."
 source: package
+domain: process
 execution:
   type: assisted
   handler: internal

package/.agent-src/skills/receiving-code-review/SKILL.md

@@ -4,6 +4,7 @@ description: "Use when processing code review feedback (bot or human) before cha
 personas:
   - critical-challenger
 source: package
+domain: process
 ---
 
 # receiving-code-review

package/.agent-src/skills/refine-prompt/SKILL.md

@@ -6,6 +6,7 @@ personas:
   - senior-engineer
   - ai-agent
 source: package
+domain: product
 execution:
   type: assisted
   handler: internal

package/.agent-src/skills/refine-ticket/SKILL.md

@@ -9,6 +9,7 @@ personas:
   - critical-challenger
   - ai-agent
 source: package
+domain: product
 execution:
   type: assisted
   handler: internal

package/.agent-src/skills/release-comms/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: release-comms
+description: "Use when turning a shipped changelog into a release narrative — value-not-feature framing, audience-segmented surfaces, one source of truth. Triggers on 'announce the release', 'write changelog post'."
+status: active
+tier: senior
+source: package
+domain: product
+context_spine: [product, team]
+---
+
+# release-comms
+
+## When to use
+
+- Release shipping with user-facing change, team about to send feature-list email.
+- Changelog draft reads like commit log — engineering-honest, unparseable for user.
+- Multiple comms surfaces (in-app, email, social, docs) about to be written by different people from same release.
+
+Do NOT use for incident comms (see `incident-commander`),
+deprecation announcements needing legal sign-off, or pre-release
+discovery — this skill assumes change is **shipped**.
+
+## Cognition cluster
+
+- **Mental model 16 — Leading vs. lagging indicators.** Release note
+  is lagging artifact; leading version = in-app prompt that fired
+  before user found change-log. See
+  [`docs/contracts/mental-models.md`](../../../docs/contracts/mental-models.md) § 16.
+- **Value-not-feature heuristic.** Every paragraph passes *"so the
+  user can ___"* completion. Failing rows go back for re-write.
+
+## Procedure
+
+### Step 0: Ground the release
+
+1. Read merged PR list / changelog block / release branch diff. Release = **what**; comms = **so what**. Conflate the two → ship marketing.
+2. Read **product** and **team** slots of [context-spine](../../../docs/contracts/context-spine.md) (if consumer filled them) for bounded scope and cadence — surface choice depends on cadence (weekly: in-app + log; quarterly: email + post; major: all four).
+3. Identify **single dominant change** the release ships. Three "headliners" reads as three half-announcements.
+
+### Step 1: Audience-segment
+
+1. Three audiences max: **active user**, **at-risk / lapsed user**, **prospect**. More fragments message; fewer hides routing.
+2. Per audience, write one sentence: *"After this release, you can …"* completing with user-side verb, not product-side feature.
+3. If two audiences end up with same sentence, collapse — segmentation that does not change message = theatre.
+
+### Step 2: Map surfaces to audiences
+
+1. **Changelog** (always) — engineers + power users; truthful, dense, link-heavy. Source of truth — every other surface points back here.
+2. **In-app prompt** — active users; ≤ 1 sentence + 1 CTA; fires for users whose past behaviour predicts they'll touch the new path.
+3. **Email** — at-risk / lapsed; one headline value, one CTA, one paragraph of context. No feature lists.
+4. **Social / blog** — prospect; the **why**, not the **what** — frame against user job (cite [`customer-research`](../customer-research/SKILL.md) if switch-event surfaced).
+
+Cut surfaces aggressively. Weekly release does not need blog post.
+
+### Step 3: Draft each surface from the changelog
+
+1. Open changelog. Per surface, copy dominant change line, then **rewrite verb subject** from "we" to "you".
+2. Strip qualifiers ("now", "even better", "lightning-fast"). Noise, not signal.
+3. Run *"so the user can ___"* completion on every paragraph. Failing paragraphs cut, not edited.
+
+### Step 4: Truth-check
+
+1. Every claim links back to changelog row or doc URL. Unsourced claim → cut.
+2. No tense games — past for shipped, future for coming-soon (and only if date is committed). "Roadmap" lives outside this skill.
+3. Names match product surface. In-app says "Reports" and email says "Insights" → user fires lookup tax.
+
+### Step 5: Hand off
+
+1. Produce four artifacts (see `## Output`).
+2. Hand to whoever owns send. Do not embed scheduling or A/B test plans here — that is RevOps.
+
+## Related Skills
+
+**WHEN to use this**
+
+- Change is **shipped** and needs to reach existing users.
+- Multiple comms surfaces written by different people from same source.
+- Team about to default to feature-list email.
+
+**WHEN NOT to use this**
+
+- Production incident comms → [`incident-commander`](../incident-commander/SKILL.md).
+- Pre-release discovery / validation → [`customer-research`](../customer-research/SKILL.md).
+- Funnel-stage diagnostics post-release → [`funnel-analysis`](../funnel-analysis/SKILL.md).
+- Ranking which release to comms next → [`rice-prioritization`](../rice-prioritization/SKILL.md).
+
+## When the agent should load this
+
+- "Write the release notes for sprint 47."
+- "We're shipping the new export — how do we announce it?"
+- "Draft the changelog email for last week's batch."
+- "What's the in-app prompt copy for the redesign?"
+- "Turn the merged PR list into something users can read."
+
+## Output
+
+1. **`release-narrative.md`** — single source of truth: dominant change, audiences (1–3), per-audience *"After this release, you can …"* sentence, links to source changelog rows.
+2. **`changelog-entry.md`** — engineer-honest, dense, link-heavy block ready to paste into project's changelog.
+3. **`comms-pack.md`** — per-surface drafts (in-app prompt, email, optional social/blog), each ≤ surface's hard cap, each pointing back to `changelog-entry.md`.
+4. **`comms-checklist.md`** — pre-send checks: every claim sourced, names consistent across surfaces, audience match, "so the user can …" completion passing on every paragraph. Hand-off artifact for senior PO ([`product-owner`](../../personas/product-owner.md)).
+
+## Gotcha
+
+- Default failure mode = feature-list email — written to make engineering feel seen, not to help user.
+- Marketing puffery ("revolutionary", "delightful") fails source check; cut on sight.
+- Two surfaces using different names for same thing = highest-frequency support-ticket trigger after release.
+- Hidden coming-soon claims in past-tense paragraphs erode trust faster than missing the comms entirely.
+
+## Do NOT
+
+- Do NOT promote coming-soon item alongside shipped items — user cannot tell which is which and stops trusting next note.
+- Do NOT let long-tail change steal the headline — dominant change earns headline, long tail goes in changelog.
+- Do NOT ship surfaces without truth-check pass; unsourced claim survives in social longer than release does.
+
+## Runnable example
+
+Sprint 47 ships a one-click monthly export and three small bug fixes:
+
+- Dominant change: one-click export. Bug fixes go in changelog only.
+- Audiences: active user (will use it), at-risk (export friction was churn trigger per [`customer-research`](../customer-research/SKILL.md) evidence-log).
+- "After this release, you can pull a board-ready monthly report in one click." (active, at-risk — same sentence ⇒ collapse to one).
+- Surfaces: changelog (full), in-app prompt to active users on next month-end, email to at-risk cohort with same sentence and one CTA. No social.
+- Truth-check: claim links to export PR; "one click" is literal — verified against shipped UI.

package/.agent-src/skills/repomix-packer/SKILL.md

@@ -2,6 +2,7 @@
 name: repomix-packer
 description: "Use when packaging a codebase to a single AI-friendly file for LLM analysis — local or remote, XML/Markdown/JSON, token counting, gitignore filtering, peer-side `repomix` CLI."
 source: package
+domain: process
 ---
 
 > **Pinned upstream:** `repomix` CLI (npm: `repomix`, brew: `repomix`). Re-verify per minor bump. Repomix is an **optional dependency** — this skill never installs it silently.

package/.agent-src/skills/requesting-code-review/SKILL.md

@@ -4,6 +4,7 @@ description: "Use when asking for a review or creating a PR — self-review firs
 personas:
   - critical-challenger
 source: package
+domain: process
 ---
 
 # requesting-code-review

package/.agent-src/skills/review-routing/SKILL.md

@@ -2,6 +2,7 @@
 name: review-routing
 description: "Use when preparing a PR description, suggesting reviewers, or flagging risk — produces owner-mapped roles plus historical bug-pattern matches from project-local YAML."
 source: package
+domain: quality
 ---
 
 # review-routing

package/.agent-src/skills/rice-prioritization/SKILL.md

@@ -4,6 +4,7 @@ description: "Use when ranking competing initiatives for a roadmap, breaking a t
 status: active
 tier: senior
 source: package
+domain: product
 ---
 
 # rice-prioritization