work-plan 계획서와 work-execute 작업 결과를 읽고,
Surveyor 프로젝트 파트 / hmCesium API 파트로 나눠 GitHub 이슈 형식으로 정리하고
커밋 메시지를 생성한다. 완료 후 _issue.md 파일로 저장한다.
STEP 1 — 계획서 파일 특정
$ARGUMENTS에 파일 경로나 파일명이 주어진 경우 해당 파일을 사용한다.
주어지지 않은 경우 아래 규칙으로 자동 탐색한다.
pwd로 현재 프로젝트 루트 확인{프로젝트루트}/ai_history/work-plan/폴더 내*.md파일 목록 조회-issue.md로 끝나는 파일은 제외한다- 가장 최근에 수정된 파일 (또는 인덱스 번호가 가장 큰 파일)을 대상으로 선택
- 사용자에게 선택된 파일명을 알리고 진행 의사를 확인
STEP 2 — 계획서 파싱
선택된 계획서를 Read 도구로 읽고 아래 항목을 추출한다.
- 기능 이름: 파일명의 kebab-case 부분 (예:
13.draw-polygon.md→draw-polygon) - 원본 프롬프트: 계획서의 “프롬프트” 섹션 원문
- 계획 요약: “계획” 섹션에서 구현 내용 핵심 추출
- 작업 내용: “작업 내용” 섹션 — 수정된 파일 목록과 변경 내용
- 결과: “결과” 섹션 — 테스트 방법, 주요 변경점
- 현재 상태 확인: “작업 내용”이 “계획 수립 완료”이면 사용자에게 알리고 작업이 완료된 이후 다시 실행하도록 안내한 뒤 중단한다
STEP 3 — 변경 파일 분류
“작업 내용”에서 수정된 파일 목록을 추출하고 두 그룹으로 분류한다.
hmCesium API 파트 (공유 코드):
- 경로에
api/src/core/또는api/src/modules/또는api/src/가 포함된 파일
Surveyor 프로젝트 파트 (Surveyor 전용):
- 위에 해당하지 않는 모든 파일
- 예:
views/,routes/,controllers/,public/,db/,config/, HTML, CSS 등
변경 내용이 어느 파트에도 없으면 해당 섹션은 생략한다.
STEP 4 — 이슈 타입 결정
작업 내용을 보고 다음 중 가장 적합한 타입을 선택한다.
| 타입 | 설명 |
|---|---|
Feature | 새로운 기능 추가 |
Fix | 버그 수정 |
Refactor | 코드 구조 개선 (기능 변화 없음) |
Chore | 설정, 빌드, 문서, 의존성 등 |
커밋 접두어는 같은 분류를 사용한다: feat, fix, refactor, chore
STEP 5 — 이슈 내용 생성
아래 형식으로 GitHub 이슈 본문을 작성한다.
# [{타입}] {기능 한글명}
## 개요
{계획서의 프롬프트와 계획 요약을 참고해 3~5줄로 이번 작업의 배경과 목적을 서술한다}
---
## 변경 파일 목록
### hmCesium API 변경 사항
> 다른 프로젝트(new_gsim 등)와 공유하는 코드. 기존 코드 수정 없이 추가만 수행.
| 파일 | 변경 내용 |
|---|---|
| `{파일경로}` | {변경 내용} |
**추가된 주요 API** (있는 경우에만)
- `{함수명}({파라미터})` — {설명}
---
### Surveyor 프로젝트 변경 사항
> Surveyor 프로젝트 전용 코드.
| 파일 | 변경 내용 |
|---|---|
| `{파일경로}` | {변경 내용} |
**추가된 주요 기능** (있는 경우에만)
- `{함수명}({파라미터})` — {설명}
---
## 결과
- {테스트 방법}
- {주요 변경점 요약}
---
> 상세 작업 기록: `ai_history/{계획서 파일명}`
---
## 커밋 메시지
{STEP 6에서 생성한 커밋 메시지를 아래 형식으로 삽입}
한 파트만 변경된 경우 — 커밋 1개:
{타입접두어}: {기능 한글 요약}
- {변경 내용 핵심 1}
- {변경 내용 핵심 2}
양쪽 파트 모두 변경된 경우 — 커밋 2개:
**커밋 1 (hmCesium API)**
{타입접두어}(hmCesium): {API 변경 한글 요약}
- {API 변경 핵심 1}
- {API 변경 핵심 2}
**커밋 2 (Surveyor)**
{타입접두어}: {프로젝트 변경 한글 요약}
- {프로젝트 변경 핵심 1}
- {프로젝트 변경 핵심 2}
작성 규칙:
- hmCesium API 변경 사항이 없으면 해당 섹션 전체 생략
- Surveyor 프로젝트 변경 사항이 없으면 해당 섹션 전체 생략
- 추가된 주요 API / 주요 기능은 3개 이상일 때만 별도 기재, 그 미만이면 표 안에 포함
- 관련 DB 테이블 변경이 있으면 “결과” 섹션 앞에 ”## 관련 DB 테이블” 섹션 추가
STEP 6 — 커밋 메시지 생성
STEP 3에서 분류한 결과에 따라 커밋 메시지를 생성한다.
케이스 A — 한 파트만 변경된 경우 (API 파트만 or 프로젝트 파트만)
커밋 메시지 1개만 생성한다.
{타입접두어}: {기능 한글 요약} #{이슈번호가 있는 경우}
- {변경 내용 핵심 1} (파일명 또는 함수명 포함)
- {변경 내용 핵심 2}
- {변경 내용 핵심 3}
케이스 B — 양쪽 파트 모두 변경된 경우 (API + 프로젝트)
커밋을 반드시 2개로 분리해서 생성한다. API 파트를 먼저 커밋하고, 프로젝트 파트를 나중에 커밋하는 순서를 권장한다.
── 커밋 1: hmCesium API ──
{타입접두어}(hmCesium): {API 변경 한글 요약} #{이슈번호가 있는 경우}
- {API 변경 핵심 1} (파일명 또는 함수명 포함)
- {API 변경 핵심 2}
── 커밋 2: Surveyor 프로젝트 ──
{타입접두어}: {프로젝트 변경 한글 요약} #{이슈번호가 있는 경우}
- {프로젝트 변경 핵심 1} (파일명 또는 함수명 포함)
- {프로젝트 변경 핵심 2}
- {프로젝트 변경 핵심 3}
공통 규칙:
- 각 커밋 제목(첫 줄)은 70자 이내
- 불릿 라인은 2~4개 (가장 핵심적인 변경만)
- 파일명 또는 함수명을 최소 하나 이상 포함
- API 커밋에는
(hmCesium)스코프 명시
STEP 7 — 파일 저장
이슈 내용을 {인덱스}.{kebab-case}-issue.md 파일로 저장한다.
- 인덱스와 kebab-case는 계획서 파일명에서 그대로 가져온다
(예: 계획서
13.draw-polygon.md→ 이슈 파일13.draw-polygon-issue.md) - 저장 위치:
{프로젝트루트}/ai_history/work-plan/ - 이미 같은 이름의
_issue.md파일이 존재하면 사용자에게 덮어쓸지 확인
STEP 8 — 완료 보고
사용자에게 다음을 전달한다.
- 이슈 본문 — 마크다운 코드블록 없이 바로 출력 (사용자가 복사하기 쉽게)
- 커밋 메시지 — 각각 별도 코드블록으로 출력
- 양쪽 파트 모두 변경된 경우: “커밋 1 (hmCesium API)”, “커밋 2 (Surveyor)” 라벨 붙여 순서대로 출력
- 한 파트만 변경된 경우: 커밋 메시지 1개 출력
- 저장된 파일 경로