skills/magnus919_agent-skills

Fork 0

mirror of https://github.com/magnus919/agent-skills.git synced 2026-09-11 19:47:12 +03:00

Files

T

4f14ce3df6 feat(incident-learning): add incident-learning skill (#226 )

Create incident-learning skill that converts operational incident and
near-miss evidence into verified, owned improvements across product,
code, tests, evals, operations, and governance domains.

- SKILL.md: progressive disclosure with loading guide, routing table,
  ownership boundaries, and core principles (evidence/inference/
  uncertainty separation, ticket-closure rejection, no-blame design)
- README.md: human-facing with all 5 required sections
- references/discovery-brief.md: bounded survey comparing SRE, QA,
  verification, agent-evals, product-lifecycle-learning,
  implementation-planning, resilience-and-recovery, production-readiness
- references/: evidence/inference taxonomy, escaped-from analysis,
  follow-up domains, verification and closure standard
- templates/: incident-learning record, causal/evidence ledger,
  follow-up work map, verification and closure record
- evals/evals.json: 5 schema-valid cases (noisy report, monitoring gap,
  process failure, agent authority failure, non-actionable rejection)
- Regenerated catalogs and updated root README and skill-triggers

Closes #200

Co-authored-by: username <username>
Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>

2026-08-02 18:44:36 -04:00

4.0 KiB

Raw Blame History

Incident-Learning Record

Use this template to structure an incident into a learning record. The record separates observed facts from causal hypotheses and unresolved uncertainty, maps escaped-from gaps, and links to the follow-up work map.

Incident identifier

Field	Value
Incident ID
Title
Date
Duration
Severity
Systems affected
Services affected
User impact
Detection method	(alert, user report, manual observation, exercise finding)
Postmortem reference	(link to the blameless postmortem, if one exists)

Observed facts

What happened — backed by telemetry, logs, direct observation, or reproducible measurement. Every fact must have a named source. No interpretation, no inference, no blame.

#	Fact	Source	Timestamp / time range
1
2
3

Causal hypotheses

Inferences about why the incident occurred. Each hypothesis must be labeled with confidence and at least one alternative explanation.

#	Hypothesis	Supporting evidence (fact #s)	Confidence	Alternative explanations	Testability
1			(high/medium/low)
2

Confidence level guide:

High: supported by multiple independent evidence sources; alternatives ruled out; causal mechanism well-understood.
Medium: supported by some evidence; alternatives plausible but less consistent.
Low: consistent with evidence but not strongly supported; alternatives equally plausible; mechanism speculative.

Contributing conditions

System states, process gaps, environmental factors that enabled or amplified the incident — without necessarily causing it.

#	Condition	How it contributed	Related hypotheses
1
2

Unresolved uncertainty

Open questions, competing hypotheses, missing data, and unknowns. Every uncertainty must state why it matters and what would resolve it.

#	Uncertainty	Why it matters	What would resolve it	Status
1				(open / investigating / cannot resolve)
2

Escaped-from mapping

What gap allowed this incident to reach production or users? Map each gap to one or more categories.

#	Gap description	Escaped-from category	How it contributed	Follow-up domain
1		(escaped requirement / missing monitoring / unsafe authority / migration gap / adoption consequence)		(product / code / tests / evals / operations / governance)
2

Escaped-from categories:

Escaped requirement: A needed requirement was absent, incomplete, or incorrectly specified.
Missing monitoring or observability: No signal existed to detect the condition.
Unsafe authority or access: Insufficient guardrails on who could act or what actions were permitted.
Migration gap: A transition introduced or exposed the condition.
Adoption consequence: User or operator behavior contributed to the incident.

Follow-up work map

Link to the follow-up work map. Every significant finding maps to at least one follow-up item with an owner, domain, and verification method.

Follow-up work map reference: (link or reference to the follow-up work map document)

Finding	Domain	Description	Owner	Target date	Verification method	Status

Verification and closure summary

Follow-up ID	Status	Implementation evidence	Verification evidence	Effect evidence	Closure date

Closure states: Verified closed / Verified closed — effect pending / Rejected / Superseded / Open

Record metadata

Field	Value
Record author
Record date
Last updated
Reviewers
No-blame attestation	This record contains no blame assignment. Findings describe system outcomes, not individual failures.

4.0 KiB Raw Blame History