스코빌 플랜 (Scoville Plan)은(는) 무엇을 하나요?
계획 CLI, MCP 서버, 데이터베이스, 일지, 숨은 상태 없이도 검토 가능한 리포지토리 파일로 프로젝트 방향을 유지하세요. 이 스킬은 계획 수련(planning discipline)과 네이티브 Plan 및 Decision 유지를 책임집니다. 인간이 이미 내린 선택을 기록하고, 중요한 미해결 선택은 수명주기 결정을 요청하기 전에 제안(proposal)으로 보존합니다. 추론된 선택에 권한을 부여하거나 보고된 작업이 실제로 수행되었음을 증명하지 않습니다.
지원되는 format_version: 1 기능 표면 전체를 유지하세요: 읽기 전용 복구, 설정, Plan, Work Item, Decision, 제안, 수명주기, 블로커, 증거, 제한적 수정. 프로젝트 지식 기능을 제거하거나 재해석하지 않고 직접 네이티브 편집을 사용하세요.
명시적 옵트아웃 시에는 참조를 읽거나 계획 파일을 생성/변경하거나 스킬 기반 주장을 하지 마세요. 더 높은 우선순위의 프로젝트 명령이 이 Plan 시스템을 요구하는 경우, 그 정확한 충돌을 보고하세요. 형제 스코빌의 옵트아웃은 해당 형제에만 적용됩니다.
기존 소유자를 따르세요
계획 요구사항을 다음 순서로 해결하세요:
- 현재 요청에 대한 시스템, 안전, 명시적 지침;
- 리포지토리 지침 및 기존 표준 계획 메커니즘;
- 기존 지원되는 네이티브 프로필; 그리고
- 이 스킬의 기본값 (나머지 미지정 사항에 대해).
프로젝트 소유 계획 옆에 두 번째 계획을 절대 만들지 마세요. 다른 내구성 있는 계획 시스템이 이미 상태를 소유하고 있다면 그것을 사용하고, 이 스킬의 계획 품질 가드레일만 호환되는 범위 내에서 적용하세요. 런타임 계획은 일회용 미러(disposable mirror)이며, 두 번째 표준 소유자가 아닙니다.
이 스킬은 필수 실행 가능 의존성이 없으며 계획 CLI를 호출하지 않습니다. 번들된 파이썬 검증기는 선택적이며 엄격히 읽기 전용 구조 검사입니다. 쓰기 경로가 아닙니다. 잠금, 원자적 다중 파일 게시, 타입화된 변경 안전성, 또는 의미론적 증명을 주장하지 마세요. 일반적인 범위의 파일 도구를 사용하고 실제로 수행된 검사만 보고하세요.
이 스킬은 독립적으로 작동합니다. Code, UI, 또는 Scribe를 요구하거나 설치하거나 시뮬레이션하지 마세요. 형제가 독립적으로 적용 가능한 경우, 해당 형제가 소유한 구현, 인터페이스, 또는 표현 문제만 구성하세요; 형제가 없어도 Plan 구조, 수명주기, 권한, 또는 증거 규칙이 약화되지 않습니다.
내구성 있는 계획이 필요한지 결정하세요
리포지토리 Plan은 여러 종속 결과, 물리적 순서 지정, 중단이나 인계를 견뎌야 하는 작업, 또는 바인딩된 프로젝트 워크플로에 사용하세요. 하나의 작고 되돌릴 수 있는 변경의 경우, 프로젝트에서 이미 추적된 Work Item을 요구하지 않는 한 직접 구현하고 검증하세요.
세부 정보를 로드하기 전에 작업을 분류하세요:
읽기 전용 상태 응답을 위해 형식 세부 정보를 미리 로드하지 마세요.
프로필 존재 여부를 모를 경우, 표준 경로를 읽기 전에 프로젝트 루트를 나열하세요. PROJECT_INDEX.md 가 없으면 읽기를 시도하지 마세요. 명시적으로 요청된 새로운 내구성 Plan의 경우, 현재 작업 공간을 설정 루트로 취급하고 전체 프로필을 분류한 후 세 가지 표준 경로가 모두 완전히 없을 때만 초기화하세요. 생성이 요청되지 않은 경우, 프로필이 존재하지 않음을 보고하고 암시적으로 초기화하지 마세요. 부분적이거나, 외부적이거나, 지원되지 않거나, 의도가 유효하지 않은 프로필은 보존하고 중지하세요.
권한과 증거를 보존하세요
- 목표, 비목표, 수용 결과, 블로커, 의존성, 증거, 또는 수락된 수명주기 선택을 절대 만들어내지 마세요. 구현, 일반 문서, 소스 코드, 침묵, 현재 동작을 증거로 취급하되, 인간의 승인으로 취급하지 마세요.
- 활성화, 취소, 범위 변경, 약한 수용, 모호한 후속 작업, 또는 단지 가능한 물리적 선택을 채택하기 전에 물어보세요.
- 사용자가 명시적으로 방향을 선택하거나, 프로젝트 규칙에 보존해 달라고 요청하거나, 적용 가능한 프로젝트 명령이 인간이 선택한 방향을 명백히 나타내는 경우, 다시 묻지 않고 해당 Decision을 생성하고 수락하세요. 영향을 받는 모든 변경 가능한 Work Item을 연결하세요.
- 분석 결과 범위, 아키텍처, 공개 동작, 저장 데이터, 보안, 의존성, 되돌리기 가능성, 수용, 마이그레이션, 또는 롤아웃에 관한 중요한 가능한 Decision만 드러날 경우, 이를
proposed로 생성하고, 영향을 받는 모든 변경 가능한 Work Item을 연결하고, 권장 사항, 대안, 트레이드오프, 실제 효과를 보고한 후 사용자에게 수락, 거절, 또는 개정을 요청하세요. 그 응답 전에는 수락하지 마세요. - 제안 초안 작성 요청은
proposed를 생성합니다. 명시된 방향을 기록하겠다는 명확한 선택은 수락을 승인합니다. 명시적인 수명주기 선택 없이 Decision을 거절, 폐기 또는 대체하지 마세요. - 프로젝트 작업 시작 시, Decision 프론트매터를 목록화하고, 모든 제안을 읽고, ID, 제목, 권장 선택, 실제 효과를 보고하고, 사용자에게 수락, 거절, 또는 개정을 요청하세요. 인계 시 미해결 제안을 반복하세요. 의존 작업만 중단됩니다.
- Work Item을
done으로 표시하는 것은 수용 결과를 관찰하고 간결한 증거를 추가한 후에만 가능합니다. 파일 형태 검사는 구조만 증명합니다. - 실패하거나 부분적인 작업은
in_progress,paused, 또는 명시적으로blocked상태로 유지하세요.
행동이 완전한 Work Item을 유지하세요
in_progress인 Work Item은 최대 하나만 유지하고, 이는current_item과 같아야 합니다. 이는 동시 실행을 제한할 뿐, 전체 Plan의 Work Item 수를 제한하지 않습니다.- 독립적으로 재개 가능한 결과를 별도의 Work Item으로 분할하세요. 각 결과는 고유한 수용 경계, 의존성, 소유자, 또는 롤아웃 시점을 가져야 합니다.
- 구현 순서는 선택적 Steps 내에 유지하세요. 테스트, 리뷰, 문서화, 릴리스 검사는 별도로 요청된 전달물이 자체 재개 가능한 결과를 필요로 하지 않는 한 수용(Acceptance) 또는 증거(Evidence)에 속합니다.
- 항목이
todo인 경우에만 작성된 내용이나 순서를 변경하세요. 시작 후에는 시작 접근 방식을 보존하고 라이브 상태만 업데이트하세요. Next action은 아직 수행되지 않은 첫 번째 구체적 조치와 같게 유지하세요. 구현이 존재하면, 다음으로 관찰되지 않은 테스트, 빌드, 브라우저 검사, 리뷰, 또는 평가자 소유 검증으로 진행하세요.- 새 현재 작업은 해당 의존성이 완료되고 후속 작업이 명시적일 때만 선택하세요.
complete_and_advance는 완료와 정확한 대체 시작이 모두 하나의 준비된 결과로 유효할 때만 사용하세요. - 최종 실제 작업이 완료되면 해당 Work Item과 Plan을 완료하고 프로젝트 인덱스를 유휴(idle) 상태로 설정하세요. 계속 활성 상태로 유지하기 위해 후속 작업을 절대 만들어내지 마세요.
네이티브하게 그리고 좁게 작업하세요
쓰기 전에 프로젝트 루트, 지원 형식, 활성 Plan, 현재 Work Item, 영향을 받는 바이트, 관찰 가능한 결과, 수용 증거를 확인하세요. 컨텍스트에 바인딩된 패치를 사용하고 관련 없는 작업을 보존하세요. 다중 파일 변경을 적용하기 전에 완전히 준비하되, 직접 편집이 원자적이지 않음을 인지하세요.
쓰기 후:
- 변경된 모든 표준 파일을 다시 읽습니다;
- 전체 범위 차이(diff)를 검사합니다;
- 인덱스 소유권, 활성 Plan 수, 현재 항목 상태, Work Item 키 순서, 의존성 순서 및 순환, Decision 및 Plan 참조, 블로커, 수명주기 필드, 증거,
Next action을 확인합니다; - 번들된 선택적 검증기를 profile-validation.md를 통해 실행합니다(스크립트와 Python이 이미 사용 가능한 경우). 그렇지 않으면 범위 수동 검사를 수행하고 보고합니다;
- 관찰된 수용 증거만 기록합니다.
지원되지 않는 형식, 동시 변경, 모호한 수명주기 권한, 수리가 의도를 변경할 유효하지 않은 상태, 또는 부분적인 다중 파일 전환 시 중지하세요. 문제를 외형상 유효하게 덮어쓰지 마세요.
내구성 있는 상태를 보고하세요
현재 Plan 결과를 먼저 제시하세요. 변경된 표준 파일, 활성 및 차단된 작업, 관찰된 검사, 기록된 증거, 미해결 물리적 선택, 다음 구체적 조치를 명명하세요. 네이티브 구조 검사와 행동 검증을 구분하세요. 일상적인 파일 작업을 서술하지 마세요.