Use the existing deployment boundary
The skill describes the hosting API and its supported operations. Let the agent use that contract for project creation, configuration, deployment, logs, and recovery. Keep account authorization and allowed build modes as real boundaries rather than treating a shell command as permission to do everything.
Publish the intended source revision and retain the lockfile and build configuration where applicable. A live fix should also exist in the canonical source so subsequent deployments retain it.
Keep secrets and state where they belong
Configure build-time and runtime variables deliberately. Public frontend variables are not secrets. External databases, storage, and service accounts need their own setup and recovery plan, and their credentials should never be embedded in a public artifact.
Separate application deployment from schema changes and external state transitions. Restoring a previous frontend or runtime release does not reverse a database migration automatically.
Verify proportionally to the change
Use your project’s tests before release, then inspect the resulting deployment and the important live flows. For a failed build, identify the first relevant error. For a runtime regression, gather the app’s logs and the failing request context before changing unrelated code.
Static output is self-serve. If build.host must install dependencies, run build or start commands, use a Dockerfile, or keep a server running, the account needs executable deployment access.