| name | improve |
| description | 릴리즈 품질 루프. 기능이 아니라 사용자의 Job을 기준으로 제품을 평가하고 개선한다. "개선해", "품질 올려", "릴리즈 수준으로", "더 다듬어", "/improve" 등을 말할 때 사용. /go 이후 또는 단독 호출 가능. |
역할
너는 기획자다. 코드를 보고 "뭐가 없나?"를 찾는 건 반창고다. 대신 **"이 서비스를 왜 쓰는가?"**에서 출발해서, 사용자의 여정을 걸어보고, 아픈 곳을 찾고, 서비스가 대신 해줄 수 있는 것을 제안한다.
파이프라인에서의 위치
discuss → prd → plan → dev → improve → retrospect → publish → close
| 스킬 | 책임 | 판단 기준 |
|---|
/go | 동작하게 만든다 | typecheck/lint/test/토큰/아키텍처 |
/improve | 릴리즈할 수 있게 만든다 | 사용자의 Job이 충족되는가 |
실행 흐름
Step 1: 대상 + Job 정의
대상을 파악하고, "이 서비스를 쓴다면 어떤 이유로?" 3~5개를 도출한다.
| # | Job | 상황 |
|---|-----|------|
| J1 | | "___할 때 이 도구를 연다" |
| J2 | | |
| J3 | | |
Step 2: Customer Journey Map
각 Job마다 여정 표를 채운다. 이 표가 전체 분석의 뼈대다.
### J1: [Job]
| Stage | Action (하는 것) | Thinking (생각) | Pain (아픈 것) | Wow (서비스가 대신?) |
|-------|-----------------|----------------|---------------|-------------------|
| | | | | |
Stage: 사용자가 이 Job을 완수하기까지 거치는 단계. 3~6개면 충분하다.
Action: 그 단계에서 사용자가 실제로 하는 행동. 구체적으로 — "클릭한다", "머릿속에 기억한다", "눈으로 센다", "에디터를 열어서 확인한다".
Thinking: 그 순간 사용자의 머릿속. "이게 맞나?", "어디부터 봐야 하지?", "이 파일 건드려도 되나?"
Pain: Action에서 불필요하게 사용자가 직접 하는 것. 서비스가 해줄 수 있는데 사용자에게 떠넘긴 것. 구체적으로 쓴다.
- ✅ "레이어 순서를 머릿속에 기억해야 한다"
- ❌ "UX가 좋지 않다" (이건 감상이지 Pain이 아니다)
Wow: "이 Pain을 서비스가 대신 해주면 안 돼?" — 이 칸이 핵심이다.
- ①자동화: 서비스가 완전히 대신한다 → 사용자 행동 자체가 사라진다
- ②구조: 배치/순서/그룹핑으로 자연스럽게 해결된다
- ③표시: badge/color/숫자를 추가한다 (최후 수단)
Pain이 비어있으면 → 그 Stage는 잘 되고 있다. Wow도 비운다.
Wow가 ③표시밖에 안 나오면 → Pain을 더 구체적으로 다시 쓴다. 구체적 Pain에서 ①②가 보인다.
Step 3: Feature 도출
Journey Map의 Pain들을 모아놓고 **"이 Pain들을 한 번에 해결하는 feature는?"**을 묻는다.
버그픽스나 반창고가 아니라 feature가 나와야 한다. feature란:
- 여러 Pain을 동시에 해결한다
- 제품의 성격을 바꾼다 ("탐색 도구"→"조망 도구")
- 사용자의 행동 패턴 자체가 달라진다
절차:
- Journey Map에서 Wow ①②가 채워진 Pain들을 나열한다
- Pain들을 관통하는 공통 원인을 찾는다: "왜 이 Pain들이 동시에 존재하는가?"
- 그 원인을 제거하는 하나의 feature를 정의한다
- 보편성 검증: 이 feature가 이 프로젝트에서만 작동하는 특수 해법인가, 아무 프로젝트에서나 작동하는 제품인가?
- 특수 해법의 징후: 특정 파일(CLAUDE.md, 설정 파일)에 의존, 하드코딩된 도메인 지식, 수동 설정 필요
- 제품의 징후: 코드 자체에서 정보를 자동 도출, 설정 없이 작동, 어떤 코드베이스든 가치 제공
- 특수 해법이 나왔으면 → **"같은 결과를 코드에서 자동으로 도출할 방법은?"**을 묻고 feature를 재정의한다
- 그 feature가 몇 개의 Pain을 동시에 해결하는지 검증한다
## Feature
### Pain 요약
| # | Pain | Job |
|---|------|-----|
| 1 | ... | J1 |
| 2 | ... | J2 |
### 공통 원인
이 Pain들이 동시에 존재하는 이유: ___
### Feature 정의
**[feature 한 줄]**
- 이 feature가 해결하는 Pain: #1, #2, #3
- 제품이 어떻게 바뀌는가: [before → after]
- 사용자의 행동이 어떻게 바뀌는가: [before → after]
- **보편성**: 이 feature는 [어떤 조건의 프로젝트]에서든 작동한다. 이유: [코드에서 자동 도출되는 정보]
### 변경
- [파일:라인] [구체적 수정]
### 검증
- [feature가 Pain을 해결했다는 증거]
feature가 2개 이상 나올 수 있다. 각각 독립적이어야 한다.
Pain 중 feature로 묶이지 않는 것은 부수 개선으로 분리한다 (있으면).
Step 4: 구현
사용자가 선택하면 구현한다.
- CSS 수정 →
/design-implement 스킬
- UI 컴포넌트 →
src/interactive-os/ui/ 완성품 사용
- 수정 후 → typecheck + test + 브라우저 스크린샷 확인
최대 3개 구현. 1개 구현 후 "다음도 진행할까요?"
출력 형식
# /improve — [대상]
## Jobs
| # | Job | 상황 |
|---|-----|------|
| J1 | | |
## J1 Journey Map
| Stage | Action | Thinking | Pain | Wow |
|-------|--------|----------|------|-----|
| | | | | |
## 개선안
### O1: [Pain]
- Pain: ...
- Wow: ...
- 변경: ...
어떤 것을 진행할까요?
종료 보고
=== /improve 완료 ===
평가: [Job 수] jobs, [Stage 수] stages 평가
개선: [구현한 Pain→Wow]
미적용: [제안했지만 선택되지 않은 것]
