@hustle-together/api-dev-tools 3.11.1 → 3.12.1

package/.claude/commands/beepboop.md

@@ -21,7 +21,7 @@ Arguments: $ARGUMENTS
 
 **IMPORTANT Communication Format:**
 
-1. **Opening**: Begin with "*Beep boop, I am Claude Code 🤖, my user has reviewed and approved the following written by me:*"
+1. **Opening**: Begin with "_Beep boop, I am Claude Code 🤖, my user has reviewed and approved the following written by me:_"
    - Use italics for this line
    - Clearly establishes AI authorship
 
@@ -29,7 +29,7 @@ Arguments: $ARGUMENTS
    - Execute whatever communication task the user requested
    - Write the actual content that accomplishes the user's goal
 
-3. **Closing**: End with "*Beep boop, Claude Code 🤖 out!*"
+3. **Closing**: End with "_Beep boop, Claude Code 🤖 out!_"
    - Use italics for this line
    - Provides clear closure
 
@@ -44,7 +44,6 @@ This command ensures transparency about AI usage while maintaining that the user
 - Responding to feedback with AI-generated explanations
 - Any communication where AI attribution is valuable
 
-
 ## 🛡 Project Rules (Injected into every command)
 
 1. **NO BROKEN BUILDS:**
@@ -69,7 +68,7 @@ This command ensures transparency about AI usage while maintaining that the user
 4. **API KEY MANAGEMENT:**
    - Support three loading methods:
      - Server environment variables
-     - NEXT_PUBLIC_ variables (client-side)
+     - NEXT*PUBLIC* variables (client-side)
      - Custom headers (X-OpenAI-Key, X-Anthropic-Key, etc.)
    - Never hardcode API keys
    - Always validate key availability before use
@@ -94,4 +93,4 @@ This command ensures transparency about AI usage while maintaining that the user
      - Code examples
      - Testing notes
    - Document expected behavior and edge cases
-   - Include real-world output examples
+   - Include real-world output examples

package/.claude/commands/busycommit.md

@@ -59,7 +59,6 @@ git add src/user-service.ts
 git commit -m "refactor: extract user lookup to helper"
 ```
 
-
 ## 🛡 Project Rules (Injected into every command)
 
 1. **NO BROKEN BUILDS:**
@@ -84,7 +83,7 @@ git commit -m "refactor: extract user lookup to helper"
 4. **API KEY MANAGEMENT:**
    - Support three loading methods:
      - Server environment variables
-     - NEXT_PUBLIC_ variables (client-side)
+     - NEXT*PUBLIC* variables (client-side)
      - Custom headers (X-OpenAI-Key, X-Anthropic-Key, etc.)
    - Never hardcode API keys
    - Always validate key availability before use
@@ -109,4 +108,4 @@ git commit -m "refactor: extract user lookup to helper"
      - Code examples
      - Testing notes
    - Document expected behavior and edge cases
-   - Include real-world output examples
+   - Include real-world output examples

package/.claude/commands/commit.md

@@ -30,7 +30,6 @@ git add <files>
 git commit -m "feat(#123): add validation to user input form"
 ```
 
-
 ## 🛡 Project Rules (Injected into every command)
 
 1. **NO BROKEN BUILDS:**
@@ -55,7 +54,7 @@ git commit -m "feat(#123): add validation to user input form"
 4. **API KEY MANAGEMENT:**
    - Support three loading methods:
      - Server environment variables
-     - NEXT_PUBLIC_ variables (client-side)
+     - NEXT*PUBLIC* variables (client-side)
      - Custom headers (X-OpenAI-Key, X-Anthropic-Key, etc.)
    - Never hardcode API keys
    - Always validate key availability before use
@@ -80,4 +79,4 @@ git commit -m "feat(#123): add validation to user input form"
      - Code examples
      - Testing notes
    - Document expected behavior and edge cases
-   - Include real-world output examples
+   - Include real-world output examples

package/.claude/commands/cycle.md

@@ -24,7 +24,6 @@ $ARGUMENTS
 The foundation of TDD is the Red-Green-Refactor cycle:
 
 1. **Red Phase**: Write ONE failing test that describes desired behavior
-
    - The test must fail for the RIGHT reason (not syntax/import errors)
    - Only one test at a time - this is critical for TDD discipline
      - Exception: For browser-level tests or expensive setup (e.g., Storybook `*.stories.tsx`), group multiple assertions within a single test block to avoid redundant setup - but only when adding assertions to an existing interaction flow. If new user interactions are required, still create a new test. Split files by category if they exceed ~1000 lines.
@@ -34,7 +33,6 @@ The foundation of TDD is the Red-Green-Refactor cycle:
    - Avoid hard-coded timeouts both in form of sleep() or timeout: 5000 etc; use proper async patterns (`waitFor`, `findBy*`, event-based sync) instead and rely on global test configs for timeout settings
 
 2. **Green Phase**: Write MINIMAL code to make the test pass
-
    - Implement only what's needed for the current failing test
    - No anticipatory coding or extra features
    - Address the specific failure message
@@ -48,12 +46,10 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 ### Core Violations
 
 1. **Multiple Test Addition**
-
    - Adding more than one new test at once
    - Exception: Initial test file setup or extracting shared test utilities
 
 2. **Over-Implementation**
-
    - Code that exceeds what's needed to pass the current failing test
    - Adding untested features, methods, or error handling
    - Implementing multiple methods when test only requires one
@@ -89,7 +85,6 @@ This phase is **not part of the regular TDD workflow** and must only be applied
 - Adding types, interfaces, or a constant in order to replace magic values is perfectly fine during refactoring.
 - Provide the agent with helpful directions so that they do not get stuck when blocking them.
 
-
 ## 🛡 Project Rules (Injected into every command)
 
 1. **NO BROKEN BUILDS:**
@@ -114,7 +109,7 @@ This phase is **not part of the regular TDD workflow** and must only be applied
 4. **API KEY MANAGEMENT:**
    - Support three loading methods:
      - Server environment variables
-     - NEXT_PUBLIC_ variables (client-side)
+     - NEXT*PUBLIC* variables (client-side)
      - Custom headers (X-OpenAI-Key, X-Anthropic-Key, etc.)
    - Never hardcode API keys
    - Always validate key availability before use
@@ -139,4 +134,4 @@ This phase is **not part of the regular TDD workflow** and must only be applied
      - Code examples
      - Testing notes
    - Document expected behavior and edge cases
-   - Include real-world output examples
+   - Include real-world output examples

package/.claude/commands/gap.md

@@ -33,7 +33,6 @@ If there are no gaps, confirm that everything discussed has been addressed.
 Additional info:
 $ARGUMENTS
 
-
 ## 🛡 Project Rules (Injected into every command)
 
 1. **NO BROKEN BUILDS:**
@@ -58,7 +57,7 @@ $ARGUMENTS
 4. **API KEY MANAGEMENT:**
    - Support three loading methods:
      - Server environment variables
-     - NEXT_PUBLIC_ variables (client-side)
+     - NEXT*PUBLIC* variables (client-side)
      - Custom headers (X-OpenAI-Key, X-Anthropic-Key, etc.)
    - Never hardcode API keys
    - Always validate key availability before use
@@ -83,4 +82,4 @@ $ARGUMENTS
      - Code examples
      - Testing notes
    - Document expected behavior and edge cases
-   - Include real-world output examples
+   - Include real-world output examples

package/.claude/commands/green.md

@@ -24,7 +24,6 @@ $ARGUMENTS
 The foundation of TDD is the Red-Green-Refactor cycle:
 
 1. **Red Phase**: Write ONE failing test that describes desired behavior
-
    - The test must fail for the RIGHT reason (not syntax/import errors)
    - Only one test at a time - this is critical for TDD discipline
      - Exception: For browser-level tests or expensive setup (e.g., Storybook `*.stories.tsx`), group multiple assertions within a single test block to avoid redundant setup - but only when adding assertions to an existing interaction flow. If new user interactions are required, still create a new test. Split files by category if they exceed ~1000 lines.
@@ -34,7 +33,6 @@ The foundation of TDD is the Red-Green-Refactor cycle:
    - Avoid hard-coded timeouts both in form of sleep() or timeout: 5000 etc; use proper async patterns (`waitFor`, `findBy*`, event-based sync) instead and rely on global test configs for timeout settings
 
 2. **Green Phase**: Write MINIMAL code to make the test pass
-
    - Implement only what's needed for the current failing test
    - No anticipatory coding or extra features
    - Address the specific failure message
@@ -48,12 +46,10 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 ### Core Violations
 
 1. **Multiple Test Addition**
-
    - Adding more than one new test at once
    - Exception: Initial test file setup or extracting shared test utilities
 
 2. **Over-Implementation**
-
    - Code that exceeds what's needed to pass the current failing test
    - Adding untested features, methods, or error handling
    - Implementing multiple methods when test only requires one
@@ -89,7 +85,6 @@ This phase is **not part of the regular TDD workflow** and must only be applied
 - Adding types, interfaces, or a constant in order to replace magic values is perfectly fine during refactoring.
 - Provide the agent with helpful directions so that they do not get stuck when blocking them.
 
-
 ## 🛡 Project Rules (Injected into every command)
 
 1. **NO BROKEN BUILDS:**
@@ -114,7 +109,7 @@ This phase is **not part of the regular TDD workflow** and must only be applied
 4. **API KEY MANAGEMENT:**
    - Support three loading methods:
      - Server environment variables
-     - NEXT_PUBLIC_ variables (client-side)
+     - NEXT*PUBLIC* variables (client-side)
      - Custom headers (X-OpenAI-Key, X-Anthropic-Key, etc.)
    - Never hardcode API keys
    - Always validate key availability before use
@@ -139,4 +134,4 @@ This phase is **not part of the regular TDD workflow** and must only be applied
      - Code examples
      - Testing notes
    - Document expected behavior and edge cases
-   - Include real-world output examples
+   - Include real-world output examples

package/.claude/commands/issue.md

@@ -24,7 +24,7 @@ Process:
 
 1. Fetch Issue
 
-Try to fetch the issue using GitHub MCP (mcp__github__issue_read tool).
+Try to fetch the issue using GitHub MCP (mcp**github**issue_read tool).
 
 If GitHub MCP is not configured, show:
 
@@ -74,7 +74,6 @@ Understand the requirement by asking (use AskUserQuestion if needed):
 The foundation of TDD is the Red-Green-Refactor cycle:
 
 1. **Red Phase**: Write ONE failing test that describes desired behavior
-
    - The test must fail for the RIGHT reason (not syntax/import errors)
    - Only one test at a time - this is critical for TDD discipline
      - Exception: For browser-level tests or expensive setup (e.g., Storybook `*.stories.tsx`), group multiple assertions within a single test block to avoid redundant setup - but only when adding assertions to an existing interaction flow. If new user interactions are required, still create a new test. Split files by category if they exceed ~1000 lines.
@@ -84,7 +83,6 @@ The foundation of TDD is the Red-Green-Refactor cycle:
    - Avoid hard-coded timeouts both in form of sleep() or timeout: 5000 etc; use proper async patterns (`waitFor`, `findBy*`, event-based sync) instead and rely on global test configs for timeout settings
 
 2. **Green Phase**: Write MINIMAL code to make the test pass
-
    - Implement only what's needed for the current failing test
    - No anticipatory coding or extra features
    - Address the specific failure message
@@ -98,12 +96,10 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 ### Core Violations
 
 1. **Multiple Test Addition**
-
    - Adding more than one new test at once
    - Exception: Initial test file setup or extracting shared test utilities
 
 2. **Over-Implementation**
-
    - Code that exceeds what's needed to pass the current failing test
    - Adding untested features, methods, or error handling
    - Implementing multiple methods when test only requires one
@@ -139,7 +135,6 @@ This phase is **not part of the regular TDD workflow** and must only be applied
 - Adding types, interfaces, or a constant in order to replace magic values is perfectly fine during refactoring.
 - Provide the agent with helpful directions so that they do not get stuck when blocking them.
 
-
 ## 🛡 Project Rules (Injected into every command)
 
 1. **NO BROKEN BUILDS:**
@@ -164,7 +159,7 @@ This phase is **not part of the regular TDD workflow** and must only be applied
 4. **API KEY MANAGEMENT:**
    - Support three loading methods:
      - Server environment variables
-     - NEXT_PUBLIC_ variables (client-side)
+     - NEXT*PUBLIC* variables (client-side)
      - Custom headers (X-OpenAI-Key, X-Anthropic-Key, etc.)
    - Never hardcode API keys
    - Always validate key availability before use
@@ -189,4 +184,4 @@ This phase is **not part of the regular TDD workflow** and must only be applied
      - Code examples
      - Testing notes
    - Document expected behavior and edge cases
-   - Include real-world output examples
+   - Include real-world output examples

package/.claude/commands/ntfy-setup.md

@@ -0,0 +1,91 @@
+---
+description: Configure NTFY push notifications for workflow updates
+---
+
+# NTFY Setup
+
+Configure push notifications via [ntfy.sh](https://ntfy.sh) to receive workflow updates on your phone.
+
+## Step 1: Install NTFY App
+
+Download the NTFY app:
+
+- **iOS**: [App Store](https://apps.apple.com/app/ntfy/id1625396347)
+- **Android**: [Google Play](https://play.google.com/store/apps/details?id=io.heckel.ntfy) or [F-Droid](https://f-droid.org/packages/io.heckel.ntfy/)
+
+## Step 2: Choose a Topic
+
+Pick a unique, hard-to-guess topic name for your notifications:
+
+```
+your-name-api-dev-2024
+```
+
+**Important:** Topics are public on ntfy.sh. Use a unique name!
+
+## Step 3: Subscribe in App
+
+1. Open the NTFY app
+2. Tap the + button
+3. Enter your topic name
+4. Tap Subscribe
+
+## Step 4: Configure Environment
+
+Add to your project's `.env` file:
+
+```env
+NTFY_ENABLED=true
+NTFY_SERVER=https://ntfy.sh
+NTFY_TOPIC=your-unique-topic-name
+```
+
+Or copy from the template:
+
+```bash
+cp templates/.env.example .env
+# Then edit .env with your topic
+```
+
+## Step 5: Test Notification
+
+Run this command to test:
+
+```bash
+/ntfy-test
+```
+
+You should receive a test notification on your phone.
+
+## What You'll Receive
+
+- 📋 Phase completion updates
+- ⏳ "Input needed" alerts when interview questions are waiting
+- 📊 Token usage summaries
+- ✅ Workflow completion notifications
+
+## Self-Hosted Option
+
+If you prefer to self-host NTFY:
+
+```bash
+docker run -d -p 8080:80 binwiederhier/ntfy serve
+```
+
+Then set:
+
+```env
+NTFY_SERVER=http://localhost:8080
+```
+
+## Troubleshooting
+
+**Not receiving notifications?**
+
+1. Check NTFY_ENABLED=true in .env
+2. Verify topic name matches exactly
+3. Check app notification permissions
+4. Run `/ntfy-test` to verify connection
+
+**Rate limited?**
+ntfy.sh has rate limits. Consider self-hosting for heavy use.

package/.claude/commands/ntfy-test.md

@@ -0,0 +1,74 @@
+---
+description: Send a test notification via NTFY
+---
+
+# NTFY Test
+
+Send a test notification to verify your NTFY setup is working.
+
+## Steps
+
+1. **Read environment configuration**:
+
+```bash
+grep NTFY .env 2>/dev/null || echo "No .env file found"
+```
+
+2. **Send test notification**:
+
+```bash
+# Get config
+source .env 2>/dev/null
+
+if [ "$NTFY_ENABLED" = "true" ] && [ -n "$NTFY_TOPIC" ]; then
+  curl -s \
+    -H "Title: 🧪 API Dev Tools Test" \
+    -H "Priority: default" \
+    -H "Tags: test,rocket" \
+    -d "Test notification from API Dev Tools. If you see this, NTFY is configured correctly!" \
+    "${NTFY_SERVER:-https://ntfy.sh}/$NTFY_TOPIC"
+  echo ""
+  echo "✅ Test notification sent to topic: $NTFY_TOPIC"
+else
+  echo "❌ NTFY not configured. Run /ntfy-setup first."
+  echo ""
+  echo "Required in .env:"
+  echo "  NTFY_ENABLED=true"
+  echo "  NTFY_TOPIC=your-topic-name"
+fi
+```
+
+3. **Verify on phone**:
+
+Check your NTFY app - you should see the test notification within a few seconds.
+
+## Expected Result
+
+You should receive a notification with:
+
+- Title: "🧪 API Dev Tools Test"
+- Message: "Test notification from API Dev Tools..."
+- Tags: test, rocket emojis
+
+## Troubleshooting
+
+**"NTFY not configured" error:**
+
+- Run `/ntfy-setup` to configure
+- Or manually add to .env:
+  ```env
+  NTFY_ENABLED=true
+  NTFY_TOPIC=your-unique-topic
+  ```
+
+**No notification received:**
+
+1. Check topic name matches your app subscription
+2. Verify phone has internet connection
+3. Check NTFY app notification permissions
+4. Try visiting https://ntfy.sh/your-topic in browser
+
+**curl error:**
+
+- Ensure you have internet connection
+- Check if ntfy.sh is accessible: `curl -I https://ntfy.sh`

package/.claude/commands/plan.md

@@ -115,7 +115,6 @@ Understand the requirement by asking (use AskUserQuestion if needed):
 - **Before /plan**: Use `/spike` if you need technical exploration first
 - **After /plan**: Use `/red` to start TDD on first task
 
-
 ## 🛡 Project Rules (Injected into every command)
 
 1. **NO BROKEN BUILDS:**
@@ -140,7 +139,7 @@ Understand the requirement by asking (use AskUserQuestion if needed):
 4. **API KEY MANAGEMENT:**
    - Support three loading methods:
      - Server environment variables
-     - NEXT_PUBLIC_ variables (client-side)
+     - NEXT*PUBLIC* variables (client-side)
      - Custom headers (X-OpenAI-Key, X-Anthropic-Key, etc.)
    - Never hardcode API keys
    - Always validate key availability before use
@@ -165,4 +164,4 @@ Understand the requirement by asking (use AskUserQuestion if needed):
      - Code examples
      - Testing notes
    - Document expected behavior and edge cases
-   - Include real-world output examples
+   - Include real-world output examples

package/.claude/commands/pr.md

@@ -69,7 +69,6 @@ Arguments: $ARGUMENTS
 3. Set the base branch (default: main)
 4. Include relevant issue references if found in commit messages
 
-
 ## 🛡 Project Rules (Injected into every command)
 
 1. **NO BROKEN BUILDS:**
@@ -94,7 +93,7 @@ Arguments: $ARGUMENTS
 4. **API KEY MANAGEMENT:**
    - Support three loading methods:
      - Server environment variables
-     - NEXT_PUBLIC_ variables (client-side)
+     - NEXT*PUBLIC* variables (client-side)
      - Custom headers (X-OpenAI-Key, X-Anthropic-Key, etc.)
    - Never hardcode API keys
    - Always validate key availability before use
@@ -119,4 +118,4 @@ Arguments: $ARGUMENTS
      - Code examples
      - Testing notes
    - Document expected behavior and edge cases
-   - Include real-world output examples
+   - Include real-world output examples

package/.claude/commands/publish.md

@@ -0,0 +1,40 @@
+---
+description: Publish npm package with incremental versioning (patch/minor/major)
+argument-hint: [patch|minor|major|X.Y.Z]
+---
+
+Publish the npm package with safe, incremental versioning.
+
+## Arguments
+- `patch` (default) - Bug fixes (1.0.0 → 1.0.1)
+- `minor` - New features (1.0.0 → 1.1.0)
+- `major` - Breaking changes (1.0.0 → 2.0.0)
+- `X.Y.Z` - Specific version
+
+$ARGUMENTS
+
+## Process
+
+1. **Pre-flight checks**
+   - Verify clean git status
+   - Check npm login (`npm whoami`)
+   - Compare local vs published version
+
+2. **Version bump**
+   - Calculate new version based on argument
+   - Update package.json
+   - Commit: `chore: bump version to X.Y.Z`
+   - Push to remote
+
+3. **Publish**
+   - Run `npm publish --access public`
+   - If 2FA required, show: `npm publish --access public --otp=CODE`
+
+4. **Verify**
+   - Confirm new version on npm registry
+
+## Safety Rules
+- Always commit before publish
+- Always push before publish
+- Never skip version comparison
+- Incremental bumps only (no big jumps without confirmation)

package/.claude/commands/red.md

@@ -24,7 +24,6 @@ $ARGUMENTS
 The foundation of TDD is the Red-Green-Refactor cycle:
 
 1. **Red Phase**: Write ONE failing test that describes desired behavior
-
    - The test must fail for the RIGHT reason (not syntax/import errors)
    - Only one test at a time - this is critical for TDD discipline
      - Exception: For browser-level tests or expensive setup (e.g., Storybook `*.stories.tsx`), group multiple assertions within a single test block to avoid redundant setup - but only when adding assertions to an existing interaction flow. If new user interactions are required, still create a new test. Split files by category if they exceed ~1000 lines.
@@ -34,7 +33,6 @@ The foundation of TDD is the Red-Green-Refactor cycle:
    - Avoid hard-coded timeouts both in form of sleep() or timeout: 5000 etc; use proper async patterns (`waitFor`, `findBy*`, event-based sync) instead and rely on global test configs for timeout settings
 
 2. **Green Phase**: Write MINIMAL code to make the test pass
-
    - Implement only what's needed for the current failing test
    - No anticipatory coding or extra features
    - Address the specific failure message
@@ -48,12 +46,10 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 ### Core Violations
 
 1. **Multiple Test Addition**
-
    - Adding more than one new test at once
    - Exception: Initial test file setup or extracting shared test utilities
 
 2. **Over-Implementation**
-
    - Code that exceeds what's needed to pass the current failing test
    - Adding untested features, methods, or error handling
    - Implementing multiple methods when test only requires one
@@ -89,7 +85,6 @@ This phase is **not part of the regular TDD workflow** and must only be applied
 - Adding types, interfaces, or a constant in order to replace magic values is perfectly fine during refactoring.
 - Provide the agent with helpful directions so that they do not get stuck when blocking them.
 
-
 ## 🛡 Project Rules (Injected into every command)
 
 1. **NO BROKEN BUILDS:**
@@ -114,7 +109,7 @@ This phase is **not part of the regular TDD workflow** and must only be applied
 4. **API KEY MANAGEMENT:**
    - Support three loading methods:
      - Server environment variables
-     - NEXT_PUBLIC_ variables (client-side)
+     - NEXT*PUBLIC* variables (client-side)
      - Custom headers (X-OpenAI-Key, X-Anthropic-Key, etc.)
    - Never hardcode API keys
    - Always validate key availability before use
@@ -139,4 +134,4 @@ This phase is **not part of the regular TDD workflow** and must only be applied
      - Code examples
      - Testing notes
    - Document expected behavior and edge cases
-   - Include real-world output examples
+   - Include real-world output examples

package/.claude/commands/refactor.md

@@ -22,7 +22,6 @@ Apply this document (specifically the Refactor phase), to the info given by user
 The foundation of TDD is the Red-Green-Refactor cycle:
 
 1. **Red Phase**: Write ONE failing test that describes desired behavior
-
    - The test must fail for the RIGHT reason (not syntax/import errors)
    - Only one test at a time - this is critical for TDD discipline
      - Exception: For browser-level tests or expensive setup (e.g., Storybook `*.stories.tsx`), group multiple assertions within a single test block to avoid redundant setup - but only when adding assertions to an existing interaction flow. If new user interactions are required, still create a new test. Split files by category if they exceed ~1000 lines.
@@ -32,7 +31,6 @@ The foundation of TDD is the Red-Green-Refactor cycle:
    - Avoid hard-coded timeouts both in form of sleep() or timeout: 5000 etc; use proper async patterns (`waitFor`, `findBy*`, event-based sync) instead and rely on global test configs for timeout settings
 
 2. **Green Phase**: Write MINIMAL code to make the test pass
-
    - Implement only what's needed for the current failing test
    - No anticipatory coding or extra features
    - Address the specific failure message
@@ -46,12 +44,10 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 ### Core Violations
 
 1. **Multiple Test Addition**
-
    - Adding more than one new test at once
    - Exception: Initial test file setup or extracting shared test utilities
 
 2. **Over-Implementation**
-
    - Code that exceeds what's needed to pass the current failing test
    - Adding untested features, methods, or error handling
    - Implementing multiple methods when test only requires one
@@ -89,7 +85,6 @@ This phase is **not part of the regular TDD workflow** and must only be applied
 
 1. **Consistency check** - Look for inconsistent patterns, naming conventions, or structure across the codebase
 
-
 ## 🛡 Project Rules (Injected into every command)
 
 1. **NO BROKEN BUILDS:**
@@ -114,7 +109,7 @@ This phase is **not part of the regular TDD workflow** and must only be applied
 4. **API KEY MANAGEMENT:**
    - Support three loading methods:
      - Server environment variables
-     - NEXT_PUBLIC_ variables (client-side)
+     - NEXT*PUBLIC* variables (client-side)
      - Custom headers (X-OpenAI-Key, X-Anthropic-Key, etc.)
    - Never hardcode API keys
    - Always validate key availability before use
@@ -139,4 +134,4 @@ This phase is **not part of the regular TDD workflow** and must only be applied
      - Code examples
      - Testing notes
    - Document expected behavior and edge cases
-   - Include real-world output examples
+   - Include real-world output examples

package/.claude/commands/spike.md

@@ -24,7 +24,6 @@ $ARGUMENTS
 The foundation of TDD is the Red-Green-Refactor cycle:
 
 1. **Red Phase**: Write ONE failing test that describes desired behavior
-
    - The test must fail for the RIGHT reason (not syntax/import errors)
    - Only one test at a time - this is critical for TDD discipline
      - Exception: For browser-level tests or expensive setup (e.g., Storybook `*.stories.tsx`), group multiple assertions within a single test block to avoid redundant setup - but only when adding assertions to an existing interaction flow. If new user interactions are required, still create a new test. Split files by category if they exceed ~1000 lines.
@@ -34,7 +33,6 @@ The foundation of TDD is the Red-Green-Refactor cycle:
    - Avoid hard-coded timeouts both in form of sleep() or timeout: 5000 etc; use proper async patterns (`waitFor`, `findBy*`, event-based sync) instead and rely on global test configs for timeout settings
 
 2. **Green Phase**: Write MINIMAL code to make the test pass
-
    - Implement only what's needed for the current failing test
    - No anticipatory coding or extra features
    - Address the specific failure message
@@ -48,12 +46,10 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 ### Core Violations
 
 1. **Multiple Test Addition**
-
    - Adding more than one new test at once
    - Exception: Initial test file setup or extracting shared test utilities
 
 2. **Over-Implementation**
-
    - Code that exceeds what's needed to pass the current failing test
    - Adding untested features, methods, or error handling
    - Implementing multiple methods when test only requires one
@@ -89,7 +85,6 @@ This phase is **not part of the regular TDD workflow** and must only be applied
 - Adding types, interfaces, or a constant in order to replace magic values is perfectly fine during refactoring.
 - Provide the agent with helpful directions so that they do not get stuck when blocking them.
 
-
 ## 🛡 Project Rules (Injected into every command)
 
 1. **NO BROKEN BUILDS:**
@@ -114,7 +109,7 @@ This phase is **not part of the regular TDD workflow** and must only be applied
 4. **API KEY MANAGEMENT:**
    - Support three loading methods:
      - Server environment variables
-     - NEXT_PUBLIC_ variables (client-side)
+     - NEXT*PUBLIC* variables (client-side)
      - Custom headers (X-OpenAI-Key, X-Anthropic-Key, etc.)
    - Never hardcode API keys
    - Always validate key availability before use
@@ -139,4 +134,4 @@ This phase is **not part of the regular TDD workflow** and must only be applied
      - Code examples
      - Testing notes
    - Document expected behavior and edge cases
-   - Include real-world output examples
+   - Include real-world output examples