mirror of https://github.com/ghostfolio/ghostfolio
1 changed files with 49 additions and 0 deletions
@ -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. |
|||
Loading…
Reference in new issue