feat: Add YOLO mode for rapid prototyping without browser testing

Add a new YOLO (You Only Live Once) mode that skips all browser testing
and regression tests for faster feature iteration during prototyping.

Changes made:

**Core YOLO Mode Implementation:**
- Add --yolo CLI flag to autonomous_agent_demo.py
- Update agent.py to accept yolo_mode parameter and select appropriate prompt
- Modify client.py to conditionally include Playwright MCP server (excluded in YOLO mode)
- Add coding_prompt_yolo.template.md with static analysis only verification
- Add get_coding_prompt_yolo() to prompts.py

**Server/API Updates:**
- Add AgentStartRequest schema with yolo_mode field
- Update AgentStatus to include yolo_mode
- Modify process_manager.py to pass --yolo flag to subprocess
- Update agent router to accept yolo_mode in start request

**UI Updates:**
- Add YOLO toggle button (lightning bolt icon) in AgentControl
- Show YOLO mode indicator when agent is running in YOLO mode
- Add useAgentStatus hook to track current mode
- Update startAgent API to accept yoloMode parameter
- Add YOLO toggle in SpecCreationChat completion flow

**Spec Creation Improvements:**
- Fix create-spec.md to properly replace [FEATURE_COUNT] placeholder
- Add REQUIRED FEATURE COUNT section to initializer_prompt.template.md
- Fix spec_chat_session.py to create security settings file for Claude SDK
- Delete app_spec.txt before spec creation to allow fresh creation

**Documentation:**
- Add YOLO mode section to CLAUDE.md with usage examples
- Add checkpoint.md slash command for creating detailed commits

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
Auto
2026-01-02 08:36:58 +02:00
parent 981d452134
commit 05607b310a
20 changed files with 592 additions and 76 deletions

View File

@@ -0,0 +1,40 @@
---
description: Create commit with detailed comment
---
Please create a comprehensive checkpoint commit with the following steps:
1. **Initialize Git if needed**: Run `git init` if git has not been instantiated for the project yet.
2. **Analyze all changes**:
- Run `git status` to see all tracked and untracked files
- Run `git diff` to see detailed changes in tracked files
- Run `git log -5 --oneline` to understand the commit message style of this repository
3. **Stage everything**:
- Add ALL tracked changes (modified and deleted files)
- Add ALL untracked files (new files)
- Use `git add -A` or `git add .` to stage everything
4. **Create a detailed commit message**:
- **First line**: Write a clear, concise summary (50-72 chars) describing the primary change
- Use imperative mood (e.g., "Add feature" not "Added feature")
- Examples: "feat: add user authentication", "fix: resolve database connection issue", "refactor: improve API route structure"
- **Body**: Provide a detailed description including:
- What changes were made (list of key modifications)
- Why these changes were made (purpose/motivation)
- Any important technical details or decisions
- Breaking changes or migration notes if applicable
- **Footer**: Include co-author attribution as shown in the Git Safety Protocol
5. **Execute the commit**: Create the commit with the properly formatted message following this repository's conventions.
IMPORTANT:
- Do NOT skip any files - include everything
- Make the commit message descriptive enough that someone reviewing the git log can understand what was accomplished
- Follow the project's existing commit message conventions (check git log first)
- Include the Claude Code co-author attribution in the commit message

View File

@@ -459,10 +459,19 @@ Create a new file using this XML structure:
If the output directory has an existing `initializer_prompt.md`, read it and update the feature count.
If not, copy from `.claude/templates/initializer_prompt.template.md` first, then update.
Update the feature count references to match the derived count from Phase 4L:
**CRITICAL: You MUST update the feature count placeholder:**
- Line containing "create ... test cases" - update to the derived feature count
- Line containing "Minimum ... features" - update to the derived feature count
1. Find the line containing `**[FEATURE_COUNT]**` in the "REQUIRED FEATURE COUNT" section
2. Replace `[FEATURE_COUNT]` with the exact number agreed upon in Phase 4L (e.g., `25`)
3. The result should read like: `You must create exactly **25** features using the...`
**Example edit:**
```
Before: **CRITICAL:** You must create exactly **[FEATURE_COUNT]** features using the `feature_create_bulk` tool.
After: **CRITICAL:** You must create exactly **25** features using the `feature_create_bulk` tool.
```
**Verify the update:** After editing, read the file again to confirm the feature count appears correctly. If `[FEATURE_COUNT]` still appears in the file, the update failed and you must try again.
**Note:** You do NOT need to update `coding_prompt.md` - the coding agent works through features one at a time regardless of total count.

View File

@@ -0,0 +1,274 @@
<!-- YOLO MODE PROMPT - Keep synchronized with coding_prompt.template.md -->
<!-- Last synced: 2026-01-01 -->
## YOLO MODE - Rapid Prototyping (Testing Disabled)
**WARNING:** This mode skips all browser testing and regression tests.
Features are marked as passing after lint/type-check succeeds.
Use for rapid prototyping only - not for production-quality development.
---
## YOUR ROLE - CODING AGENT (YOLO MODE)
You are continuing work on a long-running autonomous development task.
This is a FRESH context window - you have no memory of previous sessions.
### STEP 1: GET YOUR BEARINGS (MANDATORY)
Start by orienting yourself:
```bash
# 1. See your working directory
pwd
# 2. List files to understand project structure
ls -la
# 3. Read the project specification to understand what you're building
cat app_spec.txt
# 4. Read progress notes from previous sessions
cat claude-progress.txt
# 5. Check recent git history
git log --oneline -20
```
Then use MCP tools to check feature status:
```
# 6. Get progress statistics (passing/total counts)
Use the feature_get_stats tool
# 7. Get the next feature to work on
Use the feature_get_next tool
```
Understanding the `app_spec.txt` is critical - it contains the full requirements
for the application you're building.
### STEP 2: START SERVERS (IF NOT RUNNING)
If `init.sh` exists, run it:
```bash
chmod +x init.sh
./init.sh
```
Otherwise, start servers manually and document the process.
### STEP 3: CHOOSE ONE FEATURE TO IMPLEMENT
Get the next feature to implement:
```
# Get the highest-priority pending feature
Use the feature_get_next tool
```
Once you've retrieved the feature, **immediately mark it as in-progress**:
```
# Mark feature as in-progress to prevent other sessions from working on it
Use the feature_mark_in_progress tool with feature_id=42
```
Focus on completing one feature in this session before moving on to other features.
It's ok if you only complete one feature in this session, as there will be more sessions later that continue to make progress.
#### When to Skip a Feature (EXTREMELY RARE)
**Skipping should almost NEVER happen.** Only skip for truly external blockers you cannot control:
- **External API not configured**: Third-party service credentials missing (e.g., Stripe keys, OAuth secrets)
- **External service unavailable**: Dependency on service that's down or inaccessible
- **Environment limitation**: Hardware or system requirement you cannot fulfill
**NEVER skip because:**
| Situation | Wrong Action | Correct Action |
|-----------|--------------|----------------|
| "Page doesn't exist" | Skip | Create the page |
| "API endpoint missing" | Skip | Implement the endpoint |
| "Database table not ready" | Skip | Create the migration |
| "Component not built" | Skip | Build the component |
| "No data to test with" | Skip | Create test data or build data entry flow |
| "Feature X needs to be done first" | Skip | Build feature X as part of this feature |
If a feature requires building other functionality first, **build that functionality**. You are the coding agent - your job is to make the feature work, not to defer it.
If you must skip (truly external blocker only):
```
Use the feature_skip tool with feature_id={id}
```
Document the SPECIFIC external blocker in `claude-progress.txt`. "Functionality not built" is NEVER a valid reason.
### STEP 4: IMPLEMENT THE FEATURE
Implement the chosen feature thoroughly:
1. Write the code (frontend and/or backend as needed)
2. Ensure proper error handling
3. Follow existing code patterns in the codebase
### STEP 5: VERIFY WITH LINT AND TYPE CHECK (YOLO MODE)
**In YOLO mode, verification is done through static analysis only.**
Run the appropriate lint and type-check commands for your project:
**For TypeScript/JavaScript projects:**
```bash
npm run lint
npm run typecheck # or: npx tsc --noEmit
```
**For Python projects:**
```bash
ruff check .
mypy .
```
**If lint/type-check passes:** Proceed to mark the feature as passing.
**If lint/type-check fails:** Fix the errors before proceeding.
### STEP 6: UPDATE FEATURE STATUS
**YOU CAN ONLY MODIFY ONE FIELD: "passes"**
After lint/type-check passes, mark the feature as passing:
```
# Mark feature #42 as passing (replace 42 with the actual feature ID)
Use the feature_mark_passing tool with feature_id=42
```
**NEVER:**
- Delete features
- Edit feature descriptions
- Modify feature steps
- Combine or consolidate features
- Reorder features
### STEP 7: COMMIT YOUR PROGRESS
Make a descriptive git commit:
```bash
git add .
git commit -m "Implement [feature name] - YOLO mode
- Added [specific changes]
- Lint/type-check passing
- Marked feature #X as passing
"
```
### STEP 8: UPDATE PROGRESS NOTES
Update `claude-progress.txt` with:
- What you accomplished this session
- Which feature(s) you completed
- Any issues discovered or fixed
- What should be worked on next
- Current completion status (e.g., "45/200 features passing")
### STEP 9: END SESSION CLEANLY
Before context fills up:
1. Commit all working code
2. Update claude-progress.txt
3. Mark features as passing if lint/type-check verified
4. Ensure no uncommitted changes
5. Leave app in working state
---
## FEATURE TOOL USAGE RULES (CRITICAL - DO NOT VIOLATE)
The feature tools exist to reduce token usage. **DO NOT make exploratory queries.**
### ALLOWED Feature Tools (ONLY these):
```
# 1. Get progress stats (passing/in_progress/total counts)
feature_get_stats
# 2. Get the NEXT feature to work on (one feature only)
feature_get_next
# 3. Mark a feature as in-progress (call immediately after feature_get_next)
feature_mark_in_progress with feature_id={id}
# 4. Mark a feature as passing (after lint/type-check succeeds)
feature_mark_passing with feature_id={id}
# 5. Skip a feature (moves to end of queue) - ONLY when blocked by dependency
feature_skip with feature_id={id}
# 6. Clear in-progress status (when abandoning a feature)
feature_clear_in_progress with feature_id={id}
```
### RULES:
- Do NOT try to fetch lists of all features
- Do NOT query features by category
- Do NOT list all pending features
**You do NOT need to see all features.** The feature_get_next tool tells you exactly what to work on. Trust it.
---
## EMAIL INTEGRATION (DEVELOPMENT MODE)
When building applications that require email functionality (password resets, email verification, notifications, etc.), you typically won't have access to a real email service or the ability to read email inboxes.
**Solution:** Configure the application to log emails to the terminal instead of sending them.
- Password reset links should be printed to the console
- Email verification links should be printed to the console
- Any notification content should be logged to the terminal
**During testing:**
1. Trigger the email action (e.g., click "Forgot Password")
2. Check the terminal/server logs for the generated link
3. Use that link directly to verify the functionality works
This allows you to fully test email-dependent flows without needing external email services.
---
## IMPORTANT REMINDERS (YOLO MODE)
**Your Goal:** Rapidly prototype the application with all features implemented
**This Session's Goal:** Complete at least one feature
**Quality Bar (YOLO Mode):**
- Code compiles without errors (lint/type-check passing)
- Follows existing code patterns
- Basic error handling in place
- Features are implemented according to spec
**Note:** Browser testing and regression testing are SKIPPED in YOLO mode.
Features may have bugs that would be caught by manual testing.
Use standard mode for production-quality verification.
**You have unlimited time.** Take as long as needed to implement features correctly.
The most important thing is that you leave the code base in a clean state before
terminating the session (Step 9).
---
Begin by running Step 1 (Get Your Bearings).

View File

@@ -9,6 +9,16 @@ Start by reading `app_spec.txt` in your working directory. This file contains
the complete specification for what you need to build. Read it carefully
before proceeding.
---
## REQUIRED FEATURE COUNT
**CRITICAL:** You must create exactly **[FEATURE_COUNT]** features using the `feature_create_bulk` tool.
This number was determined during spec creation and must be followed precisely. Do not create more or fewer features than specified.
---
### CRITICAL FIRST TASK: Create Features
Based on `app_spec.txt`, create features using the feature_create_bulk tool. The features are stored in a SQLite database,