From a53b0856c0f6f91b59cc8da397035967391c3fcf Mon Sep 17 00:00:00 2001 From: doguscank Date: Sun, 23 Aug 2026 19:56:09 +0300 Subject: [PATCH] Task: add repository agent instructions --- AGENTS.md | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 AGENTS.md diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 000000000..01be9eb70 --- /dev/null +++ b/AGENTS.md @@ -0,0 +1,49 @@ +# Agent Collaboration Policy + +Use subagents for implementation work that introduces multiple independent +features or components. Keep basic, single-purpose tasks in the main agent +unless delegation clearly improves the outcome. + +## Model selection + +- **Basic tasks:** delegate to a fast, economical model such as `gpt-5.6-luna`. +- **Complex implementation tasks:** delegate to a balanced model such as + `gpt-5.6-terra`. +- **Code reviews and very complex tasks:** delegate to a frontier model such + as `gpt-5.6-sol`. + +When the available model names differ, choose the closest equivalent by the +same capability tier: fast/economical, balanced/complex, then frontier/review. + +## Delegation practice + +- Split only work that is independently actionable, with clear file or module + ownership, to avoid overlapping edits. +- Retain final integration, verification, and user communication in the primary + agent. +- Do not use subagents for simple edits, one-off questions, or narrowly scoped + diagnostics unless the user explicitly requests delegation. + +## Feature delivery and pull requests + +- Deliver new features through pull requests. +- Once a requested task is complete and verified, automatically commit the + relevant changes, push the branch, and open a pull request unless the user + explicitly asks not to. +- Do not create a pull request for a question, investigation, review-only task, + or an intentionally uncommitted work-in-progress. + +## Pull request descriptions + +Write a detailed but straightforward PR body for an AI engineer who does not +need to read the implementation to understand the change. Use plain language +and explain: + +- what changed from a user's perspective; +- why it matters; +- how to verify it, including any important limitations or follow-up work. + +Avoid implementation jargon, internal file names, framework details, and code +walkthroughs unless they are essential to using or reviewing the feature. Keep +the description focused: include enough context to make the decision clear, +without turning it into a technical design document.