maj0rika/.gemini/skills/pipeline

Pipeline (올인원 파이프라인) 에이전트

이 스킬은 기능 요청을 받아 6개 역할을 순차적으로 수행합니다.

실행 순서

[사용자 요청]
    ↓
[Phase 1: PM] 요구사항 분석 → 작업 분해
    ↓
[Phase 2: UX/UI] 사용자 경험 설계 → 렌더링 전략 → 인터랙션 명세
    ↓
[Phase 3: BE] DB 스키마 + Server Action + API
    ↓
[Phase 4: FE] UI 컴포넌트 + 페이지 통합 (UXUI 명세 준수)
    ↓
[Phase 5: Infra] 빌드 검증 + 보안 점검
    ↓
[Phase 6: Record] 히스토리 기록 + 메모리 업데이트
    ↓
[최종 보고서]

Phase 1: PM (분석)

목표: 요청을 구체적 작업으로 분해

1. 요청 사항을 명확한 기능 명세로 정리
2. docs/implementation-plan.md와 기존 코드를 참고하여 영향 범위 분석
3. 수용 기준(Acceptance Criteria) 정의
4. UXUI/BE/FE/Infra 각각의 구체적 작업 목록 산출

산출물: 작업 분해표 (파일 단위)

⚠️ 이 단계에서 코드를 수정하지 않습니다. 분석만 합니다. 분석 결과를 사용자에게 보여주고, 승인 후 다음 Phase로 진행합니다.

---

Phase 2: UX/UI (사용자 경험 설계)

목표: 사용자 관점에서 최적의 경험 설계

1. 사용자 시나리오 작성 (주요 흐름 + 엣지 케이스)
2. 인터랙션 명세: 액션별 피드백, 렌더링 범위, 지연 허용치
3. 레이아웃 설계: 모바일(375px) 와이어프레임
4. 렌더링 전략: Server/Client Component 분리, 상태 관리 방식, 리렌더링 범위 결정
5. 접근성 체크리스트

핵심 검증 항목:

• 필터/검색 등 인터랙션 시 풀 페이지 리렌더링이 발생하지 않는가?
• 클라이언트 상태로 처리 가능한 것이 서버를 거치지 않는가?
• 로딩/에러/빈 상태가 모두 정의되었는가?
• 터치 타겟 44px 이상인가?

산출물: 인터랙션 명세 + 렌더링 전략 + 레이아웃

⚠️ 이 단계에서 코드를 수정하지 않습니다. FE에게 구체적 지시를 내립니다.

---

Phase 3: BE (백엔드 구현)

목표: 데이터 레이어와 비즈니스 로직 구현

1. DB 스키마 변경 필요 시: src/server/db/schema.ts 수정 → 마이그레이션
2. Server Action 생성/수정: src/server/actions/
3. API Route 필요 시: src/app/api/
4. 타입 정의: src/types/index.ts 업데이트

검증: npx tsc --noEmit 통과

---

Phase 4: FE (프론트엔드 구현)

목표: UI 컴포넌트와 페이지 구현 (Phase 2 UXUI 명세 반드시 준수)

1. 필요한 shadcn/ui 컴포넌트 설치 (npx shadcn@latest add ...)
2. UXUI의 렌더링 전략에 따른 Server/Client Component 분리
3. 컴포넌트 구현: src/components/
4. 페이지 통합: src/app/
5. 모바일 퍼스트 반응형 확인
6. 리렌더링 범위 검증: 인터랙션 시 필요한 컴포넌트만 업데이트되는지 확인

검증: npx tsc --noEmit 통과

---

Phase 5: Infra (검증 및 마무리)

목표: 전체 빌드 성공 + 보안 점검

1. npm run build 성공 확인
2. npm test 통과 확인
3. 환경변수 변경 시 .env.example 동기화
4. 보안 점검 (시크릿 노출, 타입 안전성)

검증: 빌드 성공 + 테스트 통과

---

Phase 6: Record (기록)

목표: 작업 내역을 프로젝트 히스토리와 에이전트 메모리에 기록하여 컨텍스트 유지

이 단계는 다음 세션에서 에이전트가 이전 작업의 맥락을 즉시 파악할 수 있도록 합니다.

6-1. 프로젝트 히스토리 기록

docs/history/ 디렉토리에 아래 형식으로 마크다운 파일을 생성합니다:

파일명 규칙: {날짜}-{순번}-{기능명-kebab-case}.md

• 예: 2026-02-25-03-category-crud-complete.md
• 순번은 같은 날짜에 이미 존재하는 파일 수 + 1

파일 구조:

---
date: YYYY-MM-DD
type: complete
pipeline: true
---

# {기능명} 완료

## 요청 요약
(사용자의 원래 요청 1줄)

## 변경 내용
### 1. {변경 영역}
- 구체적 변경 사항
- ...

## 변경된 파일
| 파일 | 작업 | 설명 |
|------|------|------|
| `경로/파일.ts` | 신규/수정/삭제 | 설명 |

## 설계 결정
### {결정 사항}
- **선택**: ...
- **이유**: ...
- **대안 (미채택)**: ...

## 검증 결과
- TypeScript: ✅/❌
- 빌드: ✅/❌
- 테스트: ✅/❌

## 다음 할 일
- ...

6-2. 에이전트 메모리 업데이트

영구 메모리 디렉토리(~/.claude/projects/.../memory/)에 작업 내역을 반영합니다:

1. MEMORY.md 업데이트: 프로젝트 구조나 아키텍처에 변화가 있으면 해당 섹션 업데이트

   • 새 패키지/라이브러리 추가 시 → "프로젝트 구조" 섹션 업데이트
   • 새 패턴/규칙 확립 시 → 관련 섹션 추가 또는 code-quality.md 업데이트
   • 배포/인프라 변경 시 → "배포 & 인프라" 섹션 업데이트

2. pipeline-log.md 업데이트: 파이프라인 실행 이력을 누적 기록

   • 파일이 없으면 생성
   • 아래 형식으로 최신 항목을 맨 위에 추가 (최신순):

## {날짜} — {기능명}
- **요청**: (1줄 요약)
- **주요 변경**: {BE/FE/DB 등} — 핵심 변경 요약
- **변경 파일**: `file1.ts`, `file2.tsx`, ...
- **설계 결정**: {핵심 결정 1줄}
- **상태**: 완료 ✅
- **히스토리**: `docs/history/{파일명}`

6-3. implementation-plan.md 동기화

docs/implementation-plan.md의 체크리스트가 있다면 완료된 항목을 [x]로 업데이트합니다.

규칙

• 기록은 사실만 작성합니다 (추측, 감상 금지)
• 메모리에는 재사용 가능한 정보만 기록합니다 (일회성 세부사항은 히스토리에만)
• 이미 존재하는 메모리와 중복되지 않도록 기존 내용을 먼저 읽고 업데이트합니다
• pipeline-log.md가 200줄을 넘으면 오래된 항목(하단)을 제거하여 관리합니다

---

최종 보고서

모든 Phase 완료 후 다음 형식으로 보고합니다:

## 파이프라인 실행 완료

### 요청 요약
(한 줄)

### PM 분석
- 기능 명세: ...
- 영향 범위: ...

### UX/UI 설계
- 사용자 시나리오: ...
- 렌더링 전략: ...
- 주요 개선점: ...

### BE 구현
| 파일 | 작업 | 설명 |
|------|------|------|

### FE 구현
| 파일 | 작업 | 설명 |
|------|------|------|

### Infra 검증
- 빌드: ✅/❌
- 테스트: ✅/❌
- 보안: ✅/❌

### 확인 방법
1. ...
2. ...

규칙

• Jira를 사용하지 않습니다. 모든 관리는 프로젝트 내에서 합니다.
• Phase 1(PM 분석) 결과를 사용자에게 보여준 뒤, 사용자 승인을 받고 Phase 2로 진행합니다.
• Phase 2(UXUI)에서 정한 렌더링 전략은 Phase 4(FE)에서 반드시 준수합니다.
• 각 Phase에서 문제가 발생하면 즉시 사용자에게 보고하고 판단을 구합니다.
• docs/implementation-plan.md의 Phase 체크리스트를 업데이트합니다.
• Phase 6(Record)는 반드시 실행합니다. 히스토리 기록과 메모리 업데이트를 건너뛰지 않습니다.
• Phase 6은 사용자 승인 없이 자동으로 수행합니다 (기록은 항상 유익하므로).