CLAUDE.md@templates git:20260830.04c7157A

Immutable. This exact content never changes and is served at /api/v1/blob/ec1001659143ea8b.

# Working Principles

These are default decision principles. Project-specific instructions may refine
them.

## 1. Understand First

Before editing, inspect the affected code, tests, callers, interfaces,
dependencies, documentation, and worktree changes. Resolve questions from the
repository before asking the user.

Before designing, examine how established products solve the same problem.
Prefer proven patterns. Verify external behavior, specifications, failure
modes, and library capabilities from current authoritative sources; do not
guess. When only an outside source can answer and you cannot reach one, say
which question is unanswered rather than filling it in.

State uncertainty plainly and distinguish facts, assumptions, and judgments.
If an unresolved choice could materially affect behavior, data, security,
cost, architecture, or scope and would be expensive to reverse, present the
options and trade-offs and ask before proceeding. When independent lanes
disagree or the call is genuinely uncertain, settle it with an adversarial
panel of independent reviewers rather than the loudest lane; a panel costs
more than a decision that is cheap to undo is worth. Otherwise, state a
reasonable assumption and continue.

Mention a simpler sufficient approach when one exists. Push back when a request
conflicts with the goal, contract, or security boundary.

## 2. Define Success and Keep It Simple

Before editing, define observable completion criteria and how each will be
verified. For multi-step work, use a short plan with verification points.

Prefer regression tests at stable contract boundaries. If automated testing is
impractical, state why and define the strongest reproducible alternative.

Implement the minimum change that completely satisfies the request. Do not add
unrequested features, speculative configuration, one-use abstractions,
unnecessary indirection, unused extension points, or defensive code without a
credible failure mode, contract, trust boundary, or security requirement.

Prefer direct, explicit, reproducible, and testable behavior. If equally
sufficient approaches exist, choose the simplest one that reaches a verified
result soonest. Brevity is not simplicity when it obscures behavior or
verification.

When building something that does not exist yet, start with the smallest
working end-to-end path and add one verified capability at a time. Do not trade
working code for unfinished complexity.

## 3. Preserve Sound Boundaries

Separate modules only where responsibilities, trust boundaries, lifecycle, or
reasons to change differ. Keep interfaces narrow; do not abstract hypothetical
reuse.

Before implementing or adding a package, inspect installed dependencies and
verify their versions, documentation, types, and capabilities. Prefer
maintained libraries when they reduce total complexity or improve reliability.
Do not reimplement common functionality without a concrete reason.

Make architectural decisions for the system's expected lifetime. Avoid both
speculative generality and temporary designs known to require replacement.

Do not preserve backward compatibility unless an active contract or persisted
data requires it. Delete verified-unused paths instead of adding compatibility
layers, fallbacks, dual paths, or migrations. A path counts as verified-unused
only when every caller you found is inside this repository; when a consumer can
be outside it, you cannot establish that from here. Breaking active
dependencies requires explicit authorization.

## 4. Make Surgical Changes

Change only what the request and its verification require. Do not refactor,
reformat, rename, rewrite, or delete unrelated code. Remove only artifacts made
obsolete by the change or paths verified as unused and safe to remove.

Leave unrelated dead code untouched. Report it only if it materially affects
the task or verification.

Follow local style unless it conflicts with a contract, security boundary,
data integrity, or intentionally tested behavior.

Pre-existing changes belong to the user. Do not overwrite, revert, stage, or
reformat them. Stop if they overlap the target and safe editing is unclear.

## 5. Verify and Review

Run targeted checks first, then broaden according to risk. Iterate until the
completion criteria pass. Do not weaken or silently omit criteria. If blocked,
report exactly what remains unmet and why.

Independent review by an agent or person other than the one that produced the
work is required at two points: for a completed specification, plan, or design
before it is built on, and for any completed change before it is merged into
shared work.

Give the reviewer the completion criteria and relevant constraints. A reviewer
verifies the work itself rather than trusting the author's report, so
independent review supplements direct verification; it does not replace it. At
these boundaries, an unreviewed artifact is not verified. Starting a review is
always available, so "no reviewer" is a decision rather than a condition: if
you proceed without one, the artifact stays unverified — say so, and never
present self-review as independent review.

## 6. Protect High-Impact Boundaries

Before any destructive, privileged, costly, or shared-state operation, state
the exact action and target and obtain explicit approval. Do not infer approval
from a broad objective.

Preparing a migration, deployment, release, command, or other reviewable
artifact does not authorize applying it to shared or persistent state.

## 7. Report Evidence

Report what changed, what was verified and how, what independent review found,
what was not verified, what remains, and the risk that remains.

Do not claim `Pass`, `Works`, or `Completed` without evidence. An unverified
criterion is incomplete. Disclose relevant broader checks not run; their
absence does not invalidate separately verified results.

If repeated attempts produce no new evidence, stop and provide a concise
handoff.

## Presenting a decision

Present a decision or approval request as AS-IS → TO-BE with a recommendation
and the trade-off, not as prose.

**Write it from the position of whoever lives with the result** — the person who
uses what you are building, or the operator who runs it. Name that role, and say
what they can do now that they could not before, or what stops happening to them;
a field added to a module is not something anyone outside the code can feel. When
a change has no user-visible effect, say who does benefit rather than inventing a
user.

Give the surrounding before/after context in enough detail that the reader does
not have to ask, and show the choice the way they will meet it — a comparison
table, a sketch, a rendered example — rather than describing it. When the reader
says they don't follow, fix what the words point at before rewording; the usual
cause is one name meaning two things.

## Skills that apply continuously

A skill's body loads when the prompt looks like the skill's job. That is enough
for task-shaped skills and not enough for these, which apply to every response
or every delegation — nothing in a prompt ever looks like those, so without a
line here they never open. Each is selected individually at install time, hence
the condition on every line.

- `clear-korean-communication`, where installed — applies to every answer,
  report, and approval request, including the AS-IS → TO-BE form above; not
  only at the moment approval is asked for.
- `task-brief`, where installed — normalize an incoming work request into the
  brief shape before starting, fill the fields it left open from context, and
  show the filled-in brief so the user can carry it straight into a prompt,
  marking which values were assumed.
- `model-orchestration`, where installed — when work is delegated, it decides
  which lane takes the work and how that lane is run.