Plan Do Check Act
Run structured Plan–Do–Check–Act cycles so your agent experiments on a problem, measures results, and standardizes what works.
Overview
plan-do-check-act is a journey-wide agent skill that runs Plan–Do–Check–Act cycles—usable whenever a solo builder needs to test a change and standardize results before committing.
Install
npx skills add https://github.com/neolabhq/context-engineering-kit --skill plan-do-check-actWhat is this skill?
- Four-phase PDCA cycle: Plan, Do, Check, Act with explicit success criteria
- Plan phase ties to `/why` and `/cause-and-effect` for root-cause analysis
- Do phase emphasizes small-scale implementation and deviation logging
- Check phase compares metrics to baseline and tests the hypothesis
- Supports numbered iterations via CYCLE_NUMBER for repeated experiments
- 4-phase PDCA cycle (Plan, Do, Check, Act)
Adoption & trust: 525 installs on skills.sh; 1.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You keep tweaking workflows or product behavior without a baseline, hypothesis, or clear rule for what to keep.
Who is it for?
Builders iterating on agent prompts, shipping quality, support macros, or growth experiments who want measurable small bets.
Skip if: One-shot creative brainstorming with no metric, or emergencies where you must hotfix without measurement.
When should I use this skill?
You have an improvement goal or problem and want an iterative PDCA cycle (optional `/plan-do-check-act [improvement_goal]`).
What do I get? / Deliverables
You finish a cycle with measured before/after results, documented learnings, and either a standardized change or a defined next experiment.
- Documented experiment plan with success criteria
- Check-phase analysis against baseline
- Act decision: standardize change or next cycle inputs
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Test a pricing-page tweak on a small traffic slice before full build.
Hypothesis a perf fix, deploy to a subset, and check latency against criteria.
Standardize an on-call runbook change after a successful Do/Check cycle.
Experiment with onboarding email timing and act on open-rate results.
Iterate agent prompt rules with logged deviations and measured task success.
How it compares
Use instead of ad-hoc “try and see” chat loops when you need explicit Plan/Check gates and standardization in Act.
Common Questions / FAQ
Who is plan-do-check-act for?
Solo and indie builders who manage their own product and ops and want their agent to follow a repeatable improvement method across bugs, UX, and process.
When should I use plan-do-check-act?
In validate when scoping experiments, in ship when verifying a fix, in operate when refining production behavior, in grow when testing lifecycle changes, and in build when tuning agent workflows—any time you have a measurable improvement goal.
Is plan-do-check-act safe to install?
It is procedural documentation with no inherent shell requirements; still review the Security Audits panel on this Prism page before enabling tool use in your agent host.
SKILL.md
READMESKILL.md - Plan Do Check Act
# 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 1. Define the problem or improvement goal 2. Analyze current state (baseline metrics) 3. Identify root causes (use `/why` or `/cause-and-effect`) 4. Develop hypothesis: "If we change X, Y will improve" 5. Design experiment: what to change, how to measure success 6. Set success criteria (measurable targets) ### Phase 2: DO 1. Implement the planned change (small scale first) 2. Document what was actually done 3. Record any deviations from plan 4. Collect data throughout implementation 5. Note unexpected observations ### Phase 3: CHECK 1. Measure results against success criteria 2. Compare to baseline (before vs. after) 3. Analyze data: did hypothesis hold? 4. Identify what worked and what didn't 5. Document learnings and insights ### Phase 4: ACT 1. **If successful**: Standardize the change - Update documentation - Train team - Create checklist/automation - Monitor for regression 2. **If unsuccessful**: Learn and adjust - Understand why it failed - Refine hypothesis - Start new PDCA cycle with adjusted plan 3. **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: 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 testin