report-writing
작업 완료 후 상세 리포트 문서를 작성. 변경 이력, 영향도 분석, 검증 결과를 문서화할 때 사용. 파일명 규칙 YYYY-MM-DD-<제목>-report.md
Best use case
report-writing is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
작업 완료 후 상세 리포트 문서를 작성. 변경 이력, 영향도 분석, 검증 결과를 문서화할 때 사용. 파일명 규칙 YYYY-MM-DD-<제목>-report.md
Teams using report-writing should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/report-writing/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How report-writing Compares
| Feature / Agent | report-writing | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
작업 완료 후 상세 리포트 문서를 작성. 변경 이력, 영향도 분석, 검증 결과를 문서화할 때 사용. 파일명 규칙 YYYY-MM-DD-<제목>-report.md
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Report Writing
작업 완료 후 상세 리포트를 작성하는 스킬입니다.
## Core Principle
> **"작업의 '무엇'과 '왜'를 기록하여 6개월 후에도 추적 가능하게"**
## 파일명 규칙 (필수)
```
docs/reports/YYYY-MM-DD-<제목>-report.md
```
예시:
- `2024-12-24-path-renaming-report.md`
- `2024-12-20-security-audit-report.md`
- `2024-12-15-migration-complete-report.md`
## 리포트 구조
### 필수 섹션
```markdown
# 🔄 [작업 제목] 리포트
**작성일**: YYYY-MM-DD
**작업자**: [작업자명]
**스킬 사용**: [사용한 스킬 목록]
---
## 📋 변경 개요
| 항목 | 내용 |
|------|------|
| **변경 사유** | [왜 이 작업이 필요했는지] |
| **변경 내용** | [무엇을 변경했는지] |
| **영향 범위** | [어디에 영향을 미치는지] |
| **상태** | ✅ 완료 / 🔄 진행중 / ❌ 실패 |
---
## 🔧 변경된 파일 목록
### 📝 수정된 파일
| # | 파일 | 변경 내용 | 변경 유형 |
|---|------|----------|----------|
| 1 | `파일경로` | 변경 설명 | 🔧 Refactor |
---
## 🔍 상세 변경 내역
### 파일명
\`\`\`diff
- 이전 내용
+ 변경된 내용
\`\`\`
---
## ✅ 검증 완료
\`\`\`bash
# 검증 명령어 및 결과
\`\`\`
---
## 📌 후속 작업
- [ ] 후속 작업 1
- [ ] 후속 작업 2
```
## 변경 유형 분류
| Prefix | 이모지 | 설명 |
|--------|--------|------|
| Feature | ✨ | 새로운 기능 추가 |
| Fix | 🐛 | 버그 수정 |
| Refactor | 🔧 | 코드 리팩토링 |
| Docs | 📚 | 문서 변경 |
| Performance | ⚡ | 성능 개선 |
| Security | 🔒 | 보안 관련 |
| Breaking | 💥 | 호환성 깨짐 |
| Delete | 🗑️ | 파일/기능 삭제 |
## Before/After 패턴
복잡한 변경에는 Before/After 비교 포함:
```markdown
### Before/After 구조
\`\`\`
Before After
────────────────── ──────────────────
.old-folder/ .new-folder/
├── files/ ├── files/ ✏️
└── config/ └── config/
\`\`\`
```
## 영향도 분석 섹션
```markdown
## 📊 영향도 분석
### 직접 영향
- 영향 1
- 영향 2
### 간접 영향
- 의존성 변경
- 설정 파일 업데이트 필요
### 유지된 항목
| 항목 | 사유 |
|------|------|
| 항목1 | 변경하지 않은 이유 |
```
## 다이어그램 (선택)
Mermaid로 아키텍처 변경 시각화:
```markdown
\`\`\`mermaid
graph LR
A[Before] --> B[Change]
B --> C[After]
\`\`\`
```
## Workflow
### 1. 정보 수집
```bash
# 변경된 파일 확인
git status --porcelain
# 변경 내용 확인
git diff --name-only HEAD
```
### 2. 리포트 초안 작성
필수 섹션 구조에 맞춰 작성
### 3. 검증 결과 추가
실제 검증 명령어와 결과 포함
### 4. 후속 작업 정리
남은 작업 체크리스트로 정리
## 관련 스킬
리포트 작성 시 함께 활용:
| 스킬 | 활용 |
|------|------|
| `changelog-generator` | 변경 분류, 이모지 체계 |
| `adr-log` | 결정 기록, 대안 분석 |
| `writing-plans` | 태스크 구조화 |
## Checklist
리포트 작성 완료 전 확인:
- [ ] 파일명이 `YYYY-MM-DD-<제목>-report.md` 형식
- [ ] 변경 개요 테이블 작성
- [ ] 모든 변경 파일 목록화
- [ ] diff 형식 상세 내역 포함
- [ ] 검증 명령어/결과 포함
- [ ] 후속 작업 체크리스트 작성Related Skills
recipe-generate-report-from-sheet
Read data from a Google Sheet and create a formatted Google Docs report.
gws-workflow-standup-report
Google Workflow: Today's meetings + open tasks as a standup summary.
gws-admin-reports
Google Workspace Admin SDK: Audit logs and usage reports.
power-bi-report-design-consultation
Power BI report visualization design prompt for creating effective, user-friendly, and accessible reports with optimal chart selection and layout design.
creating-oracle-to-postgres-migration-bug-report
Creates structured bug reports for defects found during Oracle-to-PostgreSQL migration. Use when documenting behavioral differences between Oracle and PostgreSQL as actionable bug reports with severity, root cause, and remediation steps.
blog-writing-guide
Write, review, and improve blog posts for the Sentry engineering blog following Sentry's specific writing standards, voice, and quality bar. Use this skill whenever someone asks to write a blog post, draft a technical article, review blog content, improve a draft, write a product announcement, create an engineering deep-dive, or produce any written content destined for the Sentry blog or developer audience. Also trigger when the user mentions "blog post," "blog draft," "write-up," "announcement post," "engineering post," "deep dive," "postmortem," or asks for help with technical writing for Sentry. Even if the user just says "help me write about [feature/topic]" — if it sounds like it could become a Sentry blog post, use this skill.
Writing Fuzzing Harnesses
A fuzzing harness is the entrypoint function that receives random data from the fuzzer and routes it to your system under test (SUT). The quality of your harness directly determines which code paths get exercised and whether critical bugs are found. A poorly written harness can miss entire subsystems or produce non-reproducible crashes.
../../../engineering-team/playwright-pro/skills/report/SKILL.md
No description provided.
user-guide-writing
Write clear and helpful user guides and tutorials for end users. Use when creating onboarding docs, how-to guides, or FAQ pages. Handles user-focused documentation, screenshots, step-by-step instructions.
technical-writing
Write clear, comprehensive technical documentation. Use when creating specs, architecture docs, runbooks, or API documentation. Handles technical specifications, system design docs, operational guides, and developer documentation with industry best practices.
postmortem-writing
Write effective blameless postmortems with root cause analysis, timelines, and action items. Use when conducting incident reviews, writing postmortem documents, or improving incident response processes.
plan-writing
Structured task planning with clear breakdowns, dependencies, and verification criteria. Use when implementing features, refactoring, or any multi-step work.