backend-claude-code 1.0.0

package/commands/dev-plan.md

@@ -0,0 +1,501 @@
+---
+description: Create comprehensive feature implementation plan with codebase analysis and pattern extraction
+argument-hint: <feature description | path/to/prd.md>
+---
+
+> Adapted from PRPs-agentic-eng by Wirasm. Part of the PRP workflow series.
+
+# PRP Plan
+
+Create a detailed, self-contained implementation plan that captures all codebase patterns, conventions, and context needed to implement a feature in a single pass.
+
+**Core Philosophy**: A great plan contains everything needed to implement without asking further questions. Every pattern, every convention, every gotcha — captured once, referenced throughout.
+
+**Golden Rule**: If you would need to search the codebase during implementation, capture that knowledge NOW in the plan.
+
+---
+
+## Phase 0 — DETECT
+
+Determine input type from `$ARGUMENTS`:
+
+| Input Pattern | Detection | Action |
+|---|---|---|
+| Path ending in `.prd.md` | File path to PRD | Parse PRD, find next pending phase |
+| Path to `.md` with "Implementation Phases" | PRD-like document | Parse phases, find next pending |
+| Path to any other file | Reference file | Read file for context, treat as free-form |
+| Free-form text | Feature description | Proceed directly to Phase 1 |
+| Empty / blank | No input | Ask user what feature to plan |
+
+### PRD Parsing (when input is a PRD)
+
+1. Read the PRD file with `cat "$PRD_PATH"`
+2. Parse the **Implementation Phases** section
+3. Find phases by status:
+   - Look for `pending` phases
+   - Check dependency chains (a phase may depend on prior phases being `complete`)
+   - Select the **next eligible pending phase**
+4. Extract from the selected phase:
+   - Phase name and description
+   - Acceptance criteria
+   - Dependencies on prior phases
+   - Any scope notes or constraints
+5. Use the phase description as the feature to plan
+
+If no pending phases remain, report that all phases are complete.
+
+---
+
+## Phase 1 — PARSE
+
+Extract and clarify the feature requirements.
+
+### Feature Understanding
+
+From the input (PRD phase or free-form description), identify:
+
+- **What** is being built (concrete deliverable)
+- **Why** it matters (user value)
+- **Who** uses it (target user/system)
+- **Where** it fits (which part of the codebase)
+
+### User Story
+
+Format as:
+```
+As a [type of user],
+I want [capability],
+So that [benefit].
+```
+
+### Complexity Assessment
+
+| Level | Indicators | Typical Scope |
+|---|---|---|
+| **Small** | Single file, isolated change, no new dependencies | 1-3 files, <100 lines |
+| **Medium** | Multiple files, follows existing patterns, minor new concepts | 3-10 files, 100-500 lines |
+| **Large** | Cross-cutting concerns, new patterns, external integrations | 10+ files, 500+ lines |
+| **XL** | Architectural changes, new subsystems, migration needed | 20+ files, consider splitting |
+
+### Ambiguity Gate
+
+If any of these are unclear, **STOP and ask the user** before proceeding:
+
+- The core deliverable is vague
+- Success criteria are undefined
+- There are multiple valid interpretations
+- Technical approach has major unknowns
+
+Do NOT guess. Ask. A plan built on assumptions fails during implementation.
+
+---
+
+## Phase 2 — EXPLORE
+
+Gather deep codebase intelligence. Search the codebase directly for each category below.
+
+### Codebase Search (8 Categories)
+
+For each category, search using grep, find, and file reading:
+
+1. **Similar Implementations** — Find existing features that resemble the planned one. Look for analogous patterns, endpoints, components, or modules.
+
+2. **Naming Conventions** — Identify how files, functions, variables, classes, and exports are named in the relevant area of the codebase.
+
+3. **Error Handling** — Find how errors are caught, propagated, logged, and returned to users in similar code paths.
+
+4. **Logging Patterns** — Identify what gets logged, at what level, and in what format.
+
+5. **Type Definitions** — Find relevant types, interfaces, schemas, and how they're organized.
+
+6. **Test Patterns** — Find how similar features are tested. Note test file locations, naming, setup/teardown patterns, and assertion styles.
+
+7. **Configuration** — Find relevant config files, environment variables, and feature flags.
+
+8. **Dependencies** — Identify packages, imports, and internal modules used by similar features.
+
+### Codebase Analysis (5 Traces)
+
+Read relevant files to trace:
+
+1. **Entry Points** — How does a request/action enter the system and reach the area you're modifying?
+2. **Data Flow** — How does data move through the relevant code paths?
+3. **State Changes** — What state is modified and where?
+4. **Contracts** — What interfaces, APIs, or protocols must be honored?
+5. **Patterns** — What architectural patterns are used (repository, service, controller, etc.)?
+
+### Unified Discovery Table
+
+Compile findings into a single reference:
+
+| Category | File:Lines | Pattern | Key Snippet |
+|---|---|---|---|
+| Naming | `src/services/userService.ts:1-5` | camelCase services, PascalCase types | `export class UserService` |
+| Error | `src/middleware/errorHandler.ts:10-25` | Custom AppError class | `throw new AppError(...)` |
+| ... | ... | ... | ... |
+
+---
+
+## Phase 3 — RESEARCH
+
+If the feature involves external libraries, APIs, or unfamiliar technology:
+
+1. Search the web for official documentation
+2. Find usage examples and best practices
+3. Identify version-specific gotchas
+
+Format each finding as:
+
+```
+KEY_INSIGHT: [what you learned]
+APPLIES_TO: [which part of the plan this affects]
+GOTCHA: [any warnings or version-specific issues]
+```
+
+If the feature uses only well-understood internal patterns, skip this phase and note: "No external research needed — feature uses established internal patterns."
+
+---
+
+## Phase 4 — DESIGN
+
+### UX Transformation (if applicable)
+
+Document the before/after user experience:
+
+**Before:**
+```
+┌─────────────────────────────┐
+│  [Current user experience]  │
+│  Show the current flow,     │
+│  what the user sees/does    │
+└─────────────────────────────┘
+```
+
+**After:**
+```
+┌─────────────────────────────┐
+│  [New user experience]      │
+│  Show the improved flow,    │
+│  what changes for the user  │
+└─────────────────────────────┘
+```
+
+### Interaction Changes
+
+| Touchpoint | Before | After | Notes |
+|---|---|---|---|
+| ... | ... | ... | ... |
+
+If the feature is purely backend/internal with no UX change, note: "Internal change — no user-facing UX transformation."
+
+---
+
+## Phase 5 — ARCHITECT
+
+### Strategic Design
+
+Define the implementation approach:
+
+- **Approach**: High-level strategy (e.g., "Add new service layer following existing repository pattern")
+- **Alternatives Considered**: What other approaches were evaluated and why they were rejected
+- **Scope**: Concrete boundaries of what WILL be built
+- **NOT Building**: Explicit list of what is OUT OF SCOPE (prevents scope creep during implementation)
+
+---
+
+## Phase 6 — GENERATE
+
+Write the full plan document using the template below. Save to `.claude/PRPs/plans/{kebab-case-feature-name}.plan.md`.
+
+Create the directory if it doesn't exist:
+```bash
+mkdir -p .claude/PRPs/plans
+```
+
+### Plan Template
+
+````markdown
+# Plan: [Feature Name]
+
+## Summary
+[2-3 sentence overview]
+
+## User Story
+As a [user], I want [capability], so that [benefit].
+
+## Problem → Solution
+[Current state] → [Desired state]
+
+## Metadata
+- **Complexity**: [Small | Medium | Large | XL]
+- **Source PRD**: [path or "N/A"]
+- **PRD Phase**: [phase name or "N/A"]
+- **Estimated Files**: [count]
+
+---
+
+## UX Design
+
+### Before
+[ASCII diagram or "N/A — internal change"]
+
+### After
+[ASCII diagram or "N/A — internal change"]
+
+### Interaction Changes
+| Touchpoint | Before | After | Notes |
+|---|---|---|---|
+
+---
+
+## Mandatory Reading
+
+Files that MUST be read before implementing:
+
+| Priority | File | Lines | Why |
+|---|---|---|---|
+| P0 (critical) | `path/to/file` | 1-50 | Core pattern to follow |
+| P1 (important) | `path/to/file` | 10-30 | Related types |
+| P2 (reference) | `path/to/file` | all | Similar implementation |
+
+## External Documentation
+
+| Topic | Source | Key Takeaway |
+|---|---|---|
+| ... | ... | ... |
+
+---
+
+## Patterns to Mirror
+
+Code patterns discovered in the codebase. Follow these exactly.
+
+### NAMING_CONVENTION
+// SOURCE: [file:lines]
+[actual code snippet showing the naming pattern]
+
+### ERROR_HANDLING
+// SOURCE: [file:lines]
+[actual code snippet showing error handling]
+
+### LOGGING_PATTERN
+// SOURCE: [file:lines]
+[actual code snippet showing logging]
+
+### REPOSITORY_PATTERN
+// SOURCE: [file:lines]
+[actual code snippet showing data access]
+
+### SERVICE_PATTERN
+// SOURCE: [file:lines]
+[actual code snippet showing service layer]
+
+### TEST_STRUCTURE
+// SOURCE: [file:lines]
+[actual code snippet showing test setup]
+
+---
+
+## Files to Change
+
+| File | Action | Justification |
+|---|---|---|
+| `path/to/file.ts` | CREATE | New service for feature |
+| `path/to/existing.ts` | UPDATE | Add new method |
+
+## NOT Building
+
+- [Explicit item 1 that is out of scope]
+- [Explicit item 2 that is out of scope]
+
+---
+
+## Step-by-Step Tasks
+
+### Task 1: [Name]
+- **ACTION**: [What to do]
+- **IMPLEMENT**: [Specific code/logic to write]
+- **MIRROR**: [Pattern from Patterns to Mirror section to follow]
+- **IMPORTS**: [Required imports]
+- **GOTCHA**: [Known pitfall to avoid]
+- **VALIDATE**: [How to verify this task is correct]
+
+### Task 2: [Name]
+- **ACTION**: ...
+- **IMPLEMENT**: ...
+- **MIRROR**: ...
+- **IMPORTS**: ...
+- **GOTCHA**: ...
+- **VALIDATE**: ...
+
+[Continue for all tasks...]
+
+---
+
+## Testing Strategy
+
+### Unit Tests
+
+| Test | Input | Expected Output | Edge Case? |
+|---|---|---|---|
+| ... | ... | ... | ... |
+
+### Edge Cases Checklist
+- [ ] Empty input
+- [ ] Maximum size input
+- [ ] Invalid types
+- [ ] Concurrent access
+- [ ] Network failure (if applicable)
+- [ ] Permission denied
+
+---
+
+## Validation Commands
+
+### Static Analysis
+```bash
+# Run type checker
+[project-specific type check command]
+```
+EXPECT: Zero type errors
+
+### Unit Tests
+```bash
+# Run tests for affected area
+[project-specific test command]
+```
+EXPECT: All tests pass
+
+### Full Test Suite
+```bash
+# Run complete test suite
+[project-specific full test command]
+```
+EXPECT: No regressions
+
+### Database Validation (if applicable)
+```bash
+# Verify schema/migrations
+[project-specific db command]
+```
+EXPECT: Schema up to date
+
+### Browser Validation (if applicable)
+```bash
+# Start dev server and verify
+[project-specific dev server command]
+```
+EXPECT: Feature works as designed
+
+### Manual Validation
+- [ ] [Step-by-step manual verification checklist]
+
+---
+
+## Acceptance Criteria
+- [ ] All tasks completed
+- [ ] All validation commands pass
+- [ ] Tests written and passing
+- [ ] No type errors
+- [ ] No lint errors
+- [ ] Matches UX design (if applicable)
+
+## Completion Checklist
+- [ ] Code follows discovered patterns
+- [ ] Error handling matches codebase style
+- [ ] Logging follows codebase conventions
+- [ ] Tests follow test patterns
+- [ ] No hardcoded values
+- [ ] Documentation updated (if needed)
+- [ ] No unnecessary scope additions
+- [ ] Self-contained — no questions needed during implementation
+
+## Risks
+| Risk | Likelihood | Impact | Mitigation |
+|---|---|---|---|
+| ... | ... | ... | ... |
+
+## Notes
+[Any additional context, decisions, or observations]
+```
+
+---
+
+## Output
+
+### Save the Plan
+
+Write the generated plan to:
+```
+.claude/PRPs/plans/{kebab-case-feature-name}.plan.md
+```
+
+### Update PRD (if input was a PRD)
+
+If this plan was generated from a PRD phase:
+1. Update the phase status from `pending` to `in-progress`
+2. Add the plan file path as a reference in the phase
+
+### Report to User
+
+```
+## Plan Created
+
+- **File**: .claude/PRPs/plans/{kebab-case-feature-name}.plan.md
+- **Source PRD**: [path or "N/A"]
+- **Phase**: [phase name or "standalone"]
+- **Complexity**: [level]
+- **Scope**: [N files, M tasks]
+- **Key Patterns**: [top 3 discovered patterns]
+- **External Research**: [topics researched or "none needed"]
+- **Risks**: [top risk or "none identified"]
+- **Confidence Score**: [1-10] — likelihood of single-pass implementation
+
+> Next step: Run `/dev run .claude/PRPs/plans/{name}.plan.md` to execute this plan.
+```
+
+---
+
+## Verification
+
+Before finalizing, verify the plan against these checklists:
+
+### Context Completeness
+- [ ] All relevant files discovered and documented
+- [ ] Naming conventions captured with examples
+- [ ] Error handling patterns documented
+- [ ] Test patterns identified
+- [ ] Dependencies listed
+
+### Implementation Readiness
+- [ ] Every task has ACTION, IMPLEMENT, MIRROR, and VALIDATE
+- [ ] No task requires additional codebase searching
+- [ ] Import paths are specified
+- [ ] GOTCHAs documented where applicable
+
+### Pattern Faithfulness
+- [ ] Code snippets are actual codebase examples (not invented)
+- [ ] SOURCE references point to real files and line numbers
+- [ ] Patterns cover naming, errors, logging, data access, and tests
+- [ ] New code will be indistinguishable from existing code
+
+### Validation Coverage
+- [ ] Static analysis commands specified
+- [ ] Test commands specified
+- [ ] Build verification included
+
+### UX Clarity
+- [ ] Before/after states documented (or marked N/A)
+- [ ] Interaction changes listed
+- [ ] Edge cases for UX identified
+
+### No Prior Knowledge Test
+A developer unfamiliar with this codebase should be able to implement the feature using ONLY this plan, without searching the codebase or asking questions. If not, add the missing context.
+
+---
+
+## Next Steps
+
+- Run `/dev run <plan-path>` to execute this plan
+- Run `/plan` for quick conversational planning without artifacts
+````

package/commands/dev-review.md

@@ -0,0 +1,144 @@
+---
+description: 코드 리뷰 — 로컬 변경사항(Java 특화) 또는 GitHub PR 리뷰 (PR 번호/URL 전달 시 PR 모드)
+argument-hint: [pr-number | pr-url | file-path | blank for all changes]
+---
+
+# Dev Review
+
+**Input**: $ARGUMENTS
+
+---
+
+## Mode Selection
+
+`$ARGUMENTS`에 PR 번호, PR URL, 또는 `--pr`이 포함된 경우:
+→ **PR Review Mode**로 이동
+
+그 외:
+→ **Local Review Mode** 사용
+
+---
+
+## Local Review Mode
+
+### Phase 1 — GATHER
+
+```bash
+git diff --name-only HEAD
+```
+
+특정 파일 지정 시 (`$ARGUMENTS`):
+```bash
+git diff HEAD -- "$ARGUMENTS"
+```
+
+변경된 파일 없으면 종료: "리뷰할 내용이 없습니다."
+
+### Phase 2 — BUILD CHECK
+
+```bash
+./mvnw compile -q --no-transfer-progress 2>&1 | tail -5 || \
+./gradlew compileJava -q 2>&1 | tail -5
+```
+
+컴파일 실패 시 → `/dev build` 실행 먼저.
+
+### Phase 3 — REVIEW
+
+Java 파일이 포함된 경우 `java-reviewer` 에이전트에 위임한다.
+그 외 파일은 직접 리뷰한다.
+
+**Security Issues (CRITICAL)**
+- 하드코딩된 자격 증명, API 키, 토큰
+- SQL 인젝션 취약점 (문자열 연결)
+- 입력 검증 누락 (`@Valid` 없는 `@RequestBody`)
+- 경로 순회 위험
+
+**Spring Boot Architecture (HIGH)**
+- 필드 주입 (`@Autowired`) — 생성자 주입으로 전환
+- 컨트롤러에 비즈니스 로직
+- `@Transactional` 잘못된 레이어
+- 엔티티 직접 반환 (DTO 없음)
+
+**JPA Issues (HIGH)**
+- `FetchType.EAGER` on collections
+- 페이지네이션 없는 목록 엔드포인트
+- `Optional.get()` without `isPresent()`
+
+**Code Quality (MEDIUM)**
+- 50줄 이상 함수
+- 800줄 이상 파일
+- 중첩 깊이 > 4
+- 오류 처리 누락, 빈 catch 블록
+
+### Phase 4 — REPORT
+
+```
+Dev Review — <날짜>
+Files Changed: N
+
+CRITICAL: N issues
+  - [파일:라인] 문제 → 수정 방법
+
+HIGH: N issues
+  - [파일:라인] 문제 → 수정 방법
+
+MEDIUM: N issues
+  - [파일:라인] 문제
+
+Decision: APPROVE | REQUEST_CHANGES | BLOCK
+```
+
+CRITICAL/HIGH → 커밋 차단.
+
+---
+
+## PR Review Mode
+
+GitHub PR 종합 리뷰.
+
+### Phase 1 — FETCH
+
+```bash
+gh pr view <NUMBER> --json number,title,body,author,baseRefName,headRefName,changedFiles,additions,deletions
+gh pr diff <NUMBER>
+```
+
+### Phase 2 — REVIEW
+
+변경된 파일 **전체** 읽기 (diff만 아님).
+
+| 카테고리 | 확인 내용 |
+|---------|---------|
+| **Correctness** | 로직 오류, null 처리, 엣지 케이스 |
+| **Security** | 인젝션, 인가 누락, 시크릿 노출 |
+| **Spring Boot** | 계층 아키텍처, @Transactional, DTO |
+| **JPA** | N+1, 페이지네이션, fetch 전략 |
+| **Tests** | 커버리지, 테스트 슬라이스, 명명 |
+| **Performance** | N+1 쿼리, 무제한 조회, 인덱스 |
+
+### Phase 3 — VALIDATE
+
+```bash
+./mvnw verify -q --no-transfer-progress 2>&1 | tail -10 || \
+./gradlew check -q 2>&1 | tail -10
+```
+
+### Phase 4 — DECIDE
+
+| 조건 | 결정 |
+|------|------|
+| CRITICAL/HIGH 없음, 검증 통과 | **APPROVE** |
+| MEDIUM만 있음 | **APPROVE** with comments |
+| HIGH 있음 | **REQUEST CHANGES** |
+| CRITICAL 있음 | **BLOCK** |
+
+### Phase 5 — PUBLISH
+
+```bash
+# APPROVE
+gh pr review <NUMBER> --approve --body "<요약>"
+
+# REQUEST CHANGES
+gh pr review <NUMBER> --request-changes --body "<필수 수정 요약>"
+```