kaizen-improvement-system

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

1. Observe. Inspect the real route, output, users, constraints, evidence, and failure mode.
2. 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.
3. Select. Choose the smallest high-leverage root cause. Prefer repeated defects, user harm, safety issues, missing proof, and routing failures over added prose.
4. Experiment. Name the exact skill, reference, fixture, validator, or gate; hypothesis; owner; measure; risk; rollback; stop condition; and re-audit date.
5. Check. Re-run relevant validators, tests, source checks, user or product checks, and independent review. Preserve negative evidence.
6. Standardise. Promote a successful result into the owning skill, reference, template, fixture, router, or release gate. Do not promote a one-off observation.
7. 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.