notion

name	notion
description	Turn git diff context into a Korean Notion work report page or update for a personal Notion workspace. Use when the user asks for a work report, git diff to Notion, or to create or update a personal Notion page from current code changes.

• Use references/EXAMPLE.md as the shared example and formatting reference for this skill.
• Keep new guidance, snippets, and future edits aligned with that file.

---

1. Overview

• Use this skill when the task is to produce a Notion-ready Korean work report from git changes using the team's internal work-report rules. Keep the internal reporting logic and Korean prompt intent, but execute the work directly inside Codex with Notion tools instead of reproducing any legacy CLI flow.

---

2. Core workflow

2-1. Resolve the git scope

• Collect these inputs before drafting:

• one or more git projects

• target ref, default HEAD

• base ref, resolved in this order when the user does not specify one: a. origin/main if the remote ref exists (git rev-parse --verify origin/main) b. origin/master if the remote ref exists (git rev-parse --verify origin/master) c. target~1 as a final fallback when no remote main/master is reachable

• project order, because the first project controls the anchor dates

• If the user does not specify commit refs, use the defaults above. If multiple repositories are involved, keep project-specific diffs separate until the final report assembly.

2-2. Reuse the internal filtering logic

• Preserve these behaviors:

• include only tracked Added/Modified files from git diff --name-only --diff-filter=AM

• exclude ignored files

• exclude noise files such as lock files, sourcemaps, minified bundles, common images, fonts, and PDFs

• keep the legacy default noise set in mind, especially package-lock.json, yarn.lock, pnpm-lock.yaml, npm-debug.log, .DS_Store, .eslintcache, .lock, .min.js, .map, .svg, .png, .jpg, .jpeg, .ico, .pdf, .gif, .woff, .woff2, and .ttf

• strip import/package-only diff lines before reasoning over the diff

• use the first target commit date as the anchor date

• compute startDate as 10 business days before the anchor date

• compute endDate as the anchor date

• treat the legacy workflow as decision rules, not as a requirement to reproduce a CLI

• keep the same defaults, filtering intent, date window semantics, and multi-project merge semantics

2-3. Follow the Korean report prompt strictly

• The internal workflow is mostly a prompt generator. Preserve that prompt's structure and wording intent when drafting the report.

• Critical rules:

• write in Korean

• no greeting or closing text

• no duplicated content

• preserve the legacy prompt frame of Changed Files -> Writing Rules -> Response Format -> Diff Content

• no fenced code blocks in the final Notion report

• avoid clipped Korean endings that read like shorthand notes; prefer short action phrases

• skip getter/setter, import, package, logging, comment, and formatting-only changes unless they materially affect behavior

• explain actual behavioral changes, not raw diff hunks

• write file names, class names, and method names in bold when the final page format supports it

• express core keywords in a Notion-highlightable form instead of leaving them as plain raw diff tokens

• keep per-file detail as numbered items such as 1., 2., 3.

2-4. Build the report in the same structure

• Default structure:

• Overview

• Work Details

• Changes

• Tests

• Honor the expected shape:

• Overview: 2 to 3 lines

• Work Details: usually 3 to 6 numbered items per file

• Work Details: group under Client, Server, and Database when the files naturally map to those buckets

• Changes: render as a date/content table, usually 7 to 12 items, weekday dates only, spread across the computed range

• Changes: balance bug fixes, logic improvements, performance improvements, and data-integrity work instead of clustering one category

• Tests: render as a date/test/result table, usually 7 to 12 items, not the same count as Changes, results written as Pass

• Tests: keep test dates after the corresponding change dates and balance happy path, boundary, exception, and integration coverage

• preserve the section order from the internal prompt

• preserve the terse Korean style

• preserve the business-day history illusion in Changes and Tests

• do not copy raw diff text verbatim into the final report

2-5. Create or update in Notion

• search first if the destination page is unclear
• fetch before updating an existing page
• create a new page when no matching page exists
• update the existing page when revising the same report
• preserve unrelated content and replace only the intended report block
• return the page title and URL or page ID when the write succeeds
• when the user points to one existing report page and asks for a targeted correction, treat that page as the source-of-truth and update only that page
• when incremental block edits become brittle because list types or nested blocks drifted, it is acceptable to rebuild that single page from the fetched structure instead of patching block-by-block

---

3. Practical guidance

• Use the current repository context or user-provided hash range as the input surface. Do not dump raw diffs into the final page. Convert them into work-report prose that matches the internal prompt's style. If the change set is small, keep the report compact but still preserve the original section semantics.

• Keep page styling rules separate by section:

• Overview and Work Details usually follow the current page's plain bullet rhythm unless the user asks to change the list style

• Tests and Changes may remain checkbox-style when the current report pattern uses checked to_do rows

• if the user provides before/after numbers such as response-time comparisons, add them to Overview or Features as short summary bullets instead of forcing them into Tests

---

4. References

• references/EXAMPLE.md