Claude Skill

hansei

Reflect on failures, incidents, reviews, and completed software work to turn evidence into durable tests, guardrails, documentation, and process improvements.

LLM Mart · 0 points · 0 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download kuya-egg-monozukuri-hansei-b4243fe.zip · 1 KB

kuya-egg/monozukuri 11 1 forks MIT Updated 9d ago

Part of kuya-egg/monozukuri — 13 skills

Install

skills CLI npx skills add https://github.com/kuya-egg/Monozukuri/tree/main/hansei

Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install kuya-egg-monozukuri@llmmart

Git git clone https://github.com/kuya-egg/Monozukuri.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole kuya-egg/monozukuri collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Hansei

Hansei is disciplined reflection. In software, examine what happened, why it happened, and how the system allowed it so the lesson becomes a durable improvement. This is a Japanese-inspired engineering metaphor, practiced without blame or ritual for its own sake.

Use this skill when

an incident, outage, regression, or escaped defect occurred;
a review found a recurring quality problem;
a release or project completed and important lessons should be preserved;
a workaround has become normal behavior; or
the team wants to improve its engineering system rather than only patch code.

Outcome

Produce a concise reflection with:

the observed impact and timeline;
contributing technical, process, and communication conditions;
what made detection, diagnosis, or recovery easier or harder;
what worked and should be preserved;
actionable improvements with owners or clear scope; and
a follow-up test, guardrail, document, signal, or process change.

Workflow

1. Establish the facts

Use logs, traces, tests, diffs, deployments, timelines, and direct reports. Separate what is known from what is inferred. Do not begin with blame or a preferred narrative.

2. Trace the system's contribution

Ask how the defect could be introduced, remain undetected, reach users, and persist. Look at missing tests, weak boundaries, confusing ownership, unsafe defaults, poor observability, rushed handoffs, and misleading documentation.

3. Preserve the good

Record the checks, habits, design choices, and response actions that reduced impact or sped recovery. Reflection should reinforce effective practice, not only list failure.

4. Choose durable actions

Prefer a small number of specific actions that change the system: a regression test, invariant, validation rule, alert, runbook, decision record, ownership boundary, or workflow improvement. Assign a clear completion condition.

5. Verify the lesson

Confirm that each important action would have prevented, detected, explained, or reduced the original problem. Remove vague actions that cannot be checked.

Evidence standard

Use a timeline and concrete artifacts where possible. Do not claim a root cause that the evidence cannot support. State uncertainty and residual risk plainly.

Boundaries

Do not use reflection to identify scapegoats.
Do not create a long report with no owner or completion condition.
Do not stop at “be more careful” when a mechanical guardrail is possible.
Do not reopen unrelated design debates unless the evidence connects them to the failure.
Do not treat a completed meeting as a completed improvement.

Handoff

Hand off concrete actions to poka-yoke, andon, kaizen, or shukka as appropriate. Revisit the reflection after actions land and verify that the original failure mode is now harder to repeat.

If a referenced skill is not installed, apply its named lens inline instead of trying to invoke it.

Files (monozukuri)

agents

openai.yaml 334 B

interface:
  display_name: "Hansei — Reflect and Learn"
  short_description: "Turn failures into durable improvements"
  brand_color: "#1F2937"
  default_prompt: "Use $hansei to turn this failure or completed task into concrete tests, guardrails, documentation, or process improvements."

policy:
  allow_implicit_invocation: false

SKILL.md 3.1 KB

---
name: hansei
description: "Reflect on failures, incidents, reviews, and completed software work to turn evidence into durable tests, guardrails, documentation, and process improvements."
---

# Hansei

Hansei is disciplined reflection. In software, examine what happened, why it
happened, and how the system allowed it so the lesson becomes a durable
improvement. This is a Japanese-inspired engineering metaphor, practiced
without blame or ritual for its own sake.

## Use this skill when

- an incident, outage, regression, or escaped defect occurred;
- a review found a recurring quality problem;
- a release or project completed and important lessons should be preserved;
- a workaround has become normal behavior; or
- the team wants to improve its engineering system rather than only patch code.

## Outcome

Produce a concise reflection with:

- the observed impact and timeline;
- contributing technical, process, and communication conditions;
- what made detection, diagnosis, or recovery easier or harder;
- what worked and should be preserved;
- actionable improvements with owners or clear scope; and
- a follow-up test, guardrail, document, signal, or process change.

## Workflow

### 1. Establish the facts

Use logs, traces, tests, diffs, deployments, timelines, and direct reports.
Separate what is known from what is inferred. Do not begin with blame or a
preferred narrative.

### 2. Trace the system's contribution

Ask how the defect could be introduced, remain undetected, reach users, and
persist. Look at missing tests, weak boundaries, confusing ownership, unsafe
defaults, poor observability, rushed handoffs, and misleading documentation.

### 3. Preserve the good

Record the checks, habits, design choices, and response actions that reduced
impact or sped recovery. Reflection should reinforce effective practice, not
only list failure.

### 4. Choose durable actions

Prefer a small number of specific actions that change the system: a regression
test, invariant, validation rule, alert, runbook, decision record, ownership
boundary, or workflow improvement. Assign a clear completion condition.

### 5. Verify the lesson

Confirm that each important action would have prevented, detected, explained,
or reduced the original problem. Remove vague actions that cannot be checked.

## Evidence standard

Use a timeline and concrete artifacts where possible. Do not claim a root cause
that the evidence cannot support. State uncertainty and residual risk plainly.

## Boundaries

- Do not use reflection to identify scapegoats.
- Do not create a long report with no owner or completion condition.
- Do not stop at “be more careful” when a mechanical guardrail is possible.
- Do not reopen unrelated design debates unless the evidence connects them to
  the failure.
- Do not treat a completed meeting as a completed improvement.

## Handoff

Hand off concrete actions to `poka-yoke`, `andon`, `kaizen`, or `shukka` as
appropriate. Revisit the reflection after actions land and verify that the
original failure mode is now harder to repeat.

If a referenced skill is not installed, apply its named lens inline instead of
trying to invoke it.