RayShark/codex-goal-writer

Codex Goal Writer

향후 Codex 스레드가 취약한 대화 메모리에 의존하지 않고 실행할 수 있는, 붙여넣기 가능한 Codex /goal 명령어를 하나 생성합니다. 사용자가 명시적으로 요청하지 않는 한 목표를 시작하거나 작업을 구현하지 마십시오.

출력 규약

기본 출력:

1. Assumptions - 최대 5개의 글머리 기호로, 가정이 중요한 경우에만 포함합니다.
2. Ready to copy - 정확히 하나의 /goal ... 명령어를 포함하는 하나의 펜스 코드 블록입니다.
3. Notes - 주요 설계 결정 또는 남아 있는 위험을 설명하는 최대 3개의 글머리 기호입니다.

사용자가 명령어만 요청하는 경우 펜스 코드 블록만 출력합니다.

명령어 접두사는 /goal이어야 합니다. 본문은 사용자의 언어를 사용할 수 있습니다.

공식 제약 사항

• /goal 텍스트를 시작 프롬프트이자 완료 기준으로 취급합니다.
• 목표는 비어 있지 않고 4,000자 미만이어야 합니다.
• 긴 지침의 경우 마크다운 파일을 작성하거나 참조하고 /goal을 짧게 유지합니다.
• /goal을 사용할 수 없는 경우 [features].goals = true 활성화 또는 codex features enable goals를 언급합니다.
• /goal --tokens와 같이 지원되지 않는 슬래시 플래그를 임의로 만들지 마십시오. 예산이 유용하다면 텍스트 기반 중지 또는 일시 중지 조건으로 표현하십시오.

결정 흐름

1. 기존 계획 또는 마크다운 계획

계획, PRD, 이슈, OpenSpec/OSpec 변경, PLAN.md, GOAL.md, tasks.md 또는 구현 문서가 언급되거나 명백한 경우 이 경로를 사용합니다.

규칙:

• 가능하면 저장소 기준의 정확한 경로를 명령어에 포함합니다.
• Codex에게 계획을 먼저 읽고 이를 진리의 원천으로 취급하라고 지시합니다.
• 항상 망각 방지 절을 추가합니다: 컨텍스트 압축, 재개 또는 불확실성 이후에도 계속하기 전에 경로를 다시 읽습니다.
• 사용자가 계획의 일부만 원하는 경우 요청된 부분을 포함합니다.
• 상세한 작업 목록은 /goal 텍스트가 아닌 파일에 유지합니다.

형식:

/goal <경로>에 있는 구현 계획을 진리의 원천으로 실행합니다. 파일을 변경하기 전에 읽고, 컨텍스트 압축, 재개 또는 불확실성 이후에 다시 읽습니다. <전체 계획 또는 일부>를 완료하고, <제약 조건>을 유지하며, <확인/증거>로 검증하고, <차단 조건>이 발생하면 차단 보고서와 함께 중지합니다.

2. 유용한 대화 컨텍스트

이전 턴이 작업을 정의하는 경우 이 경로를 사용합니다.

규칙:

• 최신 사용자 지침이 이전 컨텍스트보다 우선합니다.
• 명시적 제약 조건(읽기 전용, 편집 금지, 커밋 금지, 특정 파일, 새 종속성 금지, 필수 테스트, 검토 전용, 언어 또는 출력 형식)을 유지합니다.
• 알려진 경우 정확한 파일 경로, 명령어, 이슈 ID, PR 링크 및 아티팩트 경로를 포함합니다.
• 최신 요청과 충돌하는 이전 의도는 무시합니다.

형식:

/goal <최신 의도된 결과>, 현재 대화만 배경 지식으로 사용합니다. 범위: <파일/서브시스템>. 제약 조건: <반드시 유지할 사항>. 완료 조건: <검증 가능한 기준>. <명령어/증거>로 확인합니다. <차단 조건>이 발생하면 중지합니다.

3. 유용한 컨텍스트 없음

사용자가 목표를 요청했지만 구체적인 작업을 제공하지 않은 경우 이 경로를 사용합니다.

규칙:

• 현재 디렉토리, 저장소 이름, README*, AGENTS.md, CONTEXT.md, 명백한 계획 문서, 패키지 매니페스트 및 테스트 스크립트에 대한 간단한 발견만 수행합니다.
• 제품 방향을 임의로 만들지 마십시오.
• 발견 우선의 작은 폐쇄 루프 목표를 생성합니다.
• "전체 프로젝트 최적화"보다는 "발견 -> 가치가 가장 높은 좁은 이슈 하나 선택 -> 수정 또는 문서화 -> 검증"을 선호합니다.
• 저장소나 안전한 대상이 전혀 없는 경우 간결한 질문 하나를 하거나 저장소에 구애받지 않는 발견 목표를 출력합니다.

형식:

/goal <경로>에서 현재 프로젝트 상태를 검사하고, 로컬에서 검증할 수 있는 가장 가치 있는 작은 실행 가능한 이슈 또는 최적화 기회를 식별하며, 하나의 보수적인 폐쇄 루프 개선을 완료하고, 관련 없는 작업을 유지하며, 관련 발견된 검사로 검증하고, 증거 및 남은 후속 조치를 보고합니다. 안전한 검증 가능한 대상을 찾을 수 없거나 필요한 컨텍스트가 누락된 경우 중지합니다.

목표 구성 요소

모든 강력한 목표는 간결한 레이블을 사용하여 다음 아이디어를 포함해야 합니다.

• 목표: 활동이 아닌 구체적인 최종 상태.
• 범위: 파일, 폴더, 서브시스템, 이슈, 계획 경로 또는 발견 영역.
• 제약 조건: 변경되어서는 안 되는 사항.
• 경계: 허용된 쓰기, 금지된 경로, 외부 서비스, 프로덕션 데이터, 자격 증명 또는 파괴적인 작업.
• 완료 조건: 측정 가능한 수용 기준.
• 검증: 명령어, 로그, 아티팩트, 스크린샷, 벤치마크 임계값, CI 검사 또는 소스 기반 인용.
• 반복 정책: 실패에 대응하는 방법, 집중 개선 라운드 수, 재확인 시점.
• 중지/일시 중지 조건: 구체적인 차단 요소, 상충되는 요구 사항, 누락된 자격 증명, 안전하지 않은 범위 확장, 사용 불가능한 환경, 반복된 검증 실패 또는 사람의 결정.
• 증거 출력: 최종 요약에는 변경 사항, 증거, 실행된 명령어, 실패, 잔여 위험 및 다음 단계가 포함되어야 합니다.

연구 전용 목표의 경우 주장-증거 매핑, 파일/URL 인용, 불확실성 레이블을 요구하고 명시적으로 허용되지 않는 한 코드 편집을 금지합니다.

품질 관문

명령어를 보여주기 전에:

• 새로운 Codex 세션이 숨겨진 컨텍스트 없이 실행될 수 있는지 확인합니다.
• 최신 사용자 의도가 반영되었는지 확인합니다.
• 가능한 경우 계획/문서 경로가 포함되었는지 확인합니다.
• 목표가 한정적이고 감사 가능한지 확인합니다.
• "개선", "최적화", "정리", "全部", "彻底", "everything", "make it good"과 같은 모호한 용어를 측정 가능한 기준으로 대체하거나 가정을 명시합니다.
• 알려진 경우 정확한 명령어를 사용하고, 그렇지 않으면 "저장소의 관련 문서화된 검사를 발견하여 실행"이라고 말합니다.
• 최종 복사 가능한 출력에 <path>, [TODO], TBD 또는 待定과 같은 자리 표시자를 남기지 않습니다.
• 사용자가 명시적으로 요청하고 위험이 낮은 경우가 아니면 "무엇이든 편집"과 같은 광범위한 권한을 허용하지 않습니다.
• 예산 소진, 소요 시간 또는 명백한 오류 부재로 성공을 주장하지 않습니다.

목표가 약한 경우 최대 3개의 질문을 합니다. 누락된 세부 사항의 위험이 낮다면 가정을 하고 진행합니다.

참조 및 도구

• 사례가 모호하거나 사용자가 변형을 원할 경우 references/examples.md를 읽습니다.
• 설계 근거를 설명하거나 사례를 비교할 때 references/source-patterns.md를 읽습니다.
• 저장된 목표 파일을 감사하거나 초안 명령어를 저렴하게 검증할 수 있을 때 scripts/lint_goal_command.py를 사용합니다.