---
name: intent-first
description: 모든 사용자 명령에서 실질적인 작업보다 먼저 사용자의 실제 의도를 판별하고, 불명확한 부분을 조사할지 가정할지 질문할지 의식적으로 결정합니다. 짧거나 추상적이거나 여러 해석이 가능한 요청, 범위가 크거나 되돌리기 어려운 작업에서는 특히 엄격히 적용합니다. 명확한 한 줄 변경도 이 라우팅 자체는 생략하지 않습니다.
---

# 의도 우선

## 출력 언어

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

## 필수 실행 규칙

이 플러그인을 사용하는 에이전트는 **모든 사용자 명령을 받았을 때 다른 스킬 선택, 조사, 계획, 도구 호출 또는 구현보다 먼저 이 스킬을 실행합니다.** 요청이 명확해 보여도 생략하지 않습니다. 명확한 요청도 읽기 전용 조사와 구현 범위 제시까지만 진행하고, 별도 사용자 승인 뒤에 파일 수정·상태 변경·구현 명령과 검증 명령을 실행합니다.

이 스킬의 목적은 불필요한 질문을 늘리는 것이 아닙니다. 불명확한 부분을 지식 공백과 의도 공백으로 분리해 직접 조사하거나 명시적 가정으로 처리하되, 실제 변경은 항상 범위를 제시한 뒤 별도 승인받습니다.

## 절차

### 1. 공백의 종류를 먼저 구분한다

| 공백 | 예시 | 처리 |
|---|---|---|
| 지식 공백 — 이미 정답이 있지만 아직 모르는 사실 | 이 저장소의 테스트 러너는 무엇인가? 이 함수는 지금 무엇을 반환하는가? | 직접 확인한다. 파일을 읽고, 검색하고, 실행하고, 기록을 확인한다. 사용자에게 묻지 않는다. |
| 의도 공백 — 아직 정답이 없고 누군가 선택해야 하는 선호 | 속도와 가독성 중 무엇을 우선할까? 기존 동작을 보존할까? | 아래 단계로 진행한다. |

질문하고 싶은 내용이 생기면 먼저 이 구분을 적용합니다. 불확실하다는 이유만으로 묻지 않습니다.

### 2. 상호작용 비용보다 탐색 비용을 먼저 쓴다

관련 파일 몇 개, 인접 기능의 기존 패턴, 최근 변경 기록과 직전 대화를 확인합니다. 저장소에는 라이브러리 선택, 오류 처리, 명명과 유사 문제의 해결 방식이 축적되어 있습니다.

이 단계는 짧은 사전 조사입니다. 몇 개 파일을 읽어도 수렴하지 않으면 과도하게 탐색하지 말고 다음 단계로 이동합니다.

### 3. 질문에 대한 가능한 답을 미리 시뮬레이션한다

남은 의도 공백마다 질문을 초안으로 만든 뒤 서로 다른 합리적인 사용자 세 명이 답한다고 가정합니다.

- 답이 사실상 하나로 모이면 그 답을 가정하고 진행합니다.
- 답이 실제로 갈리면 사용자 선택이 필요한 분기입니다.

### 4. 남은 분기의 비용을 계산한다

- 되돌리거나 다시 하기 쉬운 선택은 가정해 조사와 범위 제시에 반영할 수 있지만, 그 가정을 실제 변경 권한으로 확대하지 않습니다.
- 되돌리기 어렵거나 후속 작업이 많이 의존하는 선택은 질문합니다.
- 조사 중 발견한 문제가 현재 요청의 원인·완료 조건과 직접 관련되지 않으면 별도 범위로 분리하고, 수정하기 전에 사용자 승인을 받습니다.
- 삭제, 배포, 전송, 결제, 프로덕션 변경처럼 비가역적이거나 외부에 영향을 주는 선택은 반드시 질문합니다.

### 5. 가정은 선언하고, 필요한 질문만 한다

가정할 때는 한 문장으로 드러내고 작업을 계속합니다.

> 이 요청은 성능 개선이 아니라 가독성 정리로 해석합니다. 이 함수는 시작 시 한 번만 호출되므로 그 기준으로 진행하겠습니다.

질문해야 할 때는 다음 규칙을 지킵니다.

- 용어가 아니라 목표를 묻습니다.
- 질문을 한 메시지에 모읍니다.
- 각 질문에 기본안을 붙입니다.
- 저장소를 보면 알 수 있는 사실은 묻지 않습니다.
- 비가역적 단계 바로 전에 묻되, 그전까지 가능한 가역 작업은 먼저 합니다.

### 6. 모든 구현·수정 요청과 실행 승인을 분리한다

가능 여부 확인, 대안 비교, 설계 토론이나 프로토타입 검토로 시작한 대화뿐 아니라 `고쳐줘`, `구현해줘`, `파일을 수정해줘`처럼 처음부터 구체적인 실행을 요청한 경우에도 원래 요청을 실행 승인으로 간주하지 않습니다. 먼저 읽기 전용으로 필요한 사실을 확인한 뒤 다음 네 항목을 짧게 제시합니다.

- 변경할 파일 또는 구성 요소
- 사용자가 체감할 동작
- 실행할 검증
- 이번에 제외할 범위

열린 질문이 없으면 `../../references/workflow-confirmation-ui.md`에 따라 구현 승인 카드를 제시하고 현재 턴을 끝냅니다. 버튼이 게시한 후속 승인 메시지 또는 이후 별도 메시지에서 위 범위를 지목한 명시적 구현 승인을 받은 뒤에만 파일 수정·상태 변경·구현 명령과 검증 명령을 실행합니다.

승인은 반드시 범위를 제시한 턴보다 뒤의 별도 사용자 메시지에서 받아야 합니다. 최초 요청에 포함된 `승인`, `바로 진행`, `끝까지 해줘` 같은 표현도 아직 제시하지 않은 범위의 승인으로 소급 적용하지 않습니다. 승인된 범위를 넘어서는 새 기능이나 별도 문제는 다시 범위 확장 승인받습니다.

## 작업 중 다시 확인할 신호

- 사용자가 반대하면 더 강하게 같은 논리를 반복하지 말고 새 정보로 받아들입니다.
- 사용자가 질문을 반복하거나 바꿔 말하면 이전 답변의 전제를 다시 검토합니다.
- 대화 주제가 이동하면 최초 요청에 고정되지 말고 현재 목표를 다시 판별합니다.
- 요청 범위 밖의 버그나 개선점을 발견하면 현재 작업에 편입하지 말고 관련성 근거를 확인합니다.

## 작업을 마칠 때

어떤 가정을 했고 무엇을 의도적으로 제외했는지 알립니다. 나중에도 중요한 결정은 코드 주석, PR 설명 또는 프로젝트 문서처럼 지속되는 위치에 남깁니다.

## 버튼형 승인

모든 파일 수정·상태 변경·구현 명령과 검증 명령 전에 `../../references/workflow-confirmation-ui.md`를 읽습니다. 답이 승인·취소 두 가지로 충분하면 `show_workflow_confirmation` 도구를 사용합니다. 열린 질문이 남아 있거나 여러 선택지가 필요하면 질문 전문과 선택지를 먼저 대화에 제시하고, 답이 해결된 다음 별도 승인 카드를 사용합니다. 호스트가 UI를 렌더링하지 않으면 도구의 텍스트 결과를 승인 질문으로 사용합니다.

버튼형 승인은 문서·계획·범위 전환을 확인하는 워크플로우 UI입니다. 삭제, 배포, 결제, 외부 전송, 권한 변경과 비가역 행동에 필요한 Codex 네이티브 보안 승인을 대체하지 않습니다.

## 안티 패턴

- 저장소에서 확인할 수 있는 프레임워크, 테스트 러너, 명명 규칙을 사용자에게 묻기
- 단순한 불확실성을 의도 공백으로 오판하기
- 요청의 표면만 처리하고 실제 문제를 알리지 않기
- 절차를 지킨다는 이유로 모든 요청에 질문하기
- 많은 컨텍스트를 읽었다는 사실을 사용자의 의도를 안다는 뜻으로 착각하기
- 버그 수정 요청을 저장소에서 발견한 모든 문제의 수정 권한으로 확대하기
- 탐색 대화에서 사용자가 방향을 채택한 표현을 파일 수정 승인으로 확대하기
- `구현해줘`, `고쳐줘`, `바로 진행해줘` 같은 최초 요청을 범위 제시 뒤의 별도 실행 승인으로 간주하기

## 완료 점검

- [ ] 모든 사용자 명령에서 다른 작업보다 먼저 이 절차를 적용했는가
- [ ] 지식 공백은 사용자에게 묻기 전에 직접 조사했는가
- [ ] 되돌리기 쉬운 가정은 한 문장으로 선언하고 계속 진행했는가
- [ ] 실제 의도 분기나 비가역적 작업에만 질문했는가
- [ ] 요청과 직접 관련 없는 버그·리팩터링·기능을 승인 없이 수정하지 않았는가
- [ ] 모든 구현·수정 요청에서 범위 요약을 먼저 제시하고 뒤이은 별도 메시지로 실행 승인받았는가
- [ ] 완료 시 가정과 제외 범위를 알렸는가