build
자연어 설명으로 프로젝트를 구축합니다. 설정, 계획, 구현을 자동으로 조율합니다.
사용자에게 보여지는 모든 출력은 반드시 평이한 영어를 사용해야 합니다. 전문 용어는 사용하지 마세요: "TDD", "sprint", "PR", "squash merge", "CI/CD", "ORM", "middleware" 등. 기술 용어가 불가피한 경우에는 괄호로 설명하세요.
인자
$ARGUMENTS — 무엇을 구축할지에 대한 평이한 영어 설명입니다 (예: "사용자 계정과 마감일이 있는 작업 관리 앱").
0단계: 설정 확인
CLAUDE.md에서 현재 프로파일을 읽으세요. lean이 아닌 경우 프로파일을 기록해 두되 계속 진행하세요. /build는 프로젝트 프로파일과 관계없이 내부적으로 항상 lean 스타일 실행을 사용합니다.
1단계: 분해
표시: "무엇을 구축해야 할지 계획하는 중..."
/ideate 로직을 사용하여 설명을 내부적으로 순서가 지정된 스토리로 분해하세요:
- 설명된 핵심 엔티티와 기능 식별
- 의존성 순서에 따른 구현 단계로 분할
- 각각을 기능, 인프라, 또는 테스트로 분류
- 각 단계의 크기 측정 (최대 5개 파일을 건드리는 단계를 목표로)
이 중 어떤 것도 사용자에게 표시하지 마세요. 스토리 유형, SPIDR, 우선순위 레이블, 방법론 용어 없음. 분해는 내부적으로 유지하세요.
단순한 내부 계획을 작성하세요 (사용자에게는 표시되지 않음):
steps:
- summary: "데이터베이스 테이블 설정"
type: infrastructure
files: [...]
- summary: "API 엔드포인트 구축"
type: feature
files: [...]
- summary: "사용자 인증 추가"
type: feature
files: [...]
- summary: "테스트 작성"
type: testing
files: [...]
발견 기록 (사후적)
향후 단계 검토를 위해 발견 컨텍스트를 조용히 기록하세요 — 사용자는 이를 보지 못합니다:
- 설명에서 아키텍처 유형 추론 (
.claude/skills/discover/references/scale-guide.md의 10가지 유형과 대조하여 분류) - 규모를 Quick Build로 설정
- 최소한의
docs/reference/DECISION_LOG.md자동 생성 (.claude/skills/discover/assets/decision-log.md에서 템플릿 복사), 모든 기술 결정을 ASSUMED 신뢰도로 기록 - 단계 전환 스토리 (E0N-REVIEW: 3-스토리 빠른 변형 — E0N-001, E0N-004, E0N-006)를 마지막 내부 단계로 포함
- 분류를
vision/classification.md에 저장
이렇게 하면 /build 사용자가 초기 마찰 없이 검토 주기를 사용할 수 있습니다.
2단계: 실행
의존성 순서에 따라 각 단계를 실행하세요:
-
평이한 영어로 진행 상황 표시:
- "데이터베이스를 설정하는 중..." / "API를 구축하는 중..." / "사용자 로그인을 추가하는 중..." / "모든 것이 잘 작동하는지 확인하는 테스트를 작성하는 중..."
- 사용자가 이해할 수 있는 언어를 사용하세요. 다음과 같이 절대 표시하지 마세요: "스토리 E01-003 실행 (유형: feature, 크기: STANDARD)"
-
스토리 사이클 Lean 동작으로 실행:
- 계획 (간결하게 — 신뢰도 점수 없음)
- 중요하지 않은 부분은 TDD로 구축 (테스트 실행, TDD 방법론 설명하지 않음)
- 테스트 통과 확인
- 관례적 형식으로 커밋 (커밋 규칙 설명하지 않음)
-
모든 기술 결정은 조용히 내리세요:
- 프레임워크/라이브러리 선택: 가장 적합한 것을 선택하고 최종 요약에 문서화
- 아키텍처: 탐지된 스택에 대한 표준 패턴 따름
- 파일 구조: 기존 프로젝트 규칙 또는 탐지된 스택 기본값 따름
- 진정한 제품 모호성에 대해서만 멈춤: "디자인이 두 가지 방향으로 갈 수 있습니다: [A] 또는 [B]. 어느 것을 선호하시나요?"
- 다음과 같은 이유로 절대 멈추지 않음: 데이터베이스 선택, API 스타일, 파일 이름 지정, 테스트 프레임워크, 폴더 구조
-
오류를 우아하게 처리:
- 2회 시도 후에도 단계가 실패하면 다음 메모와 함께 건너뛰기: "[X]를 자동으로 작동하게 할 수 없었습니다. 수동으로 해야 할 작업은 다음과 같습니다: [설명]"
- 나머지 단계를 계속 진행 — 전체 빌드를 차단하지 마세요
3단계: 완료
3A. 실행 및 확인 (해당되는 경우)
CLAUDE.md Commands에서 dev: 명령어가 있는지 확인하세요. 구성된 경우:
- 표시: "프로젝트를 시작하는 중..."
run_in_background: true를 사용하여 백그라운드에서 Bash로 dev 명령어 실행- 몇 초 기다리세요. 출력을 읽어보세요 — URL, 포트, 파일 경로 또는 상태 메시지를 찾으세요.
- 명령어가 생성하는 것을 표시하세요. URL이 출력되면 강조하세요. CLI인 경우 도움말 출력을 표시하세요. 서버를 시작하는 경우 주소를 표시하세요.
- 물어보세요: "한번 살펴보시고 어떻게 생각하는지 알려주세요!"
- 피드백을 기다리세요. 긍정적 → 완료 보고서로 진행. 문제 있음 → 수정 후 재실행.
dev 명령어가 구성되지 않은 경우 (라이브러리, 패키지, 파이프라인 등) → 이 단계를 건너뛰세요. 테스트가 이미 빌드를 확인했습니다.
localhost나 특정 URL을 가정하지 마세요. 실제 명령어 출력을 읽으세요. 프로젝트마다 다른 결과가 생성됩니다.
3B. 완료 보고서
완료 보고서를 평이한 영어로 표시하세요:
## 모두 완료!
### 구축된 것
- [기능 1]: [기능이 무엇을 하는지에 대한 평이한 영어 설명]
- [기능 2]: [설명]
- ...
### 생성/수정된 파일
- `src/models/user.ts` — 사용자 데이터 모델
- `src/api/auth.ts` — 로그인 및 등록 엔드포인트
- ...
### 테스트
- [N]개의 테스트 작성, 모두 통과
### 내린 기술 결정
- **데이터베이스:** PostgreSQL (안정적이고 무료이며 [프레임워크]와 잘 작동함)
- **인증:** [선택한 방식] — [한 줄 이유]
- ...
### 사용해 보기
[dev 명령어가 실행된 경우: "프로젝트가 실행 중입니다 — 위 참조"]
[dev 명령어는 있지만 실행되지 않은 경우: "`[dev 명령어]`를 실행하여 시작하세요"]
[dev 명령어가 없는 경우: 이 섹션 생략]
### 다음 단계
- [제안 1, 예: "/build 'Stripe 결제 통합'으로 결제 시스템 추가"]
- [제안 2]
규칙
- 평이한 영어만 사용 — 사용자에게 보여지는 모든 메시지는 코딩을 한 번도 해보지 않은 사람도 이해할 수 있어야 함
- 기술 결정은 조용히 — 좋은 기본값을 선택하고 완료 보고서에 문서화하며 절대 묻지 않음
- 제품 질문에 대해서만 멈춤 — "사용자가 자신의 계정을 삭제할 수 있어야 하나요?"는 유효함. "REST인가요 GraphQL인가요?"는 유효하지 않음
- 안전 훅은 여전히 실행됨 — 비밀 탐지, Git 보호, 테스트 실행은 눈에 보이지 않게 발생
- Lean 실행 — 품질 에이전트 파견, 스프린트 명세, 회고, 작업에 필요한 것 이상의 문서 생성 없음
- 우아하게 건너뛰기 — 실패한 단계는 기록되지만 치명적이지 않음. 빌드는 계속됨
- 단일 세션 — /build의 첫 번째 버전은 단일 세션에서 완료됨. 다중 세션 빌드는 향후 작업임