improve

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을 동시에 해결한다
• 제품의 성격을 바꾼다 ("탐색 도구"→"조망 도구")
• 사용자의 행동 패턴 자체가 달라진다

절차:

1. Journey Map에서 Wow ①②가 채워진 Pain들을 나열한다
2. Pain들을 관통하는 공통 원인을 찾는다: "왜 이 Pain들이 동시에 존재하는가?"
3. 그 원인을 제거하는 하나의 feature를 정의한다
4. 보편성 검증: 이 feature가 이 프로젝트에서만 작동하는 특수 해법인가, 아무 프로젝트에서나 작동하는 제품인가?
   • 특수 해법의 징후: 특정 파일(CLAUDE.md, 설정 파일)에 의존, 하드코딩된 도메인 지식, 수동 설정 필요
   • 제품의 징후: 코드 자체에서 정보를 자동 도출, 설정 없이 작동, 어떤 코드베이스든 가치 제공
   • 특수 해법이 나왔으면 → **"같은 결과를 코드에서 자동으로 도출할 방법은?"**을 묻고 feature를 재정의한다
5. 그 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]
미적용: [제안했지만 선택되지 않은 것]