- Primary Response Language: Always communicate, explain, and write documentation/comments in Thai (ภาษาไทย).
- Code & Configuration: All source code, terminal commands, configuration files (JSON, YAML, ENV, etc.), variable names, and code syntax MUST remain in English.
- Technical Terms: Keep standard software architecture and programming jargon in English (e.g., refactor, middleware, dependency injection) to maintain accuracy.
- Explanations: Provide all explanations, step-by-step guidance, and trade-off analyses in Thai.
- Code Blocks: Write clean, executable code entirely in English. Do not translate programming keywords, variables, or API routes into Thai.
- Inline Comments: Write comments within code blocks in Thai if they explain logic to the developer, but keep the code itself standard English.
- Read this root
AGENTS.md,README.md, contribution guidance, and repository-native configuration before making changes. - If a nested
AGENTS.mdexists, treat the nearest file as the more specific instruction set for that subtree while preserving these root rules unless explicitly overridden. - Preserve the existing architecture, public interfaces, naming conventions, formatting, and repository style unless the task explicitly requires a change.
- Prefer the smallest safe diff that fully solves the requested problem. Do not rewrite unrelated code or generated/vendor files.
- Never commit credentials, tokens, private keys, production secrets, personal data, or sensitive runtime output. Use documented secret/env mechanisms instead.
- Do not disable tests, security checks, type checks, lint rules, branch protections, or validation gates merely to make CI pass.
- Use repository-native build, test, lint, type-check, security, migration, and packaging commands whenever available.
- Before claiming a task complete, verify the relevant tests/checks and report what actually passed, what was not run, and any remaining blocker.
- Do not claim
production-ready,enterprise-ready,secure, orcompletewithout concrete evidence from the repository and validation results. - For production-impacting changes, consider security, backward compatibility, observability, rollback, migrations, backup/restore, failure handling, and operational documentation.
- Treat authentication, authorization, payments, secrets, infrastructure, data migration, destructive operations, and externally visible API contracts as high-risk changes requiring extra validation.
- Do not force-push, rewrite shared history, delete unrelated branches/tags, or perform destructive Git operations unless the user explicitly authorizes that exact action.
- Keep commits focused and descriptive. Avoid mixing unrelated refactors with functional fixes.
- Do not merge failing changes or bypass required checks. If checks are unavailable, say so rather than assuming success.
- Preserve existing user work and project-specific instructions. When requirements conflict, follow the more specific repository rule or explicit user instruction and document the trade-off.