القائمة
Five Whys (Toyota): iterate "why?" until you reach a systemic/actionable root cause.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Canonical b00t reviewer capability — adversarial multi-framework code/datum review. Shared across all harnesses (Claude Code, opencode, Hermes, b00t-cli). Loaded via: b00t learn reviewer, or by harness-specific role supplements.
Remove AI-generated artifacts from code. Three-phase certainty-graded cleanup. Use after any AI implementation session or before PR creation.
8-phase agile workflow — strategy→ideate→brainstorm→plan→work→review→compound→pulse. State machine with FOL-guarded transitions, gh-issues backlog, executable just harness. Inspired by everyinc/compound-engineering-plugin.
Australian crypto tax treatment per ATO guidance QC 53725. Crypto assets are CGT assets under ITAA 1997 s 108-5. Each disposal triggers CGT event A1. Covers personal-use exception, trading stock test, and the 50% CGT discount.
Australian R&D Tax Incentive (RDTI) — ITAA 1997 Division 355. Covers eligibility criteria for core and supporting R&D activities, registration with AusIndustry/IP Australia, expenditure categories, offset rates, and the company size threshold test.
Evidence graph construction for tax audit trails. Each Satisfies check emits EvidenceNode structs with Blake3 content hashes. Evidence chains are tamper-evident and link legislative citations to factual findings.
| name | five-whys |
| type | skill |
| hint | Root cause analysis — ask 'why?' 5 times; stops at systemic cause not symptom |
| version | 1.0.0 |
| tags | ["transferable","five-whys","root-cause","rca","why","symptom","systemic","cause","analysis"] |
| tier | sm0l |
| complexity | 2 |
| description | Five Whys (Toyota): iterate "why?" until you reach a systemic/actionable root cause. |
Five Whys (originating from Toyota) is a root cause analysis technique where you iterate "why?" until you reach a systemic, actionable root cause. Each answer becomes the subject of the next "why?" — for example: Bug in prod → why? → test missed it → why? → no test for this path → why? → developer didn't know the path existed → why? → no onboarding doc → why? → we never wrote it. Root cause: missing documentation process.
Fix the root, not the symptom — patching the bug without fixing the process guarantees recurrence. The number 5 is a heuristic, not a law. Stop when you reach something you can actually change. Watch for multiple branches — one "why" may have two answers, diagram both.
Use Five Whys during incident post-mortems, debugging sessions, process improvement, and any time you need to find the underlying systemic cause of a problem rather than treating surface symptoms.
