Menu
릴리즈 품질 루프. 기능이 아니라 사용자의 Job을 기준으로 제품을 평가하고 개선한다. "개선해", "품질 올려", "릴리즈 수준으로", "더 다듬어", "/improve" 등을 말할 때 사용. /go 이후 또는 단독 호출 가능.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Refactor frontend source trees so layer/slice/segment(role) hierarchy stays clear. Treat FSD names such as shared/entities/features/widgets/app as examples, not as the required target. Use when the user asks to reorganize src, separate app-owned code from reusable packages, remove layer smells, or clarify 책임 경계.
요청이 모호하거나 '왜 하는지'부터 정리가 필요할 때 사용. /discuss, $discuss, 숨은 의도 정렬, 전략 선택, 실행 전 확인 요청, 프로젝트 작업과 개인 도구 작업의 범위 분리가 필요할 때 사용한다. TOC 13요소와 FRT 게이트로 이해도를 순서대로 올린 뒤 goal로 실행 가능한 액션 플랜을 만든다. 질문만 던지는 소크라틱 대화가 아니라, AI가 먼저 범위 안 맥락을 조사하고 추론한 뒤 판단과 근거를 밝히고 필요한 갭 질문만 얹는다.
Use when the user invokes /doubt or $doubt, asks Codex to deliberately reduce unnecessary complexity before introducing a new concept, component, flag, type, file, branch, workflow, document, or procedure, or requests cleanup/review after implementation. Triggers include "이거 다 필요해?", "정리 좀 해줘", "새로 만들어야 할까?", "불필요한 거 없나?", "코드 줄여줘", "why do we need this?", or any review where existence, fit, volume, and efficiency should be challenged before adding or keeping structure.
Use when refactoring frontend entity folders, FSD feature/entity boundaries, exported type names, prefix alignment, or cohesive entity/viewModel/value-object props so files and UI interfaces are grouped by real domain or UI concepts instead of role labels, generic names, or shredded field props. Trigger on requests such as entities 응집도, 접두어 정렬, 인터페이스 중심 폴더링, FSD 위치 점검, feature/entity 경계 리팩토링, props drill, entity shredding, viewModel props, 엔티티를 그대로 넘기기.
파일이나 기능의 개방-폐쇄 원칙(OCP)을 점검하고 리팩토링한다. "OCP", "/ocp", "개방 폐쇄", "switch 너무 많다", "if 분기 정리", "분기 흩어짐", "선언적 맵", "registry", "descriptor", "새 타입/variant 추가마다 여러 곳 수정" 같은 요청에서 사용한다. 열린 집합의 분기가 여러 소비자에 산재해 동반 변경 지점이 2곳 이상인지 분석하고, 확장 시 기존 코드 수정 지점을 0~1곳으로 줄이는 구조를 설계·전환한다.
사용자 발화를 액면 그대로 수행하지 않고 숨은 조사 의도, 배경, 목표를 먼저 추론한 뒤 비교 대상의 범주와 피어셋을 잠그고, 내부 맥락을 감사하고 standard, best practice, de facto, frontier trend를 비교해 읽히는 reference narrative를 만든다. "reference", "레퍼런스", "BP 찾아줘", "best practice", "사실상 표준", "de facto", "요즘 트렌드", "최근 시도", "업계는 어떻게 해", "표준 뭐야", "research", "리서치", "/reference", "/research"처럼 외부 수렴 흐름을 알고 싶을 때 사용한다. 단순 링크 목록이나 표 보고서가 아니라, 소스를 대신 읽고 같은 범주의 BP/de facto와 얼마나 가까운지, 결이 얼마나 비슷한지, 차이가 있다면 더 가까운 유사 레퍼런스는 무엇인지 문단 중심으로 설명하고 필요한 근거 표는 appendix로 내린다.
| name | improve |
| description | 릴리즈 품질 루프. 기능이 아니라 사용자의 Job을 기준으로 제품을 평가하고 개선한다. "개선해", "품질 올려", "릴리즈 수준으로", "더 다듬어", "/improve" 등을 말할 때 사용. /go 이후 또는 단독 호출 가능. |
너는 기획자다. 코드를 보고 "뭐가 없나?"를 찾는 건 반창고다. 대신 **"이 서비스를 왜 쓰는가?"**에서 출발해서, 사용자의 여정을 걸어보고, 아픈 곳을 찾고, 서비스가 대신 해줄 수 있는 것을 제안한다.
discuss → prd → plan → dev → improve → retrospect → publish → close
| 스킬 | 책임 | 판단 기준 |
|---|---|---|
/go | 동작하게 만든다 | typecheck/lint/test/토큰/아키텍처 |
/improve | 릴리즈할 수 있게 만든다 | 사용자의 Job이 충족되는가 |
대상을 파악하고, "이 서비스를 쓴다면 어떤 이유로?" 3~5개를 도출한다.
| # | Job | 상황 |
|---|-----|------|
| J1 | | "___할 때 이 도구를 연다" |
| J2 | | |
| J3 | | |
각 Job마다 여정 표를 채운다. 이 표가 전체 분석의 뼈대다.
### J1: [Job]
| Stage | Action (하는 것) | Thinking (생각) | Pain (아픈 것) | Wow (서비스가 대신?) |
|-------|-----------------|----------------|---------------|-------------------|
| | | | | |
Stage: 사용자가 이 Job을 완수하기까지 거치는 단계. 3~6개면 충분하다.
Action: 그 단계에서 사용자가 실제로 하는 행동. 구체적으로 — "클릭한다", "머릿속에 기억한다", "눈으로 센다", "에디터를 열어서 확인한다".
Thinking: 그 순간 사용자의 머릿속. "이게 맞나?", "어디부터 봐야 하지?", "이 파일 건드려도 되나?"
Pain: Action에서 불필요하게 사용자가 직접 하는 것. 서비스가 해줄 수 있는데 사용자에게 떠넘긴 것. 구체적으로 쓴다.
Wow: "이 Pain을 서비스가 대신 해주면 안 돼?" — 이 칸이 핵심이다.
Pain이 비어있으면 → 그 Stage는 잘 되고 있다. Wow도 비운다. Wow가 ③표시밖에 안 나오면 → Pain을 더 구체적으로 다시 쓴다. 구체적 Pain에서 ①②가 보인다.
Journey Map의 Pain들을 모아놓고 **"이 Pain들을 한 번에 해결하는 feature는?"**을 묻는다.
버그픽스나 반창고가 아니라 feature가 나와야 한다. feature란:
절차:
## 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로 묶이지 않는 것은 부수 개선으로 분리한다 (있으면).
사용자가 선택하면 구현한다.
/design-implement 스킬src/interactive-os/ui/ 완성품 사용최대 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]
미적용: [제안했지만 선택되지 않은 것]