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

package/.skills/cycle/SKILL.md

@@ -12,8 +12,10 @@ allowed-tools: WebSearch WebFetch mcp__context7 mcp__github AskUserQuestion Read
 ---
 
 ---
+
 description: Execute complete TDD cycle - Red, Green, and Refactor phases in sequence
 argument-hint: <feature or requirement description>
+
 ---
 
 RED+GREEN+REFACTOR (one cycle) PHASE! Apply the below to the info given by user input here:
@@ -37,7 +39,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.
@@ -47,7 +48,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
@@ -61,12 +61,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
@@ -102,7 +100,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:**
@@ -127,7 +124,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
@@ -152,4 +149,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/.skills/gap/SKILL.md

@@ -12,8 +12,10 @@ allowed-tools: WebSearch WebFetch mcp__context7 mcp__github AskUserQuestion Read
 ---
 
 ---
+
 description: Analyze conversation context for unaddressed items and gaps
 argument-hint: [optional additional info]
+
 ---
 
 ## General Guidelines
@@ -46,7 +48,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:**
@@ -71,7 +72,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
@@ -96,4 +97,4 @@ $ARGUMENTS
      - Code examples
      - Testing notes
    - Document expected behavior and edge cases
-   - Include real-world output examples
+   - Include real-world output examples

package/.skills/green/SKILL.md

@@ -12,8 +12,10 @@ allowed-tools: WebSearch WebFetch mcp__context7 mcp__github AskUserQuestion Read
 ---
 
 ---
+
 description: Execute TDD Green Phase - write minimal implementation to pass the failing test
 argument-hint: <implementation description>
+
 ---
 
 GREEN PHASE! Apply the below to the info given by user input here:
@@ -37,7 +39,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.
@@ -47,7 +48,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
@@ -61,12 +61,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
@@ -102,7 +100,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:**
@@ -127,7 +124,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
@@ -152,4 +149,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/.skills/issue/SKILL.md

@@ -12,8 +12,10 @@ allowed-tools: WebSearch WebFetch mcp__context7 mcp__github AskUserQuestion Read
 ---
 
 ---
+
 description: Analyze GitHub issue and create TDD implementation plan
 argument-hint: [optional-issue-number]
+
 ---
 
 Analyze GitHub issue and create TDD implementation plan.
@@ -37,7 +39,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:
 
@@ -87,7 +89,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.
@@ -97,7 +98,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
@@ -111,12 +111,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
@@ -152,7 +150,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:**
@@ -177,7 +174,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
@@ -202,4 +199,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/.skills/plan/SKILL.md

@@ -12,8 +12,10 @@ allowed-tools: WebSearch WebFetch mcp__context7 mcp__github AskUserQuestion Read
 ---
 
 ---
+
 description: Create implementation plan from feature/requirement with PRD-style discovery and TDD acceptance criteria
 argument-hint: <feature/requirement description or GitHub issue URL/number>
+
 ---
 
 # Plan: PRD-Informed Task Planning for TDD
@@ -128,7 +130,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:**
@@ -153,7 +154,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
@@ -178,4 +179,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/.skills/pr/SKILL.md

@@ -12,8 +12,10 @@ allowed-tools: WebSearch WebFetch mcp__context7 mcp__github AskUserQuestion Read
 ---
 
 ---
+
 description: Creates a pull request using GitHub MCP
 argument-hint: [optional-pr-title-and-description]
+
 ---
 
 # Create Pull Request
@@ -82,7 +84,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:**
@@ -107,7 +108,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
@@ -132,4 +133,4 @@ Arguments: $ARGUMENTS
      - Code examples
      - Testing notes
    - Document expected behavior and edge cases
-   - Include real-world output examples
+   - Include real-world output examples

package/.skills/publish/SKILL.md

@@ -0,0 +1,160 @@
+---
+name: publish
+description: Publish npm package with incremental versioning (patch/minor/major). Verifies git status, bumps version, commits, pushes, and publishes. Keywords: npm, publish, version, release, semver
+license: MIT
+compatibility: Requires npm login, git configured, optional 2FA
+metadata:
+  version: "1.0.0"
+  category: "release"
+  tags: ['npm', 'publish', 'version', 'release', 'semver']
+  author: "Hustle Together"
+allowed-tools: Bash Read Edit AskUserQuestion TodoWrite
+---
+
+---
+
+description: Publish npm package with incremental version bump
+argument-hint: [patch|minor|major] or [specific-version]
+
+---
+
+## Overview
+
+Publish the npm package with safe, incremental versioning. Defaults to patch bump unless specified otherwise.
+
+## Arguments
+
+- `patch` (default) - Always use 0.0.1 increments (3.12.0 → 3.12.1)
+- `minor` - New features, backwards compatible (3.12.0 → 3.13.0) - requires confirmation
+- `major` - Breaking changes (3.12.0 → 4.0.0) - requires confirmation
+- `X.Y.Z` - Specific version - requires confirmation if jump > 0.0.1
+
+**Default behavior:** Always increment by 0.0.1 (patch) unless explicitly specified otherwise.
+
+Include any of the following info if specified: $ARGUMENTS
+
+## Process
+
+### Phase 1: Pre-flight Checks
+
+1. **Verify clean working directory**
+   ```bash
+   git status --porcelain
+   ```
+   - If dirty, ask user to commit or stash changes first
+   - Exception: allow `.claude/` runtime files
+
+2. **Check npm login**
+   ```bash
+   npm whoami
+   ```
+   - If not logged in, prompt user to run `npm login`
+
+3. **Check current versions**
+   ```bash
+   # Local version
+   node -p "require('./package.json').version"
+
+   # Published version
+   npm view $(node -p "require('./package.json').name") version 2>/dev/null || echo "Not yet published"
+   ```
+
+4. **Verify on correct branch** (master/main)
+   ```bash
+   git branch --show-current
+   ```
+
+### Phase 2: Version Bump
+
+1. **Determine new version** based on argument:
+   - Parse $ARGUMENTS for: patch, minor, major, or X.Y.Z
+   - Default to `patch` if not specified
+   - Calculate new version from current
+
+2. **Ask for confirmation**
+   Use AskUserQuestion:
+   - Show current version → new version
+   - Ask to confirm or specify different version
+
+3. **Update package.json**
+   - Edit version field only
+   - Do NOT use `npm version` (it auto-commits)
+
+### Phase 3: Commit and Push
+
+1. **Commit the version bump**
+   ```bash
+   git add package.json
+   git commit -m "chore: bump version to X.Y.Z"
+   ```
+
+2. **Push to remote**
+   ```bash
+   git push origin $(git branch --show-current)
+   ```
+
+### Phase 4: Publish
+
+1. **Attempt publish**
+   ```bash
+   npm publish --access public
+   ```
+
+2. **Handle 2FA** (if required)
+   - If OTP error, inform user:
+     ```
+     npm publish --access public --otp=YOUR_CODE
+     ```
+   - User must run manually with their authenticator code
+
+3. **Verify publication**
+   ```bash
+   npm view $(node -p "require('./package.json').name") version
+   ```
+
+## Example Usage
+
+```bash
+# Default patch bump (3.12.0 → 3.12.1)
+/publish
+
+# Minor bump (3.12.0 → 3.13.0)
+/publish minor
+
+# Major bump (3.12.0 → 4.0.0)
+/publish major
+
+# Specific version
+/publish 3.15.0
+```
+
+## Safety Rules
+
+1. **Never skip version checks** - Always compare local vs published
+2. **Never force publish** - If version exists, bump first
+3. **Always commit before publish** - Version bump must be in git
+4. **Always push before publish** - Remote should match local
+5. **0.0.1 increments only** - Default to patch bumps; require confirmation for minor/major
+6. **No big jumps** - Any jump > 0.0.1 requires explicit user confirmation
+
+## Error Handling
+
+| Error | Action |
+|-------|--------|
+| Dirty git status | Ask user to commit/stash |
+| Not logged in | Prompt `npm login` |
+| Version exists | Bump version first |
+| OTP required | Show command with --otp flag |
+| Push failed | Check remote access |
+
+## TodoWrite Integration
+
+Initialize with:
+```
+1. Pre-flight checks (git, npm, versions)
+2. Calculate version bump
+3. Update package.json
+4. Commit and push
+5. Publish to npm
+6. Verify publication
+```

package/.skills/red/SKILL.md

@@ -12,8 +12,10 @@ allowed-tools: WebSearch WebFetch mcp__context7 mcp__github AskUserQuestion Read
 ---
 
 ---
+
 description: Execute TDD Red Phase - write ONE failing test
 argument-hint: [optional additional info]
+
 ---
 
 RED PHASE! Apply the below to the info given by user input here:
@@ -37,7 +39,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.
@@ -47,7 +48,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
@@ -61,12 +61,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
@@ -102,7 +100,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:**
@@ -127,7 +124,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
@@ -152,4 +149,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/.skills/refactor/SKILL.md

@@ -12,8 +12,10 @@ allowed-tools: WebSearch WebFetch mcp__context7 mcp__github AskUserQuestion Read
 ---
 
 ---
+
 description: Execute TDD Refactor Phase - improve code structure while keeping tests green
 argument-hint: <refactoring description>
+
 ---
 
 Apply this document (specifically the Refactor phase), to the info given by user input here: $ARGUMENTS
@@ -35,7 +37,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.
@@ -45,7 +46,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
@@ -59,12 +59,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
@@ -102,7 +100,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:**
@@ -127,7 +124,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
@@ -152,4 +149,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/.skills/spike/SKILL.md

@@ -12,8 +12,10 @@ allowed-tools: WebSearch WebFetch mcp__context7 mcp__github AskUserQuestion Read
 ---
 
 ---
+
 description: Execute TDD Spike Phase - exploratory coding to understand problem space before TDD
 argument-hint: <exploration description>
+
 ---
 
 SPIKE PHASE! Apply the below to the info given by user input here:
@@ -37,7 +39,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.
@@ -47,7 +48,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
@@ -61,12 +61,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
@@ -102,7 +100,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:**
@@ -127,7 +124,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
@@ -152,4 +149,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/.skills/summarize/SKILL.md

@@ -12,8 +12,10 @@ allowed-tools: WebSearch WebFetch mcp__context7 mcp__github AskUserQuestion Read
 ---
 
 ---
+
 description: Summarize conversation progress and next steps
 argument-hint: [optional additional info]
+
 ---
 
 ## General Guidelines
@@ -54,7 +56,6 @@ Provide a summary with these sections:
 
 Keep the summary concise and actionable - suitable for pasting into a new conversation to quickly restore context without needing the full conversation history.
 
-
 ## 🛡 Project Rules (Injected into every command)
 
 1. **NO BROKEN BUILDS:**
@@ -79,7 +80,7 @@ Keep the summary concise and actionable - suitable for pasting into a new conver
 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
@@ -104,4 +105,4 @@ Keep the summary concise and actionable - suitable for pasting into a new conver
      - Code examples
      - Testing notes
    - Document expected behavior and edge cases
-   - Include real-world output examples
+   - Include real-world output examples