---
name: no-comments
description: "Comment Sicko를 생성하고, 수락된 발견 사항을 수정하고, 주장된 제약 조건에 대한 인코딩을 제공하세요."
disable-model-invocation: true
---

# No comments

Comment Sicko를 생성하세요. 수락된 발견 사항에 대해 조치하세요.

Comment Sicko의 신선한 관점을 따르세요.

## 범위

호출자의 파일 또는 diff를 사용하세요. 그렇지 않으면 작업 트리를 포함하여 기본 브랜치 (기본값 `main`)에 대한 현재 diff를 사용하세요.

## 단계

1. `subagent_type: "comment-sicko"`로 `Task`를 생성하세요. 범위를 전달하세요. **poteto-mode** 스킬의 Subagents 섹션에 따라 작업에 대한 각 서브에이전트의 추론 수준과 빠른 또는 표준 속도를 선택하세요. 규칙을 재진술하지 마세요.
2. 보고서와 diff를 검사하세요. 애플리케이션 코드 편집, 범위 이탈, 예외 보호 삭제, 잘못 진술된 `MUST KILL` 이유, 보관된 의도적 코드를 유죄로 취급하는 플래그를 거부하세요. 우리 코드 놀라움에 대한 재형성 플래그는 실행 가능한 상태를 유지합니다. 해당 주석을 복원하지 마세요. keep는 우리가 변경할 수 없는 것에 관한 것이라는 증거로만 살아남습니다. 누락된 범위 린트 및 TypeScript 억제를 감사하세요. 정확성 또는 안전 억제는 실행 가능한 `MUST KILL`로 남습니다. 정확한 예외와 범위 증거로만 삭제를 복원하세요. 얇은 `IMPORTANT` 또는 `do not remove` kill 또는 keep를 수락하기 전에 해당 심볼에 대해 `/how` 또는 `/why`를 실행하세요. kill이 모호하면 복원하지 마세요. keep가 반박되거나 여전히 모호하면 삭제하세요. 거부된 보고서를 실패로 명명하여 되돌리고 다시 실행하세요. 두 번째를 거부하고, 열려 있다고 보고하고, `/no-comments`를 실패하세요.
3. 죽은 경로를 삭제하거나, 매개변수를 삭제하거나, 실제 API를 사용하여 사소한 수락된 플래그를 직접 수정하세요. 수정이 형태가 필요하면 수락된 세트와 주변 코드에 대해 한 번 `/architect`를 실행하세요. 스케치에서 멈추세요. Architect가 형태를 잡습니다. 4단계가 구현합니다.
4. 범위 내에서 가장 작은 근본 원인 수정을 구현하세요. 명명된 모든 해결책을 제거하세요. 근본 원인이 범위 밖이면 범위 내 가장 작은 수정을 착륙시키고 나머지를 열려 있다고 보고하세요. **principle-fix-root-causes**와 **principle-redesign-from-first-principles** 스킬은 의도만 안내합니다. 둘 다 울타리를 넓히거나 울타리 외부의 인스턴스를 수정하는 것을 승인하지 않습니다. 증상 가드를 절대 볼트로 고정하지 마세요.
5. 제약 주석은 `do not remove`, `do not change wording`, 또는 `talk to X before changing`이라고 말합니다. 우리가 변경할 수 없는 것에 관한 keep를 남기세요. 범위 내 가장 저렴한 타입, 런타임, 테스트 또는 CI 린트를 제공하세요. 대화형 승인을 기다리세요. 무인 및 평가는 호출자 사전 승인이 필요합니다. 승인되면 인코딩한 다음 삭제하세요. 그렇지 않으면 삭제하고, 제약을 열려 있다고 보고하고, 범위 밖 작업을 스케치하세요.
6. 삭제 카운트, 복원된 주석, 재실행, architect 스케치, 수정, 인코딩 제공, 인코딩, 강제되지 않은 제약 조건 및 기타 열린 작업을 보고하세요.