Continuous improvement opex

Skill Sofigf/continuous-improvement-opex

Install

npx -y skills add Sofigf/continuous-improvement-opex

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

3 things to look at

19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Complete Continuous Improvement (CI) / Operational Excellence (OpEx) toolkit covering Lean Six Sigma belt levels (White, Yellow, Green, Black), Root Cause Analysis (RCA) with Fishbone/Ishikawa, 5 Why, Pareto, FMEA, plus DMAIC, PDCA 8 langkah, QCC (Quality Control Circle), Kaizen, 5S, OEE, and VSM. Use this skill whenever the user mentions continuous improvement, operational excellence, lean six sigma, any belt level, RCA, root cause, fishbone, ishikawa, 5 why, why-why analysis, DMAIC, PDCA, QCC, gugus kendali mutu, kaizen, improvement project, quality problem solving, defect analysis, waste reduction, A3 report, risalah QCC, or asks to analyze a production/quality/process problem to find its root cause — even if they don't name a specific tool.

SKILL.md

7.2 KB, as published. Nobody here has run it

Continuous Improvement / Operational Excellence

Toolkit lengkap untuk pekerjaan Continuous Improvement dan Operational Excellence: problem solving terstruktur, Root Cause Analysis, proyek improvement (DMAIC/PDCA/QCC), materi training belt, dan coaching pemilihan metodologi.

Language rule (penting)

Follow the user's language. Jika user menulis dalam Bahasa Indonesia, jawab dalam Bahasa Indonesia; if in English, answer in English. Istilah teknis baku (DMAIC, Fishbone, Cp/Cpk, OEE, takt time) boleh tetap dalam bahasa aslinya di kedua bahasa. Untuk konteks Indonesia, kenali istilah lokal: GKM (Gugus Kendali Mutu) = QCC, "risalah" = laporan/dokumentasi QCC, "delapan langkah tujuh alat" (8L7A) = PDCA 8 langkah + 7 QC tools.

How to route the request

Identify what the user actually needs, then read the matching reference file. Do not load all references — only what the task requires.

User needs	Read	Typical trigger phrases
Find root cause of a problem	`references/rca-tools.md`	"kenapa defect naik", "analisa akar masalah", "fishbone", "5 why", "RCA"
Run/document a full improvement project	`references/methodologies.md`	"proyek DMAIC", "QCC", "PDCA", "improvement project", "risalah"
Training material for a belt level	`references/belts.md`	"materi white belt", "training yellow belt", "silabus green belt"
Choose the right tool/methodology	`references/belts.md` + this file's decision guide below	"sebaiknya pakai apa", "DMAIC atau PDCA?", "tools apa yang cocok"
Lean tools (5S, OEE, VSM, SMED, Kaizen, TPM)	`references/lean-tools.md`	"hitung OEE", "implementasi 5S", "value stream mapping", "waste"
Produce a formal document (A3, risalah QCC, charter, FMEA table)	`references/templates.md`	"buatkan A3", "format risalah", "project charter", "laporan QCC"

Multiple needs in one request are common (e.g., "analisa masalah ini lalu buatkan risalah QCC" → rca-tools.md + templates.md). Read both.

Core working principles

These apply to every CI/OpEx task regardless of tool:

Data before opinion. Always ask for (or work from) actual data: defect counts, downtime minutes, reject rate, periods. If the user gives no data, proceed with their qualitative description but explicitly flag which conclusions need data validation and suggest what to measure. Never invent numbers.
Problem statement first. Before any analysis, restate the problem in measurable terms: what, where, when, how much, versus what baseline/target (4W + gap). A vague problem ("kualitas jelek") must be sharpened ("reject rate ribbon coding line 2 naik dari 1,2% ke 3,5% sejak minggu ke-3 Juni").
Root cause ≠ symptom ≠ blame. A valid root cause is something that, if removed, prevents recurrence; it is within the organization's control; and it is verified (or verifiable) with evidence. "Operator kurang teliti" is almost never a root cause — dig into why the process allows the error (missing standard, no poka-yoke, unclear visual control).
Distinguish correction, corrective action, and preventive action. Correction fixes the defect instance; corrective action removes the root cause; preventive action stops similar problems elsewhere. Improvement projects need at least corrective action.
Countermeasures must map to root causes. Every proposed action should trace to a specific verified cause. Actions that don't map to a cause are scope creep.
Standardize or it didn't happen. Every improvement ends with standardization (update SOP/OPL/control plan) and a control mechanism, otherwise results decay.
Scale to the problem. A simple recurring defect needs 5 Why + quick countermeasure, not a 6-month Black Belt project. Use the decision guide below.

Decision guide: which methodology?

Just-do-it / Kaizen teian: cause is obvious, solution is cheap and low-risk. No formal project needed — but still document briefly.
PDCA 8 langkah / QCC: recurring operational problem, solvable by a small cross-functional or single-department team using 7 QC tools, timeframe weeks–3 months. Standard for shop-floor improvement in Indonesian manufacturing (and QCC competitions).
DMAIC: cause unknown, data-heavy, needs statistical analysis, cross-functional, high impact, timeframe 3–6 months. Green/Black Belt territory.
DMADV/DFSS: designing a new process/product, not fixing an existing one.
Kaizen event / blitz: focused 3–5 day workshop on a bounded area (changeover, layout, 5S).
A3 thinking: works as the documentation/communication layer over PDCA or DMAIC — one-page storytelling.

When the user asks "sebaiknya pakai apa", ask (or infer) three things: is the cause known? is data available? how big is the impact/scope? Then recommend, with the reason.

Quality bar for outputs

Fishbone diagrams: causes must be specific and verifiable, not category labels. "Suhu ruang tidak terkontrol (28–34°C, spec 25±2°C)" ✓; "Lingkungan" as a cause ✗ (that's the bone name).
5 Why chains: each "why" must be a causal answer to the previous line, checkable by reading bottom-up with "therefore". Stop when you reach a process/system cause the team can act on — typically 3–5 levels, not mechanically five.
Pareto: always compute cumulative %, identify the vital few (~80%), and state the conclusion in words.
Any recommendation: include PIC placeholder, due date placeholder, and how effectiveness will be verified (metric + target + when to check).
When producing visual diagrams (fishbone, pareto chart) in chat, use the visualization capability if available; for documents, follow references/templates.md.

Reference files

references/rca-tools.md — All RCA tools: Fishbone step-by-step, 5 Why, Why-Why tree, Pareto, FMEA, Is/Is-Not (Kepner-Tregoe), fault tree, 7 QC tools, cause verification methods
references/methodologies.md — DMAIC phase-by-phase with deliverables and tollgates; PDCA 8 langkah / QCC full workflow incl. risalah structure; Kaizen event agenda
references/belts.md — Belt level curriculum (White/Yellow/Green/Black/MBB): scope, tools mastered per level, training material outlines, exam/exercise ideas, tool-selection coaching
references/lean-tools.md — 5S, 8 wastes, OEE calculation, VSM, SMED, TPM, standard work, visual management, poka-yoke
references/templates.md — Ready-to-fill formats: A3, risalah QCC (8 langkah), project charter, SIPOC, FMEA table, 5W1H action plan, control plan