bootstrap
Initializes or adds to the DMK workflow config. Collects org, project name, repos, team, Notion integration, and GitHub Project for task tracking. Saves to ~/.datamktkorea/config.json. Supports multiple projects in one config. Works from any directory. Use this skill when the user says "setup", "initialize pipeline", "create the project board", "새 프로젝트 추가", "파이프라인 설정", "처음 설정해줘", or when other dmk-pipeline skills detect that ~/.datamktkorea/config.json is missing and direct the user here.
format-and-commit
Chains Korean code-comment formatting and conventional-commit creation into a single PR-prep flow. Use when the user wants to add comments AND commit in one pass — triggered by "주석 달고 커밋", "PR 준비해줘", "주석 정리하고 커밋", "format and commit", "comment then commit", or any phrasing that pairs commenting with committing on recently changed code. Delegates to `dmk-oneteam:format-code-comments` first, gates on user approval, then delegates to `dmk-oneteam:git-commit`. Never runs `git add .`, `git add -A`, or `git commit -a`.
format-code-comments
Adds Korean inline comments, documentation comments (TSDoc / Google-style docstring), and section comments to TypeScript and Python code before a PR. Analyzes git diff against a chosen base branch, expands scope to full functions and classes that contain changes, reviews existing comment quality, presents an approval plan, then writes. Use when the user says "주석 달아줘", "PR 전 주석 정리", "comment 추가", "코드 문서화", "docstring 작성", "JSDoc 추가", or describes wanting comments on recently changed code. Works on entire files or specific functions/sections. Do NOT use for code review, refactoring suggestions, or documentation outside source files.
git-commit
Use this skill whenever the user wants to commit changes, asks to split working-tree changes into multiple commits, or wants help organizing messy unstaged work — even if they don't explicitly say "commit". Writes Conventional Commits + Gitmoji messages. Strictly never runs `git add .`, `git add -A`, or `git commit -a`; commits only what the user has staged or what an approved grouping plan specifies.
git-pull-request
Generates a polished Pull Request body by analyzing git commit logs, branch lineage, and diffs against the correct parent branch (develop vs main). Use this skill whenever the user asks to "PR 만들어줘", "PR 내용 정리", "PR 본문 작성", "Create a PR", "Summarize commits", "merge 준비", "릴리스 노트", or wraps up work on `features/*`, `feature/*`, `feat/*`, `hotfix/*`, `release/*`, `fix/*`, or `bugfix/*` branches — even if they don't say the word "PR" explicitly.
decompose-sdlc-trigger
Decomposes a 트리거(Initiative) document into N sub-Requests in the Notion Requests DB via AI-draft + Human-edit loop. Reads the parent Trigger's Fat Marker Sketch, Success Criteria, Appetite, and Rabbit Holes; proposes 3–7 candidate sub-Requests aligned with INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable); lets the human review/edit/reject/add in a single approval gate; then batch-writes to Notion with proper relations. Use when the user says "트리거 분해", "하위 요구사항 나눠줘", "이 Trigger를 Requests로 쪼개줘", "decompose trigger", "break down initiative", or after a Trigger's Phase 8 Review has completed and sub-work items need to exist in Requests DB. Do NOT use for small Requests that directly map to a single Spec (bypass to write-sdlc-spec) or for Triggers without a completed Fat Marker Sketch.
notion-api
Read, query, and write Notion pages and databases via the Notion API (version 2026-03-11) using bundled bash + curl scripts. Use this skill whenever the task touches Notion in any way — reading an arbitrary page to gather development context, looking up a page by title, listing items from a team database, creating a new page, updating properties or content, moving a page to trash. Prefer these scripts over any MCP or ad-hoc curl so behavior stays consistent across the datamktkorea team. Requires `~/.datamktkorea/config.json` (with `notion_token` and `notion_dbs` map) and `jq`.
task-writer
Writes a new Request page in Notion's Requests DB from a free-form description, sizing the body to match the actual work. Use when the user wants to formalize a 업무 지시 / 티켓 / 작업 요청 / hand-off — including "업무 지시 써줘", "티켓 작성해줘", "task 만들어줘". Also trigger when the user describes a task to delegate without explicitly asking for a document. Do NOT use for 2–6주 strategic bets (`write-sdlc-trigger`), implementation specs (`write-sdlc-spec`), or meeting notes (`write-meeting-notes`).
write-meeting-notes
Writes structured meeting notes for team meetings. Use this skill whenever the user provides meeting content — a transcript, script, audio file path, or rough notes — and wants it turned into a proper meeting record. Trigger on phrases like "회의록 써줘", "미팅 노트 정리해줘", "회의 내용 정리", "write meeting notes", or when a user pastes a meeting transcript and says "이거 회의록으로 만들어줘". Also trigger when the user shares a meeting recording or file and asks to summarize or document it.
write-sdlc-prd
Writes a Product Requirements Document (PRD) section-by-section through interactive Q&A, designed to surface decisions that get expensive when discovered late (pricing, multi-tenancy, i18n, audit, permissions). Trigger whenever the user mentions PRD, 기획서, 요구사항 문서, 제품 기획, 프로덕트 스펙 — and also when they describe wanting to plan out a new product or feature in writing, even without naming the artifact. Use for any feature serious enough to warrant a written spec, not for one-line memos.
write-sdlc-spec
Writes an executable Spec document in Notion "Specs" DB through interactive Q&A, linked to a parent Request in "Requests" DB. Handles 4 Request 유형 (기능 에러 / 기능 추가 / 기능 변경 / 기능 개선), each with its own template-driven Q&A flow that forces substantive writing (sentence stems, good/bad examples, self-checks). Reads the user's codebase (via ~/.datamktkorea/code.json) before writing so the Spec contains real file:line references, not generic text. Use when the user says "스펙 써줘", "write spec", "기능 추가 명세 작성", "버그 수정 스펙", "이 요청 Spec으로 만들어줘", or wants to turn a Request into an agent-ready implementation spec. Do NOT use for Initiative-level bets (use write-sdlc-trigger for those) or for non-development requests (지원 요청, 행정 요청).
write-sdlc-trigger
Writes a 트리거(Initiative) document in Notion "Triggers" DB through interactive Q&A. Conducts section-by-section dialogue with the user following a 7-section bet structure: TL;DR, Problem, DIBB, Fat Marker Sketch, Appetite, Rabbit Holes/No-gos, Success/Kill Criteria. Each section has sentence stems, good/bad examples, and self-check questions that structurally prevent vague or performative writing ("AI will be useful" is literally unwriteable here). Use when the user says "이니셔티브 써줘", "트리거 작성", "write trigger", "write initiative", "베팅 문서 만들자", or wants to document a large bet that requires 2–6 weeks of team time. Do NOT use for small feature additions, bug fixes, or chores: those are Specs, not Triggers.
fastapi-best-practices
A skill for following best practices when developing FastAPI applications. It covers guidelines for project structure, code organization, and common patterns to ensure maintainable and scalable FastAPI projects.