Report

Report 스킬

작업 보고서를 프로젝트 private/ 디렉터리에 마크다운 파일로 저장한다. 노션·외부 동기화 없이 로컬에만 남긴다.

저장 규칙

• 위치 (하드코딩하지 말 것): 프로젝트에 보고서·산출물 저장 규약이 있으면 그 위치(예: CLAUDE.md·문서 구조가 지정한 보고서(reports) 폴더), 없으면 프로젝트 루트의 private/를 기본값으로 쓴다(없으면 생성). 이 문서의 다른 private/ 언급은 모두 이렇게 결정된 위치로 읽는다.
• 파일명: <저장위치>/<유형>-<slug>-<YYYYMMDD>.md
  • 유형 접두사: done(완료보고) · analysis(분석) · decision(의사결정)
  • <slug>: 보고서 제목에서 영문 소문자 + 하이픈, 40자 이하 (한글 제목은 영문 키워드 추출)
  • 같은 날 동일 파일명 충돌 시 -2, -3 접미사
  • 예: private/done-login-refactor-20260616.md

작업 순서

1. 보고서 유형 결정

argument 또는 대화 맥락에서 유형을 판단한다:

• 완료보고(done) — 작업 완료 후 결과 보고
• 분석(analysis) — 코드/데이터/이슈 분석 결과
• 의사결정(decision) — 선택지를 제시하고 사용자 결정 요청

구현 계획(작업 시작 전 계획 제안)은 이 스킬이 아니라 draft-plan이 담당한다.

2. 저장 경로 결정

프로젝트 루트를 판별하고 저장 위치(규약 우선, 없으면 private/)를 준비한다.

ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
# REPORTDIR = 프로젝트 규약이 지정한 보고서 폴더가 있으면 그 경로, 없으면 기본 private
REPORTDIR="$ROOT/private"   # 규약 위치가 있으면 그 절대경로로 바꾼다
mkdir -p "$REPORTDIR"
DATE="$(date +%Y%m%d)"

프로젝트명은 아래 우선순위로 결정해 프론트매터·slug에 활용한다:

1. 사용자가 명시한 경우 — 그대로 사용
2. 워킹 디렉토리/레포명 — basename "$ROOT" 또는 git remote get-url origin
3. 대화 맥락에서 언급된 프로젝트/서비스/앱 이름
4. 위 모두 불명확 → 기타

3. 본문 작성

표준 마크다운으로 작성한다 (파이프 표·> 인용 그대로 — 별도 변환 없음).

파일 맨 위에 YAML 프론트매터를 둔다:

---
type: done            # done | analysis | decision
title: <보고서 제목>
project: <프로젝트명>
created: YYYY-MM-DD
status: 초안
---

유형별 본문 템플릿:

완료보고 (done)

> 요약: (한 줄 요약)
> 요청: [확인]

## 작업 내용 요약
## 결과물
## 이슈 / 특이사항
## 다음 단계 제안

분석 (analysis)

> 요약: (한 줄 요약)
> 요청: [검토] / [방향 조언]

## 분석 배경
## 분석 결과
## 인사이트
## 제안

의사결정 (decision)

> 요약: (한 줄 요약)
> 요청: [선택]

## 결정이 필요한 상황
## 선택지
  - 각 선택지별 장단점
## 추천안 + 근거
## 결정 기한 (있다면)

4. 파일 저장

Write로 <REPORTDIR>/<유형>-<slug>-<DATE>.md(위에서 결정한 저장 위치)에 프론트매터 + 본문을 저장한다.

5. 완료 메시지 출력

📋 보고서를 저장했습니다.

- 제목: <보고서 제목>
- 유형: <유형>
- 경로: <저장된 파일 경로>

파일을 열어 검토하고, 수정할 점은 이 대화에서 말씀해 주세요.

행동 원칙

• 본문은 간결하게 — 핵심만 담고 불필요한 내용은 넣지 않는다.
• 사용자가 프로젝트명을 언급했다면 반드시 그 이름을 slug·프론트매터에 사용한다.
• 코드를 다루는 보고서(분석·완료보고)는 줄번호 나열 금지. 경로:라인만 주면 독자가 IDE로 찾아야 해 번거롭다. 현황·문제를 짚을 땐 핵심 코드를 발췌해 코드블록으로 넣고 말로 설명한다. 파일명은 발췌 출처로만 붙인다. 보고서만 읽어도 ① 배경(도메인·용어·흐름) ② 문제(지금 코드가 무엇을 어떻게 해서 왜 문제인지, 발췌로 증명) ③ 하고자 하는 것을 파악할 수 있게 자립적으로 구성한다. (draft-plan의 "보고서 작성 원칙"과 동일 기조)
• 구현 계획서가 필요하면 이 스킬이 아니라 draft-plan을 쓴다.