Skip to main content

walkthrough

Two-minute guided tour of the latest change so the user understands what changed and why, not just that it works. Before/after behaviour on a concrete example, the few lines that matter and why each exists, a predict-then-reveal question, and an optional small "your turn" variation.

소스 정보

저장소
pipeshub-ai/sharp
최근 소스 활동
2026년 10월 15일 14:15
감지된 SKILL.md 언어
영어
스타
4
포크
0

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
walkthrough
description
Two-minute guided tour of the latest change so the user understands what changed and why, not just that it works. Before/after behaviour on a concrete example, the few lines that matter and why each exists, a predict-then-reveal question, and an optional small "your turn" variation.
argument-hint
[file, commit, or 'last change']
allowed-tools
Bash(git diff *) Bash(git log *) Bash(git show *) Read Grep Glob Bash(node ~/.sharp/bin/sharp.mjs *)
# /sharp:walkthrough: understand what changed and why Target: `$ARGUMENTS`, or the most recent change in this session. If nothing changed in this session, use `git diff` / `git diff HEAD~1`. Teach the change the way a good senior would at a desk, **one step at a time, waiting at each question**. Keep each step to ≤ 5 lines. 1. **Before → after, on one concrete example.** Pick a real input and show what happened before and what happens now: `checkoutTotal([0.10, 0.20])`: before `0.30000000000000004`, now `0.30`. Then say in one line *why* the old behaviour happened (the root cause, not the symptom). 2. **The lines that matter.** Show only the 1–3 changed lines (or hunks) that do the real work, quoted from the diff. For each: what it does, and **what would break without it**. Skip boilerplate, renames and formatting. 3. **Predict, then reveal.** Ask the user to predict the result for a slightly different input that exercises the key line (an edge case is best): "What does it return for 15% off 4.35 × 3?" Wait. Then reveal and explain any gap. If you can, run it (`node -e`, tests) so the answer is observed, not asserted. 4. **Context check.** One line: where this approach is right, and where it would be wrong ("integer cents suit currency; scientific averages need full precision"). 5. **Your turn (optional, offer once).** A tiny variation for them to make themselves: "Add a 'round down for refunds' rule; I'll review it." If they accept, review their change kindly and specifically. Finish by asking for their one-line **Next time** rule, refine it with them, and save it: ```bash node ~/.sharp/bin/sharp.mjs lesson add --topic "<area>" --when "<signals>" --context "<where it holds>" --unless "<boundary>" --principle "<what to do>" --why "<because>" --source "walkthrough: <change>" ``` For non-code changes (a contract redline, a policy edit, an analysis), use the same steps: before and after on a concrete scenario, the clauses or lines that matter and the risk each one handles, a predict question ("which party bears the loss now if…?"), and the context check.
GitHub에서 보기