1. Overview of TRAE SOLO Agent Prompt Architecture
1.1 Core Operating Foundation
TRAE SOLO operates as an autonomous pair-programming agent inside Trae IDE. Its reasoning model is Gemini-3-Pro-Preview. The complete system prompt is divided into 18 functional modules. Each module controls a specific part of the agent’s behavior.
The prompt does not only define who the agent is. It also defines how the agent should plan tasks, read files, edit code, validate changes, manage memory and respond to users.
During each interaction, Trae IDE injects real-time context into the agent. This includes active file paths, cursor positions and the current development task. The user’s request is inserted through the <user_input> placeholder. This allows the agent to reason from the current project state instead of answering like a disconnected chatbot.
Traditional AI coding assistants often require users to confirm every small step. This slows down development. TRAE SOLO uses a different design. It gives the agent controlled autonomy. The agent can decompose tasks, inspect the project, modify files and run validation before asking for final user review.
This is why the prompt system is valuable to study. It reveals how an autonomous coding agent can be constrained, guided and made useful inside a real IDE environment.
1.2 Six-Layer Structure of the 18 Prompt Modules
For easier understanding, the 18 modules can be grouped into six functional layers.
The first layer is identity and baseline behavior. It defines the agent’s role, model foundation and output style.
The second layer is autonomy and execution authority. It tells the agent when to act, when to ask for missing information and how to perform code modifications.
The third layer is task orchestration. It defines how the agent creates Todo Lists, decomposes complex requirements and assigns subtasks.
The fourth layer is tool governance and self-verification. It controls parallel tool usage, file editing safety and mandatory validation after changes.
The fifth layer is output standardization. It defines language matching, code reference formatting, preamble style and final answer structure.
The sixth layer is persistent memory. It defines what the agent can store, what it must not store, how memory should be updated and how memory references should be cited.
Together, these layers form a closed-loop workflow:
Receive user input
→ Load IDE context
→ Understand the task
→ Build a plan if needed
→ Read project files
→ Edit code safely
→ Validate the result
→ Store reusable knowledge
→ Deliver a concise final response
This layered design prevents the prompt from becoming a single chaotic instruction block. It also makes the agent easier to maintain and extend.
2. Tier One: Identity and Baseline Operating Rules
Module 1: Agent Identity Declaration
The first module defines TRAE SOLO as a professional coding assistant running inside Trae IDE. It also states that Gemini-3-Pro-Preview is the underlying model.
This identity declaration is important. It anchors the agent inside a software development environment. The agent is not expected to behave like a general chat assistant. It should focus on project-aware coding support.
Two mechanisms are especially important.
First, the IDE injects real-time environment information into every interaction. This includes open files, cursor position and current development context.
Second, the <user_input> placeholder stores the user’s exact request. This helps the agent separate system-level rules from the user’s actual task.
This structure reduces off-topic answers. It also helps the model reason from the current codebase instead of producing generic advice.
Module 2: Output Style Requirements
The second module defines the output style. TRAE SOLO must provide clear, relevant and technically useful responses.
The agent should not return only raw code. It should explain what it changed and why. This turns the agent into a pair-programming assistant rather than a blind code generator.
The output should also avoid unnecessary long explanations. Developers usually need fast answers. They need enough detail to trust the change, but not so much text that the result becomes hard to scan.
This rule creates a practical balance. The agent supports developer learning, but it still respects engineering speed.
3. Tier Two: Autonomy and Code Modification Rules
Module 3: Proactiveness and Persistence
This is one of the most important parts of the prompt. It gives TRAE SOLO controlled autonomy.
The agent is instructed to keep working until the user’s task is fully resolved. It should stop only when critical missing information blocks progress.
It must also detect whether the PLAN toggle is enabled in the input panel. If PLAN mode is active, the agent should create a more formal multi-step plan. If the task is simple, it can execute directly.
The module includes several key rules:
- Continue the workflow until the task is complete and validated.
- Use PLAN mode when the task requires structured planning.
- Validate changes before marking a subtask as finished.
- When information is unclear, investigate first instead of stopping too early.
- Make reasonable project-aligned assumptions when safe.
- Use local SQLite access when structured data storage or querying is required.
- Avoid repeated “should I continue?” prompts.
This design solves a major problem in many AI coding tools. Traditional assistants often pause too frequently. They ask for approval after every small operation. TRAE SOLO is designed to work more like a senior teammate. It can complete a batch of related actions before asking the user to review the result.
Module 4: Code Change Standards
The fourth module defines how the agent should make code changes.
It forbids generating oversized hash strings, raw binary blobs or non-text artifacts. These outputs waste tokens and are rarely useful in a coding conversation.
It also requires the agent to use built-in IDE editing capabilities when changing files. The agent should not only print code and ask the user to copy it manually.
This rule makes the workflow more practical. Developers do not want long code blocks if the agent can safely apply the change inside the project.
Module 5: Full Context Understanding
The fifth module requires the agent to collect enough context before generating a solution.
If the repository context is incomplete, the agent should read more files. If uncertainty remains, it should explain the knowledge gap instead of inventing details.
This is a key guardrail against hallucination. Coding tasks are highly context-sensitive. A solution that looks correct in isolation may break the project if it ignores local conventions, dependencies or architecture.
TRAE SOLO’s prompt tries to prevent this by making context collection part of the workflow.
4. Tier Three: Multi-Tier Task Orchestration
Module 6: Four-Tier Task Assignment Architecture
TRAE SOLO includes a task delegation structure for complex development work. The original analysis describes four functional roles.
The first role is the Orchestrator. It coordinates the whole task and decides how work should be distributed.
The second role is the Primary Task Handler. It creates the central Todo List and keeps the task aligned with the user’s request.
The third role is the General Subtask Executor. It handles ordinary file edits, code updates and documentation tasks.
The fourth role is the Specialized Domain Specialist. It is used for more specific work, such as database schema design, frontend architecture or performance optimization.
The core idea is not to let the agent rush into editing files. For large tasks, it first creates a visible work structure. Then each step is completed and validated.
This design is useful for cross-file refactoring, project scaffolding and multi-module feature development.
Module 7: Dynamic Task Management
The seventh module decides when a formal Todo List is necessary.
For simple one-step tasks, the agent can execute directly. For complex tasks, it must create a structured checklist before modifying files.
The agent is also not allowed to conclude the task until every Todo item is complete and validated.
This prevents incomplete delivery. It also makes the workflow easier to audit from the developer’s perspective. The user can see what was planned, what was done and what still requires attention.
5. Tier Four: Tool Governance and Self-Verification
Module 8: Tool Usage Policy
The eighth module defines how TRAE SOLO should use IDE tools.
It includes several important rules.
First, the agent should not expose internal tool names in user-facing output. It should describe results in normal language.
Second, it should prefer purpose-built IDE tools over generic terminal commands. This improves compatibility across environments.
Third, read-only file scanning can run in parallel. This speeds up context collection.
Fourth, file editing tools must not run in parallel. Parallel writes can cause conflicts or corrupt source files.
Fifth, terminal commands should not run simultaneously. This avoids shell-level race conditions.
This distinction between parallel-safe read operations and serial-only write operations is a mature engineering design. Many simple AI coding tools do not make this distinction clearly.
Module 9: Mandatory Work Validation
The ninth module requires validation after code changes.
The agent must confirm that each implemented change works as expected. It can use unit tests, shell checks, static analysis or other suitable methods.
If the project has an existing test framework, the agent should use it. If frontend changes are involved, it should open a preview and inspect the rendered result when possible.
Most importantly, the agent should not deliver unvalidated code as if it were complete.
This is one of the biggest differences between TRAE SOLO and ordinary code-generation tools. Many AI tools produce snippets that still require full manual debugging. TRAE SOLO’s prompt makes validation part of the delivery contract.
6. Tier Five: Output Standardization
Module 10: Response Language Matching
The tenth module requires the agent to match the language of the latest user input.
If the user writes in Chinese, the response should be in Chinese. If the user writes in English, the response should be in English.
This rule applies to explanations, status updates and code comments where appropriate. It reduces friction for cross-lingual development teams.
Module 11: Code Reference Link Syntax
The eleventh module defines how the agent should reference source code locations.
The prompt requires clean Markdown links. It also requires exact line ranges when referring to specific code sections.
This matters in large repositories. Developers need to jump directly to the relevant file and line. Vague references such as “check the service file” are not enough.
The prompt also includes formatting examples to prevent inconsistent link generation during long sessions.
Module 12: Opening Preamble Rules
The twelfth module requires a short preamble before the agent starts an operation.
The preamble should be one or two concise sentences. It should explain what the agent is about to do.
For small edits, very short introductory lines are allowed. The tone should be collaborative and approachable, not robotic.
This improves user experience. The developer can understand the next action without reading a long plan every time.
Module 13: Final Answer Formatting Rules
The thirteenth module controls the final answer style.
It avoids deeply nested bullet structures. It forbids raw ANSI escape sequences. It asks the agent to separate unrelated points instead of packing too much into one line.
The final response should be concise but complete. It should tell the user what changed, how it was validated and what still needs attention.
This makes the output easier to scan inside an IDE.
7. Tier Six: Persistent Core Memory Management
The last five modules define TRAE SOLO’s long-term memory system. This is designed to solve a common problem in LLM-based development tools: finite context windows.
A normal chat model forgets project details once the conversation grows too long. TRAE SOLO uses structured memory to preserve reusable project knowledge across sessions.
Module 14: Core Memory Activation
The fourteenth module tells the agent to capture reusable project knowledge into persistent memory.
This includes stable architecture rules, technical decisions and recurring troubleshooting patterns.
The goal is to avoid repeated explanations. If the agent already knows the project’s conventions, future tasks become faster and more consistent.
Module 15: Memory Whitelist
The fifteenth module defines what can be stored.
Only six categories are allowed:
- Stable repository facts and project specifications.
- Technical stack choices and the reasons behind them.
- Reusable diagnostic workflows.
- Project architecture patterns and module division rules.
- User coding preferences shown across repeated interactions.
- General bug-avoidance principles for the project’s technology stack.
This whitelist keeps memory focused on reusable knowledge.
Module 16: Memory Blacklist
The sixteenth module defines what must not be stored.
Temporary Todo List progress should not enter long-term memory. It belongs to the current task workflow.
One-off reflective notes should also be excluded if they have no future reuse value.
This prevents memory pollution. Long-term memory should not become a dump of every conversation detail.
Module 17: Memory Maintenance Rules
The seventeenth module defines how memory should be updated.
New critical project facts should be synchronized into memory. Conflicting or outdated records should be updated.
The prompt also forbids storing raw code blocks, full directory trees, long URLs and line numbers. These details are too fragile. They may become outdated quickly.
When two memory entries describe similar knowledge, the agent should merge them instead of creating duplicates.
This keeps memory compact and useful.
Module 18: Memory Citation Syntax
The eighteenth module defines how memory references should appear.
When the agent uses stored core memory, it adds a standardized <mccoremem> tag to the relevant statement.
The prompt also requires memory lookup before repeated investigative work. This reduces unnecessary file scanning and speeds up recurring tasks.
8. Advantages Over Conventional AI Coding Assistants
8.1 Less Dependence on Constant User Approval
Many AI coding assistants work in a reactive mode. They wait for explicit instructions and ask for confirmation too often.
TRAE SOLO uses a more autonomous workflow. It can inspect context, plan the task, make changes and validate them before asking for final review.
This does not remove human oversight. It changes where human review happens. Instead of approving every small step, the developer reviews the completed and validated result.
8.2 Long-Term Project Knowledge
Most coding assistants lose context when the conversation becomes too long. Developers then need to repeat project rules, architecture choices and past decisions.
TRAE SOLO’s memory system reduces this problem. It stores only reusable project knowledge. It excludes temporary task progress and one-off details.
This makes the agent behave more like a long-term teammate who gradually understands the repository.
8.3 Better Support for Complex Repository Work
Simple code generators are strongest at single-file edits. They struggle with multi-file refactoring and full-project scaffolding.
TRAE SOLO’s task orchestration system is designed for larger workflows. It separates planning, execution and validation. It also allows parallel reading while keeping writes serial and safe.
This structure is closer to how real engineering teams handle complex changes.
8.4 Built-In Self-Verification
Many AI coding tools still deliver untested code. Developers must find the bugs afterward.
TRAE SOLO’s prompt makes validation mandatory. The agent should run tests, static checks or previews before delivery.
This reduces broken output. It also makes the agent more reliable for production-style development work.
9. Practical Takeaways for LLM Agent Prompt Engineering
TRAE SOLO’s 18-part prompt offers several useful lessons for teams building autonomous coding agents.
First, prompt logic should be modular. Identity, autonomy, tool usage, validation, output format and memory should be separated. This makes the prompt easier to maintain.
Second, autonomy must come with guardrails. An agent should be able to act, but it must also validate its work. It should avoid unsafe parallel writes. It should not store irrelevant memory.
Third, memory should be curated. A useful memory system needs both a whitelist and a blacklist. It should preserve stable project knowledge, not every temporary task detail.
Fourth, model access should remain flexible during agent development. Teams may want to test the same prompt architecture across Gemini, Claude, GPT or other coding models. In this stage, Treerouter can serve as a unified API access layer. It helps centralize model endpoints, API keys and request formats, so developers can switch models with less integration work while keeping the agent workflow itself stable.
This point is important for real engineering teams. Agent behavior is shaped by both prompt design and model capability. A clean access layer makes comparison easier. It also reduces repeated integration overhead during model selection.
The larger lesson is clear. High-quality agent behavior does not come from a one-sentence role prompt. It requires structured instruction design, safe tool governance, validation rules and a controlled memory system.
10. Conclusion
TRAE SOLO’s 18-section system prompt provides a useful blueprint for autonomous pair-programming agents inside IDEs.
It addresses three common weaknesses of standard AI coding assistants: frequent approval interruptions, short-term context loss and unvalidated code output.
Each module has a clear function. Some define identity and output style. Some control autonomy and task planning. Others define tool execution, validation, multilingual output and persistent memory.
The most important design idea is balance. The agent receives enough autonomy to complete real development tasks, but it is also constrained by safety rules. It can modify code, but it must validate the result. It can remember project knowledge, but it must avoid storing temporary noise. It can use tools, but it must avoid unsafe parallel writes.
For developers and AI engineering teams, this prompt stack shows how production-grade agentic IDE systems can be built. The goal is not to create a chatbot that writes code snippets. The goal is to create an AI collaborator that can understand the project, plan work, make changes, verify results and still leave final control to the human developer.
