> For the complete documentation index, see [llms.txt](https://docs.buzzy.buzz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.buzzy.buzz/the-building-blocks/mcp/buzzy-builder-mcp/editing-existing-apps.md).

# Editing existing apps

Use Buzzy Builder MCP to help an agent inspect and change an app that already exists. This workflow is best for focused improvements, screen refinements, data-model adjustments, bug fixes, and follow-on features.

If you have not connected and bootstrapped your agent yet, start with [Getting Started with Builder MCP](/the-building-blocks/mcp/buzzy-builder-mcp/getting-started.md).

## Recommended Workflow

1. Connect the agent to Buzzy MCP and bootstrap the local repo if needed.
2. Identify the existing app by name, workspace URL, editor URL, or app ID.
3. Ask the agent to inspect the current app before changing anything.
4. Have the agent summarize the relevant data model, flows, blueprint, screens, and runtime behavior.
5. Review a short implementation plan for broad changes.
6. Apply changes in staged passes.
7. Verify the result in preview or runtime, using screenshots for visual changes.

## Good Editing Prompts

For inspection:

```
Connect to Buzzy MCP and inspect this existing app: [app name or URL]. Summarize the current data model, main screens, navigation, and anything that looks risky before making changes.
```

For a focused change:

```
Update the [screen or flow] so that [specific outcome]. Keep the change scoped to this behavior and verify it in preview before reporting back.
```

For broader product feedback:

```
Make a plan before editing. I want [screen or workflow] to change from [current issue] to [desired outcome]. Inspect the current app first, then propose the smallest staged set of changes.
```

## Review Gates

Use review gates when the change can affect multiple parts of the app:

* data model changes that may affect screens or sample data
* auth, public/private access, or user-owned content
* navigation, modal, or multi-screen workflow changes
* code-widget changes
* visual refinements across several screens

For small copy or layout fixes, it is reasonable for the agent to apply the change directly and then verify it.

## Verification

Ask the agent to verify the specific path that changed. For UI work, screenshots are usually the clearest proof. For data or permission-sensitive work, check both allowed and denied user states where relevant.

Avoid broad rewrites while editing an existing app. The safest MCP editing loop is: inspect, plan, change one coherent area, verify, then continue.


---

# 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://docs.buzzy.buzz/the-building-blocks/mcp/buzzy-builder-mcp/editing-existing-apps.md?ask=<question>&goal=<endgoal>
```

`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.