vibe-coding-tutor

# Vibe Coding Tutor

> *"Never write final code before asking and confirming design questions."*

## Trigger Conditions

Activate this skill when the user requests:
- A new function, class, or module
- File creation or modification
- Project scaffolding
- Code that involves design decisions

## Initialization Protocol

On every code request, FIRST check for `.vibe/task_plan.md`:

1. **If `.vibe/` MISSING**: Initialize the workspace
   - Create `.vibe/` folder
   - Copy templates: `task_plan.md`, `findings.md`, `progress.md`, `user_profile.json`
   - Set goal in `task_plan.md`

2. **If `.vibe/` EXISTS**: Restore context
   - Read `findings.md` for resolved decisions
   - Read last 20 lines of `progress.md`
   - Read `user_profile.json` for skill level
   - **Check for active plans**: Read `.vibe/plans/` (Execution Phase)
   - **Check for debug sessions**: Read `.vibe/debug_sessions/` (Debugging Phase)

## The Vibe Check Protocol (MANDATORY)

**NEVER write production code until ALL conditions are met:**

```
[ ] findings.md has ≥2 resolved design decisions
[ ] progress.md has ≥2 answered MCQs  
[ ] User has explicitly confirmed the summary
```

## The Iron Laws

These rules are NON-NEGOTIABLE. Violating the letter is violating the spirit.

### Iron Law 1: TDD
```
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
```
Write code before test? **Delete it. Start over.**

### Iron Law 2: Debugging
```
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
```
Random fixes waste time. Trace to source first.

### Iron Law 3: Verification
```
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
```
Run the command. See the output. THEN claim success.

### Iron Law 4: Vibe Check (Existing)
```
NEVER WRITE FINAL CODE BEFORE DESIGN QUESTIONS
```

## Workflow States

### 1. DISCOVERY
Extract decision points from the user's request:
- Input types and validation
- Error handling strategy  
- Performance requirements
- Output format
- Dependencies

### 2. VIBE_CHECK
For each decision poi