Agent Usage Patterns

Basic Flow

Using All Agents:

1. Plan (with the Project agent)
2. Review the existing codebase (with the Broad Review agent)
3. Implement changes (using various sub-agents)

Adding A New Feature (using only sub-agents):

1. Consider data storage (use the Storage agent and ask for changes to the database schema)
2. Design the UI (use the Page agent and ask for HTML and CSS only, keeping in mind global styling)
3. Consider reusable functions (use the Operations agent and ask for new or about existing functions)
4. Make the UI work (use the Page agent and ask for frontend and routing JS)

Situations

Goal-Driven Development

When working with a broad goal, it can be beneficial to reflect and do background research before building features.

Note: The project agent's role is to help organise your thoughts and identify gaps. It's role is not to answer what you should do. Instead, when it provides a question, you need to read up on online resources (and critically think about what would work best for you).

What you have:

• A vauge goal or desired outcome.

What you do:

1. Start a new project
2. Clearly explain your goal (and provide relevant context on your situation)
3. Prompt further to answer questions (and do external reading to aswer questions well)
4. Use relevant coding agents to implement (once clear practical steps are established)

Targeted Development

When working within a limited scope, it is best to prompt specialised agents directly.

Note: The sub-agents' roles are not to tell you what to build, instead you provide the intent (in a pricise technical way) and they help deliver it efficiently.

What you have:

• The ID/s of the code you want to work with
• A clear description of what you want to do

What you do:

1. Start a sub-agent specific chat
2. Provide the target IDs and the clear description
3. (where applicable) Prompt further to refine the output
4. (after reviewing) Copy over code

Codebase Scanning

When cleaning codebases, an agent scan can help identify code snippets to work on.

Extra: For larger codebases, it is recommended to limit reviews to a specific web app and one code category of that web app.

What you have:

• A clear check that needs to be applied to multiple files

What you do:

1. Start a broad review specific chat
2. Specify the scope and check to run
3. (where applicable) Use sub-agents to implement changes

Feature Developmemnt

When doing standardised work where precision won't really deliver any different results, speed can be convenient.

Note: While it is possible to 'feature farm' a whole application, it is recommended to limit usage of this capability.

What you have:

• A straighforward feature that needs to be built

What you do:

1. Start a broad review specific chat
2. Specify the feature and ask for storage and page related changes
3. (where applicable) Prompt further to refine the output
4. (after reviewing) Copy over code

Notes on Agents

Project Agent

Scope Limitation: The project agent should not replace clear strategy documents or project plans. Those should be stored separately. Instead it helps with otherwise chaotic brainstorming.

Context Given: The project agent does not have access to your codebase. The purpose of this is to allow each session to start with a 'fresh slate'. This helps avoid the agent from following the same though process each time (which can limit creativity).

Broad Review Agent

Capabilities: The Broad Review agent has the ability to prompt sub-agents. It also has context on what chnages where made since the last deployment.

Sub-Agents

About: Sub agents include all agents other than the project agent and broad review agent.

Design Choices

Why prompt?

By choosing what prompt to use developers need to critically think about how they are using agents. This helps avoid mental atrophy (by staying actively engaged in the process and understanding what's going on) and allows developers to use agents to their full capabilities (rather than being limited to a few choosen workflows).

Why copy over code?

Copying over code is minimal effort for developers who are already reviewing the code. Furthermore, it acts as a break to prevent code 'runaway' (where excess code is written that becomes technical debt). This encourages developers to think about features and build with a focus on what matters.