AGENT.md

Language

• Respond in Japanese unless the user explicitly requests another language.
• Preserve code, identifiers, commands, file paths, and quoted text in their appropriate language.

Communication

• Start with the answer, result, or next concrete action.
• Do not begin with acknowledgements, ceremonial preambles, or explanations of planned work.
• Make the result and next action easy to understand.
• Prefer concrete commands, paths, line numbers, expected results, and examples.
• State completed progress explicitly.
• Describe errors by stating what failed, why, and how it was fixed.
• Use numbered lists for multi-step tasks, with one small action per step.
• In multi-turn tasks, state the current status and next step.
• Ask one short clarifying question when ambiguity would materially affect the result.
• Confirm before destructive or difficult-to-reverse actions.
• Provide sufficient detail and clear headings for explanations or walkthroughs.
• If work remains, end with one concrete next action.
• Do not add generic closing phrases or offers to help.

Files and Markdown

• Do not manually modify CHANGELOG.md or files marked as auto-generated.
• Use the repository’s documented generation process for generated files.
• In long Markdown files, put each complete sentence on its own physical line.

Technical Decisions

• Do not optimize primarily for short-term implementation cost.
• Prefer quality, simplicity, robustness, scalability, and long-term maintainability.
• Explain trade-offs when no option satisfies all requirements.

Bug Fixing

• Reproduce the bug before implementing a fix.
• Prefer end-to-end reproduction for user-facing behavior.
• If that is impractical, use the closest reliable reproduction level and explain why.
• Identify and fix the root cause, not only the symptom.
• Add or update a regression test that fails before the fix and passes afterward.
• After three unsuccessful debugging attempts, stop proposing incremental fixes.
• State the most likely incorrect assumption and request one specific diagnostic result.

Engineering Quality and Artifacts

• Address lint errors, test failures, and flaky tests introduced or exposed by the change.
• Fix unrelated issues only when they are low-risk and reasonably within scope.
• Otherwise, report them clearly.
• Do not weaken, skip, or delete checks merely to make them pass.
• Production code expresses how; tests express what; commit messages explain why.
• Comments explain why this implementation was chosen instead of alternatives, including constraints and trade-offs.
• Do not write comments that merely restate the code.

Git and GitHub

• Use git for local version control and gh for GitHub operations.
• Assume repositories are private.
• New branches must use the develop/ prefix and a concise descriptive name.
• Before creating a pull request, read and follow .github/PULL_REQUEST_TEMPLATE.md.
• Keep pull requests concise and include the reason, non-obvious decisions, and validation performed.

When posting GitHub comments through gh, append this footer after a blank line:

🤖 AI-assisted message ({Agent name})

When replying to review comments:

• Briefly explain how the comment was addressed.
• Append the commit hash as plain text.
• Append the standard footer.

Format:

{Response explaining how the comment was addressed} ( {commit hash} )

🤖 AI-assisted message ({Agent name})

Checks Before Pushing

• Run the checks required by the target repository and ensure relevant tests pass.
• Do not push with known failures unless the user explicitly instructs otherwise.
• If a required check cannot be run, state that clearly and do not claim it passed.
• For frontend changes, run at least lint and format.
• For backend changes, run at least spotlessApply and detekt.

Final Response

• Remove sentences that only announce planned work.
• Ensure the first line states the result or immediate action.
• If work remains, ensure the final line states the next concrete action.