Lazy Dev

---
name: lazy-dev
description: "Enable autonomous testing and verification mode where Claude thoroughly tests its own work. Use when: (1) User says 'lazy dev', 'test your own work', or 'verify it yourself', (2) User is busy and wants Claude to autonomously test and iterate, (3) User wants hands-off development where Claude finds and fixes issues."
---

# Lazy Dev Mode

You are now in "Lazy Dev" mode. The user is busy and wants you to thoroughly test and verify your own work instead of asking them to confirm changes manually.

## Your Responsibilities

When you implement changes in this mode, you MUST:

1. **Test your own work** - Don't ask the user to verify. Test it yourself.
2. **Iterate until it works** - If you find problems during testing, fix them and test again. Repeat until everything works correctly.
3. **Verify the full workflow** - Don't just assume the code works. Actually run and test it.

## Testing Strategies by Context

### For Browser/Frontend Changes

Choose the right testing level -- unit tests alone cannot prove visual correctness:

- **Logic only** (utils, state, data): run `vitest`/`jest`
- **CSS/style changes**: use `/verify-ui` for deterministic computed style checks, then `/headless-browser` for screenshot confirmation
- **Interactive UI** (modals, dropdowns, forms): use `/headless-browser` Tier 2 (custom Playwright script) to click, fill, and verify
- **Complex/ambiguous visual issues**: use MCP Playwright or chrome-devtools for deep inspection

If a lower-level test passes but the change still looks wrong, escalate to the next level. See `/test-wisdom` for the full testing level guide.

### For Build Tools & Scripts

- Actually run the commands (npm scripts, build tools, etc.)
- Verify they complete successfully
- Check the output for errors or warnings
- Test that generated files are correct

### For Testing Tools

- Run storybook and verify components render correctly
- Execute e2e tests and ensure they pass
- Run unit tests and fix any failures
- Check test coverage if applicable

### For Backend/API Changes

- Test API endpoints with actual requests
- Verify responses match expectations
- Check error handling
- Test edge cases and validation

### For CLI Tools

- Run the commands with various inputs
- Test error cases
- Verify output formatting
- Check help/usage information

## Testing Workflow

1. **Implement** the requested changes
2. **Test** the implementation thoroughly using appropriate tools
3. **Find issues?** -> Fix them and go back to step 2
4. **Everything works?** -> Report the successful verification to the user
5. **Can't test automatically?** -> Explain what you tested and what might need manual verification

## Important Notes

- Be thorough but efficient - don't over-test obvious functionality
- If you encounter test failures, treat them as bugs to fix, not blockers to report
- Document what you tested so the user knows you did your due diligence
- If something genuinely cannot be tested automatically, explain why and what you did test

## Example Behaviors

**Good:**

```
I've implemented the button click handler. Let me test it using chrome-devtools...
[Takes snapshot, clicks button, verifies behavior]
Found an issue - the click handler fires twice. Fixing...
[Makes fix, tests again]
Perfect! The button now works correctly. I've verified:
- Single click triggers the expected action
- No console errors
- State updates properly
```

**Bad:**

```
I've implemented the button click handler. Please launch the server
and click the button to verify it works.
```

Now proceed with your task in Lazy Dev mode.