bkit-claude-code

# bkit Project Rules

## Language Rules

### Conversation
- Always respond in the **same language the user's prompt is written in**. Match the user's language for all conversational replies (e.g., English prompt → English reply, 한국어 프롬프트 → 한국어 답변).

### Code & Documentation Language
- **English by default** for ALL generated content:
  - Code, comments, commit messages, PR descriptions
  - README.md, CHANGELOG.md, and all non-docs/ markdown files
  - Agent definitions (`agents/*.md`), skill definitions (`skills/*/SKILL.md`)
  - Templates (`templates/*.md`)
  - Config files, error messages, log messages

- **Bilingual docs (`docs/` only)** — every NEW file under `docs/` and its subdirectories (`docs/01-plan/`, `docs/02-design/`, `docs/03-analysis/`, `docs/04-report/`, etc.) MUST be created as a matched pair of sibling files:
  - `<base>.en.md` — English version
  - `<base>.ko.md` — Korean (한국어) version
  - Suffix convention: dot separator with ISO language codes (`en`, `ko`). Use `ko`, not `kr`.
  - Both versions must stay in sync in content; only the language differs.
  - Applies to NEW files only — do NOT retroactively rename or translate existing docs.
- **Korean-only exceptions** (한국어 작성, single file):
  - 8-language auto-trigger keywords (EN, KO, JA, ZH, ES, FR, DE, IT) in agent/skill trigger lists
  - bkit memory state descriptions in `.bkit/state/memory.json`

### Key Principle
bkit is a **global service**. Keep all public-facing and code-level content in English. Conversation language follows the user's prompt language. New `docs/` files are bilingual (`.en.md` + `.ko.md` siblings); everything else stays English-only.

### Do NOT
- Do NOT create a new `docs/` file in only one language — always produce both `.en.md` and `.ko.md` siblings
- Do NOT retroactively rename or translate existing docs (waste of tokens; new-files-only rule)
- Do NOT mix languages within a single file (except trigger keyword lists)

## Versioning

**Do NOT advance or modify the project version.** Version bumps (the `version` field in `.claude-plugin/plugin.json`, package.json if any, and version headers) are the repo maintainer's responsibility — not the agent's. This applies to:

- Do NOT bump `.claude-plugin/plugin.json` `version` (leave it as-is even when adding a CHANGELOG entry).
- Do NOT change version numbers in code, manifests, or headers as part of a fix/feature.
- A CHANGELOG entry MAY be added documenting the changes (e.g. a new `## [x.y.z]` section), but the version *number* chosen for that heading is provisional labeling only — it does not constitute a release, and the maintainer will assign the real version at release time. If unsure what version heading to use, ask rather than guessing, or label the entry clearly as unreleased.
- Rationale: version advancement is a release decision that depends on the overall release cadence and what else is merging; an agent making isolated changes cannot determine the correct next version.

## Sprint Management (v2.1.13)

Sprint Management is a meta-container that groups one or more features under a
shared scope, budget, and timeline. Each sprint runs its own 8-phase lifecycle:
`prd → plan → design → do → iterate → qa → report → archived`.

When the user mentions "sprint", invoke `bkit:sprint` skill (`/sprint <action>`).
Sprint phases coexist with PDCA's 9-phase enum — both may track concurrently
(see `docs/06-guide/sprint-migration.guide.md`).

Trust Level scope (`SPRINT_AUTORUN_SCOPE`, L0–L4) controls auto-run boundaries.
At L4 Full-Auto, the orchestrator advances phases until any of 4 auto-pause
triggers fires (quality gate fail / iteration exhausted / budget exceeded /
phase timeout).

For deep-dive Korean guidance, see `docs/06-guide/sprint-management.guide.md`.