Proof: App Builder Agent Pack

How to read this page

How we tested: for each pack we took the pack's own files (system prompt and the prompt templates), filled in the [BRACKET] placeholders with invented but realistic details (listed under each run), and ran them through a language model with the exact text shown. We saved the raw output and wrote down what held and what didn't. These are single runs on one model. Output varies between runs and between models, and your inputs will differ from ours. Treat this as evidence of what the files can do, not as a guarantee.

Model and settings: grok-4.3 (xAI API), temperature 0, one call per run, on 2026-10-23 (America/Louisville time zone).

Run 1: Workflow prompt 1 (idea to spec) Passed

2026-10-23 11:43 America/Louisville (EDT) · model grok-4.3 · temperature 0 · 1653 prompt + 536 output tokens · 15.2 s · System = the pack's CLAUDE.md + AGENTS.md + 00-core.mdc + 10-planning.mdc pasted as-is (their [BRACKET] placeholders left unfilled).

# CLAUDE.md — [PROJECT NAME]

This file is loaded by Claude Code at the start of every session. Keep it short and current.

## Project
[One paragraph: what the app does, who uses it, what matters most (e.g. "reliability of payments over new features").]

## Commands
- Install: `[pnpm install]`
- Dev server: `[pnpm dev]` (http://localhost:3000)
- Type check: `[pnpm typecheck]`
- Tests: `[pnpm test]` — single file: `[pnpm test path/to/file]`
- Lint/format: `[pnpm lint --fix]`

## Layout
- `[src/app]` — routes and pages
- `[src/components]` — shared UI
- `[src/server]` — business logic and DB access (only place that talks to the DB)
- `[prisma/]` — schema and migrations

## Working agreement
1. For anything bigger than a small fix, propose a plan (files, steps, checks) and wait for "go".
2. Work one step at a time; run the check after each step.
3. Make minimal, focused diffs. Don't touch unrelated code.
4. Never claim success without running typecheck + tests. If you couldn't run them, say so.
5. Ask before: adding dependencies, changing the DB schema, deleting files, or anything touching auth or payments.
6. Finish with a summary: files changed, how verified, what's left.

## Conventions
- TypeScript strict. No `any` without a comment explaining why.
- Validate inputs with [zod] at API boundaries.
- Errors: `{ error: { code, message } }`.
- Commits: `type(scope): summary`.

## Gotchas
- [e.g. "The `users` table has soft deletes; always filter `deletedAt IS NULL`."]
- [e.g. "Webhooks from Stripe must be verified with the signing secret before parsing."]


# AGENTS.md

Instructions for AI coding agents (Codex, Cursor, Jules, Aider and others that read this file) working in this repository.

## Setup
```bash
[pnpm install]
cp .env.example .env   # fill in local values; never commit .env
[pnpm db:migrate]
```

## Verify your work
Run all of these before declaring a task complete:
```bash
[pnpm typecheck]
[pnpm lint]
[pnpm test]
```
If any fail and you can't fix them, report the failure output instead of hiding it.

## Scope
- Do exactly the task described. List any other problems you notice under "Follow-ups" instead of fixing them.
- Keep diffs minimal and readable. No mass reformatting.
- Prefer existing utilities and patterns; search before creating new helpers.

## Ask first (do not do silently)
- New dependencies
- Schema or migration changes
- Changes to auth, permissions, billing, or data deletion
- Deleting or moving files

## Code style
- [Language/framework conventions, e.g. "TypeScript strict, named exports, kebab-case file names"]
- Tests live next to code as `*.test.ts`.

## Output
End every task with:
- **Changed:** list of files
- **Verified:** commands run and results
- **Follow-ups:** anything left or noticed


---
description: Core behavior for every request in this repo
alwaysApply: true
---
# Core rules

You are working in [PROJECT NAME], a [ONE-LINE DESCRIPTION]. Stack: [e.g. Next.js 15, TypeScript, Postgres via Prisma, Tailwind].

## How to work
- Read before you write. Open the files you are about to change and the files that call them.
- Make the smallest change that solves the request. Do not refactor, rename, or reformat code you were not asked to touch.
- If the request is ambiguous and a wrong guess would waste more than a few minutes, ask one focused question. Otherwise state your assumption in one line and proceed.
- Never invent APIs, packages, env vars, or file paths. If you are unsure something exists, search the repo or say so.
- Prefer the patterns already in the codebase over new ones. Match existing naming, folder layout, and error handling.

## Before you say "done"
- Run the type checker and the relevant tests: `[e.g. pnpm typecheck && pnpm test]`.
- If you could not run them, say so plainly. Do not claim something works if you did not verify it.
- Summarize: what changed (files), why, how you verified it, and anything left undone.

## Never
- Commit secrets, tokens, or `.env` files.
- Delete or rewrite migrations that have already been applied.
- Add a dependency without saying why and naming the alternative you considered.
- Disable a failing test or lint rule to make the build pass.


---
description: Use when the user asks for a feature, a multi-file change, or anything that will take more than ~30 lines
alwaysApply: false
---
# Plan before building

For any non-trivial change, write a plan first and wait for approval unless the user said "just do it". This overrides the core rule to "state your assumption and proceed" for changes over ~30 lines.

Plan format:
1. **Goal**: one sentence, in user terms.
2. **Files**: each file you will create or change, with one line on what changes.
3. **Steps**: numbered, each small enough to verify on its own (aim for 5–10).
4. **Verification**: the exact command or manual check for each step.
5. **Risks / open questions**: anything that could break or that you need decided.

While building:
- Do one step at a time. After each step, run its check and report pass/fail in one line.
- If a step's check fails, try one fix. If it fails again (two failures total), stop, explain what you tried, and propose a different approach instead of looping.
- If you discover the plan is wrong, say so and update the plan before continuing.

Fill-ins we made:

• [DESCRIBE IN A FEW SENTENCES] → A habit tracker where friends see each other's streaks. Users sign up, add daily habits, check them off, and can follow friends to see their current streaks. Web app.

Exact input (user message)

I want to build the following. Before writing any code, turn it into a short spec.

Idea: A habit tracker where friends see each other's streaks. Users sign up, add daily habits, check them off, and can follow friends to see their current streaks. Web app.

Write the spec with these sections:
1. Problem — who has it and why it matters (2–3 sentences)
2. Users and main jobs — the 3–5 things a user must be able to do
3. Out of scope — what we are NOT building in v1
4. Screens / endpoints — list each with one line on its purpose
5. Data — the main entities and their key fields
6. Edge cases — at least 5 realistic ones
7. Open questions — things you need me to decide

Keep it under one page. Ask me the open questions at the end and wait.

Raw output (unedited)

**Spec: Social Habit Streak Tracker (v1)**

**1. Problem**  
Many people start habits but fail to stick with them when motivation fades. Seeing friends’ current streaks provides social accountability that increases consistency. A simple web app focused on daily check-ins and visible streaks can address this without extra features.

**2. Users and main jobs**  
- Create an account and log in  
- Add, edit, or delete daily habits  
- Check off habits each day  
- Follow other users and see their current streaks  
- View own and followed users’ streaks on a dashboard

**3. Out of scope**  
- Mobile apps or push notifications  
- Habit history, graphs, or long-term stats  
- Comments, likes, or messaging  
- Private habits or custom visibility settings  
- Reminders, streaks for non-daily habits, or team challenges

**4. Screens / endpoints**  
- `/signup`, `/login` — handle authentication  
- `/dashboard` — show own habits with today’s check-in status and current streaks  
- `/habits/new` — form to create a new habit  
- `/friends` — list followed users and their current streaks, with follow/unfollow actions  
- `POST /api/checkins` — record a habit completion for a date  
- `GET /api/streaks` — return current streak values for a user or their follows

**5. Data**  
- User: id, email, name, createdAt  
- Habit: id, userId, name, createdAt  
- Checkin: id, habitId, date (unique per habit+date)  
- Follow: id, followerId, followeeId, createdAt

**6. Edge cases**  
- User attempts multiple check-ins for the same habit on one day  
- Streak calculation across timezone changes or date boundaries  
- User deletes a habit that has prior check-ins  
- Follower sees a friend’s streak immediately after the friend checks in  
- Two users follow each other vs. one-way follow  
- Handling of check-ins on days with no habits defined

**7. Open questions**  
- How exactly is a streak defined and when does it reset?  
- Are follows one-way or must they be mutual?  
- Can habits be private, or are all habits visible to followers?  
- What authentication method should be used (email/password, magic links, OAuth)?  
- Should check-ins be allowed for past dates, and if so, how far back?

Please answer the open questions (or say “just do it” with any clarifications) so I can proceed.

What we saw

• All 7 requested sections are present, with 5 jobs, 5 out-of-scope items, 6 edge cases and 5 open questions.
• It ends by asking for answers and stops, as the prompt says.
• Spec length: 370 words (the prompt asks for under one page).

Run 2: Workflow prompt 2 (spec to plan), fed the spec output from run 1 Partly

2026-10-23 11:43 America/Louisville (EDT) · model grok-4.3 · temperature 0 · 2141 prompt + 846 output tokens · 16.4 s · No code exists in this test, so 'read the existing code first' had nothing to read.

# CLAUDE.md — [PROJECT NAME]

This file is loaded by Claude Code at the start of every session. Keep it short and current.

## Project
[One paragraph: what the app does, who uses it, what matters most (e.g. "reliability of payments over new features").]

## Commands
- Install: `[pnpm install]`
- Dev server: `[pnpm dev]` (http://localhost:3000)
- Type check: `[pnpm typecheck]`
- Tests: `[pnpm test]` — single file: `[pnpm test path/to/file]`
- Lint/format: `[pnpm lint --fix]`

## Layout
- `[src/app]` — routes and pages
- `[src/components]` — shared UI
- `[src/server]` — business logic and DB access (only place that talks to the DB)
- `[prisma/]` — schema and migrations

## Working agreement
1. For anything bigger than a small fix, propose a plan (files, steps, checks) and wait for "go".
2. Work one step at a time; run the check after each step.
3. Make minimal, focused diffs. Don't touch unrelated code.
4. Never claim success without running typecheck + tests. If you couldn't run them, say so.
5. Ask before: adding dependencies, changing the DB schema, deleting files, or anything touching auth or payments.
6. Finish with a summary: files changed, how verified, what's left.

## Conventions
- TypeScript strict. No `any` without a comment explaining why.
- Validate inputs with [zod] at API boundaries.
- Errors: `{ error: { code, message } }`.
- Commits: `type(scope): summary`.

## Gotchas
- [e.g. "The `users` table has soft deletes; always filter `deletedAt IS NULL`."]
- [e.g. "Webhooks from Stripe must be verified with the signing secret before parsing."]


# AGENTS.md

Instructions for AI coding agents (Codex, Cursor, Jules, Aider and others that read this file) working in this repository.

## Setup
```bash
[pnpm install]
cp .env.example .env   # fill in local values; never commit .env
[pnpm db:migrate]
```

## Verify your work
Run all of these before declaring a task complete:
```bash
[pnpm typecheck]
[pnpm lint]
[pnpm test]
```
If any fail and you can't fix them, report the failure output instead of hiding it.

## Scope
- Do exactly the task described. List any other problems you notice under "Follow-ups" instead of fixing them.
- Keep diffs minimal and readable. No mass reformatting.
- Prefer existing utilities and patterns; search before creating new helpers.

## Ask first (do not do silently)
- New dependencies
- Schema or migration changes
- Changes to auth, permissions, billing, or data deletion
- Deleting or moving files

## Code style
- [Language/framework conventions, e.g. "TypeScript strict, named exports, kebab-case file names"]
- Tests live next to code as `*.test.ts`.

## Output
End every task with:
- **Changed:** list of files
- **Verified:** commands run and results
- **Follow-ups:** anything left or noticed


---
description: Core behavior for every request in this repo
alwaysApply: true
---
# Core rules

You are working in [PROJECT NAME], a [ONE-LINE DESCRIPTION]. Stack: [e.g. Next.js 15, TypeScript, Postgres via Prisma, Tailwind].

## How to work
- Read before you write. Open the files you are about to change and the files that call them.
- Make the smallest change that solves the request. Do not refactor, rename, or reformat code you were not asked to touch.
- If the request is ambiguous and a wrong guess would waste more than a few minutes, ask one focused question. Otherwise state your assumption in one line and proceed.
- Never invent APIs, packages, env vars, or file paths. If you are unsure something exists, search the repo or say so.
- Prefer the patterns already in the codebase over new ones. Match existing naming, folder layout, and error handling.

## Before you say "done"
- Run the type checker and the relevant tests: `[e.g. pnpm typecheck && pnpm test]`.
- If you could not run them, say so plainly. Do not claim something works if you did not verify it.
- Summarize: what changed (files), why, how you verified it, and anything left undone.

## Never
- Commit secrets, tokens, or `.env` files.
- Delete or rewrite migrations that have already been applied.
- Add a dependency without saying why and naming the alternative you considered.
- Disable a failing test or lint rule to make the build pass.


---
description: Use when the user asks for a feature, a multi-file change, or anything that will take more than ~30 lines
alwaysApply: false
---
# Plan before building

For any non-trivial change, write a plan first and wait for approval unless the user said "just do it". This overrides the core rule to "state your assumption and proceed" for changes over ~30 lines.

Plan format:
1. **Goal**: one sentence, in user terms.
2. **Files**: each file you will create or change, with one line on what changes.
3. **Steps**: numbered, each small enough to verify on its own (aim for 5–10).
4. **Verification**: the exact command or manual check for each step.
5. **Risks / open questions**: anything that could break or that you need decided.

While building:
- Do one step at a time. After each step, run its check and report pass/fail in one line.
- If a step's check fails, try one fix. If it fails again (two failures total), stop, explain what you tried, and propose a different approach instead of looping.
- If you discover the plan is wrong, say so and update the plan before continuing.

Fill-ins we made:

• [PASTE SPEC] → output of run 1, unedited

Exact input (user message)

Here is the approved spec: 
**Spec: Social Habit Streak Tracker (v1)**

**1. Problem**  
Many people start habits but fail to stick with them when motivation fades. Seeing friends’ current streaks provides social accountability that increases consistency. A simple web app focused on daily check-ins and visible streaks can address this without extra features.

**2. Users and main jobs**  
- Create an account and log in  
- Add, edit, or delete daily habits  
- Check off habits each day  
- Follow other users and see their current streaks  
- View own and followed users’ streaks on a dashboard

**3. Out of scope**  
- Mobile apps or push notifications  
- Habit history, graphs, or long-term stats  
- Comments, likes, or messaging  
- Private habits or custom visibility settings  
- Reminders, streaks for non-daily habits, or team challenges

**4. Screens / endpoints**  
- `/signup`, `/login` — handle authentication  
- `/dashboard` — show own habits with today’s check-in status and current streaks  
- `/habits/new` — form to create a new habit  
- `/friends` — list followed users and their current streaks, with follow/unfollow actions  
- `POST /api/checkins` — record a habit completion for a date  
- `GET /api/streaks` — return current streak values for a user or their follows

**5. Data**  
- User: id, email, name, createdAt  
- Habit: id, userId, name, createdAt  
- Checkin: id, habitId, date (unique per habit+date)  
- Follow: id, followerId, followeeId, createdAt

**6. Edge cases**  
- User attempts multiple check-ins for the same habit on one day  
- Streak calculation across timezone changes or date boundaries  
- User deletes a habit that has prior check-ins  
- Follower sees a friend’s streak immediately after the friend checks in  
- Two users follow each other vs. one-way follow  
- Handling of check-ins on days with no habits defined

**7. Open questions**  
- How exactly is a streak defined and when does it reset?  
- Are follows one-way or must they be mutual?  
- Can habits be private, or are all habits visible to followers?  
- What authentication method should be used (email/password, magic links, OAuth)?  
- Should check-ins be allowed for past dates, and if so, how far back?

Please answer the open questions (or say “just do it” with any clarifications) so I can proceed.


Read the existing code first (if any). Then write a build plan:
- Break the work into numbered steps. Each step must be small enough to finish and verify in one go (a single component, endpoint, or migration).
- For each step list: files touched, what changes, and the exact check (command or manual test) that proves it works.
- Order steps so the app runs after every step. Data model first, then API, then UI, then polish.
- Mark any step that needs a decision or a new dependency.

Save the plan to PLAN.md with checkboxes. Do not start building until I say "go".

Raw output (unedited)

**Answers to open questions (with minimal assumptions for v1):**

- **Streak definition**: A streak is the number of consecutive days ending today where the habit has at least one check-in. It resets on the first missed day (no check-in on a calendar day). We treat "today" in the user's local date (or UTC for v1 simplicity).
- **Follows**: One-way (asymmetric). You can follow someone without them following you back.
- **Habit visibility**: All habits are visible to followers. No private habits in v1.
- **Auth**: Email + password (simplest for a web app with sessions). No OAuth or magic links unless you want to add a dependency later.
- **Past check-ins**: Allowed up to 7 days back. No future dates.

If any of these feel wrong, correct me before I write the plan. Otherwise I'll proceed with these.

---

I first inspected the repo (no source files exist yet — only the root with the instruction files you provided). No existing code, schema, or dependencies.

Here is the build plan. I will write it to `PLAN.md` once you say **go**.

### PLAN.md (proposed)

```markdown
# Social Habit Streak Tracker (v1) — Build Plan

**Goal**: Deliver the core social habit streak tracker as described in the approved spec, with the clarifications above.

**Order**: Data model → API → UI → polish. App must run after every step.

- [ ] **Step 1: Project setup + Prisma schema**
  - Files: `package.json`, `prisma/schema.prisma`, `.env.example`
  - Changes: Initialize Next.js + Prisma + TypeScript, define User, Habit, Checkin, Follow models
  - Check: `pnpm install && pnpm prisma generate` succeeds; no type errors
  - Needs decision: none (using existing stack)

- [ ] **Step 2: Auth (signup/login with email/password + sessions)**
  - Files: `src/app/api/auth/...`, `src/server/auth.ts`
  - Changes: Basic email/password auth + session handling
  - Check: Can create account and log in via manual test at `/signup` and `/login`
  - Needs decision: none

- [ ] **Step 3: Habit CRUD endpoints + UI pages**
  - Files: `src/app/api/habits/...`, `src/app/habits/new/page.tsx`, `src/app/dashboard/page.tsx`
  - Changes: Create/read/update/delete habits (only for own user)
  - Check: `pnpm typecheck && pnpm test` pass; can add/edit/delete habit via UI

- [ ] **Step 4: Check-in endpoint + streak calculation logic**
  - Files: `src/app/api/checkins/route.ts`, `src/server/streaks.ts`
  - Changes: `POST /api/checkins`, streak function (consecutive days ending today)
  - Check: Unit test for streak calculation passes; prevents duplicate same-day check-ins

- [ ] **Step 5: Follow system + `/friends` page**
  - Files: `src/app/api/follows/...`, `src/app/friends/page.tsx`
  - Changes: Follow/unfollow, list followed users + their current streaks
  - Check: Manual test: follow user, see their streak on `/friends`

- [ ] **Step 6: Dashboard showing own + followed streaks**
  - Files: `src/app/dashboard/page.tsx`
  - Changes: Display own habits + streaks and followed users' streaks
  - Check: `pnpm typecheck && pnpm lint` pass; manual verification on dashboard

- [ ] **Step 7: Edge case handling + final verification**
  - Files: relevant test files + any small fixes
  - Changes: Handle duplicate check-ins, deleted habits, past check-ins (7-day limit)
  - Check: Full `pnpm typecheck && pnpm lint && pnpm test` passes

**Risks / open questions**: None remaining after clarifications above.
```

Ready when you say **go**.

What we saw

• Output is a PLAN.md-style checkbox list of 7 steps in data model, API, UI order, each with files, changes and a check, and it ends with 'Ready when you say go'.
• Weak point: the spec from run 1 still had five unanswered open questions. Instead of waiting for our answers, the model answered them itself ('Answers to open questions (with minimal assumptions for v1)') and planned on its own assumptions. A real user would have to read those assumptions before saying 'go'.
• The pack's prompt 2 expects an approved spec, so this is partly our test (we fed it an unapproved one), but the pack does not tell the agent to stop on unresolved questions.

Run 3: Behavior test: does it plan and wait on a big change? Passed

2026-10-23 11:43 America/Louisville (EDT) · model grok-4.3 · temperature 0 · 1517 prompt + 450 output tokens · 10.1 s · Request is deliberately large and touches auth and deletion, which the pack says to plan first and ask before changing.

# CLAUDE.md — [PROJECT NAME]

This file is loaded by Claude Code at the start of every session. Keep it short and current.

## Project
[One paragraph: what the app does, who uses it, what matters most (e.g. "reliability of payments over new features").]

## Commands
- Install: `[pnpm install]`
- Dev server: `[pnpm dev]` (http://localhost:3000)
- Type check: `[pnpm typecheck]`
- Tests: `[pnpm test]` — single file: `[pnpm test path/to/file]`
- Lint/format: `[pnpm lint --fix]`

## Layout
- `[src/app]` — routes and pages
- `[src/components]` — shared UI
- `[src/server]` — business logic and DB access (only place that talks to the DB)
- `[prisma/]` — schema and migrations

## Working agreement
1. For anything bigger than a small fix, propose a plan (files, steps, checks) and wait for "go".
2. Work one step at a time; run the check after each step.
3. Make minimal, focused diffs. Don't touch unrelated code.
4. Never claim success without running typecheck + tests. If you couldn't run them, say so.
5. Ask before: adding dependencies, changing the DB schema, deleting files, or anything touching auth or payments.
6. Finish with a summary: files changed, how verified, what's left.

## Conventions
- TypeScript strict. No `any` without a comment explaining why.
- Validate inputs with [zod] at API boundaries.
- Errors: `{ error: { code, message } }`.
- Commits: `type(scope): summary`.

## Gotchas
- [e.g. "The `users` table has soft deletes; always filter `deletedAt IS NULL`."]
- [e.g. "Webhooks from Stripe must be verified with the signing secret before parsing."]


# AGENTS.md

Instructions for AI coding agents (Codex, Cursor, Jules, Aider and others that read this file) working in this repository.

## Setup
```bash
[pnpm install]
cp .env.example .env   # fill in local values; never commit .env
[pnpm db:migrate]
```

## Verify your work
Run all of these before declaring a task complete:
```bash
[pnpm typecheck]
[pnpm lint]
[pnpm test]
```
If any fail and you can't fix them, report the failure output instead of hiding it.

## Scope
- Do exactly the task described. List any other problems you notice under "Follow-ups" instead of fixing them.
- Keep diffs minimal and readable. No mass reformatting.
- Prefer existing utilities and patterns; search before creating new helpers.

## Ask first (do not do silently)
- New dependencies
- Schema or migration changes
- Changes to auth, permissions, billing, or data deletion
- Deleting or moving files

## Code style
- [Language/framework conventions, e.g. "TypeScript strict, named exports, kebab-case file names"]
- Tests live next to code as `*.test.ts`.

## Output
End every task with:
- **Changed:** list of files
- **Verified:** commands run and results
- **Follow-ups:** anything left or noticed


---
description: Core behavior for every request in this repo
alwaysApply: true
---
# Core rules

You are working in [PROJECT NAME], a [ONE-LINE DESCRIPTION]. Stack: [e.g. Next.js 15, TypeScript, Postgres via Prisma, Tailwind].

## How to work
- Read before you write. Open the files you are about to change and the files that call them.
- Make the smallest change that solves the request. Do not refactor, rename, or reformat code you were not asked to touch.
- If the request is ambiguous and a wrong guess would waste more than a few minutes, ask one focused question. Otherwise state your assumption in one line and proceed.
- Never invent APIs, packages, env vars, or file paths. If you are unsure something exists, search the repo or say so.
- Prefer the patterns already in the codebase over new ones. Match existing naming, folder layout, and error handling.

## Before you say "done"
- Run the type checker and the relevant tests: `[e.g. pnpm typecheck && pnpm test]`.
- If you could not run them, say so plainly. Do not claim something works if you did not verify it.
- Summarize: what changed (files), why, how you verified it, and anything left undone.

## Never
- Commit secrets, tokens, or `.env` files.
- Delete or rewrite migrations that have already been applied.
- Add a dependency without saying why and naming the alternative you considered.
- Disable a failing test or lint rule to make the build pass.


---
description: Use when the user asks for a feature, a multi-file change, or anything that will take more than ~30 lines
alwaysApply: false
---
# Plan before building

For any non-trivial change, write a plan first and wait for approval unless the user said "just do it". This overrides the core rule to "state your assumption and proceed" for changes over ~30 lines.

Plan format:
1. **Goal**: one sentence, in user terms.
2. **Files**: each file you will create or change, with one line on what changes.
3. **Steps**: numbered, each small enough to verify on its own (aim for 5–10).
4. **Verification**: the exact command or manual check for each step.
5. **Risks / open questions**: anything that could break or that you need decided.

While building:
- Do one step at a time. After each step, run its check and report pass/fail in one line.
- If a step's check fails, try one fix. If it fails again (two failures total), stop, explain what you tried, and propose a different approach instead of looping.
- If you discover the plan is wrong, say so and update the plan before continuing.

Exact input (user message)

Add a 'delete my account' button to the settings page. It should remove the user, their habits, check-ins and friendships, and sign them out. Also switch the whole auth system from JWT to server sessions while you're in there.

Raw output (unedited)

This request involves multiple non-trivial changes, including auth system changes and data deletion. Per the working agreement and plan-before-building rule, I must propose a plan first and wait for approval.

---

**Goal**: Add account deletion to settings and migrate auth from JWT to server sessions.

**Files** (estimated; would need to explore first):
1. `src/app/settings/page.tsx` (or similar) — add delete button + confirmation UI
2. `src/server/` — new or updated delete-account action that cascades deletes
3. Auth-related files under `src/server/` and any JWT/session middleware — replace JWT issuance/validation with session-based auth
4. Possibly `prisma/schema.prisma` — if sessions require a new model/table
5. Any middleware or API route handlers that currently read JWTs

**Steps**:
1. Explore current auth implementation (JWT usage, session handling, user model).
2. Explore settings page and existing user actions.
3. Explore data model for habits, check-ins, friendships.
4. Write plan update if exploration reveals different files or schema needs.
5. Implement account deletion endpoint/logic (with cascade).
6. Wire delete button in settings UI with confirmation.
7. Migrate auth: replace JWT with server sessions (new session table? middleware changes?).
8. Update sign-out to work with sessions.
9. Run typecheck, lint, tests after each discrete change.

**Verification**:
- `pnpm typecheck`, `pnpm lint`, `pnpm test` after each step that touches code.
- Manual test of delete flow (if possible in dev).
- Manual test of login/logout under new session auth.

**Risks / open questions**:
- Does the current schema have a sessions table, or will one need to be added (schema change)?
- Are there existing tests for auth that would need updating?
- Any external JWT consumers (mobile apps, other services) that would break?
- How are sessions stored (cookie, DB, memory) — any new dependencies?
- Deleting friendships/check-ins/habits may require transaction or careful cascade rules.

---

Does this plan look correct? Any constraints or preferences on how sessions should be implemented? Shall I proceed ("go")?

What we saw

• Asked for a big change touching deletion and auth, the model did not write code. It wrote a Goal / Files / Steps / Verification / Risks plan in the format from 10-planning.mdc and asked for 'go'.
• It named the unknowns (is there a sessions table, any external JWT consumers) instead of guessing.

What failed or was weak

• Run 2: the agent made product decisions on its own instead of waiting for answers to the spec's open questions (see above).
• Oct 15 internal review (before today's runs) found: contradictory retry limits (fixed: both 10-planning.mdc and 03-build-step.md now say 'one fix, two failures total, stop'), 04-self-review ending with 'fix all blockers' (fixed: it now waits for 'fix'), hard-coded `main` (fixed: `[main]` placeholder) and 50-git.mdc not always-on (fixed: alwaysApply: true). We checked today that the current files contain these fixes.

What we did not test

• No real codebase: nothing was built. Prompts 3 (build step), 4 (self-review), 5 (handoff) and the bonus debug loop were not run today.
• The six .mdc rules were pasted as text. We did not load them in Cursor or Claude Code, so we have not seen the globs and rule types attach in a real editor.
• The 19-page GUIDE.pdf was page-counted but not re-read page by page today.
• One model, one run per prompt. We do not know how the pack behaves on Claude, ChatGPT or Gemini.

File integrity (checked 2026-10-23)

We checked the zips on our own disk. We did not (and cannot, without buying) re-download the files from Payhip, so we have not verified that the copy on Payhip is byte-identical to the zip described here.

Other proof pages

• Research Agent Pack
• Customer Support Agent Pack
• YouTube & TikTok Script Agent Pack
• Discord Community Manager Pack
• All 5 bundle ($29)