@wbern/claude-instructions 1.3.0 → 1.5.0

package/README.md

@@ -24,6 +24,7 @@ npx @wbern/claude-instructions
 ```
 
 The interactive installer lets you choose:
+
 - **Variant**: With or without [Beads MCP](https://github.com/steveyegge/beads) integration
 - **Scope**: User-level (global) or project-level installation
 
@@ -89,6 +90,7 @@ flowchart TB
     Utils --> TDD[📚 /tdd<br/>Remind agent about TDD]
     Utils --> AddCommand[➕ /add-command<br/>Create custom commands]
     Utils --> Summarize[📄 /summarize<br/>Summarize conversation<br/><i>Optional: Beads MCP</i>]
+    Utils --> Gap[🔍 /gap<br/>Find unaddressed items<br/><i>Optional: Beads MCP</i>]
     Utils --> Beepboop[🤖 /beepboop<br/>AI attribution]
 
     Worktree[<b>WORKTREE MANAGEMENT</b>]
@@ -117,10 +119,12 @@ 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)
 - `/summarize` - Summarize conversation progress and next steps
+- `/gap` - Analyze conversation context for unaddressed items and gaps
 
 ### Worktree Management
 
@@ -140,6 +144,7 @@ flowchart TB
 Here's a simple example to get you started with the TDD workflow:
 
 **1. Write a failing test (`/red`)**
+
 ```
 You: /red add a function that validates email addresses
 
@@ -149,6 +154,7 @@ Claude: I'll write a failing test for email validation.
 ```
 
 **2. Make it pass (`/green`)**
+
 ```
 You: /green
 
@@ -158,6 +164,7 @@ Claude: I'll implement the minimal code to pass the test.
 ```
 
 **3. Refactor for quality (`/refactor`)**
+
 ```
 You: /refactor extract regex pattern to a constant
 
@@ -169,18 +176,23 @@ Claude: I'll refactor while keeping tests green.
 ### Complete Workflow Example
 
 **Starting from a GitHub issue:**
+
 ```
 /issue 123
 ```
+
 Claude analyzes the GitHub issue and creates a TDD implementation plan showing what tests to write.
 
 **Running a full TDD cycle:**
+
 ```
 /cycle implement user authentication with password hashing
 ```
+
 Claude executes the complete red-green-refactor cycle: writes a failing test, implements it, then refactors.
 
 **Individual phases for more control:**
+
 ```
 /red test that users can't login with wrong password
 /green
@@ -188,14 +200,17 @@ Claude executes the complete red-green-refactor cycle: writes a failing test, im
 ```
 
 **Committing and creating PRs:**
+
 ```
 /commit
 ```
+
 Claude reviews changes, drafts a commit message following project standards, and creates the commit.
 
 ```
-/pr
+/ask
 ```
+
 Claude analyzes commits, creates a PR with summary and test plan.
 
 ### What to Expect
@@ -220,69 +235,84 @@ The commands enforce TDD discipline: you can't refactor with failing tests, can'
 
 👤 `/red` single element [1] returns 1
 
-🔴 *writes test*
+🔴 _writes test_
+
 ```typescript
 expect(closestToZero([1])).toBe(1);
 ```
+
 FAIL: closestToZero is not defined
 
 👤 `/green`
 
-🟢 *returns hardcoded 1*
+🟢 _returns hardcoded 1_
+
 ```typescript
 function closestToZero(nums: number[]): number {
   return 1; // minimal - only need to pass current test
 }
 ```
+
 ✅ Test passes
 
 👤 `/red` two numbers [3, 2] returns 2
 
-🔴 *writes test*
+🔴 _writes test_
+
 ```typescript
 expect(closestToZero([3, 2])).toBe(2);
 ```
+
 FAIL: expected 1 to be 2
 
 👤 `/green`
 
-🟢 *sorts and returns first*
+🟢 _sorts and returns first_
+
 ```typescript
 function closestToZero(nums: number[]): number {
   return nums.sort((a, b) => a - b)[0]; // minimal
 }
 ```
+
 ✅ 2/2 tests pass
 
 👤 `/red` with negative [-3, 2] returns 2
 
-🔴 *writes test*
+🔴 _writes test_
+
 ```typescript
 expect(closestToZero([-3, 2])).toBe(2);
 ```
+
 FAIL: expected -3 to be 2 (regular sort puts -3 first)
 
 👤 `/green`
 
-🟢 *sorts by absolute value*
+🟢 _sorts by absolute value_
+
 ```typescript
 function closestToZero(nums: number[]): number {
   return nums.sort((a, b) => Math.abs(a) - Math.abs(b))[0];
 }
 ```
+
 ✅ 3/3 tests pass
 
 👤 `/red` exact tie [-2, 2] returns positive 2
 
-🔴 *writes test*
+🔴 _writes test_
+
 ```typescript
 expect(closestToZero([-2, 2])).toBe(2);
 ```
+
 FAIL: expected -2 to be 2 (returns first when tied)
 
 👤 `/green`
 
-🟢 *adds tie-breaking: prefer positive*
+🟢 _adds tie-breaking: prefer positive_
+
 ```typescript
 function closestToZero(nums: number[]): number {
   return nums.sort((a, b) => {
@@ -291,11 +321,13 @@ function closestToZero(nums: number[]): number {
   })[0];
 }
 ```
+
 ✅ 4/4 tests pass
 
 👤 `/refactor` extract helper and use iteration instead of sort
 
-🔵 *extracts helper function for comparison logic*
+🔵 _extracts helper function for comparison logic_
+
 ```typescript
 function isCloser(candidate: number, current: number): boolean {
   const candAbs = Math.abs(candidate);
@@ -314,21 +346,23 @@ function closestToZero(nums: number[]): number {
   return closest;
 }
 ```
+
 ✅ 4/4 tests still pass
 
 👤 `/refactor`
 
-🔵 *uses reduce for more functional style*
+🔵 _uses reduce for more functional style_
+
 ```typescript
 function closestToZero(nums: number[]): number {
   if (nums.length === 0) return 0;
   return nums.reduce((closest, num) =>
-    isCloser(num, closest) ? num : closest
+    isCloser(num, closest) ? num : closest,
   );
 }
 ```
-✅ 4/4 tests still pass
 
+✅ 4/4 tests still pass
 
 ## Contributing
 

package/bin/cli.js

@@ -2,6 +2,7 @@
 
 // scripts/cli.ts
 import { select, text, groupMultiselect, isCancel, intro, outro } from "@clack/prompts";
+import os2 from "os";
 
 // scripts/cli-generator.ts
 import fs from "fs-extra";
@@ -24,14 +25,30 @@ var DIRECTORIES = {
   DOWNLOADS: "downloads"
 };
 var TEMPLATE_SOURCE_FILES = ["CLAUDE.md", "AGENTS.md"];
+var ELLIPSIS = "...";
+function truncatePathFromLeft(pathStr, maxLength) {
+  if (pathStr.length <= maxLength) {
+    return pathStr;
+  }
+  const truncated = pathStr.slice(-(maxLength - ELLIPSIS.length));
+  const firstSlash = truncated.indexOf("/");
+  if (firstSlash > 0) {
+    return ELLIPSIS + truncated.slice(firstSlash);
+  }
+  return ELLIPSIS + truncated;
+}
 var VARIANT_OPTIONS = [
-  { value: VARIANTS.WITH_BEADS, label: "With Beads" },
-  { value: VARIANTS.WITHOUT_BEADS, label: "Without Beads" }
-];
-var SCOPE_OPTIONS = [
-  { value: SCOPES.PROJECT, label: "Project/Repository" },
-  { value: SCOPES.USER, label: "User (Global)" }
+  { value: VARIANTS.WITH_BEADS, label: "With Beads", hint: "Includes Beads task tracking" },
+  { value: VARIANTS.WITHOUT_BEADS, label: "Without Beads", hint: "Standard commands only" }
 ];
+function getScopeOptions(terminalWidth = 80) {
+  const projectPath = path.join(process.cwd(), DIRECTORIES.CLAUDE, DIRECTORIES.COMMANDS);
+  const userPath = path.join(os.homedir(), DIRECTORIES.CLAUDE, DIRECTORIES.COMMANDS);
+  return [
+    { value: SCOPES.PROJECT, label: "Project/Repository", hint: truncatePathFromLeft(projectPath, terminalWidth) },
+    { value: SCOPES.USER, label: "User (Global)", hint: truncatePathFromLeft(userPath, terminalWidth) }
+  ];
+}
 async function getCommandsGroupedByCategory(variant) {
   const sourcePath = path.join(__dirname, "..", DIRECTORIES.DOWNLOADS, variant || VARIANTS.WITH_BEADS);
   const metadataPath = path.join(sourcePath, "commands-metadata.json");
@@ -179,9 +196,11 @@ async function main(args) {
     if (isCancel(variant)) {
       return;
     }
+    const terminalWidth = process.stdout.columns || 80;
+    const uiOverhead = 25;
     scope = await select({
       message: "Select installation scope",
-      options: [...SCOPE_OPTIONS]
+      options: getScopeOptions(terminalWidth - uiOverhead)
     });
     if (isCancel(scope)) {
       return;
@@ -205,7 +224,12 @@ async function main(args) {
     }
   }
   const result = await generateToDirectory(void 0, variant, scope, { commandPrefix, skipTemplateInjection: args?.skipTemplateInjection, commands: selectedCommands });
-  outro(`Installed ${result.filesGenerated} commands to .claude/commands`);
+  const fullPath = scope === "project" ? `${process.cwd()}/.claude/commands` : `${os2.homedir()}/.claude/commands`;
+  outro(`Installed ${result.filesGenerated} commands to ${fullPath}
+
+If Claude Code is already running, restart it to pick up the new commands.
+
+Happy TDD'ing!`);
 }
 
 // scripts/bin.ts

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/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
@@ -131,4 +141,3 @@ Use Beads MCP to:
 - Track dependencies with `bd dep add`
 
 See https://github.com/steveyegge/beads for more information.
-

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

@@ -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/with-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,15 +7,19 @@ 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
-4. **Open issues** - Beads issues that are still open or in progress
-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. **Open issues** - Beads issues that are still open or in progress
+      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/with-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/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

@@ -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/with-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/with-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,6 +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
 
@@ -90,4 +95,3 @@ Use Beads MCP to:
 - Track dependencies with `bd dep add`
 
 See https://github.com/steveyegge/beads for more information.
-