Find the guide for a task

This page maps each task to the page that covers it, and says which to read first where two pages cover one task. Each guide opens with a prompt that starts its task, lists what your tool does and which platform tools it uses, and shows what a successful run looks like.

Each guide's Refusals section lists the refusals its task can receive. The Refusals page lists every refusal the platform returns.

Where a step fails or a response looks wrong, the Troubleshooting pages start from what you see: Setup, Deploys, Secrets, and Status and logs.

Tasks and their guides

Files or a database for a list of records

A list of records can be stored as a JSON file in a storage area or as rows in the database. Choose by how the application uses the list:

• A file suits a small list the application reads and writes whole, such as its settings or a scheduled handler's state. Each change rewrites the file with a conditional put, so one writer never silently overwrites another writer's change.
• The database suits a list that grows, that the application searches, sorts, or pages through, or that several requests change at once. Each record is a row, a change is one statement, and a query reads only the rows it needs.
• Files also suit content the application sends unchanged, such as images, uploads, and exports.

Store files covers the areas and the conditional put. Add a database covers the database, which the manifest declares and the migration files define.

How these actions usually happen

Every guide opens with a prompt you can give word for word. Usually, though, the action happens inside a larger prompt about your application, and your tool does the platform's part itself. For example, you say:

Let's let our web site visitors search our parts catalog.

Your tool plans the feature. It chooses the library's database package, declares the database service in the manifest, and resubmits the manifest. It takes the package into the project, writes the migrations and the search route, and deploys. Each of those steps has a guide listed on this page, and you wrote none of their prompts.

On a new application the deploy reaches production, so the feature reaches your users at once. Where you turned on a development environment, the deploy reaches development only, and the feature reaches the production hostname only after a promote. Read the guides to see what your tool did, to ask for one action on its own, and to check a step when something looks wrong.

The skills

A skill is a ready sequence of actions that the platform offers as a Model Context Protocol (MCP) prompt. A client that supports prompts may show each skill as a slash command. A client that lists no prompts reads a skill with read_context, id skill:<name>. The skills are store-key, delete-account, deploy, schedule, manifest-author, add-service, diagnose, release, move-existing-app, develop-then-promote, cost-review, add-library-entry, update-library, mobile-backend, and use-ai-allowance. A sixteenth, platform-admin, is offered only to platform staff. MCP resources and prompts lists each skill with the actions it uses.

A short skill is one page. A long skill has a first page with its steps and rules, and a page of the reasons behind the rules: deploy, mobile-backend, and schedule are long. The deploy skill also has a page for each case, such as an application with a database. On any skill, a few rules may say on their own line when they apply. Each first page lists the skill's other pages by id.