plan-do-check-act

Iterative PDCA cycle for systematic experimentation and continuous improvement

1,197
installs: 0 up / 0 down, score 0.00
votes: 1,783
repo stars
Updated: 2 months ago
In the catalog since: 5 Oct 2026
From: neolabhq/context-engineering-kit

Get it through your agent npx skills add neolabhq/context-engineering-kit@plan-do-check-act

Skill instructions

Rendered from the published SKILL.md, 251 lines.

Plan-Do-Check-Act (PDCA)

Apply PDCA cycle for continuous improvement through iterative problem-solving and process optimization.

Description

Four-phase iterative cycle: Plan (identify and analyze), Do (implement changes), Check (measure results), Act (standardize or adjust). Enables systematic experimentation and improvement.

Usage

/plan-do-check-act [improvement_goal]

Variables

GOAL: Improvement target or problem to address (default: prompt for input)
CYCLE_NUMBER: Which PDCA iteration (default: 1)

Steps

Phase 1: PLAN

Define the problem or improvement goal
Analyze current state (baseline metrics)
Identify root causes (use /why or /cause-and-effect)
Develop hypothesis: "If we change X, Y will improve"
Design experiment: what to change, how to measure success
Set success criteria (measurable targets)

Phase 2: DO

Implement the planned change (small scale first)
Document what was actually done
Record any deviations from plan
Collect data throughout implementation
Note unexpected observations

Phase 3: CHECK

Measure results against success criteria
Compare to baseline (before vs. after)
Analyze data: did hypothesis hold?
Identify what worked and what didn't
Document learnings and insights

Phase 4: ACT

If successful: Standardize the change
- Update documentation
- Train team
- Create checklist/automation
- Monitor for regression
If unsuccessful: Learn and adjust
- Understand why it failed
- Refine hypothesis
- Start new PDCA cycle with adjusted plan
If partially successful:
- Standardize what worked
- Plan next cycle for remaining issues

Examples

Example 1: Reducing Build Time

CYCLE 1
───────
PLAN:
  Problem: Docker build takes 45 minutes
  Current State: Full rebuild every time, no layer caching
  Root Cause: Package manager cache not preserved between builds
  Hypothesis: Caching dependencies will reduce build to <10 minutes
  Change: Add layer caching for package.json + node_modules
  Success Criteria: Build time <10 minutes on unchanged dependencies

DO:
  - Restructured Dockerfile: COPY package*.json before src files
  - Added .dockerignore for node_modules
  - Configured CI cache for Docker layers
  - Tested on 3 builds

CHECK:
  Results:
    - Unchanged dependencies: 8 minutes ✓ (was 45)
    - Changed dependencies: 12 minutes (was 45)
    - Fresh builds: 45 minutes (same, expected)
  Analysis: 82% reduction on cached builds, hypothesis confirmed

ACT:
  Standardize:
    ✓ Merged Dockerfile changes
    ✓ Updated CI pipeline config
    ✓ Documented in README
    ✓ Added build time monitoring
  
  New Problem: 12 minutes still slow when deps change
  → Start CYCLE 2


CYCLE 2
───────
PLAN:
  Problem: Build still 12 min when dependencies change
  Current State: npm install rebuilds all packages
  Root Cause: Some packages compile from source
  Hypothesis: Pre-built binaries will reduce to <5 minutes
  Change: Use npm ci instead of install, configure binary mirrors
  Success Criteria: Build <5 minutes on dependency changes

DO:
  - Changed to npm ci (uses package-lock.json)
  - Added .npmrc with binary mirror configs
  - Tested across 5 dependency updates

CHECK:
  Results:
    - Dependency changes: 4.5 minutes ✓ (was 12)
    - Compilation errors reduced to 0 (was 3)
  Analysis: npm ci faster + more reliable, hypothesis confirmed

ACT:

Show the whole skill (131 more lines)

Standardize: ✓ Use npm ci everywhere (local + CI) ✓ Committed .npmrc ✓ Updated developer onboarding docs

Total improvement: 45min → 4.5min (90% reduction) ✓ PDCA complete, monitor for 2 weeks


### Example 2: Reducing Production Bugs

CYCLE 1 ─────── PLAN: Problem: 8 production bugs per month Current State: Manual testing only, no automated tests Root Cause: Regressions not caught before release Hypothesis: Adding integration tests will reduce bugs by 50% Change: Implement integration test suite for critical paths Success Criteria: <4 bugs per month after 1 month

DO: Week 1-2: Wrote integration tests for: - User authentication flow - Payment processing - Data export Week 3: Set up CI to run tests Week 4: Team training on test writing Coverage: 3 critical paths (was 0)

CHECK: Results after 1 month: - Production bugs: 6 (was 8) - Bugs caught in CI: 4 - Test failures (false positives): 2 Analysis: 25% reduction, not 50% target Insight: Bugs are in areas without tests yet

ACT: Partially successful: ✓ Keep existing tests (prevented 4 bugs) ✓ Fix flaky tests

Adjust for CYCLE 2: - Expand test coverage to all user flows - Add tests for bug-prone areas → Start CYCLE 2

CYCLE 2 ─────── PLAN: Problem: Still 6 bugs/month, need <4 Current State: 3 critical paths tested, 12 paths total Root Cause: UI interaction bugs not covered by integration tests Hypothesis: E2E tests for all user flows will reach <4 bugs Change: Add E2E tests for remaining 9 flows Success Criteria: <4 bugs per month, 80% coverage

DO: Week 1-3: Added E2E tests for all user flows Week 4: Set up visual regression testing Coverage: 12/12 user flows (was 3/12)

CHECK: Results after 1 month: - Production bugs: 3 ✓ (was 6) - Bugs caught in CI: 8 (was 4) - Test maintenance time: 3 hours/week Analysis: Target achieved! 62% reduction from baseline

ACT: Standardize: ✓ Made tests required for all PRs ✓ Added test checklist to PR template ✓ Scheduled weekly test review ✓ Created runbook for test maintenance

Monitor: Track bug rate and test effectiveness monthly ✓ PDCA complete


### Example 3: Improving Code Review Speed

PLAN: Problem: PRs take 3 days average to merge Current State: Manual review, no automation Root Cause: Reviewers wait to see if CI passes before reviewing Hypothesis: Auto-review + faster CI will reduce to <1 day Change: Add automated checks + split long CI jobs Success Criteria: Average time to merge <1 day (8 hours)

DO:

Set up automated linter checks (fail fast)
Split test suite into parallel jobs
Added PR template with self-review checklist
CI time: 45min → 15min
Tracked PR merge time for 2 weeks

CHECK: Results: - Average time to merge: 1.5 days (was 3) - Time waiting for CI: 15min (was 45min) - Time waiting for review: 1.3 days (was 2+ days) Analysis: CI faster, but review still bottleneck

ACT: Partially successful: ✓ Keep fast CI improvements

Insight: Real bottleneck is reviewer availability, not CI Adjust for new PDCA: - Focus on reviewer availability/notification - Consider rotating review assignments → Start new PDCA cycle with different hypothesis


## Notes

- Start with small, measurable changes (not big overhauls)
- PDCA is iterative—multiple cycles normal
- Failed experiments are learning opportunities
- Document everything: easier to see patterns across cycles
- Success criteria must be measurable (not subjective)
- Phase 4 "Act" determines next cycle or completion
- If stuck after 3 cycles, revisit root cause analysis
- PDCA works for technical and process improvements
- Use `/analyse-problem` (A3) for comprehensive documentation

Get it through your agent

Call the Graph-of-Skills MCP server's retrieve_skill_bundle tool and it returns this skill's text inside your budget.

{
  "tool": "retrieve_skill_bundle",
  "arguments": {
    "query": "plan-do-check-act"
  }
}

New to this? Set up Graph-of-Skills or get a free key. The text on this page comes from its authors: how skills are sourced and what we check. If none fits your task, your agent can write a skill for your own library. To keep a skill from your own library on a machine, see how to install one of your skills.

Share on X Share on LinkedIn Share on Bluesky Share on Hacker News

Share on Reddit

Source

Source repository neolabhq/context-engineering-kit
Listing on skills.sh

From neolabhq/context-engineering-kit via skills.sh

Related skills

autoresearch
Autonomous iterative experimentation loop for any programming task. Guides the user through defining goals, measurable metrics, and scope constraints, then runs an autonomous loop of code changes, testing, measuring, and keeping/discarding results. Inspired by Karpathy's autoresearch. USE FOR: autonomous improvement, iterative optimization, experiment loop, auto research, performance tuning, automated experimentation, hill climbing, try things automatically, optimize code, run experiments, autonomous coding loop. DO NOT USE FOR: one-shot tasks, simple bug fixes, code review, or tasks without a measurable metric.
3,411 installs
experiment-design
Design experiment plans with progressive stages — initial implementation, baseline tuning, creative research, and ablation studies. Plan baselines, datasets, hyperparameter sweeps, and evaluation metrics. Use when planning experiments for a research paper.
1,756 installs
sequential-thinking
Use when complex problems require systematic step-by-step reasoning with ability to revise thoughts, branch into alternative approaches, or dynamically adjust scope. Ideal for multi-stage analysis, design planning, problem decomposition, or tasks with initially unclear scope.
1,780 installs
review-loop
Iterative worker-reviewer cycle that spawns a critic subagent to score work 1-10 and provide actionable feedback, then revises until a quality gate is met. Use when implementing features, writing specs, reviewing existing code, or completing any task where quality matters more than speed. Trigger phrases: "use review-loop", "polish this", "iterate on this", "/review-loop", "review with feedback loop".
104,076 installs
pua-en
Performance-coaching mode for repeated failures, passive behavior, completion-quality issues, or explicit try-harder requests. Uses structured troubleshooting and evidence-first delivery habits.
2,905 installs

More from neolabhq/context-engineering-kit

prompt-engineering
Use this skill when you writing commands, hooks, skills for Agent, or prompts for sub agents or any other LLM interaction, including optimizing prompts, improving LLM outputs, or designing production prompt templates.
1,422 installs
thought-based-reasoning
Use when tackling complex reasoning tasks requiring step-by-step logic, multi-step arithmetic, commonsense reasoning, symbolic manipulation, or problems where simple prompting fails - provides comprehensive guide to Chain-of-Thought and related prompting techniques (Zero-shot CoT, Self-Consistency, Tree of Thoughts, Least-to-Most, ReAct, PAL, Reflexion) with templates, decision matrices, and research-backed patterns
1,386 installs
context-engineering
Understand the components, mechanics, and constraints of context in agent systems. Use when writing, editing, or optimizing commands, skills, or sub-agents prompts.
1,383 installs
reflect
Reflect on previus response and output, based on Self-refinement framework for iterative improvement with complexity triage and verification
1,359 installs
write-concisely
Apply writing rules to any documentation that humans will read. Makes your writing clearer, stronger, and more professional.
1,328 installs

Content is provided as published by its creators; you are responsible for how you use it.

To request removal, use the contact form.