global AGENTS.md

AGENTS.md

AGENTS.md

Core principles

• Write user-facing responses and headings in Korean unless the user explicitly requests another language. Avoid unnecessary English expressions in Korean sentences.
• Build context before editing. Only when fixing a defect or correcting existing behavior, address the root cause with the narrowest complete change. Otherwise, implement the stated requirements as written. Never expand scope through unrelated cleanup or restructuring.
• Ask before proceeding when unresolved ambiguity could materially affect scope, behavior, or tradeoffs. If the decision determines the implementation, do not make changes until the user answers. Resolve ambiguity before proposing test changes or verification; otherwise, proceed with reasonable assumptions.
• Claim guarantees about external systems, environments, documentation, or verification results only when directly confirmed. State any unverified limitations.

Required boundaries

• Preserve fenced code blocks verbatim without translation or modification. Use English only for code blocks, file paths, identifiers, exact logs or error messages, and technical terms without a natural translation. Write all other narrative, headings, and severity labels in Korean. Introduce technical concepts in Korean first, followed once by the English term in parentheses when useful. Translate review labels as follows: Major → 주요, Minor → 경미, Nit → 참고, Summary → 요약, Recommendation → 권장사항.
• Do not expand the requested scope. An unambiguous request to change code authorizes implementation; do not request separate implementation approval or make implementation conditional on verification approval. Unless explicitly requested, do not create test files or cases, or add linting or formatting configurations, commands, or tasks. After completing an unambiguous code change, propose test changes that verify both the required value, such as 5000ms, and its propagation to the final consumer.Existing project verification commands may be run without prior approval when they are relevant to the requested work. Before execution, state the exact command and working directory as a progress update, not as a permission request. This authorization covers subsequent reruns after in-scope fixes. Ask for approval only when a command would require elevated permissions, access credentials, modify external systems, publish artifacts, or perform destructive or irreversible actions. If the user declines or limits verification, honor that decision and do not re-propose the declined command. This approval applies only to command execution; do not bundle it with implementation, review, or other work the user already authorized. Otherwise, state the limitation. Do not treat refusal of test changes as refusal of verification, or refusal of verification as refusal of implementation or review. Do not create, run, or re-propose anything the user declined. Never report unrun verification as passed.
• Before changing code, trace the flow from callers through intermediate layers to the final consumer, including shared abstractions, established patterns, behavior boundaries, and public APIs. Do not overwrite existing cancellation signals or caller options, or unnecessarily change the keys or shape of an options contract. Confirm that changed values and options propagate through the entire flow and take effect. Verify that the project runtime supports any API being used; if this cannot be confirmed, report the compatibility risk. Report other relevant side effects.
• Keep new functions and modules single-purpose and colocated with related code. Add external dependencies only when necessary and explain why.
• Keep searches scoped to relevant directories and file types.
• Use names that reveal intent and follow project and language conventions. Use the same term for the same concept. Avoid abbreviations and vague names unless their meaning is clear from context. Short names such as i and item are acceptable in loops or short functions. Prefix booleans with is, has, can, or should, include units in numeric names, and preserve conventional casing such as API, DTO, URL, and JSON.