Stop Chatter은(는) 무엇을 하나요?
사용자가 현재 요청한 내용만 유지하세요. 수정은 작업 대상을 변경해야 하며, 이전 실수에 관한 새로운 콘텐츠가 되어서는 안 됩니다.
가장 가벼운 모드 선택
- Light 모드 (기본값): 일반적인 수정 및 후속 보충에 사용합니다. 작업 컨텍스트에 대상을 유지하고 아래 규칙을 따릅니다. 임시 상태나 기타 워크플로 산출물을 생성하지 마십시오. 이 스킬을 읽거나 채팅에서 계획을 다시 설명하는 것은 전달이 아닙니다. 파일을 변경하세요.
- Guarded 모드: 사용자가 명시적으로 요청한 경우에만 사용하거나, 동일한 철회 항목이 이미 다시 나타났고 검증 범위를 해당 잔여물로 한정할 수 있는 경우에 사용합니다. 전달물을 변경하기 전에 references/protocol.md를 읽고, 한 번 초기화한 후 전달 전에 검사기를 실행하세요.
작업이 길거나, Git을 건드리거나, 여러 파일에 걸쳐 있다고 해서 Guarded로 전환하지 마십시오. 이 수정이 완료된 후에는 일반적인 연속 작업이 Light 모드로 돌아갑니다. 명시적인 미완료 핸드오프가 있는 경우 동일한 작업 상태를 재사용할 수 있습니다. 철회 목록을 영구 메모리에 기록하지 마세요.
전달물에서 Stop Chatter, 준수 모드 또는 수정 내역을 언급하지 마세요. 대화 완료 요약을 유용하게 유지하세요: 사용자가 무슨 일이 있었는지 이해하는 데 필요한 경우 중요한 변경 사항, 검증 및 알려진 제한 사항을 보고하세요.
현재 대상 재컴파일
모든 수정 후:
- 목표를 현재의 긍정적 결과로 다시 작성하세요.
- 여전히 활성 상태인 요구 사항만 유지하세요. 철회된 항목은 삭제되며, 부정적 요구 사항으로 유지되지 않습니다.
- 간결함, 효율성, 과도한 구축 금지와 같은 메타 제약 조건을 분리하세요. 이는 실행 방식을 형성하며 제목, 레이블, UI 텍스트, 버전 이름 또는 영구 환경 설정이 되어서는 안 됩니다.
- 명시적 제외 사항은 부재 자체가 활성 외부 계약, 안전 속성 또는 수용 기준인 경우에만 유지하세요.
잔여물을 제거하기 전에 다시 작성된 대상을 파일에 넣으세요. 이번 라운드에서 언급되지 않았다고 해서 철회된 것은 아닙니다. 하나의 항목을 철회한다고 해서 여전히 활성 상태인 기능을 삭제하거나 프로젝트의 나머지 부분을 정리할 수 있는 권한이 부여되는 것은 아닙니다. 이 단계 후에는 원시 대화를 계속되는 사양으로 사용하지 마세요.
제거할 수 있는 것
명시적으로 철회된 콘텐츠와 가시적 증거가 그것만을 제공하기 위해 존재함을 보여주는 파생물만 정리 집합에 들어갑니다. 기존 파일과 사용자의 이전 편집은 기본적으로 유지됩니다. 여전히 유효한 기능, 안전 속성 및 호환성 계약은 유지됩니다. 파일의 출처가 불분명하면 유지하세요.
기본 산출물이 현재 대상과 일치한 후, 철회된 항목만을 제공하기 위해 존재하는 파생물을 한 번 찾아보세요: 이 수정을 위한 기념성 변경 로그 또는 릴리스 노트, 철회된 항목이 없음을 증명하는 테스트, 거부된 옵션의 기록, 철회된 기능의 이름을 딴 파일. 이 패스는 프로젝트 전반의 정리가 아닙니다.
모호함이 전달을 막는 경우에만 질문하세요. 모든 파일에 확인 단계를 추가하지 마세요.
단순히 수정을 기념하거나 요청되지 않은 항목이 없음을 증명하기 위해 테스트를 추가하지 마세요. 활성 요구 사항으로 인해 해당 부재가 외부에서 관찰 가능하거나 안전에 중요한 경우에만 부정 테스트를 유지하세요. 검사기 자체의 파일 작업 계약 테스트는 남을 수 있습니다.
이번 라운드의 파일 작업 추적
이번 라운드에서 추가되거나 수정된 모든 파일은 적어도 하나의 활성 요구 사항에 매핑되어야 합니다. 경로를 변경하도록 허용한다고 해서 전체 파일을 삭제할 수 있는 권한이 부여되는 것은 아닙니다. 가시적 작업 증거가 해당 제거를 뒷받침하는 경우에만 전체 파일을 삭제하세요.
주석은 여전히 존재하는 코드의 명확하지 않은 속성을 설명합니다. PR 및 릴리스 텍스트는 결과적인 긍정적 상태를 설명합니다. UI는 사용자 대면 제품 콘텐츠를 포함하며, 내부 요구 사항이나 수정 내역을 포함하지 않습니다. 사용자나 릴리스 프로세스에서 요구하지 않는 한 버전 번호, 불변 릴리스 주장, 해시 또는 추가 의식을 추가하지 마세요.
메모리 깔끔하게 유지
수정 사항을 기본적으로 작업 로컬로 처리하세요. 사용자가 명시적으로 영구 메모리를 요청하거나 안정적인 교차 작업 선호도를 명확히 밝힌 경우에만 하나를 유지하세요. 긍정적인 추상적 동작과 범위를 저장하고, 거부된 예제는 저장하지 마세요. 편집 후, 남은 파일(메모리 포함)에서 철회된 항목과 다른 언어 또는 근접한 이름의 별칭을 스캔하고 해당 흔적만 제거하세요.
Guarded 검사
Guarded 모드에서 전달물을 변경하기 전에 초기화하세요. 이 루트에 대해 유효한 작업 상태가 이미 존재하면 재사용하고 덮어쓰거나 시작 기준선을 재설정하지 마세요. 상태가 유효하지 않거나 다른 루트에 속하는 경우 재사용하거나 교체하는 대신 중지하세요.
python3 <skill-dir>/scripts/stop_chatter.py init --root .
템플릿 값을 현재 대상, 가장 좁은 추가/수정 경로, 가시적 증거로 뒷받침되는 정확한 must_remove 경로, 철회된 레이블 및 별칭, 메타 명령 누출 마커로 대체하세요. init으로 캡처된 기준선을 편집하지 마세요. 해당 값이 최신 상태가 된 후에만 ready를 true로 설정하세요. 그런 다음 한 번 검사하세요:
python3 <skill-dir>/scripts/stop_chatter.py check --root . --cleanup-state-on-pass
성공 시, 이 동일한 명령어는 .stop-chatter/state.json만 제거합니다. 두 번째 성공적인 검사나 별도의 정리 명령어를 실행하지 마세요. 해석기 캐시, 테스트 캐시 또는 기타 사용자 파일을 "상태 정리"를 위해 삭제하지 마세요. 실패 시 상태는 보존됩니다. 증거가 있는 범위 또는 잔여물 문제만 수정한 후 최대 한 번 다시 실행하세요.
검사기는 보고만 합니다. 전달물을 삭제하거나 복원하지 않으며, 제품 소유권을 결정하지 않습니다. 통과는 구성된 검사가 통과했음을 의미할 뿐, 구현이 올바르거나 아무것도 남지 않았음을 의미하지 않습니다.
활성 핸드오프가 여전히 상태를 필요로 하는 경우 --cleanup-state-on-pass를 생략하고 해당 핸드오프가 종료될 때 파일을 제거하세요. 일시적인 철회 원장을 절대 메모리로 승격시키지 마세요.
설치 경로 및 호스트별 호출에 대해서는 설치 또는 발견 진단 시에만 references/host-setup.md를 읽으세요.
결과 전달
파일이 현재 대상과 일치할 때만 중지하세요. 요청된 산출물과 사용자가 중요한 변경 사항, 검증 및 알려진 제한 사항을 이해할 수 있는 충분한 완료 정보를 반환하세요. 단순히 응답을 깔끔하게 보이게 하기 위해 유용한 상태를 억제하지 마세요. 산출물 자체는 현재 상태 언어로 유지하세요: 수정된, 깔끔한, 간결한, X-없음, 또는 최종 상태 버전이라고 부르지 마세요. 응답에서 사용자가 감사 추적을 요청하거나 제거가 범위, 마이그레이션, 안전성 또는 호환성에 실질적으로 관련된 경우에만 제거된 기록을 언급하세요.