> For the complete documentation index, see [llms.txt](https://studio-docs.sandbox.game/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://studio-docs.sandbox.game/working-with-ai-agents/working-feature-by-feature.md).
# Working feature by feature
## Opening: The Problem or Principle
AI-assisted development works best when each request has a clear feature boundary. Building feature by feature keeps the work small enough to understand, test, and correct before it spreads through the project.
In Sandbox Studio, a feature is not every idea connected to a system. It is one player-facing result that can be built, checked, and improved before the next result begins.
## The Core Explanation
### A Feature Has a Clear Outcome
A useful feature describes what changes for the player or creator. “Add combat” is too broad. “Let the player fire one projectile by pressing the left mouse button that then damages our enemy” is a feature because it has a visible result and a clear success condition.
This outcome gives the AI a boundary. It can focus on the node, input, asset, or UI needed for that result instead of redesigning nearby systems.
When the outcome is clear, review becomes easier. You can test whether the feature works instead of judging whether a large collection of changes feels finished.
### Feature Boundaries Prevent Drift
Drift happens when one request turns into several hidden requests. A pickup feature becomes inventory storage, then UI, then crafting, then save data. Each addition may be useful, but together they make the work harder to inspect.
Keep the first version narrow. Build the pickup. Confirm it works. Then decide whether inventory, UI, or persistence should be the next feature.
This does not slow the project down. It creates checkpoints where you can keep what works, fix what does not, and choose the next step with better information.
### Each Feature Should Be Testable
A feature is ready to build when you know how you will check it. The test does not need to be formal, but it should be specific.
For example, “When the player walks over the coin, the coin disappears and the score increases by one” is testable. “Improve collectibles” is not testable until the expected behavior is named.
Testing each feature before moving on protects later work. If the score display is wrong after the inventory feature is added, you know the coin pickup worked before that change and can narrow the problem faster.
### AI Needs One Main Job at a Time
AI can handle complex tasks, but it performs better when the current job is specific. A focused request helps it choose relevant files, avoid unrelated edits, and explain the result clearly.
A good feature request includes the goal, current behavior, desired behavior, relevant context, and limits. If the feature touches multiple systems, ask for a plan first and approve the slice before implementation.
{% hint style="info" %}
*NOTE: If a feature requires several parts to make sense, separate the work into ordered slices. For example: input first, then gameplay behavior, then UI feedback, then polish.*
{% endhint %}
### Finish the Loop Before Starting the Next Feature
A feature loop includes planning, building, checking, and deciding what comes next. Skipping the check step makes later problems harder to diagnose.
Before moving on, confirm the feature does what the plan said it should do. Check the editor behavior, read the changed code or document, and note any follow-up work.
Follow-up work should become its own feature or bug fix. This keeps the current feature complete and keeps the next request clean.
## Practical Guidance
* Name the player-facing or creator-facing outcome before asking for implementation.
* Keep the first version of a feature small enough to test in one pass.
* State what is included in the feature and what is outside the scope.
* Ask for a plan when the feature touches more than one system.
* Build one complete slice before adding polish or extra behavior.
* Check the feature in the editor before moving to the next request.
* Turn follow-up ideas into separate feature requests.
* Restate context when the feature changes direction.
## Common Mistakes
| Mistake | What to do instead |
| -------------------------------------------------- | ----------------------------------------------------------- |
| Calling a broad system a single feature | Define one visible result that can be built and checked. |
| Adding polish before the basic behavior works | Build the smallest complete version first, then improve it. |
| Letting follow-up ideas expand the current request | Capture follow-ups and turn them into separate requests. |
| Moving on without testing the feature | Check the result before starting the next feature. |
| Asking the AI to fix everything at once | Give the AI one main job and clear limits. |
## The Takeaway
Working feature by feature keeps AI-assisted development clear and controllable. Build one useful result, check it, then choose the next feature from a stable place.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://studio-docs.sandbox.game/working-with-ai-agents/working-feature-by-feature.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.