Three prompts. Three apps. Zero infrastructure.

You will build ChurnGuard, a customer retention app, by describing what you want to Cortex Code Desktop. Each iteration adds one prompt and one kind of app:

Snowflake App Runtime runs the app on Snowflake as an APPLICATION SERVICE. You don't build Docker images, manage a registry, or set up a pipeline. One command deploys it.

Each iteration ends with a working app. Session leaders can stop after any of them.

Each iteration uses an Intent-Driven Development (IDD) prompt. It tells Cortex Code what you want, not how to build it:

The three iterations map to the three kinds of app Snowflake App Runtime is built for:

You probably have Git and Node.js already. The table lists every tool so you can check versions. psql and the Cortex Code CLI are optional:

If you want to try the MCP server in iteration 3, install the Cortex Code CLI:

Check the required tools. Snowflake CLI must be 3.26.0 or later and Node.js 20 or later:

The repo holds the setup scripts and the prompt for each iteration:

Add a quickstart connection and test it:

The command writes the connection to your Snowflake config file. Replace your_account and your_user with your values. Cortex Code Desktop and the Cortex Code CLI read the same file.

Run the three setup scripts in order:

What each one does:

Check the tables:

Expect about 30,000 rows in CHURN_METRICS and 12 rows (one per month) in CHURN_TRENDS. TPC-DS is a benchmark dataset, so its dates come from the early 2000s rather than this year.

Create your own working branch, my-app, from the iteration 1 branch:

The branch includes AGENTS.md, which tells Cortex Code your connection, role, database, and conventions. Cortex Code reads it automatically.

Set the default connection and role. The branch also includes .env.example, which makes quickstart your default connection and SFQUICKSTART_CHURNGUARD_ROLE its role. Load it now that grants.sql has created the role:

Set the connection's default role and warehouse. snow app deploy uses the connection's default role, not --role or .env, so set it in your Snowflake config file (~/.snowflake/connections.toml). Add these two lines to the [quickstart] block, or update them if they're already there:

The setup scripts still switch to ACCOUNTADMIN themselves, so you can rerun grants.sql later without changing anything.

Snowflake CLI commands, the Cortex Code CLI, and npm run dev started from this terminal now use that connection and role. The files hold no secrets, and the repo's .gitignore keeps .env and .envrc out of your commits.

Open the repo directory in Cortex Code Desktop. Your account name should appear in the status bar.

How your app carries over. Cortex Code generates the app in churnguard/ on your my-app branch. Each iteration branch adds only that iteration's prompts and scripts, so at the start of the next iteration you commit your app and merge the next branch in. Edit only files in churnguard/ and every merge stays conflict-free.

See the risk. Explore the why.

A static report shows you numbers. An explorer lets you ask why. In this iteration one prompt builds a churn dashboard you can pivot and drill into, and deploys it.

Open the prompt file 01-build-explorer.md and paste it into Cortex Code Desktop. Here it is in full, so you can see how an IDD prompt is put together:

How the prompt is built:

The prompt never names a framework, a chart library, or a file. Those choices are left to Cortex Code. The later prompts follow the same structure.

The build and deploy take a few minutes, so follow along in the chat. Cortex Code generates code with an LLM, so layout, chart styles, and colors vary between runs; your app will do the same things as the screenshots but may not look identical.

AGENTS.md tells Cortex Code where to deploy, so it works through the whole lifecycle:

1. Scaffold. Cortex Code copies the Next.js App Runtime starter and runs npm install.

2. Manifest and code. It runs snow app setup to generate the app.yml manifest, then writes:

3. Deploy. Cortex Code runs snow app deploy, watches the build, and gives you the App URL once the service is RUNNING.

Open the App URL. Click a segment in the churn-risk chart to filter the customer table, then switch the pivot to another dimension.

The URL stays the same when you redeploy. The service upgrades in place, with no downtime.

Checkpoint: the dashboard filters by segment and pivots by dimension. You're ready for iteration 2.

Start the dev server from churnguard/, then open http://localhost:3000. It connects to Snowflake with your CLI credentials.

Open app.yml in your project root. snow app setup (Snowflake CLI 3.26.0+) generates it, and every App Runtime app uses it as its manifest. Cortex Code runs snow app setup for you; run it yourself only when you bring existing app code.

For every field, see the app.yml reference.

Each snow app deploy applies the whole manifest. Iteration 2 adds secrets and external_access_integrations so the app can reach Snowflake Postgres. Otherwise only the app code changes.

Turn insight into action.

A dashboard tells you who is at risk. It doesn't help you do anything about it. In this iteration ChurnGuard becomes a workflow app: teams flag customers, assign retention actions, and track them to resolution.

The app reads and writes actions only in Snowflake Postgres, so the Action Board always shows the latest state. In Snowflake, data mirroring, a dynamic table, and an alert run separately. The only thing the app reads from that pipeline is the NOTIFICATIONS table.

Commit your iteration 1 work if you haven't already, then merge in iteration 2:

Step 1 — Rerun grants. This adds the Postgres, External Access Integration, mirroring, and alert privileges:

Step 2 — Create the Postgres instance and data mirror. Find your public IP address first (for example at ifconfig.me); the prompt asks for it so psql can create the table. Then open the prompt file 02-postgres-setup.md and paste it into Cortex Code Desktop. It uses the /snowflake-postgres skill to:

Step 3 — Create the dynamic table, notifications table, and alert:

This creates the ACTION_SUMMARY dynamic table, which reads the mirrored $live view, plus the NOTIFICATIONS table and ESCALATION_ALERT.

Open the prompt file 02-add-workflow.md and paste it into Cortex Code Desktop. It asks for an Action Board, writes to Postgres with parameterized queries, and toast notifications driven by a Snowflake alert.

Cortex Code changes the existing app. It doesn't start over.

1. Postgres connection. A lib/postgres.ts module opens a connection pool with credentials from the Snowflake secrets that app.yml mounts. The connection uses SSL, which Snowflake Postgres requires.

2. Write routes. New API routes insert and update actions with parameterized queries:

The action list and its KPI cards read from Postgres too, so a new action shows up the moment you save it. A customer can have only one open action: flagging them again shows already flagged instead of creating a duplicate.

3. Mirroring. Postgres changes replicate to Snowflake automatically. ACTION_SUMMARY reads the mirrored $live view. The app never queries it.

4. Notifications. ESCALATION_ALERT runs every minute. When the dynamic table shows open escalations, it writes a row to NOTIFICATIONS. The app polls that table and shows a toast. No email or webhook needed.

5. Manifest. app.yml gains secrets for the Postgres credentials and host, and external_access_integrations for network access to Postgres.

6. Redeploy. The app upgrades in place at the same URL.

Compare app.yml with the iteration 1 version. Cortex Code added two blocks:

The install, build, run, and ignore fields don't change. Adding these two blocks is all the app needs to reach Postgres.

Open the app and run through the workflow:

1. Find a high-risk customer in the customer table.
2. Click Flag and choose Escalate as the action type.
3. Open the Action Board. The new action and its KPI cards appear right away, because both read from Postgres.
4. Click the status badge to move it from New to In Progress to Resolved.
5. Wait 1–2 minutes while the data mirrors, the dynamic table refreshes, and the alert runs.
6. A toast appears for the escalation. Dismiss it.

Checkpoint: you can flag a customer, move the action through its statuses, and see an escalation toast. You're ready for iteration 3.

Ask your data. Get a next step.

In this iteration ChurnGuard gets an agent. You ask a question from any page, and a Cortex Agent explores the data, explains what it finds, and recommends what to do. Overnight, a serverless task stages recommendations, so proposals wait for you in the morning. An MCP server lets other agents, such as the Cortex Code CLI, use ChurnGuard without opening a browser.

AI proposes. You approve. Three design choices keep a person in control:

Commit your iteration 2 work if you haven't already, then merge in iteration 3:

Step 1 — Rerun grants. This adds the privileges for the agent, the staging procedure, and the task:

Step 2 — Create the playbook, recommendations view, proposals table, staging procedure, and daily task:

The setup also runs the task once, so proposals are ready right away. See iteration-3-setup.sql for the full SQL.

The playbook starts with five rules:

Iteration 3 uses two prompts, like iteration 2.

1. Semantic view and agent. Open the prompt file 03-agent-setup.md and paste it into Cortex Code Desktop. It uses /agent-studio to create the CHURNGUARD_SV semantic view and the CHURNGUARD_AGENT agent, then tests the agent.

2. Agent in the app. Open the prompt file 03-add-agent.md and paste it into Cortex Code Desktop. It uses /snowflake-apps to add the chat drawer, the Agent Suggested tab, the approve flow, and the MCP server, then redeploys.

In Snowflake

1. Semantic view. CHURNGUARD_SV covers CHURN_METRICS, CHURN_TRENDS, CUSTOMER_RECOMMENDATIONS, ACTION_SUMMARY, and NOTIFICATIONS, with synonyms and verified queries. The agent can answer questions such as "which high-risk customers have no open action?"

2. Cortex Agent. CHURNGUARD_AGENT has:

3. Daily proposals. AGENT_SUGGESTION_TASK runs at 08:00 UTC. It stages up to 20 proposals, highest risk and spend first, for customers with no open action and no pending proposal.

In the app

4. Chat in the app. Open the chat drawer from the header or with Cmd+K. The conversation stays open as you move between pages. Each screen also offers a shortcut that carries its context:

An empty drawer suggests prompts for the current page.

5. Streaming answers. An API route streams the agent:run REST API. An answer takes about 30 seconds, so the chat shows a thinking indicator, then each tool call, then the answer with tables and charts. When the agent stages proposals, the chat shows how many and links to the Agent Suggested tab.

6. Agent Suggested tab. The Action Board gains a tab of pending proposals. Each card shows the customer, the action, and the playbook rule behind it. Approve writes the action to Postgres, Dismiss drops it, and Approve All handles every pending proposal. A badge shows how many are waiting. If a customer already has an open action, approving dismisses the proposal and tells you how many were skipped.

7. Threads. The app reuses one agent thread per conversation, so follow-up questions keep their context.

8. MCP server. The app serves an MCP server at /api/mcp with four tools: flag_customer, list_actions, get_customer_risk, and get_churn_summary. Snowflake authenticates every request as your user. The Cortex Code CLI connects with your Snowflake connection, not an API key; other MCP clients are redirected to the Snowflake login page.

Open the app and try the agent:

1. Open the Action Board and switch to the Agent Suggested tab. You should see the proposals the setup staged.
2. Click Approve All. The actions move to the main Action Board.

3. Open the chat drawer with Cmd+K.
4. Ask: "Who are the top 5 high-risk customers by spend and what should we do?"
5. The agent returns a table of 5 customers, each with an action and the playbook rule behind it.

6. Ask: "Flag high-risk customers for retention." The agent calls stage_retention_actions, and new proposals appear on the Agent Suggested tab.
7. Ask: "Show me the monthly churn trend as a chart with readable labels." The agent answers with a chart.

8. On the dashboard, open a customer row and choose Ask about this customer. The agent explains that customer's risk and suggests a next step.

Verify the MCP server with the Cortex Code CLI. Add the server and start the CLI. Run this from the churnguard/ folder; snow app open --print-only prints your App URL, and the command adds /api/mcp to it. The --snowflake-connection flag signs each request in as your Snowflake user.

Then ask the CLI, one at a time (your results will differ):

Open the Action Board in your browser: the new action is at the top of All actions, and Open escalations goes up by one. Within about a minute, once the mirror syncs and the alert runs, an escalation toast appears on every page.

Checkpoint: the agent answers questions, stages proposals you can approve, and the MCP server works from the CLI. ChurnGuard is complete.

Use the queries below, or paste the error into Cortex Code Desktop and ask "Why am I seeing this?"

The checks, grouped by area:

A conflict means a file outside churnguard/ was edited. Keep the iteration branch's version:

Paste the error into Cortex Code Desktop and ask:

Cortex Code can run diagnostic queries in your account.

Run this when you're done, including any Build Your Own App prompts in the next section. It removes everything the guide created:

It drops:

The script ends by listing anything left over; every list should be empty.

Leave SNOWFLAKE_SAMPLE_DATA in place unless you're sure nothing else in your account uses it.

To clean up by hand:

If DROP_MIRROR fails, DROP POSTGRES INSTANCE fails too, because the mirror's catalog integration still references the instance. cleanup.sql shows the error and handles both leftovers; by hand, run DROP INTEGRATION IF EXISTS CHURNGUARD_MIRROR_CATALOG_INTEGRATION, and to drop the mirror database, first run GRANT OWNERSHIP ON DATABASE CHURNGUARD_MIRROR TO ROLE ACCOUNTADMIN (it's owned by the snowflake application).

To remove what the guide set up on your machine:

If you used psql, also remove the CHURNGUARD_PG entries from ~/.pgpass and ~/.pg_service.conf. Then set your connection's default role back to what it was: SFQUICKSTART_CHURNGUARD_ROLE no longer exists.

You built one app in three iterations, and each one added a kind of app:

Every iteration followed the same loop:

1. Describe the outcome in an IDD prompt.
2. Build: Cortex Code scaffolds or changes the app.
3. Deploy with snow app deploy to the same URL, with no downtime.
4. Verify in the browser.
5. Iterate with another prompt.

To compare your app with the reference, see the solution branch of the companion repo.

Keep going. Paste any of these prompts into Cortex Code Desktop and keep extending ChurnGuard. Each one follows the IDD structure, so edit the requirements to fit what you want.

User profiles and role-based views

Export at-risk customers

More ideas to write as IDD prompts in the same shape: