auto-commit
CommandAnalyze changes, run quality gate, and auto-commit with PR-based workflow. Trigger on "/auto-commit", "git 푸시", "git push", "자동…
Generate structured PRD documents from vague feature requests. Trigger keywords: - Commands: "/prd", "PRD 작성해줘", "기능 정의서", "요구사항 문서" - Natural language (바이브 코더 친화): - "~하는거 만들고 싶어", "~하는 기능 필요해" - "~할 수 있게 해줘", "~하는 앱 만들어줘" - "~하는 서비스 기획해줘", "이런 거 가능해?" - "아이디어가 있는데", "기능 추가하고
> /plugin marketplace add wigtn/wigtn-plugins> /plugin install wigtn-plugins@wigtn-plugins
description: |
Generate structured PRD documents from vague feature requests.
Trigger keywords:
- Commands: "/prd", "PRD 작성해줘", "기능 정의서", "요구사항 문서"
- Natural language (바이브 코더 친화):
- "~하는거 만들고 싶어", "~하는 기능 필요해"
- "~할 수 있게 해줘", "~하는 앱 만들어줘"
- "~하는 서비스 기획해줘", "이런 거 가능해?"
- "아이디어가 있는데", "기능 추가하고 싶어"
- "~하는 사이트 만들어줘", "~하는 시스템 구축해줘"모호한 기능 요청을 구조화된 PRD 문서로 변환한다.
파이프라인: `/prd` → `prd-reviewer` → (FE 페이지 있으면) `/screen-spec` → `/implement` → `/auto-commit`
**`${CLAUDE_PLUGIN_ROOT}/contracts/PRD-CONTRACT.md`를 Read한다.** PRD 골격·섹션 조건·Critical 항목은 전부 그 파일에 있다. 이 커맨드는 그것을 재진술하지 않는다.
모호하면 AskUserQuestion. 판정 결과를 PRD 헤더 `> **Type**:` 에 쓴다.
(`refactor`는 생략). 등급 경계는 계약 §4.0.
기존 PRD(`prd/`, `docs/prd/`), 기술 스택(`package.json` 등), API·컴포넌트·스키마 구조를 확인해 PRD가 실제 코드베이스와 어긋나지 않게 한다.
계약의 골격대로 PRD를 쓴다. 문장 규칙:
1. **구체적으로** — "카테고리별 필터링" (O) / "검색 가능" (X) 2. **측정 가능하게** — "p95 < 200ms" (O) / "빠른 응답" (X) 3. **검증 가능하게** — 모든 스토리에 수용 기준 4. API 명세는 Request / Response / Error를 모두 정의한다. REST 외(GraphQL / gRPC / WebSocket / OpenAPI) 템플릿이 필요하면 `${CLAUDE_PLUGIN_ROOT}/commands/references/prd-api-templates.md`를 읽는다.
AskUserQuestion으로 위치 확인: `docs/prd/` (권장) | `prd/` | 루트.
이어서 실행 계획을 `docs/todo_plan/PLAN_{feature-name}.md`로 생성한다. PRD의 §6 Implementation Phases를 Phase로, §3 FR을 Task로 매핑하고 **의존성 순서대로** 배치한다. 각 Task는 `- [ ]` 체크박스로 쓴다 — 이 파일이 `/implement`의 진행 원장(ledger)이다.
`prd-reviewer` 에이전트를 실행한다. 판정은 **findings 롤업**이다:
| 결과 | 조건 | 다음 | |---|---|---| | ❌ BLOCKED | Critical ≥1 | 수정 후 재검증 | | ✅ PASS | Critical 0 | `/implement` 진행 가능 |
Critical은 위치 / 문제 / 영향 / 개선안 4줄로 제시한다. Major·Minor는 건수만 요약한다.
§5.4 Pages에 `Has FE Components: Yes` 행이 **1개 이상이면** `/screen-spec {feature}` 권장, 아니면 곧바로 `/implement {feature}`. PRD 경로·PLAN 경로·게이트 결과·감지된 FE 페이지 수를 함께 보고한다.
Analyze changes, run quality gate, and auto-commit with PR-based workflow. Trigger on "/auto-commit", "git 푸시", "git push", "자동…
Implement features based on PRD specifications. Trigger keywords: - Commands: "/implement", "구현해줘", "만들어줘", "바로 구현" - Natural…
`/prd` Phase 3에서 선택한 API 유형의 상세 템플릿. REST / GraphQL / gRPC / WebSocket / OpenAPI 템플릿과 로그인 API 예시를 담고 있다. 필요한 유형 섹션만 참고하여 PRD §5.1…
GitHub PR을 터미널에서 리뷰합니다. PR diff를 분석하고, 코드 리뷰 점수를 매기고, 리뷰 코멘트를 남깁니다. Trigger on "/review-pr", "PR 리뷰해줘", "리뷰해줘", "PR 봐줘", "코드 리뷰",…
Generate screen specifications (IA / User Flow / Screen Spec / Wireframe / Dev Handoff) from an existing PRD. Trigger keywords: -…
Implement tasks incrementally — build, test, verify, commit. Add "auto" to run the whole plan in one approved pass.