Lisa Prep

Prepare groundwork files for a Lisa loop. This command creates the scaffolding needed for effective autonomous iteration.

Workflow

When user invokes /lisa:prep, follow this workflow:

Step 1: Ask About Preparation Mode

First, ask the user which preparation approach they want:

"Which preparation mode do you prefer?"

Mode	Description	Best For
Quick	Brief questions, generate specs fast	Simple features, prototypes
Interview	In-depth AskUserQuestionTool interview	Complex features, critical systems

If Interview mode selected: Use the interview workflow (Step 2a) If Quick mode selected: Use the quick workflow (Step 2b)

Step 2a: Interview Mode (Recommended for Complex Features)

This methodology is inspired by Thariq (@trq212) from the Claude Code team.

Use the AskUserQuestionTool to conduct an in-depth interview. The goal is to surface requirements the user hasn't thought about.

Interview Guidelines:

• Ask about technical implementation details
• Ask about UI & UX decisions
• Ask about edge cases and error handling
• Ask about security and performance concerns
• Ask about tradeoffs they're willing to make
• Make questions NON-OBVIOUS (don't ask what they already told you)

Example Interview Flow:

Q: "What authentication method: JWT with short-lived tokens + refresh,
    JWT with long-lived tokens, or session-based?"

Q: "For password requirements, what's the minimum? Should we check
    against common password lists?"

Q: "When a user's token expires mid-request, should we auto-refresh
    or return 401?"

Q: "Rate limiting: per-IP, per-user, or both? What limits?"

Q: "Should deleted users' data be hard-deleted or soft-deleted?"

Continue interviewing until:

• All major features have detailed requirements
• Edge cases are documented
• Technical decisions are made
• The user says "that's enough" or similar

Step 2b: Quick Mode

Ask basic questions:

• What is the goal?
• What technologies/stack?
• Any specific requirements?
• How will we know when it's done?

Step 3: Ask About Version Control

Before creating files, ask:

"Do you want Lisa artifacts committed or ignored in git?"

Option	When to use
Commit	Team project, want to preserve design decisions
Ignore	Personal project, temporary task

If ignore, add to .gitignore:

# Lisa loop artifacts
PROMPT.md
IMPLEMENTATION_PLAN.md
specs/

Step 4: Analyze Existing Codebase (if applicable)

If working in an existing project:

• Explore the project structure
• Identify existing patterns and conventions
• Note the tech stack being used
• Find similar implementations to follow

Step 5: Create specs/ Directory

Create specs/ with verifiable requirement files:

specs/
├── overview.md          # What the project does (1 paragraph)
├── features.md          # CHECKBOXED requirements (THE CONTRACT)
├── tech-stack.md        # Technologies and why
├── api-contracts.md     # Request/response shapes (if API)
├── edge-cases.md        # Error handling requirements
└── conventions.md       # Code patterns to follow

CRITICAL: specs/features.md must use checkboxes because it becomes the verification checklist.

Example specs/features.md (Interview Mode):

# Features

## AUTH: Authentication

### AUTH-1: User Registration
- [ ] POST /auth/register accepts { email, password, name }
- [ ] Password minimum 8 chars, 1 uppercase, 1 number
- [ ] Email validated with regex, must be unique
- [ ] Password hashed with bcrypt (cost factor 12)
- [ ] Returns 201 with { user: { id, email, name }, token }
- [ ] Returns 400 for validation errors with field-specific messages
- [ ] Returns 409 if email already exists

### AUTH-2: User Login
- [ ] POST /auth/login accepts { email, password }
- [ ] Returns 200 with { user, token, refreshToken }
- [ ] Returns 401 for invalid credentials (generic message)
- [ ] Token expires in 15 minutes
- [ ] Refresh token expires in 7 days
- [ ] Rate limited: 5 attempts per minute per IP

### AUTH-3: Token Refresh
- [ ] POST /auth/refresh accepts { refreshToken }
- [ ] Returns new token pair if refresh token valid
- [ ] Returns 401 if refresh token expired/invalid
- [ ] Old refresh token invalidated after use

### AUTH-4: Protected Routes
- [ ] Middleware extracts Bearer token from Authorization header
- [ ] Returns 401 if token missing
- [ ] Returns 401 if token invalid/expired (with 'expired' flag)
- [ ] Attaches decoded user to req.user

Notice: Each requirement is specific, testable, and checkboxed.

Step 6: Create IMPLEMENTATION_PLAN.md

Group requirements into phases:

# Implementation Plan

## Phase 1: Foundation
- [ ] Setup project structure (package.json, tsconfig, etc.)
- [ ] Configure database connection
- [ ] Create User model/schema

## Phase 2: Authentication
- [ ] AUTH-1: User Registration
- [ ] AUTH-2: User Login
- [ ] AUTH-3: Token Refresh
- [ ] AUTH-4: Protected Routes middleware

## Phase 3: Core Features
- [ ] [Feature requirements...]

## Phase 4: Polish
- [ ] Error handling middleware
- [ ] Request validation
- [ ] API documentation
- [ ] Test coverage > 80%

Step 7: Create PROMPT.md

For Interview Mode - Generate verification-enforced prompt:

# Mission

Implement [FEATURE] as specified in specs/.

# Source of Truth

The ONLY definition of "done" is specs/features.md.
Your subjective sense of completion is IRRELEVANT.
Do NOT trust your memory across iterations.

# Process Per Iteration

1. Read specs/features.md from disk (not memory)
2. Find FIRST unchecked requirement (- [ ])
3. Implement it with tests
4. Run tests to verify
5. Mark [x] in specs/features.md
6. Commit: "feat: implement [REQ-ID]"

# Mandatory Verification (NEVER SKIP)

Before outputting completion promise:
1. Re-read specs/features.md from disk
2. For EACH requirement:
   - Verify code exists
   - Verify test exists and passes
3. Count: X checked, Y unchecked
4. IF Y > 0: List unchecked, continue working
5. IF Y == 0 AND all tests pass: Output promise

# Critical Rules

- NEVER promise if ANY requirement unchecked
- NEVER mark [x] without verification
- NEVER trust memory - re-read spec every iteration

# Completion

<promise>ALL REQUIREMENTS VERIFIED</promise>

For Quick Mode - Generate simple prompt:

# Mission

Build [PROJECT_NAME].

# Process

1. Read specs/ for requirements
2. Read IMPLEMENTATION_PLAN.md for tasks
3. Pick first unchecked task, implement, test, mark done
4. Commit with descriptive message
5. Repeat until all tasks complete

# Completion

<promise>DONE</promise>

Step 8: Show Summary

✅ Lisa preparation complete!

Mode: [Interview/Quick]

Created:
  specs/overview.md
  specs/features.md      ← Verification checklist
  specs/tech-stack.md
  specs/edge-cases.md
  specs/conventions.md
  IMPLEMENTATION_PLAN.md
  PROMPT.md

Requirements extracted: [N] checkboxed items

To start:
  /lisa:loop PROMPT.md --max-iterations 50

Tip: The verification protocol in PROMPT.md will prevent
premature completion by requiring systematic spec checks.

Key Principles

1. Interview surfaces unknowns - Ask non-obvious questions to catch edge cases early
2. Specs are the contract - The checkboxed requirements define "done", not gut feeling
3. Verification prevents lying - The prompt forces re-reading specs before completion
4. Atomic tasks - Each checkbox should be completable in one iteration
5. Safety limits - Always recommend --max-iterations