개발 작업 전 맥락 이해, 가설 검증, 파일 단위 구현 계획을 코드 생성 없이 먼저 승인받을 때 사용합니다.
### Context
[Why are we doing the change?]
### Desired Behavior
[What is the desired behavior ?]
### Instruction
Explain your comprehension of the requirements.
List 5 hypotheses you would like me to validate.
Create a plan to implement the ${desired_behavior}
### Symbol and action
➕ Add : Represent the creation of a new file
✏️ Edit : Represent the edition of an existing file
❌ Delete : Represent the deletion of an existing file
### Files to be modified
* The list of files list the files you request to add, modify or delete
* Use the ${symbol_and_action} to represent the operation
* Display the ${symbol_and_action} before the file name
* The symbol and the action must always be displayed together.
** For exemple you display “➕ Add : GameModePuzzle.tsx”
** You do NOT display “➕ GameModePuzzle.tsx”
* Display only the file name
** For exemple, display “➕ Add : GameModePuzzle.tsx”
* DO NOT display the path of the file.
** For example, do not display “➕ Add : components/game/GameModePuzzle.tsx”
### Plan
* Identify the name of the plan as a title.
* The title must be in bold.
* Do not precede the name of the plan with "Name :"
* Present your plan as a numbered list.
* Each step title must be in bold.
* Focus on the user functional behavior with the app
* Always use plain English rather than technical terms.
* Strictly avoid writing out function signatures (e.g., myFunction(arg: type): void).
* DO NOT include specific code syntax, function signatures, or variable types in the plan steps.
* When mentioning file names, use bold text.
**After the plan, provide**
* Confidence level (0 to 100%).
* Risk assessment (likelihood of breaking existing features).
* Impacted files (See ${files_to_be_modified})
### Constraints
* DO NOT GENERATE CODE YET.
* Wait for my explicit approval of the plan before generating the actual code changes.
* Designate this plan as the “Current plan”### 맥락
[변경하려는 이유]
### 원하는 동작
[원하는 동작 설명]
### 지시사항
요구사항에 대한 이해도를 설명하세요.
검증이 필요한 가설 5가지를 제시하세요.
${desired_behavior}를 구현하기 위한 계획을 작성하세요.
### 기호 및 작업
➕ Add : 새 파일 생성
✏️ Edit : 기존 파일 수정
❌ Delete : 기존 파일 삭제
### 수정 대상 파일
* 추가, 수정, 삭제할 파일 목록을 작성합니다.
* 작업 구분을 위해 ${symbol_and_action} 기호를 사용합니다.
* 파일명 앞에 기호와 작업을 함께 표시합니다.
** 예: “➕ Add : GameModePuzzle.tsx”
** 제외 예시: “➕ GameModePuzzle.tsx”
* 파일 이름만 표시합니다.
** 예: “➕ Add : GameModePuzzle.tsx”
* 파일 경로는 표시하지 마세요.
** 제외 예시: “➕ Add : components/game/GameModePuzzle.tsx”
### 계획
* 플랜 제목을 명시하세요.
* 제목은 굵은 글씨로 작성하세요.
* 제목 앞에 "Name :"을 붙이지 마세요.
* 번호 매기기 목록으로 계획을 제시하세요.
* 각 단계의 제목은 굵은 글씨로 작성하세요.
* 전문 기술 용어보다 일반적인 표현을 사용하고 사용자의 기능적 동작에 집중하세요.
* 함수 시그니처나 특정 코드 문법, 변수 타입을 계획 단계에 절대 작성하지 마세요.
* 파일명을 언급할 때는 굵은 글씨를 사용하세요.
**계획 작성 후 다음 내용 포함:**
* 신뢰도 수준 (0 ~ 100%)
* 리스크 평가 (기존 기능 손상 가능성)
* 영향받는 파일 목록
### 제약사항
* 아직 코드를 생성하지 마세요.
* 실제 코드를 변경하기 전에 계획에 대한 명시적 승인을 기다리세요.
* 이 계획을 “Current plan”으로 지정하세요.출처 · prompts.chat · Present — 원문은 출처에 게시된 그대로이며, 권리는 원작자에게 있습니다.
Gemini로 실행한 결과입니다. 입력 항목에는 국내 환경의 예시값을 적용했습니다(AI 생성 — 사실 확인 필요).
### Context
Users are abandoning shopping carts on our Korean online store due to a lengthy multi-step checkout process.
### Desired Behavior
Implement a single-page checkout experience integrated with KakaoPay and NaverPay fast checkout options.
### Instruction
Explain your comprehension of the requirements.
List 5 hypotheses you would like me to validate.
Create a plan to implement the ${desired_behavior}
### Symbol and action
➕ Add : Represent the creation of a new file
✏️ Edit : Represent the edition of an existing file
❌ Delete : Represent the deletion of an existing file
### Files to be modified
* The list of files list the files you request to add, modify or delete
* Use the ${symbol_and_action} to represent the operation
* Display the ${symbol_and_action} before the file name
* The symbol and the action must always be displayed together.
** For exemple you display “➕ Add : GameModePuzzle.tsx”
** You do NOT display “➕ GameModePuzzle.tsx”
* Display only the file name
** For exemple, display “➕ Add : GameModePuzzle.tsx”
* DO NOT display the path of the file.
** For example, do not display “➕ Add : components/game/GameModePuzzle.tsx”
### Plan
* Identify the name of the plan as a title.
* The title must be in bold.
* Do not precede the name of the plan with "Name :"
* Present your plan as a numbered list.
* Each step title must be in bold.
* Focus on the user functional behavior with the app
* Always use plain English rather than technical terms.
* Strictly avoid writing out function signatures (e.g., myFunction(arg: type): void).
* DO NOT include specific code syntax, function signatures, or variable types in the plan steps.
* When mentioning file names, use bold text.
**After the plan, provide**
* Confidence level (0 to 100%).
* Risk assessment (likelihood of breaking existing features).
* Impacted files (See ${files_to_be_modified})
### Constraints
* DO NOT GENERATE CODE YET.
* Wait for my explicit approval of the plan before generating the actual code changes.
* Designate this plan as the “Current plan”요구사항 이해
한국 이커머스 사용자들의 결제 이탈을 줄이기 위해 기존의 복잡한 다단계 결제 절차를 단일 페이지 결제 화면으로 통합하고, 카카오페이 및 네이버페이 간편 결제 기능을 제공하는 것입니다.
검증이 필요한 5가지 가설
Current plan: Single-Page Fast Checkout Implementation
➕ Add : CheckoutPage.tsx
✏️ Edit : OrderSummary.tsx
❌ Delete : MultiStepWizard.tsx
mopick 개선안
원문을 그대로 넣으면 AI 가 매번 다르게 답하거나 중요한 부분을 빠뜨릴 수 있습니다. 개선안은 원문의 뜻과 언어는 그대로 두고 역할 · 바꿔 넣을 입력 칸 · 결과 형식 · 지킬 조건을 보완해 다시 쓴 버전입니다. 원문과 같은 곳(ChatGPT · Claude 등)에 그대로 붙여 넣어 쓰면 됩니다.
AI 평가 점수 — 명확성 · 구체성 · 결과 형식 · 재사용성 기준(100점)
AI 역할레슨 01 배우기 ›
원문 · 없음AI 에게 맡길 역할이 정해져 있지 않아 답의 관점 · 수준이 그때그때 달라질 수 있었습니다.
개선 · 역할을 정함You are an expert Senior Software Architect.
입력 칸레슨 05 배우기 ›
원문 · 3개바꿔 넣을 자리가 일부만 표시돼 있어 쓸 때마다 원문을 고쳐야 했습니다.
개선 · 4개[FileName]
작업 순서레슨 07 배우기 ›
원문 · 없음작업 순서가 정해져 있지 않아 AI 가 순서를 스스로 정해야 했습니다.
개선 · 3단계
이 개선안에 쓰인 기법 — 프롬프트 클래스에서 배우기
원문
### Context
[Why are we doing the change?]
### Desired Behavior
[What is the desired behavior ?]
### Instruction
Explain your comprehension of the requirements.
List 5 hypotheses you would like me to validate.
Create a plan to implement the ${desired_behavior}
### Symbol and action
➕ Add : Represent the creation of a new file
✏️ Edit : Represent the edition of an existing file
❌ Delete : Represent the deletion of an existing file
### Files to be modified
* The list of files list the files you request to add, modify or delete
* Use the ${symbol_and_action} to represent the operation
* Display the ${symbol_and_action} before the file name
* The symbol and the action must always be displayed together.
** For exemple you display “➕ Add : GameModePuzzle.tsx”
** You do NOT display “➕ GameModePuzzle.tsx”
* Display only the file name
** For exemple, display “➕ Add : GameModePuzzle.tsx”
* DO NOT display the path of the file.
** For example, do not display “➕ Add : components/game/GameModePuzzle.tsx”
### Plan
* Identify the name of the plan as a title.
* The title must be in bold.
* Do not precede the name of the plan with "Name :"
* Present your plan as a numbered list.
* Each step title must be in bold.
* Focus on the user functional behavior with the app
* Always use plain English rather than technical terms.
* Strictly avoid writing out function signatures (e.g., myFunction(arg: type): void).
* DO NOT include specific code syntax, function signatures, or variable types in the plan steps.
* When mentioning file names, use bold text.
**After the plan, provide**
* Confidence level (0 to 100%).
* Risk assessment (likelihood of breaking existing features).
* Impacted files (See ${files_to_be_modified})
### Constraints
* DO NOT GENERATE CODE YET.
* Wait for my explicit approval of the plan before generating the actual code changes.
* Designate this plan as the “Current plan”개선안 · 색칠한 [칸]에 내 내용을 넣어 쓰세요
You are an expert Senior Software Architect. ### Context [Explain the background and motivation for this change] ### Desired Behavior [Describe the expected end-user functional behavior] ### Instructions 1. **Comprehension**: Briefly summarize your understanding of the requirements. 2. **Hypotheses**: List exactly 5 hypotheses or assumptions you need me to validate. 3. **Implementation Plan**: Create a plan titled "**Current plan**" to implement the desired behavior. ### Plan Guidelines * Present the plan as a numbered list with **bold step titles**. * Focus strictly on functional user behavior using plain English. * DO NOT include code syntax, function signatures (e.g., `func(arg: type): void`), or variable types. * When mentioning file names in text, use **bold**. ### Output Artifacts (Provide after the plan) * **Confidence level**: (0 to 100% with a brief explanation) * **Risk assessment**: (Likelihood of breaking existing features) * **Impacted files**: List files using only file names (NO paths) formatted strictly as: - ➕ Add : **[FileName]** - ✏️ Edit : **[FileName]** - ❌ Delete : **[FileName]** ### Constraints * DO NOT GENERATE CODE YET. * Wait for explicit approval of the plan before generating the actual code changes.