@wbern/claude-instructions 1.3.0 → 1.5.0

package/downloads/with-beads/show.md

@@ -1,5 +1,5 @@
 ---
-allowed-tools: mcp__github__*, Bash(git:*)
+allowed-tools: mcp__github__create_pull_request, mcp__github__update_pull_request, Bash(git status:*), Bash(git log:*), Bash(git push:*), Bash(git branch:*)
 description: Show code to team with auto-merge - for changes that should be visible but don't need approval (Cursor's modern workflow)
 argument-hint: [optional-pr-title-and-description]
 ---
@@ -18,6 +18,7 @@ argument-hint: [optional-pr-title-and-description]
 > 🚀 **Cursor says**: Not every change needs a traditional review. Show your work, then merge.
 
 Show is for changes that teammates should see, but don't require approval. Examples:
+
 - Refactoring with test coverage
 - New features with comprehensive tests
 - Performance improvements
@@ -26,6 +27,7 @@ Show is for changes that teammates should see, but don't require approval. Examp
 ## Prerequisites
 
 Before using show:
+
 1. All tests must pass
 2. Changes should have good test coverage
 3. Changes should be non-breaking or backward compatible
@@ -60,6 +62,7 @@ Arguments: $ARGUMENTS
    - Add notice that feedback is welcome but not required
 
 4. **PR Description Template**:
+
    ```markdown
    ## 🚀 Show - Auto-merging after CI
 
@@ -71,12 +74,15 @@ Arguments: $ARGUMENTS
    -->
 
    ### What changed
+
    [Brief description]
 
    ### Why
+
    [Rationale for change]
 
    ### Test coverage
+
    - [ ] All tests pass
    - [ ] Coverage maintained/improved
    - [ ] No breaking changes
@@ -87,6 +93,7 @@ Arguments: $ARGUMENTS
 ## Decision Guide
 
 Use **Show** when:
+
 - ✅ Tests are comprehensive
 - ✅ Changes are non-breaking
 - ✅ You're confident in the approach
@@ -104,4 +111,3 @@ Use Beads MCP to:
 - Track dependencies with `bd dep add`
 
 See https://github.com/steveyegge/beads for more information.
-

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

@@ -1,10 +1,12 @@
 ---
-allowed-tools: AskUserQuestion, mcp__beads__list, mcp__beads__stats
+allowed-tools: AskUserQuestion
 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/ask.md

@@ -1,5 +1,5 @@
 ---
-allowed-tools: mcp__github__*, Bash(git:*)
+allowed-tools: mcp__github__create_pull_request, mcp__github__update_pull_request, Bash(git status:*), Bash(git log:*), Bash(git push:*), Bash(git branch:*)
 description: Request team review and approval - for complex changes needing discussion (OK fine, traditional PRs still have their place - Cursor)
 argument-hint: [optional-pr-title-and-description]
 ---
@@ -18,6 +18,7 @@ argument-hint: [optional-pr-title-and-description]
 > 💭 **Cursor says**: Fine, SOME things still need traditional PRs. But be intentional about it.
 
 Ask is for complex changes that need team discussion and approval. Examples:
+
 - Breaking API changes
 - New architecture decisions
 - Significant feature additions
@@ -27,6 +28,7 @@ Ask is for complex changes that need team discussion and approval. Examples:
 ## When to Ask
 
 Use **Ask** when:
+
 - Changes affect multiple systems
 - Breaking changes are needed
 - You need input on approach
@@ -54,10 +56,11 @@ Arguments: $ARGUMENTS
    - Push to remote: `git push origin [branch-name]`
 
 2. **Create Ask PR**: Create a PR that clearly needs review
-   
+
    Title: conventional commits format, prefixed with `[ASK]`
-   
+
    Description template:
+
    ```markdown
    ## 🤔 Ask - Review and Approval Needed
 
@@ -68,32 +71,38 @@ Arguments: $ARGUMENTS
    -->
 
    ### What changed
+
    [Detailed description of changes]
 
    ### Why
+
    [Rationale and context]
 
    ### Questions for reviewers
+
    - [ ] Question 1
    - [ ] Question 2
 
    ### Concerns
+
    - Potential concern 1
    - Potential concern 2
 
    ### Test Plan
+
    - [ ] Unit tests
    - [ ] Integration tests
    - [ ] Manual testing steps
 
    ### Alternatives considered
+
    - Alternative 1: [why not chosen]
    - Alternative 2: [why not chosen]
    ```
 
 3. **Request Reviewers**: Assign specific reviewers who should weigh in
 
-4. **Add Labels**: 
+4. **Add Labels**:
    - "needs-review"
    - "breaking-change" (if applicable)
    - "security" (if applicable)
@@ -113,6 +122,7 @@ Arguments: $ARGUMENTS
 ## Decision Guide
 
 Use **Ask** when:
+
 - ✅ Change is complex or risky
 - ✅ Breaking changes involved
 - ✅ Need team input on approach
@@ -123,4 +133,3 @@ Use **/show** instead if: confident in approach, just want visibility
 
 Use **/ship** instead if: change is tiny, obvious, and safe
 
-

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

@@ -1,5 +1,5 @@
 ---
-allowed-tools: Read, Glob, Grep, Bash(pnpm test:*), Bash(pnpm:*)
+allowed-tools: Read, Glob, Grep, Bash(pnpm test:*)
 description: Execute complete TDD cycle - Red, Green, and Refactor phases in sequence
 argument-hint: <feature or requirement description>
 ---
@@ -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

@@ -1,5 +1,4 @@
 ---
-allowed-tools: mcp__beads__list, mcp__beads__ready
 description: Analyze conversation context for unaddressed items and gaps
 ---
 
@@ -8,14 +7,18 @@ Analyze the current conversation context and identify things that have not yet b
 1. **Incomplete implementations** - Code that was started but not finished
 2. **Unused variables/results** - Values that were captured but never used
 3. **Missing tests** - Functionality without test coverage
-5. **User requests** - Things the user asked for that weren't fully completed
-6. **TODO comments** - Any TODOs mentioned in conversation
-7. **Error handling gaps** - Missing error cases or edge cases
-8. **Documentation gaps** - Undocumented APIs or features
+      4. **User requests** - Things the user asked for that weren't fully completed
+5. **TODO comments** - Any TODOs mentioned in conversation
+6. **Error handling gaps** - Missing error cases or edge cases
+7. **Documentation gaps** - Undocumented APIs or features
 
 Present findings as a prioritized list with:
+
 - What the gap is
 - Why it matters
 - Suggested next action
 
 If there are no gaps, confirm that everything discussed has been addressed.
+
+Additional info:
+$ARGUMENTS

package/downloads/without-beads/green.md

@@ -1,5 +1,5 @@
 ---
-allowed-tools: Read, Glob, Grep, Bash(pnpm test:*), Bash(pnpm:*)
+allowed-tools: Read, Glob, Grep, Bash(pnpm test:*)
 description: Execute TDD Green Phase - write minimal implementation to pass the failing test
 argument-hint: <implementation description>
 ---
@@ -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

@@ -1,4 +1,5 @@
 ---
+allowed-tools: Read, Glob, Grep, Bash(pnpm test:*)
 description: Execute TDD Red Phase - write ONE failing test
 ---
 
@@ -25,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

@@ -1,5 +1,5 @@
 ---
-allowed-tools: Read, Glob, Grep, Bash(pnpm test:*), Bash(pnpm:*)
+allowed-tools: Read, Glob, Grep, Bash(pnpm test:*)
 description: Execute TDD Refactor Phase - improve code structure while keeping tests green
 argument-hint: <refactoring description>
 ---
@@ -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/ship.md

@@ -1,5 +1,5 @@
 ---
-allowed-tools: mcp__github__*, Bash(git:*)
+allowed-tools: Bash(git status:*), Bash(git log:*), Bash(git diff:*), Bash(git checkout:*), Bash(git pull:*), Bash(git merge:*), Bash(git push:*), Bash(git branch:*)
 description: Ship code directly to main - for small, obvious changes that don't need review (Cursor's modern alternative to PRs)
 argument-hint: [optional-commit-message]
 ---
@@ -18,6 +18,7 @@ argument-hint: [optional-commit-message]
 > 🎯 **Cursor says**: It's 2025! Not everything needs a PR. Ship small, obvious changes directly.
 
 Ship is for small, obvious changes that don't need code review. Examples:
+
 - Typo fixes
 - Formatting changes
 - Documentation updates
@@ -27,6 +28,7 @@ Ship is for small, obvious changes that don't need code review. Examples:
 ## Prerequisites
 
 Before shipping directly to main:
+
 1. All tests must pass
 2. Linter must pass
 3. Changes must be small and low-risk
@@ -57,10 +59,11 @@ Arguments: $ARGUMENTS
    - Is this a small, obvious change?
    - Do all tests pass?
    - Is CI green?
-   
+
    If ANY of these are "no", suggest using `/show` or `/ask` instead.
 
 5. **Merge to Main**: If all checks pass and user confirms:
+
    ```bash
    git checkout main
    git pull origin main
@@ -69,6 +72,7 @@ Arguments: $ARGUMENTS
    ```
 
 6. **Cleanup**: Delete the feature branch
+
    ```bash
    git branch -d [feature-branch]
    git push origin --delete [feature-branch]
@@ -79,7 +83,7 @@ Arguments: $ARGUMENTS
 ## Safety Rails
 
 If tests fail, linter fails, or changes are large/complex, STOP and suggest:
+
 - Use `/show` for changes that should be seen but don't need approval
 - Use `/ask` (traditional PR) for complex changes needing discussion
 
-

package/downloads/without-beads/show.md

@@ -1,5 +1,5 @@
 ---
-allowed-tools: mcp__github__*, Bash(git:*)
+allowed-tools: mcp__github__create_pull_request, mcp__github__update_pull_request, Bash(git status:*), Bash(git log:*), Bash(git push:*), Bash(git branch:*)
 description: Show code to team with auto-merge - for changes that should be visible but don't need approval (Cursor's modern workflow)
 argument-hint: [optional-pr-title-and-description]
 ---
@@ -18,6 +18,7 @@ argument-hint: [optional-pr-title-and-description]
 > 🚀 **Cursor says**: Not every change needs a traditional review. Show your work, then merge.
 
 Show is for changes that teammates should see, but don't require approval. Examples:
+
 - Refactoring with test coverage
 - New features with comprehensive tests
 - Performance improvements
@@ -26,6 +27,7 @@ Show is for changes that teammates should see, but don't require approval. Examp
 ## Prerequisites
 
 Before using show:
+
 1. All tests must pass
 2. Changes should have good test coverage
 3. Changes should be non-breaking or backward compatible
@@ -60,6 +62,7 @@ Arguments: $ARGUMENTS
    - Add notice that feedback is welcome but not required
 
 4. **PR Description Template**:
+
    ```markdown
    ## 🚀 Show - Auto-merging after CI
 
@@ -71,12 +74,15 @@ Arguments: $ARGUMENTS
    -->
 
    ### What changed
+
    [Brief description]
 
    ### Why
+
    [Rationale for change]
 
    ### Test coverage
+
    - [ ] All tests pass
    - [ ] Coverage maintained/improved
    - [ ] No breaking changes
@@ -87,6 +93,7 @@ Arguments: $ARGUMENTS
 ## Decision Guide
 
 Use **Show** when:
+
 - ✅ Tests are comprehensive
 - ✅ Changes are non-breaking
 - ✅ You're confident in the approach
@@ -96,4 +103,3 @@ Use **/ship** instead if: change is tiny and obvious (typo, formatting)
 
 Use **/ask** instead if: change needs discussion, breaks APIs, or you're uncertain
 
-

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

@@ -1,10 +1,12 @@
 ---
-allowed-tools: AskUserQuestion, mcp__beads__list, mcp__beads__stats
+allowed-tools: AskUserQuestion
 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`