Skip to main content

edit-discipline

Change files with the edit and write tools, never by rewriting them through bash (sed, awk, tee, heredoc, redirection), and show `git diff` before reporting a file-changing task as done. Triggers: edit, write, modify, refactor, patch, fix, diff, review changes.

소스 정보

저장소
softspark/ai-toolkit
최근 소스 활동
2026년 9월 3일 08:42
감지된 SKILL.md 언어
영어
스타
179
포크
21

설치 방법

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

소스 파일 검토

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

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
edit-discipline
description
Change files with the edit and write tools, never by rewriting them through bash (sed, awk, tee, heredoc, redirection), and show `git diff` before reporting a file-changing task as done. Triggers: edit, write, modify, refactor, patch, fix, diff, review changes.
effort
low
user-invocable
false
allowed-tools
Read
# Edit Discipline This rule comes from `app/rules/edit-discipline.md` in ai-toolkit. It applies to every task in this workspace, not only when it is loaded. # Edit Discipline & Reviewable Changes ## Edit files with the editing tools, not the shell Use the `edit` and `write` tools to change a file. Do not rewrite tracked files through `bash` with `sed`, `awk`, `tee`, a heredoc, or `>` redirection. This is not a style preference. A shell rewrite is opaque to the host: the session records a command, not a change. An `edit` call records which file changed and how, so the interface can render it, a reviewer can read it, and a later turn can cite it. A `sed` line records none of that, and the only way to find out what happened is to read the file again. The shell remains correct for what it is for: running builds, tests, linters, git, package managers, and generators that own their own output. ## Show the change before calling the work done Before reporting a file-changing task as finished, show what changed: ```bash git diff -- <paths> # tracked files git status --short # what is new or removed ``` Paste the diff into the reply, or state precisely why it is too large and summarise it by file with the counts. A task that reports success without showing the change asks the reader to take the result on trust, and the reader is the one who has to decide whether to commit it. For an untracked file, show the content you wrote, not a description of it. ## Why both halves matter together Editing through the tools makes a change *recordable*; showing the diff makes it *reviewed*. Either alone leaves the person deciding whether to ship blind to something they are accountable for.
GitHub에서 보기