Craft Codex Prompts은(는) 무엇을 하나요?

목적

불완전한 맥락을, 다른 Codex 대화가 추론된 해석을 사실로 취급하지 않고 실행할 수 있는 태스크 패키지로 변환합니다. 소스 충실도, 제한된 권한, 테스트 가능한 완료, 낮은 프롬프트 오버헤드를 목표로 최적화합니다.

작업 선택

초안(Draft): 파일, 프로젝트 맥락 또는 대략적인 요청으로부터 프롬프트를 구성합니다.
검토(Review): 기존 프롬프트의 약점을 진단하고 수정 버전을 생성합니다.
인계(Handoff): 이전 작업, 결과 및 미해결 문제를 다음 실행 가능한 프롬프트로 변환합니다.
지식 루프(Knowledge loop): 지식 베이스에 적합한 현재 상태, 결정, 미해결 문제 및 인계 업데이트를 생성합니다.

사용자가 프롬프트만 요청하는 경우, 필수 가정과 함께 프롬프트만 반환합니다. 재사용 가능한 워크플로우를 요청하는 경우 전체 태스크 패키지를 반환합니다.

워크플로우

1. 소스 및 권한 설정

초안 작성을 준비하는 동안 권한이 있고 유용한 경우, 사용자가 제공한 파일과 접근 가능한 프로젝트 자료를 읽기 전용으로 검사합니다. 프롬프트를 준비하는 동안 소스 프로젝트를 수정하지 마십시오.

입력을 분류합니다:

기본 사실(Primary facts): 현재 파일, 저장소 상태, 명시적 사용자 진술, 권위 있는 프로젝트 문서.
파생 맥락(Derived context): 요약, 이전 어시스턴트 결론, 보고서 및 복사된 채팅.
미지의 것(Unknowns): 누락된 파일, 확인되지 않은 런타임 상태, 해결되지 않은 선택 사항 및 외부 종속성.

파생 맥락을 단서로 취급하고 증거로 취급하지 마십시오. 실행하는 대화가 이를 기본 소스에 대해 반드시 검증해야 한다고 명시적으로 밝히십시오.

한 대화에 첨부된 파일이 다른 대화에서 사용 가능하다고 가정하지 마십시오. 실행하는 대화가 반드시 받아야 하는 모든 파일 또는 정확한 작업 공간의 이름을 지정하십시오.

2. 태스크 유형 식별

가장 가까운 태스크 유형을 선택합니다:

답변 또는 설명;
검사 또는 검토;
진단;
변경 또는 구축;
조사 또는 비교;
아티팩트 생성;
외부 작업 수행.

일치하는 권한 경계를 유지합니다. 분석 또는 진단 요청은 편집을 승인하지 않습니다. 변경 또는 구축 요청은 일반적으로 범위 내 구현 및 검증을 승인하지만, 관련 없는 리팩터링, 게시, 메시징, 커밋, 푸시 또는 파괴적 작업은 승인하지 않습니다.

일치하는 태스크 패턴에 대해 task-blueprints.md를 참조하십시오.

3. 안정적인 규칙과 태스크 델타 분리

내구성 있는 프로젝트 규칙은 AGENTS.md, PROJECT_BRIEF.md 또는 CODEX_TASK_CONTRACT.md와 같은 프로젝트 계약에 배치합니다. 현재 프롬프트는 이번에 변경된 사항에 집중하도록 유지합니다.

안전에 중요하거나 놓칠 가능성이 있는 경우에만 태스크 프롬프트에서 안정적인 규칙을 반복합니다.

4. 모호성을 비례적으로 해결

답변이 범위, 소스 선택, 되돌릴 수 없는 동작, 외부 효과 또는 수용 기준을 실질적으로 변경하는 경우에만 명확한 질문을 합니다. 그렇지 않은 경우 가장 안전한 합리적 가정을 선택하고 레이블을 붙입니다.

누락된 소스, 지원되지 않는 기능 또는 외부 차단 요소를 확신 있는 표현 뒤에 숨기지 마십시오.

5. 태스크 패키지 구성

해당되는 경우 다음 섹션을 만듭니다:

결과(Outcome): 하나의 구체적인 최종 상태.
진실의 소스(Source of truth): 정확한 파일, 경로, 데이터 또는 사용자 결정.
현재 상태(Current state): 검증되었거나 명확히 귀속된 사실만.
범위(Scope): 허용된 읽기, 편집, 시스템 및 아티팩트.
비목표(Non-goals): 가능하지만 승인되지 않은 확장.
인접 검사(Adjacent checks): 동일한 결함을 노출할 수 있는 다운스트림 표면.
실행 지침(Execution guidance): 정확성에 영향을 미치는 제약 사항(추측성 구현 세부 사항이 아님).
수용(Acceptance): 관찰 가능한 검사 및 예상 증거.
차단 요소 및 중지 조건(Blockers and stop conditions): 추측 대신 보고가 필요한 조건.
전달(Delivery): 변경된 파일, 아티팩트, 증거, 제한 사항 및 다음 인계.

구현이 포함된 경우 L1-L4 검증 사다리를 사용합니다:

L1: 구문, 임포트, 스키마 또는 정적 검증;
L2: 단위, 서비스 또는 집중 회귀 테스트;
L3: 실제 파일 또는 종단 간 데이터 경로 검증;
L4: 실제 UI, 패키징된 런타임, 장치, 프로덕션 유사 또는 인간 수용.

낮은 수준을 높은 수준의 증거로 제시하지 마십시오.

태스크에 맞게 조정된 다음 소스 충실도 조항을 포함합니다:

이 프롬프트를 실행 브리프로 취급하고 저장소 상태의 증거로 취급하지 마십시오. 현재 작업 공간 및 기본 파일에 대해 주장을 검증하십시오. 충돌하는 경우 소스 자료를 보존하고, 충돌을 보고하며, 사용자가 달리 결정하지 않는 한 기본 소스를 따르십시오.

6. 프롬프트 실행 가능성 유지

결과로 시작합니다.
직접적인 지시와 구체적인 명사를 사용합니다.
형용사보다 파일 이름, 경로, 개수 및 예상 아티팩트를 선호합니다.
정확한 표현 자체가 증거인 경우가 아니라면 원시 채팅을 복사하지 마십시오.
사용자가 선택을 고정하지 않는 한 검사 전에 아키텍처를 규정하지 마십시오.
금지 사항을 현실적인 실패 모드로 제한합니다.
Codex가 보고만 할지, 진단만 할지, 구현할지, 또는 구현하고 검증할지 명시합니다.
간결한 완료 형식으로 끝냅니다.

7. 전달 전 감사

여섯 가지 검사에 대해 프롬프트를 내부적으로 평가합니다:

충실도(Fidelity): 각 사실 주장이 소스로 추적될 수 있습니까?
권한(Authority): 읽기, 편집, 외부 작업 및 금지된 작업이 명확합니까?
완전성(Completeness): 가능한 인접 소비자 및 실패 경로가 포함되었습니까?
테스트 가능성(Testability): 완료가 관찰 가능한 증거로 입증될 수 있습니까?
실현 가능성(Feasibility): 사용할 수 없는 도구, 런타임 제한 및 인간 종속성이 노출되었습니까?
간결성(Brevity): 모든 명령이 실행 또는 검증을 변경합니까?

하나의 상태를 반환합니다:

READY: 사용 가능한 컨텍스트로 실행 가능;
READY_WITH_ASSUMPTIONS: 제한된 가정을 나열한 후 실행 가능;
NEEDS_INPUT: 하나 이상의 중요한 선택 사항이 누락됨;
BLOCKED_SOURCE_MISSING: 필요한 기본 자료를 사용할 수 없음.

명백한 엄격함을 개선하기 위해 프롬프트를 부풀리지 마십시오.

8. 지식 루프 종료

사용자가 Obsidian 또는 다른 지식 베이스에서 작업을 보관하는 경우 obsidian-loop.md를 읽습니다. 변경 불가능한 원시 채팅을 현재 프로젝트 진실과 분리하여 유지합니다. 실행 후, 트랜스크립트에만 의존하지 않고 현재 상태, 결정, 미해결 문제 및 인계를 업데이트합니다.

기본 출력

사용자가 다른 형식을 요청하지 않는 한 다음을 반환합니다:

## TASK_BRIEF
[검증된 사실, 가정, 미지의 것, 소스]

## MAIN_PROMPT
[복사 가능한 프롬프트]

## PROMPT_STATUS
[READY, READY_WITH_ASSUMPTIONS, NEEDS_INPUT 또는 BLOCKED_SOURCE_MISSING]
[짧은 설명 및 필요한 첨부 파일]

프롬프트 검토의 경우 MAIN_PROMPT 앞에 짧은 KEY_GAPS 섹션을 추가합니다. 비공개 사고 과정을 노출하지 말고 간결하고 결정에 관련된 이유를 제공합니다.

Craft Codex Prompts