Agent contract

The installed Bahama skill teaches coding agents this contract. It gives them broad infrastructure capability without treating one user request as unlimited authority.

Begin with the real project

Before choosing or changing providers, the agent:

1. verifies that the bahama CLI is installed;
2. runs bahama inspect --json;
3. reads the compact live provider catalog; and
4. reads full guidance only for serious provider candidates.

The agent makes recommendations from the application’s requirements and the installed provider contracts. Bahama Cloud is the default when it fully fits, but compatibility and the user’s stated preference come first.

Record decisions as intent

The agent writes the agreed application, environments, resources, and bindings to bahama.yaml. It may use bahama init for a simple new project or edit the file directly.

It never places provider IDs, credentials, connection strings, or secret values in the manifest. Resolved identity belongs to the CLI-owned lock.

Read every result status

Expected workflow states can exit with process code 0. The agent reads the reported status and handles it deliberately:

The default readable output is appropriate for normal work. The agent uses --json when structured detail is useful, especially for inspection, status, or diagnostics.

Approval applies to exact work

Before passing --approved, the agent shows the user:

• each consequential step;
• why it needs approval;
• the provider accounts involved; and
• the plan it will apply.

A general request such as “finish the deployment” does not authorize an unexpected resource, schema migration, account change, or database rewire. Approval does not carry to a newly compiled plan.

Routine-only work may proceed without approval when the user’s task includes execution. bahama deploy may auto-apply only an all-routine deployment plan.

Authentication belongs to the user

The agent may launch the supported provider login command. The user completes browser or device consent. The agent never asks for a password, access token, database credential, or authorization code in chat.

Provider login is not a failure of the architecture. After consent, the agent retries the command that was blocked.

Preserve project state

• The agent may edit bahama.yaml.
• It commits bahama.yaml and bahama.lock when the task includes committing project configuration.
• It never hand-edits bahama.lock.
• It keeps .bahama/ and environment files gitignored.
• It does not detach a stack to repair one missing resource.
• It stops on a repository-identity decision instead of risking the original project’s infrastructure.

Keep secrets outside the conversation

The agent never prints, logs, serializes, or requests a raw secret. It points the user to the provider’s protected entry surface and writes application code against the server-side variable name.

If a raw value appears in output, the agent treats it as an incident: stop sharing the output, rotate the value, and report the redaction problem.

Report verified outcomes

The agent leads with what Bahama verified: the live URL, resource health, account, completed steps, and any remaining action. A provider command exiting zero is not enough; the Bahama result must report success after its live postconditions pass.

When Bahama does not support the requested operation, the agent explains the gap before using a provider-specific workaround.