Give your agent the brief below when you want your own Energon, even if you have not created a deployment repository or chosen hostnames yet. It starts from the repository’s installation instructions because the deployment procedure should stay with the code it installs. You can copy it unchanged; the agent gathers your choices as part of that procedure.

Deploy with an agent

Copy this brief

Help me deploy my own Energon from https://github.com/tmchow/energon.
Read and follow INSTALL.md. Create an independent private deployment
repository with upstream Git history if I do not have one yet.
Guide me through the choices, suggest sensible defaults, and handle
setup and verification.

The agent should begin with the upstream installation guide . Once it has your deployment repository checked out, that checkout’s INSTALL.md and linked references govern the commands it runs. If your deployment repository is older than the website, resolve the version difference before applying newer instructions. A first deploy leaves ENABLE_PRODUCTION_DEPLOY=false so Actions stays tests only.

New installations use one path: an independent private repository with Energon’s Git history, origin pointing to your repository, and upstream pointing to the public source. The agent creates and verifies the private destination before committing your settings. Credentials continue to live in secret stores; non-secret settings and custom code can stay in your private repository. A GitHub fork or template copy is not needed.

What to expect

The installation guide explains which choices are needed and recommends personal or team defaults. You do not need to research every variable before starting. Bring any preferences you already have, such as your Cloudflare account, allowed people, administrator, and hostnames. The agent should ask about missing choices before it creates resources.

For the deployment phases and reference map, see Deploy an Energon host. Configure Energon policy explains how retention, write ownership, and token lifetime affect an existing installation.

Updating an existing Energon

If you already run this Energon, tell the agent which deployment repository and deployment to update. Keep your existing account, hostnames, policy, and plugin identity unless you want to change them.

Help me update this Energon from the latest published upstream release.
Follow .agents/skills/update-from-upstream/SKILL.md if present, otherwise
INSTALL.md "Update an existing Energon". Do not use GitHub Sync fork.
Ask before landing on main if that might deploy.

If the checkout has update-from-upstream , ask the agent to follow that skill. Otherwise use Update an existing Energon  after merging the published release tag, not unreleased main.

An update should inspect and verify existing resources before proposing new ones. A working Access application with different names is not a reason to delete and recreate it. Ask before a merge to main when that push might migrate D1 and deploy. The Access reference  describes verification of existing applications; use the current checkout’s supported procedure. See Upgrade and recover for the Admin How to update path.

Human handoffs

Expect the agent to pause for the account access or connection approval it cannot complete itself. It should keep the work already done, explain the next handoff, and resume from that point. After deployment, Connect an agent explains the human side of the connection.

Browser upload checks may also need permission to choose local fixture files in the automation environment. If that permission is unavailable, record the staging check as untested or have the human perform it; successful API publishing does not verify browser staging.

Completion follows the installation guide’s verification criteria. Ask for the results and any unresolved steps, rather than treating a successful deploy command as proof that the whole installation works.