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

package/.skills/tdd/SKILL.md

@@ -12,8 +12,10 @@ allowed-tools: WebSearch WebFetch mcp__context7 mcp__github AskUserQuestion Read
 ---
 
 ---
+
 description: Remind agent about TDD approach and continue conversation
 argument-hint: [optional-response-to-last-message]
+
 ---
 
 # TDD Reminder
@@ -33,7 +35,6 @@ argument-hint: [optional-response-to-last-message]
 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.
@@ -43,7 +44,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
@@ -57,12 +57,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
@@ -104,7 +102,6 @@ User response to the last message: $ARGUMENTS
 
 Please continue with TDD approach based on the above response.
 
-
 ## 🛡 Project Rules (Injected into every command)
 
 1. **NO BROKEN BUILDS:**
@@ -129,7 +126,7 @@ Please continue with TDD approach based on the above response.
 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
@@ -154,4 +151,4 @@ Please continue with TDD approach based on the above response.
      - Code examples
      - Testing notes
    - Document expected behavior and edge cases
-   - Include real-world output examples
+   - Include real-world output examples

package/.skills/update-todos/SKILL.md

@@ -112,6 +112,7 @@ You are a TodoWrite progress updater. Your job is to:
 ### Status Logic
 
 For a given `current_phase` number:
+
 - Phases < current_phase: `"completed"`
 - Phase == current_phase: `"in_progress"`
 - Phases > current_phase: `"pending"`
@@ -121,6 +122,7 @@ For a given `current_phase` number:
 User calls: `/update-todos api-create 3`
 
 You build:
+
 ```json
 [
   {"content": "Phase 1: Disambiguation", "status": "completed", "activeForm": "Clarified API terms"},
@@ -136,17 +138,23 @@ Then call TodoWrite with this array.
 ## Special Cases
 
 ### Initialization (phase 0)
+
 When `current_phase = 0`, all phases are `"pending"` with one `"in_progress"`:
+
 - Phase 1: `"in_progress"` (starting workflow)
 - Phases 2-13: `"pending"`
 
 ### Completion (phase 13 for 13-phase workflows)
+
 When `current_phase = 13`:
+
 - All phases: `"completed"`
 - Display completion message
 
 ### Loop-Back Scenarios
+
 If a verification phase fails (e.g., Phase 10 requires going back to Phase 8):
+
 - The calling workflow will call `/update-todos` with the looped-back phase number
 - Example: After Phase 10 fails verification → `/update-todos api-create 8`
 - Phase 8 becomes `"in_progress"` again
@@ -155,6 +163,7 @@ If a verification phase fails (e.g., Phase 10 requires going back to Phase 8):
 ## Error Handling
 
 If invalid parameters:
+
 - Invalid workflow name → Use `api-create` as default, warn user
 - Invalid phase number → Clamp to valid range (0-13 or 0-12)
 - Missing parameters → Ask user to provide them
@@ -162,6 +171,7 @@ If invalid parameters:
 ## Silent Operation
 
 **CRITICAL:** This is a helper skill. After calling TodoWrite, you MUST:
+
 - **NOT output any text to the user**
 - **NOT explain what you did**
 - **NOT ask follow-up questions**
@@ -172,38 +182,49 @@ The calling workflow (e.g., `/api-create`) will handle all user communication.
 ## Usage Examples
 
 ### From api-create workflow
+
 ```markdown
 # Start of workflow
+
 /update-todos api-create 0
 
 # After Phase 1 completes
+
 /update-todos api-create 1
 
 # After Phase 10 verification fails (loop back to Phase 8)
+
 /update-todos api-create 8
 ```
 
 ### From ui-create-component workflow
+
 ```markdown
 # Start of workflow
+
 /update-todos ui-create-component 0
 
 # After completing Brand Guide check
+
 /update-todos ui-create-component 2
 ```
 
 ### From combine workflow
+
 ```markdown
 # Start of workflow (note: only 12 phases)
+
 /update-todos combine 0
 
 # After Flow Type selection
+
 /update-todos combine 3
 ```
 
 ## Integration Points
 
 This skill is called by:
+
 - `.skills/api-create/SKILL.md` (or `/hustle-api-create`)
 - `.skills/hustle-ui-create/SKILL.md` (component mode)
 - `.skills/hustle-ui-create-page/SKILL.md` (page mode)
@@ -212,6 +233,7 @@ This skill is called by:
 ## Testing
 
 To test this helper independently:
+
 ```bash
 /update-todos api-create 5
 # Should show phases 1-4 completed, phase 5 in_progress, 6-13 pending