@event4u/agent-config 1.33.0 → 1.34.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/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

package/.agent-src/skills/risk-officer/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: risk-officer
+description: "Use when surfacing and prioritising risk before commit — blast-radius framing, mitigations, residual-risk verdict — even if the user just says 'what could go wrong here?'."
+personas:
+  - critical-challenger
+  - senior-engineer
+source: package
+domain: quality
+---
+
+# risk-officer
+
+> Surface risks the implementer or PO is likely to underweight, score
+> them by **likelihood × impact**, and propose mitigations the team
+> can actually execute. Sibling of
+> [`threat-modeling`](../threat-modeling/SKILL.md) (security-only)
+> and [`blast-radius-analyzer`](../blast-radius-analyzer/SKILL.md)
+> (call-site only) — this skill takes the wider product, ops, and
+> coordination view.
+
+## When to use
+
+- Pre-implementation: a roadmap, ADR, or refined ticket needs a risk
+  pass before the team commits.
+- Pre-merge: a non-trivial diff is about to land and the team wants
+  one more risk lens beyond the four standard judges.
+- Post-incident: surface the risks the team should track to prevent
+  recurrence (without writing the post-mortem itself).
+- German triggers: "was kann schiefgehen?", "Risiko-Check", "wo
+  brennt es?".
+
+Do NOT use when:
+
+- The concern is exclusively security or authZ — route to
+  [`threat-modeling`](../threat-modeling/SKILL.md) or
+  [`judge-security-auditor`](../judge-security-auditor/SKILL.md).
+- The concern is exclusively call-site impact of a refactor — route
+  to [`blast-radius-analyzer`](../blast-radius-analyzer/SKILL.md).
+- The user wants a fix, not a risk view — risk-officer never patches.
+
+## Procedure
+
+### 1. Inspect the change
+
+Read the input (roadmap step, ticket, diff, post-mortem) and identify
+the scope in one sentence: *"This change does X for users Y, touching
+systems Z."* If you cannot, the artefact is not reviewable — stop and
+ask.
+
+### 2. Enumerate risks across five lenses
+
+| Lens | Sample questions |
+|---|---|
+| Product | Wrong outcome shipped, churn, support load, brand impact |
+| Operations | Rollback path, observability, on-call burden, alert noise |
+| Coordination | Cross-team dependencies, communication gaps, sequencing |
+| Data | Loss, corruption, leakage, retention, compliance, residency |
+| Time | Schedule slip, opportunity cost, sunk-cost lock-in |
+
+Per lens, list each risk as a single bullet. Reject vague risks —
+"could break things" is not a risk; "queue worker silently drops
+messages on retry exhaustion" is.
+
+### 3. Score each risk
+
+For every risk, assign **L** (likelihood: low / med / high) and **I**
+(impact: low / med / high). Top-5 sort by `LxI` rank; cite the
+trigger condition for each L and I. Do NOT pad to a fixed count —
+three sharp risks beat ten generic ones.
+
+### 4. Propose mitigations
+
+For the top-5 risks, propose **one** mitigation that the team can
+own. Each mitigation has an owner role (eng, ops, PO, support), a
+rough size (S / M / L), and a residual-risk note (what stays after
+mitigation). Mitigations the team cannot execute are not mitigations
+— flag them as `accept` or escalate.
+
+### 5. Issue a verdict
+
+| Verdict  | When to issue |
+|---|---|
+| `proceed`             | Top-5 risks have owned mitigations; residual is acceptable |
+| `proceed-with-mitigations` | Mitigations must land BEFORE or WITH the change |
+| `pause`               | One or more `high × high` risks have no executable mitigation |
+
+`pause` is not a veto — it forces the user to decide explicitly.
+
+### 6. Validate the verdict
+
+Before emitting, verify each top-5 risk has: a concrete trigger, a
+scored L×I, an owned mitigation (or explicit `accept`), and a
+residual note. Ensure the verdict matches the worst residual — a
+`high × high` residual without executable mitigation must produce
+`pause`, not `proceed`.
+
+## Output format
+
+The report is a single block with these ordered fields:
+
+1. `Target:` — one-sentence scope from step 1
+2. `Top-5 risks:` — numbered list, each with `L=`, `I=`, trigger,
+   mitigation, owner, size, residual
+3. `Other risks tracked:` — count of risks below the top-5 cut
+4. `Verdict:` — exactly one of `proceed` / `proceed-with-mitigations`
+   / `pause`
+
+```
+Risk-Officer
+Target: <one-sentence scope>
+
+Top-5 risks:
+1. 🔴 <risk> (L=high, I=high)  Trigger: <condition>
+   Mitigation: <action>  Owner: <role>  Size: <S/M/L>
+   Residual: <what remains>
+2. 🟡 <risk> (L=med, I=high)   ...
+
+Other risks tracked: <count>, summarised below or omitted if low/low.
+
+Verdict: proceed | proceed-with-mitigations | pause
+```
+
+## Gotcha
+
+- A risk without a trigger is a vibe, not a risk. Reject vibes.
+- Likelihood is conditional on the change — not the universal base
+  rate of the system. "Postgres goes down" is not a risk of *this
+  change* unless the change increases that likelihood.
+- Mitigations the team will not execute are theatre. Be honest in
+  the residual-risk note.
+
+## Do NOT
+
+- Do NOT enumerate every conceivable risk — top-5 with rationale is
+  the contract.
+- Do NOT score `high × high` reflexively to be cautious; mis-scoring
+  destroys the rank.
+- Do NOT propose mitigations the agent itself will own — the owner
+  is always a human role.
+- Do NOT issue `pause` as a soft veto on something the user already
+  decided; issue `proceed-with-mitigations` and surface the residual.

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

@@ -2,6 +2,7 @@
 name: roadmap-management
 description: "Use when the user says "create roadmap", "show roadmap", or "execute roadmap". Creates, reads, and manages roadmap files with phase tracking."
 source: package
+domain: process
 ---
 
 # roadmap-manager

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

@@ -2,6 +2,7 @@
 name: roadmap-writing
 description: "Use when authoring or rewriting a roadmap in agents/roadmaps/ — phase prose, goal sentence, acceptance criteria, council notes — even when the user just says 'write a plan for X' or 'draft a roadmap'."
 source: package
+domain: process
 ---
 
 <!-- cloud_safe: degrade -->