Skip to main content

​
1. Install the platform skills

The skills teach the platform model and safe search-plan-apply-verify workflow. They do not carry a credential or grant extra authority.

​
2. Authorize the CLI

The browser OAuth flow binds the grant to the selected organization, cli audience, exact public operation ids, approving user, and a member/admin role ceiling. A human must review and approve it. For CI, request a separate organization API key rather than copying the local refresh token.

​
3. Ship the repository

Inspect the generated korve.toml, plan, detected repository/ref, runtime class, and pricing before confirming. init applies, writes .korve.toml, deploys, and follows the build. It never overwrites a different existing manifest or project link.

​
4. Verify instead of assuming

For a failure or cross-resource question, create a project operator thread. The operator can investigate with typed read tools, but mutations remain version-bound pending actions that only a signed-in human can decide.

​
5. Bound ongoing work

  • Declare infrastructure in the manifest and plan before apply.
  • Configure app sharing only after enforcement reports ready.
  • Set a project hard-stop budget.
  • Configure maintenance with narrow categories, environments, operation allowlists, and action caps.
  • Treat secrets and one-time tokens as write-only. Never put them in prompts, logs, manifests, or shell arguments that enter history.
  • Read current state before creates; stop on auth, RBAC, billing, validation, and not-found errors.

​
MCP

MCP exposes search and execute. Search the live contract before every unfamiliar operation, then use only the declared method/path/body through korve.request. An OAuth-capable first-party MCP client uses its own mcp-audience grant; do not reuse a CLI token. See MCP Code Mode.