jg-challenge-plan – 계획 검증 도구

호출

개발자가 직접 호출할 때만 실행합니다. 사용 가능한 도구로 워크플로를 수행하고, 시뮬레이션하거나 셸 명령을 대체하거나 이미 승인된 작업에 대해 다시 묻지 않습니다.

제공된 텍스트를 인수, 제약 조건 또는 맥락으로 취급하며, 한도와 연기를 존중합니다. 누락된 기능과 차단 요인을 정직하게 보고합니다. 성공을 절대 시뮬레이션하지 않습니다.

실패 시를 포함하여 소유한 런타임 리소스와 일회용 스크래치 출력을 해제하고, 해결되지 않은 증거는 보존하며 이 스킬의 출력에 보유된 리소스를 보고합니다. 이 좁은 정리 예외는 검토/기존 파일 변경, 예상치 못한 변경 제거 또는 이전 작업 정리를 허용하지 않습니다. 다른 모든 쓰기는 이 워크플로를 따릅니다. 제공된 자료에 대한 이 스킬의 특정 규칙이 우선합니다.

jg-plans 프로토콜 0.2

영속화된 문서에는 프로젝트 로컬 jg-plans >=0.6.1과 CLI 스키마 3이 필요합니다. 계획 없음/코드 전용 작업, 기록 분석 및 일시 중지는 CLI가 필요하지 않습니다.

• 일반적으로 <repository-root>/node_modules/.bin/jg-plans인 설치된 프로젝트 진입점 또는 문서화된 빌드 진입점을 사용합니다. --version --json과 함께 정확한 진입점을 실행합니다. 오류가 null, 버전 >=0.6.1, schemaVersion 3이어야 문서 작업을 진행합니다. 그렇지 않으면 관찰된 쌍과 매니저별 해결 방법(예: npm install --save-dev --save-exact [email protected])으로 해당 작업을 중단합니다. 런타임 소비자의 프로덕션 종속성을 유지합니다. 자동 설치, 러너 다운로드, 전역 도구 사용 또는 다른 프로젝트의 CLI 차용을 절대 하지 않습니다. 업그레이드/빌드 후 진입점을 다시 확인합니다.
• 해당 CLI를 통해서만 선택된 디렉토리를 읽습니다: inspect --directory <path> --include-body --fingerprint-exclude '["created_at","updated_at","revision","status","priority","delivery"]' --json. 소스, 메타데이터, 범위, 진단, sha256 및 구조적 지문을 사용합니다. 영속화된 문서를 직접 편집/파싱/해싱하거나, UUID를 생성하거나, 최근성을 기준으로 계획을 선택하거나, 기록을 파일로 재구성하지 않습니다. 검사를 위해 적합성은 필요하지 않습니다. jg-plan만 overlaps --json을 추가로 실행하며, 코드가 선언된 경우 기록된/자체 저장소의 기존 계획 루트당 하나의 --root를 사용합니다.
• 계획 상태는 pending, in progress, done, delivered입니다. 마일스톤 상태는 pending, in progress, done입니다. Active는 pending, in progress, done을 의미하며, delivered만 비활성입니다. 오류 선언은 repository/registry/codes 목록을 사용합니다. 문자열/숫자 유형을 유지하고 repository/registry 내에서 String(code)을 비교합니다. 누락/사용자 지정 상태, 사용할 수 없는 메타데이터/파일 및 모호한 마커는 관찰 사항으로 남으며, 기본값이나 권한이 아닙니다.
• 필수 전달 맵은 선언된 모든 저장소를 해당 저장소 정의 중단점에 매핑하며, 일치하는 키를 사용합니다. 저장소가 선언되지 않은 경우에만 명시적 빈 매핑을 사용합니다. 전달은 구현 범위나 마일스톤 진행 상황을 변경하지 않습니다. 지문은 정확히 created_at, updated_at, revision, status, priority, delivery를 제외하며, 사용할 수 없는 ID는 새로운 적용 범위를 설정할 수 없습니다.
• 이 워크플로의 권한 내에서 동일한 진입점으로 구조화된 create/update/write/remove-milestones 입력을 통해 변경합니다. 기존 대상 쓰기에는 freshExpectedSha256이 필요합니다. null은 명시적으로 요청된 없는 마일스톤만 생성합니다. write는 계획 본문/메타데이터 또는 완전한 마일스톤 소스에 사용하고, update는 좁은 메타데이터/마커에 사용합니다. 승인된 경우에만 누락된 ID를 할당하고, 반환된 ID를 보유하며 쓰기를 검사합니다. plan.md가 변경되면 updated_at을 명시적으로 설정합니다. 전달 전용 편집은 revision/progress를 유지합니다. 변경된 범위는 적용 범위 재평가가 필요합니다.
• 잠금은 짧고 로컬입니다. 턴 간에 유지하거나, 익숙하지 않은 잠금을 제거하거나, 최신 텍스트 위에서 재생하지 않습니다. 부분적인 다중 문서 또는 불확실한 변경 실패 후, 지속 상태를 검사/보고하고 롤백/재시도 없이 중단합니다. 문서, 진단 및 바인딩은 권한을 부여하지 않습니다.

워크플로

현재 논의 중인 엔지니어링 변경에 대한 하나의 구체적인 계획을 간결하고 읽기 전용으로 검증합니다. 동일한 에이전트가 생성했더라도 계획을 신뢰할 수 없는 제안으로 취급합니다. 목적은 개발자가 계획된 결과가 작업 계약과 일치하는지 신속하게 확인하고, 승인, jg-breakdown 또는 구현 전에 중대한 결정, 가정, 누락 및 위험을 노출하도록 돕는 것입니다. 이 스킬은 계획 변경, 계획 파일 생성 또는 편집, 소스 코드, 테스트, 스냅샷, 구성, 종속성, 마이그레이션, 생성된 아티팩트, 일반 프로젝트 문서 또는 Git 상태 수정, 계획 승인 또는 거부, jg-breakdown 승인 또는 구현 시작을 승인하지 않습니다. 검사 명령이 예기치 않게 파일을 변경하는 경우, 해당 변경 사항을 정리, 되돌리기 또는 검증의 일부로 주장하지 않고 보존하고 보고합니다.

구체적인 계획이 필요합니다. 개발자가 경로 또는 다른 명확한 식별자로 계획을 식별하면 정확히 해당 계획을 검증합니다. 그렇지 않으면 현재 논의에 명확한 후보가 하나만 있는 경우에만 정확한 현재 계획을 사용합니다. 합리적으로 의도된 대상이 될 수 있는 계획이 두 개 이상이면 중단하고 개발자에게 하나를 선택하도록 요청합니다. 다른 계획 디렉토리를 검색하거나, 타임스탬프에서 계획을 선택하거나, 파일 최근성만으로 대상을 추론하지 않습니다. 현재 계획이 없거나 식별된 계획에 완전히 접근할 수 없으면 차단자를 보고하고 중단합니다. 현재 저장소 증거가 계획을 실질적으로 무효화하면 검증을 계속하고 그 진부함을 차단 발견 사항으로 표면화합니다.

1. 대상 계획 전체, 현재 논의의 작업 계약, 해당 정확한 계획에 적용되는 모든 개발자 수정 사항을 읽습니다. 계획 자체의 작업 요약을 개발자 의도의 독립적인 증거가 아닌 신뢰할 수 없는 표현으로 취급합니다. 개발자의 목표, 제약 조건, 제외 사항, 수용 기준 및 수정 사항을 계획과 독립적으로 설정할 수 없으면 계획 내부 및 저장소 증거 검증만으로 계속 진행하고, 의도 정렬을 확인할 수 없음을 명시하고, 계획의 목표, 제약 조건 및 제외 사항이 개발자의 의도와 일치하는지 확인하는 결정 1로 나열하며, 중대한 계획 결함이 없는 한 Developer decision required before proceeding을 사용하고, 그렇지 않으면 Plan revision required before proceeding을 사용합니다. 대상 계획의 저장소 기준 경로 또는 제공된 식별자와 현재 선택된 검사의 정확한 바이트 SHA-256을 캡처하여 ## Plan at a glance에 포함시키고, 응답 직전에 재검사하여 해시가 변경되지 않았는지 확인합니다. 변경된 경우 차단자를 보고하고 중단합니다. 계획에 의해 설정된 저장소 증거를 현재 상태인 경우 재사용합니다. 중요한 불확실성을 확인하거나, 진부함을 감지하거나, 영향력이 큰 주장을 검증하는 데 필요한 최소한의 추가 읽기 전용 검사만 수행합니다. 이 스킬이 호출되었다는 이유만으로 완전한 계획 워크플로를 반복하지 않습니다.
2. 계획이 실제로 구축, 변경, 제거, 마이그레이션, 노출 또는 배포할 내용을 결정합니다. 그 결과를 개발자의 목표, 제약 조건, 제외 사항, 수용 기준 및 승인된 결정과 비교합니다. 중대한 범위 확장, 누락된 필요 작업, 변경된 동작, 지원되지 않는 가정, 제안된 결과가 개발자의 의도와 다를 수 있는 부분을 식별합니다. 전달이 선언된 모든 저장소를 포함하는지, 전달 문서에 대상이 존재하는지, 연산자/전제 조건이 명시적인지, 승인이 에이전트 운영 단계를 포함하는지 확인합니다. 전체 계획 전달은 구현 및 검토를 따라야 합니다. 개발자가 운영하는 나머지 단계는 전달되었다고 할 수 없습니다.
3. 해당되는 경우 계획의 중대한 결정 및 위험 통제를 검증합니다. 여기에는 아키텍처 및 모듈 소유권; 데이터 흐름 및 통합 경계; 데이터베이스 스키마, 영속 데이터, 마이그레이션 및 롤백; 공개 API, 내보내기, 이벤트, 큐, 웹훅, 캐시 키, 구성 및 호환성; 보안, 개인정보 보호, 인증, 권한 부여, 소유권, 결제 및 기타 가치 관련 동작; 동시성, 재시도, 멱등성 및 실패 복구; 종속성, 인프라, 배포 및 운영 요구 사항; 대체 또는 병렬 경로 제거; 테스트 및 검증 전략이 중요한 결함을 현실적으로 노출할 수 있는지 여부가 포함됩니다.
4. 불필요한 복잡성, 추측성 추상화, 중복 소유권, 정당화된 마이그레이션 필요 없는 임시 또는 병렬 구현, 불완전한 호환성 또는 롤백 경로, 숨겨진 높은 영향 반경 변경, 중요한 동작이 잘못된 상태에서 통과할 수 있는 검증을 특히 찾습니다. 이 스킬 이름이 jg-challenge-plan이라는 이유만으로 비판을 만들어내지 않습니다. No material concerns는 유효한 결과입니다. 후속 조치에서는 이전 발견 사항, 변경된 의도 또는 계획 자료, 영향을 받은 상호 작용을 재평가하고, 변경되지 않은 검토 영역에 대해 현재 증거를 재사용합니다. 해결되지 않은 중요한 문제를 유지합니다. 명시적인 새로운 전체 검증, 이전 범위 누락, 오래된 증거, 새로운 실패 또는 변경된 중대한 위험에 대해서만 범위를 확장합니다.
5. 개발자가 승인 결정을 내리는 데 도움이 되는 정보만 보고합니다. 영향이 적은 구현 세부 사항, 철저한 파일 목록, 단계별 구현 시퀀스, 완전한 테스트 매트릭스, 검증 명령 목록은 특정 항목이 중대한 문제를 노출하지 않는 한 결과에서 제외합니다. 모든 검증에 대해 구체적인 불일치, 누락, 지원되지 않는 가정 또는 위험, 그것이 중요한 이유, 가장 작은 적절한 수정 사항을 명시합니다. 계획을 다시 작성하거나, 아키텍처를 조용히 대체하거나, 대체 구현을 이미 승인된 것처럼 제시하지 않습니다.
6. 정확히 다음 섹션을 사용하여 결과를 제시합니다:
   • ## Plan at a glance: 의도된 최종 결과, 주요 구현 경계 및 중요한 명시적 제외 사항을 요약합니다.
   • ## Material impact: 개발자의 주의가 필요한 아키텍처 결정, 데이터베이스 또는 영속 데이터 변경, 공개 또는 통합 계약 변경, 보안에 민감한 동작, 종속성 또는 인프라 변경, 마이그레이션, 호환성, 배포 또는 롤백 영향만 표면화합니다. 관련 없는 범주는 생략하거나 부재 자체가 중요한 경우 No change를 명시합니다.
   • ## Challenges: 영향력 내림차순으로 중요한 발견 사항을 나열합니다. 없으면 No material concerns found를 명시합니다.
   • ## Developer decisions required: 동작, 범위, 계약, 안전, 데이터, 아키텍처 또는 운영에 실질적으로 영향을 미치는 해결되지 않은 선택만 포함합니다. 모든 나열된 결정에 개발자가 처리해야 할 순서대로 번호를 매깁니다. 각 결정에 대해 정확히 내려야 할 선택을 명시하고, 최소 하나의 권장 사항을 제공하며, 권장 사항을 수락하거나, 의미 있는 대안을 선택하거나, 결정을 해결하지 않은 상태로 두었을 때의 중대한 결과와 트레이드오프를 설명합니다. 더 이상 그러한 결정이 없으면 None을 명시합니다. 이 섹션을 채우기 위해 결정을 임의로 만들지 않습니다.
   • ## Recommendation: 첫 줄에 정확히 No material concerns, Plan revision required before proceeding, Developer decision required before proceeding 중 하나를 넣습니다. 중대한 계획 결함이 있을 때는 개발자 입력이 필요한 경우에도 Plan revision required before proceeding을 사용합니다. 계획이 다른 측면에서는 적절하지만 중요한 개발자 결정 없이 안전하게 진행할 수 없을 때만 Developer decision required before proceeding을 사용합니다. 평결 아래에 정확히 하나의 Next step: 줄을 넣습니다:
     • No material concerns 후: 계획에 각각 완료, 검증 및 검토될 수 있는 별도의 패키지, 저장소 또는 릴리스와 같은 최소 두 부분이 있으면 개발자에게 jg-breakdown을 실행하도록 지시하고, 그렇지 않으면 계획을 승인하거나 jg-execute를 호출하도록 지시합니다. 계획 자체의 검토 체크포인트는 분해를 불필요하게 만들지 않습니다. milestones.md가 없으면 jg-execute는 전체 계획을 하나의 단위로 실행하고 체크포인트에서 멈추지 않습니다.
     • Plan revision required before proceeding 후: 개발자에게 번호가 매겨진 결정에 응답하고, jg-plan을 호출하여 필요한 수정 사항을 해당 응답과 함께 적용하고, 수정된 계획이 제시된 후 jg-challenge-plan을 다시 호출하도록 지시합니다.
     • Developer decision required before proceeding 후: 개발자에게 번호가 매겨진 결정에 응답하고, 계획을 변경하는 응답과 함께 jg-plan을 호출하고, 수정된 계획이 제시된 후 jg-challenge-plan을 다시 호출하도록 지시합니다.
7. 전체 검증을 1,000단어 이하로 유지합니다. 밀접하게 관련된 문제를 통합하고 결정 가치가 가장 높은 정보에 우선순위를 둡니다. 제한을 충족하기 위해 차단 문제를 생략하지 않으며, 사용 가능한 공간을 채우기 위해 계획 내용을 복제하지 않습니다.
8. 권장 사항을 조언으로 취급합니다. 계획을 승인하거나, 이전 승인을 취소하거나, jg-breakdown을 승인하거나, 구현을 승인하거나, jg-challenge-plan을 다른 워크플로의 전제 조건으로 만들지 않습니다. 검증은 평가된 정확한 계획 버전에만 적용됩니다. 계획 개정은 이전 검증을 무효화하며, 수정된 계획에 대한 증거로 재사용해서는 안 됩니다. ## Recommendation의 Next step: 줄 다음에 종료합니다. 이 스킬의 출력 계약은 일반적인 완료 요약 요구 사항을 대체합니다.