| name | new-feature |
| description | 신규 기능을 개발할 때 정책 문서 → 코드 → 테스트 순서로 작성한다.
ADR은 기술적 결정에만 사용하고, 기능 정책은 docs/features/ 에 작성한다.
다음 상황에서 반드시 이 스킬을 사용한다:
- "기능 추가해줘", "기획부터 해봐", "설계해봐"
- 새로운 API 엔드포인트 또는 도메인 규칙이 생길 때
- "/new-feature" 직접 호출
ARGUMENTS: 기능 이름 또는 요구사항 (없으면 대화에서 추출)
|
new-feature
신규 기능 개발 표준 절차.
원칙:
docs/features/ = 기능 정책·스펙 (기획, 규칙, UX 흐름)docs/adr/ = 기술적 결정만 (왜 이 기술을 선택했는가)
체크리스트
[ ] 1. 기능 명세 작성 — docs/features/{feature-name}.md
[ ] 2. 코드 구현 — 명세를 보고 구현
[ ] 3. 테스트 — 명세의 에러 케이스를 기반으로 작성
[ ] 4. ADR — 기술적 결정이 있었다면 작성 (기술 결정만)
[ ] 5. CI 확인 — push 후 통과 확인
Step 1. 기능 명세 (코드 전 필수)
docs/features/{feature-name}.md 파일을 먼저 작성한다.
포함 내용:
- 개요 — 무엇을 만드는가
- 역할/권한 — 누가 사용할 수 있나 (권한 매트릭스)
- API 명세 — 경로, 요청/응답 스펙
- 정책 (비즈니스 규칙) — 허용/금지 케이스, 에러 코드
- 화면 흐름 — FE 관점의 UX 흐름 (텍스트 다이어그램)
- 특이사항 — 즉시 반영 여부, 부작용, 주의사항
Step 2. 코드 구현
명세를 보고 구현한다. 구현 중에 명세가 바뀌면 명세 파일도 함께 수정한다.
- DB 변경 → Flyway 마이그레이션 (
V{n+1}__{description}.sql)
- 헥사고날 레이어 순서: domain → port → usecase → adapter
- 기존 패턴 참조:
docs/CONVENTION.md
Step 3. 테스트
명세의 정책(허용/금지 케이스)을 1:1로 매핑해서 테스트를 작성한다.
명세의 에러 케이스 하나 = 테스트 케이스 하나
커버 범위:
- 성공 케이스 (정상 권한 + 정상 입력)
- 권한 없음 (403)
- 입력 오류 (400)
- 대상 없음 (404)
- 비즈니스 규칙 위반 (409)
- 정책 제약 위반 (403 + 고유 에러 코드)
Step 4. ADR (기술적 결정이 있을 때만)
다음에 해당할 때만 ADR을 작성한다:
| ADR 써야 할 때 | ADR 쓰지 않을 때 |
|---|
| 기술 스택 선택 (왜 PostgreSQL?) | 기능 기획/정책 결정 |
| 아키텍처 패턴 선택 | 에러 코드 명명 |
| 인증 방식 변경 | 화면 흐름 설계 |
| 라이브러리 교체 결정 | 권한 매트릭스 정의 |
→ /adr 스킬 사용
Step 5. CI 확인
git push origin {branch}
gh run watch $(gh run list --repo {owner}/{repo} --branch {branch} \
--limit 1 --json databaseId --jq '.[0].databaseId') \
--repo {owner}/{repo} 2>&1 | tail -3
실패 시 즉시 원인 파악 + 수정. 실패 상태로 남기지 않는다.
참조
| 항목 | 위치 |
|---|
| 기능 명세 목록 | docs/features/ |
| 코드 컨벤션 | docs/CONVENTION.md |
| 시퀀스 다이어그램 | docs/SEQUENCE-DIAGRAMS.md |
| ADR 목록 | docs/adr/ |
| Flyway 마이그레이션 | db/migration/ (레포 루트, 전역 관리 — ADR-0014) |
