jutell 0.3.0

package/assets/skill/references/glossary-ko.md

@@ -0,0 +1,302 @@
+# JuTell — 한국어 용어 reference
+
+이 문서는 `docs/GLOSSARY_POLICY.md`를 실행할 때 필요한 핵심 용어 사전이다. 모든 용어를 자동으로 설명하지 말고, 현재 보고서를 이해하는 데 필요한 경우에만 사용한다.
+
+## 목차
+
+1. [화면과 코드 구조](#1-화면과-코드-구조)
+2. [서버와 데이터](#2-서버와-데이터)
+3. [로그인과 보안](#3-로그인과-보안)
+4. [실행과 검증](#4-실행과-검증)
+5. [Git과 변경](#5-git과-변경)
+6. [배포와 운영](#6-배포와-운영)
+7. [문맥 주의 용어](#7-문맥-주의-용어)
+
+## 1. 화면과 코드 구조
+
+### GUI
+
+GUI(사용자가 눈으로 보고 클릭하거나 입력하는 프로그램 화면)
+
+### CLI
+
+CLI(터미널에 명령어를 입력해 프로그램을 사용하는 방식)
+
+### IDE
+
+IDE(코드를 작성하고 실행하는 개발 도구)
+
+주의: Codex가 파일을 읽고 수정하는 실행 환경을 자동으로 IDE라고 부르지 않는다.
+
+### Component
+
+Component(화면이나 기능을 구성하는 독립적인 코드 조각)
+
+적용 조건: 프로젝트가 Component 구조를 사용하는 것이 확인된 경우에만 사용한다.
+
+### Props
+
+Props(React Component에 전달되는 값)
+
+적용 조건: React 프로젝트에서만 사용한다.
+
+### Hook
+
+Hook(React의 상태나 기능을 재사용하기 위한 기능)
+
+적용 조건: React 프로젝트에서만 사용한다.
+
+### Event
+
+Event(클릭이나 입력처럼 프로그램에서 발생한 동작이나 신호)
+
+문맥에 따라 사용자 동작인지 시스템 신호인지 확인한다.
+
+### Handler
+
+Handler(특정 동작이 발생했을 때 실행되는 기능)
+
+### State
+
+State(화면이나 기능이 현재 가지고 있는 값이나 상태)
+
+현재 프로젝트에서 입력값, 로그인 상태, 검색 진행 상태 중 무엇을 뜻하는지 확인한다.
+
+### Layout
+
+Layout(화면 요소를 배치하는 구조)
+
+## 2. 서버와 데이터
+
+### API
+
+API(프로그램끼리 정보를 주고받는 연결 통로)
+
+### Endpoint
+
+Endpoint(API 요청을 보내거나 받는 구체적인 주소)
+
+### Request
+
+Request(프로그램에 작업이나 정보를 요청하는 것)
+
+### Response
+
+Response(요청에 대해 프로그램이 돌려주는 결과)
+
+### Server
+
+Server(요청을 받아 처리하고 결과를 돌려주는 프로그램)
+
+### Client
+
+Client(서버에 요청을 보내고 결과를 사용하는 프로그램이나 화면)
+
+### Database
+
+Database(프로그램의 정보를 저장하고 관리하는 시스템)
+
+### Schema
+
+Schema(데이터가 어떤 항목과 구조로 저장되는지 정한 규칙)
+
+### Query
+
+Query(데이터를 조회하거나 변경하기 위해 보내는 요청)
+
+### Migration
+
+Migration(데이터베이스 구조를 변경하고 적용하는 작업)
+
+### Cache
+
+Cache(다시 사용할 정보를 빠르게 가져오도록 임시로 저장하는 기능)
+
+### 입력 검증
+
+입력 검증(입력한 값이 필요한 조건에 맞는지 먼저 확인하는 기능)
+
+시나리오 B에서는 다음 의미를 유지한다.
+
+> 검색어가 필요한 조건에 맞는지 검색 실행 전에 먼저 확인하는 기능
+
+### Dependency
+
+Dependency(프로젝트가 사용하기 위해 의존하는 다른 코드나 패키지)
+
+### Package
+
+Package(설치해서 사용할 수 있도록 묶어 놓은 코드와 설정)
+
+### Framework
+
+Framework(프로그램을 일정한 구조로 만들도록 도와주는 개발 기반)
+
+### Library
+
+Library(특정 기능을 가져다 사용할 수 있는 코드 모음)
+
+## 3. 로그인과 보안
+
+### Authentication
+
+Authentication(사용자가 누구인지 확인하는 과정)
+
+한국어 보고서에서는 `인증(Authentication, 사용자가 누구인지 확인하는 과정)`처럼 쓸 수 있다.
+
+### Authorization
+
+Authorization(확인된 사용자가 어떤 기능을 사용할 수 있는지 판단하는 과정)
+
+한국어 보고서에서는 `권한 확인(Authorization, 사용자가 해당 기능을 사용할 수 있는지 판단하는 과정)`처럼 쓸 수 있다.
+
+### Session
+
+Session(여러 요청을 같은 사용자나 작업의 흐름으로 연결하는 정보)
+
+로그인 문맥에서는 로그인 상태를 일정 시간 유지하는 정보라는 뜻으로 설명할 수 있다.
+
+### Token
+
+Token(인증이나 접근 권한을 확인할 때 사용하는 값)
+
+실제 Token 값은 보고서에 출력하지 않는다. 현재 프로젝트에서 다른 용도로 사용되면 그 문맥을 우선한다.
+
+### Cookie
+
+Cookie(브라우저가 로그인 상태나 설정을 기억하기 위해 저장하는 작은 정보)
+
+### Middleware
+
+Middleware(요청과 실제 기능 사이에서 추가 확인이나 처리를 하는 중간 기능)
+
+처리가 실행 전인지, 실행 후인지, 요청과 응답 모두에 적용되는지 현재 코드를 확인한다.
+
+### Permission
+
+Permission(사용자가 특정 기능을 사용할 수 있는 권한)
+
+### Secret
+
+Secret(외부에 공개하면 안 되는 민감한 값)
+
+예: API 키, 비밀번호, 접근 토큰, 인증 쿠키, 연결 문자열.
+
+### Environment Variable
+
+Environment Variable(코드 밖에서 설정값이나 비밀 값을 전달하는 방식)
+
+실제 값은 보고서에 표시하지 않고 변수 이름만 표시한다.
+
+## 4. 실행과 검증
+
+### Runtime
+
+Runtime(프로그램이 실제로 실행되는 환경)
+
+### Build
+
+Build(작성한 코드를 실행하거나 배포할 수 있는 형태로 준비하는 과정)
+
+### Compile
+
+Compile(작성한 코드를 다른 실행 가능한 형태로 바꾸는 과정)
+
+### Unit Test
+
+Unit Test(작은 기능 하나가 올바르게 작동하는지 확인하는 자동 테스트)
+
+### Integration Test
+
+Integration Test(여러 기능이 연결됐을 때 함께 작동하는지 확인하는 테스트)
+
+### Lint
+
+Lint(코드 형식이나 잠재적인 문제를 자동으로 검사하는 도구)
+
+### Type Check
+
+Type Check(코드에서 사용하는 값의 종류가 서로 맞는지 검사하는 과정)
+
+### Refactoring
+
+Refactoring(기능을 바꾸지 않는 것을 목표로 코드 구조를 정리하는 작업)
+
+Refactoring 후 기능이 실제로 유지됐는지는 별도 검증이 필요하다.
+
+## 5. Git과 변경
+
+### Diff
+
+Diff(수정 전과 수정 후의 차이)
+
+### Commit
+
+Commit(Git에 변경 내용을 하나의 기록으로 저장하는 것)
+
+### Branch
+
+Branch(코드 변경을 분리해 작업하는 개발 흐름 또는 기록)
+
+Branch를 실제 별도 폴더나 작업 공간으로 설명하지 않는다.
+
+### Merge
+
+Merge(분리해서 작업한 변경 내용을 하나의 흐름으로 합치는 작업)
+
+## 6. 배포와 운영
+
+### Deploy
+
+Deploy(프로그램을 실제 사용 가능한 환경에 반영하는 작업)
+
+### Production
+
+Production(실제 사용자가 이용하는 운영 환경)
+
+### Staging
+
+Staging(실제 배포 전에 운영 환경과 비슷하게 시험하는 환경)
+
+### Hosting
+
+Hosting(웹사이트나 프로그램을 실행할 공간을 제공하는 서비스)
+
+### Domain
+
+Domain(사용자가 웹사이트에 접속할 때 사용하는 주소)
+
+### Rollback
+
+Rollback(문제가 생긴 변경을 이전 상태로 되돌리는 작업)
+
+### Log
+
+Log(프로그램에서 발생한 동작, 상태 또는 오류를 기록한 내용)
+
+## 7. 문맥 주의 용어
+
+다음 용어는 하나의 정의로 고정하지 않는다.
+
+| 용어 | 확인할 문맥 |
+|---|---|
+| Route | 웹 페이지 주소, 서버 API 경로, 화면 이동 규칙 중 무엇인지 확인 |
+| State | 입력값, 로그인 상태, 화면 표시 상태 등 무엇을 기억하는지 확인 |
+| Event | 사용자 동작인지 시스템 신호인지 확인 |
+| Session | 로그인 유지 정보인지, 일반 작업 흐름인지 확인 |
+| Token | 인증 토큰인지, 다른 용도의 식별 값인지 확인 |
+| Middleware | 요청 전 처리인지, 요청·응답을 함께 처리하는지 확인 |
+
+문맥을 확인하지 못하면 다음과 같이 표시한다.
+
+> 이 용어가 현재 프로젝트에서 정확히 어떤 역할을 하는지는 확인하지 못했습니다.
+
+## 잘못된 설명을 피하는 예
+
+| 피해야 할 표현 | 권장 방향 |
+|---|---|
+| GUI는 AI와 대화하는 공간이다 | GUI는 사용자가 보고 조작하는 프로그램 화면이다 |
+| Database는 컴퓨터의 머리다 | Database는 정보를 저장하고 관리하는 시스템이다 |
+| Middleware는 요청을 가로채는 계층이다 | Middleware는 요청과 기능 사이에서 추가 처리를 하는 중간 기능이다 |
+| Branch는 별도 작업 폴더다 | Branch는 변경을 분리하는 개발 흐름 또는 기록이다 |
+| 입력 검증은 Submit handler에 guard를 넣는 것이다 | 입력한 값이 조건에 맞는지 실행 전에 확인하는 기능이다 |

package/assets/skill/references/report-format.md

@@ -0,0 +1,176 @@
+# JuTell — Report Format Reference
+
+이 문서는 `docs/BEGINNER_REPORT_SPEC.md`의 짧은 실행용 형식이다. 상황에 맞는 형식만 사용하고 내용을 반복하지 않는다.
+
+## 1. 정보 체계
+
+서로 다른 네 가지 정보를 섞지 않는다.
+
+* 근거 출처: 파일, Git, 명령, 브라우저 또는 실제 실행, 코드 예상, 사용자 제공 정보
+* 확인 상태: 확인됨, 일부 확인, 확인하지 못함
+* 사용자 행동: 사용자 확인 필요, 추가 테스트 권장, 설정 필요, 사용자 결정 필요
+* 보고서 상태: 확인 완료, 추가 확인 필요, 일부 확인, 작업 보류, 범위 밖
+
+검증 결과는 별도로 표시한다.
+
+* 통과
+* 일부 통과
+* 실패
+* 실행하지 못함
+* 실행하지 않음
+* 검증 수단 없음
+
+중요한 주장에는 가능한 경우 근거와 확인 상태를 함께 적는다. 코드만 보고 예상한 내용은 `근거: 코드 예상`과 `확인 상태: 확인하지 못함`으로 표시한다.
+
+## 2. 단순 작업 보고
+
+문구, 색상, 작은 화면 배치처럼 위험이 낮은 작업에 사용한다.
+
+```md
+## 변경 요약
+<무엇을 바꿨는지 한두 문장>
+
+## 사용자에게 달라지는 점
+<확인됨 또는 예상됨을 표시한 화면 변화>
+
+## 프로그램 내부에서 달라진 점
+<내부 기능 변화 또는 없음>
+
+## 주요 수정 파일
+- `<파일>` — <역할 한 문장>
+
+## 검증 결과
+- 근거: <출처>
+- 확인 상태: <상태>
+- <실행한 검증과 실행하지 않은 검증>
+
+## 위험과 사용자 확인
+- 위험도: <낮음/중간/높음/판정 불가>
+- 근거: <짧은 이유>
+- <필요한 사용자 행동>
+- 보고서 상태: <상태>
+```
+
+단순 작업은 기본 항목마다 1~2문장, 주요 파일 최대 3개, 전체 기본 12문장 또는 약 25줄을 우선한다. 안전 문제나 중요한 실패가 있으면 정확한 경고를 우선한다.
+
+## 3. 일반 작업 보고
+
+기능 동작이 바뀌거나 여러 파일이 수정된 경우 사용한다.
+
+* 기본 6개 항목을 유지한다.
+* 주요 파일은 최대 5개를 설명한다.
+* 검증 결과, 미확인 항목, 위험도 근거를 분리한다.
+* 나머지 파일은 필요할 때 목록이나 개수로 요약한다.
+
+## 4. 최소 보고
+
+사용자가 상세 보고를 생략해달라고 요청한 경우 사용한다.
+
+```md
+작업 완료 여부: <완료/미완료>
+주요 수정 파일: <파일 또는 확인하지 못함>
+중요한 실패 또는 확인하지 못한 항목: <내용 또는 없음>
+```
+
+안전 문제, 데이터 손실 가능성, 비밀정보 노출, 핵심 검증 실패는 최소 보고에서도 생략하지 않는다.
+
+## 5. 계획 요청
+
+실제 변경 전에는 완료 보고서처럼 쓰지 않는다.
+
+* 변경 목표
+* 예상 변경 범위
+* 영향을 받을 수 있는 기능
+* 확인할 파일
+* 필요한 검증
+* 아직 결정되지 않은 사항
+
+## 6. 코드 또는 파일 설명 요청
+
+전체 작업 보고서를 강제로 만들지 않는다. 요청한 범위에서 필요한 항목만 설명한다.
+
+* 이 코드나 파일의 역할
+* 언제 사용되는지
+* 입력과 결과 중 필요한 내용
+* 수정 시 영향 가능성
+
+여러 코드 블록을 한 줄씩 설명하지 않고 기능 블록으로 묶는다.
+
+## 6.5 코드 또는 Diff 설명
+
+코드·Diff 원문을 요청받았거나 실제로 제시한 경우에만 적용한다. 코드 원문을 제시하지 않은 일반 완료 보고에는 강제하지 않는다.
+
+* 모든 줄을 하나씩 해설하지 않는다.
+* 기능 단위로 묶어 설명한다.
+* 파일 역할
+* 변경 전 문제
+* 변경한 내용
+* 사용자에게 보이는 변화
+* 수정 시 주의할 영향
+* 확인된 사실과 예상 구분
+* Diff가 매우 길면 핵심 구간만 설명하고 전체 원문 반복 금지
+
+```md
+### 변경 내용 설명
+
+- 이 코드는 <파일 역할>.
+- 기존에는 <변경 전 문제>.
+- 이제 <변경한 내용>과 <사용자에게 보이는 변화>.
+- 주의: <수정 시 영향 또는 확인 상태>.
+```
+
+## 6.6 다음 행동 제안
+
+`nextActionSuggestions`가 활성일 때 보고서 마지막에 한 문장 제안을 **최대 3개**만 추가한다. 다음 경우에만 추가한다.
+
+* 사용자가 직접 확인해야 할 항목이 남은 경우
+* 검증되지 않아 보류된 항목이 있는 경우
+* 설정이 필요한 경우
+* 데이터 손실·보안 위험이 확인된 경우
+
+```md
+## 다음 행동 제안
+- 실제 화면에서 검색 버튼을 눌러 확인해주세요.
+- `WEATHER_API_KEY` 설정을 마치면 결과를 다시 확인해주세요.
+```
+
+제안은 보고서에 이미 있는 확인 항목 중에서만 고르고, 추측이나 새 작업을 제안하지 않는다. 해당하지 않으면 섹션을 만들지 않는다.
+
+## 6.7 설명형 변경 요약
+
+`explainedDiff` Feature가 활성일 때 의미 있는 변경(기능 동작·화면 변화·데이터 처리 변화)은 무엇을 바꿨나요·왜 바꿨나요·어디를 바꿨나요·실제 중요한 변경 순으로 묶어 설명할 수 있다.
+
+* 근거가 없는 변경 이유는 추측하지 않고 "변경 이유는 Agent 결과에서 확인되지 않았습니다."로 표시한다.
+* 문구·색상·경로처럼 직접 다듬을 수 있는 위치의 코드 근거가 있을 때만 "내가 직접 다듬고 싶다면?"을 덧붙인다.
+* 단순 작업에는 이 형식을 강제하지 않고 기존 6개 항목을 유지한다.
+
+형식과 예시는 `references/explained-diff-format.md`를 따른다.
+
+## 7. 금지 표현
+
+근거가 없으면 다음 표현을 사용하지 않는다.
+
+* 완벽하게 작동합니다
+* 모든 문제가 해결됐습니다
+* 오류가 전혀 없습니다
+* 기존 기능에 영향이 없습니다
+* 배포해도 됩니다
+* 안전합니다
+* 모든 테스트가 통과했습니다
+* 화면이 정상적으로 표시됩니다
+
+대신 확인한 범위, 실행한 검증, 남은 미확인 사항을 적는다.
+
+## 8. 로컬 Feature 설정
+
+프로젝트 루트의 `.jutell.json` 우선, 없으면 `.beginner-bridge.json`을 확인한다.
+
+* 파일이 없으면 `balanced` 기본값을 사용한다.
+* JSON, Profile, Feature ID, 값 형식 또는 limits가 잘못되면 설정 전체를 추측하지 않고 `balanced`로 진행한다.
+* 잘못된 설정이 있었을 때만 설정 문제를 짧게 알리고 설정 파일 전체를 출력하지 않는다.
+* 명시적 `features`와 `limits`는 Profile 기본값보다 우선한다.
+* 사용자가 요청한 보고 형식과 안전상 강제 보고 항목은 Feature를 끄더라도 적용한다.
+* 실패, 핵심 검증 실패, 중요한 미확인 사항, 높은 위험·판정 불가, 비밀정보·데이터 손실 위험, 범위 밖 변경과 작업 보류 사유는 숨기지 않는다.
+* limits는 선택 정보의 길이와 수에 적용하며 안전상 강제 정보에는 적용하지 않는다.
+
+Feature ID별 상세 예외는 `references/feature-registry.md`, 전체 정책은 `docs/FEATURE_CONFIGURATION.md`를 참조한다.

package/assets/skill/references/risk-level-guide.md

@@ -0,0 +1,85 @@
+# JuTell — Risk Level Guide
+
+이 문서는 `docs/BEGINNER_REPORT_SPEC.md`의 위험도 규칙을 짧게 적용하기 위한 reference다. 위험도는 정상 작동 여부가 아니라 변경이 기존 기능에 미칠 수 있는 영향의 크기다.
+
+## 1. 낮음
+
+프로그램 핵심 동작에 영향을 줄 가능성이 작은 변경이다.
+
+* 일반 문구
+* 색상, 여백, 단순 화면 배치
+* 문서나 주석
+* 테스트 설명
+
+예: 로그인 버튼의 문구와 `#2563EB` 색상만 변경하고 로그인 처리 코드는 건드리지 않은 경우.
+
+## 2. 중간
+
+특정 기능이나 한정된 사용자 흐름의 동작에 영향을 줄 수 있는 변경이다.
+
+* 버튼 동작
+* 입력 검증
+* 특정 페이지 이동
+* 특정 기능의 상태 처리
+* 특정 페이지의 데이터 표시
+* 파일 업로드
+* 로컬 저장 방식
+
+예: 검색 실행 전에 빈 검색어인지 확인하는 조건을 추가한 경우.
+
+## 3. 높음
+
+여러 기능, 중요한 데이터, 보안 또는 운영 환경에 영향을 줄 수 있는 변경이다.
+
+* 로그인과 인증
+* 권한
+* 결제
+* 데이터베이스 구조
+* 공통 상태 관리
+* 공통 API 처리
+* 외부 서비스 연결
+* 비밀정보 처리
+* 배포 설정
+* 여러 기능이 사용하는 공통 로직
+
+## 4. 판정 불가
+
+실행 환경이 없다는 이유만으로 판정 불가로 만들지 않는다. 코드나 변경 범위 자체를 충분히 읽지 못해 영향도를 판단할 근거가 없을 때 사용한다.
+
+예:
+
+* 변경 파일을 열 수 없음
+* 기존 변경과 이번 변경을 구분할 수 없고 영향 범위도 확인하지 못함
+* 프로젝트 구조가 불명확해 수정 대상의 역할을 파악할 수 없음
+
+코드를 읽었지만 테스트나 브라우저를 실행하지 못한 경우에는 가능한 범위에서 위험도를 판단하고, 검증 상태를 별도로 표시한다.
+
+## 5. 여러 조건이 겹칠 때
+
+여러 위험도 조건에 해당하면 가장 높은 위험도를 적용한다. 파일 이름이 아니라 실제 변경 내용을 기준으로 한다.
+
+단, 인증 파일 안의 주석만 수정한 것처럼 실제 변경 내용이 문서·주석 수준인 경우에는 변경 내용에 맞춰 낮음으로 판단할 수 있다.
+
+위험도에는 한두 문장의 근거를 함께 작성한다.
+
+## 6. 검증 가능성과 분리
+
+위험도와 검증 가능성은 서로 다른 판단이다.
+
+* 위험도: 변경이 얼마나 넓고 중요한 기능에 영향을 줄 수 있는가
+* 검증 가능성: 테스트, 브라우저, 권한, 도구로 실제 결과를 확인할 수 있는가
+
+예:
+
+* 브라우저를 실행하지 못했지만 로그인 처리 코드를 읽음 → 위험도 높음, 화면 검증은 확인하지 못함
+* 파일을 읽지 못해 변경 범위를 모름 → 위험도 판정 불가
+
+## 7. V0.1 시나리오
+
+### 시나리오 A
+
+로그인 버튼 문구와 색상만 변경하면 낮음이다. 로그인 처리, 인증, 세션, 공통 버튼 동작까지 변경하면 실제 변경 범위에 따라 중간 또는 높음이다.
+
+### 시나리오 B
+
+검색어가 비어 있을 때 검색 요청을 막는 입력 조건 변경은 중간이다. 공통 검색 로직, 검색 API, 데이터 저장 방식을 함께 변경하면 높음으로 올린다.

package/assets/templates/request-builder/BUG_REPORT_REQUEST.md

@@ -0,0 +1,100 @@
+# 문제(버그) 신고서
+
+> 작성법: `[ ]`에 체크하고, 빈칸은 쉬운 말로 채웁니다. 모르는 항목은 비워 두세요.
+
+## 1. 지금 만들고 있는 것
+
+지금 만들고 있는 화면이나 프로젝트를 한두 문장으로 설명해 주세요.
+
+```
+(예: 사용자가 검색어를 입력하면 결과를 보여주는 화면)
+```
+
+- [ ] 잘 모르겠음
+- [ ] AI가 먼저 확인 후 제안
+
+## 2. 어떤 문제가 있나요?
+
+무엇이 어떻게 이상한지 있는 그대로 적어 주세요. 어디서부터 잘못됐는지 몰라도 괜찮습니다.
+
+```
+(예: 검색 버튼을 눌러도 아무 반응이 없다)
+```
+
+- [ ] 정확히 무엇이 문제인지 모르겠음 (어떤 점이 이상한지 느껴지지만 특정하지 못함)
+- [ ] 잘 모르겠음
+- [ ] AI가 먼저 확인 후 제안
+
+## 3. 언제 문제가 생기나요?
+
+문제가 생기는 상황을 가능한 한 자세히 적어 주세요. 기억나는 순서대로 적으면 됩니다.
+
+```
+(예: 검색어를 입력하고 Enter를 누르면 화면이 멈춘다. 몇 초 뒤 다시 동작한다)
+```
+
+- [ ] 항상 발생함
+- [ ] 가끔 발생함
+- [ ] 특정 조건에서만 발생함 (아래에 조건을 적어 주세요)
+- [ ] 정확히 언제인지 모르겠음
+
+```
+(특정 조건이 있으면 여기에 적기)
+```
+
+## 4. 원하는 결과
+
+문제가 해결되면 어떻게 동작하길 원하는지 적어 주세요.
+
+```
+(예: 버튼을 누르면 바로 검색 결과가 보인다)
+```
+
+- [ ] 잘 모르겠음 (AI가 원래 의도된 동작을 확인해 알려주기)
+
+## 5. 반드시 유지할 부분
+
+이번 수정에서 지금 있는 것 중 없어지면 안 되는 것을 적어 주세요.
+
+```
+(예: 검색 결과 정렬 순서는 그대로 유지)
+```
+
+- [ ] 현재 상태 유지
+- [ ] 요청하지 않음
+
+## 6. 사용자가 직접 확인할 부분
+
+수정 뒤 사용자가 직접 눌러 보거나 확인해야 하는 것을 적어 주세요.
+
+```
+(예: 검색 버튼을 눌렀을 때 결과가 보이는지)
+```
+
+- [ ] 요청하지 않음
+
+## 7. AI가 먼저 확인할 질문
+
+- [ ] AI가 먼저 문제를 재현해 보고 원인을 찾아 알려주세요.
+- [ ] 문제가 데이터 손실이나 보안과 관련될 가능성이 있는지 확인해 알려주세요.
+- [ ] 원인을 못 찾으면 어떤 정보가 더 필요한지 알려주세요.
+- [ ] AI가 먼저 확인 후 제안 (위 항목 대신 AI 판단에 맡김)
+
+## 8. 최종 요청문
+
+아래를 복사해서 사용 중인 AI Agent에 붙여넣으세요. `( )` 자리에 위 내용을 합쳐서 적어도 됩니다.
+
+```text
+이 프로젝트에서 다음 문제를 확인하고 고쳐주세요.
+
+[문제 내용] (2번 항목 내용)
+[발생 상황] (3번 항목 내용)
+[원하는 결과] (4번 항목 내용)
+[유지할 부분] (5번 항목, 없으면 "없음")
+[사용자 확인] (6번 항목, 없으면 "없음")
+
+체크되지 않은 항목은 비워 두었습니다.
+먼저 문제를 재현하고 원인을 찾은 뒤 수정 계획을 알려주세요.
+원인을 확정하기 전에는 추측을 확정된 사실처럼 말하지 말아주세요.
+데이터 손실이나 보안 관련 가능성이 있으면 작업 전에 먼저 알려주세요.
+```