> For the complete documentation index, see [llms.txt](https://docs.paradime.io/app-help/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.paradime.io/app-help/products/bolt/creating-schedules/schedules-as-code/editing-yaml-schedules-from-the-paradime-ui.md).

# Editing YAML Schedules from the Paradime UI

You don't have to leave Paradime to edit your schedule YAML. The Bolt YAML editor lets you open every schedule file in your connected Git repository, edit it inline, and commit the changes — all in one place.

This works for both layouts:

* The modular `.bolt/` folder
* The legacy flat `paradime_schedules.yml` file

***

#### What the editor shows

The editor automatically detects which layout your repository uses:

* **`.bolt/` folder layout** — the editor shows a file tree of every `.yaml`/`.yml` file under `.bolt/`. You can open any of them in the editor, create new files, rename them, or delete them. If a flat `paradime_schedules.yml` also exists, it appears alongside.
* **Flat layout** — the editor shows the single `paradime_schedules.yml` file.
* **Nothing configured yet** — the editor offers to create your first schedule file.

***

#### Source branch

The editor reads file contents from the same branch that Paradime uses to deploy schedules:

* By default, your repository's **default branch** (usually `main` or `master`).
* If a custom schedule deployment branch is configured, that branch is used instead.

When you save, you choose the target branch to commit to. You can:

* Commit directly to the deployment branch (fast path, no review).
* Commit to a feature branch and open a Pull Request back to the deployment branch (recommended for teams).

The editor can open a PR for you in the same flow as the save.

***

#### Atomic multi-file commits

When you save changes, **all edited files are committed as a single Git commit**. This matters most for the modular layout:

* If you rename a schedule and need to update two files (the definition file and a downstream `schedule_trigger` reference), both changes land in one commit.
* If a commit fails partway through (e.g. a permissions issue), no file is updated — your branch is never left in a half-saved state.
* The commit shows up in your Git history as a normal commit attributed to your Paradime user.

***

#### What you can do

| Action                | Folder layout   | Flat layout                  |
| --------------------- | --------------- | ---------------------------- |
| Edit an existing file | ✅               | ✅                            |
| Create a new file     | ✅               | — (only one file is allowed) |
| Delete a file         | ✅               | ✅                            |
| Rename a file         | ✅               | —                            |
| Commit message        | Custom per save | Custom per save              |

***

#### After saving

Saving from the UI creates a Git commit, but does **not** trigger a redeploy on its own. Once your changes land on the deployment branch (either directly, or via a merged PR), schedules are picked up on the regular cadence:

* **Automatic Refresh**: every 10 minutes.
* **Manual Refresh**: click **Parse Schedules** in Bolt.

{% hint style="info" %}
💡 **Note**: If you committed to a feature branch, Paradime won't see the changes until the PR is merged into the deployment branch.
{% endhint %}


---

# 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.paradime.io/app-help/products/bolt/creating-schedules/schedules-as-code/editing-yaml-schedules-from-the-paradime-ui.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.