빠른 흐름

/goal에 넣을 것
1. 최종 목표: 무엇이 참이 되어야 하는가
2. 범위: 어떤 파일, 기능, 문서, 저장소까지 포함하는가
3. 금지 조건: 푸시 금지, 파괴적 작업 금지, API 변경 금지 등
4. 검증 기준: 어떤 명령과 결과로 완료를 증명할 것인가
5. 진행 방식: 한 번에 끝나지 않으면 어떤 단위로 계속할 것인가

좋은 형태
/goal Complete [objective] until [verifiable end state].

목표 구조

/goal은 긴 작업의 의도를 유지하지만 완료 기준을 대신 만들지는 않는다

공식 use case는 /goal을 "검증 가능한 종료 조건을 향해 여러 턴에 걸쳐 계속해야 하는 작업"에 쓰는 흐름으로 설명합니다. 핵심은 긴 작업을 잊지 않는 것이 아니라, 멈춰야 할 지점을 검증 가능하게 만드는 것입니다. "레퍼런스 카드를 계속 보강해줘"처럼 방향만 있는 목표는 유용하지만, 어느 정도가 충분한지 불명확하면 매 턴마다 현재 상태를 확인하고 다음 배치로 좁혀야 합니다.

장기 목표에는 완료 조건과 진행 단위를 같이 둡니다. 예를 들어 "각 배치마다 기존 카드 규칙을 확인하고, 신규 카드 3~4장을 추가하고, content check와 build를 통과시키고, 커밋하되 푸시하지 않는다"처럼 운영 단위가 있으면 중간에 세션이 이어져도 작업 품질이 흔들리지 않습니다.

목표, 제약, 완료 판단을 한 문장에 섞지 않는다

긴 목표일수록 "무엇을 할지", "무엇을 하지 않을지", "끝났는지 어떻게 알지"가 섞이기 쉽습니다. Codex는 이 셋을 모두 따라야 하므로, 프롬프트에서는 줄을 나눠 적는 편이 안정적입니다.

Goal:
- Codex 레퍼런스 카드를 보강한다.

Constraints:
- 기존 subCategory를 우선 재사용한다.
- 커밋은 하되 푸시는 하지 않는다.
- 새 카드가 기존 카드와 문체·구조상 크게 다르면 수정한다.

Done when:
- 신규 카드가 매니페스트에 반영된다.
- npm run content:check와 npm run build가 통과한다.
- graphify update가 완료된다.
- 로컬 커밋이 생성되고 작업트리가 clean이다.

운영 기준

작업이 길다고 항상 /goal이 필요한 것은 아닙니다. 목표가 하루 안에 끝나는지보다 "중간에 이어받아도 같은 종료 조건을 적용해야 하는가"가 더 중요합니다. 짧은 버그 수정이라도 검증 루프가 복잡하고 여러 번 실패할 수 있으면 goal이 유용하고, 긴 설명 요청이라도 한 번 답하면 끝이면 goal로 만들 필요가 없습니다.

주의할 점

실패 예시
- "계속 개선해줘"만 goal로 만들고 품질 기준을 적지 않음
- 푸시 금지 같은 제약을 goal 밖의 대화에만 남김
- 이전 배치가 통과했다는 기억만 믿고 현재 작업트리 검증을 생략함
- 완료 조건이 약해서 "몇 장 추가했다"를 전체 목표 완료로 착각함