continuous-improvement
Skill1 starsChanged 2 months agoApache-2.0View on GitHub
Turns repeated mistakes, costly failures, and recurring review findings into durable engineering safeguards. Use when a failure class should be prevented by a test, check, script, skill, concise rule, documentation change, or other maintainable control.
We split this skill into the rules it gives an agent
6 rules. 0 are common, 6 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
6
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 10
Use this procedure when a failure class repeats, a costly incident exposes a missing safeguard, or recurring manual review reveals a …
- Distinctive: line 19
Prefer mechanisms that fail clearly and mechanically over reminders that require repeated model or human judgment.
- Distinctive: line 21
Keep narrow or infrequent procedures out of always-on context when an on-demand skill or deterministic check is sufficient.
- Distinctive: line 23
Keep project-specific lessons in the project.
- Distinctive: line 25
Before adding a new safeguard, check whether an existing test, rule, skill, script, or document should be extended instead.
- Distinctive: line 27
Verify that the proposed safeguard would have prevented, detected, or made the original failure materially easier to diagnose without …
“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Continuous improvement
Use this procedure when a failure class repeats, a costly incident exposes a missing safeguard, or recurring manual review reveals a preventable source of engineering risk.
- Describe the general failure class and its impact rather than preserving only the details of one incident.
- Determine why existing safeguards did not prevent, detect, or clearly explain the failure.
- Choose the smallest durable prevention or detection mechanism that reliably addresses the failure. Prefer, when appropriate: deterministic test or invariant → static or runtime check → script or hook → focused skill → concise always-on rule → documentation.
- Prefer mechanisms that fail clearly and mechanically over reminders that require repeated model or human judgment.
- Keep narrow or infrequent procedures out of always-on context when an on-demand skill or deterministic check is sufficient.
- Keep project-specific lessons in the project. Promote a lesson into shared engineering guidance only when the failure class is genuinely reusable across unrelated projects and technologies.
- Before adding a new safeguard, check whether an existing test, rule, skill, script, or document should be extended instead. Merge or remove duplicated guidance when practical.
- Verify that the proposed safeguard would have prevented, detected, or made the original failure materially easier to diagnose without imposing disproportionate friction on unrelated work.
- Record how the safeguard itself can be maintained, tested, or removed if its underlying risk disappears.
The goal is continuous reduction of repeated engineering failure, not accumulation of process artifacts.
Report the failure class, chosen safeguard, why that layer is appropriate, evidence that it addresses the problem, and any added maintenance cost.
Other versions5 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 5
- l-gevity/l-gevity-skills★ 72same name
- muyen/vibe-to-prod★ 34same name
- naimkatiman/continuous-improvement★ 9same name
- kaka-ruto/skills★ 4same name
- Abdox-menara/guard-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository16 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- automation-cost-controlSkill
- backup-and-recovery-reviewSkill
- calculation-model-validationSkill
- change-reviewSkill
- compatibility-and-rolloutSkill
- cross-surface-consistencySkill
- delegation-strategySkill
- dependency-changeSkill
- documentation-syncSkill
- environment-release-safetySkill
- high-risk-change-reviewSkill
- interface-qaSkill
- root-cause-debugSkill
- secret-exposure-responseSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.