hatch3r 1.8.0 → 2.0.0

package/{commands/hatch3r-hooks.md → dist/content/skills/hatch3r-hooks/SKILL.md}

@@ -1,41 +1,40 @@
 ---
 id: hatch3r-hooks
-type: command
-orchestrator: false
-description: Define and manage event-driven hooks that activate agents on project events
-tags: [core, devops]
+name: hatch3r-hooks
+type: skill
+description: Define, edit, and manage event-driven hooks that activate agents on project events. Tool-agnostic — adapters translate hook definitions into tool-native configurations during `npx hatch3r sync`.
+tags: [devops, orchestration]
 quality_charter: agents/shared/quality-charter.md
 efficiency_patterns: agents/shared/efficiency-patterns.md
 cache_friendly: true
-parallel_tool_default: true
 ---
 
-## §0 Detect Ambiguity (P8 B1)
-
-Before any action, scan the user's request and provided context for unresolved questions in scope, acceptance criteria, irreversibility, or constraint conflicts (contradictory inputs, missing target, unknown convention). If any are found, ask the user via the platform-native question tool per `agents/shared/user-question-protocol.md` — do not proceed under silent assumption. This is the default path, not an exception. Acceptable to proceed without asking ONLY when scope is single-target, single-concern, and the brief alone is testable. Any residual ambiguity discovered mid-workflow invokes the same protocol.
-
-## Agent Pipeline
-
-This command runs as a single orchestrator without sub-agent delegation. Hook definition and management are performed inline.
-
-## Learnings Consultation
+# Hooks — Event-Driven Agent Activation
 
-If `.agents/learnings/` exists, scan for learnings related to hook configurations, event trigger patterns, or prior hook issues before starting.
+## Quick Start
 
-# Hooks — Event-Driven Agent Activation
+```
+Task Progress:
+- [ ] Step 0: Detect ambiguity (P8 B1)
+- [ ] Step 1: Discover current state
+- [ ] Step 2: Define a hook (add) — select event, agent, conditions, write definition file
+- [ ] Step 3: Edit an existing hook
+- [ ] Step 4: Remove a hook
+- [ ] Step 5: Sync hooks to tools
+```
 
-Define, edit, and manage event-driven hooks that automatically activate hatch3r agents when specific project events occur. Hook definitions are tool-agnostic — the adapter pipeline translates them into tool-native configurations during `npx hatch3r sync`.
+## Step 0 — Detect Ambiguity (P8 B1)
 
----
+Before any action, scan the user's request and provided context for unresolved questions in scope, acceptance criteria, irreversibility, or constraint conflicts (contradictory inputs, missing target, unknown convention). If any are found, ask the user via the platform-native question tool per `agents/shared/user-question-protocol.md` — do not proceed under silent assumption. This is the default path, not an exception. Acceptable to proceed without asking ONLY when scope is single-target, single-concern, and the brief alone is testable. Any residual ambiguity discovered mid-workflow invokes the same protocol.
 
-## Workflow
+## Learnings Consultation
 
-Execute these steps in order. **Do not skip any step.** Ask the user at every checkpoint marked with ASK.
+If `.hatch3r/learnings/` exists, scan for learnings related to hook configurations, event trigger patterns, or prior hook issues before starting.
 
-### Step 1: Discover Current State
+## Step 1: Discover Current State
 
-1. Check `.agents/hooks/` for existing hook definition files (`.md` files with frontmatter).
-2. Read `.agents/hatch.json` for configured tools and features.
+1. Check `hooks/` for existing hook definition files (`.md` files with frontmatter).
+2. Read `.hatch3r/hatch.json` for configured tools and features.
 3. List existing hooks with their event, agent, and conditions.
 
 Present the current state:
@@ -48,13 +47,11 @@ Hooks Feature: {enabled/disabled}
 
 **ASK:** "Current hooks: {list or 'none'}. Tools: {list}. What would you like to do? (a) Add a new hook, (b) Edit existing hook, (c) Remove a hook, (d) List all hooks, (e) Sync hooks to tools"
 
----
-
-### Step 2: Define Hook
+## Step 2: Define Hook
 
 For adding a new hook:
 
-#### 2a. Select Event
+### 2a. Select Event
 
 Present available events with descriptions:
 
@@ -79,36 +76,39 @@ Present available events with descriptions:
 | `on-dependency-change` | Triggered when dependencies are added/updated/removed | Security audit, compatibility check, license validation |
 | `on-security-finding` | Triggered when a security issue is discovered | Alert escalation, auto-fix suggestions, incident creation |
 
+> [!IMPORTANT]
+> Claude Code only maps `session-start` → `SessionStart` semantically. Every other event above (pre-commit, post-merge, ci-failure, file-save, pre-push, etc.) is a git/project lifecycle event with NO native Claude Code mapping — the adapter emits a no-op or alternative strategy, NOT a PreToolUse/PostToolUse binding. If the user picks one of these and targets Claude Code, say so before writing the definition. Full detail: the "Claude Code event mapping" note in Step 2d below.
+
 **ASK:** "Select an event for this hook."
 
-#### 2b. Select Agent
+### 2b. Select Agent
 
 Present available hatch3r agents:
 
 - `lint-fixer` — Automatic lint error resolution
-- `test-writer` — Test generation for new or changed code
+- `hatch3r-testability` — Test generation for new or changed code
 - `reviewer` — Code review and quality checks
-- `security-auditor` — Security vulnerability scanning
+- `hatch3r-security` — Security vulnerability scanning
 - `ci-watcher` — CI/CD pipeline monitoring and diagnosis
 - `a11y-auditor` — Accessibility compliance checks
-- `perf-profiler` — Performance analysis and optimization
+- `hatch3r-performance` — Performance analysis and optimization
 - `dependency-auditor` — Dependency security and update checks
 - `docs-writer` — Documentation generation and updates
 
-If the user wants a custom agent name not in this list, accept it but warn that the agent must exist in `.agents/agents/`.
+If the user wants a custom agent name not in this list, accept it but warn that the agent must exist in `agents/`.
 
 **ASK:** "Select an agent to activate when this event fires."
 
-#### 2c. Define Conditions (Optional)
+### 2c. Define Conditions (Optional)
 
 - **Glob patterns:** Which files trigger this hook (e.g., `src/**/*.ts`, `*.css`)
 - **Branch patterns:** Which branches (e.g., `main`, `release/*`)
 
 **ASK:** "Add conditions? (glob patterns, branch patterns, or skip for 'always activate')"
 
-#### 2d. Write Hook Definition File
+### 2d. Write Hook Definition File
 
-Generate the hook definition file at `.agents/hooks/{event}-{agent-short-name}.md`:
+Generate the hook definition file at `hooks/{event}-{agent-short-name}.md`:
 
 ```markdown
 ---
@@ -141,152 +141,63 @@ Claude Code event mapping: **Claude Code's native hook events (PreToolUse, PostT
 
 **ASK:** "Hook definition: {summary}. Create? (yes / adjust / cancel)"
 
----
-
-### Step 3: Edit Existing Hook
+## Step 3: Edit Existing Hook
 
 For editing an existing hook:
 
 1. List all hooks and ask which to edit.
 2. Show current definition.
 3. Ask what to change (event, agent, conditions, description).
-4. Update the hook file in `.agents/hooks/`.
+4. Update the hook file in `hooks/`.
 
 **ASK:** "Updated hook: {summary}. Save? (yes / revert / cancel)"
 
----
-
-### Step 4: Remove a Hook
+## Step 4: Remove a Hook
 
 1. List all hooks and ask which to remove.
 2. Show the hook definition.
 
-**ASK:** "Remove hook '{id}'? This will delete `.agents/hooks/{filename}`. (yes / cancel)"
+**ASK:** "Remove hook '{id}'? This will delete `hooks/{filename}`. (yes / cancel)"
 
 3. Delete the file. Warn that tool-specific generated files (e.g., `.cursor/rules/hatch3r-hook-*.mdc`) will be cleaned up on the next `npx hatch3r sync`.
 
----
-
-### Step 5: Sync Hooks to Tools
+## Step 5: Sync Hooks to Tools
 
-1. Read all hook definitions from `.agents/hooks/`.
+1. Read all hook definitions from `hooks/`.
 2. For each configured tool in `hatch.json`, describe what will be generated:
    - **Claude Code:** Hook documentation appended to managed section of `CLAUDE.md`
    - **Cursor:** Glob-based `.mdc` rule files in `.cursor/rules/hatch3r-hook-*.mdc`
    - **Others:** No-op (hook definitions stored for future adapter support)
 3. Present the list of files that will be generated/updated.
 
+> [!IMPORTANT]
+> For Claude Code, only `session-start` becomes an executable native hook. Git/project-event hooks (pre-commit, post-merge, ci-failure, file-save, pre-push, etc.) are written to `CLAUDE.md` as documentation, NOT registered as native Claude Code hooks — they do not fire on the named event. State this explicitly when listing the generated Claude Code output (see the "Claude Code event mapping" note in Step 2d).
+
 **ASK:** "Hooks will generate these files: {list}. Run `npx hatch3r sync` to apply. (understood / sync now)"
 
 If user chooses "sync now", instruct them to run `npx hatch3r sync` in the terminal.
 
----
-
-## Custom Events
-
-Define project-specific hook events beyond the built-in types:
+## Hook Definition Schema (implemented surface)
 
-- **Event naming**: `custom:{domain}:{action}` (e.g., `custom:billing:subscription-change`)
-- **Event registration**: Add custom events to `hatch.json` under `hooks.customEvents`
-- **Event triggering**: Agents trigger custom events via `emit-hook custom:{name}` in their workflows
-- **Event payload**: Custom events can pass structured data to hook handlers via JSON payload
+A hook is a single canonical artifact: one event fires one agent, optionally narrowed by conditions. The fields below are the complete config that adapters honor today (`src/hooks/types.ts` `HookDefinition` + `HookCondition`):
 
-### Custom Event Definition
+| Field | Required | Meaning |
+|-------|----------|---------|
+| `id` | yes | Unique hook identifier (sanitized for shell safety). |
+| `event` | yes | Lifecycle event from the events table in Step 2a. |
+| `agent` | yes | Agent ID dispatched when the event fires. |
+| `description` | yes | Human-readable purpose. |
+| `globs` | no | File glob patterns — hook fires only when matching files are affected. |
+| `branches` | no | Branch name patterns — hook fires only on matching branches. |
+| `labels` | no | Issue/PR labels — hook fires only when matching labels are present. |
 
-In `hatch.json`:
-
-```json
-{
-  "hooks": {
-    "customEvents": [
-      {
-        "name": "custom:billing:subscription-change",
-        "description": "Fired when a subscription plan changes",
-        "payload": { "userId": "string", "oldPlan": "string", "newPlan": "string" }
-      }
-    ]
-  }
-}
-```
-
-Custom events follow the same hook definition format as built-in events — create a hook file in `.agents/hooks/` with `event: custom:{domain}:{action}`.
-
----
-
-## Hook Chaining
-
-Hooks can trigger other hooks in sequence:
-
-- **Chain definition**: Define ordered hook chains in `hatch.json` under `hooks.chains`
-- **Execution order**: Hooks in a chain execute sequentially; failure in any hook stops the chain
-- **Error handling**: Chain-level error handlers can catch and handle failures from individual hooks
-- **Conditional chaining**: Hooks can conditionally trigger next hook based on output (pass/fail/skip)
-
-### Chain Definition
-
-In `hatch.json`:
-
-```json
-{
-  "hooks": {
-    "chains": [
-      {
-        "id": "pre-release-pipeline",
-        "description": "Full pre-release validation chain",
-        "steps": [
-          { "hook": "pre-release-security-auditor", "on_fail": "stop" },
-          { "hook": "pre-release-test-writer", "on_fail": "stop" },
-          { "hook": "pre-release-docs-writer", "on_fail": "warn" }
-        ],
-        "on_error": "notify"
-      }
-    ]
-  }
-}
-```
-
-Chains are triggered by referencing the chain ID as the hook target. Individual hook results (`pass`, `fail`, `skip`) determine whether the chain continues.
-
----
-
-## Hook Execution Ordering
-
-When multiple hooks are registered for the same event:
-
-- **Priority**: Hooks have a priority field (1-100, lower runs first, default 50)
-- **Parallel vs Sequential**: Hooks at the same priority level run in parallel; different priority levels run sequentially
-- **Timeout**: Each hook has a configurable timeout (default 30 seconds). Timed-out hooks are reported as failures.
-- **Isolation**: Each hook runs in its own context. Hook outputs are collected but don't affect other hooks unless chained.
-
-### Priority Configuration
-
-Add `priority` and `timeout` to hook frontmatter:
-
-```markdown
----
-id: my-pre-commit-lint-fixer
-type: hook
-event: pre-commit
-agent: lint-fixer
-priority: 10
-timeout: 60
----
-```
-
-### Execution Example
-
-For `pre-commit` with three hooks:
-1. `lint-fixer` (priority 10) — runs first
-2. `security-auditor` (priority 20) — runs second
-3. `test-writer` (priority 50) and `reviewer` (priority 50) — run in parallel, third
-
----
+There is no chaining, custom-event, priority, timeout, or parallel-by-priority config: each hook is independent, the adapter emits one tool-native entry per hook, and ordering across multiple hooks on the same event is the tool's own (Claude Code stacks matcher entries; Cursor stacks `.cursor/hooks.json` entries). Do not author `hooks.chains`, `hooks.customEvents`, `emit-hook`, `priority:`, or `timeout:` — no code consumes them.
 
 ## Error Handling
 
-- `.agents/hooks/` doesn't exist: create it automatically.
+- `hooks/` doesn't exist: create it automatically.
 - Invalid event type: warn and show the valid events table.
-- Agent not found in `.agents/agents/`: warn but allow (agent may be added later).
+- Agent not found in `agents/`: warn but allow (agent may be added later).
 - Adapter doesn't support hooks: generate hook definition file anyway, warn that sync for that tool is a no-op.
 - Duplicate hook ID: warn and ask the user to choose a different name or overwrite.
 
@@ -297,5 +208,5 @@ For `pre-commit` with three hooks:
 - Never delete hook files without explicit user confirmation.
 - Always validate event names against the known events list.
 - Hook IDs must be unique across all hook definitions.
-- The command creates hook DEFINITIONS only — actual hook registration happens via `npx hatch3r sync`.
+- The skill creates hook DEFINITIONS only — actual hook registration happens via `npx hatch3r sync`.
 - Do not modify adapter output files directly — they are managed by the sync pipeline.

package/dist/content/skills/hatch3r-incident-response/SKILL.md

@@ -0,0 +1,174 @@
+---
+id: hatch3r-incident-response
+name: hatch3r-incident-response
+type: skill
+description: Handles production incidents with structured triage, mitigation, and post-mortem. Use when responding to production issues, outages, or security incidents.
+tags: [devops]
+quality_charter: agents/shared/quality-charter.md
+efficiency_patterns: agents/shared/efficiency-patterns.md
+cache_friendly: true
+---
+# Incident Response Workflow
+
+## Relationship to `commands/hatch3r-incident-response.md` (Decision 13 handoff)
+
+This skill shares the `id: hatch3r-incident-response` with the orchestrator command `commands/hatch3r-incident-response.md`. The two are NOT duplicates — they split the incident workflow by execution model per CONSTITUTION §6 Decision 13:
+
+- **`commands/hatch3r-incident-response.md` (orchestrator entry):** the delegated live-incident pipeline — a hatch3r-incident-responder specialist drives triage → bounded-autonomy mitigation → communication → blameless post-mortem, and a hatch3r-reliability specialist runs the post-incident telemetry/SLO reconstruction in parallel once stabilized (`agentPipeline: [hatch3r-incident-responder, hatch3r-reliability]`). Use the command for a live production incident that warrants specialist fan-out (parallel mitigation + reliability reconstruction); a security-suspected incident adds hatch3r-security.
+- **This skill (inline procedure):** the single-pass reference body the responder follows for the classify → topology → triage → mitigate → root-cause → post-mortem sequence. Use the skill directly for a Tier 1 single-service incident where no fan-out is needed, OR as the step-by-step procedure the command's incident-responder stage executes.
+- **Unique to this skill:** the Bounded Autonomy & Escalation matrix (auto-action vs human-gate threshold by severity) and the Telemetry Sources adapter (signal-by-capability-class) are the inline-procedure detail the command references rather than restates.
+
+The merge-candidate review (F16.3-H3) flagged the shared id; this handoff documentation is the explicit workflow-split declaration that disambiguates the pair, enforced by the Decision-13 command↔skill gate in `src/cli/commands/validate.ts`. A future collapse into a single command appendix requires coordinated edits to the command body, the bundled content inventory (skills count), and that gate.
+
+## Quick Start
+
+```
+Task Progress:
+- [ ] Step 0: Detect ambiguity (P8 B1)
+- [ ] Step 1: Classify severity (P0-P3) based on impact
+- [ ] Step 1b: Capture topology context — impacted service graph + upstream/downstream deps
+- [ ] Step 2: Triage — identify affected systems, user impact, blast radius
+- [ ] Step 3: Mitigate — apply hotfix or rollback, verify mitigation works
+- [ ] Step 4: Root cause analysis — trace the failure chain
+- [ ] Step 5: Write post-mortem with timeline, root cause, action items
+- [ ] Step 6: Create follow-up issues for permanent fixes and preventive measures
+```
+
+Two policies bound this workflow before any remediation action runs: the **Bounded Autonomy & Escalation** matrix (which actions auto-execute vs require a human gate, by severity) and the **Telemetry Sources** adapter (where to read signal, by capability class). Both are defined below; read them before Step 3.
+
+## Step 0 — Detect Ambiguity (P8 B1)
+
+Before any work, scan the invocation for unresolved questions in scope, intent, acceptance criteria, target environment, or irreversibility. If any are found, ask the user via the platform-native question tool per `agents/shared/user-question-protocol.md`. Do not proceed under silent assumption. Default path, not an exception. Triggers for THIS skill: user-facing impact vs internal-only, blast radius known (single tenant vs all users), rollback safety verified, stakeholder notification scope (engineering vs exec vs public), and whether mitigation requires data write (irreversible) vs config flip (reversible).
+
+## Fan-out Discipline (P8 B2)
+
+Fan-out scales with task size; token cost never justifies serializing independent work (`rules/hatch3r-fan-out-discipline.md` P8 B2; `agents/shared/efficiency-patterns.md`). Emit `sub_agents_spawned: { count, rationale }` in your output.
+
+## Bounded Autonomy & Escalation
+
+An agent acting in a live incident operates under bounded autonomy: actions are bounded, reversible-first, and gated on a human-in-the-loop for high-blast-radius severities. This matrix sets the auto-action vs escalation threshold by severity. Match the row to the severity assigned in Step 1.
+
+| Severity | Autonomy bound | Required gate before action |
+| -------- | -------------- | --------------------------- |
+| P0 | No autonomous mutation. Investigate, build the timeline, propose a diff — do not apply. | Human approval required before any mitigation. Page on-call; do not self-execute. |
+| P1 | Confidence-routed. High-confidence reversible action (flag flip, scale-up, documented rollback) may auto-apply WITH a diff preview emitted first; low-confidence or irreversible action escalates. | Human gate when confidence is medium/low OR the action writes data / is irreversible. |
+| P2 | Auto-remediation acceptable for reversible actions with a diff preview emitted before apply. | Human gate only for irreversible (data-write, schema, destructive) actions. |
+| P3 | Auto-remediation acceptable. | None for reversible actions; flag irreversible actions for review. |
+
+Rules that hold across all rows:
+
+- **Reversibility-first.** Prefer the reversible mitigation (feature-flag flip, config revert, scale-up, deploy rollback) over an irreversible one (data write, schema change). An irreversible action escalates one severity band on the gate column.
+- **Diff preview before apply.** Any auto-applied mutation emits the exact change (command, flag, config delta) before execution, never after.
+- **Confidence routing.** State confidence (high/medium/low per `agents/shared/quality-charter.md` section 1) on every proposed mitigation. Medium/low confidence on P1 routes to a human gate.
+- **Audit trail.** Every action (auto or gated) is recorded in the incident timeline (Step 5) with actor, timestamp, and the gate decision.
+
+## Telemetry Sources
+
+Capture signal from the project's observability stack before declaring blast radius (Step 1b) and when verifying mitigation (Step 3). Read the configured stack from project conventions; do not assume a vendor. Adapter patterns by capability class:
+
+| Capability class | What to read | Common providers |
+| ---------------- | ------------ | ---------------- |
+| Distributed traces | Request path spans, `trace_id`/`span_id` correlation, latency percentiles | OpenTelemetry-compatible backend, Datadog APM, Grafana Tempo |
+| Metrics (RED/USE) | Rate, Errors, Duration per route; Utilization, Saturation, Errors per resource | Prometheus/Grafana, CloudWatch, Datadog |
+| Logs | Structured JSON with `trace_id`, service+version+environment, error-level stack traces | Splunk, CloudWatch Logs, Loki |
+| Error tracking | Grouped exceptions with release + environment tags | Sentry-class tracker |
+| Deploy/change history | Recent deploys, config changes, dependency bumps correlated to incident start | Platform CLI (`gh`/`az`/`glab`), CI deploy log |
+
+Reference `rules/hatch3r-observability-tracing.md` and `rules/hatch3r-observability-logging.md` for the end-user instrumentation floor these sources read from. When a capability class is not instrumented in the project, record the gap as a post-mortem action item rather than assuming data exists.
+
+## Step 1: Classify Severity
+
+| Severity | Definition                                  | Examples                                     |
+| -------- | ------------------------------------------- | -------------------------------------------- |
+| P0       | Complete outage, data loss, security breach | App unusable, auth down, data exposed        |
+| P1       | Major degradation, significant user impact  | Sync failing, billing broken, >1% error rate |
+| P2       | Partial degradation, limited impact         | Single flow broken, slow performance       |
+| P3       | Minor issue, workaround available            | Cosmetic bug, edge case                     |
+
+- Check for related issues or prior incidents using the platform tools (check `platform` in `.hatch3r/hatch.json`):
+  - **GitHub:** Use **GitHub MCP** (`issue_read`, `search_issues`) or `gh issue list --search "..."`
+  - **Azure DevOps:** `az boards query --wiql "SELECT [System.Id] FROM WorkItems WHERE [System.Title] CONTAINS '...'"` or `az boards work-item show --id N`
+  - **GitLab:** `glab issue list --search "..."` or `glab issue view N`
+- For external library docs and current best practices, follow the project's tooling hierarchy.
+
+## Step 1b: Capture Topology Context
+
+Before declaring blast radius in Step 2, map the impacted service graph. A correct blast-radius estimate depends on knowing what the failing component talks to — upstream callers amplify user impact, downstream dependencies are candidate root causes.
+
+1. **Identify the impacted node(s):** which service, function, or resource is emitting the failure signal (from the Telemetry Sources above).
+2. **Trace upstream:** which services/clients call the impacted node? These define the user-facing blast radius — a failure in a shared dependency fans out to every caller.
+3. **Trace downstream:** which dependencies does the impacted node call (database, queue, third-party API, RPC peer)? A downstream failure is a candidate root cause, not a symptom site.
+4. **Record the graph:** capture the upstream/downstream edges (from distributed traces, a service catalog, or an architecture ADR in project docs) before estimating blast radius. If no service map exists, reconstruct it from trace spans and note the absence as a post-mortem action item.
+
+Output a one-line topology summary: `impacted: {node} | upstream callers: {list} | downstream deps: {list}`. Step 2 blast-radius estimation consumes this directly.
+
+## Step 2: Triage
+
+- **Affected systems:** Frontend, backend, database, auth, payment, third-party services?
+- **User impact:** How many users? Which flows? Which plans (free/paid)?
+- **Blast radius:** Is the issue contained or spreading?
+- **Data:** Any data corruption, loss, or exposure? Check project privacy/security specs for implications.
+- **Timeline:** When did it start? Any recent deploys, config changes, or dependency updates?
+
+## Step 3: Mitigate
+
+- **Immediate actions:** Rollback last deploy, disable feature flag, revert config, scale up, or apply hotfix.
+- **Verification:** Confirm mitigation works — error rate drops, affected flow recovers.
+- **Communication:** Notify stakeholders per the page-target SLA below. Document status in incident channel or issue.
+  - Default page-target by severity (tune per org): P0 — page on-call ≤5 min after detection; P1 — ≤15 min; P2 — ≤1 h; P3 — next business day.
+- Do not spend time on perfect fixes during active incident — stabilize first.
+
+## Step 4: Root Cause Analysis
+
+- Trace the failure chain: what changed, what failed, why.
+- Review logs (correlationId, userId), metrics, deploy history.
+- Check ADRs in project docs for architectural context.
+- For external library docs and current best practices, follow the project's tooling hierarchy.
+
+## Step 5: Post-Mortem
+
+Write a structured post-mortem document:
+
+- **Summary:** One-paragraph description of the incident.
+- **Timeline:** Key events (detection, mitigation, resolution) with timestamps.
+- **Root cause:** What went wrong and why.
+- **Impact:** Users affected, duration, business impact.
+- **Action items:** Permanent fixes, preventive measures, process improvements.
+- **Lessons learned:** What we'll do differently.
+
+Store in project incident docs or as an issue/wiki page on the platform. Follow project conventions.
+
+## Step 6: Follow-Up Issues
+
+- Create follow-up issues/work items for each action item from the post-mortem (check `platform` in `.hatch3r/hatch.json`):
+  - **GitHub:** `gh issue create --title "..." --body "..." --label "incident-follow-up"` (or use **GitHub MCP** `issue_create`)
+  - **Azure DevOps:** `az boards work-item create --type "Bug" --title "..." --description "..." --fields "System.Tags=incident-follow-up"`
+  - **GitLab:** `glab issue create --title "..." --description "..." --label "incident-follow-up"`
+- Label appropriately (e.g., `incident-follow-up`, `P0`, `P1`).
+- Link issues/work items to the post-mortem and to each other.
+- Assign owners and due dates for critical fixes.
+
+## Error Handling
+
+- **Cannot reproduce the incident locally**: Use production logs and traces to build the timeline. If local reproduction is blocked by environment differences, document the gap and recommend a staging environment test.
+- **Mitigation introduces new issues**: Roll back the mitigation immediately, reassess the approach, and apply a more targeted fix. Document both the original incident and the mitigation regression in the post-mortem.
+- **Root cause spans multiple services or teams**: Document the cross-service dependency chain, assign follow-up items to the responsible teams, and coordinate a joint post-mortem.
+
+## Definition of Done
+
+- [ ] Incident mitigated and verified
+- [ ] Post-mortem written with timeline, root cause, and action items
+- [ ] Follow-up issues created for permanent fixes and preventive measures
+- [ ] Stakeholders notified (if P0/P1)
+- [ ] No sensitive data (secrets, PII, code content) in post-mortem or logs
+
+## Additional Resources
+
+- Privacy/security specs: project documentation
+- Observability: project logging and correlation conventions
+- Error handling: project error handling patterns
+
+## References
+
+- [Managing Incidents — Google SRE Book, ch. 14](https://sre.google/sre-book/managing-incidents/) — accessed 2026-05-31, official-docs (Google SRE). Source for the severity-tiered incident command structure and the timeline / post-mortem discipline in Steps 1–5.
+- [Monitoring distributed systems (RED / USE / four golden signals) — Google SRE Book, ch. 6](https://sre.google/sre-book/monitoring-distributed-systems/) — accessed 2026-05-31, official-docs (Google SRE). Source for the RED/USE metric classes in the Telemetry Sources adapter and the blast-radius signal capture in Step 1b.

package/{skills → dist/content/skills}/hatch3r-issue-workflow/SKILL.md

@@ -1,7 +1,9 @@
 ---
 id: hatch3r-issue-workflow
+name: hatch3r-issue-workflow
+type: skill
 description: Guides the 8-step agentic development workflow for issues/work items. Covers parsing issues, loading skills, reading specs, planning, implementing, testing, opening PRs/MRs, and addressing review. Use when working on any issue/work item or when the user mentions an issue number.
-tags: [core, implementation]
+tags: [implementation, orchestration]
 quality_charter: agents/shared/quality-charter.md
 efficiency_patterns: agents/shared/efficiency-patterns.md
 cache_friendly: true
@@ -10,7 +12,7 @@ cache_friendly: true
 
 ## Quick Start
 
-When assigned an issue or work item (GitHub Issue, Azure DevOps Work Item, or GitLab Issue — check `platform` in `.agents/hatch.json`), follow these 8 steps in order:
+When assigned an issue or work item (GitHub Issue, Azure DevOps Work Item, or GitLab Issue — check `platform` in `.hatch3r/hatch.json`), follow these 8 steps in order:
 
 ```
 Task Progress:
@@ -108,8 +110,8 @@ Skip this step if the issue has no user-facing UI changes.
 
 - Use the project's PR/MR template. Fill every section.
 - Link to the issue/work item. Include plan, implementation summary, test evidence.
-- **Base branch:** Use `board.defaultBranch` from `.agents/hatch.json` (fallback: `"main"`).
-- Open a code review using the platform CLI (check `platform` in `.agents/hatch.json`):
+- **Base branch:** Use `board.defaultBranch` from `.hatch3r/hatch.json` (fallback: `"main"`).
+- Open a code review using the platform CLI (check `platform` in `.hatch3r/hatch.json`):
   - **GitHub:** `gh pr create --base {defaultBranch} --head {branch} --title "..." --body "..."`
   - **Azure DevOps:** `az repos pr create --source-branch {branch} --target-branch {defaultBranch} --title "..." --description "..."`
   - **GitLab:** `glab mr create --source-branch {branch} --target-branch {defaultBranch} --title "..." --description "..."`
@@ -121,6 +123,15 @@ Skip this step if the issue has no user-facing UI changes.
 - Push fixes as new commits (don't force-push during review).
 - Re-request review after addressing all comments.
 
+## Fan-out Discipline (P8 B2)
+
+Fan-out scales with task size; token cost never justifies serializing independent work (`rules/hatch3r-fan-out-discipline.md` P8 B2; `agents/shared/efficiency-patterns.md`). Tier boundaries for THIS skill:
+- Tier 1 (trivial single-file issue): inline.
+- Tier 2 (multi-file or multi-concern issue): spawn parallel sub-agents per concern (researcher, implementer, reviewer) via the Task tool.
+- Tier 3 (multi-module / high-risk issue): one fresh sub-agent per independent module or gate; orchestrator integrates only.
+
+Emit `sub_agents_spawned: { count, rationale }` in your output.
+
 ## Error Handling
 
 - **Issue description is too vague to implement**: Do not guess. Ask the user for clarification on acceptance criteria, scope boundaries, and expected behavior before starting Step 3 (planning).