new-policy
new-policy
Adds a new policy document to the project following the standard format,
with an automatic Korean translation in docs/ko/policy/.
When to Use
- User says "add a policy", "create a policy for X", "새 정책 추가", "규칙 만들어줘"
- A new convention needs to be formalized (branching strategy, review process, etc.)
- The user describes a working rule that isn't yet written down
Step-by-Step Instructions
Step 1: Gather Information
Ask the user (or infer from context):
- Policy name — becomes the filename in kebab-case
- Example: "branching strategy" →
branching-strategy.md
- Example: "branching strategy" →
- Purpose — what does this policy govern and why?
- Rules — the actual rules (numbered or bulleted)
- Exceptions — when, if ever, the rules may be bypassed
If the user has described the policy in their message, draft the content and ask for confirmation before writing.
Step 2: Create the English Policy Document
Create docs/en/policy/<policy-name>.md:
# <Policy Title>
## Purpose
<What this policy governs and why it exists>
## Rules
1. <Rule 1>
2. <Rule 2>
## Exceptions
<When the rules may be bypassed, or "None" if no exceptions apply>
## Revision History
- <YYYY-MM-DD>: Initial version
Step 3: Create the Korean Mirror
Create docs/ko/policy/<policy-name>.md with a full Korean translation.
Translation rules (same as sync-translations):
- All prose and headings → Korean
- Code blocks, file paths, technical identifiers → keep in English
- Checkbox and list markers → keep as-is
# <정책 한국어 제목>
## 목적
<이 정책이 다루는 내용과 존재 이유>
## 규칙
1. <규칙 1>
2. <규칙 2>
## 예외
<규칙을 우회할 수 있는 경우, 또는 "없음">
## 개정 이력
- <YYYY-MM-DD>: 최초 작성
Step 4: Reference in policy.md
After creating the files, remind the user:
Consider adding an @-reference to this new policy in
docs/en/policy/policy.mdunder the "Related Policy Files" section:- [@docs/en/policy/<policy-name>.md](docs/en/policy/<policy-name>.md) — <description>
Do not automatically edit policy.md — show the suggested line and let the
user decide.
Step 5: Confirm and Report
Tell the user:
Created:
docs/en/policy/<policy-name>.mddocs/ko/policy/<policy-name>.mdAdd an @-reference to
docs/en/policy/policy.mdif appropriate.
More from ywj3493/claude-skills
new-issue
Creates a new issue for tracking work. When a git remote exists, creates a GitHub Issue via `gh` CLI, sets up a working branch, and opens a draft PR linked to the issue. When no remote is configured, falls back to creating local issue documents in docs/en/issue/ with Korean translations. Use this whenever starting new work — features, bug fixes, tasks, or investigations. The user may say "create an issue", "new issue", "이슈 만들어줘", or simply describe work they want to start.
21init-docs
Initializes the standard docs/ directory structure for a new project. Creates docs/en/{specifications,issue,policy}/, docs/ko/{specifications,issue,policy}/, and docs/reference/, seeds initial policy documents in both English and Korean, and places a CLAUDE.md in the project root. Use this when starting a fresh project that should follow the standard documentation system.
19sync-dev
Audits docs/specifications/, docs/issue/, and docs/policy/ for English documents that are missing a Korean translation in docs/dev/, or where the Korean version appears out of date compared to the English source, then creates or updates those translations. Use this to keep docs/dev/ in sync. Triggered by "sync docs", "번역 동기화", "update translations", "sync dev", or "mirror docs".
10sync-translations
Audits docs/en/specifications/, docs/en/issue/, and docs/en/policy/ for English documents that are missing a Korean translation in docs/ko/, or where the Korean version appears out of date compared to the English source, then creates or updates those translations. Use this to keep docs/ko/ in sync. Triggered by "sync docs", "번역 동기화", "update translations", "sync translations", or "mirror docs".
10frontend-planning
[DEPRECATED] Use dev-planning instead. Former 6-step frontend planning pipeline.
10backend-planning
Generates a 5-step backend planning document pipeline (requirements → user stories → API spec → use cases → sequence diagrams) into docs/en/specifications/<domain>/, with domain analysis, tech stack detection, and user review gates at each step.
2