القائمة
어려운 버그와 성능 회귀(regression)를 위한 체계적 진단 루프. 재현 → 최소화 → 가설 → 계측 → 수정 → 회귀 테스트. 사용자가 "진단해줘" / "디버그해줘"라고 하거나, 버그를 보고하거나, 뭔가 깨졌다/throwing/실패하고 있다고 말하거나, 성능 회귀를 설명할 때 사용.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
구현 완료 후 commit→push→PR→review→merge→cleanup 파이프라인을 자율 오케스트레이션할 때 사용. T0~T7 절차를 순서대로 실행하고 T3는 pr-create, T4는 pr-review skill에 위임한다. 중단 조건 도달 시 사용자에게 보고.
Memory/docs 동기화형 grill. 계획/설계를 압박 테스트하면서 active memory, docs, 코드에 맞춰 용어·결정·현재/미래 상태를 즉시 정리. 사용자가 "grill me", "그릴링", "grill with memory", "memory/docs 반영하며 grill", "결정 문서화하면서 그릴링"을 요청할 때 사용.
Simplifies code for clarity. Use when refactoring code for clarity without changing behavior. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity. 사용자가 "단순화해", "깔끔하게 만들어", "리팩토링", "/code-simplify"라고 할 때 트리거. 동작은 보존하고 가독성·유지보수성만 개선.
대화 중 합의된 결정, 룰, 적용 원칙을 repo memory/docs의 올바른 SOT에 저장. 사용자가 remember skill 실행을 요청하거나 "기억해"라고 말할 때 사용.
Multi-agent Planner-Generator-Evaluator harness with sprint-based workflow and contract system. Produces high-quality features by separating planning, implementation, and evaluation into distinct agents with a feedback loop. Usage: /harness <feature-description>
레드-그린-리팩터 루프를 사용하는 테스트 주도 개발. 사용자가 TDD로 기능을 만들거나 버그를 수정하고 싶거나, "레드-그린-리팩터"를 언급하거나, 통합 테스트를 원하거나, 테스트 우선 개발을 요청할 때 사용.
| name | diagnose |
| description | 어려운 버그와 성능 회귀(regression)를 위한 체계적 진단 루프. 재현 → 최소화 → 가설 → 계측 → 수정 → 회귀 테스트. 사용자가 "진단해줘" / "디버그해줘"라고 하거나, 버그를 보고하거나, 뭔가 깨졌다/throwing/실패하고 있다고 말하거나, 성능 회귀를 설명할 때 사용. |
어려운 버그를 위한 규율. 명시적으로 정당화될 때만 단계를 건너뛰어.
코드베이스를 탐색할 때, 프로젝트의 도메인 용어집을 사용해서 관련 모듈에 대한 명확한 멘탈 모델을 만들고, 건드리는 영역의 ADR을 확인.
이게 핵심 스킬. 나머지는 다 기계적. 버그에 대한 빠르고 결정적이며 에이전트가 실행 가능한 pass/fail 신호가 있다면, 원인을 찾을 수 있어 — 이분법, 가설 검증, 계측은 모두 그 신호를 소비할 뿐. 신호가 없다면, 코드를 아무리 째려봐도 구원받지 못해.
여기에 비례적으로 큰 노력을 쏟아. 공격적으로. 창의적으로. 포기하기를 거부해.
git bisect run으로 실행 가능하게..agents/skills/diagnose/scripts/hitl-loop.template.sh로 _사람_을 구동해서 루프가 구조화되도록. 캡처된 출력이 너에게 피드백.올바른 피드백 루프를 만들면, 버그는 90% 수정된 셈.
루프를 제품처럼 다뤄. 일단 어떤 루프든 만들었으면, 자문해:
30초짜리 flaky 루프는 루프가 없는 것보다 약간 나을 뿐. 2초짜리 결정적 루프는 디버깅 슈퍼파워.
목표는 깔끔한 재현이 아니라 재현률 상승. 트리거를 100× 반복, 병렬화, 스트레스 추가, 타이밍 윈도우 좁히기, sleep 주입. 50% flake 버그는 디버깅 가능. 1%는 안 됨 — 디버깅 가능할 때까지 비율을 올려.
멈추고 명시적으로 말해. 시도한 것을 나열해. 사용자에게 요청: (a) 재현되는 환경 접근권, (b) 캡처된 아티팩트 (HAR 파일, 로그 덤프, core dump, 타임스탬프 있는 화면 녹화), 또는 (c) 임시 프로덕션 계측 추가 허가. 루프 없이 가설로 진행하지 마.
믿을 수 있는 루프가 생기기 전까지 Phase 2로 진행하지 마.
루프 실행. 버그가 나타나는 것을 봐.
확인:
버그를 재현하기 전까지 진행하지 마.
검증 전에 3-5개의 순위가 매겨진 가설을 생성. 단일 가설 생성은 첫 번째 그럴듯한 아이디어에 닻을 내림.
각 가설은 반증 가능해야 함: 그것이 만드는 예측을 진술해.
형식: "만약 가 원인이라면, <Y를 바꾸면> 버그가 사라질 것 / <Z를 바꾸면> 더 나빠질 것."
예측을 진술할 수 없다면, 가설은 그냥 vibe — 버리거나 날카롭게.
검증 전에 사용자에게 순위 리스트를 보여줘. 도메인 지식으로 즉시 재순위 매길 수 있음 ("3번에 방금 변경 배포했어"), 또는 이미 배제한 가설을 알 수도 있음. 저렴한 체크포인트, 큰 시간 절약. 사용자가 자리에 없으면 막히지 말고 — 너의 순위로 진행.
각 프로브는 Phase 3의 특정 예측에 매핑되어야 함. 한 번에 한 변수만 변경.
도구 선호:
모든 디버그 로그에 태그, 예: [DEBUG-a4f2]. 끝에 정리할 때 grep 한 번으로 끝남. 태그 없는 로그는 살아남음. 태그 있는 로그는 죽음.
성능 분기. 성능 회귀의 경우, 로그는 보통 틀림. 대신: 베이스라인 측정 확립 (타이밍 하니스, performance.now(), 프로파일러, 쿼리 플랜), 그 다음 이분법. 측정 먼저, 수정 나중.
회귀 테스트를 수정 전에 작성 — 단, 올바른 seam이 있을 때만.
올바른 seam이란 테스트가 호출 지점에서 발생하는 실제 버그 패턴을 실행하는 곳. 사용 가능한 seam이 너무 얕다면 (버그가 여러 호출자를 필요로 하는데 단일 호출자 테스트, 버그를 트리거한 체인을 복제할 수 없는 단위 테스트), 그곳의 회귀 테스트는 거짓 자신감을 줌.
올바른 seam이 없다면, 그 자체가 발견. 기록해. 코드베이스 아키텍처가 버그를 잡아두는 것을 막고 있는 것. 다음 단계를 위해 표시.
올바른 seam이 있다면:
완료 선언 전 필수:
[DEBUG-...] 계측 제거됨 (grep으로 prefix 확인)그 다음 자문: 무엇이 이 버그를 예방했을까? 답이 아키텍처 변경 (좋은 테스트 seam 부재, 얽힌 호출자, 숨은 결합)을 포함한다면 구체적인 내용과 함께 /improve-codebase-architecture 스킬로 넘겨. 권장은 수정이 들어간 후에 — 시작할 때보다 더 많은 정보가 있어.