@event4u/agent-config 1.32.0 → 1.34.0

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 -->

package/.agent-src/skills/rtk-output-filtering/SKILL.md

@@ -2,6 +2,7 @@
 name: rtk-output-filtering
 description: "Use when running verbose CLI commands — wraps them with rtk (Rust Token Killer) for 60-90% token savings. Covers installation, configuration, and usage patterns."
 source: package
+domain: process
 execution:
   type: assisted
   handler: shell

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

@@ -2,6 +2,7 @@
 name: rule-writing
 description: "Use when creating or editing a rule in .agent-src.uncompressed/rules/ — trigger wording, always vs auto classification, size budget — even when the user just says 'add a rule for X'."
 source: package
+domain: process
 ---
 
 <!-- cloud_safe: degrade -->

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

@@ -2,6 +2,7 @@
 name: script-writing
 description: "Use when adding or editing any script under `scripts/` — `--quiet` flag, `_lib/script_output` helpers, silent Taskfile wiring, Iron-Law carve-outs — even when you just say 'add a check script for X'."
 source: package
+domain: process
 ---
 
 <!-- cloud_safe: degrade -->

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

@@ -2,6 +2,7 @@
 name: secrets-management
 description: "Use when picking a secrets store, designing rotation, or wiring scanning gates — multi-cloud (Vault, AWS, Azure, GCP), CI, and Kubernetes — decision framework, provider deep-dives externalized."
 source: package
+domain: devops
 status: active
 refresh_trigger: "A cited provider deprecates an auth method, OR External Secrets Operator ships a major version with breaking CRD changes, OR ≥30% of cited scanner tools change their gate semantics."
 sunset_criterion: "When provider docs (Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) all converge on a single rotation + scanning standard AND consumer projects no longer cite this skill in PR reviews for two consecutive review cycles."

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

@@ -2,6 +2,7 @@
 name: security
 description: "Use when applying security best practices — authentication, authorization via Policies, CSRF protection, input sanitization, rate limiting, or secure coding."
 source: package
+domain: quality
 ---
 
 # security

package/.agent-src/skills/security-audit/SKILL.md

@@ -2,6 +2,7 @@
 name: security-audit
 description: "ONLY when user explicitly requests: security audit, vulnerability scan, or penetration test review. NOT for regular feature work."
 source: package
+domain: quality
 ---
 
 # security-audit

package/.agent-src/skills/sentry-integration/SKILL.md

@@ -2,6 +2,7 @@
 name: sentry-integration
 description: "Use when the user shares a Sentry URL, says "check Sentry", or wants to investigate production errors. Uses Sentry MCP tools for deep analysis."
 source: package
+domain: devops
 ---
 
 # Sentry Skill

package/.agent-src/skills/sequential-thinking/SKILL.md

@@ -2,6 +2,7 @@
 name: sequential-thinking
 description: "ONLY when user explicitly requests: step-by-step reasoning, structured problem decomposition, or iterative analysis. NOT for regular coding tasks."
 source: package
+domain: process
 ---
 
 # sequential-thinking

package/.agent-src/skills/skill-improvement-pipeline/SKILL.md

@@ -2,6 +2,7 @@
 name: skill-improvement-pipeline
 description: "ONLY when user explicitly requests: run the skill improvement pipeline after a learning was detected. Orchestrates capture, classify, create, validate, and apply."
 source: package
+domain: process
 execution:
   type: assisted
   handler: internal

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

@@ -2,6 +2,7 @@
 name: skill-management
 description: "Use when compressing, decompressing, refactoring, or improving existing skills. Covers the full skill lifecycle from verbose → sharp → maintained."
 source: project
+domain: process
 execution:
   type: assisted
   handler: internal

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

@@ -2,6 +2,7 @@
 name: skill-reviewer
 description: "Use when reviewing, auditing, or optimizing skills — validates against the 7 Skill Killers checklist and produces fix recommendations."
 source: package
+domain: quality
 execution:
   type: assisted
   handler: internal

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

@@ -2,6 +2,7 @@
 name: skill-writing
 description: "Use when deciding 'should this be a skill or a rule?', creating/improving/reviewing agent skills, SKILL.md frontmatter, or procedure sections — even without saying 'skill-writing'."
 source: project
+domain: process
 ---
 
 # skill-writing

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

@@ -2,6 +2,7 @@
 name: sql-writing
 description: "Use when writing raw SQL — MariaDB/MySQL syntax, parameterization, raw migrations, seeders with `DB::statement` — even when the user just pastes a query and asks 'why is this slow' without naming SQL."
 source: package
+domain: engineering
 ---
 
 # sql