### Quick Start Guide

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/README.md

Follow these steps to get started with Vibe Coding in 5 minutes. This includes reading an overview, deciding on suitability, and following a checklist.

```text
1. Read: 00-project-overview.md (3 min)
2. Decide: Is Vibe Coding right for your project? (2 min)
3. If yes: Follow 08-quick-start-checklist.md to begin
```

--------------------------------

### Example Implementation Plan: Asteroid Miner

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/03-memory-bank-reference.md

Illustrates a complete implementation plan for a game project, showing how to structure overview and individual steps. This example covers scene setup, player controls, and collision detection.

```markdown
# Asteroid Miner — Implementation Plan

## Overview
Total estimated steps: 18
Base game complete when: Player can mine asteroids, avoid enemies, 
  collect power-ups, and game persists score

## Step 1: Three.js Scene Setup
### Objective
Create a 3D scene with camera, lighting, and a rotating asteroid

### Requirements
- Black space background
- White directional light
- Asteroid mesh (cube or sphere) in center
- Camera positioned 5 units back
- Asteroid rotates smoothly

### Test
Open app in browser. Verify:
- Scene loads without console errors
- Asteroid visible in center of viewport
- Asteroid rotates visibly

## Step 2: Player Ship Model and Controls
### Objective
Add player spaceship and basic keyboard control

### Requirements
- Simple ship model (triangular wireframe or basic mesh)
- WASD keys move ship horizontally/vertically
- Ship stays within viewport bounds
- Ship position resets on page reload

### Test
Keyboard controls move ship in all directions. 
Ship cannot move off-screen. 
Page refresh resets position to center.

## Step 3: Asteroid Collision Detection
### Objective
Detect when ship touches asteroid and trigger ore collection

### Requirements
- Collision detection using bounding boxes
- Ore counter increments on collision
- Asteroid respawns at random position
- Counter displays on screen

### Test
Collide ship with asteroid. 
Verify: counter increments, asteroid moves, no errors in console.

## Step 4: Energy System
...
[Continue for remaining steps]
```

--------------------------------

### Commit Initial Project Setup

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/08-quick-start-checklist.md

Stage all changes and commit them to mark the initial project setup.

```bash
git add .
git commit -m "initial: setup project structure"
```

--------------------------------

### Troubleshooting Incorrect Implementation Plan

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/07-faq-troubleshooting.md

This example outlines the steps to take when an implementation plan is found to be incorrect mid-way. It involves documenting the issue, reverting changes if necessary, updating the plan, and starting a new chat session.

```text
Step 5 test: "Asteroid respawns at random position"
Actual result: Asteroid respawns at same position; random function not working

Issue: Implementation plan assumed random seed behavior; actually need explicit random lib

Fix: Update Step 4 to "Add random library import" + Step 5 to use it

Result: Update implementation-plan.md, revert Step 5, re-implement with fix
```

--------------------------------

### Vibe Coding Integration Example: Complete Tool Flow

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/05-tool-ecosystem-reference.md

This example illustrates a typical project workflow using Claude Code and asset generation tools, broken down into phases from setup to finalization.

```markdown
## Integration Example: Complete Tool Flow

**Typical project with Claude Code + asset generation:**

```
Phase 1: Setup
1. Claude Code: /init → generate CLAUDE.md
2. Claude Code: Clarify implementation-plan.md
3. Git: Initial commit

Phase 2: Implement Step 1 (Scene setup)
1. Claude Code: Implement base scene
2. Claude Code: Review code
3. ESLint + Prettier: Lint and format
4. Git: Commit Step 1

Phase 3: Implement Step 5 (Asteroid visuals)
1. ChatGPT + DALL-E: Generate asteroid sprite
2. Claude Code: Add sprite to game
3. Claude Code: Review
4. Git: Commit with sprite asset

Phase 4: Implement Step 10 (Collision SFX)
1. ElevenLabs: Generate collision sound effect
2. Claude Code: Add sound playback on collision
3. Claude Code: Review
4. Git: Commit with audio asset

Phase 5: Recovery if stuck
1. RepoPrompt: Bundle codebase
2. Claude Code: Paste bundled code, ask for full diagnosis
3. Claude Code: Implement fix
4. Git: Commit fix

Phase 6: Finalization
1. Suno: Generate background music
2. Claude Code: Add music to game loop
3. Full game test
4. Git: Final commit
5. Deploy
```
```

--------------------------------

### Quick Start Steps

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/00-START-HERE.md

Follow these steps for a rapid introduction to Vibe Coding.

```text
1. Read this file (2 min)
2. Read README.md (3 min)
3. Decide: Is Vibe Coding right for me? (5 min)
4. If yes: Start 08-quick-start-checklist.md (20 min)
```

--------------------------------

### Run Development Server

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/08-quick-start-checklist.md

Start the development server to test your application. Verify that it launches without errors.

```bash
npm run dev
```

--------------------------------

### Specific Example Prompt Structure

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/04-best-practices-patterns.md

Employ this structure when a general request needs precise definition. Providing an exact example removes ambiguity and guides the AI to generate code that matches a specific behavior or output.

```plaintext
I want [general request].

Example of what I mean:
[Show exact input/output or behavior]

If user does X, game should do Y exactly.
```

--------------------------------

### Install nvm (Node Version Manager)

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/05-tool-ecosystem-reference.md

Installs nvm, a tool for managing multiple Node.js versions. Run this script to set up nvm on your system.

```bash
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash
```

--------------------------------

### Clear Constraints Prompt Example

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/04-best-practices-patterns.md

An example demonstrating how to apply the Clear Constraints prompt structure for a UI feature. It specifies technologies, code limits, and behavioral requirements.

```plaintext
I want to add a pause menu that overlays the game.

Constraints:
1. Use React and Tailwind only; no styled-components
2. Keep PauseMenu component under 80 lines
3. No full-page refresh; just pause the game loop
4. Must pass: Click pause → game stops; click resume → resumes; ESC also resumes

Plan Mode: Show me the component structure and state management approach first.
```

--------------------------------

### Initialize Project and Start Claude

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/02-tools-and-commands.md

Basic commands to navigate to your project directory and initialize a Claude session or use Codex.

```bash
cd /path/to/project
claude
```

```bash
codex
```

--------------------------------

### Install Three.js Dependency

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/08-quick-start-checklist.md

Install the Three.js library for 3D graphics. Add any other dependencies as specified in your tech-stack.md.

```bash
npm install three
```

--------------------------------

### Codex Workflow: Initial Setup

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/02-tools-and-commands.md

Use the `/init` command to generate rules from project documentation. Review and manually edit the generated CLAUDE.md for 'Always' rules.

```bash
# Generate rules from project documentation
/init

# Review the generated CLAUDE.md
# Manually edit to add/refine "Always" rules
```

--------------------------------

### Codex Workflow: Pre-Implementation Clarification

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/02-tools-and-commands.md

Start a new session with `/new` for clarity review. Prompt Codex to read documents and identify any questions regarding the implementation plan.

```bash
# Start new session for clarity review
/new

# Prompt:
# Read all documents in /memory-bank. 
# Is implementation-plan.md clear? 
# What are your questions?
```

--------------------------------

### Install Codex CLI

Source: https://github.com/enzed/vibe-coding/blob/main/README.md

Install the Codex CLI globally using npm. This command is used for setting up the Codex development environment.

```bash
npm i -g @openai/codex
```

--------------------------------

### Specific Example Prompt Example

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/04-best-practices-patterns.md

An example of the Specific Example prompt for AI-driven enemy AI behavior. It details a precise patrol pattern, including movement, timing, and repetition.

```plaintext
I want the enemy AI to patrol in a pattern.

Example of what I mean:
- Enemy starts at position (0, 0)
- Moves right 5 units over 5 seconds
- Pauses for 1 second
- Moves left 5 units over 5 seconds
- Repeats pattern forever until shot
- Each enemy patrols independently
```

--------------------------------

### Example Architecture.md Entry

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/07-faq-troubleshooting.md

Illustrates how to document a file's purpose, props, and constraints in Architecture.md. This complements the code by explaining the 'why' behind its existence.

```markdown
## Ship.jsx
- Purpose: Renders player spaceship mesh
- Receives props from Scene.jsx (position, velocity)
- Emit to parent (collision events future)
- Constraint: Keep under 80 lines (split if larger)
```

--------------------------------

### Custom Claude Code Command Example

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/01-methodology-workflow.md

An example of a custom command to trigger a deep-dive explanation of a specific argument.

```bash
/explain $arguments
```

--------------------------------

### Install ESLint for Development

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/08-quick-start-checklist.md

Install ESLint as a development dependency using npm. ESLint is a linter that helps identify and fix code quality issues.

```bash
npm install --save-dev eslint
```

--------------------------------

### Prompt for Executing Implementation Steps

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/01-methodology-workflow.md

This prompt guides the AI to execute a specific step from the implementation plan. It includes instructions for updating progress and architecture documentation after validation.

```bash
Read all files in /memory-bank. 
Proceed with Step N of the implementation-plan. 
I will run the tests. 
Do not start Step N+1 until I validate the tests. 
Once I validate them:
- Open progress.md and document what you did
- Add architectural insights to architecture.md
```

--------------------------------

### Install Claude Code

Source: https://github.com/enzed/vibe-coding/blob/main/README.md

Install the Claude Code CLI globally using npm. This command is used for setting up the Claude Code development environment.

```bash
npm i -g @anthropic-ai/claude-code
```

--------------------------------

### Handling Feature Creep During Implementation

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/07-faq-troubleshooting.md

This example demonstrates how to respond to feature requests during the implementation phase. It categorizes requests and suggests appropriate actions to maintain focus on the core game development.

```text
Request: "Can we add achievements system?"

Status: Currently at Step 12/30 of base game

Response: Achievements are nice-to-have. Two options:
1. Add to Step 25 (post-core-systems, before final polish)
2. Implement after base game complete in separate feature phase

Recommendation: Option 2 (doesn't risk base game progress)

Action: Create achievement-implementation.md after Step 30 completes
```

--------------------------------

### Codex Workflow: Implementation Step

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/02-tools-and-commands.md

Start a new session with `/new` for each implementation step. Prompt Codex to read relevant files and proceed with the plan. Run tests before the next step and request documentation updates afterward.

```bash
# Start new session for each step
/new

# Prompt:
# Read all files in /memory-bank.
# Proceed with Step N of the implementation-plan.
# (I will run tests before Step N+1)

# After validation, request documentation update:
# Update progress.md and architecture.md accordingly
```

--------------------------------

### Example Project Technology Stack

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/03-memory-bank-reference.md

This markdown block details the technology stack for a project, including frontend, backend, and real-time components, along with rationale and trade-offs.

```markdown
# Asteroid Miner — Technology Stack

## Frontend
- Framework: Vite + React 18
- 3D: Three.js 173+
- Styling: Tailwind CSS
- Network: ws (WebSocket)
- Package Manager: npm

## Backend
- Runtime: Node.js 20+
- Framework: Express 4.18+
- Database: PostgreSQL 15+
- Deployment: Docker + Render

## Real-Time
- Protocol: WebSocket (Socket.io optional)
- Target latency: <100ms for multiplayer

## Rationale
- React chosen for reactive state and component reuse
- Three.js for web-based 3D graphics
- Express for simplicity and ecosystem
- PostgreSQL for relational game state
- Docker for reproducible deployment

## Trade-offs
- Complexity: WebSocket latency vs HTTP simplicity → WebSocket chosen
- Scope: Backend multiplayer vs single-player only → Multiplayer deferred

```

--------------------------------

### Codex Workflow: Context Management

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/02-tools-and-commands.md

Use `/context` to check context usage. Use `/compact` if context is below 60%, or `/clear` to start a fresh chat.

```bash
# Check context usage
/context

# Compress if below 60%
/compact

# Or start fresh chat
/clear
```

--------------------------------

### Markdown Usage Pattern: Start of Step

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/03-memory-bank-reference.md

This markdown pattern should be used at the beginning of each new development step. It includes the step number, name, status, start date, and developer.

```markdown
## Step N: [Name]
**Status:** IN PROGRESS
**Started:** [Date]
**Developer:** [AI assistant]
```

--------------------------------

### Install Prettier for Development

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/08-quick-start-checklist.md

Install Prettier as a development dependency using npm. Prettier is a code formatter that helps maintain consistent code style.

```bash
npm install --save-dev prettier
```

--------------------------------

### Manual Testing Checklist Example

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/04-best-practices-patterns.md

Create a detailed checklist for each development step to ensure explicit validation and prevent overlooking edge cases. This checklist can be automated later.

```markdown
## Step 5: Energy System Test Checklist

- [ ] Game starts with 100 energy
- [ ] Mining asteroid (collision) drains 1 energy per collision
- [ ] Energy display updates in real-time
- [ ] Energy pickup restores 25 energy
- [ ] Energy bar color changes when below 25% (red vs green)
- [ ] Game pauses when energy reaches 0
- [ ] Energy cannot go negative
- [ ] Page refresh preserves energy value (from localStorage)
- [ ] No console errors during 2-minute play session
```

--------------------------------

### Troubleshoot Implementation Errors

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/02-tools-and-commands.md

Steps to take when an implementation goes wrong, including reviewing rewind options, checking commit history, resetting to a known state, or starting a new attempt.

```bash
# Review /rewind options
/rewind
```

```bash
# Check recent commits
git log --oneline -10
```

```bash
# Reset to last known good state
git reset --hard [commit_hash]
```

```bash
# Start fresh implementation attempt
/new
```

--------------------------------

### Example Game Design Document (GDD)

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/03-memory-bank-reference.md

An example of a game design document for 'Asteroid Miner', outlining its overview, core mechanics, visual style, and success criteria.

```markdown
# Asteroid Miner — Game Design Document

## Overview
A casual 3D web-based asteroid mining game where players 
guide a spaceship to collect ore and avoid obstacles.

Target Audience: Ages 13+, casual browser gamers
Genre: Action-Arcade
Unique Value: Relaxing pace with strategic power-ups

## Core Mechanics
- **Mining:** Collision with asteroids collects ore automatically
- **Energy:** Mining depletes energy; pickups restore it
- **Obstacles:** Enemy ships patrol; collision causes damage
- **Power-ups:** Shield, speed boost, magnet for 10 seconds each

## Visual Style
- 3D asteroids using Three.js
- Neon color scheme (cyan, magenta, white)
- Minimalist HUD overlay
- Particle effects for impacts and pickups

## Success Criteria
- MVP: Mine, energy, basic enemy, one power-up type
- Quality: 60 FPS, mobile-touch compatible
- Scope out: Multiplayer, procedural generation, campaigns
```

--------------------------------

### Asteroid Collision Detection Example

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/04-best-practices-patterns.md

An example of a step-based implementation for a game feature, focusing on collision detection between a player ship and asteroids. It outlines objectives, requirements, acceptance criteria, and notes for clarity.

```markdown
## Step 3: Asteroid Collision Detection

### Objective
Implement collision detection so player earns ore when ship touches asteroid.

### Requirements
- Detect when ship bounding box overlaps asteroid bounding box
- Increment ore counter by 1 per collision
- Respawn asteroid at random position after collision
- Display ore count on screen at top-left
- Only increment counter once per collision (not continuously)

### Acceptance Criteria
1. Run game in browser
2. Steer ship into asteroid
3. Verify:
   - Ore counter in top-left increments by 1
   - Asteroid disappears and reappears elsewhere
   - No console errors
4. Repeat collision 5 times
5. Verify counter matches 5

### Notes
- Use simple AABB (bounding box) collision; pixel-perfect not required
- Recommend using Three.js bounding box helpers for debugging
```

--------------------------------

### Architecture-First Approach - Data Structures

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/04-best-practices-patterns.md

An example prompt for the architecture-first approach, focusing on defining data structures before implementation. It outlines the desired player state and message format for a multiplayer system.

```markdown
Prompt: Before we implement the multiplayer system, 
let me sketch the data structures.

Player state should be:
{
  id: UUID,
  position: {x, y, z},
  energy: number,
  score: number,
  lastUpdate: timestamp
}

Message format from client to server:
{
  type: "playerMove",
  payload: {x, y, z},
  clientTimestamp: number
}

Is this design sound? 
Any improvements before we implement?
```

--------------------------------

### Example 'Always' Rules for AI Actions

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/01-methodology-workflow.md

These rules are critical for ensuring AI actions adhere to project architecture and context. They should be reviewed before each AI action.

```markdown
# IMPORTANT:
# Always read memory-bank/@architecture.md before writing any code.
# Always include entire database schema in context.
# Always read memory-bank/@game-design-document.md before writing any code.
# After adding a major feature or completing a milestone, update memory-bank/@architecture.md.
```

--------------------------------

### Progressive Refinement Prompt Steps

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/04-best-practices-patterns.md

This pattern is useful when requirements are initially unclear. It involves a step-by-step approach, starting with a rough idea and progressively refining details through collaboration with the AI.

```plaintext
Step 1 - Rough idea:
Prompt: I want scoring system. What should the mechanics be?

[AI responds with options]

Step 2 - Pick best idea:
Prompt: Let's go with option 2. Here's more detail...

Step 3 - Refine details:
Prompt: [Clarify edge cases based on AI's option 2]

Step 4 - Implement:
Prompt: Implement exactly this scoring system...
```

--------------------------------

### Manage Node.js Versions with nvm

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/05-tool-ecosystem-reference.md

Commands to list remote Node.js versions, install a specific version, use it in the current shell, and set a default version.

```bash
# List available Node versions
nvm list-remote

# Install specific version
nvm install 20

# Use specific version in current shell
nvm use 20

# Set default version
nvm alias default 20
```

--------------------------------

### Markdown Template for Pending Step

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/03-memory-bank-reference.md

Use this template to indicate future steps that have not yet been started. It includes the step number and a placeholder for the next steps.

```markdown
## ⏳ Step 4: Pending
[Next steps not yet started]
```

--------------------------------

### Generate SFX with ElevenLabs

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/05-tool-ecosystem-reference.md

This prompt is for generating sound effects using ElevenLabs. Specify the desired sound characteristics such as sharpness, brightness, duration, pitch, and envelope. This example details creating a 'ping' sound for notifications.

```plaintext
Generate a sharp, bright "ping" sound effect. 
Duration: 0.5 seconds.
Pitch: High (2000 Hz).
Envelope: Quick attack, quick decay.
Use case: Ore collection notification sound.
```

--------------------------------

### Example Modularity Rules for AI

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/04-best-practices-patterns.md

These rules guide an AI agent to enforce strict modularity in code generation, preventing monolithic structures and promoting single-responsibility components. They are intended for use in AI configuration files like CLAUDE.md.

```markdown
# STRICT MODULARITY
- Never create functions longer than 50 lines
- Each component file handles ONE responsibility
- No monolithic App.jsx containing all game logic
- Create utils/, hooks/, components/ directories with clear separation

# Discourage monoliths:
- When I draft a file over 100 lines, ask if it can be split
- When a component does rendering AND business logic, suggest separation
- When a file imports more than 5 other files, suggest restructuring
```

--------------------------------

### Initial Prompt for Clarifying Implementation Plan

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/01-methodology-workflow.md

Use this prompt to have the AI review the implementation plan and ask clarifying questions. Ensure all documents in the memory bank are accessible.

```bash
Read all documents in /memory-bank. 
Is implementation-plan.md clear? 
What are your questions to make it 100% clear for you?
```

--------------------------------

### Initialize New Node.js Project

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/08-quick-start-checklist.md

Initialize a new Node.js project using npm. This command creates a package.json file.

```bash
npm init -y
```

--------------------------------

### Initialize Git Repository

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/08-quick-start-checklist.md

Initialize a new Git repository in your project directory. This is essential for version control.

```bash
git init
```

--------------------------------

### Jest Example Test for Collision Detection

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/05-tool-ecosystem-reference.md

An example Jest test case for a 'Collision Detection' module. It checks if the 'checkCollision' function correctly returns true when a ship and asteroid are at the same position.

```javascript
describe('Collision Detection', () => {
  test('should increment ore counter on asteroid collision', () => {
    const ship = { position: {x: 0, y: 0} }
    const asteroid = { position: {x: 0, y: 0} }
    const result = checkCollision(ship, asteroid)
    expect(result).toBe(true)
  })
})
```

--------------------------------

### Commit Implementation Plan

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/08-quick-start-checklist.md

Stage and commit the updated implementation-plan.md after addressing Claude's questions.

```bash
git add implementation-plan.md && git commit -m "docs: clarify implementation plan"
```

--------------------------------

### Implementing with Clear Requirements

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/07-faq-troubleshooting.md

Provide precise requirements to the AI after clarifying behavior and architecture, ensuring a clear path for implementation.

```markdown
Prompt: Let's go with approach B (state machine).

Requirements:
- Enemy starts in PATROL state
- In PATROL: Move between waypoint A (0,0) and B (5,0)
- Takes 2 seconds to travel A→B, 2 seconds B→A
- In ATTACK state: Chase player (implement later)
- Transition: PATROL → ATTACK when player within 10 units

Implement Step 7 with these exact requirements.
```

--------------------------------

### Create React Project with Vite

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/08-quick-start-checklist.md

Scaffold a new React project using Vite. This command sets up a basic React application structure.

```bash
npm create vite@latest . -- --template react
npm install
```

--------------------------------

### Launch Claude Code from Terminal

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/02-tools-and-commands.md

Launches the Claude Code application from the terminal. This is the primary command to start an interactive session.

```bash
claude
```

--------------------------------

### Stop and Restart Claude Session

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/02-tools-and-commands.md

Commands to halt an unresponsive Claude session and initiate a fresh start, either in the same or a new terminal.

```bash
# Stop current session
Ctrl+C
```

```bash
# Start fresh
/clear
```

```bash
# Or in new terminal
claude --dangerously-skip-permissions
```

--------------------------------

### Codex Prompting Template Structure

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/02-tools-and-commands.md

Use this template to guide Codex's initial thinking process, emphasizing precision and thoroughness.

```text
Think as long as needed to get this right. I am not in a hurry. 
What matters is that you follow precisely what I ask you and execute it perfectly. 
Ask me questions if I am not precise enough.
```

--------------------------------

### Format Code with Prettier

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/05-tool-ecosystem-reference.md

Automatically formats code in the 'src/' directory using Prettier. Run this command after installing Prettier as a dev dependency.

```bash
npx prettier --write src/
```

--------------------------------

### Manage Stale Context in Claude

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/02-tools-and-commands.md

Options for dealing with outdated context, including compacting, clearing, or committing changes to start a new session.

```bash
# Compact existing context
/compact
```

```bash
# Or clear and restart
/clear
```

```bash
# Or commit and start new session
git add .
git commit -m "WIP: [description]"
/new
```

--------------------------------

### Implementation Plan Step Format

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/01-methodology-workflow.md

This markdown format is used to define individual steps in the project implementation plan. Each step should be small, testable, and include clear objectives and acceptance criteria.

```markdown
## Step 1: [Feature/Component Name]
### Objective
[Clear description of what to build]

### Acceptance Criteria / Test
[Explicit, testable validation that step is complete]

## Step 2: [Next Feature]
...
```

--------------------------------

### Seeking Architecture Advice for Implementation

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/07-faq-troubleshooting.md

Ask for architectural guidance by presenting options and requesting the simplest, most maintainable approach.

```markdown
Prompt: For patrol behavior, should I:
A) Calculate waypoints in advance and loop through them?
B) Use a state machine (patrol state, attack state)?
C) Generate waypoints randomly each time?

Which approach is simplest and most maintainable?
```

--------------------------------

### Recovering from Off-Track Implementation with /rewind

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/07-faq-troubleshooting.md

Use the `/rewind` command for faster recovery from incorrect implementation steps. Choose a checkpoint before the issue occurred.

```markdown
/rewind

# Choose the checkpoint before things went wrong
# E.g., if Step 5 implementation is broken, rewind to before Step 5

# Then ask Claude to retry Step 5 with different approach or clearer requirements
```

--------------------------------

### Claude Code Depth Control Phrases

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/01-methodology-workflow.md

Phrases to increase the reasoning depth of Claude Code. Start with 'think' and progress to 'ultrathink' for more intensive reasoning.

```bash
think
```

```bash
think hard
```

```bash
think harder
```

```bash
ultrathink
```

--------------------------------

### Memory-Driven Session Structure

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/04-best-practices-patterns.md

Illustrates a pattern for managing AI development sessions by leveraging project files for context. This approach ensures the AI has the necessary information without relying on chat history, using files like `progress.md` and `architecture.md`.

```markdown
**Session 1:**
```
Prompt: Read all files in /memory-bank. 
Is implementation-plan.md clear? 
What are your 5-10 questions to make it 100% clear?
```

**Session 2 (after clarifications):**
```
Prompt: Read all files in /memory-bank (especially the clarified implementation-plan). 
Now proceed with Step 1.

After you complete Step 1:
1. I will test it
2. Open progress.md and document what you did
3. Update architecture.md with the new files/modules created
```

**Session 3+:**
```
Prompt: Read all files in /memory-bank, especially progress.md to see what's been done.
Proceed with Step 2.

[Continue pattern]
```
```

--------------------------------

### Clarify Implementation Plan with Claude

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/08-quick-start-checklist.md

Ask Claude to identify unclear aspects of the implementation plan and pose clarifying questions.

```plaintext
Read game-design-document.md, tech-stack.md, and implementation-plan.md.

Is the implementation-plan.md clear? What are your 5-10 questions to make it 100% clear?
```

--------------------------------

### Vibe Coding Tool Stack Overview

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/05-tool-ecosystem-reference.md

This section lists the core, highly recommended, and optional tools for vibe coding projects. It also details asset generation tools and optional workflow tools.

```markdown
## Summary: Recommended Tool Stack for Vibe Coding

### Core Tools (Required)
- **Claude Code** (primary AI assistant)
- **Git** (version control; commit after each step)
- **VSCode** (IDE with Claude Code extension)

### Highly Recommended Additions
- **Codex 5.5** (secondary AI for small edits)
- **Node Version Manager** (nvm or fnm)
- **Prettier** (auto-formatting)
- **ESLint** (code quality)

### Optional but Useful
- **BrowserTools** (JavaScript debugging)
- **Superwhisper** (voice prompting)
- **RepoPrompt** (emergency full-context sharing)

### Asset Generation (Per Project Needs)
- **ChatGPT + DALL-E** (2D sprites and images)
- **Trellis or Tripo** (3D models)
- **Suno** (music)
- **ElevenLabs** (sound effects and voice-overs)

### Optional Workflow Tools
- **GitGraph** (git visualization)
- **Obsidian** (personal notes)
- **Jest** (automated testing)
```

--------------------------------

### Step-Based Implementation Structure

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/04-best-practices-patterns.md

Defines a clear, structured format for breaking down AI development tasks into manageable steps. Use this to ensure clarity before coding begins and to enable objective progress tracking.

```markdown
## Step N: [Feature Name]

Objective: [One sentence describing what to build]

Requirements:
- [Requirement 1]
- [Requirement 2]
- [Requirement 3]

Acceptance Criteria:
[Specific test or validation]

Notes:
[Optional clarifications]
```

--------------------------------

### Architectural Decision - localStorage vs IndexedDB

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/03-memory-bank-reference.md

Explains the choice of localStorage over IndexedDB for game state persistence, based on simplicity and current state size.

```markdown
### Decision 2: localStorage instead of IndexedDB
**Rationale:** Simpler API, sufficient for <1MB game state  
**Trade-off:** 5MB storage limit (vs 50MB+)
**Reversible:** Yes, can migrate if high scores feature added
```

--------------------------------

### Claude Code Commands

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/01-methodology-workflow.md

Common commands for managing context and state within Claude Code. Use /rewind to roll back changes or /clear to start a fresh chat.

```bash
/rewind
```

```bash
/clear
```

```bash
/compact
```

```bash
/context
```

```bash
/init
```

--------------------------------

### Import Graph - useGameState.js Dependencies

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/03-memory-bank-reference.md

Illustrates the dependencies for the useGameState.js hook, primarily constants.

```markdown
```
useGameState.js
  └── imports: constants.js
```
```

--------------------------------

### Browser DevTools Debugging Steps

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/04-best-practices-patterns.md

Utilize browser developer tools (F12) for quick debugging without additional setup. This method allows for rapid iteration on bugs and visual debugging.

```text
Test failing: "Collision doesn't trigger ore increment"

Steps:
1. Open F12 → Console
2. Add temporary log statement in collision code
3. Reproduce collision
4. Check console output
5. If not logged, collision function not called
6. Use Elements tab to inspect ship/asteroid positions
7. If positions correct, collision logic is bug
```

--------------------------------

### Create Memory Bank Directory

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/08-quick-start-checklist.md

Use this command to create the main directory for your memory bank files.

```bash
mkdir memory-bank
```

--------------------------------

### File Directory Reference - /src/utils

Source: https://github.com/enzed/vibe-coding/blob/main/_autodocs/03-memory-bank-reference.md

Describes the utility functions and constants located in the /src/utils directory, covering game constants, collision logic, and spawning mechanisms.

```markdown
## /src/utils/
**Purpose:** Utility functions and constants

### constants.js
- Game constants (asteroid spawn rate, max energy, etc.)
- UI positioning and sizing
- Network configuration (future multiplayer)

### collision.js
- Pure collision detection algorithms
- Imported by useCollisionDetection.js

### spawn.js
- Asteroid spawning logic
- Random position generation within viewport
- Respawn timing
```