Prefer the CLI: an Agent Configures, It Does Not Instruct

Prefer an approved API or CLI when it provides reproducible inputs, scoped permissions and inspectable results. UI operations can also be verified; CLI commands can fail silently or target the wrong resource. Tool choice does not supply authority to change repository settings or publish a site.

For each operational change, identify the exact account/project/environment, inspect current state, obtain required authorization, apply the bounded change and read back its effect. Retain redacted evidence and a recovery plan. A successful exit is not proof of intended state.

Cloudflare Pages example. Read the selected project through Cloudflare’s own GET /accounts/{account_id}/pages/projects/{project_name} API and inspect production_branch; gh api addresses GitHub and is the wrong client for that route. Use authorized read access without logging credentials or unrelated configuration. After authorized deployment, verify the intended production host and changed content—not only a preview URL or HTTP 200. Cloudflare project API.

GitHub example. Review the proposed policy and actual check names before applying rules. Read-only assessment and write authorization are separate. scripts/check-repo-config.sh assesses a supported subset against explicit policy; it neither creates rules nor grants permission to do so.

Keep provider recipes versioned and tested. When a step requires human interaction, record and verify the outcome rather than treating the lack of a CLI as the lack of a control.

---