[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DSVBQECJTVFM5Z2QA7SBTR":3,"skill-same:01M6DSVBQECJTVFM5Z2QA7SBTR":76},{"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":22,"linkOnly":23,"markdownContent":24,"markdownBody":25,"frontMatter":26,"refName":28,"commitSha":29,"skillDirectory":30,"forksCount":31,"repositoryHtmlUrl":32,"repositoryHomepageUrl":6,"ownerHtmlUrl":33,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":34,"install":35,"resources":48},"01M6DSVBQECJTVFM5Z2QA7SBTR","kaizen:analyse",null,"Auto-selects best Kaizen method (Gemba Walk, Value Stream, or Muda) for target","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\u002Fanalyse\u002FSKILL.md",[],[18,5,19,20,21],"kaizen","workflow","code","auto","2026-11-10 10:12:30",false,"---\nname: kaizen:analyse\ndescription: Auto-selects best Kaizen method (Gemba Walk, Value Stream, or Muda) for target\nargument-hint: Optional target description (e.g., code, workflow, or inefficiencies)\n---\n\n# Smart Analysis\n\nIntelligently select and apply the most appropriate Kaizen analysis technique based on what you're analyzing.\n\n## Description\nAnalyzes context and chooses best method: Gemba Walk (code exploration), Value Stream Mapping (workflow\u002Fprocess), or Muda Analysis (waste identification). Guides you through the selected technique.\n\n## Usage\n`\u002Fanalyse [target_description]`\n\nExamples:\n- `\u002Fanalyse authentication implementation`\n- `\u002Fanalyse deployment workflow`\n- `\u002Fanalyse codebase for inefficiencies`\n\n## Variables\n- TARGET: What to analyze (default: prompt for input)\n- METHOD: Override auto-selection (gemba, vsm, muda)\n\n## Method Selection Logic\n\n**Gemba Walk** → When analyzing:\n- Code implementation (how feature actually works)\n- Gap between documentation and reality\n- Understanding unfamiliar codebase areas\n- Actual vs. assumed architecture\n\n**Value Stream Mapping** → When analyzing:\n- Workflows and processes (CI\u002FCD, deployment, development)\n- Bottlenecks in multi-stage pipelines\n- Handoffs between teams\u002Fsystems\n- Time spent in each process stage\n\n**Muda (Waste Analysis)** → When analyzing:\n- Code quality and efficiency\n- Technical debt\n- Over-engineering or duplication\n- Resource utilization\n\n## Steps\n1. Understand what's being analyzed\n2. Determine best method (or use specified method)\n3. Explain why this method fits\n4. Guide through the analysis\n5. Present findings with actionable insights\n\n---\n\n## Method 1: Gemba Walk\n\n\"Go and see\" the actual code to understand reality vs. assumptions.\n\n### When to Use\n- Understanding how feature actually works\n- Code archaeology (legacy systems)\n- Finding gaps between docs and implementation\n- Exploring unfamiliar areas before changes\n\n### Process\n1. **Define scope**: What code area to explore\n2. **State assumptions**: What you think it does\n3. **Observe reality**: Read actual code\n4. **Document findings**: \n   - Entry points\n   - Actual data flow\n   - Surprises (differs from assumptions)\n   - Hidden dependencies\n   - Undocumented behavior\n5. **Identify gaps**: Documentation vs. reality\n6. **Recommend**: Update docs, refactor, or accept\n\n### Example: Authentication System Gemba Walk\n\n```\nSCOPE: User authentication flow\n\nASSUMPTIONS (Before):\n• JWT tokens stored in localStorage\n• Single sign-on via OAuth only\n• Session expires after 1 hour\n• Password reset via email link\n\nGEMBA OBSERVATIONS (Actual Code):\n\nEntry Point: \u002Fapi\u002Fauth\u002Flogin (routes\u002Fauth.ts:45)\n├─> AuthService.authenticate() (services\u002Fauth.ts:120)\n├─> UserRepository.findByEmail() (db\u002Fusers.ts:67)\n├─> bcrypt.compare() (services\u002Fauth.ts:145)\n└─> TokenService.generate() (services\u002Ftoken.ts:34)\n\nActual Flow:\n1. Login credentials → POST \u002Fapi\u002Fauth\u002Flogin\n2. Password hashed with bcrypt (10 rounds)\n3. JWT generated with 24hr expiry (NOT 1 hour!)\n4. Token stored in httpOnly cookie (NOT localStorage)\n5. Refresh token in separate cookie (15 days)\n6. Session data in Redis (30 days TTL)\n\nSURPRISES:\n✗ OAuth not implemented (commented out code found)\n✗ Password reset is manual (admin intervention)\n✗ Three different session storage mechanisms:\n  - Redis for session data\n  - Database for \"remember me\"\n  - Cookies for tokens\n✗ Legacy endpoint \u002Fauth\u002Flegacy still active (no auth!)\n✗ Admin users bypass rate limiting (security issue)\n\nGAPS:\n• Documentation says OAuth, code doesn't have it\n• Session expiry inconsistent (docs: 1hr, code: 24hr)\n• Legacy endpoint not documented (security risk)\n• No mention of \"remember me\" in docs\n\nRECOMMENDATIONS:\n1. HIGH: Secure or remove \u002Fauth\u002Flegacy endpoint\n2. HIGH: Document actual session expiry (24hr)\n3. MEDIUM: Clean up or implement OAuth\n4. MEDIUM: Consolidate session storage (choose one)\n5. LOW: Add rate limiting for admin users\n```\n\n### Example: CI\u002FCD Pipeline Gemba Walk\n\n```\nSCOPE: Build and deployment pipeline\n\nASSUMPTIONS:\n• Automated tests run on every commit\n• Deploy to staging automatic\n• Production deploy requires approval\n\nGEMBA OBSERVATIONS:\n\nActual Pipeline (.github\u002Fworkflows\u002Fmain.yml):\n1. On push to main:\n   ├─> Lint (2 min)\n   ├─> Unit tests (5 min) [SKIPPED if \"[skip-tests]\" in commit]\n   ├─> Build Docker image (15 min)\n   └─> Deploy to staging (3 min)\n\n2. Manual trigger for production:\n   ├─> Run integration tests (20 min) [ONLY for production!]\n   ├─> Security scan (10 min)\n   └─> Deploy to production (5 min)\n\nSURPRISES:\n✗ Unit tests can be skipped with commit message flag\n✗ Integration tests ONLY run for production deploy\n✗ Staging deployed without integration tests\n✗ No rollback mechanism (manual kubectl commands)\n✗ Secrets loaded from .env file (not secrets manager)\n✗ Old \"hotfix\" branch bypasses all checks\n\nGAPS:\n• Staging and production have different test coverage\n• Documentation doesn't mention test skip flag\n• Rollback process not documented or automated\n• Security scan results not enforced (warning only)\n\nRECOMMENDATIONS:\n1. CRITICAL: Remove test skip flag capability\n2. CRITICAL: Migrate secrets to secrets manager\n3. HIGH: Run integration tests on staging too\n4. HIGH: Delete or secure hotfix branch\n5. MEDIUM: Add automated rollback capability\n6. MEDIUM: Make security scan blocking\n```\n\n---\n\n## Method 2: Value Stream Mapping\n\nMap workflow stages, measure time\u002Fwaste, identify bottlenecks.\n\n### When to Use\n- Process optimization (CI\u002FCD, deployment, code review)\n- Understanding multi-stage workflows\n- Finding delays and handoffs\n- Improving cycle time\n\n### Process\n1. **Identify start and end**: Where process begins and ends\n2. **Map all steps**: Including waiting\u002Fhandoff time\n3. **Measure each step**:\n   - Processing time (work happening)\n   - Waiting time (idle, blocked)\n   - Who\u002Fwhat performs step\n4. **Calculate metrics**:\n   - Total lead time\n   - Value-add time vs. waste time\n   - % efficiency (value-add \u002F total time)\n5. **Identify bottlenecks**: Longest steps, most waiting\n6. **Design future state**: Optimized flow\n7. **Plan improvements**: How to achieve future state\n\n### Example: Feature Development Value Stream Map\n\n```\nCURRENT STATE: Feature request → Production\n\nStep 1: Requirements Gathering\n├─ Processing: 2 days (meetings, writing spec)\n├─ Waiting: 3 days (stakeholder review)\n└─ Owner: Product Manager\n\nStep 2: Design\n├─ Processing: 1 day (mockups, architecture)\n├─ Waiting: 2 days (design review, feedback)\n└─ Owner: Designer + Architect\n\nStep 3: Development\n├─ Processing: 5 days (coding)\n├─ Waiting: 2 days (PR review queue)\n└─ Owner: Developer\n\nStep 4: Code Review\n├─ Processing: 0.5 days (review)\n├─ Waiting: 1 day (back-and-forth changes)\n└─ Owner: Senior Developer\n\nStep 5: QA Testing\n├─ Processing: 2 days (manual testing)\n├─ Waiting: 1 day (bug fixes, retest)\n└─ Owner: QA Engineer\n\nStep 6: Staging Deployment\n├─ Processing: 0.5 days (deploy, smoke test)\n├─ Waiting: 2 days (stakeholder UAT)\n└─ Owner: DevOps\n\nStep 7: Production Deployment\n├─ Processing: 0.5 days (deploy, monitor)\n├─ Waiting: 0 days\n└─ Owner: DevOps\n\n───────────────────────────────────────\nMETRICS:\nTotal Lead Time: 22.5 days\nValue-Add Time: 11.5 days (work)\nWaste Time: 11 days (waiting)\nEfficiency: 51%\n\nBOTTLENECKS:\n1. Requirements review wait (3 days)\n2. Development time (5 days)\n3. Stakeholder UAT wait (2 days)\n4. PR review queue (2 days)\n\nWASTE ANALYSIS:\n• Waiting for reviews\u002Fapprovals: 9 days (82% of waste)\n• Rework due to unclear requirements: ~1 day\n• Manual testing time: 2 days\n\nFUTURE STATE DESIGN:\n\nChanges:\n1. Async requirements approval (stakeholders have 24hr SLA)\n2. Split large features into smaller increments\n3. Automated testing replaces manual QA\n4. PR review SLA: 4 hours max\n5. Continuous deployment to staging (no approval)\n6. Feature flags for production rollout (no wait)\n\nProjected Future State:\nTotal Lead Time: 9 days (60% reduction)\nValue-Add Time: 8 days\nWaste Time: 1 day\nEfficiency: 89%\n\nIMPLEMENTATION PLAN:\nWeek 1: Set review SLAs, add feature flags\nWeek 2: Automate test suite\nWeek 3: Enable continuous staging deployment\nWeek 4: Train team on incremental delivery\n```\n\n### Example: Incident Response Value Stream Map\n\n```\nCURRENT STATE: Incident detected → Resolution\n\nStep 1: Detection\n├─ Processing: 0 min (automated alert)\n├─ Waiting: 15 min (until someone sees alert)\n└─ System: Monitoring tool\n\nStep 2: Triage\n├─ Processing: 10 min (assess severity)\n├─ Waiting: 20 min (find right person)\n└─ Owner: On-call engineer\n\nStep 3: Investigation\n├─ Processing: 45 min (logs, debugging)\n├─ Waiting: 30 min (access to production, gather context)\n└─ Owner: Engineer + SRE\n\nStep 4: Fix Development\n├─ Processing: 60 min (write fix)\n├─ Waiting: 15 min (code review)\n└─ Owner: Engineer\n\nStep 5: Deployment\n├─ Processing: 10 min (hotfix deploy)\n├─ Waiting: 5 min (verification)\n└─ Owner: SRE\n\nStep 6: Post-Incident\n├─ Processing: 20 min (update status, notify)\n├─ Waiting: 0 min\n└─ Owner: Engineer\n\n───────────────────────────────────────\nMETRICS:\nTotal Lead Time: 230 min (3h 50min)\nValue-Add Time: 145 min\nWaste Time: 85 min (37%)\n\nBOTTLENECKS:\n1. Finding right person (20 min)\n2. Gaining production access (30 min)\n3. Investigation time (45 min)\n\nIMPROVEMENTS:\n1. Slack integration for alerts (reduce detection wait)\n2. Auto-assign by service owner (no hunt for person)\n3. Pre-approved prod access for on-call (reduce wait)\n4. Runbooks for common incidents (faster investigation)\n5. Automated rollback for deployment incidents\n\nProjected improvement: 230min → 120min (48% faster)\n```\n\n---\n\n## Method 3: Muda (Waste Analysis)\n\nIdentify seven types of waste in code and development processes.\n\n### When to Use\n- Code quality audits\n- Technical debt assessment\n- Process efficiency improvements\n- Identifying over-engineering\n\n### The 7 Types of Waste (Applied to Software)\n\n**1. Overproduction**: Building more than needed\n- Features no one uses\n- Overly complex solutions\n- Premature optimization\n- Unnecessary abstractions\n\n**2. Waiting**: Idle time\n- Build\u002Ftest\u002Fdeploy time\n- Code review delays\n- Waiting for dependencies\n- Blocked by other teams\n\n**3. Transportation**: Moving things around\n- Unnecessary data transformations\n- API layers with no value add\n- Copying data between systems\n- Repeated serialization\u002Fdeserialization\n\n**4. Over-processing**: Doing more than necessary\n- Excessive logging\n- Redundant validations\n- Over-normalized databases\n- Unnecessary computation\n\n**5. Inventory**: Work in progress\n- Unmerged branches\n- Half-finished features\n- Untriaged bugs\n- Undeployed code\n\n**6. Motion**: Unnecessary movement\n- Context switching\n- Meetings without purpose\n- Manual deployments\n- Repetitive tasks\n\n**7. Defects**: Rework and bugs\n- Production bugs\n- Technical debt\n- Flaky tests\n- Incomplete features\n\n### Process\n1. **Define scope**: Codebase area or process\n2. **Examine for each waste type**\n3. **Quantify impact** (time, complexity, cost)\n4. **Prioritize by impact**\n5. **Propose elimination strategies**\n\n### Example: API Codebase Waste Analysis\n\n```\nSCOPE: REST API backend (50K LOC)\n\n1. OVERPRODUCTION\n   Found:\n   • 15 API endpoints with zero usage (last 90 days)\n   • Generic \"framework\" built for \"future flexibility\" (unused)\n   • Premature microservices split (2 services, could be 1)\n   • Feature flags for 12 features (10 fully rolled out, flags kept)\n   \n   Impact: 8K LOC maintained for no reason\n   Recommendation: Delete unused endpoints, remove stale flags\n\n2. WAITING\n   Found:\n   • CI pipeline: 45 min (slow Docker builds)\n   • PR review time: avg 2 days\n   • Deployment to staging: manual, takes 1 hour\n   \n   Impact: 2.5 days wasted per feature\n   Recommendation: Cache Docker layers, PR review SLA, automate staging\n\n3. TRANSPORTATION\n   Found:\n   • Data transformed 4 times between DB and API response:\n     DB → ORM → Service → DTO → Serializer\n   • Request\u002Fresponse logged 3 times (middleware, handler, service)\n   • Files uploaded → S3 → CloudFront → Local cache (unnecessary)\n   \n   Impact: 200ms avg response time overhead\n   Recommendation: Reduce transformation layers, consolidate logging\n\n4. OVER-PROCESSING\n   Found:\n   • Every request validates auth token (even cached)\n   • Database queries fetch all columns (SELECT *)\n   • JSON responses include full object graphs (nested 5 levels)\n   • Logs every database query in production (verbose)\n   \n   Impact: 40% higher database load, 3x log storage\n   Recommendation: Cache auth checks, selective fields, trim responses\n\n5. INVENTORY\n   Found:\n   • 23 open PRs (8 abandoned, 6+ months old)\n   • 5 feature branches unmerged (completed but not deployed)\n   • 147 open bugs (42 duplicates, 60 not reproducible)\n   • 12 hotfix commits not backported to main\n   \n   Impact: Context overhead, merge conflicts, lost work\n   Recommendation: Close stale PRs, bug triage, deploy pending features\n\n6. MOTION\n   Found:\n   • Developers switch between 4 tools for one deployment\n   • Manual database migrations (error-prone, slow)\n   • Environment config spread across 6 files\n   • Copy-paste secrets to .env files\n   \n   Impact: 30min per deployment, frequent mistakes\n   Recommendation: Unified deployment tool, automate migrations\n\n7. DEFECTS\n   Found:\n   • 12 production bugs per month\n   • 15% flaky test rate (wasted retry time)\n   • Technical debt in auth module (refactor needed)\n   • Incomplete error handling (crashes instead of graceful)\n   \n   Impact: Customer complaints, rework, downtime\n   Recommendation: Stabilize tests, refactor auth, add error boundaries\n\n───────────────────────────────────────\nSUMMARY\n\nTotal Waste Identified:\n• Code: 8K LOC doing nothing\n• Time: 2.5 days per feature\n• Performance: 200ms overhead per request\n• Effort: 30min per deployment\n\nPriority Fixes (by impact):\n1. HIGH: Automate deployments (reduces Motion + Waiting)\n2. HIGH: Fix flaky tests (reduces Defects)\n3. MEDIUM: Remove unused code (reduces Overproduction)\n4. MEDIUM: Optimize data transformations (reduces Transportation)\n5. LOW: Triage bug backlog (reduces Inventory)\n\nEstimated Recovery:\n• 20% faster feature delivery\n• 50% fewer production issues\n• 30% less operational overhead\n```\n\n---\n\n## Notes\n- Method selection is contextual—choose what fits best\n- Can combine methods (Gemba Walk → Muda Analysis)\n- Start with Gemba Walk when unfamiliar with area\n- Use VSM for process optimization\n- Use Muda for efficiency and cleanup\n- All methods should lead to actionable improvements\n- Document findings for organizational learning\n- Consider using `\u002Fanalyse-problem` (A3) for comprehensive documentation of findings\n\n","# Smart Analysis\n\nIntelligently select and apply the most appropriate Kaizen analysis technique based on what you're analyzing.\n\n## Description\nAnalyzes context and chooses best method: Gemba Walk (code exploration), Value Stream Mapping (workflow\u002Fprocess), or Muda Analysis (waste identification). Guides you through the selected technique.\n\n## Usage\n`\u002Fanalyse [target_description]`\n\nExamples:\n- `\u002Fanalyse authentication implementation`\n- `\u002Fanalyse deployment workflow`\n- `\u002Fanalyse codebase for inefficiencies`\n\n## Variables\n- TARGET: What to analyze (default: prompt for input)\n- METHOD: Override auto-selection (gemba, vsm, muda)\n\n## Method Selection Logic\n\n**Gemba Walk** → When analyzing:\n- Code implementation (how feature actually works)\n- Gap between documentation and reality\n- Understanding unfamiliar codebase areas\n- Actual vs. assumed architecture\n\n**Value Stream Mapping** → When analyzing:\n- Workflows and processes (CI\u002FCD, deployment, development)\n- Bottlenecks in multi-stage pipelines\n- Handoffs between teams\u002Fsystems\n- Time spent in each process stage\n\n**Muda (Waste Analysis)** → When analyzing:\n- Code quality and efficiency\n- Technical debt\n- Over-engineering or duplication\n- Resource utilization\n\n## Steps\n1. Understand what's being analyzed\n2. Determine best method (or use specified method)\n3. Explain why this method fits\n4. Guide through the analysis\n5. Present findings with actionable insights\n\n---\n\n## Method 1: Gemba Walk\n\n\"Go and see\" the actual code to understand reality vs. assumptions.\n\n### When to Use\n- Understanding how feature actually works\n- Code archaeology (legacy systems)\n- Finding gaps between docs and implementation\n- Exploring unfamiliar areas before changes\n\n### Process\n1. **Define scope**: What code area to explore\n2. **State assumptions**: What you think it does\n3. **Observe reality**: Read actual code\n4. **Document findings**: \n   - Entry points\n   - Actual data flow\n   - Surprises (differs from assumptions)\n   - Hidden dependencies\n   - Undocumented behavior\n5. **Identify gaps**: Documentation vs. reality\n6. **Recommend**: Update docs, refactor, or accept\n\n### Example: Authentication System Gemba Walk\n\n```\nSCOPE: User authentication flow\n\nASSUMPTIONS (Before):\n• JWT tokens stored in localStorage\n• Single sign-on via OAuth only\n• Session expires after 1 hour\n• Password reset via email link\n\nGEMBA OBSERVATIONS (Actual Code):\n\nEntry Point: \u002Fapi\u002Fauth\u002Flogin (routes\u002Fauth.ts:45)\n├─> AuthService.authenticate() (services\u002Fauth.ts:120)\n├─> UserRepository.findByEmail() (db\u002Fusers.ts:67)\n├─> bcrypt.compare() (services\u002Fauth.ts:145)\n└─> TokenService.generate() (services\u002Ftoken.ts:34)\n\nActual Flow:\n1. Login credentials → POST \u002Fapi\u002Fauth\u002Flogin\n2. Password hashed with bcrypt (10 rounds)\n3. JWT generated with 24hr expiry (NOT 1 hour!)\n4. Token stored in httpOnly cookie (NOT localStorage)\n5. Refresh token in separate cookie (15 days)\n6. Session data in Redis (30 days TTL)\n\nSURPRISES:\n✗ OAuth not implemented (commented out code found)\n✗ Password reset is manual (admin intervention)\n✗ Three different session storage mechanisms:\n  - Redis for session data\n  - Database for \"remember me\"\n  - Cookies for tokens\n✗ Legacy endpoint \u002Fauth\u002Flegacy still active (no auth!)\n✗ Admin users bypass rate limiting (security issue)\n\nGAPS:\n• Documentation says OAuth, code doesn't have it\n• Session expiry inconsistent (docs: 1hr, code: 24hr)\n• Legacy endpoint not documented (security risk)\n• No mention of \"remember me\" in docs\n\nRECOMMENDATIONS:\n1. HIGH: Secure or remove \u002Fauth\u002Flegacy endpoint\n2. HIGH: Document actual session expiry (24hr)\n3. MEDIUM: Clean up or implement OAuth\n4. MEDIUM: Consolidate session storage (choose one)\n5. LOW: Add rate limiting for admin users\n```\n\n### Example: CI\u002FCD Pipeline Gemba Walk\n\n```\nSCOPE: Build and deployment pipeline\n\nASSUMPTIONS:\n• Automated tests run on every commit\n• Deploy to staging automatic\n• Production deploy requires approval\n\nGEMBA OBSERVATIONS:\n\nActual Pipeline (.github\u002Fworkflows\u002Fmain.yml):\n1. On push to main:\n   ├─> Lint (2 min)\n   ├─> Unit tests (5 min) [SKIPPED if \"[skip-tests]\" in commit]\n   ├─> Build Docker image (15 min)\n   └─> Deploy to staging (3 min)\n\n2. Manual trigger for production:\n   ├─> Run integration tests (20 min) [ONLY for production!]\n   ├─> Security scan (10 min)\n   └─> Deploy to production (5 min)\n\nSURPRISES:\n✗ Unit tests can be skipped with commit message flag\n✗ Integration tests ONLY run for production deploy\n✗ Staging deployed without integration tests\n✗ No rollback mechanism (manual kubectl commands)\n✗ Secrets loaded from .env file (not secrets manager)\n✗ Old \"hotfix\" branch bypasses all checks\n\nGAPS:\n• Staging and production have different test coverage\n• Documentation doesn't mention test skip flag\n• Rollback process not documented or automated\n• Security scan results not enforced (warning only)\n\nRECOMMENDATIONS:\n1. CRITICAL: Remove test skip flag capability\n2. CRITICAL: Migrate secrets to secrets manager\n3. HIGH: Run integration tests on staging too\n4. HIGH: Delete or secure hotfix branch\n5. MEDIUM: Add automated rollback capability\n6. MEDIUM: Make security scan blocking\n```\n\n---\n\n## Method 2: Value Stream Mapping\n\nMap workflow stages, measure time\u002Fwaste, identify bottlenecks.\n\n### When to Use\n- Process optimization (CI\u002FCD, deployment, code review)\n- Understanding multi-stage workflows\n- Finding delays and handoffs\n- Improving cycle time\n\n### Process\n1. **Identify start and end**: Where process begins and ends\n2. **Map all steps**: Including waiting\u002Fhandoff time\n3. **Measure each step**:\n   - Processing time (work happening)\n   - Waiting time (idle, blocked)\n   - Who\u002Fwhat performs step\n4. **Calculate metrics**:\n   - Total lead time\n   - Value-add time vs. waste time\n   - % efficiency (value-add \u002F total time)\n5. **Identify bottlenecks**: Longest steps, most waiting\n6. **Design future state**: Optimized flow\n7. **Plan improvements**: How to achieve future state\n\n### Example: Feature Development Value Stream Map\n\n```\nCURRENT STATE: Feature request → Production\n\nStep 1: Requirements Gathering\n├─ Processing: 2 days (meetings, writing spec)\n├─ Waiting: 3 days (stakeholder review)\n└─ Owner: Product Manager\n\nStep 2: Design\n├─ Processing: 1 day (mockups, architecture)\n├─ Waiting: 2 days (design review, feedback)\n└─ Owner: Designer + Architect\n\nStep 3: Development\n├─ Processing: 5 days (coding)\n├─ Waiting: 2 days (PR review queue)\n└─ Owner: Developer\n\nStep 4: Code Review\n├─ Processing: 0.5 days (review)\n├─ Waiting: 1 day (back-and-forth changes)\n└─ Owner: Senior Developer\n\nStep 5: QA Testing\n├─ Processing: 2 days (manual testing)\n├─ Waiting: 1 day (bug fixes, retest)\n└─ Owner: QA Engineer\n\nStep 6: Staging Deployment\n├─ Processing: 0.5 days (deploy, smoke test)\n├─ Waiting: 2 days (stakeholder UAT)\n└─ Owner: DevOps\n\nStep 7: Production Deployment\n├─ Processing: 0.5 days (deploy, monitor)\n├─ Waiting: 0 days\n└─ Owner: DevOps\n\n───────────────────────────────────────\nMETRICS:\nTotal Lead Time: 22.5 days\nValue-Add Time: 11.5 days (work)\nWaste Time: 11 days (waiting)\nEfficiency: 51%\n\nBOTTLENECKS:\n1. Requirements review wait (3 days)\n2. Development time (5 days)\n3. Stakeholder UAT wait (2 days)\n4. PR review queue (2 days)\n\nWASTE ANALYSIS:\n• Waiting for reviews\u002Fapprovals: 9 days (82% of waste)\n• Rework due to unclear requirements: ~1 day\n• Manual testing time: 2 days\n\nFUTURE STATE DESIGN:\n\nChanges:\n1. Async requirements approval (stakeholders have 24hr SLA)\n2. Split large features into smaller increments\n3. Automated testing replaces manual QA\n4. PR review SLA: 4 hours max\n5. Continuous deployment to staging (no approval)\n6. Feature flags for production rollout (no wait)\n\nProjected Future State:\nTotal Lead Time: 9 days (60% reduction)\nValue-Add Time: 8 days\nWaste Time: 1 day\nEfficiency: 89%\n\nIMPLEMENTATION PLAN:\nWeek 1: Set review SLAs, add feature flags\nWeek 2: Automate test suite\nWeek 3: Enable continuous staging deployment\nWeek 4: Train team on incremental delivery\n```\n\n### Example: Incident Response Value Stream Map\n\n```\nCURRENT STATE: Incident detected → Resolution\n\nStep 1: Detection\n├─ Processing: 0 min (automated alert)\n├─ Waiting: 15 min (until someone sees alert)\n└─ System: Monitoring tool\n\nStep 2: Triage\n├─ Processing: 10 min (assess severity)\n├─ Waiting: 20 min (find right person)\n└─ Owner: On-call engineer\n\nStep 3: Investigation\n├─ Processing: 45 min (logs, debugging)\n├─ Waiting: 30 min (access to production, gather context)\n└─ Owner: Engineer + SRE\n\nStep 4: Fix Development\n├─ Processing: 60 min (write fix)\n├─ Waiting: 15 min (code review)\n└─ Owner: Engineer\n\nStep 5: Deployment\n├─ Processing: 10 min (hotfix deploy)\n├─ Waiting: 5 min (verification)\n└─ Owner: SRE\n\nStep 6: Post-Incident\n├─ Processing: 20 min (update status, notify)\n├─ Waiting: 0 min\n└─ Owner: Engineer\n\n───────────────────────────────────────\nMETRICS:\nTotal Lead Time: 230 min (3h 50min)\nValue-Add Time: 145 min\nWaste Time: 85 min (37%)\n\nBOTTLENECKS:\n1. Finding right person (20 min)\n2. Gaining production access (30 min)\n3. Investigation time (45 min)\n\nIMPROVEMENTS:\n1. Slack integration for alerts (reduce detection wait)\n2. Auto-assign by service owner (no hunt for person)\n3. Pre-approved prod access for on-call (reduce wait)\n4. Runbooks for common incidents (faster investigation)\n5. Automated rollback for deployment incidents\n\nProjected improvement: 230min → 120min (48% faster)\n```\n\n---\n\n## Method 3: Muda (Waste Analysis)\n\nIdentify seven types of waste in code and development processes.\n\n### When to Use\n- Code quality audits\n- Technical debt assessment\n- Process efficiency improvements\n- Identifying over-engineering\n\n### The 7 Types of Waste (Applied to Software)\n\n**1. Overproduction**: Building more than needed\n- Features no one uses\n- Overly complex solutions\n- Premature optimization\n- Unnecessary abstractions\n\n**2. Waiting**: Idle time\n- Build\u002Ftest\u002Fdeploy time\n- Code review delays\n- Waiting for dependencies\n- Blocked by other teams\n\n**3. Transportation**: Moving things around\n- Unnecessary data transformations\n- API layers with no value add\n- Copying data between systems\n- Repeated serialization\u002Fdeserialization\n\n**4. Over-processing**: Doing more than necessary\n- Excessive logging\n- Redundant validations\n- Over-normalized databases\n- Unnecessary computation\n\n**5. Inventory**: Work in progress\n- Unmerged branches\n- Half-finished features\n- Untriaged bugs\n- Undeployed code\n\n**6. Motion**: Unnecessary movement\n- Context switching\n- Meetings without purpose\n- Manual deployments\n- Repetitive tasks\n\n**7. Defects**: Rework and bugs\n- Production bugs\n- Technical debt\n- Flaky tests\n- Incomplete features\n\n### Process\n1. **Define scope**: Codebase area or process\n2. **Examine for each waste type**\n3. **Quantify impact** (time, complexity, cost)\n4. **Prioritize by impact**\n5. **Propose elimination strategies**\n\n### Example: API Codebase Waste Analysis\n\n```\nSCOPE: REST API backend (50K LOC)\n\n1. OVERPRODUCTION\n   Found:\n   • 15 API endpoints with zero usage (last 90 days)\n   • Generic \"framework\" built for \"future flexibility\" (unused)\n   • Premature microservices split (2 services, could be 1)\n   • Feature flags for 12 features (10 fully rolled out, flags kept)\n   \n   Impact: 8K LOC maintained for no reason\n   Recommendation: Delete unused endpoints, remove stale flags\n\n2. WAITING\n   Found:\n   • CI pipeline: 45 min (slow Docker builds)\n   • PR review time: avg 2 days\n   • Deployment to staging: manual, takes 1 hour\n   \n   Impact: 2.5 days wasted per feature\n   Recommendation: Cache Docker layers, PR review SLA, automate staging\n\n3. TRANSPORTATION\n   Found:\n   • Data transformed 4 times between DB and API response:\n     DB → ORM → Service → DTO → Serializer\n   • Request\u002Fresponse logged 3 times (middleware, handler, service)\n   • Files uploaded → S3 → CloudFront → Local cache (unnecessary)\n   \n   Impact: 200ms avg response time overhead\n   Recommendation: Reduce transformation layers, consolidate logging\n\n4. OVER-PROCESSING\n   Found:\n   • Every request validates auth token (even cached)\n   • Database queries fetch all columns (SELECT *)\n   • JSON responses include full object graphs (nested 5 levels)\n   • Logs every database query in production (verbose)\n   \n   Impact: 40% higher database load, 3x log storage\n   Recommendation: Cache auth checks, selective fields, trim responses\n\n5. INVENTORY\n   Found:\n   • 23 open PRs (8 abandoned, 6+ months old)\n   • 5 feature branches unmerged (completed but not deployed)\n   • 147 open bugs (42 duplicates, 60 not reproducible)\n   • 12 hotfix commits not backported to main\n   \n   Impact: Context overhead, merge conflicts, lost work\n   Recommendation: Close stale PRs, bug triage, deploy pending features\n\n6. MOTION\n   Found:\n   • Developers switch between 4 tools for one deployment\n   • Manual database migrations (error-prone, slow)\n   • Environment config spread across 6 files\n   • Copy-paste secrets to .env files\n   \n   Impact: 30min per deployment, frequent mistakes\n   Recommendation: Unified deployment tool, automate migrations\n\n7. DEFECTS\n   Found:\n   • 12 production bugs per month\n   • 15% flaky test rate (wasted retry time)\n   • Technical debt in auth module (refactor needed)\n   • Incomplete error handling (crashes instead of graceful)\n   \n   Impact: Customer complaints, rework, downtime\n   Recommendation: Stabilize tests, refactor auth, add error boundaries\n\n───────────────────────────────────────\nSUMMARY\n\nTotal Waste Identified:\n• Code: 8K LOC doing nothing\n• Time: 2.5 days per feature\n• Performance: 200ms overhead per request\n• Effort: 30min per deployment\n\nPriority Fixes (by impact):\n1. HIGH: Automate deployments (reduces Motion + Waiting)\n2. HIGH: Fix flaky tests (reduces Defects)\n3. MEDIUM: Remove unused code (reduces Overproduction)\n4. MEDIUM: Optimize data transformations (reduces Transportation)\n5. LOW: Triage bug backlog (reduces Inventory)\n\nEstimated Recovery:\n• 20% faster feature delivery\n• 50% fewer production issues\n• 30% less operational overhead\n```\n\n---\n\n## Notes\n- Method selection is contextual—choose what fits best\n- Can combine methods (Gemba Walk → Muda Analysis)\n- Start with Gemba Walk when unfamiliar with area\n- Use VSM for process optimization\n- Use Muda for efficiency and cleanup\n- All methods should lead to actionable improvements\n- Document findings for organizational learning\n- Consider using `\u002Fanalyse-problem` (A3) for comprehensive documentation of findings\n\n",{"name":5,"description":7,"argument-hint":27},"Optional target description (e.g., code, workflow, or inefficiencies)","master","c73386b305dec167db7654e0e6feacb462d4f9dc","assets\u002Fskills\u002Fthinking\u002Fanalyse",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":36,"prompt":46,"zipAvailable":47},[37,40,43],{"tool":38,"command":39},"npx","npx skills add AntifragileTech\u002Fantifragile-claude-code --skill \"kaizen:analyse\"",{"tool":41,"command":42},"bunx","bunx skills add AntifragileTech\u002Fantifragile-claude-code --skill \"kaizen:analyse\"",{"tool":44,"command":45},"pnpm","pnpm dlx skills add AntifragileTech\u002Fantifragile-claude-code --skill \"kaizen:analyse\"","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fanalyse\u002FSKILL.md",true,[49,55,58,61,64,67,70,73],{"path":50,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":53,"sourceHtmlUrl":54},"algorithms.md","REFERENCE","参考文档",0,"https:\u002F\u002Fgithub.com\u002Fhefarica\u002Farbitragex-v2\u002Fblob\u002Fmain\u002F.claude\u002Fagents\u002Fskills\u002Fcalldata-decoding-for-mev-searchers\u002Falgorithms.md",{"path":56,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":53,"sourceHtmlUrl":57},"failure_modes.md","https:\u002F\u002Fgithub.com\u002Fhefarica\u002Farbitragex-v2\u002Fblob\u002Fmain\u002F.claude\u002Fagents\u002Fskills\u002Fcalldata-decoding-for-mev-searchers\u002Ffailure_modes.md",{"path":59,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":53,"sourceHtmlUrl":60},"formulas.md","https:\u002F\u002Fgithub.com\u002Fhefarica\u002Farbitragex-v2\u002Fblob\u002Fmain\u002F.claude\u002Fagents\u002Fskills\u002Fcalldata-decoding-for-mev-searchers\u002Fformulas.md",{"path":62,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":53,"sourceHtmlUrl":63},"implementation_notes.md","https:\u002F\u002Fgithub.com\u002Fhefarica\u002Farbitragex-v2\u002Fblob\u002Fmain\u002F.claude\u002Fagents\u002Fskills\u002Fcalldata-decoding-for-mev-searchers\u002Fimplementation_notes.md",{"path":65,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":53,"sourceHtmlUrl":66},"integration_arbitragex.md","https:\u002F\u002Fgithub.com\u002Fhefarica\u002Farbitragex-v2\u002Fblob\u002Fmain\u002F.claude\u002Fagents\u002Fskills\u002Fcalldata-decoding-for-mev-searchers\u002Fintegration_arbitragex.md",{"path":68,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":53,"sourceHtmlUrl":69},"manifest.json","https:\u002F\u002Fgithub.com\u002Fhefarica\u002Farbitragex-v2\u002Fblob\u002Fmain\u002F.claude\u002Fagents\u002Fskills\u002Fcalldata-decoding-for-mev-searchers\u002Fmanifest.json",{"path":71,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":53,"sourceHtmlUrl":72},"references.json","https:\u002F\u002Fgithub.com\u002Fhefarica\u002Farbitragex-v2\u002Fblob\u002Fmain\u002F.claude\u002Fagents\u002Fskills\u002Fcalldata-decoding-for-mev-searchers\u002Freferences.json",{"path":74,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":53,"sourceHtmlUrl":75},"validation_tests.md","https:\u002F\u002Fgithub.com\u002Fhefarica\u002Farbitragex-v2\u002Fblob\u002Fmain\u002F.claude\u002Fagents\u002Fskills\u002Fcalldata-decoding-for-mev-searchers\u002Fvalidation_tests.md",[77,103,117,132,144,157],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":96,"publishedAt":22},"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",[83,88,91],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":89,"categoryName":90,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":92,"categoryName":93,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[97,98,99,100,101,102],"writing skills","writing","use","editing","work","deployment",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":111,"publishedAt":22},"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",[109,110],{"categoryNo":89,"categoryName":90,"taxonomyType":86,"taxonomyTypeDesc":87},{"categoryNo":92,"categoryName":93,"taxonomyType":94,"taxonomyTypeDesc":95},[112,113,98,114,115,99,20,116],"plans","writing plans","requirements","task","spec",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":125,"publishedAt":22},"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",[123,124],{"categoryNo":89,"categoryName":90,"taxonomyType":86,"taxonomyTypeDesc":87},{"categoryNo":92,"categoryName":93,"taxonomyType":94,"taxonomyTypeDesc":95},[126,127,128,129,130,131,98],"docs:write concisely","write","docs","read","Rules","documentation",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":22},"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",[],[134,139,18,140,141,142,143],"why","issue","five whys","analysis","root cause analysis",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":150,"publishedAt":22},"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",[],[151,152,153,154,20,155,156],"verification loop","verification","loop","sessions","claude code sessions","system",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":163,"publishedAt":22},"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",[],[164,152,165,101,99,166,167,168],"verification before completion","commands","evidence","claim","complete"]