본문으로 건너뛰기
cccskills
무료GitHub에 공개

distill

Cut the branch down to what the code cannot say: reuse what exists, remove duplication, dead code, and wasted work, turn invariants into asserts, and delete the comments the code already speaks. Run it after answering review feedback too — a fix written to satisfy a reviewer is the least distilled code on the branch.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

wado-lang/wado스타 119(GitHub 119 + cccskills 0)

실행 점수 미검증

설치 방법 보기

포함된 파일(1)

  • SKILL.md4.8 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Distill

Scope

B=$(git merge-base origin/main HEAD)
scripts/changed-sources.sh              # the files, one per line
git diff "$B" --stat -- $(scripts/changed-sources.sh)
git diff "$B" -- $(scripts/changed-sources.sh)

Every file that reports, whatever its type, plus any doc it made stale. Whatever you notice on the way in is in scope too, pre-existing or not. A WEP keeps the sections docs/AGENTS.md requires.

Generated files are the one exclusion, and the script is what applies it: .gitattributes marks them linguist-generated, so a new generated path is excluded the moment it is marked and nothing here lists paths a second time. A plain git diff buries the branch under them — on a generator change they outnumber the sources five to one. Read the sources; regenerate the rest.

This is the scope on every run. Distilling again means the whole branch again, never the diff since the last distill: an earlier pass is not a clean bill, and what the code between the two commits made stale is spread across everything the branch touched.

Answering review feedback is one of the times to run it. Such a fix is written to satisfy a reviewer rather than to fit the code, so it arrives with the reviewer's framing in its comments, an explanation of the bug beside the fix, and often a helper the codebase already had.

Rules

Distilling keeps what the code does. The only change of behaviour it makes is a bug fix, and a bug fix starts from a failing test.

Code

  • Reuse: don't re-implement what the codebase already has. Grep the shared modules and the files next to the change, and call the existing helper.
  • Duplication: one behaviour, one implementation. Hoist the shared part of near-copies behind the difference — a parameter, a closure, an enum. Don't abstract a single use.
  • Altitude: a special case layered on shared infrastructure means the fix sits too shallow. Generalize the mechanism instead.
  • Dead code: delete what the change left behind.
  • Efficiency: cut wasted work — recomputation, repeated I/O, independent work run in sequence. A stored closure pins everything it captured; prefer a struct holding only the fields it needs.
  • Contracts, not defences: a function states what it requires and trusts its callers. Defensive programming is banned. A default or a fallback whose validity you cannot argue is the smell. It turns a broken call into a wrong answer that no test will catch. Write assert! for what the caller owes and unreachable! for the arm that cannot happen, and say which caller establishes it where that is not obvious. A branch that genuinely can happen is control flow and stays; the ban is on inventing an answer for a case you have not shown to be reachable.

Comments

Apply AGENTS.md § General Rules to every comment in scope. A comment saying what the code does is a rename or a decomposition to make. A comment stating an invariant is an assert to write. A comment that carries no information is deleted outright.

Markdown

Apply the markdown skill to every Markdown file in scope.

In an instruction file (an AGENTS.md, a skill), also cut a rule that is trivially deduced from a principle the file or the root AGENTS.md already states: detail dilutes the rules that matter. Keep one that fences a principle against a reading broader than intended.

Cut words, never a fact. A measurement, a name to grep for (a pass, a type, a function), a condition or an exception, and the bug behind a rule are facts, not detail. Before removing a passage, grep for what links to it. Keep a code block runnable on its own: every name it uses defined in it, every command and path real. Run only a block without side effects to check it.

Sweep by shape

A copy does not share a name, so grepping the name finds nothing.

For every predicate or helper the branch adds or moves, grep the tree for what its body looks like rather than what it is called. Two or three tokens of the body carry further than a signature.

Finish the sweep in the same pass. Fixing the sites a reviewer named and calling it a class fix leaves the rest standing, and the next review returns them one at a time.

Cycle

Three passes over that scope; surviving one is no exemption. Stop when a pass finds nothing to cut.

Finish

mise run format

Code edits: run the tests covering what you touched (mise run test, mise run test-wado). Comment, doc, and Markdown edits alone need only mise run check, which holds the specification's examples to their fixtures.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

benchmark

무료

Measure Wado's performance or the size of the Wasm it generates, and refresh the benchmark/ and wasm-size/ README files. Use for any benchmarking or size-measurement request, whichever benchmark it names.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

wado-lang/wado1192026년 10월 26일 업데이트

ci-timing

무료

Measure how long GitHub Actions jobs and steps took across past runs, and find the pull request that made CI slower. Use for any question about CI duration, a slow job, or when CI got slow.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

wado-lang/wado1192026년 10월 26일 업데이트

How to answer code review feedback — a human reviewer, CodeRabbit, or any review bot. Verify the findings, report the classes they are instances of to the user before fixing, then fix the class rather than the sites named. Put design decisions to the user, then run /distill. Invoke when responding to review comments on a pull request, or to the findings of a /code-review run.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

wado-lang/wado1192026년 10월 26일 업데이트

Investigate and improve code coverage for the wado-compiler crate. Use for any question about what the tests do and do not reach, dead code included.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

wado-lang/wado1192026년 10월 26일 업데이트

cr

무료

Review the branch with /code-review at high, then answer the findings with /code-review-response.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

wado-lang/wado1192026년 10월 26일 업데이트

debugger

무료

Use rust-gdb to inspect variables and step through code without modifying it. Prefer it over print debugging for any investigation into what the compiler is actually doing (lldb is unavailable on Claude Code Web).

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

wado-lang/wado1192026년 10월 26일 업데이트

wado-lang의 스킬 모두 보기

이 스킬의 문제 신고