@wbern/claude-instructions 1.6.0 → 1.8.0

package/downloads/with-beads/tdd.md

@@ -9,10 +9,13 @@ argument-hint: [optional-response-to-last-message]
 ## 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
 
+Beads is available for task tracking. Use `mcp__beads__*` tools to manage issues (the user interacts via `bd` commands).
+
 ## TDD Fundamentals
 
 ### The TDD Cycle

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

@@ -9,10 +9,13 @@ argument-hint: <branch-name-or-github-issue-url> [optional-base-branch]
 ## 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
 
+Beads is available for task tracking. Use `mcp__beads__*` tools to manage issues (the user interacts via `bd` commands).
+
 Create a new git worktree for branch: $ARGUMENTS
 
 <current_state>
@@ -72,7 +75,7 @@ Uncommitted changes: !git status --short`
     <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>
+    <example_github_url><https://github.com/owner/project/issues/123> main</example_github_url>
     <default_base_branch>main (if not specified)</default_base_branch>
   </step_1>
 
@@ -182,7 +185,7 @@ Uncommitted changes: !git status --short`
       - packages/*/.env.local
       - (any other .env.local files found)
     </common_locations>
-    <copy_command>find . -name ".env.local" -type f -exec sh -c 'mkdir -p "$(dirname "${parent_path}/${branch_name}/$1")" && cp "$1" "${parent_path}/${branch_name}/$1"' _ {} \;</copy_command>
+    <copy_command>find . -name ".env.local" -type f -exec sh -c 'mkdir -p "$(dirname "${parent_path}/${branch_name}/$1")" && cp "$1" "${parent_path}/${branch_name}/$1"' _{} \;</copy_command>
     <purpose>Preserve local environment configurations for development</purpose>
     <note>Only copies files that exist; ignores missing ones</note>
   </step_9>
@@ -249,14 +252,15 @@ EOF</create_file_command>
 </execution_steps>
 
 <important_notes>
-  - Automatically detects and uses your current IDE (VS Code, VS Code Insiders, Cursor, Zed, etc.)
-  - Creates VS Code-specific tasks.json only for VS Code variants (auto-starts Claude on folder open)
-  - Branch names with slashes (feat/, fix/, etc.) are fully supported
-  - The worktree directory path will match the full branch name including slashes
-  - Settings are copied to maintain the same permissions across worktrees
-  - Environment files (.env.local) are copied to preserve local configurations
-  - Each worktree has its own node_modules installation
-  - Uncommitted changes are automatically stashed and moved to the new worktree
-  - Your work-in-progress seamlessly transfers to the new branch
-  - IDE detection fallback: checks available editors and uses priority order
-</important_notes>
+
+- Automatically detects and uses your current IDE (VS Code, VS Code Insiders, Cursor, Zed, etc.)
+- Creates VS Code-specific tasks.json only for VS Code variants (auto-starts Claude on folder open)
+- Branch names with slashes (feat/, fix/, etc.) are fully supported
+- The worktree directory path will match the full branch name including slashes
+- Settings are copied to maintain the same permissions across worktrees
+- Environment files (.env.local) are copied to preserve local configurations
+- Each worktree has its own node_modules installation
+- Uncommitted changes are automatically stashed and moved to the new worktree
+- Your work-in-progress seamlessly transfers to the new branch
+- IDE detection fallback: checks available editors and uses priority order
+</important_notes>

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

@@ -9,10 +9,13 @@ argument-hint: (no 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
 
+Beads is available for task tracking. Use `mcp__beads__*` tools to manage issues (the user interacts via `bd` commands).
+
 Clean up merged worktrees by finding the oldest merged branch, consolidating settings, and removing stale worktrees.
 
 Additional info: $ARGUMENTS
@@ -212,17 +215,18 @@ Current worktrees: !git worktree list`
 </execution_steps>
 
 <important_notes>
-  - Uses GitHub PR merge status as the ONLY reliable way to verify if a branch was merged
-  - DOES NOT use "git branch --merged" command as it's unreliable for merge verification
-  - Only processes branches with PRs that were definitively merged to main
-  - Skips worktrees without merged PRs and continues to next oldest candidate
-  - Checks and optionally closes related GitHub issues
-  - Prioritizes oldest worktrees by directory age first for systematic cleanup
-  - Warns about very recent worktrees (created within 24 hours) to avoid cleaning active work
-  - Preserves useful development settings before deletion
-  - Requires explicit confirmation before any destructive actions
-  - Handles locked worktrees automatically
-  - Processes one worktree at a time to maintain control
-  - Must be run from main branch for safety
-  - Works with standard GitHub repository URLs (owner/repo format)
-</important_notes>
+
+- Uses GitHub PR merge status as the ONLY reliable way to verify if a branch was merged
+- DOES NOT use "git branch --merged" command as it's unreliable for merge verification
+- Only processes branches with PRs that were definitively merged to main
+- Skips worktrees without merged PRs and continues to next oldest candidate
+- Checks and optionally closes related GitHub issues
+- Prioritizes oldest worktrees by directory age first for systematic cleanup
+- Warns about very recent worktrees (created within 24 hours) to avoid cleaning active work
+- Preserves useful development settings before deletion
+- Requires explicit confirmation before any destructive actions
+- Handles locked worktrees automatically
+- Processes one worktree at a time to maintain control
+- Must be run from main branch for safety
+- Works with standard GitHub repository URLs (owner/repo format)
+</important_notes>

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

@@ -3,10 +3,20 @@ description: Guide for creating new slash commands
 argument-hint: <command-name> <description>
 ---
 
+## 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
+
 # Slash Command Creator Guide
 
 ## How This Command Works
+
 The `/add-command` command shows this guide for creating new slash commands. It includes:
+
 - Command structure and syntax
 - Common patterns and examples
 - Security restrictions and limitations
@@ -15,6 +25,7 @@ The `/add-command` command shows this guide for creating new slash commands. It
 **Note for AI**: When creating commands, you CAN use bash tools like `Bash(mkdir:*)`, `Bash(ls:*)`, `Bash(git status:*)` in the `allowed-tools` frontmatter of NEW commands - but ONLY for operations within the current project directory. This command itself doesn't need bash tools since it's just documentation.
 
 ## Command Locations
+
 - **Personal**: `~/.claude/commands/` (available across all projects)
 - **Project**: `.claude/commands/` (shared with team, shows "(project)")
 
@@ -41,32 +52,40 @@ Bash command output: (exclamation)git status(backticks)
 ## ⚠️ Security Restrictions
 
 **Bash Commands (exclamation prefix)**: Limited to current working directory only.
+
 - ✅ Works: `! + backtick + git status + backtick` (in project dir)
 - ❌ Blocked: `! + backtick + ls /outside/project + backtick` (outside project)  
 - ❌ Blocked: `! + backtick + pwd + backtick` (if referencing dirs outside project)
 
 **File References (`@` prefix)**: No directory restrictions.
+
 - ✅ Works: `@/path/to/system/file.md`
 - ✅ Works: `@../other-project/file.js`
 
 ## Common Patterns
 
 ### Simple Command
+
 ```bash
 echo "Review this code for bugs and suggest fixes" > ~/.claude/commands/review.md
 ```
 
 ### Command with Arguments
+
+**Note for AI**: The example below uses a fullwidth dollar sign (＄, U+FF04) to prevent interpolation in this documentation. When creating actual commands, use the regular `$` character.
+
 ```markdown
-Fix issue #ARGUMENTS following our coding standards
+Fix issue ＄ARGUMENTS following our coding standards
 ```
 
 ### Command with File References
+
 ```markdown
 Compare @src/old.js with @src/new.js and explain differences
 ```
 
 ### Command with Bash Output (Project Directory Only)
+
 ```markdown
 ---
 allowed-tools: Bash(git status:*), Bash(git branch:*), Bash(git log:*)
@@ -81,13 +100,17 @@ Create commit for these changes.
 **Note**: Only works with commands in the current project directory.
 
 ### Namespaced Command
+
+**Note for AI**: The example below uses a fullwidth dollar sign (＄, U+FF04) to prevent interpolation in this documentation. When creating actual commands, use the regular `$` character.
+
 ```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
 ```
 
 ## Frontmatter Options
+
 - `allowed-tools`: Tools this command can use
   - **Important**: Intrusive tools like `Write`, `Edit`, `NotebookEdit` should NEVER be allowed in commands unless the user explicitly requests them. These tools modify files and should only be used when the command's purpose is to make changes.
   - ✅ Safe for most commands: `Read`, `Glob`, `Grep`, `Bash(git status:*)`, `Task`, `AskUserQuestion`
@@ -98,6 +121,7 @@ echo "Ask GPT-5 about: ARGUMENTS" > ~/.claude/commands/ai/gpt5.md
 ## Best Practices
 
 ### Safe Commands (No Security Issues)
+
 ```markdown
 # System prompt editor (file reference only)  
 (@)path/to/system/prompt.md
@@ -106,6 +130,7 @@ Edit your system prompt above.
 ```
 
 ### Project-Specific Commands (Bash OK)
+
 ```markdown
 ---
 allowed-tools: Bash(git status:*), Bash(npm list:*)
@@ -117,6 +142,7 @@ Review project state and suggest next steps.
 ```
 
 ### Cross-Directory File Access (Use @ not !)
+
 ```markdown
 # Compare config files
 Compare (@)path/to/system.md with (@)project/config.md
@@ -125,6 +151,7 @@ Show differences and suggest improvements.
 ```
 
 ## Usage
+
 After creating: `/<command-name> [arguments]`
 
 Example: `/review` or `/ai:gpt5 "explain this code"`

package/downloads/without-beads/ask.md

@@ -9,6 +9,7 @@ argument-hint: [optional-pr-title-and-description]
 ## 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
@@ -132,4 +133,3 @@ Use **Ask** when:
 Use **/show** instead if: confident in approach, just want visibility
 
 Use **/ship** instead if: change is tiny, obvious, and safe
-

package/downloads/without-beads/beepboop.md

@@ -11,11 +11,11 @@ Execute the user's requested task (e.g., posting PR comments, GitHub issue comme
 ## 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
 
-
 ## Instructions
 
 Arguments: $ARGUMENTS

package/downloads/without-beads/busycommit.md

@@ -4,12 +4,17 @@ 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
+## General Guidelines
 
-Include any of the following info if specified: $ARGUMENTS
+### 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
 
+Create multiple atomic git commits, committing the smallest possible logical unit at a time
 
+Include any of the following info if specified: $ARGUMENTS
 
 ## Process
 

package/downloads/without-beads/commit.md

@@ -4,12 +4,17 @@ description: Create a git commit following project standards
 argument-hint: [optional-commit-description]
 ---
 
-Create a git commit following project standards
+## General Guidelines
 
-Include any of the following info if specified: $ARGUMENTS
+### 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
 
+Create a git commit following project standards
 
+Include any of the following info if specified: $ARGUMENTS
 
 ## Process
 

package/downloads/without-beads/cycle.md

@@ -11,11 +11,13 @@ $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
 
 (If there was no info above, fallback to:
+
 1. Context of the conversation, if there's an immediate thing
 2. `bd ready` to see what to work on next and start from there)
 

package/downloads/without-beads/gap.md

@@ -1,16 +1,26 @@
 ---
 description: Analyze conversation context for unaddressed items and gaps
+argument-hint: [optional additional info]
 ---
 
+## 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
+
 Analyze the current conversation context and identify things that have not yet been addressed. Look for:
 
 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. **User requests** - Things the user asked for that weren't fully completed
+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
+8. **Consistency check** - Look for inconsistent patterns, naming conventions, or structure across the codebase
 
 Present findings as a prioritized list with:
 

package/downloads/without-beads/green.md

@@ -11,11 +11,13 @@ $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
 
 (If there was no info above, fallback to:
+
 1. Context of the conversation, if there's an immediate thing
 2. `bd ready` to see what to work on next and start from there)
 

package/downloads/without-beads/issue.md

@@ -9,6 +9,7 @@ Analyze GitHub issue and create TDD implementation plan.
 ## 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
@@ -22,11 +23,12 @@ Process:
 - Or from this bullet point with custom info: $ARGUMENTS
 - If not found: ask user
 
-2. Fetch Issue
+1. Fetch Issue
 
 Try to fetch the issue using GitHub MCP (mcp__github__issue_read tool).
 
 If GitHub MCP is not configured, show:
+
 ```
 GitHub MCP not configured!
 See: https://github.com/modelcontextprotocol/servers/tree/main/src/github
@@ -35,7 +37,7 @@ Trying GitHub CLI fallback...
 
 Then try using `gh issue view [ISSUE_NUMBER] --json` as fallback.
 
-3. Analyze and Plan
+1. Analyze and Plan
 
 Summarize the issue and requirements, then:
 
@@ -44,25 +46,28 @@ Summarize the issue and requirements, then:
 Understand the requirement by asking (use AskUserQuestion if needed):
 
 **Problem Statement**
+
 - What problem does this solve?
 - Who experiences this problem?
 - What's the current pain point?
 
 **Desired Outcome**
+
 - What should happen after this is built?
 - How will users interact with it?
 - What does success look like?
 
 **Scope & Constraints**
+
 - What's in scope vs. out of scope?
 - Any technical constraints?
 - Dependencies on other systems/features?
 
 **Context Check**
+
 - Search codebase for related features/modules
 - Check for existing test files that might be relevant
 
-
 ## TDD Fundamentals
 
 ### The TDD Cycle

package/downloads/without-beads/plan.md

@@ -11,6 +11,7 @@ Create structured implementation plan that bridges product thinking (PRD) with t
 ## 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
@@ -24,6 +25,7 @@ $ARGUMENTS
 ## Input Processing
 
 The input can be one of:
+
 1. **GitHub Issue URL** (e.g., `https://github.com/owner/repo/issues/123`)
 2. **GitHub Issue Number** (e.g., `#123` or `123`)
 3. **Feature Description** (e.g., "Add user authentication")
@@ -34,12 +36,14 @@ The input can be one of:
 If input looks like a GitHub issue:
 
 **Step 1: Extract Issue Number**
+
 - From URL: extract owner/repo/number
 - From number: try to infer repo from git remote
 - From branch name: check patterns like `issue-123`, `123-feature`, `feature/123`
 
 **Step 2: Fetch Issue**
 Try GitHub MCP first:
+
 - If available: use `mcp__github__issue_read` to fetch issue details
 - If not available: show message and try `gh issue view <number>`
 
@@ -50,6 +54,7 @@ Trying GitHub CLI fallback...
 ```
 
 **Step 3: Use Issue as Discovery Input**
+
 - Title → Feature name
 - Description → Problem statement and context
 - Labels → Type/priority hints
@@ -57,6 +62,7 @@ Trying GitHub CLI fallback...
 - Linked issues → Dependencies
 
 Extract from GitHub issue:
+
 - Problem statement and context
 - Acceptance criteria (if present)
 - Technical notes (if present)
@@ -69,38 +75,42 @@ Extract from GitHub issue:
 Understand the requirement by asking (use AskUserQuestion if needed):
 
 **Problem Statement**
+
 - What problem does this solve?
 - Who experiences this problem?
 - What's the current pain point?
 
 **Desired Outcome**
+
 - What should happen after this is built?
 - How will users interact with it?
 - What does success look like?
 
 **Scope & Constraints**
+
 - What's in scope vs. out of scope?
 - Any technical constraints?
 - Dependencies on other systems/features?
 
 **Context Check**
+
 - Search codebase for related features/modules
 - Check for existing test files that might be relevant
 
-
 ## Key Principles
 
 **From PRD World:**
+
 - Start with user problems, not solutions
 - Define success criteria upfront
 - Understand constraints and scope
 
 **From TDD World:**
+
 - Make acceptance criteria test-ready
 - Break work into small, testable pieces
 - Each task should map to test(s)
 
-
 ## Integration with Other Commands
 
 - **Before /plan**: Use `/spike` if you need technical exploration first

package/downloads/without-beads/red.md

@@ -1,21 +1,26 @@
 ---
 allowed-tools: Read, Glob, Grep, Bash(pnpm test:*)
 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:
 
 $ARGUMENTS
 
-(If there was no info above, use info from the current context of conversation. If there was not enough info, ask for it.)
-
 ## 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
 
+(If there was no info above, fallback to:
+
+1. Context of the conversation, if there's an immediate thing
+2. `bd ready` to see what to work on next and start from there)
+
 ## TDD Fundamentals
 
 ### The TDD Cycle

package/downloads/without-beads/refactor.md

@@ -9,11 +9,13 @@ Apply this document (specifically the Refactor phase), to the info given by user
 ## 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
 
 (If there was no info above, fallback to:
+
 1. Context of the conversation, if there's an immediate thing
 2. `bd ready` to see what to work on next and start from there)
 
@@ -88,3 +90,5 @@ This phase is **not part of the regular TDD workflow** and must only be applied
 - In the refactor phase, it is perfectly fine to refactor both test and implementation code. That said, completely new functionality is not allowed. Types, clean up, abstractions, and helpers are allowed as long as they do not introduce new behavior.
 - 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.
+
+1. **Consistency check** - Look for inconsistent patterns, naming conventions, or structure across the codebase

package/downloads/without-beads/ship.md

@@ -9,6 +9,7 @@ argument-hint: [optional-commit-message]
 ## 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
@@ -86,4 +87,3 @@ 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

@@ -9,6 +9,7 @@ argument-hint: [optional-pr-title-and-description]
 ## 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
@@ -102,4 +103,3 @@ Use **Show** when:
 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

@@ -11,11 +11,13 @@ $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
 
 (If there was no info above, fallback to:
+
 1. Context of the conversation, if there's an immediate thing
 2. `bd ready` to see what to work on next and start from there)
 

package/downloads/without-beads/summarize.md

@@ -1,8 +1,17 @@
 ---
 allowed-tools: AskUserQuestion
 description: Summarize conversation progress and next steps
+argument-hint: [optional additional info]
 ---
 
+## 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
+
 Create a concise summary of the current conversation suitable for transferring context to a new conversation.
 
 Additional info: $ARGUMENTS
@@ -12,16 +21,19 @@ Additional info: $ARGUMENTS
 Provide a summary with these sections:
 
 ### What We Did
+
 - Key accomplishments and changes made
 - Important decisions or discoveries
 - Files created, modified, or analyzed
 
 ### What We're Doing Next
+
 - Immediate next steps
 - Pending tasks or work in progress
 - Goals or objectives to continue
 
 ### Blockers & User Input Needed
+
 - Any issues requiring user intervention
 - Decisions that need to be made
 - Missing information or clarifications needed
@@ -29,4 +41,3 @@ Provide a summary with these sections:
 ## Output Format
 
 Keep the summary concise and actionable - suitable for pasting into a new conversation to quickly restore context without needing the full conversation history.
-