@event4u/agent-config 1.33.0 → 1.34.0

package/.agent-src/skills/decision-record/SKILL.md

@@ -0,0 +1,143 @@
+---
+name: decision-record
+description: "Use when locking a trade-off, structuring an ADR draft, or wiring supersession chains — frames options · trade-offs · consequences before the file is written by `adr-create`."
+personas:
+  - senior-engineer
+  - critical-challenger
+  - product-owner
+source: package
+domain: process
+---
+
+# decision-record
+
+> Shape the **thinking** behind an architectural decision: list the
+> options, expose trade-offs, lock the chosen variant, and wire the
+> supersession chain. Hands off to [`adr-create`](../adr-create/SKILL.md)
+> for file mechanics (numbering, index, frontmatter). This skill does
+> not write the ADR file itself.
+
+## When to use
+
+- A team is about to commit to a non-trivial architectural choice and
+  wants the trade-offs on paper first.
+- Two engineers disagree on an approach — surface the options and
+  consequences before one wins by attrition.
+- A previous decision needs revisiting; the result must `supersede:`
+  the older ADR with explicit rationale.
+- German triggers: "lass uns das festzurren", "Trade-off-Matrix",
+  "welche Option ziehen wir?".
+
+Do NOT use when:
+
+- The file mechanics are the entire ask (numbering, regenerating the
+  index) — route directly to [`adr-create`](../adr-create/SKILL.md).
+- The decision is reversible and small (e.g. variable rename) — ADRs
+  are for choices that constrain future work.
+- The user wants a feature plan, not a decision — route to the
+  planning command instead.
+
+## Procedure
+
+### 1. State the decision in one sentence
+
+*"We need to decide `X` because `Y`."* If you cannot, the decision
+is not ripe — surface that and stop.
+
+### 2. Identify and enumerate options (≥ 2, usually ≤ 4)
+
+Each option gets:
+
+- **Name** — short, descriptive, never "option A / B / C".
+- **Sketch** — what it actually does in one paragraph.
+- **Cost / benefit** — three to five bullets per side, concrete.
+- **Reversibility** — easy / costly / one-way (Bezos two-way / one-way
+  door framing).
+
+Add an **explicit "do nothing"** option whenever it is plausible —
+forces the user to compare the change against the status quo.
+
+### 3. Build the trade-off matrix
+
+| Criterion | Option 1 | Option 2 | ... |
+|---|---|---|---|
+| Implementation cost | | | |
+| Operational cost | | | |
+| Reversibility | | | |
+| Blast radius | | | |
+| Time-to-value | | | |
+
+Pick criteria that *separate* the options. Criteria where every
+option scores the same are noise — drop them.
+
+### 4. Lock the choice + consequences
+
+Write:
+
+- **Decision:** *"We pick `<Option name>`."*
+- **Consequences:** what becomes true, what becomes harder, what
+  becomes impossible. At least one of each, or admit that nothing
+  becomes harder (rare; verify).
+
+### 5. Wire the supersession chain (if any)
+
+If this decision overrides a prior ADR:
+
+- Cite the prior ADR id and one-line summary.
+- State **what changed in the world** that justifies overriding —
+  not "we now think differently".
+- Hand off the `supersedes:` linkage to `adr-create`.
+
+### 6. Hand off to file mechanics
+
+Output the structured payload (below). The user — or
+`adr-create` — turns it into the file.
+
+## Output format
+
+```
+Decision: <one sentence>
+
+Options:
+  1. <name> — <sketch>
+       Pros: ...
+       Cons: ...
+       Reversibility: easy | costly | one-way
+  2. ...
+  N. Do nothing — <sketch>
+
+Trade-off matrix:
+  | Criterion | <opt 1> | <opt 2> | ... |
+  | ...
+
+Locked: <chosen option name>
+
+Consequences:
+  + <becomes true>
+  - <becomes harder>
+  ✗ <becomes impossible>
+
+Supersedes: <ADR-XYZ "title">  (if any)
+Trigger:    <what changed>     (if superseding)
+
+Next: /adr-create  with the payload above
+```
+
+## Gotcha
+
+- "We compared the options" is not a comparison. The matrix must
+  separate them on at least two criteria.
+- Pros without cons is advocacy, not analysis. If you cannot find
+  cons for the chosen option, you have not understood it yet.
+- A supersession with no "what changed in the world" is a vibe
+  pivot. Reject and ask.
+
+## Do NOT
+
+- Do NOT pick the option before listing them — the matrix is the
+  point, not the conclusion.
+- Do NOT write the ADR file from this skill — `adr-create` owns
+  filenames, numbering, and index regeneration.
+- Do NOT pad option counts to look thorough; two real options beat
+  four straw men.
+- Do NOT silently update an old ADR; supersession is explicit.

package/.agent-src/skills/deep-reading-analyst/SKILL.md

@@ -3,6 +3,7 @@ name: deep-reading-analyst
 description: "Deep analysis of articles/long-form via thinking frameworks (SCQA, mental models, inversion) — 'analyze article', 'deep dive', 'extract insights', URL/text wanting depth not summary."
 status: active
 source: package
+domain: discovery
 external_source: "https://github.com/ginobefun/deep-reading-analyst-skill/tree/26cd7dc9920e025d39751e396e707399022e49ef/src/deep-reading-analyst"
 refresh_trigger: "Upstream `ginobefun/deep-reading-analyst-skill` major rewrite (new framework added, dispatch table reshaped, or SHA pin invalidated by reference rename)."
 sunset_criterion: "Replace with a 50-line pointer skill if (a) all referenced modules are adopted as project-local guidelines (`docs/guidelines/agent-infra/{framework}.md`) AND (b) the dispatch logic moves into a project-native router."

package/.agent-src/skills/defense-in-depth/SKILL.md

@@ -2,6 +2,7 @@
 name: defense-in-depth
 description: "Use when validation needs entry, business-logic, environment, and instrumentation guards so a bad value cannot reach the failure point — turns a local bug fix into a structural one."
 source: package
+domain: quality
 ---
 
 # defense-in-depth

package/.agent-src/skills/dependency-upgrade/SKILL.md

@@ -2,6 +2,7 @@
 name: dependency-upgrade
 description: "Use when upgrading dependencies — "update Laravel", "bump PHP version", or "upgrade packages". Covers changelog review, breaking change detection, and verification."
 source: package
+domain: engineering
 ---
 
 # dependency-upgrade

package/.agent-src/skills/description-assist/SKILL.md

@@ -2,6 +2,7 @@
 name: description-assist
 description: "Use when polishing a skill/rule/command/guideline frontmatter description — pushier phrasing, trigger coverage, undertrigger audit — even if the user just says 'make this pushier'."
 source: package
+domain: process
 ---
 
 <!-- cloud_safe: degrade -->

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

@@ -2,6 +2,7 @@
 name: design-review
 description: "Use when the user says "review the design", "check the UI", or wants a comprehensive UI/UX review. Uses a 7-phase methodology covering interaction, responsiveness, accessibility, and more."
 source: package
+domain: quality
 ---
 
 # design-review

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

@@ -2,6 +2,7 @@
 name: devcontainer
 description: "Use when configuring DevContainers or GitHub Codespaces — devcontainer.json, custom images, secrets, VS Code features — even when the user just says 'why does my Codespace not start'."
 source: package
+domain: devops
 ---
 
 # devcontainer

package/.agent-src/skills/developer-like-execution/SKILL.md

@@ -2,6 +2,7 @@
 name: developer-like-execution
 description: "Use when implementing, debugging, refactoring, or reviewing code — enforces the think → analyze → verify → execute workflow — even when the user just says 'implement X' without naming it."
 source: package
+domain: process
 execution:
   type: assisted
   handler: internal

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

@@ -2,6 +2,7 @@
 name: docker
 description: "Use when working with Docker — Dockerfile edits, docker-compose services, containers, or the dual-container (fast + Xdebug) setup — even when the user just says 'my container won't start'."
 source: package
+domain: devops
 ---
 
 # docker

package/.agent-src/skills/dto-creator/SKILL.md

@@ -2,6 +2,7 @@
 name: dto-creator
 description: "Use when the user says "create a DTO", "new data transfer object", or needs to convert request/response data into a typed PHP class. Creates DTOs with SimpleDto base class and attribute mapping."
 source: package
+domain: engineering
 ---
 
 # dto-creator

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

@@ -1,7 +1,10 @@
 ---
 name: eloquent
 description: "Use when writing Eloquent models, relationships, scopes, or queries via Model:: — 'fetch users with their orders'. NOT for PHPStan output, non-Eloquent services, or raw SQL questions."
+personas:
+  - eloquent-tamer
 source: package
+domain: engineering
 ---
 
 # eloquent

package/.agent-src/skills/error-handling-patterns/SKILL.md

@@ -2,6 +2,7 @@
 name: error-handling-patterns
 description: "Use when picking a failure-reporting strategy — exceptions vs Result types, recoverable vs not, retry / circuit-breaker / graceful degradation — decision framework only, catalogues externalized."
 source: package
+domain: engineering
 status: active
 refresh_trigger: "≥30% of cited upstream pattern catalogues become deprecated, OR a new top-2 ecosystem (Python/JS/PHP/Go/Rust) ships a paradigm-shifting standard error model"
 sunset_criterion: "When the upstream framework docs (Laravel, FastAPI, Express, Axum, Effect-TS) all carry an equivalent in-tree decision framework AND consumer projects no longer cite this skill in PR reviews for two consecutive review cycles."

package/.agent-src/skills/estimate-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/existing-ui-audit/SKILL.md

@@ -1,7 +1,10 @@
 ---
 name: existing-ui-audit
 description: "Use BEFORE writing or editing any non-trivial UI — inventories components, design tokens, shadcn primitives, and reusable patterns into state.ui_audit. Hard gate for the ui directive set."
+personas:
+  - frontend-engineer
 source: package
+domain: discovery
 ---
 
 # existing-ui-audit

package/.agent-src/skills/fe-design/SKILL.md

@@ -1,7 +1,10 @@
 ---
 name: fe-design
 description: "Reference for frontend-design heuristics — component architecture, layout patterns, form/table design, responsive strategy, a11y, UX principles. Stack-agnostic; cited by directives/ui/design.py."
+personas:
+  - frontend-engineer
 source: package
+domain: engineering
 ---
 
 # Frontend Design Skill (Reference)
@@ -200,7 +203,7 @@ Step indicator (1 — 2 — 3)
 
 When `directives/ui/design.py` (or any caller) cites this skill:
 
-1. **Confirm the audit ran first** — `state.ui_audit` from [`existing-ui-audit`](../existing-ui-audit/SKILL.md) is mandatory. Stop and request the audit if missing.
+1. **Inspect `state.ui_audit` first** — review the audit produced by [`existing-ui-audit`](../existing-ui-audit/SKILL.md); it is mandatory. Stop and request the audit if missing.
 2. **Pick the smallest matching section** — Component Architecture, Form Design, Table Design, Responsive Strategy, Accessibility, or UX Principles. Cite by H2/H3 heading, never paste the whole skill.
 3. **Defer to audit findings** — when the audit pins a project pattern (token, primitive, layout convention), use it. The heuristics here are fallbacks for gaps, not overrides.
 4. **Defer to the stack apply skill** — Blade vs. Livewire vs. Flux vs. React-shadcn choices come from the dispatched impl skill, never from this reference.

package/.agent-src/skills/feature-planning/SKILL.md

@@ -2,6 +2,7 @@
 name: feature-planning
 description: "Use when the user says "plan a feature", "brainstorm", "explore this idea", or wants to go from idea to structured plan and roadmap."
 source: package
+domain: product
 ---
 
 # feature-planning

package/.agent-src/skills/file-editor/SKILL.md

@@ -2,6 +2,7 @@
 name: file-editor
 description: "Use when opening edited files in the user's IDE. Reads settings from .agent-settings.yml to determine IDE and whether auto-open is enabled."
 source: package
+domain: process
 execution:
   type: assisted
   handler: shell

package/.agent-src/skills/finishing-a-development-branch/SKILL.md

@@ -2,6 +2,7 @@
 name: finishing-a-development-branch
 description: "Use when the feature is implementation-complete and the next step is 'ship it' — verifies, cleans up, and routes to merge/PR/park/discard — even when the user just says 'I'm done, what now?'."
 source: package
+domain: process
 ---
 
 # finishing-a-development-branch

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

@@ -2,6 +2,7 @@
 name: flux
 description: "Use when the project uses `livewire/flux` — dispatched by `directives/ui/{apply,review,polish}.py`. Covers Flux components, slots, variants, and form primitives."
 source: package
+domain: engineering
 ---
 
 # flux

package/.agent-src/skills/form-handler/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: form-handler
+description: "Use when designing or reviewing a form — validation timing, error display, submission lifecycle, optimistic UI, dirty/pristine state, idempotency — even on 'why does submit double-fire?'."
+personas:
+  - frontend-engineer
+source: package
+domain: engineering
+---
+
+# form-handler
+
+> Pick the validation timing, lay out error placement, sequence the
+> submission lifecycle, and decide where (and whether) to use
+> optimistic UI. Stack-agnostic — Livewire, Inertia, React Hook Form,
+> server-rendered Blade — the lens is the same. Pair with
+> [`laravel-validation`](../laravel-validation/SKILL.md) for
+> server-side rules and [`accessibility-auditor`](../accessibility-auditor/SKILL.md)
+> for label / error a11y.
+
+## When to use
+
+- A new form is being designed (login, signup, settings, multi-step
+  wizard) and the validation strategy is unsettled.
+- A form bug shows up: double-submission, lost data on validation
+  fail, error not announced, optimistic update flicker.
+- A wizard or multi-step flow needs state across steps and the
+  ownership of dirty / pristine state is unclear.
+- German triggers: "Formular bauen", "wann validieren?",
+  "Submit feuert doppelt".
+
+Do NOT use when:
+
+- The screen is read-only / display-only — no form, skip.
+- The question is purely server-side validation rules — route to
+  [`laravel-validation`](../laravel-validation/SKILL.md) (or the
+  stack equivalent).
+- The question is form *layout* / spacing — route to
+  [`fe-design`](../fe-design/SKILL.md) or
+  [`tailwind-engineer`](../tailwind-engineer/SKILL.md).
+
+## Procedure
+
+### 1. Identify field types, pick validation timing
+
+Inspect every field on the form (text, password, async-checked,
+file, multi-step) before choosing timing. Three knobs, picked per
+field:
+
+| Timing | When |
+|---|---|
+| On submit only | Forms with privacy concerns (passwords); short forms |
+| On blur | Default — feedback when the user finishes the field |
+| On change (debounced) | Typing-feedback fields (username availability, password strength) |
+
+Avoid validate-on-change for the whole form — premature errors
+shame the user. Username-availability is the canonical exception.
+
+### 2. Lock the error display contract
+
+Per field: error message location (below field), text-based
+(never colour-only), `aria-describedby` wired, focus moves to
+**first** error on submit-fail. Per form: a summary box at top
+that lists every error with anchor links — required for forms
+> 5 fields and any wizard step.
+
+### 3. Sequence the submission lifecycle
+
+Order matters; bake into one helper:
+
+1. Disable the submit button (idempotency).
+2. Run client-side validation; bail on failure with focus to
+   first error.
+3. Mark optimistic state if applicable (step 5).
+4. POST to server.
+5. On 2xx: clear dirty state, show success, route or reset.
+6. On 4xx: surface field errors per the display contract; restore
+   submit button; **do not** lose user input.
+7. On 5xx: keep input, show retry CTA, log to error tracker.
+
+A submit handler that skips step 1 is a duplicate-record bug
+waiting to fire on slow networks.
+
+### 4. Decide on optimistic UI per action
+
+Optimistic UI is only safe when **rollback is cheap and visible**:
+toggling a like, marking read, in-list reorder. It is unsafe for:
+multi-field forms, money movements, anything with downstream
+notifications. Default to non-optimistic; opt in per action with
+a documented rollback path.
+
+### 5. Track dirty state and unsaved-changes guard
+
+Pristine = identical to the server's last-known value. Dirty =
+any difference. On route-leave with dirty form, prompt
+confirmation (browser `beforeunload` for full nav, in-app modal
+for client-side route changes). For wizards, dirty state is
+per-step; submit at step N validates only that step's fields,
+final submit re-validates the whole payload server-side.
+
+## Output format
+
+Return:
+
+1. Validation contract — per-field timing + error-display rules.
+2. Submit lifecycle — the 7-step sequence with any deviations called out.
+3. Risk surface — optimistic-UI rollback path, dirty guard, idempotency,
+   server contract (endpoint, status codes, error shape).
+
+Concrete shape:
+
+```
+Form:               <name / route>
+Validation timing:  per field — <field: timing>
+Error display:      below field + summary box (≥ 5 fields)
+Submit lifecycle:   <list of steps 1–7 with any deviations>
+Optimistic UI:      <none | per action — list with rollback path>
+Dirty guard:        <yes/no — and the route-leave hook>
+Idempotency:        <strategy — disable + token? request id?>
+Server contract:    <endpoint, status codes, error shape>
+```
+
+## Gotcha
+
+- Disabling the submit button without showing a spinner reads as
+  "broken UI"; pair the disable with a visible busy state.
+- Validation-on-change for a password creates a bad UX: errors
+  appear before the user has finished typing. Validate-on-blur
+  with a single re-validate-on-change *after* the first failure.
+- Optimistic UI + slow network = the user sees success then a
+  rollback; that is worse than waiting. Pick optimistic only when
+  the request is < 300 ms p95.
+- Wizard "save & continue" buttons that POST per step double the
+  failure surface; only do this if the back-end can resume.
+  Otherwise hold state client-side and POST once at the end.
+
+## Do NOT
+
+- Do NOT trust client-side validation alone; server-side is the
+  contract. Client-side is UX, not safety.
+- Do NOT clear the form on validation failure; the user's input
+  is sacred until the server says it is safely saved.
+- Do NOT use colour as the only error signal; that is both an a11y
+  failure and a print / colour-blind regression.
+- Do NOT enable optimistic UI by default; the rollback story has
+  to fit on one line, or it does not ship optimistic.

package/.agent-src/skills/funnel-analysis/SKILL.md

@@ -4,6 +4,7 @@ description: "Use when diagnosing where a SaaS or product funnel leaks — visit
 status: active
 tier: senior
 source: package
+domain: product
 ---
 
 # funnel-analysis

package/.agent-src/skills/git-workflow/SKILL.md

@@ -2,6 +2,7 @@
 name: git-workflow
 description: "Use when working with Git — branch naming, commit messages, PR creation, rebasing, or the code review process — even when the user says 'push this' or 'merge the branch' without naming Git."
 source: package
+domain: process
 execution:
   type: assisted
   handler: internal

package/.agent-src/skills/github-ci/SKILL.md

@@ -2,6 +2,7 @@
 name: github-ci
 description: "Use when working with GitHub Actions — workflow YAML, quality gates, test matrices, deployment triggers, reusable workflows — even when the user just says 'my CI is failing' or 'add a check'."
 source: package
+domain: devops
 ---
 
 # github-ci

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

@@ -2,6 +2,7 @@
 name: grafana
 description: "Use when working with Grafana — dashboards, Loki LogQL queries, alerting rules, monitoring panels — even when the user just says 'build me a dashboard' or 'query the logs' without naming Grafana."
 source: package
+domain: devops
 ---
 
 # Grafana Skill

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

@@ -2,6 +2,7 @@
 name: guideline-writing
 description: "Use when creating or editing a guideline in docs/guidelines/ — reference material cited by skills, no auto-triggers — even when the user just says 'write up our naming conventions'."
 source: package
+domain: process
 ---
 
 <!-- cloud_safe: degrade -->

package/.agent-src/skills/incident-commander/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: incident-commander
+description: "Use during or right after an incident — frames severity, sets comms cadence, drafts the post-mortem skeleton — even when the user just says 'production is down' or 'wir haben einen Vorfall'."
+personas:
+  - senior-engineer
+  - critical-challenger
+source: package
+domain: process
+---
+
+# incident-commander
+
+> Run the **coordination layer** during an incident: classify
+> severity, set comms cadence, hold a clean timeline, and draft the
+> post-mortem skeleton when the dust settles. This skill does **not**
+> debug the system — that is the engineer's job. The commander keeps
+> the room oriented so the engineer can think.
+
+## When to use
+
+- Production is degraded or down and someone needs to coordinate.
+- A critical job, queue, or third-party is failing and the team is
+  scrambling.
+- A near-miss happened and a post-mortem is being drafted.
+- German triggers: "Vorfall", "Prod ist down", "wer übernimmt
+  Comms?".
+
+Do NOT use when:
+
+- The system is healthy and the concern is a future outage —
+  route to [`risk-officer`](../risk-officer/SKILL.md) instead.
+- The user wants the bug fixed — route to `/bug-investigate` and
+  `/bug-fix`. The commander coordinates; engineers debug.
+- The incident is a security breach — route to
+  [`threat-modeling`](../threat-modeling/SKILL.md) first; the
+  commander still runs comms but the response shape changes.
+
+## Procedure
+
+### 1. Inspect the signal and classify severity
+
+| SEV | Trigger |
+|---|---|
+| SEV-1 | User-facing outage, data loss risk, revenue impact |
+| SEV-2 | Major degradation, workaround exists |
+| SEV-3 | Single-feature broken, low blast radius |
+| SEV-4 | Internal-only, not user-visible |
+
+Pick the highest SEV any signal supports. Downgrades happen later
+with evidence; never start low to avoid noise.
+
+### 2. Set the comms cadence
+
+- **Internal channel** — single thread; no side-channels.
+- **Update interval** — SEV-1 every 15 min, SEV-2 every 30 min,
+  SEV-3/4 on state change.
+- **Status page** — update on SEV-1 / SEV-2; on by default unless
+  the user opts out with a stated reason.
+- **Stakeholder list** — who hears each update (eng-lead, PO,
+  support, leadership). Pre-decide so updates are not rewritten
+  per-recipient.
+
+### 3. Hold the timeline
+
+Append-only log: timestamp + actor + observation. No edits, no
+"actually it was earlier" — corrections are new entries. Drives
+the post-mortem and prevents memory rewrite.
+
+### 4. Drive to mitigation, not root cause
+
+During the incident, the question is *"what makes the bleeding
+stop?"* Root cause is for after. Document the gap explicitly —
+"mitigated, root cause unknown" is a valid intermediate state.
+
+### 5. Draft the post-mortem skeleton
+
+Once stable:
+
+- **Summary** — one paragraph, blame-free.
+- **Timeline** — copy from step 3.
+- **Impact** — users, duration, data, revenue.
+- **What went well** — at least one item; finding none is a smell.
+- **What went wrong** — process, tooling, signals, gaps.
+- **Action items** — owned, sized, with a trigger for completion.
+
+Hand off the skeleton; the engineer fills root cause and the team
+adds action items.
+
+### 6. Validate the handoff
+
+Before declaring the incident handed off, verify: SEV is set, comms
+cadence is announced, the timeline has at least one entry per
+update, mitigation state is explicit (`active` / `mitigated` /
+`resolved`), and a post-mortem owner is assigned. Ensure no field
+is left as the placeholder default.
+
+## Output format
+
+The incident record is a single block with these ordered fields:
+
+1. `SEV:` — one of `1` / `2` / `3` / `4`
+2. `State:` — one of `active` / `mitigated` / `resolved` / `post-mortem`
+3. `Started:` and `Channel:` — timestamp and single thread/room
+4. `Cadence:` and `Timeline:` — update interval and append-only log
+5. `Mitigation:`, `Root cause:`, `Post-mortem owner:` — explicit values
+   or `unknown`; never blank
+
+```
+Incident
+SEV:       1 | 2 | 3 | 4
+State:     active | mitigated | resolved | post-mortem
+Started:   <timestamp>
+Channel:   <thread / room>
+Cadence:   <interval>
+
+Timeline (append-only):
+  - <ts>  <actor>  <observation>
+  - ...
+
+Mitigation: <action> | unknown
+Root cause: <hypothesis> | unknown — investigation deferred to post-mortem
+Post-mortem owner: <role>
+```
+
+## Gotcha
+
+- The commander does not also debug. Splitting roles keeps the room
+  oriented; one person doing both starves comms.
+- "We do not need a post-mortem" is almost always wrong. Even
+  near-misses earn a one-page write-up.
+- The first SEV classification is rarely the final one — surface
+  upgrades / downgrades explicitly with a reason.
+
+## Do NOT
+
+- Do NOT debug from this skill; route to engineering skills.
+- Do NOT skip status-page updates on SEV-1 because "it'll be quick".
+- Do NOT close an incident without a post-mortem owner assigned.
+- Do NOT edit the timeline after the fact; corrections are new
+  entries.

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

@@ -2,6 +2,7 @@
 name: jira-integration
 description: "Use when the user says "check Jira", "create ticket", "update issue", or needs JQL queries, ticket transitions, or branch-to-ticket linking."
 source: package
+domain: process
 ---
 
 # Jira Skill