Skip to content

Latest commit

 

History

History
104 lines (82 loc) · 4.18 KB

File metadata and controls

104 lines (82 loc) · 4.18 KB

CLAUDE.md / AGENTS.md / .cursorrules snippet

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.


English

## 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)로 모든
  신규 리포트의 구조를 자동 검사

Customization

  • If your project already has a CLAUDE.md with 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.