new-feature

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)