THE PLANNING LAYER FOR AI BUILDING
Your AI is a brilliant builder and a terrible project manager.
Spellflow turns a rough idea into an ordered build plan where every step is a prompt worth pasting. Works with Cursor, Claude Code, ChatGPT, whatever you already build in.
Implement email + password auth in the existing Next.js app using the `users` table from step 01. Context: sessions are server-side, stored in `sessions` (id, user_id, expires_at). No third-party auth provider. Constraints: - Hash with argon2id, never store plaintext. - Session cookie: httpOnly, secure, sameSite=lax. - Do not modify the schema from step 01. Done when: a new user can sign up, log out, log back in, and `/dashboard` redirects to `/login` when the session is missing or expired.
SOUND FAMILIAR
It's message 40 and you've lost the plot.
The build started well. Then the AI rewrote your auth for the third time, added files you didn't ask for, and quietly forgot the decision you made an hour ago. You're not stuck because the model is bad. You're stuck because nobody wrote the plan, so every message starts from scratch.
HOW IT WORKS
Describe it. Plan it. Build it.
01 / DESCRIBE
Paste the idea in plain words. Messy is fine. That's the input it's designed for.
02 / PLAN
You get an ordered, editable build plan. Right steps, right order, dependencies where they belong.
03 / BUILD
Each step becomes a prompt with context, constraints, and a definition of done. Copy it. Paste it. Move to the next one.
Add streak calculation to the habit tracker. Context: habits and check-ins already exist from step 03. A check-in row is (habit_id, user_id, local_date). Users set a timezone at signup; it is stored on `users.tz` as an IANA string. Task: compute, for each habit, the current streak and the longest streak, as of the user's local "today". Constraints: - All streak math runs in the user's timezone, not UTC. A check-in at 23:50 local counts for that local day. - A missed day breaks the current streak. Today not yet checked in does not break it. - Pure functions in `lib/streaks.ts`, no database calls inside them — pass the check-in rows in. - Do not change the check-in schema or the step 03 API. Done when: `lib/streaks.ts` exports `currentStreak()` and `longestStreak()`, both covered by tests for a normal run, a gap, a same-day double check-in, and a user in UTC+13 crossing midnight.
THE OBVIOUS QUESTION
“Can't I just ask Claude for a plan?”
You can, and you'll get a list. What you won't get is the same plan twice, an editable structure you can revise mid-build, or steps written as prompts strong enough to hand straight to a coding agent. Spellflow does one job and does it the same way every time, so the plan survives longer than the chat window.
BRING YOUR OWN KEY
Your key. This session only. Never stored.
Connect a key from OpenAI, Anthropic, Gemini, or NVIDIA. It is held in memory for the session, sent only to run your request, and never stored or logged. No credits, no per-plan limits.
THE OUTPUT
Read one before you trust one.
This is the actual output, not a mockup.
Set up a new Next.js (App Router) project with TypeScript, Tailwind, and Drizzle against Postgres. Define three tables and nothing else: - users (id, email unique, password_hash, tz, created_at) - habits (id, user_id, name, created_at, archived_at null) - check_ins (id, habit_id, user_id, local_date, created_at) with a unique constraint on (habit_id, local_date). Constraints: - No auth, no UI beyond a placeholder `/` page. Later steps own those. - Migrations checked in, not generated at runtime. Done when: `pnpm db:migrate` creates all three tables on a clean database and `pnpm dev` boots without errors.
Build habit management and the daily check-in action. Context: authenticated sessions exist from step 02. Every query must be scoped to the session user — never trust an id from the client alone. Task: - Server actions: createHabit, renameHabit, archiveHabit, toggleCheckIn(habitId, localDate). - toggleCheckIn is idempotent: calling it twice for the same local_date leaves the row absent. - Archived habits stay in the database and disappear from the active list. Constraints: - No new tables. Use the unique constraint from step 01 to enforce one check-in per habit per day. - No streak logic here — step 04 owns it. Done when: a logged-in user can create three habits, check one in twice (ending unchecked), archive another, and a second user sees none of them.
Give the model something worth building from.
Free to start. No signup for the prompt tool. Bring your own key: held for this session, never stored, no credits spent.
Start free