Drop this into your project's instruction file so that any AI coding assistant uses the 5-section response format on every code change.
Provided in English and 한국어. Pick one or include both.
For the full working rules, see working-rules.md
(EN) or working-rules.ko.md (KR). The snippet
below is the short version meant to live inline in CLAUDE.md; the full
rules file is referenced for details.
## Working Rules (mandatory)
- Do not report completion without verification.
- Do not modify things outside the requested scope (no unrequested
refactors, renames, or restructures).
- Do not present guesses as facts. If you cannot verify, explicitly say
"unverifiable" with the specific reason.
- Response format for code-change work: 1. Root cause 2. Change
3. Recurrence prevention 4. Verification 5. Remaining risk
(does not apply to pure Q&A or investigation-only work)
- Full rules: ./docs/working-rules.md — read before modifying code.
### Verification result (section 4)
- Record only what you actually ran.
- Pre-agreed "unverifiable" items: dev server, paid API real calls, real
renders/deploys, browser e2e. Anything else must have a specific reason.
### Remaining risk (section 5)
- Regression risks and unverified areas only.
- NOT wishlist, NOT follow-up improvements, NOT "could be stronger".
- If nothing applies, write "None".
### Recurrence prevention (section 3)
- Every meaningful fix must include at least one of: root-cause fix,
guardrail, regression test, or failure-visibility logging.
- Temporary hotfixes must label section 3 as "intentional omission" with
the reason.
### Verification report artifact (optional but recommended)
- For ticket-sized work, also persist the 5 sections as a file under
`plans/<ticket-id>-verification-report.md`.
- Run `npx tsx scripts/check-reports.ts` (from leceipts)
to enforce the structure on every new report.## Working Rules (필수)
- 검증 없이 완료 보고 금지
- 요청 범위 외 수정 금지 (리팩토링·네이밍·구조 개편 임의 금지)
- 추측을 사실처럼 말하지 말 것; 실행 불가 시 "검증 불가 (사유)"로 명시
- 코드 변경 작업의 응답 형식: 1.원인 2.수정 3.재발방지 4.검증 5.리스크
(단순 질의 제외)
- 상세 규칙: ./docs/working-rules.ko.md — 코드 수정 전 필독
### 4번 칸 (검증 결과)
- 실제로 실행한 것만 기록
- 사전 합의된 "검증 불가" 항목: dev 서버, 유료 API 실호출, 실 렌더/배포,
브라우저 e2e. 이 외 사유는 구체적으로 명시.
### 5번 칸 (남은 리스크)
- 회귀 가능성·미검증 영역만
- wishlist·후속 개선·"더 강화하면 좋을 것"은 금지
- 진짜 없으면 "해당 없음"이라고 쓸 것
### 3번 칸 (재발 방지)
- 모든 의미 있는 수정은 다음 중 하나 이상을 포함: 근본 원인 수정,
가드레일 추가, 회귀 테스트, 실패 가시성 로깅
- 임시 핫픽스는 3번 칸에 "의도적 생략 (사유)"로 명시
### Verification report 산출물 (선택이지만 권장)
- 티켓 단위 작업이면 5단을 파일로 저장:
`plans/<티켓-ID>-verification-report.md`
- `npx tsx scripts/check-reports.ts` (leceipts)로 모든
신규 리포트의 구조를 자동 검사- If your project already has a
CLAUDE.mdwith a "Working Rules" section, merge the bullets above into it rather than duplicating. - The "unverifiable whitelist" is pre-agreed by default. Add or remove items to match your actual environment — for example, if you don't use paid APIs at all, remove that line; if you have a staging deploy that is safe to trigger, remove "real deploys" from the whitelist.
- If you do not want to maintain verification-report files (section "Verification report artifact" above), delete that paragraph. The 5-section response format still works on its own as a response convention, without persisting files.
- The full working-rules.md lives in
docs/. Reference it from your CLAUDE.md so the assistant can pull it into context when needed.