source-command-feature

name	source-command-feature
description	기능 아이디어를 PRD·기술 설계·태스크로 구체화. 코딩 직전까지의 준비를 마친다.

source-command-feature

Use this skill when the user asks to run the migrated source command feature.

Command Template

사용자가 대략적인 기능 아이디어를 던지면, 코드베이스를 탐색해 개발 가능한 수준의 설계 문서를 산출한다. 코드는 한 줄도 건드리지 않는다.

사용

/feature <기능 아이디어> — 자연어로 대략적인 기능 설명. 한 줄이든 여러 줄이든 OK.

절차

1. 사전 스캔 + 질문 라운드

문서 작성 전까지 모호함이 모두 제거될 때까지 질문 라운드를 반복한다.

먼저 사전 코드 스캔: 라운드 시작 전에 영향 영역(관련 타입·파일·기존 패턴)을 빠르게 훑어 코드를 읽으면 답이 나오는 질문은 미리 솎아낸다. Explore 에이전트나 grep/read로 가볍게. 사용자에게 묻지 않아도 코드만 보면 결정 가능한 사항은 사전에 정리.

라운드 진행:

1. 현시점에 남은 모호함을 모두 식별해 한 라운드로 묶어 질문 (개수 제한 없음 — 명확해질 때까지 충분히)
2. 사용자 답변 후 새 의문이 생기면 다음 라운드
3. 종료 조건을 모두 만족할 때까지 반복

종료 조건 (5개 모두 충족해야 2단계로 진행):

• 스코프: 포함/제외가 명확
• UX: 핵심 플로우의 입력·출력·트리거가 명확
• 데이터: 새/변경되는 타입·스토리지·메시지가 명확
• 통합·회귀: 기존 어느 코드/플로우에 영향을 주는지 명확
• 외부 의존성: 권한·env·OAuth·외부 API가 명확

Escape: 사용자가 "충분해"·"진행해" 등 명시적으로 말하면 즉시 다음 단계로 진행.

질문 형식:

• 해석이 갈리면 선택지 제시 (A/B/C, "직접 입력" 옵션 포함)
• 카테고리별로 그룹핑하고 항목 번호 부여 (1, 1-1 형식) — 단답 답변 가능하게
• 코드를 읽으면 답이 나오는 질문 금지 (사전 스캔에서 처리)
• 사용자가 이미 답한 것 재질문 금지

2. 코드베이스 탐색

기능이 영향을 미칠 영역을 파악한다:

• 관련 파일·함수·타입 식별 (Explore 에이전트 활용 가능)
• 기존 패턴·컨벤션 파악 (동일 레이어의 기존 구현을 참고)
• 제약 사항 확인 (MV3 제약, manifest 권한, chrome API 한계 등)

3. 문서 산출

docs/features/<slug>/ 디렉터리에 3개 문서를 생성한다. <slug>는 기능을 대표하는 kebab-case 영문 이름.

3-1. prd.md — 제품 요구사항

# <기능 이름>

## 배경
왜 이 기능이 필요한가. 어떤 문제를 해결하는가.

## 목표
이 기능이 달성해야 할 것. 구체적이고 검증 가능한 문장으로.

## 비목표 (Non-goals)
이번 스코프에서 명시적으로 제외하는 것.

## 사용자 시나리오
주요 유저 플로우를 단계별로 기술. 엣지 케이스 포함.

## 성공 기준
기능이 완성됐다고 판단할 수 있는 조건.

3-2. design.md — 기술 설계

# <기능 이름> — 기술 설계

## 개요
아키텍처 수준의 접근 방식 한 문단.

## 변경 범위
영향받는 파일/모듈 목록. 각각에 대해:
- 현재 역할
- 변경 내용 요약
- 새로 추가되는 파일이 있으면 위치와 역할

## 데이터 흐름
상태/메시지/스토리지가 어떻게 흘러가는지. 필요 시 다이어그램(텍스트).

## 인터페이스 설계
새로 추가되거나 변경되는 타입/인터페이스를 TypeScript 시그니처로 기술.

## 기존 패턴 준수
AGENTS.md 컨벤션 중 이 기능에 특히 관련된 것을 명시.
(예: 세션 영속화 패턴, 메시지 비동기 응답 패턴, i18n 동시 갱신 등)

## 대안 검토
고려했지만 채택하지 않은 접근과 그 이유. 최소 1개.

## 위험 요소
구현 중 주의할 점, 알려진 제약, 잠재적 회귀.

3-3. tasks.md — 구현 태스크

# <기능 이름> — 구현 태스크

## 선행 조건
구현 전에 확인/준비해야 할 것 (권한, 의존성, 환경 등).

## 태스크

### Task 1: <제목>
- **변경 대상**: `src/path/file.ts`
- **작업 내용**: 구체적으로 무엇을 추가/수정하는지
- **검증**: 이 단계가 끝났을 때 확인할 수 있는 방법
  - [ ] 검증 항목 1
  - [ ] 검증 항목 2

### Task 2: <제목>
...

## 테스트 계획
- 단위 테스트: 어떤 순수 함수에 어떤 케이스를 추가할지
- e2e 시나리오: 자동화 가능 항목 — "~하면 ~가 된다"로 스크립트 판정 가능한 문장으로. `/e2e-write`의 입력이 된다.
- 수동 테스트: 자동화 불가 항목만 (시각 정합, captureVisibleTab 의존 등) Chrome에서 확인할 체크리스트

## 구현 순서 권장
태스크 간 의존 관계와 권장 순서. 병렬 가능한 태스크는 명시.

## 가이드 영향
사용자 노출 UX·기능이면 갱신이 필요한 `guide/` 페이지를 ko·en으로 명시한다(없으면 "없음"). 판단·작성 기준은 `guide/AUTHORING.md`. 구현 후 `/guide`로 처리한다.
- 예: `element/styling.md`(ko·en) — AI 스타일링 설명 추가

사용자 노출 기능이 아니면 "## 가이드 영향: 없음" 한 줄로 둔다.

4. 커밋

생성한 문서를 dev 브랜치에 커밋한다. 메시지: docs(feature): <slug> add PRD, design, and tasks.

이 문서는 다른 환경에서 pull 받아 이어 작업하기 위한 용도다. 구현 완료 후 사용자가 직접 삭제한다.

5. 보고

문서 경로를 알려주고 핵심 설계 결정 2-3개를 요약한다. 끝.

문서 작성 원칙

• 개발 가능한 구체성: "적절히 처리한다" 같은 모호한 표현 금지. 파일명, 함수명, 타입 시그니처 수준으로.
• 코드베이스 기반: 추측이 아니라 실제 코드를 읽고 쓴다. 존재하지 않는 함수/패턴을 가정하지 않는다.
• AGENTS.md 정합성: 아키텍처 원칙·코드 컨벤션과 충돌하는 설계를 하지 않는다.
• 간결: 문서가 길어지는 것 자체는 OK지만, 모든 문장이 구현에 필요한 정보여야 한다.
• 최소 설계: 기능 요구를 충족하는 가장 단순한 구조를 택한다. 요청하지 않은 유연성·설정 가능성·미래 대비 추상화를 설계에 포함하지 않는다.
• 외과적 범위: 기존 코드 중 변경이 필요한 부분만 변경 범위에 넣는다. "ついで에 리팩터" 금지. 기존 스타일·패턴이 마음에 안 들어도 그대로 따른다.
• 검증 우선: 모든 태스크에 "이걸 어떻게 확인하는가"를 먼저 정의한다. 검증 방법이 없는 태스크는 쪼개거나 재정의한다.

금지 사항

• 코드 수정 금지 — src/, manifest, package.json 등 프로덕션 코드 일체 변경하지 않는다.
• 빌드/테스트 실행 금지 — 읽기 전용.
• shadcn 컴포넌트 설치 금지 — 설계 문서에 "shadcn X 컴포넌트 사용" 정도로 명시만.
• 후속 액션 자동 실행 금지 — "이제 Task 1부터 시작할까요?" 같은 제안 금지. 문서 산출 후 종료.