Plan Do Check Act

NeoLabHQ/context-engineering-kit/skills/plan-do-check-act

作者 NeoLabHQ23e2428e809d77717f8acc9659c374a3a1fcb93e無授權條款收錄於 2026年10月9日更新於 2026年10月9日

Iterative PDCA cycle for systematic experimentation and continuous improvement

僅含說明Productivity & Workflow

AI 產生的概覽

引導迭代式 PDCA（計畫-執行-檢查-處理）循環，用於系統化實驗與持續改善。

功能: 此技能引導代理依序完成四個 PDCA 階段：計畫（定義問題、基準、根因、假設、實驗與成功標準）、執行（小規模實施變更並蒐集資料）、檢查（對照標準與基準衡量結果）、處理（標準化、調整或展開新一輪循環）。它產出結構化的改善紀錄，包含假設、量測結果與後續步驟，並附有縮短建置時間、減少正式環境缺陷、加快程式碼審查等範例。
適用情境: 當你希望透過可量測、可迭代的實驗來改善流程或解決反覆出現的問題，而非一次大幅改動時使用。它適合能夠定義基準、假設與成功標準的技術或流程改善目標。
執行需求: 不需要指令碼或特殊工具，僅為指示說明。文中提及可選的搭配指令，例如 /why、/cause-and-effect 與 /analyse-problem，但並非必要。

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:  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

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 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

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

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

來源與署名

來源：NeoLabHQ/context-engineering-kit位於skills/plan-do-check-act提交23e2428

授權條款：無授權條款

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架

Plan Do Check Act

Plan-Do-Check-Act (PDCA)

Description

Usage

Variables

Steps

Phase 1: PLAN

Phase 2: DO

Phase 3: CHECK

Phase 4: ACT

Examples

Example 1: Reducing Build Time

Example 2: Reducing Production Bugs

Example 3: Improving Code Review Speed

Notes

來源與署名

更多來自 NeoLabHQ/context-engineering-kit 的技能

Write Tests

Tree Of Thoughts

Write Concisely

Test Prompt

Update Docs

Test Skill

更多Productivity & Workflow技能

Morning Note

Dd Meeting Prep

Dd Checklist

Deal Tracker

Client Review

Morning Note