@event4u/agent-config 1.33.0 → 1.35.0

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 -->
@@ -161,6 +162,6 @@ to every roadmap you author.
 
 ## Examples
 
-Browse `agents/roadmaps/` (active plate) and `agents/roadmaps/archive/`
+Browse `agents/roadmaps/` (active set) and `agents/roadmaps/archive/`
 (closed work) for canonical structural / tactical / structural-with-council
 examples.

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

package/.agent-src/skills/stakeholder-tradeoff/SKILL.md

@@ -0,0 +1,237 @@
+---
+name: stakeholder-tradeoff
+description: "Use when stakeholders pull a decision in different directions — frames each lens, builds a trade-off matrix, surfaces the cost of every choice — even if the user just says 'PO and ops disagree'."
+status: active
+tier: senior
+source: package
+domain: product
+context_spine: [team, product]
+personas:
+  - product-owner
+  - stakeholder
+  - critical-challenger
+---
+
+# stakeholder-tradeoff
+
+> Make explicit who pays and who benefits when a decision pulls
+> stakeholders in different directions. Builds a **stakeholder ×
+> criterion matrix** so the trade-off is visible, not hidden in
+> politics. Sibling of [`decision-record`](../decision-record/SKILL.md)
+> — that one locks the choice; this one surfaces the *human cost*
+> of each option before the lock.
+
+## When to use
+
+- PO, ops, support, and engineering disagree on an approach and the
+  user wants the disagreement made legible.
+- A decision benefits one segment at the cost of another (free vs
+  paid users, internal vs external, region A vs region B).
+- A roadmap step has *un*declared trade-offs and the user wants
+  them surfaced before commit.
+- German triggers: "Wer zahlt was?", "Stakeholder-Konflikt",
+  "Trade-off zwischen X und Y".
+
+Do NOT use when:
+
+- One stakeholder owns the decision unambiguously — surface their
+  decision and stop.
+- The trade-off is technical-only (perf vs storage) — route to
+  [`decision-record`](../decision-record/SKILL.md).
+- The trade-off is risk-only — route to
+  [`risk-officer`](../risk-officer/SKILL.md).
+
+## Cognition cluster
+
+- **Mental model 5 — Opportunity cost.** Every `+` on the matrix is
+  also an opportunity cost on the stakeholders not getting that
+  benefit; the matrix only earns its keep when it surfaces who pays
+  for the chosen `+`. See
+  [`docs/contracts/mental-models.md`](../../../docs/contracts/mental-models.md) § 5.
+- **Mental model 27 — Outcome over output.** Picking the option with
+  the most checkmarks is output theatre; pick the option whose `–`
+  cells land on stakeholders who can execute mitigations. See
+  `mental-models.md` § 27.
+- **Mental model 29 — Pre-mortems.** For the recommended option,
+  state the failure mode each `–`-bearing stakeholder will name in
+  six months. If you cannot, the lens is incomplete — re-interview.
+  See `mental-models.md` § 29.
+- **Team + product context-spine slots.** Read **team** for the
+  silent-stakeholders inventory (on-call, support, finance) and
+  **product** for end-user / segment lenses (free vs paid, region,
+  cohort). See [`context-spine`](../../../docs/contracts/context-spine.md).
+
+## Procedure
+
+### 1. Identify the stakeholders
+
+Each by **role**, not name. Roles are stable across people —
+"on-call engineer" not "Anna". Include silent stakeholders the
+room forgot (support, finance, legal, end-users, future-team).
+
+### 2. Capture each stakeholder's lens
+
+For each stakeholder:
+
+- **What they want** — outcome, in their voice.
+- **What they fear** — the failure mode they cannot accept.
+- **What they will trade** — what they will give up to get the
+  outcome.
+
+If a lens is missing, mark `unknown` and surface it — do NOT invent
+a position the stakeholder did not state.
+
+### 3. Build the matrix
+
+| Criterion | PO | Ops | Support | Eng | End-user | ... |
+|---|---|---|---|---|---|---|
+| Time-to-ship | + | – | 0 | – | + | |
+| Operational load | 0 | – | – | – | + | |
+| ...
+
+`+` benefits, `–` costs, `0` neutral. The columns are stakeholders;
+the rows are criteria. Criteria that score `0` everywhere are
+noise — drop.
+
+### 4. Surface the trade-off
+
+Pick the top 2-3 criteria where the matrix splits stakeholders
+hardest. State the trade-off in plain language:
+
+> *"Picking option X means PO ships faster, but on-call carries
+> more pages. Picking option Y means on-call sleeps, but PO slips
+> two weeks."*
+
+If no option splits the matrix unfavourably, the trade-off is
+imaginary — surface that and stop.
+
+### 5. Recommend a path
+
+Pick the option whose `–` cells are owned by stakeholders who can
+execute mitigations. Avoid options where the cost lands on a
+stakeholder who has no voice in the room. State the recommendation
+explicitly with a one-sentence rationale.
+
+### 6. Validate the matrix
+
+Verify before emitting: every stakeholder has wants / fears / trades
+filled or marked `unknown`, the matrix has no row that scores `0`
+everywhere, the trade-off paragraph names a concrete cost (not just
+"there is a trade-off"), and the recommendation cites which `–`
+cells the named owner can execute. Ensure no silent stakeholder
+column is missing.
+
+## Related Skills
+
+**WHEN to use this**
+
+- A request crosses two stakeholder lenses (eng ↔ PO, PO ↔ ops, ops
+  ↔ infra) and the trade-off is **not yet code**.
+- The room agrees on the goal but disagrees on who absorbs the cost.
+- A roadmap step has *un*declared trade-offs that need surfacing
+  before commit.
+
+**WHEN NOT to use this**
+
+- The conflict surfaces **inside an open PR** (test-coverage fails
+  but PO wants to ship) — start with `code-review-multi-lens`
+  (sibling C8); a C8 verdict that surfaces stakeholder conflict
+  becomes input to this skill for escalation. Boundary prose lives
+  in [`docs/guidelines/cross-role-handoff.md`](../../../docs/guidelines/cross-role-handoff.md).
+- The trade-off is purely technical (perf vs storage, sync vs async)
+  — route to [`decision-record`](../decision-record/SKILL.md).
+- The dominant axis is risk, not stakeholder cost — route to
+  [`risk-officer`](../risk-officer/SKILL.md).
+- The output is the locked decision artifact — hand off to
+  [`decision-record`](../decision-record/SKILL.md) once the matrix
+  is built.
+
+## When the agent should load this
+
+- "Wer zahlt was bei dieser Entscheidung?"
+- "PO und Ops sind sich uneinig — wir brauchen Klarheit."
+- "Was ist der Trade-off zwischen X und Y für die einzelnen Lenses?"
+- "Stakeholder-Konflikt vor dem Commit auflösen."
+- "Diese Roadmap-Phase hat undeclared trade-offs."
+
+## Output
+
+The trade-off report is a single block with these ordered fields:
+
+1. `Decision:` — one sentence framing the choice
+2. `Stakeholders:` — bullet list, each with wants / fears / trades
+3. `Matrix:` — markdown table with criteria rows and stakeholder columns
+4. `Trade-off in plain language:` — one paragraph naming the cost
+5. `Recommendation:`, `Rationale:`, `Next:` — explicit choice +
+   rationale + handoff target
+
+```
+Stakeholder trade-off
+Decision: <one sentence>
+
+Stakeholders:
+  - <role>  wants: <outcome>     fears: <failure>     trades: <what>
+  - ...
+
+Matrix:
+  | Criterion       | <SH 1> | <SH 2> | ... |
+  | ...
+
+Trade-off in plain language:
+  <one paragraph>
+
+Recommendation: <option>
+Rationale:      <one sentence>
+Next:           /decision-record  to lock the choice
+```
+
+## Gotcha
+
+- The room is rarely all the stakeholders. Add the silent ones
+  explicitly (support, future-team, end-users).
+- A `+` everywhere column is suspect; either a stakeholder
+  understated the cost or you understated the cost.
+- The "happy path" recommendation is the option with the cost on
+  someone who is *not in the room*. Resist it.
+
+## Do NOT
+
+- Do NOT label stakeholders by name — roles only.
+- Do NOT score before listing the stakeholders' own words; agent
+  ventriloquism is the failure mode.
+- Do NOT pick the option that scores best on *all* stakeholders —
+  if it exists, the trade-off was imaginary; surface that.
+- Do NOT lock the choice in this skill; hand off to
+  `decision-record`.
+
+## Runnable example
+
+A pricing-page rewrite that ships faster vs gives ops more lead time:
+
+- Decision: *"Should the pricing-page rewrite ship in 2 weeks
+  (option A) or 4 weeks with a managed rollout (option B)?"*
+- Stakeholders:
+  - **PO** wants: revenue lift on Q-end · fears: churn signal in
+    the noise · trades: copy polish for time-to-ship.
+  - **On-call eng** wants: change window outside Friday · fears:
+    Saturday paging on a marketing rollout · trades: shippable A/B
+    framework for a deploy gate.
+  - **Support lead** wants: scripted answers for the new tier ·
+    fears: ticket-volume spike unprepared · trades: depth of
+    answers for breadth.
+  - **End-user (free tier)** wants: clear "what stays free" line ·
+    fears: silent paywall on a feature they rely on · trades:
+    nothing — silent stakeholder.
+- Matrix splits hardest on **operational load** (option A: `–` for
+  on-call + support, `+` for PO) and **clarity for end-users**
+  (option B: `+` for support + end-user, `–` for PO timing).
+- Trade-off in plain language: *"Option A means PO hits Q-end, but
+  on-call carries a marketing-rollout pager and support eats ticket
+  spikes blind. Option B means support and end-users land softly,
+  but PO slips two weeks past Q-end."*
+- Recommendation: option B. Rationale: the `–` cells in option A
+  land on stakeholders who **cannot** mitigate from inside the
+  rollout (free-tier user has no voice in the room).
+- Next: `/decision-record` to lock option B; the supersession chain
+  cites the original "ship by Q-end" mandate as the constraint that
+  changed.

package/.agent-src/skills/subagent-orchestration/SKILL.md

@@ -2,6 +2,7 @@
 name: subagent-orchestration
 description: "Use when orchestrating implementer/judge subagents — seven modes (do-and-judge ±two-stage, do-in-steps/parallel/worktrees, do-competitively, judge-with-debate) — models from .agent-settings.yml."
 source: package
+domain: process
 ---
 
 # subagent-orchestration
@@ -159,6 +160,18 @@ step is under ~30 minutes. The branch-creation, context-switch, and
 worktree-cleanup cost dominates. Stick with mode 1 (do-and-judge)
 or mode 3 (do-in-steps) for those.
 
+**Competitive variant — per-candidate isolation.** Mode 5
+(`do-competitively`) + worktrees: each candidate runs in its own
+worktree (no cross-candidate state leak). Selection rules:
+
+- **No auto-merge.** Orchestrator never merges candidate branches.
+  Hard Floor per [`non-destructive-by-default`](../../rules/non-destructive-by-default.md) —
+  applies even under standing autonomy. ADR-005 records reasoning.
+- **Ranked presentation.** Judge ranks 1..N with one-line
+  justifications; user picks winner.
+- **Loser worktrees stay.** Orchestrator does not auto-delete losing
+  worktrees — user keeps option to harvest a partial idea before cleanup.
+
 ## Status taxonomy — every subagent return uses one envelope
 
 Every implementer or judge return must conform to

package/.agent-src/skills/systematic-debugging/SKILL.md

@@ -2,6 +2,7 @@
 name: systematic-debugging
 description: "Use when hitting a bug, test failure, crash, or unexpected behavior — enforces reproduce → isolate → hypothesize → verify before any fix — even when the user just says 'this is broken' or 'quick fix'."
 source: package
+domain: discovery
 council_depth: deep
 ---