---
name: start-implementation-thread
description: "Codex 워크플로우로 작성한 기술 스펙 또는 UI 구현 문서를 제시한 뒤, 사용자가 별도 메시지에서 해당 문서의 구현 시작을 승인했을 때 사용합니다. 승인된 문서를 다시 읽고 모델과 추론 강도를 확인한 뒤 새 Codex 작업으로 구현을 넘깁니다. 관련 버그를 현재 작업에서 바로 수정하는 흐름에는 사용하지 않습니다."
---

# Codex 구현 작업 시작

## 출력 언어

사용자가 출력 언어를 명시적으로 지정하면 해당 언어를 사용합니다. 지정하지 않으면 이 스킬이 만드는 모든 사용자 대상 출력, 문서, 프롬프트, 보고서, 계획, 스펙 및 기타 산출물을 한국어로 작성합니다. 제목, 섹션, 레이블, 표, 체크리스트, 다이어그램과 템플릿에도 같은 언어를 사용합니다. 코드, 명령어, 파일 경로, 식별자, API 이름, 모델 ID, 프로토콜 이름과 필수 고유명사는 번역하지 않습니다.

## 적용 조건

다음을 모두 확인합니다.

1. 구현 기준이 되는 기술 스펙 또는 UI 구현 문서의 경로와 버전이 확인됐습니다. PRD만으로는 제품·기능 구현을 시작하지 않습니다.
2. 해당 문서를 사용자에게 제시한 응답이 끝났습니다.
3. 그 뒤의 별도 사용자 메시지에서 문서 경로 또는 버전을 확인하며 구현 시작을 명시적으로 승인했습니다.
4. 구현을 막는 열린 질문이 있으면 문서 링크와 함께 사용자 대화에 제시했고, 그 뒤 사용자가 권장안 일괄 승인 또는 질문별 직접 답변을 했습니다. 질문이 없으면 대화에 `구현 전 필수 열린 질문: 없음`이라고 명시했습니다.
5. 질문 답변과 피드백이 승인 문서에 반영됐으며 구현을 막는 결정 사항이 없습니다.
6. 모델과 추론 강도는 사용자가 지정한 값을 우선하고, 지정하지 않았다면 현재 도구가 지원하는 선택지를 제시해 확인합니다.

최초 요청의 `문서 작성 후 구현해줘` 같은 미래형 문장은 구현 승인으로 인정하지 않습니다. 승인 대상 문서를 제시한 뒤의 별도 메시지에서 `승인`, `이 문서대로 구현 시작`처럼 대상이 분명한 표현을 확인합니다.

일반 `승인`은 아직 대화에 제시하지 않은 열린 질문의 권장안을 선택한다는 뜻이 아닙니다. 미제시 또는 미응답 질문을 발견하면 기존 구현 승인 상태는 보존하되 문서 링크와 질문 전문·선택지·권장안·영향을 먼저 제시하고 현재 턴을 끝냅니다. 질문을 제시한 뒤 받은 `권장안대로 승인` 또는 질문 ID별 직접 답변만 결정 기록으로 인정합니다.

## 실행 전 확인

승인된 구현 문서를 파일에서 다시 읽고 다음을 추출합니다.

- 완료 목표
- 범위와 비범위
- 확인된 사실, 조건과 사용자 결정
- 실행 단계와 검증
- 선택 모델, 추론 강도와 사유
- 구현 작업에 전달할 문서 경로와 핵심 계약

대화 기억으로 문서를 재구성하지 않습니다. 새 작업 프롬프트에 승인된 문서의 절대 경로를 넣고, 수신 작업이 문서를 다시 읽은 뒤 구현·검증까지 완료하게 합니다.

## 설정 검증

현재 노출된 새 작업 도구 스키마에서 지원 모델과 추론 강도를 확인합니다.

- 사용자 승인 값이 지원되면 그대로 사용합니다. 승인된 추론 강도는 Codex Desktop 새 작업 도구의 `thinking` 인자로 같은 값 그대로 전달합니다.
- 지원되지 않으면 임의로 대체하지 않고 가능한 조합과 차이를 알려 수정받습니다.
- 사용자가 속도나 service tier를 지정하지 않았다면 별도 값을 만들지 않습니다.
- 사용자가 모델을 선택하지 않은 경우 구현 문서의 범위와 위험을 기준으로 지원되는 선택지를 제시하지만, 새 작업 호출에는 사용자가 승인한 모델만 명시합니다.
- 새 작업 도구와 현재 호스트의 권위 있는 모델 카탈로그가 모두 없으면 모델 ID를 꾸며내지 않습니다. fallback에는 `미확정 — 새 작업 UI에서 지원 모델 선택 필요`와 권장 모델 성격을 적습니다.

## 새 작업 생성

현재 Codex 앱에 제공된 도구 이름과 스키마를 따릅니다. 기억한 `thread/start`나 `turn/start` API를 가정하지 않습니다.

일반적인 Codex Desktop 절차는 다음과 같습니다.

1. 프로젝트 목록 도구로 현재 저장소와 일치하는 프로젝트를 찾습니다.
2. Git 저장소이면 사용자가 현재 체크아웃에서 직접 실행하라고 명시하지 않은 한 새 worktree를 기본값으로 사용합니다. 사용자가 기존 작업 트리의 미커밋 변경을 포함하라고 한 경우에만 그 시작 상태를 명시합니다.
3. 새 작업 생성 도구에 승인된 `model`, `thinking`, 완전한 `prompt`와 프로젝트 대상을 전달합니다.
4. 준비된 `threadId`가 반환되면 의미 있는 구현 작업 제목으로 바꿉니다.
5. 생성은 비동기이므로 진행 대기 도구로 첫 진행이나 주의 필요 상태를 확인합니다. 사용자 입력이나 승인이 필요해지면 대신 답하지 않습니다.
6. 새 작업 생성에 성공하면 현재 작업에서 같은 구현을 중복 수행하지 않습니다.

새 작업 도구의 정책이 모델 명시를 사용자의 직접 요청에만 허용한다면, 사용자가 모델과 추론 강도가 적힌 계획을 승인한 것을 해당 설정의 명시적 선택으로 취급합니다. 계획을 승인하지 않은 상태에서는 추천값만으로 도구를 호출하지 않습니다.

## 새 작업 프롬프트 최소 계약

승인된 구현 문서에서 아래 구조의 새 작업 프롬프트를 구성합니다.

```text
# 지시

## 목표
<완료 상태>

## 해야 할 일
<실행 단계와 검증>

## 하지 말아야 할 일
<비범위와 금지 사항>

## 사실과 조건
<확인된 사실, 사용자 결정, 제약과 근거>

## 유의사항
- 이 작업은 최종 구현 실행 단위입니다.
- 문서 열람이나 다른 작업으로 재인계하는 것으로 끝내지 마세요.
- 변경 후 검증하고 변경 사항, 검증 결과, 남은 위험을 보고하세요.

## 원래 사용자 요청
<원문>

문서:
- <승인된 구현 문서 절대 경로>
```

작업 위험이나 복잡도가 높아 독립 검토가 실제로 이득이면 수신 프롬프트에 `orchestrate-subagents` 적용을 권고합니다. 모든 작업에 독립 검토를 필수 게이트로 넣지 않습니다.

## 실패 시 출력

새 작업 도구가 노출되지 않았거나 생성이 실패했으면 현재 작업에서 임의의 다른 API를 호출하지 않습니다. 승인된 설정과 구성한 프롬프트를 다음 형식으로 제공합니다.

````text
현재 세션에서 새 Codex 작업을 만들 수 없습니다.

선택 모델: <model 또는 미확정 — 새 작업 UI에서 지원 모델 선택 필요>
선택 추론 강도: <effort>
선택 사유: <reason>

새 작업에 전달할 프롬프트:
```text
<승인된 구현 문서에서 구성한 완전한 Codex 실행 프롬프트>
```
````

프롬프트를 요약하거나 새로운 내용을 추가하지 않습니다. 실패 원인과 사용자가 직접 새 작업에서 붙여 넣으면 된다는 점을 함께 알립니다.

## 확인 시나리오

| 상황 | 결과 |
| --- | --- |
| 한 파일의 명확한 저위험 수정 | 이 스킬을 사용하지 않고 현재 작업에서 수행 |
| PRD만 승인됨 | 기술 스펙 작성 단계이며 새 구현 작업을 만들지 않음 |
| 기술 스펙은 승인됐지만 열린 질문을 대화에 제시하지 않음 | 승인은 보존하고 문서 링크와 질문 전체를 먼저 제시 |
| 열린 질문 제시 후 `권장안대로 승인` | 권장안을 문서에 반영한 뒤 나머지 적용 조건을 확인 |
| 열린 질문에 항목별로 답함 | 직접 선택을 문서에 반영한 뒤 나머지 적용 조건을 확인 |
| 사용자가 모델 또는 강도를 수정함 | 지원 여부 확인 후 승인된 값을 사용 |
| 사용자가 계획과 새 작업 시작을 승인함 | 새 작업 생성 후 첫 진행 상태 확인 |
| 새 작업 도구가 없음 | 모델·강도·사유·완전한 프롬프트를 코드 블록으로 출력 |
| 삭제·배포 등 별도 위험 행동이 남음 | 새 작업 생성과 별개로 해당 행동 직전에 승인 요구 |