SLW / dev ← Guides & Rules
Guide · how to work

How to work

You work in the Claude desktop app: you describe what you want in plain English, it builds, and you review. Here's the day-to-day — plus a couple of habits that keep it smooth.

Getting into your project

You work through the Claude desktop app connected to your project's cloud workspace. Set it up once:

01

From the portal, pick a project

Open the Dev Portal and click Open in Claude Desktop on a project — it shows you the exact steps for that project.

02

Create your workspace & connect

Follow the steps: a quick command creates your private cloud workspace, and you add it to the Claude desktop app as a connection. One-time setup.

03

You're working

The app opens your project. From now on, it's just you and Claude.

The everyday loop

You talk to Claude in plain English, like giving instructions to a capable teammate. You never write code — you describe, review, and decide.

You"Add a button that marks an email as read."
ClaudeMakes the change and shows you.
You"Nice — make it blue, and can you show me the page?"
ClaudeAdjusts it and opens the app so you can see it live.

Want to see your change running? Just ask Claude to show you — it starts the app for you; you don't need to know any commands. Not sure how something works? Ask it to explain.

When you have a lot to do, use /capture

Two commands carry ideas from "thought" to "shipped." Reach for them especially when several things pile up.

/captureDrop an idea in. Claude shapes it — even a quick mockup — and lines it up in the backlog, ready to build.
/executeBuild a batch. Takes what's lined up and carries it all the way to done — designed, built, and shipped.
💡

Recommendation: when a bunch of ideas hit you at once, don't fire them off one by one — capture each one. It keeps them organized, makes sure each gets thought through and designed before it's built, and nothing gets lost. Then execute builds them in a tidy batch. A pile of ad-hoc "also do this" requests gets messy fast; capturing first avoids that.

How your work gets approved & goes live

You don't push anything live yourself. When a change is ready, it goes through a short, safe review:

01

Your work sits on a separate copy

It can't affect the live app or anyone else's work while you build.

02

You ask for it to be added

Claude opens a request for review — a "pull request," which just means "please add my change."

03

It's checked automatically

The system confirms the app still works before anything moves.

04

A teammate approves it

A second set of eyes signs off.

05

It goes live

Now it's in the real app.

The team tracks work on each app's project board — a simple Todo → In Progress → Done list. (Example: the LP Flow board.)

Because everyone works on a separate copy, many people can work at once without clashing. Some apps (Task Flow, Terminal) require a person to approve before anything ships. Anything touching real data or money — ask first, always.

When a change needs new data

Sometimes a feature needs to store something new — a new field on a form, a new list, a new kind of record. That's a database change, and you don't do anything special: describe what you need, and Claude adds it. It reaches the live app through the same safe review as any other change, and your practice data stays separate from real data the whole way.

One thing to know: adding new fields is routine. Changing or removing existing ones is handled more carefully — with a backup and approval — because real data is involved. Claude follows that rule for you.

🗄️

Want to see how it actually works under the hood? Changing the database → goes deeper — but you don't need it to get started.

Habits that help

← Start here — the five-minute overview.