CLAUDE.md git:20260901.ea92942A

Immutable. This exact content is served forever at /api/v1/blob/556fd83e999e3681.

# Claude Code Rules

Use these repo-scoped Claude Code skills:

- Repository setup/sync: `github-sync` from `.claude/skills/github-sync/SKILL.md`.
- Release: `github-release` from `.claude/skills/github-release/SKILL.md`.
- Ordinary implementation tasks targeting `develop`: `develop-task-flow` from `.claude/skills/develop-task-flow/SKILL.md`.
- Urgent fix for a released defect: `hotfix-flow` from `.claude/skills/hotfix-flow/SKILL.md`.
- README writing/updating: `readme` from `.claude/skills/readme/SKILL.md`.
- jig project installation and GitHub profile setup: `jig-setup` from `.claude/skills/jig-setup/SKILL.md`.
- jig installation updates: `jig-update` from `.claude/skills/jig-update/SKILL.md`.
- jig installation diagnostics: `jig-doctor` from `.claude/skills/jig-doctor/SKILL.md`.
- Repository branch and file cleanup: `repo-hygiene` from `.claude/skills/repo-hygiene/SKILL.md`.
- Procedure conformance audit of the history: `conformance-audit` from `.claude/skills/conformance-audit/SKILL.md`.
- Version grading rubric: `version-rubric` from `.claude/skills/version-rubric/SKILL.md`.
- Project type scan and rubric recommendation: `rubric-scan` from `.claude/skills/rubric-scan/SKILL.md`.

## Repository Model

- `main` and `develop` are protected against force pushes and deletion; direct pushes are allowed.
- Work branches start from `origin/develop`: `feature/<slug>`, `fix/<slug>`, `chore/<slug>`.
- A finished task is squash-merged into `develop` locally and pushed. There are no pull requests.
- A release promotes `develop` to `main` with a fast-forward push (`git push origin develop:main`), then creates the `vX.Y.Z` tag and GitHub release from the CLI.
- Release notes are written by the agent from the commits in the release range; there is no release-drafter and there are no release labels.

## Terminology

- **jig product** means the behavior and payload delivered to users: installed skills, installer/update behavior, generated `dist/`, plugin hooks, and state created in installed repositories.
- **jig source repository** means this repository where the jig product is developed. Repo-local instructions, validation, project plans, and contributor tooling belong to this scope unless they are deliberately added to the product payload.
- **jig-managed project** means an external repository where jig is installed and used. Its clone-local hooks, `.jig/` files, Git config, and GitHub settings are managed-project state.
- Avoid “this project” or “the current project” when the distinction affects implementation. Say **jig product**, **jig source repository**, or **jig-managed project** explicitly.

## Skill Copies

- `skills/` is the source of truth for every skill and is built into `dist/` for distribution.
- Skill bodies and the rubric catalog are written in English; the rubric file contract uses English section titles with the Korean spellings still accepted as legacy. What a skill *produces* (reports, commit bodies, release notes, README) follows the target repository's own language, defaulting to English.
- This repository keeps synced copies of its repo-scoped skills under `.agents/skills` (Codex, `jig-` prefixed to match the shipped payload) and `.claude/skills` (Claude Code, unprefixed development copies). When a skill under `skills/` changes, update both copies in the same task.
- This source repository has a local maintenance rule, not a capability shipped to installed projects: every manifest skill has matching guides at `docs/en/skills/<name>.md` and `docs/ko/skills/<name>.md`. When any file under `skills/<name>/` changes, review both guides and update every affected workflow, input/output, safety rule, resource, and Mermaid diagram. Then run `sh scripts/update-skill-doc-digests.sh <name>`; validation rejects stale guide digests. Skill additions and removals also update both language indexes.

## Build

- Rebuild the distribution after any change under `skills/`, `hooks/`, or `manifest.tsv`: `sh scripts/build-dist.sh`.
- Validate before merging or releasing: `sh scripts/validate-dist.sh`. It checks the payload file list, managed block markers, the rubric catalog contract, and the README layout rules.
- `dist/` is generated, never hand-edited. The Claude Code plugin payload is `dist/claude-code-plugin/jig` and the marketplace definition is `.claude-plugin/marketplace.json`.

## Safety Rules

- Do not force push.
- Do not delete branches without explicit user confirmation.
- Do not overwrite user-modified files without explicit user confirmation.
- Do not create unrequested AI skill directories beyond `.agents/skills` and `.claude/skills`.
- `.jig/` is project-owned: only `version-rubric` writes `.jig/versioning.md`, and the installer and `jig-update` never touch it.
- The project-type rubric catalog lives at `skills/version-rubric/rubrics` and ships as payload; `rubric-scan` reads it and never writes. `rubrics/INDEX.md` is the only list of types, so a new rubric file must be added to that table in the same task.
- Do not push ordinary work directly to `main`; `main` only updates through the release fast-forward push.
- Keep all documentation and skill examples generic: use placeholders such as `your-account`, `your@email.com`, and `/absolute/path/to/<name>`. Never include local machine paths, personal identifiers, or examples taken from local or other projects.
- If a release request includes unfinished code, config, documentation, generated `dist`, or workflow changes, stop release execution and complete those changes first through `develop-task-flow`.
- If `git push origin develop:main` would not fast-forward, stop and report; never force-push to resolve it.
- In a table whose first column holds identifiers people copy (skill names, commands, options, paths), keep the description cells about as short as the identifiers. GitHub sizes columns by content, so long descriptions squeeze the identifier column until a name wraps mid-word. Trim the description or switch to a list; wrapping inside a description is fine.
- `README.md` is the English canonical README and `README.ko.md` is its Korean mirror. A change to one is made in the other in the same task, and Korean prose never lands in `README.md`.
- Preserve unrelated user changes.

## Develop Task Rules

- Use `develop-task-flow` for normal code/config/docs work.
- Create task branches from `origin/develop` using `feature/<slug>`, `fix/<slug>`, or `chore/<slug>`.
- Run relevant tests before merging.
- Finish by `git merge --squash` into `develop` and a single conventional commit, then push `develop`.
- Squash commit subjects use a conventional prefix (`feat:`, `fix:`, `chore:`, `docs:`, `refactor:`, `test:`, `ci:`); bodies carry Korean, user-perspective, release-note-ready bullets with technical terms in backticks.
- The squash commit body ends with a `Release-Grade: patch|minor|major` trailer, graded against `.jig/versioning.md` for that task alone using its changed paths. Omit the trailer only when no rubric resolves.
- These squash commits are the release-note source. Sections derive from the prefix: `feat:` → `🚀 Enhancements`, `fix:` → `🐛 Fixes`, `chore:` → `🧰 Chores`, any other prefix → its own section (`docs:` → `📚 Documentation`).

## Release Rules

- Release only when the user explicitly asks for a release.
- Grade the bump against this repository's version rubric at `.jig/versioning.md`, which grades by what installed projects pay: `patch` when the public interface is unchanged, `minor` for new capability or a break that fails loudly and names its own fix, `major` when a human decision is needed or behavior changes silently. A silent behavior change is always `major`, and any `migration-manual` block forces `major`. `docs/en/versioning.md` is the English commentary, `docs/ko/versioning.md` is its Korean mirror, and the matching `version-rubric.md` files explain the contract for installed projects.
- A hotfix must name a matching item from `## 핫픽스 트리거` in `.jig/versioning.md`; `hotfix-flow` stops when nothing matches, and widening that list is a separate committed decision rather than a step inside a hotfix.
- Two floors feed the grade. The highest `Release-Grade` trailer in the range is **never lowered**, because it was judged with the diff in hand. The `## 인터페이스 경로` path floor, matched against `git diff --name-only` with the first matching row winning, is **advisory**: a release may land below it when the report records why.
- While the major version is `0`, a `major` grade raises the minor position (`v0.Y.Z` → `v0.(Y+1).0`).
- Compute the next version from the latest `vX.Y.Z` tag using the graded bump type; an explicit `vX.Y.Z` from the user overrides it. If the grade exceeds the requested bump, report the reason and ask before continuing.
- Verify a clean worktree, `develop` synced with `origin/develop`, and a non-existing tag before promoting.
- Promote with `git push origin develop:main` (fast-forward only), tag the released commit, and publish with `gh release create`.
- Write the release notes from `git log <previous>..<version> --no-merges`: categorized `## Changes` sections plus a Korean `### Summary`, and a `### Migration` section when installed projects must take repository-side action.

## Reporting

When doing release work, report:

- Current repo and branch
- Previous and new version
- Promotion, tag, and release status
- Blocked commands and reasons