| name | kaizen-improvement-system |
| description | Use when auditing or improving this engineering engine or a product it produces. Coordinates evidence-backed baselines, small experiments, standardisation, and re-audits without replacing domain skills. |
| metadata | {"portable":true,"compatible_with":["claude-code","codex"]} |
Kaizen Improvement System
Use this skill to turn observed defects, incidents, feedback, source changes,
or audit gaps into small, reversible, evidence-backed improvements. It keeps
domain judgement with the owning engine and makes learning discoverable.
Use When
- Auditing or grading the engineering catalogue or a product made with it.
- Turning defects, incidents, user feedback, or new evidence into a tested improvement.
- Planning a major iteration, quarterly engine review, or post-release re-audit.
Do Not Use When
- A single-skill safety review is the only task; use
skill-safety-audit.
- A current external claim is needed before source evaluation and verification.
- The proposed change is cosmetic and has no measurable effect on routing, quality, safety, or delivery.
Required Inputs
- Engine or product path, intended audience, output types, owner, and constraints.
- Current routes, references, tests, user or product evidence, and known failure modes.
- Baseline scoring method, improvement target, acceptance evidence, rollback condition, and re-audit date.
Prerequisites
- Read
docs/continuous-improvement/kaizen-adoption-2026-08.md.
- For portfolio or current-standards claims, use the Digital Research engine's source-evaluation and source-verification routes.
Workflow
- Observe. Inspect the real route, output, users, constraints, evidence, and failure mode.
- Baseline. Inventory applicable dimensions and score them with named evidence. Keep raw scores, blockers, uncertainty, and
NOT ASSESSED items visible. Publish the repository policy cap of min(raw_score, 65) for permanent audits.
- Select. Choose the smallest high-leverage root cause. Prefer repeated defects, user harm, safety issues, missing proof, and routing failures over added prose.
- Experiment. Name the exact skill, reference, fixture, validator, or gate; hypothesis; owner; measure; risk; rollback; stop condition; and re-audit date.
- Check. Re-run relevant validators, tests, source checks, user or product checks, and independent review. Preserve negative evidence.
- Standardise. Promote a successful result into the owning skill, reference, template, fixture, router, or release gate. Do not promote a one-off observation.
- Teach and re-measure. Update discoverability and handoffs, re-score the changed dimensions, and leave the next improvement visible.
Core content
For a product, assess the applicable combination of requirements, architecture
or document correctness, security and privacy, accessibility, reliability,
performance, user value, deployment or handoff, rollback, and evidence quality.
For an engine, assess doctrine, taxonomy and routing, skill depth, applied
proof, standards currency, output readiness, hygiene, safety, and integrity. For
client-facing web or dashboard work, also load
references/purpose-fit-premium-ux-implementation.md and require an implementation
slice that preserves the client's design thesis rather than copying a reference product.
Quality Standards
- Scores cite concrete evidence and a one-line deficiency statement.
- A target of 95/100 is an improvement target, not an achievement claim.
- Do not award 70+ without extraordinary, specific proof or claim production readiness without executable or rendered evidence.
- Structural, behavioural, render, system, and production evidence are labelled separately.
- Missing execution, source, approval, or artefact evidence is
NOT ASSESSED.
- A safety, legal, financial, privacy, security, or release blocker remains a blocker regardless of score.
- Lessons are stored only when repeatable, generalisable, significant, actionable, and likely to prevent recurrence.
Anti-Patterns
- Adding a skill without a demonstrated routing or ownership gap. Fix: inventory and test the collision first.
- Awarding a high score because headings or checkboxes exist. Fix: require outcome-level evidence.
- Treating a green unit or structural test as product proof. Fix: add the smallest relevant behavioural, failure, render, or handoff check.
- Closing an action because prose changed. Fix: close only when named acceptance evidence exists and a fresh agent can find the result.
- Hiding an unavailable check inside an overall score. Fix: mark it
NOT ASSESSED with an owner and date.
- Keeping every retrospective note forever. Fix: promote durable learning and remove redundant narrative.
- Treating a polished screenshot as a premium implementation. Fix: test real content, critical
states, responsive reflow, keyboard/focus, reduced motion, performance, and recovery.
- Copying a recognisable competitor surface. Fix: implement the user principle and the client's
visual thesis, then retain a rationale and originality review.
Outputs
| Artifact | Consumed by | Template |
|---|
| Capped scorecard and evidence register | Maintainer and reviewer | Kaizen adoption plan and local report |
| Improvement action record | Owner and implementer | Gap, root cause, change, hypothesis, measure, risk, rollback, evidence |
| Standardisation record | Future agents and router | Skill, reference, fixture, validator, or gate change |
| Re-audit handoff | Next reviewer | Date, owner, remaining gaps, and required checks |
Evidence Produced
| Category | Artifact | Format | Example |
|---|
| Correctness | Baseline and re-score | Markdown table | Raw dimensions, cap, blockers, and evidence |
| Security | Safety and integrity review | Markdown | Permission, provenance, and harmful-output findings |
| Operability | Rollback and re-audit handoff | Markdown | Owner, stop condition, recovery, and next date |
| Release evidence | Validator and test record | Command output or Markdown | Positive, negative, and unavailable checks |
Read next
skill-engine-audit for the engine rubric and evidence matrix.skill-safety-audit for changed or imported skill safety review.advanced-testing-strategy for risk-scaled validation.world-class-engineering for delivery gates and operational handoff.
Mandatory Digital Research currentness gate
Every Kaizen cycle must begin with digital-research-engine source evaluation
and source verification. Record scope, dates, freshness class, support status,
uncertainty, and review date for current standards, APIs, frameworks, packages,
security, platform, and lifecycle claims; quarantine unsupported claims as
NOT_ASSESSED. Apply the currentness gate at
C:/wamp64/www/digital-research-skills/docs/continuous-improvement/kaizen-currentness-gate.md.
References
docs/continuous-improvement/kaizen-adoption-2026-08.md - local adoption plan.C:/wamp64/www/digital-research-skills/docs/continuous-improvement/portfolio-kaizen-standard-2026-08.md - cross-engine standard.skills/sdlc-meta/skill-engine-audit/ - audit dimensions, scoring, and report structure.skills/sdlc-meta/skill-safety-audit/ - safety and source-ingestion gate.skills/sdlc-meta/kaizen-improvement-system/references/purpose-fit-premium-ux-implementation.md - implementation patterns for friction reduction, dashboards, state feedback, and authored visual systems.
Inputs
| Artefact | Produced by | Required? | Why |
|---|
| Engine or product path and output types | Router or task owner | yes | Fixes the audit boundary |
| Current evidence and failure history | Validators, tests, users, or operators | yes | Prevents opinion-only scoring |
| Target and constraints | Task owner | yes | Defines the experiment and rollback |
Capability contract
Read and search are required. Execution is preferred for validators and tests;
editing requires an authorised improvement scope. Without execution, report the
exact checks as NOT ASSESSED. Network research is optional and must use
source-disciplined routes.
Degraded mode
If a validator, source, user result, render, system environment, or independent
review is unavailable, keep the gap visible and state its consequence. Return a
conditional plan or verdict; never convert unavailable evidence into a pass.
Decision rules
| Condition | Action | Failure avoided |
|---|
| A repeated defect has a clear owning skill or gate | Patch that source of truth and add a focused regression check | Symptom-only fixes and recurrence |
| The proposed change adds only prose or a duplicate route | Do not change the catalogue; record the gap or route to the existing owner | Kaizen bloat and routing noise |
| The result changes a cross-engine handoff | Require source owner, receiving owner, artefacts, uncertainty contract, and fallback | Silent ownership drift |
| A material outcome, render, system, or production check cannot run | Mark it NOT ASSESSED and retain the blocker | False readiness |
| The experiment passes its acceptance evidence | Standardise the result and schedule re-measurement | Learning lost in a one-off patch |
The book-wave operating contract is book-driven system decision and agent orchestration. Current technology and security claims must pass Digital Research verification.
The 2026-09-02 cross-engine study is Book-driven Kaizen Wave 3; use it for currentness-gated contracts, testing, Git recovery, secure input handling, protocol semantics, and agent evaluation.
