@wbern/claude-instructions 1.4.0 → 1.5.0

package/README.md

@@ -119,6 +119,7 @@ flowchart TB
 ### Workflow
 
 - `/commit` - Create a git commit following project standards
+- `/busycommit` - Create multiple atomic git commits, one logical change at a time
 - `/ship` - Ship code directly to main - for small, obvious changes that don't need review (Cursor's modern alternative to PRs)
 - `/show` - Show code to team with auto-merge - for changes that should be visible but don't need approval (Cursor's modern workflow)
 - `/ask` - Request team review and approval - for complex changes needing discussion (OK fine, traditional PRs still have their place - Cursor)

package/downloads/with-beads/add-command.md

@@ -58,7 +58,7 @@ echo "Review this code for bugs and suggest fixes" > ~/.claude/commands/review.m
 
 ### Command with Arguments
 ```markdown
-Fix issue #$ARGUMENTS following our coding standards
+Fix issue #ARGUMENTS following our coding standards
 ```
 
 ### Command with File References
@@ -83,7 +83,7 @@ Create commit for these changes.
 ### Namespaced Command
 ```bash
 mkdir -p ~/.claude/commands/ai
-echo "Ask GPT-5 about: $ARGUMENTS" > ~/.claude/commands/ai/gpt5.md
+echo "Ask GPT-5 about: ARGUMENTS" > ~/.claude/commands/ai/gpt5.md
 # Creates: /ai:gpt5
 ```
 

package/downloads/with-beads/busycommit.md

@@ -0,0 +1,56 @@
+---
+allowed-tools: Bash(pnpm test:*), Bash(pnpm lint:*)
+description: Create multiple atomic git commits, one logical change at a time
+argument-hint: [optional-commit-description]
+---
+
+Create multiple atomic git commits, committing the smallest possible logical unit at a time
+
+Include any of the following info if specified: $ARGUMENTS
+
+
+
+
+## Process
+
+1. Run `git status` and `git diff` to review changes
+2. Run `git log --oneline -5` to see recent commit style
+3. Stage relevant files with `git add`
+4. Create commit with descriptive message
+5. Verify with `git status`
+
+## Example
+
+```bash
+git add <files>
+git commit -m "feat(#123): add validation to user input form"
+```
+
+## Atomic Commit Approach
+
+Each commit should represent ONE logical change. Do NOT bundle multiple unrelated changes into one commit.
+
+- Identify the smallest atomic units of change
+- For EACH atomic unit: stage only those files/hunks, commit, verify
+- Use `git add -p` to stage partial file changes when a file contains multiple logical changes
+- Repeat until all changes are committed
+- It is OK to create multiple commits without stopping - keep going until `git status` shows clean
+
+## Multi-Commit Example
+
+If a single file contains multiple unrelated changes, use `git add -p` to stage hunks interactively:
+
+```bash
+# Stage only the validation-related hunks from the file
+git add -p src/user-service.ts
+# Select 'y' for validation hunks, 'n' for others
+git commit -m "feat(#123): add email format validation"
+
+# Stage the error handling hunks
+git add -p src/user-service.ts
+git commit -m "fix(#124): handle null user gracefully"
+
+# Stage remaining changes
+git add src/user-service.ts
+git commit -m "refactor: extract user lookup to helper"
+```

package/downloads/with-beads/commands-metadata.json

@@ -14,6 +14,11 @@
     "category": "Utilities",
     "order": 2
   },
+  "busycommit.md": {
+    "description": "Create multiple atomic git commits, one logical change at a time",
+    "category": "Workflow",
+    "order": 2
+  },
   "commit.md": {
     "description": "Create a git commit following project standards",
     "category": "Workflow",

package/downloads/with-beads/commit.md

@@ -8,28 +8,8 @@ Create a git commit following project standards
 
 Include any of the following info if specified: $ARGUMENTS
 
-## General Guidelines
 
-### Output Style
-- **Never explicitly mention TDD** in code, comments, commits, PRs, or issues
-- Write natural, descriptive code without meta-commentary about the development process
-- The code should speak for itself - TDD is the process, not the product
 
-## Commit Message Rules
-
-Follows [Conventional Commits](https://www.conventionalcommits.org/) standard.
-
-1. **Format**: `type(#issue): description`
-   - Use `#123` for local repo issues
-   - Use `owner/repo#123` for cross-repo issues
-   - Common types: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`
-
-2. **AI Credits**: **NEVER include AI credits in commit messages**
-   - No "Generated with Claude Code"
-   - No "Co-Authored-By: Claude" or "Co-Authored-By: Happy"
-   - Focus on the actual changes made, not conversation history
-
-3. **Content**: Write clear, concise commit messages describing what changed and why
 
 ## Process
 

package/downloads/with-beads/cycle.md

@@ -29,8 +29,11 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 
    - 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.
    - **Adding a single test to a test file is ALWAYS allowed** - no prior test output needed
    - Starting TDD for a new feature is always valid, even if test output shows unrelated work
+   - For DOM-based tests, use `data-testid` attributes to select elements rather than CSS classes, tag names, or text content
+   - 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
 

package/downloads/with-beads/gap.md

@@ -20,3 +20,6 @@ Present findings as a prioritized list with:
 - Suggested next action
 
 If there are no gaps, confirm that everything discussed has been addressed.
+
+Additional info:
+$ARGUMENTS

package/downloads/with-beads/green.md

@@ -29,8 +29,11 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 
    - 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.
    - **Adding a single test to a test file is ALWAYS allowed** - no prior test output needed
    - Starting TDD for a new feature is always valid, even if test output shows unrelated work
+   - For DOM-based tests, use `data-testid` attributes to select elements rather than CSS classes, tag names, or text content
+   - 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
 

package/downloads/with-beads/issue.md

@@ -81,8 +81,11 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 
    - 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.
    - **Adding a single test to a test file is ALWAYS allowed** - no prior test output needed
    - Starting TDD for a new feature is always valid, even if test output shows unrelated work
+   - For DOM-based tests, use `data-testid` attributes to select elements rather than CSS classes, tag names, or text content
+   - 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
 

package/downloads/with-beads/red.md

@@ -26,8 +26,11 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 
    - 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.
    - **Adding a single test to a test file is ALWAYS allowed** - no prior test output needed
    - Starting TDD for a new feature is always valid, even if test output shows unrelated work
+   - For DOM-based tests, use `data-testid` attributes to select elements rather than CSS classes, tag names, or text content
+   - 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
 

package/downloads/with-beads/refactor.md

@@ -27,8 +27,11 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 
    - 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.
    - **Adding a single test to a test file is ALWAYS allowed** - no prior test output needed
    - Starting TDD for a new feature is always valid, even if test output shows unrelated work
+   - For DOM-based tests, use `data-testid` attributes to select elements rather than CSS classes, tag names, or text content
+   - 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
 

package/downloads/with-beads/spike.md

@@ -29,8 +29,11 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 
    - 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.
    - **Adding a single test to a test file is ALWAYS allowed** - no prior test output needed
    - Starting TDD for a new feature is always valid, even if test output shows unrelated work
+   - For DOM-based tests, use `data-testid` attributes to select elements rather than CSS classes, tag names, or text content
+   - 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
 

package/downloads/with-beads/summarize.md

@@ -5,6 +5,8 @@ description: Summarize conversation progress and next steps
 
 Create a concise summary of the current conversation suitable for transferring context to a new conversation.
 
+Additional info: $ARGUMENTS
+
 ## Summary Structure
 
 Provide a summary with these sections:

package/downloads/with-beads/tdd.md

@@ -23,8 +23,11 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 
    - 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.
    - **Adding a single test to a test file is ALWAYS allowed** - no prior test output needed
    - Starting TDD for a new feature is always valid, even if test output shows unrelated work
+   - For DOM-based tests, use `data-testid` attributes to select elements rather than CSS classes, tag names, or text content
+   - 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
 

package/downloads/with-beads/worktree-add.md

@@ -69,7 +69,7 @@ Uncommitted changes: !git status --short`
 
   <step_2>
     <description>Parse the arguments</description>
-    <input>$ARGUMENTS</input>
+    <input>The user-provided arguments</input>
     <expected_format>branch-name-or-github-url [optional-base-branch]</expected_format>
     <example>fix/issue-123-main-content-area-visually-clipped main</example>
     <example_github_url>https://github.com/owner/project/issues/123 main</example_github_url>

package/downloads/with-beads/worktree-cleanup.md

@@ -15,6 +15,8 @@ argument-hint: (no arguments)
 
 Clean up merged worktrees by finding the oldest merged branch, consolidating settings, and removing stale worktrees.
 
+Additional info: $ARGUMENTS
+
 <current_state>
 Current branch: !git branch --show-current`
 Current worktrees: !git worktree list`

package/downloads/without-beads/add-command.md

@@ -58,7 +58,7 @@ echo "Review this code for bugs and suggest fixes" > ~/.claude/commands/review.m
 
 ### Command with Arguments
 ```markdown
-Fix issue #$ARGUMENTS following our coding standards
+Fix issue #ARGUMENTS following our coding standards
 ```
 
 ### Command with File References
@@ -83,7 +83,7 @@ Create commit for these changes.
 ### Namespaced Command
 ```bash
 mkdir -p ~/.claude/commands/ai
-echo "Ask GPT-5 about: $ARGUMENTS" > ~/.claude/commands/ai/gpt5.md
+echo "Ask GPT-5 about: ARGUMENTS" > ~/.claude/commands/ai/gpt5.md
 # Creates: /ai:gpt5
 ```
 

package/downloads/without-beads/busycommit.md

@@ -0,0 +1,56 @@
+---
+allowed-tools: Bash(pnpm test:*), Bash(pnpm lint:*)
+description: Create multiple atomic git commits, one logical change at a time
+argument-hint: [optional-commit-description]
+---
+
+Create multiple atomic git commits, committing the smallest possible logical unit at a time
+
+Include any of the following info if specified: $ARGUMENTS
+
+
+
+
+## Process
+
+1. Run `git status` and `git diff` to review changes
+2. Run `git log --oneline -5` to see recent commit style
+3. Stage relevant files with `git add`
+4. Create commit with descriptive message
+5. Verify with `git status`
+
+## Example
+
+```bash
+git add <files>
+git commit -m "feat(#123): add validation to user input form"
+```
+
+## Atomic Commit Approach
+
+Each commit should represent ONE logical change. Do NOT bundle multiple unrelated changes into one commit.
+
+- Identify the smallest atomic units of change
+- For EACH atomic unit: stage only those files/hunks, commit, verify
+- Use `git add -p` to stage partial file changes when a file contains multiple logical changes
+- Repeat until all changes are committed
+- It is OK to create multiple commits without stopping - keep going until `git status` shows clean
+
+## Multi-Commit Example
+
+If a single file contains multiple unrelated changes, use `git add -p` to stage hunks interactively:
+
+```bash
+# Stage only the validation-related hunks from the file
+git add -p src/user-service.ts
+# Select 'y' for validation hunks, 'n' for others
+git commit -m "feat(#123): add email format validation"
+
+# Stage the error handling hunks
+git add -p src/user-service.ts
+git commit -m "fix(#124): handle null user gracefully"
+
+# Stage remaining changes
+git add src/user-service.ts
+git commit -m "refactor: extract user lookup to helper"
+```

package/downloads/without-beads/commands-metadata.json

@@ -14,6 +14,11 @@
     "category": "Utilities",
     "order": 2
   },
+  "busycommit.md": {
+    "description": "Create multiple atomic git commits, one logical change at a time",
+    "category": "Workflow",
+    "order": 2
+  },
   "commit.md": {
     "description": "Create a git commit following project standards",
     "category": "Workflow",

package/downloads/without-beads/commit.md

@@ -8,28 +8,8 @@ Create a git commit following project standards
 
 Include any of the following info if specified: $ARGUMENTS
 
-## General Guidelines
 
-### Output Style
-- **Never explicitly mention TDD** in code, comments, commits, PRs, or issues
-- Write natural, descriptive code without meta-commentary about the development process
-- The code should speak for itself - TDD is the process, not the product
 
-## Commit Message Rules
-
-Follows [Conventional Commits](https://www.conventionalcommits.org/) standard.
-
-1. **Format**: `type(#issue): description`
-   - Use `#123` for local repo issues
-   - Use `owner/repo#123` for cross-repo issues
-   - Common types: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`
-
-2. **AI Credits**: **NEVER include AI credits in commit messages**
-   - No "Generated with Claude Code"
-   - No "Co-Authored-By: Claude" or "Co-Authored-By: Happy"
-   - Focus on the actual changes made, not conversation history
-
-3. **Content**: Write clear, concise commit messages describing what changed and why
 
 ## Process
 

package/downloads/without-beads/cycle.md

@@ -29,8 +29,11 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 
    - 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.
    - **Adding a single test to a test file is ALWAYS allowed** - no prior test output needed
    - Starting TDD for a new feature is always valid, even if test output shows unrelated work
+   - For DOM-based tests, use `data-testid` attributes to select elements rather than CSS classes, tag names, or text content
+   - 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
 

package/downloads/without-beads/gap.md

@@ -19,3 +19,6 @@ Present findings as a prioritized list with:
 - Suggested next action
 
 If there are no gaps, confirm that everything discussed has been addressed.
+
+Additional info:
+$ARGUMENTS

package/downloads/without-beads/green.md

@@ -29,8 +29,11 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 
    - 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.
    - **Adding a single test to a test file is ALWAYS allowed** - no prior test output needed
    - Starting TDD for a new feature is always valid, even if test output shows unrelated work
+   - For DOM-based tests, use `data-testid` attributes to select elements rather than CSS classes, tag names, or text content
+   - 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
 

package/downloads/without-beads/issue.md

@@ -73,8 +73,11 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 
    - 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.
    - **Adding a single test to a test file is ALWAYS allowed** - no prior test output needed
    - Starting TDD for a new feature is always valid, even if test output shows unrelated work
+   - For DOM-based tests, use `data-testid` attributes to select elements rather than CSS classes, tag names, or text content
+   - 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
 

package/downloads/without-beads/red.md

@@ -26,8 +26,11 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 
    - 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.
    - **Adding a single test to a test file is ALWAYS allowed** - no prior test output needed
    - Starting TDD for a new feature is always valid, even if test output shows unrelated work
+   - For DOM-based tests, use `data-testid` attributes to select elements rather than CSS classes, tag names, or text content
+   - 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
 

package/downloads/without-beads/refactor.md

@@ -27,8 +27,11 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 
    - 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.
    - **Adding a single test to a test file is ALWAYS allowed** - no prior test output needed
    - Starting TDD for a new feature is always valid, even if test output shows unrelated work
+   - For DOM-based tests, use `data-testid` attributes to select elements rather than CSS classes, tag names, or text content
+   - 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
 

package/downloads/without-beads/spike.md

@@ -29,8 +29,11 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 
    - 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.
    - **Adding a single test to a test file is ALWAYS allowed** - no prior test output needed
    - Starting TDD for a new feature is always valid, even if test output shows unrelated work
+   - For DOM-based tests, use `data-testid` attributes to select elements rather than CSS classes, tag names, or text content
+   - 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
 

package/downloads/without-beads/summarize.md

@@ -5,6 +5,8 @@ description: Summarize conversation progress and next steps
 
 Create a concise summary of the current conversation suitable for transferring context to a new conversation.
 
+Additional info: $ARGUMENTS
+
 ## Summary Structure
 
 Provide a summary with these sections:

package/downloads/without-beads/tdd.md

@@ -23,8 +23,11 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 
    - 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.
    - **Adding a single test to a test file is ALWAYS allowed** - no prior test output needed
    - Starting TDD for a new feature is always valid, even if test output shows unrelated work
+   - For DOM-based tests, use `data-testid` attributes to select elements rather than CSS classes, tag names, or text content
+   - 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
 

package/downloads/without-beads/worktree-add.md

@@ -69,7 +69,7 @@ Uncommitted changes: !git status --short`
 
   <step_2>
     <description>Parse the arguments</description>
-    <input>$ARGUMENTS</input>
+    <input>The user-provided arguments</input>
     <expected_format>branch-name-or-github-url [optional-base-branch]</expected_format>
     <example>fix/issue-123-main-content-area-visually-clipped main</example>
     <example_github_url>https://github.com/owner/project/issues/123 main</example_github_url>

package/downloads/without-beads/worktree-cleanup.md

@@ -15,6 +15,8 @@ argument-hint: (no arguments)
 
 Clean up merged worktrees by finding the oldest merged branch, consolidating settings, and removing stale worktrees.
 
+Additional info: $ARGUMENTS
+
 <current_state>
 Current branch: !git branch --show-current`
 Current worktrees: !git worktree list`

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wbern/claude-instructions",
-  "version": "1.4.0",
+  "version": "1.5.0",
   "description": "TDD workflow commands for Claude Code CLI",
   "type": "module",
   "bin": "./bin/cli.js",