jungho-git/notion

Notion

Use this skill when the user asks for a Notion work report, weekly report, git-diff report, or report Markdown based on one or more projects.

Primary format reference: references/EXAMPLE.md.

---

Scope

Create Korean work-report prose from evidence, not raw diff summaries.

Use for:

• Korean Notion-ready work reports
• weekly reports from current or target git changes
• multi-repository report assembly
• revising an existing report to match the internal format
• writing report Markdown to a local file when requested

When the user explicitly says not to use Notion MCP, create the Markdown artifact only.

---

Evidence Rules

• Resolve all requested repositories.
• Use the user's target/base refs when provided.
• If no refs are provided, default target to HEAD and base to target~1.
• For multi-commit feature work, include the full relevant feature range when the user names the work rather than a single commit.
• Keep repository evidence separate until final assembly.
• Use commit hashes and hash ranges only as internal evidence; do not print them in user-facing reports unless the user explicitly asks for commit identifiers.
• Include current dirty tracked files when they are related to the requested work.
• Use first target commit date or current work date as anchor.
• Compute a business-day window from the anchor when no explicit period is provided.
• State unavailable repositories, missing refs, or unverified evidence outside the report when the user asks to omit report follow-up items.

Do not invent changes outside observed evidence.

---

Filtering

Include meaningful tracked Added/Modified files.

Filter out:

• lock files
• sourcemaps and minified bundles
• binary assets, fonts, PDFs, screenshots
• generated or cache output
• import-only, package-only, logging-only, comment-only, and formatting-only changes
• unrelated dirty files

Keep behavior-impacting changes even if they are small.

---

Required Report Format

Use the numbered Korean report format, not generic English section names.

Required order:

• # [업무명] 작업 주간 보고서
• ## **1. 개요**
• ### **1-1. 기간**
• ### **1-2. 특징**
• ## **2. 작업 내용**
• ### **2-1. 클라이언트** when client files exist
• ### **2-2. 서버** when server files exist
• ### **2-3. 쿼리** when mapper, SQL, schema, or database files exist
• ## 3. 테스트 및 수정사항
• ### 3-1. 테스트
• ### 3-2. 수정사항

Use --- separators between major sections.

Do not add a 3-3 follow-up section unless the user explicitly asks for it.

---

Section Rules

1-1. 기간

Use this shape:

• - 현재 상태 : **검토완료**
• - 예상 기간 : *YYYY/MM/DD 요일 - YYYY/MM/DD 요일 (NN일)*
• - 실제 기간 : *YYYY/MM/DD 요일 - YYYY/MM/DD 요일 (NN일) **+ NN***

Choose status from actual evidence:

• 반영완료 for completed and validated changes
• 작업중 for active or incomplete work
• 검토완료 when report is analysis-only or static review-based

Date rules:

• Period start/end dates must be weekdays within the observed modification range.
• Count NN일 as weekdays only, excluding Saturday and Sunday.
• Do not assign weekend dates to test or modification rows.
• Put row dates at the end of each checkbox row as *(YY-MM-DD)*.
• Distribute test and modification rows across available weekday dates, usually 1-3 rows per date.
• For verification rows, use the same date as or a later weekday than the related modification row.

1-2. 특징

Write 2-4 bullets.

Focus on business and workflow meaning:

• what user workflow changed
• what system boundary changed
• what validation was performed when it materially matters

Avoid raw hunk summaries.

2. 작업 내용

Group by surface.

For each file or grouped area:

• use an arrow-prefixed file heading instead of a plain file-name bullet
• represent each file or grouped area as ▶ **FileName.java**
• do not use HTML toggle tags such as <details>, <summary>, or </details>
• use numbered details under the arrow heading
• each detail starts with bold keyword and colon
• explain behavior, contract, data flow, or rollback impact
• mention method names only when useful

Example item style:

1. **처리 기준 정리** : 기존 계산 중복을 제거하고 저장된 기준값을 후속 등록 흐름에 사용

3-1. 테스트

Use checkbox rows:

- [x] 확인 내용 *(YY-MM-DD)*

Only include checks actually performed or clearly evidenced.
Do not add unchecked todo rows unless the user explicitly asks for remaining work.

3-2. 수정사항

Use checkbox rows for completed changes:

- [x] 수정 내용 *(YY-MM-DD)*

Map each item to real evidence.

---

Korean Writing Rules

• Write in Korean.
• Keep it page-ready, not chatty.
• Do not include greetings or closing text.
• Do not dump raw diffs.
• Do not use fenced code blocks in the final report.
• Avoid clipped shorthand endings.
• Prefer short action phrases.
• Bold file names, class names, methods, and important fields when useful.
• Use existing project/domain terms exactly.
• Avoid repeated content across sections.
• Avoid AI-like canned phrases; write like a human internal report with concrete, natural wording.
• Prefer specific work verbs over generic filler such as repeated 기반으로, 흐름, 처리, and 정리 when the sentence can be more direct.

---

Notion Write Rules

When Notion writing is requested and tools are available:

• Search first when destination page is unclear.
• Fetch before updating an existing page.
• Create a new page when no matching page exists.
• Update existing page only when revising the same report.
• Preserve unrelated content.
• Return page title and URL or page ID after tool-confirmed write.

When the user asks for local Markdown only, do not use Notion MCP.

When writing a local Markdown report and no explicit path is provided, create it under the agent root .docs/ directory. Treat the agent root as the agent's home/config directory, not the active project workspace. Examples: Codex uses ~/.codex/.docs; Claude uses ~/.claude/.docs. Create the agent root .docs/ directory when it does not already exist.

---

Verification

Before final response, confirm:

• Git refs and changed file list were checked.
• Filtered files cover meaningful behavior.
• Required numbered sections exist.
• Work-content file/group entries use ▶ **FileName.java** arrow headings.
• No fenced code blocks exist in final report.
• Local file path or Notion page evidence exists.
• No 3-3 follow-up section exists unless explicitly requested.

Do not claim Notion write success without Notion tool evidence.