# LLM Implement Command Instructions

## Goal
Generate HTML/CSS/JS (and assets) for a site using its Design.md while preserving uniqueness and quality gates.

## Inputs
- Design.md for the site (aesthetics, layout, palette, motifs, prompts, uniqueness notes)
- Site directory: `sites/<domain-vX>/`

**Note:** The version suffix (`-vX`) in site directory paths is determined during PREPARE phase. Implement phase uses the existing versioned directories created by `tools/prepare/batch.sh`.

---

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ CRITICAL: READ ALL RULES BEFORE ANY ACTION ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

## General Rules (Main Agent AND Subagents)

These rules apply to **BOTH the main agent AND all subagents**. Include these in every subagent prompt.

### G1. Script Execution
**Run shell scripts directly (all Python scripts have .sh wrappers):**
- All shell scripts have shebangs (`#!/bin/bash`).
- Execute them directly: `tools/script.sh`
- **Do NOT** add `sh` or `bash` prefix (e.g., `bash tools/script.sh` is WRONG).

**NEVER run Python directly or create Python scripts:**
- Do NOT use `python3`, `python3.12`, `uv run python`, or any Python interpreter
- Do NOT create `.py` files for debugging, inspection, or any purpose
- ALL functionality is accessible via `.sh` wrappers — use those instead

```bash
# CORRECT
tools/implement/run.sh --batch 001
tools/implement/check-outputs.sh sites/example.com-v1
tools/implement/generate.sh sites/example.com-v1/DESIGN.md
tools/implement/start.sh example.com --root .

# WRONG — DO NOT call Python directly
python3 tools/implement/run.py ...         # WRONG
python3.12 tools/implement/run.py ...      # WRONG
uv run python3.12 tools/xxx.py ...         # WRONG — use .sh wrapper
./tools/implement/run.py ...               # WRONG
```

**AVOID — Absolute paths add unnecessary directory prefix:**

```bash
# WRONG — Uses absolute path to script (symlink source)
/Volumes/Common/QJoon/llm/wdmaker/tools/implement/start.sh domain.com --root /Volumes/Ephemeral/CMassM1

# WRONG — Uses absolute path to script AND arguments (repo path)
/Volumes/Ephemeral/CMassK1/tools/implement/check-outputs.sh /Volumes/Ephemeral/CMassK1/sites/example.com-v1

# CORRECT — Uses relative paths for both script and arguments
tools/implement/start.sh domain.com --root .
tools/implement/check-outputs.sh sites/example.com-v1
```

Scripts are symlinked into the repo; always use relative `tools/...` and `sites/...` paths.

### G2. No Invented Commands
- **DO NOT create new bash commands or scripts**
- **DO NOT use ad-hoc shell commands** (cat/ls/find/grep/wc/for-loops)
- Use ONLY the provided assist scripts listed below

**AVOID — Ad-hoc inline Python:**

```bash
# WRONG — Inline Python to inspect files
python3.12 -c "
import os
for f in os.listdir('sites/example.com-v1'):
    print(f)
"

# CORRECT — Use provided scripts
tools/implement/check-outputs.sh sites/example.com-v1
tools/check/file-stats.sh sites/example.com-v1
```

**AVOID — Creating ad-hoc debug scripts in TMP:**

```bash
# WRONG — Creating and running debug scripts
python3.12 /Volumes/Temp/WDMaker/CMassK1/debug_html.py
python3.12 /Volumes/Temp/WDMaker/CMassK1/check_css.py

# CORRECT — Use provided scripts for inspection
tools/check/verify-site.sh sites/example.com-v1
tools/check/html-check.sh sites/example.com-v1
```

**AVOID — Using non-existent or invented scripts:**

```bash
# WRONG — tools/status.sh does not exist
tools/status.sh --root . | grep example.com

# CORRECT — Use provided status scripts
tools/check/status-report.sh
tools/implement/status.sh <BATCH_ID>
```

**AVOID — Piping to grep:**

```bash
# WRONG — Piping output to grep
tools/check/status-report.sh | grep example.com

# CORRECT — Use script options for filtering, or read full output
tools/implement/status.sh <BATCH_ID>
```

### G3. No HEREDOC Pattern
- **NEVER use HEREDOC** (`<<EOF`, `<<'EOF'`, etc.) for ad-hoc file writing
- Use **Write tool** or **Filesystem MCP server** when writing new files
- **Note:** HEREDOC in provided scripts (e.g., `tools/*.sh`) is fine — this rule prohibits ad-hoc LLM usage only

```bash
# WRONG — DO NOT USE HEREDOC for ad-hoc file creation
cat <<EOF > index.html
<!DOCTYPE html>
...
EOF

# CORRECT — Use Write tool or MCP
# (Use the Write tool in Claude Code to create files)
```

### G4. Temp Directory
- Use `${TMP}` from `.wdmaker/config.toml` for temporary files
- **NEVER use `/tmp`** — always use the configured temp directory

### G5. Directory Creation
- **Use provided scripts** for creating/preparing directories (e.g., `tools/prepare/batch.sh`)
- **NEVER use `mkdir`** directly — directories are scaffolded by workflow scripts
- **DO NOT create `.gitkeep`**, `.keep`, or similar placeholder files

### G6. Preserve Reports
- **DO NOT delete** generated reports (implementation reports, batch reports, logs)
- **DO NOT make per-site reports** (design start/finish report, implement start/finish report)
- Reports in `.smbatcher/batches/`, `.smbatcher/runs/`, `${TMP}/` are historical records

### G7. Ignore Accessibility and Performance
- **DO NOT implement for accessibility** — skip ARIA attributes, screen reader support, keyboard navigation, focus styles
- **DO NOT implement for performance** — skip lazy loading, code splitting, minification, caching strategies
- Focus purely on **visual implementation, creativity, and design fidelity**

---

## Claude Code Specific Rules

These rules are specific to Claude Code orchestration.

### C1. Model Restriction
- **DO NOT use Sonnet model** for implementation tasks
- Use Opus for implementation work (higher quality, better code generation)

### C2. Maximum Effort — Ignore Token Budget
- **ALWAYS ignore token budget constraints** — prioritize quality over efficiency
- Put **maximum creative effort** into every implementation
- Write complete, detailed code with rich visual effects
- Never truncate or abbreviate to save tokens
- The goal is the **best possible visual output**, not the shortest response

### C3. Subagent Assignment — ONE SITE PER SUBAGENT
- Each subagent implements **EXACTLY ONE site**, then terminates
- **NEVER assign 2+ sites** to a single subagent
- Context exhaustion is UNRECOVERABLE — this is not optional
```
CORRECT:   10 subagents × 1 site each = 10 sites
INCORRECT: 10 subagents × 8 sites each = 80 sites ← WILL FAIL
```

### C4. Subagent Execution Mode — Foreground, Not Background
- **ALWAYS launch subagents in foreground mode** (synchronous), NOT background mode
- This means: Do NOT use `run_in_background: true` for implementation subagents
- **This does NOT mean sequential** — you CAN and SHOULD launch multiple subagents in parallel within a single message
- Wait for all subagents in the current wave to complete before launching the next wave

### C5. Status Code Updates via Scripts
**NEVER modify REGISTRY.md or batch files directly. Use scripts for all status transitions.**

| Role | Status | Script | When |
|------|--------|--------|------|
| Main | O | `tools/implement/lock.sh <BATCH>` | Before starting implementation |
| Subagent | i | `tools/implement/start.sh <domain>` | Before starting implementation work |
| Subagent | I | `tools/implement/complete.sh <domain>` | After implementation validated |
| Main | Q | `tools/implement/finish.sh --batch <BATCH>` | After all subagents complete |

**Flow:**
```
Main agent: O (open for implement via lock.sh)
     ↓
Subagent: i (implement started) → [write code] → I (implement complete)
     ↓
Main agent: Q (done via finish.sh)
```

---

## Assist Scripts Reference

### `tools/implement/start.sh`
**Purpose:** Mark a single site as implement-in-progress (i) in REGISTRY. Called by subagent at START of implementation.

```bash
tools/implement/start.sh example.com --root .
```

**Actions:**
- Acquires REGISTRY.lock
- Updates domain status: O → i
- Records timestamp

**Options:**
- `<domain>` — Domain to mark (required)
- `--root <path>` — Repository root (default: .)

---

### `tools/implement/complete.sh`
**Purpose:** Mark a single site as implement-complete (I) in REGISTRY. Called by subagent at END of implementation.

```bash
tools/implement/complete.sh example.com --root .
```

**Actions:**
- Validates required files exist (index.html, styles.css, script.js)
- Runs check-outputs.sh validation (unless --skip-validation)
- Acquires REGISTRY.lock
- Updates domain status: i → I
- Records timestamp

**Options:**
- `<domain>` — Domain to mark (required)
- `--root <path>` — Repository root (default: .)
- `--skip-validation` — Skip implementation validation

---

### `tools/implement/finish.sh`
**Purpose:** Mark all implemented sites (I) in a batch as done (Q). Called by main agent after all subagents complete.

```bash
tools/implement/finish.sh --batch 001 --root .
```

**Actions:**
- Acquires REGISTRY.lock
- Transitions all I-status sites in batch to Q
- Records timestamp

**Options:**
- `--batch <ID>` — Batch ID (required)
- `--root <path>` — Repository root (default: .)

---

### `tools/implement/lock.sh`
**Purpose:** Lock batch and transition status D→O for implementation with auto-detection.

```bash
# AUTO-DETECTION (default) — finds and claims next batch automatically
tools/implement/lock.sh

# MANUAL OVERRIDE — specify batch explicitly
tools/implement/lock.sh <BATCH_ID>
```

**Auto-Detection Behavior (no arguments):**
- Uses `find-next.sh --claim` for atomic find + claim (prevents race conditions)
- Priority: batch with `i` (continue) → `O` (start) → `D` (transition)
- Multiple subagents can run simultaneously without collision

**Actions:**
- Acquires exclusive lock on REGISTRY.lock
- Transitions all batch sites from D (Designed) to O (Open for implement)
- Creates `batch-<ID>-implement.md` tracker if not exists
- Records locked domains in tracker

**Options:**
- `<BATCH_ID>` — Optional. The batch ID (e.g., 001). Auto-detects if omitted.

**Exit codes:**
- 0 = Success (locked D→O or batch already open/in progress)
- 1 = Batch not found or no D/O/i domains to lock
- 2 = Registry not found

---

### `tools/implement/run.sh`
**Purpose:** Queue manager for implementation workflow with auto-detection. Does NOT generate site code.

```bash
# AUTO-DETECTION (default) — finds and claims next batch automatically
tools/implement/run.sh

# MANUAL OVERRIDE — specify batch explicitly
tools/implement/run.sh --batch <BATCH_ID> --concurrency <N>
```

**Auto-Detection Behavior (no arguments or `--batch auto`):**
- Uses `find-next.sh --claim` for atomic find + claim (prevents race conditions)
- Priority: batch with `i` (continue) → `O` (start) → `D` (transition)
- Multiple subagents can run simultaneously without collision

**Actions:**
- Calls `lock.sh` to acquire batch
- Collects domains from registry for the batch
- Transitions status: O → i (in-progress) → I (implemented) → Q (queued/complete)
- Runs `generate.sh`, `validate.sh`, `check-outputs.sh` for each site
- Handles retries and cleanup on failure
- Logs to `.smbatcher/runs/implement-<timestamp>.log`

**Options:**
- `--batch <ID>` — Batch ID or 'auto' (default: auto, truly auto-detects with atomic claiming)
- `--concurrency <N>` — Worker count (default: 4)
- `--dry-run` — Simulate without writing
- `--root <path>` — Override repository root
- `--max-retries <N>` — Retries per site on failure (default: 1)

**Important:** The actual HTML/CSS/JS code must be authored by the LLM coding tool. This script only orchestrates the queue and validation.

---

### `tools/implement/generate.sh`
**Purpose:** Prepare assets directory for site implementation.

```bash
tools/implement/generate.sh <DESIGN.md>
```

**Actions:**
- Creates `assets/` directory if not exists
- Does NOT generate placeholder HTML/CSS/JS (LLM must author)

**Options:**
- `<DESIGN.md>` — Path to the design file (e.g., sites/example.com-v1/DESIGN.md)

---

### `tools/implement/check-outputs.sh`
**Purpose:** Validate HTML/CSS/JS presence for a site directory.

```bash
tools/implement/check-outputs.sh <site-dir>
```

**Checks:**
- index.html exists
- styles.css exists
- script.js exists

**Output:**
- "ok" if all required files present
- "missing: <list>" if any files missing

**Exit codes:**
- 0 = All files present
- 1 = Missing required files

---

### `tools/implement/status.sh`
**Purpose:** Show registry entries for a batch with auto-detection.

```bash
# AUTO-DETECTION (default) — shows active/latest batch
tools/implement/status.sh

# MANUAL OVERRIDE — show specific batch
tools/implement/status.sh <BATCH_ID>
```

**Auto-Detection Behavior (no arguments):**
- Finds the active batch (with non-Q status sites)
- Shows all entries for that batch
- Read-only operation (no claiming needed)

**Output:**
- Registry lines matching the batch ID
- "No entries for batch <ID>" if none found

---

### `tools/shared/validate.sh`
**Purpose:** Shared HTML/asset validation checks using BeautifulSoup.

```bash
tools/shared/validate.sh <index.html>
```

**Functions:**
- `validate_html(file_path)` — Check for `<html>` root element, return errors list
- `ensure_assets(asset_dir)` — Verify assets directory exists

**Usage:**
- Called by `run.sh` during implementation validation
- Returns list of error strings; empty list means valid

---

### `tools/check/verify-site.sh`
**Purpose:** Comprehensive site verification — runs all checks in sequence.

```bash
tools/check/verify-site.sh <site-dir>
tools/check/verify-site.sh sites/example.com-v1
```

**Actions:**
1. Checks required files exist (index.html, styles.css, script.js)
2. Runs HTML structure check via `html-check.sh`
3. Runs JavaScript syntax check via `js-syntax.sh`
4. Shows file statistics via `file-stats.sh`
5. Checks for DESIGN.md presence

**Exit codes:**
- 0 = All checks passed
- 1 = One or more checks failed

---

### `tools/check/html-check.sh`
**Purpose:** Check HTML structure for required elements.

```bash
tools/check/html-check.sh <site-dir>
tools/check/html-check.sh sites/example.com-v1
```

**Checks:**
- DOCTYPE declaration
- `<html>`, `<head>`, `<body>` tags
- `<title>` tag
- Viewport meta tag
- CSS link or inline styles
- JavaScript reference
- Closing `</html>` tag

**Exit codes:**
- 0 = HTML structure valid
- 1 = Structural issues found

---

### `tools/check/js-syntax.sh`
**Purpose:** Check JavaScript syntax using Node.js.

```bash
tools/check/js-syntax.sh <site-dir>
tools/check/js-syntax.sh sites/example.com-v1
```

**Actions:**
- Finds all .js files in site directory (maxdepth 2)
- Runs `node -c` on each file to check syntax
- Reports pass/fail for each file

**Exit codes:**
- 0 = All JavaScript files valid
- 1 = Syntax errors found

---

### `tools/check/file-stats.sh`
**Purpose:** Show file statistics for a site directory.

```bash
tools/check/file-stats.sh <site-dir>
tools/check/file-stats.sh sites/example.com-v1
```

**Output:**
- Line counts and file sizes for HTML, CSS, JS files
- Total lines and KB

**Example:**
```
HTML:
  index.html           150 lines    5.2 KB

CSS:
  styles.css           200 lines    4.1 KB

JavaScript:
  script.js            100 lines    3.0 KB
---
TOTAL: 450 lines, 12.3 KB
```

---

### `tools/check/design-compliance.sh`
**Purpose:** Check implementation compliance against DESIGN.md specifications.

```bash
tools/check/design-compliance.sh <site-dir>
tools/check/design-compliance.sh sites/example.com-v1
```

**Checks:**
1. **Color Palette** — Verifies hex colors from DESIGN.md appear in CSS
2. **Typography** — Checks specified fonts are used
3. **CSS Animations** — Counts @keyframes and transitions
4. **Performance Patterns** — Checks for will-change, transforms, requestAnimationFrame, etc.
5. **JavaScript Features** — Counts classes, functions, event listeners
6. **Accessibility** — ARIA attributes, focus styles, keyboard handling
7. **External Dependencies** — External scripts, images, fonts

**Output:**
- Pass/Warn/Fail counts per category
- Summary: FULL COMPLIANCE, PARTIAL COMPLIANCE, or COMPLIANCE ISSUES FOUND

**Exit codes:**
- 0 = No failures (may have warnings)
- 1 = Compliance issues found

---

## Prohibited vs Alternatives

| ❌ Prohibited | ✅ Use Instead |
|--------------|----------------|
| `cat/less/head/tail` file inspection | `tools/implement/check-outputs.sh <site-dir>` or `tools/implement/status.sh <BATCH>` |
| `ls/find/wc/globs` directory listing | `tools/design/check-dirs.sh --batch-id <ID> --root .` or `tools/check/file-stats.sh <site-dir>` |
| `grep "pattern"` searching | `tools/implement/status.sh <BATCH>` |
| `for f in *.html; do` loops | `tools/implement/run.sh --batch <ID>` (handles queue) |
| `mkdir -p` directory creation | `tools/implement/generate.sh <DESIGN.md>` or `tools/prepare/batch.sh` |
| `python3 script.py` | `tools/.../<script>.sh` (shell wrappers) |
| `uv run python3.12 ...` | `tools/.../<script>.sh` (shell wrappers) |
| `cat <<EOF` HEREDOC | Write tool or Filesystem MCP |
| Creating new scripts | Use existing assist scripts only |
| Manual HTML validation | `tools/check/html-check.sh <site-dir>` or `tools/check/verify-site.sh <site-dir>` |
| Manual JS validation | `tools/check/js-syntax.sh <site-dir>` |
| Manual compliance check | `tools/check/design-compliance.sh <site-dir>` |

---

## Required Outputs
- `index.html` matching Design.md layout and tone
- `styles.css` implementing palette/typography/motifs
- `script.js` for interactions; ensure no console errors
- `assets/` for required media/SVGs
- No placeholders: deliver complete, production-ready files (LLM coding tools own the final content).

---

## Steps for LLM

> **Note:** General Rules (G1-G7) and Claude Code Rules (C1-C5) apply to ALL steps below.

### Quick Start: Auto-Detection Mode

For automated batch processing with atomic claiming (prevents race conditions):

```bash
# Auto-detects batch with D/O status and claims it atomically
tools/implement/run.sh
```

This uses `find-next.sh --claim` internally. Multiple agents can run simultaneously without collision.

For manual orchestration with subagents, follow the steps below.

---

### Step 1: Acquire Lock and Open Batch (Main Agent)

**Option A: Auto-Detection (Recommended)**
Execute:
  Tool: Bash
  Command: `tools/implement/lock.sh`
  Background:
  - Auto-detects next batch with D/O status
  - Uses atomic claiming (fcntl lock) to prevent race conditions
  - Multiple agents can run simultaneously without collision

**Option B: Manual Override**
Execute:
  Tool: Bash
  Command: `tools/implement/lock.sh "$BATCH"`
  Background:
  - `$BATCH` comes from: user input, conversation context, or `tools/shared/find-next.sh --registry .smbatcher/REGISTRY.md --phase implement`
  - find-next.sh returns the batch with D, O, or i status (unfinished implement work)
  - Handles D→O transition, lock + rollback on contention.

### Step 2: Launch Subagents (Main Agent)
Launch Opus subagents to implement sites in parallel. Assign only ONE site to each subagent. When launch a subagent, provide Subagent Launch Template to the subagent

**CRITICAL — PARALLEL LAUNCH WITH CONCURRENCY LIMIT:**
To execute subagents in parallel, you MUST send a **SINGLE message** containing **MULTIPLE Task tool calls**.

**IMPORTANT: Limit concurrent subagents to 10 maximum (total, not per batch).**
- If batch has > 10 sites, launch 10 subagents, wait for completion, then launch the next wave
- If processing multiple batches, the 10 limit applies across ALL batches combined
- This prevents context exhaustion and ensures stable parallel execution
- Reset the concurrent counter after all subagents in the wave complete before launching the next wave

Example for 10 sites in batch:
```
ONE message with 10 Task tool calls (MAXIMUM):
  Task #1: prompt="Implement ONLY site1.com... You are at repo root...", subagent_type="general-purpose"
  Task #2: prompt="Implement ONLY site2.com... You are at repo root...", subagent_type="general-purpose"
  Task #3: prompt="Implement ONLY site3.com... You are at repo root...", subagent_type="general-purpose"
  ...
  Task #10: prompt="Implement ONLY site10.com... You are at repo root...", subagent_type="general-purpose"
```

If batch has 25 sites:
```
WAVE 1 (10 subagents):
  Task #1-10: sites 1-10

WAIT FOR COMPLETION ← Reset counter here

WAVE 2 (10 subagents):
  Task #1-10: sites 11-20

WAIT FOR COMPLETION ← Reset counter here

WAVE 3 (5 subagents):
  Task #1-5: sites 21-25
```

**DO NOT** launch only one subagent at total, wait for it, then launch the next. Launch only one subagent is sequential, not parallel.
**DO** include all Task tool calls in the same response message.
**DO NOT** exceed 10 concurrent subagents — this causes context exhaustion and failures.

### Step 3: Implement Site (Subagent — Per Site LLM Work)

Execute #1: Mark implement start
  Tool: Bash
  Command: `tools/implement/start.sh <domain> --root .`

Execute #2: Read design
  Tool: Bash
  Command: `tools/design/read-design.sh sites/<domain-vX>/DESIGN.md`
  Background:
  - Extract layout/palette/motifs/interaction directives

Build a site (files)
After Execution #1~#2, Build a site
Write these files via Write tool:
- `sites/<domain-vX>/index.html`
- `sites/<domain-vX>/styles.css`
- `sites/<domain-vX>/script.js`
- `sites/<domain-vX>/assets/<filename>` (if needed)

- Build `index.html` → `styles.css` → `script.js`
- Keep IDs/classes consistent
- Add required assets to `assets/` such as SVG, etc.
- Avoid console errors
- Follow uniqueness notes (avoid overused motifs)

Execute #3: Validate Basic file presence check
  Tool: Bash
  Command: `tools/implement/check-outputs.sh sites/<domain-vX>`

Execute #4: Validate Comprehensive verification (HTML, JS syntax, file stats)
  Tool: Bash
  Command: `tools/check/verify-site.sh sites/<domain-vX>`

Execute #5: Validate Design compliance check (colors, fonts, patterns)
  Tool: Bash
  Command: `tools/check/design-compliance.sh sites/<domain-vX>`

Execute #6: Mark implement complete
  Tool: Bash
  Command: `tools/implement/complete.sh <domain> --root .`


### Step 4: Finalize Batch (Main Agent)
After all subagents complete:
Execute:
  Tool: Bash
  Command: `tools/implement/finish.sh --batch "$BATCH" --root .`
  Background:
  - `$BATCH` is the same batch ID used in Step 1
  - This transitions all I-status sites to Q (done).

---

## Subagent Launch Template

When launching subagents for parallel implementation.
**IMPORTANT:**
- Launch in **foreground mode** (C3), assign **ONE site only** (C2)
- **Subagents MUST use Opus model** — set `model: "opus"` parameter when launching. NEVER use Sonnet.
- Do NOT use `run_in_background: true` — all subagents must run in foreground

```
Implement ONLY the site <domain>. Do NOT implement any other sites.

- NEVER TRY to create file(ex: DESIGN.md) via cat/HEREDOC pattern. Use Only Write tool or Filesystem MCP.
- NEVER DELETE file which you created.
- DO NOT report result

You are at the repository root. Do NOT change directory. Use `sites/<domain-vX>/...` paths.
[If pre-scan found issues: Substitute font 'Mija' with 'Poppins'.]

## Step 0: Read instructions
Execute:
  Tool: Read
  Path: tools/implement/CIMPLEMENT.md
Motivation: LLMs skipped reading instructions and invented ad-hoc commands.

## Step 1: Mark implement start
Execute:
  Tool: Bash
  Command: tools/implement/start.sh <domain> --root .
  Background:
  - Marks domain status as 'i' (implement-in-progress) in REGISTRY
  - Acquires lock to prevent race conditions

## Step 2: Read the design
Execute:
  Tool: Bash
  Command: tools/design/read-design.sh sites/<domain-vX>/DESIGN.md

## Step 3: Write index.html
Execute:
  Tool: Write
  Path: sites/<domain-vX>/index.html
  Background:
  - Keep IDs/classes consistent across HTML/CSS/JS
  - Reference SVG and image assets from `assets/` directory
  - Avoid console errors
  - Follow uniqueness notes (avoid overused motifs)

## Step 4: Write styles.css
Execute:
  Tool: Write
  Path: sites/<domain-vX>/styles.css
  Background:
  - Keep IDs/classes consistent with index.html
  - Implement palette/typography/motifs from DESIGN.md
  - Use CSS animations and transitions as specified
  - Follow uniqueness notes (avoid overused patterns)

## Step 5: Write script.js
Execute:
  Tool: Write
  Path: sites/<domain-vX>/script.js
  Background:
  - Keep IDs/classes consistent with index.html
  - Implement interactions from DESIGN.md prompts
  - Avoid console errors and ensure smooth animations
  - Follow uniqueness notes (avoid overused patterns)

## Step 6: Check outputs exist
Execute:
  Tool: Bash
  Command: tools/implement/check-outputs.sh sites/<domain-vX>

## Step 7: Verify site structure
Execute:
  Tool: Bash
  Command: tools/check/verify-site.sh sites/<domain-vX>

## Step 8: Check design compliance
Execute:
  Tool: Bash
  Command: tools/check/design-compliance.sh sites/<domain-vX>

## Step 9: Mark implement complete
Execute:
  Tool: Bash
  Command: tools/implement/complete.sh <domain> --root .
```

---

## Output Format
Save files under the site directory; keep relative paths consistent and runnable with no external network calls.