菜单
Rubber duck debugging: explain the problem to a non-expert (or inanimate object) step by step.
用 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 | rubber-duck |
| type | skill |
| hint | Explain the problem aloud step by step — articulation surfaces hidden assumptions |
| version | 1.0.0 |
| tags | ["transferable","rubber-duck","debugging","articulation","explain","verbalize","assumptions","clarity"] |
| tier | sm0l |
| complexity | 1 |
| description | Rubber duck debugging: explain the problem to a non-expert (or inanimate object) step by step. |
Rubber duck debugging is the practice of explaining a problem to a non-expert (or inanimate object) step by step. The act of articulation forces you to make implicit assumptions explicit. Protocol: (1) Describe what the code/system SHOULD do. (2) Describe what it ACTUALLY does. (3) Describe each step in between, out loud. (4) The bug appears at the step where description and reality diverge.
It works because you know more than you have made explicit — speaking forces serialization of tacit knowledge. Extend the technique by writing the explanation as a comment before the code. If you cannot explain it, you do not understand it. Also applies to planning: "explain the plan" before implementing often reveals the flaw.
Use rubber duck debugging when stuck on a bug, when you cannot figure out why something is not working, or when planning a complex implementation. If you have been staring at the same code hoping the answer appears, use this technique immediately.
