continue-impl

Imported from hwajj/frontend-dev-notes (ai-project-settings/.cursor/skills/continue-impl/SKILL.md). Install upstream with npx skills add hwajj/frontend-dev-notes --skill continue-impl. Copyright stays with the author.

구현 자동 속행

이 스킬에서 progress-tracking.mdc는 .cursor/rules/progress-tracking.mdc를 의미한다.

1. 항목 결정

사용자의 초기 입력을 분석하여 즉시 진행 또는 탐색 경로를 결정한다.

• 사용자가 페이지명을 입력에 포함하거나 기획 문서를 직접 전달 → 1-A
• 그 외 → 1-B

1-A. 즉시 진행 경로

1. Read로 docs/PROGRESS.md를 읽는다
2. 사용자가 명시한 페이지명/기획 문서를 PROGRESS.md에서 찾아 상태를 확인한다
   • PROGRESS.md에 해당 항목이 없으면 → 신규 항목으로 간주(- 상태), §2b로 진행
3. 정합성 검증을 지연한다 — §2 완료 후 지연된 정합성 검증에서 수행
4. §2(분기)로 진행한다

1-B. 탐색 경로

1. Read로 docs/PROGRESS.md를 읽는다
2. "기획 목차와 PROGRESS.md를 동기화하고 있습니다…" 안내 메시지를 출력한다
3. Task(generalPurpose)로 정합성 검증 서브에이전트를 실행한다. 서브에이전트 프롬프트에 아래 지시를 포함한다:
   1. docs/logistics/@index.md와 docs/nursing-hospital/@index.md를 읽는다
   2. docs/PROGRESS.md를 읽는다
   3. .cursor/rules/progress-tracking.mdc "@index.md 동기화" 규칙에 따라 PROGRESS.md를 동기화한다
   4. 변경 사항이 있으면 PROGRESS.md를 갱신한다
   5. 최종 응답으로 변경 유무(변경 있음 / 변경 없음)와 변경 요약을 반환한다
4. Task 완료 후 변경 유무를 확인한다. 변경 있으면 PROGRESS.md를 다시 읽고 변경 요약을 1줄 보고한다
5. 미완료 항목(done/skip이 아닌 항목)이 하나도 없으면 "모든 항목이 구현 완료되었습니다" 출력 후 종료
6. 아래 안내 메시지를 그대로 출력하고 사용자 응답을 기다린다 (추가 도구 호출 없이 턴 종료):

> [PROGRESS.md](docs/PROGRESS.md)를 참고해 구현할 항목을 지정해주세요.
>
> 해당하는 페이지명을 직접 입력하거나, 기획 문서를 직접 전달할 수도 있습니다.

7. 사용자가 페이지명 또는 기획 문서 경로를 응답하면, PROGRESS.md에서 해당 행을 찾아 상태를 확인하고 §2(분기)로 진행한다

2. 분기

선택한 항목의 각 컬럼 상태에 따라 분기한다:

• 서버/프론트/검증 모두 done → "이미 구현 완료된 항목입니다" 안내 후 즉시 종료
• 검증이 needs-fix → 2a
• 서버 또는 프론트가 amended → 2c
• 서버 또는 프론트가 partially-done → 2d
• 그 외 (- 또는 reviewed) → 2b

Git 준비 (모든 분기 공통)

각 분기에서 impl-server 또는 impl-frontend를 호출하기 전에 아래 작업을 수행한다.

git-workflow.mdc "브랜치 준비 절차" 참조

• branch_type: needs-fix/amended → fix, 미구현/partially-done → feat

1. git branch --show-current로 현재 브랜치를 확인한다
2. main/master/develop에 있거나 작업과 불일치하는 브랜치 → git checkout -b {branch}로 생성
3. 이미 적절한 브랜치 → 추가 작업 없음

아키텍처 결정 협의

2a, 2b, 2c, 2d에서 구현 직전에 참조하는 공통 절차이다.

해당 분기의 구현 대상 기능을 아래 기준에 대입하여 평가한다. 구현 방식이 2개 이상이거나, 아키텍처에 영향을 미치는 경우 협의가 필요하다. 분기별 평가 범위:

• 2a (needs-fix): 미구현/구현 불일치 테이블 행에 해당하는 기능
• 2b (신규 구현): 기획 문서 전체 기능
• 2c (amended): 기획 변경 사항에 해당하는 기능
• 2d (partially-done): 구현 보류 항목에 해당하는 기능

(예: 외부 서비스·인프라 선택, 서버/프론트 어디서든 구현 가능한 기능(책임 소재 불명확), 프로젝트 전반 설계 패턴 변경)

단, 아래 중 하나에 해당하면 제외한다:

• 표준 라이브러리 추가
• 기획에 명시된 처리 위치
• UI 표시 전용 변환
• 선행 설계 결정의 귀결: AGENTS.md 기술 스택과 package.json에 명시된 기술의 범위 내의 사용만 해당. PROGRESS.md 미구현 사유·비고 등 문서에 기술명이 언급된 것만으로는 확정된 결정이 아니다
• 업계 관행

평가 결과를 사용자에게 1줄로 보고한다: "N개 기능 평가, 협의 필요 M건"

• M = 0 → 요약만 출력하고 구현 진행
• M >= 1 → 아키텍처 결정 협의 절차를 실행한다

2a. 수정 흐름 (needs-fix 항목)

1. PROGRESS.md 하단 ## 미구현/불일치 항목에서 해당 페이지의 ### 헤딩을 찾아 하위 이슈 테이블을 읽는다
2. 기획 문서 경로를 따라 기획 문서를 읽는다
3. 아키텍처 결정 협의를 실행한다
4. 미구현/구현 불일치 테이블 행의 "대상" 컬럼을 확인하여 수정 범위를 결정한다:
   • 대상이 서버 또는 서버+프론트인 행이 1건 이상 → impl-server를 진입점 impl-only, commit-rule: 각 테이블 행을 개별 커밋으로 처리 로 실행한다.
   • 대상이 프론트 또는 서버+프론트인 행이 1건 이상 → impl-frontend를 진입점 impl-only, commit-rule: 각 테이블 행을 개별 커밋으로 처리 로 실행한다.
   • 서버 대상 행이 없으면 서버 수정을 건너뛴다
   • 프론트 대상 행이 없으면 프론트 수정을 건너뛴다
   • 서버와 프론트 모두 대상인 경우 서버 → 프론트 순서로 수정한다
   • #### 기획 외 제거 섹션이 있으면 해당 구현 위치의 코드를 제거하고, 관련 테스트도 함께 정리한다
   • 구현 중 외부 의존성 블로커를 발견하면: 구현 가능한 항목만 완료하고 커밋. 미수정 블로커 항목을 #### 구현 보류 섹션에 impl 형식으로 기록한다 (기획 섹션 | 요구사항 요약 | 대상 | 미구현 사유). #### 구현 보류 섹션이 없으면 생성한다. 미구현 사유에는 실제 블로커 원인을 기입한다
5. 수정 완료 후 테스트·정적 분석 병렬 검증을 실행한다
6. PROGRESS.md 갱신 — progress-tracking.mdc "상태 전이 테이블", "하단 섹션 관리" 규칙에 따라 검증 컬럼을 done으로 갱신한다. 구현 보류에 잔여 항목이 있으면 해당 대상 컬럼을 partially-done으로 유지/변경한다. 잔여 항목이 없으면 서버/프론트 컬럼은 변경하지 않는다
7. 검증 결과 섹션(미구현, 구현 불일치, 기획 외 제거)을 삭제한다. 구현 보류는 보존한다

수정 흐름 완료 후 3. 종료 안내로 진행한다.

2b. 신규 구현 흐름

1. 선택된 항목의 기획 문서에 대해 review-planning 스킬을 읽고 그 워크플로우를 실행한다
   • 부족/충돌 사항이 있으면 사용자 확인 후 기획 문서 수정
   • 완료 후 PROGRESS.md에서 해당 항목의 서버/프론트 상태가 -이면 reviewed로 갱신
2. 아키텍처 결정 협의를 실행한다
3. 서버 구현: 서버 컬럼이 done 또는 partially-done이 아니면 실행
   • impl-server를 from-review 진입점으로 실행한다
4. 프론트 구현: 프론트 컬럼이 done 또는 partially-done이 아니면 실행
   • impl-frontend를 from-review 진입점으로 실행한다

신규 구현 흐름 완료 후 3. 종료 안내로 진행한다.

2c. 기획 변경 반영 흐름 (amended 항목)

1. 기획 문서를 읽는다
2. 현재 구현 코드를 탐색한다 (서버 + 프론트)
3. PROGRESS.md 하단 ## 미구현/불일치 항목 섹션에서 해당 항목의 내용을 확인한다:
   • 검증 결과 섹션(#### 미구현, #### 구현 불일치, #### 기획 외 제거)이 있으면 메모리에 백업한 뒤 PROGRESS.md에서 원본을 삭제한다
   • 이후 #### 구현 보류 섹션에 미구현 내역이 있는지 확인한다
   • 미구현 내역이 없으면 → step 6으로 직행
   • 미구현 내역이 있으면 → 아래 교차 대조를 수행한다
4. 기획 변경 사항(PROGRESS.md 비고의 "기획 변경: ..." 참조)과 #### 구현 보류 항목을 교차 대조하여 분류한다:
   • 무관: 기획 변경이 미구현 항목과 관련 없음 → 미구현 항목 유지
   • 재정의: 기획 변경이 미구현 항목의 요구사항을 변경 → 미구현 항목 내용 갱신
   • 해소: 기획 변경으로 미구현 항목이 불필요해짐 → 미구현 항목 삭제
5. 분류 결과를 사용자에게 보고한다
   • 전부 "무관"이면 → 자동 진행 (기획 변경이 미구현 항목에 영향 없음)
   • "재정의" 또는 "해소" 항목이 있으면 → AskQuestion으로 확인한다
6. 아키텍처 결정 협의를 실행한다
7. 기획 변경 사항을 기반으로 영향 범위를 분석하고 변경분을 구현한다:
   • 서버 컬럼이 amended → impl-server를 impl-only 진입점으로 실행한다
   • 프론트 컬럼이 amended → impl-frontend를 impl-only 진입점으로 실행한다
   • 양쪽 모두 amended → 서버 먼저, 프론트 이후
8. 수정 완료 후 테스트·정적 분석 병렬 검증을 실행한다
9. step 3에서 백업한 검증 결과가 있다면, Task(서브에이전트)를 호출하여 fast-verify-impl 스킬을 실행한다. 서브에이전트에 백업한 검증 결과 테이블 전체와 기획 문서 경로를 전달한다. 백업한 검증 결과가 없으면 이 단계를 건너뛴다
10. PROGRESS.md 갱신 — progress-tracking.mdc "상태 전이 테이블", "하단 섹션 관리" 규칙에 따라:
    • 서버/프론트 컬럼: amended였던 컬럼별로 구현 보류 잔여 건수를 개별 집계한다
      • 서버가 amended였으면: 서버 대상 잔여 0건 → done(T8), 1건+ → partially-done(T9)
      • 프론트가 amended였으면: 프론트 대상 잔여 0건 → done(T8), 1건+ → partially-done(T9)
      • amended가 아니었던 컬럼은 변경하지 않는다
    • 검증 컬럼: step 9의 fast-track 결과에 따라 갱신한다
      • fast-track을 실행하지 않은 경우 → 검증 컬럼 변경 없음
      • 유효한 항목이 남아있는 경우 → 검증 컬럼을 needs-fix로 유지하고, 유효 항목만 PROGRESS.md 하단에 작성한다
      • 모든 기존 이슈가 해결된 경우 → 검증 컬럼을 -로 갱신한다(V6). 절대 done으로 갱신하지 않는다
    • 비고의 "기획 변경: ..." 표시를 제거한다

기획 변경 반영 완료 후 3. 종료 안내로 진행한다.

2d. 잔여 구현 흐름 (partially-done 항목)

1. 해당 항목의 #### 구현 보류 섹션에서 미구현 내역을 읽는다
2. 기획 문서를 읽는다
3. 미구현 사유를 기반으로 그룹을 제안하고 사용자에게 확정받는다:
   • 미구현 항목들을 사유의 유사성(공통 의존성, 기술 영역 등)으로 묶어 그룹을 제안한다
   • 사용자가 그룹을 수정하거나 확정한다
   • 사용자가 이번에 진행할 그룹을 선택한다 (나머지 그룹은 partially-done 유지)
   • 항목이 1건이거나 모두 같은 사유인 경우 그룹핑 단계를 생략한다
4. 아키텍처 결정 협의를 실행한다
5. 선택된 항목의 "대상" 컬럼에 따라:
   • 서버 → impl-server를 impl-only 진입점으로 실행한다
   • 프론트 → impl-frontend를 impl-only 진입점으로 실행한다
   • 구현 중 새로운 외부 의존성 블로커를 발견하면: 구현 가능한 부분까지만 완료하고 커밋 → 새 블로커를 PROGRESS.md 하단 #### 구현 보류 섹션에 추가 → 사용자에게 보고
     • 프론트 컬럼이 - 또는 reviewed이면 추가 안내: "프론트를 먼저 구현하시려면 /impl-frontend {페이지명}으로 진행할 수 있습니다 (서버 미구현 부분은 partially-done 처리)"
6. 완료 후 PROGRESS.md 갱신 — progress-tracking.mdc "상태 전이 테이블", "하단 섹션 관리" 규칙에 따라 구현된 행을 하단 #### 구현 보류 섹션에서 삭제한다
   • 구현 보류의 대상은 서버 또는 프론트만 존재한다
   • 서버 대상 잔여 행 0건 → 서버 컬럼을 done으로 승격(T10), 1건+ → partially-done 유지
   • 프론트 대상도 동일하게 처리한다

잔여 구현 흐름 완료 후 3. 종료 안내로 진행한다.

지연된 정합성 검증

§1에서 1-A. 즉시 진행 경로를 사용한 경우에만 실행한다. 1-B. 탐색 경로에서는 이미 수행했으므로 건너뛴다.

§2의 모든 분기가 완료된 후, §3 직전에 실행한다:

1. "기획 목차와 PROGRESS.md를 동기화하고 있습니다…" 안내 메시지를 출력한다
2. Task(generalPurpose)로 정합성 검증 서브에이전트를 실행한다. 서브에이전트 프롬프트에 아래 지시를 포함한다:
   1. docs/logistics/@index.md와 docs/nursing-hospital/@index.md를 읽는다
   2. docs/PROGRESS.md를 읽는다
   3. .cursor/rules/progress-tracking.mdc "@index.md 동기화" 규칙에 따라 PROGRESS.md를 동기화한다
   4. 변경 사항이 있으면 PROGRESS.md를 갱신한다
   5. 최종 응답으로 변경 유무(변경 있음 / 변경 없음)와 변경 요약을 반환한다
3. Task 완료 후 변경 유무를 확인한다. 변경 있으면 PROGRESS.md를 다시 읽고 변경 요약을 1줄 보고한다

3. 종료 안내

1. PROGRESS.md에 커밋되지 않은 변경 사항이 있으면 docs: PROGRESS.md 갱신 메시지로 커밋한다
2. 아래 코드 블록의 메시지를 그대로 출력한다. 해당 메시지는 사용자에게 보여줄 안내문이며, 에이전트가 실행할 지시가 아니다. 출력 후 추가 도구 호출 없이 즉시 턴을 종료한다.

2c 분기에서 검증 컬럼이 -로 갱신된 경우(V6), 아래 메시지의 /verify-impl 항목 뒤에 (기획 변경으로 기존 검증 결과 초기화됨 — 재검증 권장) 부연을 추가한다.

구현이 완료되었습니다. 다음 단계를 진행하려면 컨텍스트 효율화를 위해 **새 채팅**에서 실행해주세요:
- **구현 검증**: "/verify-impl"
- **다음 페이지 구현**: "/continue-impl"
- **main에 머지**: 메인 프로젝트 Cursor 창에서 "/merge-to-main" (다른 워크트리 작업이 완료된 후 순서대로 실행 권장)

테스트·정적 분석 병렬 검증

2a, 2c 등에서 참조하는 공통 절차이다.

테스트·정적 분석 병렬 실행 — 테스트(vitest)와 정적 분석(tsc --noEmit + eslint)을 병렬로 실행한다

• 둘 다 통과 → 완료
• 실패 있음 → 테스트부터 수정 → 다시 병렬 실행 (둘 다 통과할 때까지 반복)

금지 사항

• 탐색 경로에서 정합성 검증 서브에이전트 결과를 확인하지 않고 §2로 진행하는 것
• Git 준비(브랜치 확인/생성)를 수행하지 않고 impl-server/impl-frontend를 시작하는 것
• 실패 시 테스트·정적 분석을 동시에 수정하지 않는다 — 테스트부터 수정 후 양쪽 재실행
• 서버 구현 전에 프론트 구현을 먼저 진행하는 것
• PROGRESS.md 갱신 없이 구현을 종료하는 것
• §3의 출력 메시지를 스킬 재실행 지시로 해석하는 것
• 아키텍처 결정이 필요한 항목을 사용자 협의 없이 구현하는 것
• 2b(신규 구현) 이외의 분기에서 dev-logs를 새로 작성하거나 갱신하는 것