Table of Contents
시작
애매한 요청으로 구현하게 되면 planning 단계와 AskUserQuestion을 거친다 해도 디테일을 놓칠 때가 종종 있다. 이를 보완하고자 cc에서는 https://github.com/team-attention/plugins-for-claude-natives?tab=readme-ov-file#clarify clarify plugin 을 사용했다. 이름 그대로 모호한 요구사항을 질문으로 쪼개서 실제로 작업 가능한 형태로 바꾸는 역할이다. 이게 codex 용으로는 없었다. 그래서 codex 에게 분석 및 포팅해달라고 했다.
특히 openclaw 사용할 때 유용하다. 일반적으로 아래와 같은 흐름으로 진행되는데:
- 원문 요구사항을 먼저 그대로 적는다
- ambiguity 를 찾는다
- 한 번에 하나씩, 선택지 중심으로 질문한다 (예: 선택지 주고 내가 거기에 1, 2, 3 번호로 답하기)
- 마지막엔 Before/After 로 정리한다
- 원하면 파일로 저장한다
질문 방식도 규칙이 있다.
- specific over general
- options over open-ended
- one concern at a time
- neutral framing
아무튼 planning 단계에서 빠진 결정들이나 디테일을 모두 챙겨준다. skill 원문에도 보면 No assumptions, Preserve intent, Minimal questions 같은 규칙이 들어가 있음을 볼 수 있다.
Codex Skill
현재 local codex global clarify skill 은 아래와 같다.clarify
---
name: clarify
description: This skill should be used when the user asks to "clarify requirements", "refine requirements", "specify requirements", "what do I mean", "make this clearer", or when the user's request is ambiguous and needs iterative questioning to become actionable. Also trigger when user says "clarify", "/clarify", or mentions unclear/vague requirements.
---
# Clarify
Transform vague or ambiguous requirements into precise, actionable specifications through iterative questioning.
## Purpose
When requirements are unclear, incomplete, or open to multiple interpretations, use structured questioning to extract the user's true intent before any implementation begins.
## Protocol
### Phase 1: Capture Original Requirement
Record the original requirement exactly as stated:
```markdown
## Original Requirement
"{user's original request verbatim}"
```
Identify ambiguities:
- What is unclear or underspecified?
- What assumptions would need to be made?
- What decisions are left to interpretation?
### Phase 2: Iterative Clarification
Ask the user iteratively to resolve each ambiguity. Continue until ALL aspects are clear.
**Question Design Principles:**
- **Specific over general**: Ask about concrete details, not abstract preferences
- **Options over open-ended**: Provide 2-4 choices (recognition > recall)
- **One concern at a time**: Avoid bundling multiple questions
- **Neutral framing**: Present options without bias
**Loop Structure:**
```
while ambiguities_remain:
identify_most_critical_ambiguity()
ask_the_user_a_clarifying_question()
update_requirement_understanding()
check_for_new_ambiguities()
```
**Question Format:**
Ask the user with a clear question and provide labeled options with descriptions. For example:
> **Question**: What authentication method should be used?
>
> Options:
>
> 1. **Username/Password** - Traditional email/password login
> 2. **OAuth** - Google, GitHub, etc. social login
> 3. **Magic Link** - Passwordless email link
### Phase 3: Before/After Comparison
After clarification is complete, present the transformation:
```markdown
## Requirement Clarification Summary
### Before (Original)
"{original request verbatim}"
### After (Clarified)
**Goal**: [precise description of what user wants]
**Scope**: [what's included and excluded]
**Constraints**: [limitations, requirements, preferences]
**Success Criteria**: [how to know when done]
**Decisions Made**:
| Question | Decision |
|----------|----------|
| [ambiguity 1] | [chosen option] |
| [ambiguity 2] | [chosen option] |
```
### Phase 4: Save Option
Ask the user if they want to save the clarified requirement:
> **Question**: Save this requirement specification to a file?
>
> Options:
>
> 1. **Yes, save to file** - Save to requirements/ directory
> 2. **No, proceed** - Continue without saving
If saving:
- Default location: `requirements/` or project-appropriate directory
- Filename: descriptive, based on requirement topic (e.g., `auth-feature-requirements.md`)
- Format: Markdown with Before/After structure
## Ambiguity Categories
Common types to probe:
| Category | Example Questions |
| --------------- | --------------------------------------- |
| **Scope** | What's included? What's explicitly out? |
| **Behavior** | Edge cases? Error scenarios? |
| **Interface** | Who/what interacts? How? |
| **Data** | Inputs? Outputs? Format? |
| **Constraints** | Performance? Compatibility? |
| **Priority** | Must-have vs nice-to-have? |
## Examples
### Example 1: Vague Feature Request
**Original**: "Add a login feature"
**Clarifying questions (ask the user iteratively)**:
1. Authentication method? -> Username/Password
2. Registration included? -> Yes, self-signup
3. Session duration? -> 24 hours
4. Password requirements? -> Min 8 chars, mixed case
**Clarified**:
- Goal: Add username/password login with self-registration
- Scope: Login, logout, registration, password reset
- Constraints: 24h session, bcrypt, rate limit 5 attempts
- Success: User can register, login, logout, reset password
### Example 2: Bug Report
**Original**: "The export is broken"
**Clarifying questions**:
1. Which export? -> CSV
2. What happens? -> Empty file
3. When did it start? -> After v2.1 update
4. Steps to reproduce? -> Export any report
**Clarified**:
- Goal: Fix CSV export producing empty files
- Scope: CSV only, other formats work
- Constraint: Regression from v2.1
- Success: CSV contains correct data matching UI
## Rules
1. **No assumptions**: Ask, don't assume
2. **Preserve intent**: Refine, don't redirect
3. **Minimal questions**: Only what's needed
4. **Respect answers**: Accept user decisions
5. **Track changes**: Always show before/after