understand-change
The understand-change skill teaches users to achieve deep comprehension of code modifications through structured, interactive tutoring. It identifies the relevant change, builds a checklist covering problem, solution, and context, then guides the user incrementally through each item by having them restate understanding first, filling gaps with progressively detailed explanations, showing relevant code, and confirming mastery with open-ended quizzes before advancing. Use this when learners request thorough instruction on understanding a change, commit, PR, or modification rather than wanting a quick summary.
git clone --depth 1 https://github.com/tobihagemann/turbo /tmp/understand-change && cp -r /tmp/understand-change/claude/skills/understand-change ~/.claude/skills/understand-changeSKILL.md
# Understand Change Act as an effective teacher whose goal is the user's deep understanding of a change. Work incrementally, confirm mastery at each stage before advancing, and keep going until the user has demonstrated understanding of everything on the checklist. ## Step 1: Identify the Change Pick the subject in priority order: 1. A commit, PR, or path passed as an argument — use that 2. The work produced in the current session — use that 3. Uncommitted work from `git status` and `git diff` — use that 4. The most recent commit when nothing else is in scope When the guess is not obvious, name what was picked so the user can redirect before teaching starts. ## Step 2: Build the Understanding Checklist Read the change in full: the diff, the touched files, related code, and any commit messages, plan, or PR description that explain intent. Then write a running checklist to `.turbo/understand/<slug>.md` where `<slug>` describes the change. Use a checkbox per item, grouped into three sections: - **Problem** — what the problem was, why it existed, and the alternative approaches that were on the table. - **Solution** — what the change does, why it was resolved this way, the design decisions, and the edge cases. - **Context** — why this matters and what the change impacts elsewhere. Cover both high level (motivation) and low level (business logic, edge cases). Update this file as the session progresses: check items off only once the user has demonstrated understanding, and add items when teaching surfaces a gap. ## Step 3: Teach Each Item Incrementally Work through the checklist one item at a time. Do not advance to the next item until the user has demonstrated mastery of the current one. For each item: 1. **Have the user restate first.** Ask what they already understand about the item before explaining anything. This reveals where the gaps are. 2. **Fill the gaps from there.** Correct misconceptions and supply what is missing. Drill into why, then the deeper why behind it, and cover what and how as well. 3. **Adjust depth on request.** The user may ask for a simpler explanation, more detail, or a worked walkthrough as if onboarding a new teammate. Match the level they ask for. 4. **Show the evidence.** Display the relevant code, or use the debugger, when seeing it makes the point land. 5. **Confirm mastery by quizzing.** Verify understanding before checking the item off. Pose open-ended recall questions as plain text. For multiple-choice questions, use `AskUserQuestion`: vary the position of the correct answer across questions, and reveal the correct answer only after the question is submitted. If the answer reveals a gap, return to step 2 for that item before moving on. ## Step 4: Confirm Full Mastery The session continues until every checklist item is checked off. When the user signals they want to stop early but items remain, use `AskUserQuestion` to confirm whether to end now or keep going. Once all items are demonstrated, summarize what the user now understands and close out.
For each reviewer question on a PR, recall implementation reasoning and compose a raw answer. Use when the user asks to \"answer reviewer questions\", \"draft answers to PR questions\", or \"explain reviewer questions\".
Apply findings by making the suggested code changes. Applies accepted verdicts, escalates ambiguous findings to the user, and offers to note genuine improvements for later. Use when the user asks to \"apply findings\", \"apply fixes\", \"apply suggestions\", \"apply accepted findings\", \"fix the findings\", or \"apply the review results\".
Project-wide health audit pipeline that fans out to all analysis skills in parallel, evaluates findings, and produces a unified report at .turbo/audit.md. Use when the user asks to \"audit the project\", \"run a full audit\", \"project health check\", \"audit my code\", \"codebase audit\", or \"comprehensive review\".
Shared changelog conventions and formatting rules referenced by $create-changelog and $update-changelog. Not typically invoked directly.
Enforce mirror, reuse, and symmetry principles to keep new code consistent with surrounding code. Use when writing new code in an existing codebase, adding new features, refactoring, or making any code changes.
Run autonomous task execution using the codex CLI. Use when the user asks to \"codex exec\", \"run codex exec\", \"execute a task with codex\", or \"delegate to codex\".
Run AI-powered code review using the codex CLI. Use when the user asks to \"codex review\", \"run codex review\", or \"review a commit with codex\".
Shared commit message rules and technical constraints referenced by $stage-commit and $commit-staged. Not typically invoked directly.