[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DT5TT8F8EVQJGY9DMZ2NW6":3,"skill-same:01M6DT5TT8F8EVQJGY9DMZ2NW6":74},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":29,"linkOnly":30,"markdownContent":31,"markdownBody":32,"frontMatter":33,"refName":35,"commitSha":36,"skillDirectory":37,"forksCount":38,"repositoryHtmlUrl":39,"repositoryHomepageUrl":6,"ownerHtmlUrl":40,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":41,"install":42,"resources":55},"01M6DT5TT8F8EVQJGY9DMZ2NW6","kaizen:plan-do-check-act",null,"Iterative PDCA cycle for systematic experimentation and continuous improvement","AntifragileTech\u002Fantifragile-claude-code","AntifragileTech","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F174357194?v=4","01M6DQCYMK4CDSQQAN0ZC72NTV","01M6DQCYS9YPW1WKMQ5TJMPQ43",9,"MIT","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fplan-do-check-act\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28],"kaizen","plan","check","do","act","kaizen:plan do check act","continuous improvement","goal","cycle","systematic","problem","2026-11-10 10:12:30",false,"---\nname: kaizen:plan-do-check-act\ndescription: Iterative PDCA cycle for systematic experimentation and continuous improvement\nargument-hint: Optional improvement goal or problem to address\n---\n\n# Plan-Do-Check-Act (PDCA)\n\nApply PDCA cycle for continuous improvement through iterative problem-solving and process optimization.\n\n## Description\n\nFour-phase iterative cycle: Plan (identify and analyze), Do (implement changes), Check (measure results), Act (standardize or adjust). Enables systematic experimentation and improvement.\n\n## Usage\n\n`\u002Fplan-do-check-act [improvement_goal]`\n\n## Variables\n\n- GOAL: Improvement target or problem to address (default: prompt for input)\n- CYCLE_NUMBER: Which PDCA iteration (default: 1)\n\n## Steps\n\n### Phase 1: PLAN\n\n1. Define the problem or improvement goal\n2. Analyze current state (baseline metrics)\n3. Identify root causes (use `\u002Fwhy` or `\u002Fcause-and-effect`)\n4. Develop hypothesis: \"If we change X, Y will improve\"\n5. Design experiment: what to change, how to measure success\n6. Set success criteria (measurable targets)\n\n### Phase 2: DO\n\n1. Implement the planned change (small scale first)\n2. Document what was actually done\n3. Record any deviations from plan\n4. Collect data throughout implementation\n5. Note unexpected observations\n\n### Phase 3: CHECK\n\n1. Measure results against success criteria\n2. Compare to baseline (before vs. after)\n3. Analyze data: did hypothesis hold?\n4. Identify what worked and what didn't\n5. Document learnings and insights\n\n### Phase 4: ACT\n\n1. **If successful**: Standardize the change\n   - Update documentation\n   - Train team\n   - Create checklist\u002Fautomation\n   - Monitor for regression\n2. **If unsuccessful**: Learn and adjust\n   - Understand why it failed\n   - Refine hypothesis\n   - Start new PDCA cycle with adjusted plan\n3. **If partially successful**:\n   - Standardize what worked\n   - Plan next cycle for remaining issues\n\n## Examples\n\n### Example 1: Reducing Build Time\n\n```\nCYCLE 1\n───────\nPLAN:\n  Problem: Docker build takes 45 minutes\n  Current State: Full rebuild every time, no layer caching\n  Root Cause: Package manager cache not preserved between builds\n  Hypothesis: Caching dependencies will reduce build to \u003C10 minutes\n  Change: Add layer caching for package.json + node_modules\n  Success Criteria: Build time \u003C10 minutes on unchanged dependencies\n\nDO:\n  - Restructured Dockerfile: COPY package*.json before src files\n  - Added .dockerignore for node_modules\n  - Configured CI cache for Docker layers\n  - Tested on 3 builds\n\nCHECK:\n  Results:\n    - Unchanged dependencies: 8 minutes ✓ (was 45)\n    - Changed dependencies: 12 minutes (was 45)\n    - Fresh builds: 45 minutes (same, expected)\n  Analysis: 82% reduction on cached builds, hypothesis confirmed\n\nACT:\n  Standardize:\n    ✓ Merged Dockerfile changes\n    ✓ Updated CI pipeline config\n    ✓ Documented in README\n    ✓ Added build time monitoring\n  \n  New Problem: 12 minutes still slow when deps change\n  → Start CYCLE 2\n\n\nCYCLE 2\n───────\nPLAN:\n  Problem: Build still 12 min when dependencies change\n  Current State: npm install rebuilds all packages\n  Root Cause: Some packages compile from source\n  Hypothesis: Pre-built binaries will reduce to \u003C5 minutes\n  Change: Use npm ci instead of install, configure binary mirrors\n  Success Criteria: Build \u003C5 minutes on dependency changes\n\nDO:\n  - Changed to npm ci (uses package-lock.json)\n  - Added .npmrc with binary mirror configs\n  - Tested across 5 dependency updates\n\nCHECK:\n  Results:\n    - Dependency changes: 4.5 minutes ✓ (was 12)\n    - Compilation errors reduced to 0 (was 3)\n  Analysis: npm ci faster + more reliable, hypothesis confirmed\n\nACT:\n  Standardize:\n    ✓ Use npm ci everywhere (local + CI)\n    ✓ Committed .npmrc\n    ✓ Updated developer onboarding docs\n  \n  Total improvement: 45min → 4.5min (90% reduction)\n  ✓ PDCA complete, monitor for 2 weeks\n```\n\n### Example 2: Reducing Production Bugs\n\n```\nCYCLE 1\n───────\nPLAN:\n  Problem: 8 production bugs per month\n  Current State: Manual testing only, no automated tests\n  Root Cause: Regressions not caught before release\n  Hypothesis: Adding integration tests will reduce bugs by 50%\n  Change: Implement integration test suite for critical paths\n  Success Criteria: \u003C4 bugs per month after 1 month\n\nDO:\n  Week 1-2: Wrote integration tests for:\n    - User authentication flow\n    - Payment processing\n    - Data export\n  Week 3: Set up CI to run tests\n  Week 4: Team training on test writing\n  Coverage: 3 critical paths (was 0)\n\nCHECK:\n  Results after 1 month:\n    - Production bugs: 6 (was 8)\n    - Bugs caught in CI: 4\n    - Test failures (false positives): 2\n  Analysis: 25% reduction, not 50% target\n  Insight: Bugs are in areas without tests yet\n\nACT:\n  Partially successful:\n    ✓ Keep existing tests (prevented 4 bugs)\n    ✓ Fix flaky tests\n  \n  Adjust for CYCLE 2:\n    - Expand test coverage to all user flows\n    - Add tests for bug-prone areas\n    → Start CYCLE 2\n\n\nCYCLE 2\n───────\nPLAN:\n  Problem: Still 6 bugs\u002Fmonth, need \u003C4\n  Current State: 3 critical paths tested, 12 paths total\n  Root Cause: UI interaction bugs not covered by integration tests\n  Hypothesis: E2E tests for all user flows will reach \u003C4 bugs\n  Change: Add E2E tests for remaining 9 flows\n  Success Criteria: \u003C4 bugs per month, 80% coverage\n\nDO:\n  Week 1-3: Added E2E tests for all user flows\n  Week 4: Set up visual regression testing\n  Coverage: 12\u002F12 user flows (was 3\u002F12)\n\nCHECK:\n  Results after 1 month:\n    - Production bugs: 3 ✓ (was 6)\n    - Bugs caught in CI: 8 (was 4)\n    - Test maintenance time: 3 hours\u002Fweek\n  Analysis: Target achieved! 62% reduction from baseline\n\nACT:\n  Standardize:\n    ✓ Made tests required for all PRs\n    ✓ Added test checklist to PR template\n    ✓ Scheduled weekly test review\n    ✓ Created runbook for test maintenance\n  \n  Monitor: Track bug rate and test effectiveness monthly\n  ✓ PDCA complete\n```\n\n### Example 3: Improving Code Review Speed\n\n```\nPLAN:\n  Problem: PRs take 3 days average to merge\n  Current State: Manual review, no automation\n  Root Cause: Reviewers wait to see if CI passes before reviewing\n  Hypothesis: Auto-review + faster CI will reduce to \u003C1 day\n  Change: Add automated checks + split long CI jobs\n  Success Criteria: Average time to merge \u003C1 day (8 hours)\n\nDO:\n  - Set up automated linter checks (fail fast)\n  - Split test suite into parallel jobs\n  - Added PR template with self-review checklist\n  - CI time: 45min → 15min\n  - Tracked PR merge time for 2 weeks\n\nCHECK:\n  Results:\n    - Average time to merge: 1.5 days (was 3)\n    - Time waiting for CI: 15min (was 45min)\n    - Time waiting for review: 1.3 days (was 2+ days)\n  Analysis: CI faster, but review still bottleneck\n\nACT:\n  Partially successful:\n    ✓ Keep fast CI improvements\n  \n  Insight: Real bottleneck is reviewer availability, not CI\n  Adjust for new PDCA:\n    - Focus on reviewer availability\u002Fnotification\n    - Consider rotating review assignments\n  → Start new PDCA cycle with different hypothesis\n```\n\n## Notes\n\n- Start with small, measurable changes (not big overhauls)\n- PDCA is iterative—multiple cycles normal\n- Failed experiments are learning opportunities\n- Document everything: easier to see patterns across cycles\n- Success criteria must be measurable (not subjective)\n- Phase 4 \"Act\" determines next cycle or completion\n- If stuck after 3 cycles, revisit root cause analysis\n- PDCA works for technical and process improvements\n- Use `\u002Fanalyse-problem` (A3) for comprehensive documentation\n","# Plan-Do-Check-Act (PDCA)\n\nApply PDCA cycle for continuous improvement through iterative problem-solving and process optimization.\n\n## Description\n\nFour-phase iterative cycle: Plan (identify and analyze), Do (implement changes), Check (measure results), Act (standardize or adjust). Enables systematic experimentation and improvement.\n\n## Usage\n\n`\u002Fplan-do-check-act [improvement_goal]`\n\n## Variables\n\n- GOAL: Improvement target or problem to address (default: prompt for input)\n- CYCLE_NUMBER: Which PDCA iteration (default: 1)\n\n## Steps\n\n### Phase 1: PLAN\n\n1. Define the problem or improvement goal\n2. Analyze current state (baseline metrics)\n3. Identify root causes (use `\u002Fwhy` or `\u002Fcause-and-effect`)\n4. Develop hypothesis: \"If we change X, Y will improve\"\n5. Design experiment: what to change, how to measure success\n6. Set success criteria (measurable targets)\n\n### Phase 2: DO\n\n1. Implement the planned change (small scale first)\n2. Document what was actually done\n3. Record any deviations from plan\n4. Collect data throughout implementation\n5. Note unexpected observations\n\n### Phase 3: CHECK\n\n1. Measure results against success criteria\n2. Compare to baseline (before vs. after)\n3. Analyze data: did hypothesis hold?\n4. Identify what worked and what didn't\n5. Document learnings and insights\n\n### Phase 4: ACT\n\n1. **If successful**: Standardize the change\n   - Update documentation\n   - Train team\n   - Create checklist\u002Fautomation\n   - Monitor for regression\n2. **If unsuccessful**: Learn and adjust\n   - Understand why it failed\n   - Refine hypothesis\n   - Start new PDCA cycle with adjusted plan\n3. **If partially successful**:\n   - Standardize what worked\n   - Plan next cycle for remaining issues\n\n## Examples\n\n### Example 1: Reducing Build Time\n\n```\nCYCLE 1\n───────\nPLAN:\n  Problem: Docker build takes 45 minutes\n  Current State: Full rebuild every time, no layer caching\n  Root Cause: Package manager cache not preserved between builds\n  Hypothesis: Caching dependencies will reduce build to \u003C10 minutes\n  Change: Add layer caching for package.json + node_modules\n  Success Criteria: Build time \u003C10 minutes on unchanged dependencies\n\nDO:\n  - Restructured Dockerfile: COPY package*.json before src files\n  - Added .dockerignore for node_modules\n  - Configured CI cache for Docker layers\n  - Tested on 3 builds\n\nCHECK:\n  Results:\n    - Unchanged dependencies: 8 minutes ✓ (was 45)\n    - Changed dependencies: 12 minutes (was 45)\n    - Fresh builds: 45 minutes (same, expected)\n  Analysis: 82% reduction on cached builds, hypothesis confirmed\n\nACT:\n  Standardize:\n    ✓ Merged Dockerfile changes\n    ✓ Updated CI pipeline config\n    ✓ Documented in README\n    ✓ Added build time monitoring\n  \n  New Problem: 12 minutes still slow when deps change\n  → Start CYCLE 2\n\n\nCYCLE 2\n───────\nPLAN:\n  Problem: Build still 12 min when dependencies change\n  Current State: npm install rebuilds all packages\n  Root Cause: Some packages compile from source\n  Hypothesis: Pre-built binaries will reduce to \u003C5 minutes\n  Change: Use npm ci instead of install, configure binary mirrors\n  Success Criteria: Build \u003C5 minutes on dependency changes\n\nDO:\n  - Changed to npm ci (uses package-lock.json)\n  - Added .npmrc with binary mirror configs\n  - Tested across 5 dependency updates\n\nCHECK:\n  Results:\n    - Dependency changes: 4.5 minutes ✓ (was 12)\n    - Compilation errors reduced to 0 (was 3)\n  Analysis: npm ci faster + more reliable, hypothesis confirmed\n\nACT:\n  Standardize:\n    ✓ Use npm ci everywhere (local + CI)\n    ✓ Committed .npmrc\n    ✓ Updated developer onboarding docs\n  \n  Total improvement: 45min → 4.5min (90% reduction)\n  ✓ PDCA complete, monitor for 2 weeks\n```\n\n### Example 2: Reducing Production Bugs\n\n```\nCYCLE 1\n───────\nPLAN:\n  Problem: 8 production bugs per month\n  Current State: Manual testing only, no automated tests\n  Root Cause: Regressions not caught before release\n  Hypothesis: Adding integration tests will reduce bugs by 50%\n  Change: Implement integration test suite for critical paths\n  Success Criteria: \u003C4 bugs per month after 1 month\n\nDO:\n  Week 1-2: Wrote integration tests for:\n    - User authentication flow\n    - Payment processing\n    - Data export\n  Week 3: Set up CI to run tests\n  Week 4: Team training on test writing\n  Coverage: 3 critical paths (was 0)\n\nCHECK:\n  Results after 1 month:\n    - Production bugs: 6 (was 8)\n    - Bugs caught in CI: 4\n    - Test failures (false positives): 2\n  Analysis: 25% reduction, not 50% target\n  Insight: Bugs are in areas without tests yet\n\nACT:\n  Partially successful:\n    ✓ Keep existing tests (prevented 4 bugs)\n    ✓ Fix flaky tests\n  \n  Adjust for CYCLE 2:\n    - Expand test coverage to all user flows\n    - Add tests for bug-prone areas\n    → Start CYCLE 2\n\n\nCYCLE 2\n───────\nPLAN:\n  Problem: Still 6 bugs\u002Fmonth, need \u003C4\n  Current State: 3 critical paths tested, 12 paths total\n  Root Cause: UI interaction bugs not covered by integration tests\n  Hypothesis: E2E tests for all user flows will reach \u003C4 bugs\n  Change: Add E2E tests for remaining 9 flows\n  Success Criteria: \u003C4 bugs per month, 80% coverage\n\nDO:\n  Week 1-3: Added E2E tests for all user flows\n  Week 4: Set up visual regression testing\n  Coverage: 12\u002F12 user flows (was 3\u002F12)\n\nCHECK:\n  Results after 1 month:\n    - Production bugs: 3 ✓ (was 6)\n    - Bugs caught in CI: 8 (was 4)\n    - Test maintenance time: 3 hours\u002Fweek\n  Analysis: Target achieved! 62% reduction from baseline\n\nACT:\n  Standardize:\n    ✓ Made tests required for all PRs\n    ✓ Added test checklist to PR template\n    ✓ Scheduled weekly test review\n    ✓ Created runbook for test maintenance\n  \n  Monitor: Track bug rate and test effectiveness monthly\n  ✓ PDCA complete\n```\n\n### Example 3: Improving Code Review Speed\n\n```\nPLAN:\n  Problem: PRs take 3 days average to merge\n  Current State: Manual review, no automation\n  Root Cause: Reviewers wait to see if CI passes before reviewing\n  Hypothesis: Auto-review + faster CI will reduce to \u003C1 day\n  Change: Add automated checks + split long CI jobs\n  Success Criteria: Average time to merge \u003C1 day (8 hours)\n\nDO:\n  - Set up automated linter checks (fail fast)\n  - Split test suite into parallel jobs\n  - Added PR template with self-review checklist\n  - CI time: 45min → 15min\n  - Tracked PR merge time for 2 weeks\n\nCHECK:\n  Results:\n    - Average time to merge: 1.5 days (was 3)\n    - Time waiting for CI: 15min (was 45min)\n    - Time waiting for review: 1.3 days (was 2+ days)\n  Analysis: CI faster, but review still bottleneck\n\nACT:\n  Partially successful:\n    ✓ Keep fast CI improvements\n  \n  Insight: Real bottleneck is reviewer availability, not CI\n  Adjust for new PDCA:\n    - Focus on reviewer availability\u002Fnotification\n    - Consider rotating review assignments\n  → Start new PDCA cycle with different hypothesis\n```\n\n## Notes\n\n- Start with small, measurable changes (not big overhauls)\n- PDCA is iterative—multiple cycles normal\n- Failed experiments are learning opportunities\n- Document everything: easier to see patterns across cycles\n- Success criteria must be measurable (not subjective)\n- Phase 4 \"Act\" determines next cycle or completion\n- If stuck after 3 cycles, revisit root cause analysis\n- PDCA works for technical and process improvements\n- Use `\u002Fanalyse-problem` (A3) for comprehensive documentation\n",{"name":5,"description":7,"argument-hint":34},"Optional improvement goal or problem to address","master","c73386b305dec167db7654e0e6feacb462d4f9dc","assets\u002Fskills\u002Fthinking\u002Fplan-do-check-act",1,"https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code","https:\u002F\u002Fgithub.com\u002FAntifragileTech","2026-10-02 14:22:14",{"source":8,"skillName":5,"commands":43,"prompt":53,"zipAvailable":54},[44,47,50],{"tool":45,"command":46},"npx","npx skills add AntifragileTech\u002Fantifragile-claude-code --skill \"kaizen:plan-do-check-act\"",{"tool":48,"command":49},"bunx","bunx skills add AntifragileTech\u002Fantifragile-claude-code --skill \"kaizen:plan-do-check-act\"",{"tool":51,"command":52},"pnpm","pnpm dlx skills add AntifragileTech\u002Fantifragile-claude-code --skill \"kaizen:plan-do-check-act\"","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fplan-do-check-act\u002FSKILL.md",true,[56,62,66,70],{"path":57,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":60,"sourceHtmlUrl":61},"evals\u002Fevals.json","REFERENCE","参考文档",7949,"https:\u002F\u002Fgithub.com\u002Fpatinaproject\u002Fskills\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Freferrals\u002Fevals\u002Fevals.json",{"path":63,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":64,"sourceHtmlUrl":65},"references\u002Faffiliate-programs.md",4400,"https:\u002F\u002Fgithub.com\u002Fpatinaproject\u002Fskills\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Freferrals\u002Freferences\u002Faffiliate-programs.md",{"path":67,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":68,"sourceHtmlUrl":69},"references\u002Fprogram-examples.md",3309,"https:\u002F\u002Fgithub.com\u002Fpatinaproject\u002Fskills\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Freferrals\u002Freferences\u002Fprogram-examples.md",{"path":71,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":72,"sourceHtmlUrl":73},"references\u002Fviral-mechanisms.md",6057,"https:\u002F\u002Fgithub.com\u002Fpatinaproject\u002Fskills\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Freferrals\u002Freferences\u002Fviral-mechanisms.md",[75,101,116,131,143,156],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":94,"publishedAt":29},"01M6DT9Q6VYA615SCXR757TZZ7","writing-skills","Use when creating new skills, editing existing skills, or verifying skills work before deployment","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fwriting-skills\u002FSKILL.md",[81,86,89],{"categoryNo":82,"categoryName":83,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":87,"categoryName":88,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[95,96,97,98,99,100],"writing skills","writing","use","editing","work","deployment",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":109,"publishedAt":29},"01M6DT9GFHDNY90P41WGAE1TV0","writing-plans","Use when you have a spec or requirements for a multi-step task, before touching code","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fwriting-plans\u002FSKILL.md",[107,108],{"categoryNo":87,"categoryName":88,"taxonomyType":84,"taxonomyTypeDesc":85},{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},[110,111,96,112,113,97,114,115],"plans","writing plans","requirements","task","code","spec",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":124,"publishedAt":29},"01M6DT9C6PFGD86WS3HY7YE3XG","docs:write-concisely","Apply writing rules to any documentation that humans will read. Makes your writing clearer, stronger, and more professional.","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fwrite-concisely\u002FSKILL.md",[122,123],{"categoryNo":87,"categoryName":88,"taxonomyType":84,"taxonomyTypeDesc":85},{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},[125,126,127,128,129,130,96],"docs:write concisely","write","docs","read","Rules","documentation",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":137,"publishedAt":29},"01M6DT98AWQ27P0N1CG97WAG66","kaizen:why","Iterative Five Whys root cause analysis drilling from symptoms to fundamentals","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fwhy\u002FSKILL.md",[],[133,138,18,139,140,141,142],"why","issue","five whys","analysis","root cause analysis",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":149,"publishedAt":29},"01M6DT93EH25NAX19R3WGE1P53","verification-loop","A comprehensive verification system for Claude Code sessions.","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fverification-loop\u002FSKILL.md",[],[150,151,152,153,114,154,155],"verification loop","verification","loop","sessions","claude code sessions","system",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":162,"publishedAt":29},"01M6DT90GW7Z7VCN98P9DVYSNC","verification-before-completion","Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fverification-before-completion\u002FSKILL.md",[],[163,151,164,99,97,165,166,167],"verification before completion","commands","evidence","claim","complete"]