Compare commits

..

1 Commits

Author SHA1 Message Date
Claude
2a0197e654 feat: Add swarm-coordination plugin for multi-agent conflict prevention
Implements three complementary patterns for coordinating multi-agent swarms:

1. Status Polling (Fix 1): Orchestrator periodically spawns status-checker
   agents to monitor swarm health, detect stuck agents, and identify
   conflicts early.

2. File Claiming (Fix 2): Agents claim file ownership before editing via
   a claims registry (.claude/file-claims.md). Prevents multiple agents
   from editing the same file simultaneously.

3. Checkpoint-Based Orchestration (Fix 5): Separates swarm execution into
   phases - planning (read-only), conflict detection, resolution, then
   implementation with monitoring.

Plugin contents:
- /swarm command for full orchestrated workflow
- status-checker agent (haiku, lightweight polling)
- conflict-detector agent (analyzes plans for overlaps)
- plan-reviewer agent (validates individual plans)
- swarm-patterns skill with comprehensive documentation
2025-12-12 01:43:30 +00:00
28 changed files with 2041 additions and 1018 deletions

View File

@@ -1,5 +1,5 @@
---
allowed-tools: Bash(gh issue view:*), Bash(gh search:*), Bash(gh issue list:*), Bash(./scripts/comment-on-duplicates.sh:*)
allowed-tools: Bash(gh issue view:*), Bash(gh search:*), Bash(gh issue list:*), Bash(gh api:*), Bash(gh issue comment:*)
description: Find duplicate GitHub issues
---
@@ -11,13 +11,28 @@ To do this, follow these steps precisely:
2. Use an agent to view a Github issue, and ask the agent to return a summary of the issue
3. Then, launch 5 parallel agents to search Github for duplicates of this issue, using diverse keywords and search approaches, using the summary from #1
4. Next, feed the results from #1 and #2 into another agent, so that it can filter out false positives, that are likely not actually duplicates of the original issue. If there are no duplicates remaining, do not proceed.
5. Finally, use the comment script to post duplicates:
```
./scripts/comment-on-duplicates.sh --base-issue <issue-number> --potential-duplicates <dup1> <dup2> <dup3>
```
5. Finally, comment back on the issue with a list of up to three duplicate issues (or zero, if there are no likely duplicates)
Notes (be sure to tell this to your agents, too):
- Use `gh` to interact with Github, rather than web fetch
- Do not use other tools, beyond `gh` and the comment script (eg. don't use other MCP servers, file edit, etc.)
- Do not use other tools, beyond `gh` (eg. don't use other MCP servers, file edit, etc.)
- Make a todo list first
- For your comment, follow the following format precisely (assuming for this example that you found 3 suspected duplicates):
---
Found 3 possible duplicate issues:
1. <link to issue>
2. <link to issue>
3. <link to issue>
This issue will be automatically closed as a duplicate in 3 days.
- If your issue is a duplicate, please close it and 👍 the existing issue instead
- To prevent auto-closure, add a comment or 👎 this comment
🤖 Generated with [Claude Code](https://claude.ai/code)
---

View File

@@ -17,22 +17,19 @@ jobs:
permissions:
contents: read
issues: write
id-token: write
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Run Claude Code slash command
uses: anthropics/claude-code-action@v1
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
uses: anthropics/claude-code-base-action@beta
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
allowed_non_write_users: "*"
prompt: "/dedupe ${{ github.repository }}/issues/${{ github.event.issue.number || inputs.issue_number }}"
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
claude_args: "--model claude-sonnet-4-5-20250929"
claude_env: |
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- name: Log duplicate comment event to Statsig
if: always()

View File

@@ -11,12 +11,65 @@ jobs:
permissions:
contents: read
issues: write
id-token: write
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Create triage prompt
run: |
mkdir -p /tmp/claude-prompts
cat > /tmp/claude-prompts/triage-prompt.txt << 'EOF'
You're an issue triage assistant for GitHub issues. Your task is to analyze the issue and select appropriate labels from the provided list.
IMPORTANT: Don't post any comments or messages to the issue. Your only action should be to apply labels.
Issue Information:
- REPO: ${{ github.repository }}
- ISSUE_NUMBER: ${{ github.event.issue.number }}
TASK OVERVIEW:
1. First, fetch the list of labels available in this repository by running: `gh label list`. Run exactly this command with nothing else.
2. Next, use the GitHub tools to get context about the issue:
- You have access to these tools:
- mcp__github__get_issue: Use this to retrieve the current issue's details including title, description, and existing labels
- mcp__github__get_issue_comments: Use this to read any discussion or additional context provided in the comments
- mcp__github__update_issue: Use this to apply labels to the issue (do not use this for commenting)
- mcp__github__search_issues: Use this to find similar issues that might provide context for proper categorization and to identify potential duplicate issues
- mcp__github__list_issues: Use this to understand patterns in how other issues are labeled
- Start by using mcp__github__get_issue to get the issue details
3. Analyze the issue content, considering:
- The issue title and description
- The type of issue (bug report, feature request, question, etc.)
- Technical areas mentioned
- Severity or priority indicators
- User impact
- Components affected
4. Select appropriate labels from the available labels list provided above:
- Choose labels that accurately reflect the issue's nature
- Be specific but comprehensive
- Select priority labels if you can determine urgency (high-priority, med-priority, or low-priority)
- Consider platform labels (android, ios) if applicable
- If you find similar issues using mcp__github__search_issues, consider using a "duplicate" label if appropriate. Only do so if the issue is a duplicate of another OPEN issue.
5. Apply the selected labels:
- Use mcp__github__update_issue to apply your selected labels
- DO NOT post any comments explaining your decision
- DO NOT communicate directly with users
- If no labels are clearly applicable, do not apply any labels
IMPORTANT GUIDELINES:
- Be thorough in your analysis
- Only select labels from the provided list above
- DO NOT post any comments to the issue
- Your ONLY action should be to apply labels using mcp__github__update_issue
- It's okay to not add any labels if none are clearly applicable
EOF
- name: Setup GitHub MCP Server
run: |
mkdir -p /tmp/mcp-config
@@ -42,64 +95,13 @@ jobs:
EOF
- name: Run Claude Code for Issue Triage
timeout-minutes: 5
uses: anthropics/claude-code-action@v1
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
uses: anthropics/claude-code-base-action@beta
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
allowed_non_write_users: "*"
prompt: |
You're an issue triage assistant for GitHub issues. Your task is to analyze the issue and select appropriate labels from the provided list.
IMPORTANT: Don't post any comments or messages to the issue. Your only action should be to apply labels.
Issue Information:
- REPO: ${{ github.repository }}
- ISSUE_NUMBER: ${{ github.event.issue.number }}
TASK OVERVIEW:
1. First, fetch the list of labels available in this repository by running: `gh label list`. Run exactly this command with nothing else.
2. Next, use the GitHub tools to get context about the issue:
- You have access to these tools:
- mcp__github__get_issue: Use this to retrieve the current issue's details including title, description, and existing labels
- mcp__github__get_issue_comments: Use this to read any discussion or additional context provided in the comments
- mcp__github__update_issue: Use this to apply labels to the issue (do not use this for commenting)
- mcp__github__search_issues: Use this to find similar issues that might provide context for proper categorization and to identify potential duplicate issues
- mcp__github__list_issues: Use this to understand patterns in how other issues are labeled
- Start by using mcp__github__get_issue to get the issue details
3. Analyze the issue content, considering:
- The issue title and description
- The type of issue (bug report, feature request, question, etc.)
- Technical areas mentioned
- Severity or priority indicators
- User impact
- Components affected
4. Select appropriate labels from the available labels list provided above:
- Choose labels that accurately reflect the issue's nature
- Be specific but comprehensive
- Select priority labels if you can determine urgency (high-priority, med-priority, or low-priority)
- Consider platform labels (android, ios) if applicable
- If you find similar issues using mcp__github__search_issues, consider using a "duplicate" label if appropriate. Only do so if the issue is a duplicate of another OPEN issue.
5. Apply the selected labels:
- Use mcp__github__update_issue to apply your selected labels
- DO NOT post any comments explaining your decision
- DO NOT communicate directly with users
- If no labels are clearly applicable, do not apply any labels
IMPORTANT GUIDELINES:
- Be thorough in your analysis
- Only select labels from the provided list above
- DO NOT post any comments to the issue
- Your ONLY action should be to apply labels using mcp__github__update_issue
- It's okay to not add any labels if none are clearly applicable
prompt_file: /tmp/claude-prompts/triage-prompt.txt
allowed_tools: "Bash(gh label list),mcp__github__get_issue,mcp__github__get_issue_comments,mcp__github__update_issue,mcp__github__search_issues,mcp__github__list_issues"
timeout_minutes: "5"
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
claude_args: |
--model claude-sonnet-4-5-20250929
--mcp-config /tmp/mcp-config/mcp-servers.json
--allowedTools "Bash(gh label list),mcp__github__get_issue,mcp__github__get_issue_comments,mcp__github__update_issue,mcp__github__search_issues,mcp__github__list_issues"
mcp_config: /tmp/mcp-config/mcp-servers.json
claude_args: "--model claude-sonnet-4-5-20250929"
claude_env: |
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

View File

@@ -31,7 +31,7 @@ jobs:
- name: Run Claude Code
id: claude
uses: anthropics/claude-code-action@v1
uses: anthropics/claude-code-action@beta
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
claude_args: "--model claude-sonnet-4-5-20250929"

View File

@@ -16,12 +16,74 @@ jobs:
permissions:
contents: read
issues: write
id-token: write
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Create oncall triage prompt
run: |
mkdir -p /tmp/claude-prompts
cat > /tmp/claude-prompts/oncall-triage-prompt.txt << 'EOF'
You're an oncall triage assistant for GitHub issues. Your task is to identify critical issues that require immediate oncall attention.
Important: Don't post any comments or messages to the issues. Your only action should be to apply the "oncall" label to qualifying issues.
Repository: ${{ github.repository }}
Task overview:
1. Fetch all open issues updated in the last 3 days:
- Use mcp__github__list_issues with:
- state="open"
- first=5 (fetch only 5 issues per page)
- orderBy="UPDATED_AT"
- direction="DESC"
- This will give you the most recently updated issues first
- For each page of results, check the updatedAt timestamp of each issue
- Add issues updated within the last 3 days (72 hours) to your TODO list as you go
- Keep paginating using the 'after' parameter until you encounter issues older than 3 days
- Once you hit issues older than 3 days, you can stop fetching (no need to fetch all open issues)
2. Build your TODO list incrementally as you fetch:
- As you fetch each page, immediately add qualifying issues to your TODO list
- One TODO item per issue number (e.g., "Evaluate issue #123")
- This allows you to start processing while still fetching more pages
3. For each issue in your TODO list:
- Use mcp__github__get_issue to read the issue details (title, body, labels)
- Use mcp__github__get_issue_comments to read all comments
- Evaluate whether this issue needs the oncall label:
a) Is it a bug? (has "bug" label or describes bug behavior)
b) Does it have at least 50 engagements? (count comments + reactions)
c) Is it truly blocking? Read and understand the full content to determine:
- Does this prevent core functionality from working?
- Can users work around it?
- Consider severity indicators: "crash", "stuck", "frozen", "hang", "unresponsive", "cannot use", "blocked", "broken"
- Be conservative - only flag issues that truly prevent users from getting work done
4. For issues that meet all criteria and do not already have the "oncall" label:
- Use mcp__github__update_issue to add the "oncall" label
- Do not post any comments
- Do not remove any existing labels
- Do not remove the "oncall" label from issues that already have it
Important guidelines:
- Use the TODO list to track your progress through ALL candidate issues
- Process issues efficiently - don't read every single issue upfront, work through your TODO list systematically
- Be conservative in your assessment - only flag truly critical blocking issues
- Do not post any comments to issues
- Your only action should be to add the "oncall" label using mcp__github__update_issue
- Mark each issue as complete in your TODO list as you process it
7. After processing all issues in your TODO list, provide a summary of your actions:
- Total number of issues processed (candidate issues evaluated)
- Number of issues that received the "oncall" label
- For each issue that got the label: list issue number, title, and brief reason why it qualified
- Close calls: List any issues that almost qualified but didn't quite meet the criteria (e.g., borderline blocking, had workarounds)
- If no issues qualified, state that clearly
- Format the summary clearly for easy reading
EOF
- name: Setup GitHub MCP Server
run: |
mkdir -p /tmp/mcp-config
@@ -47,72 +109,12 @@ jobs:
EOF
- name: Run Claude Code for Oncall Triage
timeout-minutes: 10
uses: anthropics/claude-code-action@v1
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
uses: anthropics/claude-code-base-action@beta
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
allowed_non_write_users: "*"
prompt: |
You're an oncall triage assistant for GitHub issues. Your task is to identify critical issues that require immediate oncall attention.
Important: Don't post any comments or messages to the issues. Your only action should be to apply the "oncall" label to qualifying issues.
Repository: ${{ github.repository }}
Task overview:
1. Fetch all open issues updated in the last 3 days:
- Use mcp__github__list_issues with:
- state="open"
- first=5 (fetch only 5 issues per page)
- orderBy="UPDATED_AT"
- direction="DESC"
- This will give you the most recently updated issues first
- For each page of results, check the updatedAt timestamp of each issue
- Add issues updated within the last 3 days (72 hours) to your TODO list as you go
- Keep paginating using the 'after' parameter until you encounter issues older than 3 days
- Once you hit issues older than 3 days, you can stop fetching (no need to fetch all open issues)
2. Build your TODO list incrementally as you fetch:
- As you fetch each page, immediately add qualifying issues to your TODO list
- One TODO item per issue number (e.g., "Evaluate issue #123")
- This allows you to start processing while still fetching more pages
3. For each issue in your TODO list:
- Use mcp__github__get_issue to read the issue details (title, body, labels)
- Use mcp__github__get_issue_comments to read all comments
- Evaluate whether this issue needs the oncall label:
a) Is it a bug? (has "bug" label or describes bug behavior)
b) Does it have at least 50 engagements? (count comments + reactions)
c) Is it truly blocking? Read and understand the full content to determine:
- Does this prevent core functionality from working?
- Can users work around it?
- Consider severity indicators: "crash", "stuck", "frozen", "hang", "unresponsive", "cannot use", "blocked", "broken"
- Be conservative - only flag issues that truly prevent users from getting work done
4. For issues that meet all criteria and do not already have the "oncall" label:
- Use mcp__github__update_issue to add the "oncall" label
- Do not post any comments
- Do not remove any existing labels
- Do not remove the "oncall" label from issues that already have it
Important guidelines:
- Use the TODO list to track your progress through ALL candidate issues
- Process issues efficiently - don't read every single issue upfront, work through your TODO list systematically
- Be conservative in your assessment - only flag truly critical blocking issues
- Do not post any comments to issues
- Your only action should be to add the "oncall" label using mcp__github__update_issue
- Mark each issue as complete in your TODO list as you process it
7. After processing all issues in your TODO list, provide a summary of your actions:
- Total number of issues processed (candidate issues evaluated)
- Number of issues that received the "oncall" label
- For each issue that got the label: list issue number, title, and brief reason why it qualified
- Close calls: List any issues that almost qualified but didn't quite meet the criteria (e.g., borderline blocking, had workarounds)
- If no issues qualified, state that clearly
- Format the summary clearly for easy reading
prompt_file: /tmp/claude-prompts/oncall-triage-prompt.txt
allowed_tools: "mcp__github__list_issues,mcp__github__get_issue,mcp__github__get_issue_comments,mcp__github__update_issue"
timeout_minutes: "10"
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
claude_args: |
--mcp-config /tmp/mcp-config/mcp-servers.json
--allowedTools "mcp__github__list_issues,mcp__github__get_issue,mcp__github__get_issue_comments,mcp__github__update_issue"
mcp_config: /tmp/mcp-config/mcp-servers.json
claude_env: |
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

View File

@@ -1,586 +1,8 @@
# Changelog
## 2.1.39
- Added guard against launching Claude Code inside another Claude Code session
- Fixed Agent Teams using wrong model identifier for Bedrock, Vertex, and Foundry customers
- Fixed a crash when MCP tools return image content during streaming
- Fixed /resume session previews showing raw XML tags instead of readable command names
- Improved model error messages for Bedrock/Vertex/Foundry users with fallback suggestions
- Fixed plugin browse showing misleading "Space to Toggle" hint for already-installed plugins
- Fixed hook blocking errors (exit code 2) not showing stderr to the user
- Added `speed` attribute to OTel events and trace spans for fast mode visibility
- Fixed /resume showing interrupt messages as session titles
- Fixed Opus 4.6 launch announcement showing for Bedrock/Vertex/Foundry users
- Improved terminal rendering performance
- Fixed fatal errors being swallowed instead of displayed
- Fixed process hanging after session close
- Fixed character loss at terminal screen boundary
- Fixed blank lines in verbose transcript view
## 2.1.38
- Fixed VS Code terminal scroll-to-top regression introduced in 2.1.37
- Fixed Tab key queueing slash commands instead of autocompleting
- Fixed bash permission matching for commands using environment variable wrappers
- Fixed text between tool uses disappearing when not using streaming
- Fixed duplicate sessions when resuming in VS Code extension
- Improved heredoc delimiter parsing to prevent command smuggling
- Blocked writes to `.claude/skills` directory in sandbox mode
## 2.1.37
- Fixed an issue where /fast was not immediately available after enabling /extra-usage
## 2.1.36
- Fast mode is now available for Opus 4.6. Learn more at https://code.claude.com/docs/en/fast-mode
## 2.1.34
- Fixed a crash when agent teams setting changed between renders
- Fixed a bug where commands excluded from sandboxing (via `sandbox.excludedCommands` or `dangerouslyDisableSandbox`) could bypass the Bash ask permission rule when `autoAllowBashIfSandboxed` was enabled
## 2.1.33
- Fixed agent teammate sessions in tmux to send and receive messages
- Fixed warnings about agent teams not being available on your current plan
- Added `TeammateIdle` and `TaskCompleted` hook events for multi-agent workflows
- Added support for restricting which sub-agents can be spawned via `Task(agent_type)` syntax in agent "tools" frontmatter
- Added `memory` frontmatter field support for agents, enabling persistent memory with `user`, `project`, or `local` scope
- Added plugin name to skill descriptions and `/skills` menu for better discoverability
- Fixed an issue where submitting a new message while the model was in extended thinking would interrupt the thinking phase
- Fixed an API error that could occur when aborting mid-stream, where whitespace text combined with a thinking block would bypass normalization and produce an invalid request
- Fixed API proxy compatibility issue where 404 errors on streaming endpoints no longer triggered non-streaming fallback
- Fixed an issue where proxy settings configured via `settings.json` environment variables were not applied to WebFetch and other HTTP requests on the Node.js build
- Fixed `/resume` session picker showing raw XML markup instead of clean titles for sessions started with slash commands
- Improved error messages for API connection failures — now shows specific cause (e.g., ECONNREFUSED, SSL errors) instead of generic "Connection error"
- Errors from invalid managed settings are now surfaced
- VSCode: Added support for remote sessions, allowing OAuth users to browse and resume sessions from claude.ai
- VSCode: Added git branch and message count to the session picker, with support for searching by branch name
- VSCode: Fixed scroll-to-bottom under-scrolling on initial session load and session switch
## 2.1.32
- Claude Opus 4.6 is now available!
- Added research preview agent teams feature for multi-agent collaboration (token-intensive feature, requires setting CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1)
- Claude now automatically records and recalls memories as it works
- Added "Summarize from here" to the message selector, allowing partial conversation summarization.
- Skills defined in `.claude/skills/` within additional directories (`--add-dir`) are now loaded automatically.
- Fixed `@` file completion showing incorrect relative paths when running from a subdirectory
- Updated --resume to re-use --agent value specified in previous conversation by default.
- Fixed: Bash tool no longer throws "Bad substitution" errors when heredocs contain JavaScript template literals like `${index + 1}`, which previously interrupted tool execution
- Skill character budget now scales with context window (2% of context), so users with larger context windows can see more skill descriptions without truncation
- Fixed Thai/Lao spacing vowels (สระ า, ำ) not rendering correctly in the input field
- VSCode: Fixed slash commands incorrectly being executed when pressing Enter with preceding text in the input field
- VSCode: Added spinner when loading past conversations list
## 2.1.31
- Added session resume hint on exit, showing how to continue your conversation later
- Added support for full-width (zenkaku) space input from Japanese IME in checkbox selection
- Fixed PDF too large errors permanently locking up sessions, requiring users to start a new conversation
- Fixed bash commands incorrectly reporting failure with "Read-only file system" errors when sandbox mode was enabled
- Fixed a crash that made sessions unusable after entering plan mode when project config in `~/.claude.json` was missing default fields
- Fixed `temperatureOverride` being silently ignored in the streaming API path, causing all streaming requests to use the default temperature (1) regardless of the configured override
- Fixed LSP shutdown/exit compatibility with strict language servers that reject null params
- Improved system prompts to more clearly guide the model toward using dedicated tools (Read, Edit, Glob, Grep) instead of bash equivalents (`cat`, `sed`, `grep`, `find`), reducing unnecessary bash command usage
- Improved PDF and request size error messages to show actual limits (100 pages, 20MB)
- Reduced layout jitter in the terminal when the spinner appears and disappears during streaming
- Removed misleading Anthropic API pricing from model selector for third-party provider (Bedrock, Vertex, Foundry) users
## 2.1.30
- Added `pages` parameter to the Read tool for PDFs, allowing specific page ranges to be read (e.g., `pages: "1-5"`). Large PDFs (>10 pages) now return a lightweight reference when `@` mentioned instead of being inlined into context.
- Added pre-configured OAuth client credentials for MCP servers that don't support Dynamic Client Registration (e.g., Slack). Use `--client-id` and `--client-secret` with `claude mcp add`.
- Added `/debug` for Claude to help troubleshoot the current session
- Added support for additional `git log` and `git show` flags in read-only mode (e.g., `--topo-order`, `--cherry-pick`, `--format`, `--raw`)
- Added token count, tool uses, and duration metrics to Task tool results
- Added reduced motion mode to the config
- Fixed phantom "(no content)" text blocks appearing in API conversation history, reducing token waste and potential model confusion
- Fixed prompt cache not correctly invalidating when tool descriptions or input schemas changed, only when tool names changed
- Fixed 400 errors that could occur after running `/login` when the conversation contained thinking blocks
- Fixed a hang when resuming sessions with corrupted transcript files containing `parentUuid` cycles
- Fixed rate limit message showing incorrect "/upgrade" suggestion for Max 20x users when extra-usage is unavailable
- Fixed permission dialogs stealing focus while actively typing
- Fixed subagents not being able to access SDK-provided MCP tools because they were not synced to the shared application state
- Fixed a regression where Windows users with a `.bashrc` file could not run bash commands
- Improved memory usage for `--resume` (68% reduction for users with many sessions) by replacing the session index with lightweight stat-based loading and progressive enrichment
- Improved `TaskStop` tool to display the stopped command/task description in the result line instead of a generic "Task stopped" message
- Changed `/model` to execute immediately instead of being queued
- [VSCode] Added multiline input support to the "Other" text input in question dialogs (use Shift+Enter for new lines)
- [VSCode] Fixed duplicate sessions appearing in the session list when starting a new conversation
## 2.1.29
- Fixed startup performance issues when resuming sessions that have `saved_hook_context`
## 2.1.27
- Added tool call failures and denials to debug logs
- Fixed context management validation error for gateway users, ensuring `CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1` avoids the error
- Added `--from-pr` flag to resume sessions linked to a specific GitHub PR number or URL
- Sessions are now automatically linked to PRs when created via `gh pr create`
- Fixed /context command not displaying colored output
- Fixed status bar duplicating background task indicator when PR status was shown
- Windows: Fixed bash command execution failing for users with `.bashrc` files
- Windows: Fixed console windows flashing when spawning child processes
- VSCode: Fixed OAuth token expiration causing 401 errors after extended sessions
## 2.1.25
- Fixed beta header validation error for gateway users on Bedrock and Vertex, ensuring `CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1` avoids the error
## 2.1.23
- Added customizable spinner verbs setting (`spinnerVerbs`)
- Fixed mTLS and proxy connectivity for users behind corporate proxies or using client certificates
- Fixed per-user temp directory isolation to prevent permission conflicts on shared systems
- Fixed a race condition that could cause 400 errors when prompt caching scope was enabled
- Fixed pending async hooks not being cancelled when headless streaming sessions ended
- Fixed tab completion not updating the input field when accepting a suggestion
- Fixed ripgrep search timeouts silently returning empty results instead of reporting errors
- Improved terminal rendering performance with optimized screen data layout
- Changed Bash commands to show timeout duration alongside elapsed time
- Changed merged pull requests to show a purple status indicator in the prompt footer
- [IDE] Fixed model options displaying incorrect region strings for Bedrock users in headless mode
## 2.1.22
- Fixed structured outputs for non-interactive (-p) mode
## 2.1.21
- Added support for full-width (zenkaku) number input from Japanese IME in option selection prompts
- Fixed shell completion cache files being truncated on exit
- Fixed API errors when resuming sessions that were interrupted during tool execution
- Fixed auto-compact triggering too early on models with large output token limits
- Fixed task IDs potentially being reused after deletion
- Fixed file search not working in VS Code extension on Windows
- Improved read/search progress indicators to show "Reading…" while in progress and "Read" when complete
- Improved Claude to prefer file operation tools (Read, Edit, Write) over bash equivalents (cat, sed, awk)
- [VSCode] Added automatic Python virtual environment activation, ensuring `python` and `pip` commands use the correct interpreter (configurable via `claudeCode.usePythonEnvironment` setting)
- [VSCode] Fixed message action buttons having incorrect background colors
## 2.1.20
- Added arrow key history navigation in vim normal mode when cursor cannot move further
- Added external editor shortcut (Ctrl+G) to the help menu for better discoverability
- Added PR review status indicator to the prompt footer, showing the current branch's PR state (approved, changes requested, pending, or draft) as a colored dot with a clickable link
- Added support for loading `CLAUDE.md` files from additional directories specified via `--add-dir` flag (requires setting `CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1`)
- Added ability to delete tasks via the `TaskUpdate` tool
- Fixed session compaction issues that could cause resume to load full history instead of the compact summary
- Fixed agents sometimes ignoring user messages sent while actively working on a task
- Fixed wide character (emoji, CJK) rendering artifacts where trailing columns were not cleared when replaced by narrower characters
- Fixed JSON parsing errors when MCP tool responses contain special Unicode characters
- Fixed up/down arrow keys in multi-line and wrapped text input to prioritize cursor movement over history navigation
- Fixed draft prompt being lost when pressing UP arrow to navigate command history
- Fixed ghost text flickering when typing slash commands mid-input
- Fixed marketplace source removal not properly deleting settings
- Fixed duplicate output in some commands like `/context`
- Fixed task list sometimes showing outside the main conversation view
- Fixed syntax highlighting for diffs occurring within multiline constructs like Python docstrings
- Fixed crashes when cancelling tool use
- Improved `/sandbox` command UI to show dependency status with installation instructions when dependencies are missing
- Improved thinking status text with a subtle shimmer animation
- Improved task list to dynamically adjust visible items based on terminal height
- Improved fork conversation hint to show how to resume the original session
- Changed collapsed read/search groups to show present tense ("Reading", "Searching for") while in progress, and past tense ("Read", "Searched for") when complete
- Changed `ToolSearch` results to appear as a brief notification instead of inline in the conversation
- Changed the `/commit-push-pr` skill to automatically post PR URLs to Slack channels when configured via MCP tools
- Changed the `/copy` command to be available to all users
- Changed background agents to prompt for tool permissions before launching
- Changed permission rules like `Bash(*)` to be accepted and treated as equivalent to `Bash`
- Changed config backups to be timestamped and rotated (keeping 5 most recent) to prevent data loss
## 2.1.19
- Added env var `CLAUDE_CODE_ENABLE_TASKS`, set to `false` to keep the old system temporarily
- Added shorthand `$0`, `$1`, etc. for accessing individual arguments in custom commands
- Fixed crashes on processors without AVX instruction support
- Fixed dangling Claude Code processes when terminal is closed by catching EIO errors from `process.exit()` and using SIGKILL as fallback
- Fixed `/rename` and `/tag` not updating the correct session when resuming from a different directory (e.g., git worktrees)
- Fixed resuming sessions by custom title not working when run from a different directory
- Fixed pasted text content being lost when using prompt stash (Ctrl+S) and restore
- Fixed agent list displaying "Sonnet (default)" instead of "Inherit (default)" for agents without an explicit model setting
- Fixed backgrounded hook commands not returning early, potentially causing the session to wait on a process that was intentionally backgrounded
- Fixed file write preview omitting empty lines
- Changed skills without additional permissions or hooks to be allowed without requiring approval
- Changed indexed argument syntax from `$ARGUMENTS.0` to `$ARGUMENTS[0]` (bracket syntax)
- [SDK] Added replay of `queued_command` attachment messages as `SDKUserMessageReplay` events when `replayUserMessages` is enabled
- [VSCode] Enabled session forking and rewind functionality for all users
## 2.1.18
- Added customizable keyboard shortcuts. Configure keybindings per context, create chord sequences, and personalize your workflow. Run `/keybindings` to get started. Learn more at https://code.claude.com/docs/en/keybindings
## 2.1.17
- Fixed crashes on processors without AVX instruction support
## 2.1.16
- Added new task management system, including new capabilities like dependency tracking
- [VSCode] Added native plugin management support
- [VSCode] Added ability for OAuth users to browse and resume remote Claude sessions from the Sessions dialog
- Fixed out-of-memory crashes when resuming sessions with heavy subagent usage
- Fixed an issue where the "context remaining" warning was not hidden after running `/compact`
- Fixed session titles on the resume screen not respecting the user's language setting
- [IDE] Fixed a race condition on Windows where the Claude Code sidebar view container would not appear on start
## 2.1.15
- Added deprecation notification for npm installations - run `claude install` or see https://docs.anthropic.com/en/docs/claude-code/getting-started for more options
- Improved UI rendering performance with React Compiler
- Fixed the "Context left until auto-compact" warning not disappearing after running `/compact`
- Fixed MCP stdio server timeout not killing child process, which could cause UI freezes
## 2.1.14
- Added history-based autocomplete in bash mode (`!`) - type a partial command and press Tab to complete from your bash command history
- Added search to installed plugins list - type to filter by name or description
- Added support for pinning plugins to specific git commit SHAs, allowing marketplace entries to install exact versions
- Fixed a regression where the context window blocking limit was calculated too aggressively, blocking users at ~65% context usage instead of the intended ~98%
- Fixed memory issues that could cause crashes when running parallel subagents
- Fixed memory leak in long-running sessions where stream resources were not cleaned up after shell commands completed
- Fixed `@` symbol incorrectly triggering file autocomplete suggestions in bash mode
- Fixed `@`-mention menu folder click behavior to navigate into directories instead of selecting them
- Fixed `/feedback` command generating invalid GitHub issue URLs when description is very long
- Fixed `/context` command to show the same token count and percentage as the status line in verbose mode
- Fixed an issue where `/config`, `/context`, `/model`, and `/todos` command overlays could close unexpectedly
- Fixed slash command autocomplete selecting wrong command when typing similar commands (e.g., `/context` vs `/compact`)
- Fixed inconsistent back navigation in plugin marketplace when only one marketplace is configured
- Fixed iTerm2 progress bar not clearing properly on exit, preventing lingering indicators and bell sounds
- Improved backspace to delete pasted text as a single token instead of one character at a time
- [VSCode] Added `/usage` command to display current plan usage
## 2.1.12
- Fixed message rendering bug
## 2.1.11
- Fixed excessive MCP connection requests for HTTP/SSE transports
## 2.1.10
- Added new `Setup` hook event that can be triggered via `--init`, `--init-only`, or `--maintenance` CLI flags for repository setup and maintenance operations
- Added keyboard shortcut 'c' to copy OAuth URL when browser doesn't open automatically during login
- Fixed a crash when running bash commands containing heredocs with JavaScript template literals like `${index + 1}`
- Improved startup to capture keystrokes typed before the REPL is fully ready
- Improved file suggestions to show as removable attachments instead of inserting text when accepted
- [VSCode] Added install count display to plugin listings
- [VSCode] Added trust warning when installing plugins
## 2.1.9
- Added `auto:N` syntax for configuring the MCP tool search auto-enable threshold, where N is the context window percentage (0-100)
- Added `plansDirectory` setting to customize where plan files are stored
- Added external editor support (Ctrl+G) in AskUserQuestion "Other" input field
- Added session URL attribution to commits and PRs created from web sessions
- Added support for `PreToolUse` hooks to return `additionalContext` to the model
- Added `${CLAUDE_SESSION_ID}` string substitution for skills to access the current session ID
- Fixed long sessions with parallel tool calls failing with an API error about orphan tool_result blocks
- Fixed MCP server reconnection hanging when cached connection promise never resolves
- Fixed Ctrl+Z suspend not working in terminals using Kitty keyboard protocol (Ghostty, iTerm2, kitty, WezTerm)
## 2.1.7
- Added `showTurnDuration` setting to hide turn duration messages (e.g., "Cooked for 1m 6s")
- Added ability to provide feedback when accepting permission prompts
- Added inline display of agent's final response in task notifications, making it easier to see results without reading the full transcript file
- Fixed security vulnerability where wildcard permission rules could match compound commands containing shell operators
- Fixed false "file modified" errors on Windows when cloud sync tools, antivirus scanners, or Git touch file timestamps without changing content
- Fixed orphaned tool_result errors when sibling tools fail during streaming execution
- Fixed context window blocking limit being calculated using the full context window instead of the effective context window (which reserves space for max output tokens)
- Fixed spinner briefly flashing when running local slash commands like `/model` or `/theme`
- Fixed terminal title animation jitter by using fixed-width braille characters
- Fixed plugins with git submodules not being fully initialized when installed
- Fixed bash commands failing on Windows when temp directory paths contained characters like `t` or `n` that were misinterpreted as escape sequences
- Improved typing responsiveness by reducing memory allocation overhead in terminal rendering
- Enabled MCP tool search auto mode by default for all users. When MCP tool descriptions exceed 10% of the context window, they are automatically deferred and discovered via the MCPSearch tool instead of being loaded upfront. This reduces context usage for users with many MCP tools configured. Users can disable this by adding `MCPSearch` to `disallowedTools` in their settings.
- Changed OAuth and API Console URLs from console.anthropic.com to platform.claude.com
- [VSCode] Fixed `claudeProcessWrapper` setting passing the wrapper path instead of the Claude binary path
## 2.1.6
- Added search functionality to `/config` command for quickly filtering settings
- Added Updates section to `/doctor` showing auto-update channel and available npm versions (stable/latest)
- Added date range filtering to `/stats` command - press `r` to cycle between Last 7 days, Last 30 days, and All time
- Added automatic discovery of skills from nested `.claude/skills` directories when working with files in subdirectories
- Added `context_window.used_percentage` and `context_window.remaining_percentage` fields to status line input for easier context window display
- Added an error display when the editor fails during Ctrl+G
- Fixed permission bypass via shell line continuation that could allow blocked commands to execute
- Fixed false "File has been unexpectedly modified" errors when file watchers touch files without changing content
- Fixed text styling (bold, colors) getting progressively misaligned in multi-line responses
- Fixed the feedback panel closing unexpectedly when typing 'n' in the description field
- Fixed rate limit warning appearing at low usage after weekly reset (now requires 70% usage)
- Fixed rate limit options menu incorrectly auto-opening when resuming a previous session
- Fixed numpad keys outputting escape sequences instead of characters in Kitty keyboard protocol terminals
- Fixed Option+Return not inserting newlines in Kitty keyboard protocol terminals
- Fixed corrupted config backup files accumulating in the home directory (now only one backup is created per config file)
- Fixed `mcp list` and `mcp get` commands leaving orphaned MCP server processes
- Fixed visual artifacts in ink2 mode when nodes become hidden via `display:none`
- Improved the external CLAUDE.md imports approval dialog to show which files are being imported and from where
- Improved the `/tasks` dialog to go directly to task details when there's only one background task running
- Improved @ autocomplete with icons for different suggestion types and single-line formatting
- Updated "Help improve Claude" setting fetch to refresh OAuth and retry when it fails due to a stale OAuth token
- Changed task notification display to cap at 3 lines with overflow summary when multiple background tasks complete simultaneously
- Changed terminal title to "Claude Code" on startup for better window identification
- Removed ability to @-mention MCP servers to enable/disable - use `/mcp enable <name>` instead
- [VSCode] Fixed usage indicator not updating after manual compact
## 2.1.5
- Added `CLAUDE_CODE_TMPDIR` environment variable to override the temp directory used for internal temp files, useful for environments with custom temp directory requirements
## 2.1.4
- Added `CLAUDE_CODE_DISABLE_BACKGROUND_TASKS` environment variable to disable all background task functionality including auto-backgrounding and the Ctrl+B shortcut
- Fixed "Help improve Claude" setting fetch to refresh OAuth and retry when it fails due to a stale OAuth token
## 2.1.3
- Merged slash commands and skills, simplifying the mental model with no change in behavior
- Added release channel (`stable` or `latest`) toggle to `/config`
- Added detection and warnings for unreachable permission rules, with warnings in `/doctor` and after saving rules that include the source of each rule and actionable fix guidance
- Fixed plan files persisting across `/clear` commands, now ensuring a fresh plan file is used after clearing a conversation
- Fixed false skill duplicate detection on filesystems with large inodes (e.g., ExFAT) by using 64-bit precision for inode values
- Fixed mismatch between background task count in status bar and items shown in tasks dialog
- Fixed sub-agents using the wrong model during conversation compaction
- Fixed web search in sub-agents using incorrect model
- Fixed trust dialog acceptance when running from the home directory not enabling trust-requiring features like hooks during the session
- Improved terminal rendering stability by preventing uncontrolled writes from corrupting cursor state
- Improved slash command suggestion readability by truncating long descriptions to 2 lines
- Changed tool hook execution timeout from 60 seconds to 10 minutes
- [VSCode] Added clickable destination selector for permission requests, allowing you to choose where settings are saved (this project, all projects, shared with team, or session only)
## 2.1.2
- Added source path metadata to images dragged onto the terminal, helping Claude understand where images originated
- Added clickable hyperlinks for file paths in tool output in terminals that support OSC 8 (like iTerm)
- Added support for Windows Package Manager (winget) installations with automatic detection and update instructions
- Added Shift+Tab keyboard shortcut in plan mode to quickly select "auto-accept edits" option
- Added `FORCE_AUTOUPDATE_PLUGINS` environment variable to allow plugin autoupdate even when the main auto-updater is disabled
- Added `agent_type` to SessionStart hook input, populated if `--agent` is specified
- Fixed a command injection vulnerability in bash command processing where malformed input could execute arbitrary commands
- Fixed a memory leak where tree-sitter parse trees were not being freed, causing WASM memory to grow unbounded over long sessions
- Fixed binary files (images, PDFs, etc.) being accidentally included in memory when using `@include` directives in CLAUDE.md files
- Fixed updates incorrectly claiming another installation is in progress
- Fixed crash when socket files exist in watched directories (defense-in-depth for EOPNOTSUPP errors)
- Fixed remote session URL and teleport being broken when using `/tasks` command
- Fixed MCP tool names being exposed in analytics events by sanitizing user-specific server configurations
- Improved Option-as-Meta hint on macOS to show terminal-specific instructions for native CSIu terminals like iTerm2, Kitty, and WezTerm
- Improved error message when pasting images over SSH to suggest using `scp` instead of the unhelpful clipboard shortcut hint
- Improved permission explainer to not flag routine dev workflows (git fetch/rebase, npm install, tests, PRs) as medium risk
- Changed large bash command outputs to be saved to disk instead of truncated, allowing Claude to read the full content
- Changed large tool outputs to be persisted to disk instead of truncated, providing full output access via file references
- Changed `/plugins` installed tab to unify plugins and MCPs with scope-based grouping
- Deprecated Windows managed settings path `C:\ProgramData\ClaudeCode\managed-settings.json` - administrators should migrate to `C:\Program Files\ClaudeCode\managed-settings.json`
- [SDK] Changed minimum zod peer dependency to ^4.0.0
- [VSCode] Fixed usage display not updating after manual compact
## 2.1.0
- Added automatic skill hot-reload - skills created or modified in `~/.claude/skills` or `.claude/skills` are now immediately available without restarting the session
- Added support for running skills and slash commands in a forked sub-agent context using `context: fork` in skill frontmatter
- Added support for `agent` field in skills to specify agent type for execution
- Added `language` setting to configure Claude's response language (e.g., language: "japanese")
- Changed Shift+Enter to work out of the box in iTerm2, WezTerm, Ghostty, and Kitty without modifying terminal configs
- Added `respectGitignore` support in `settings.json` for per-project control over @-mention file picker behavior
- Added `IS_DEMO` environment variable to hide email and organization from the UI, useful for streaming or recording sessions
- Fixed security issue where sensitive data (OAuth tokens, API keys, passwords) could be exposed in debug logs
- Fixed files and skills not being properly discovered when resuming sessions with `-c` or `--resume`
- Fixed pasted content being lost when replaying prompts from history using up arrow or Ctrl+R search
- Fixed Esc key with queued prompts to only move them to input without canceling the running task
- Reduced permission prompts for complex bash commands
- Fixed command search to prioritize exact and prefix matches on command names over fuzzy matches in descriptions
- Fixed PreToolUse hooks to allow `updatedInput` when returning `ask` permission decision, enabling hooks to act as middleware while still requesting user consent
- Fixed plugin path resolution for file-based marketplace sources
- Fixed LSP tool being incorrectly enabled when no LSP servers were configured
- Fixed background tasks failing with "git repository not found" error for repositories with dots in their names
- Fixed Claude in Chrome support for WSL environments
- Fixed Windows native installer silently failing when executable creation fails
- Improved CLI help output to display options and subcommands in alphabetical order for easier navigation
- Added wildcard pattern matching for Bash tool permissions using `*` at any position in rules (e.g., `Bash(npm *)`, `Bash(* install)`, `Bash(git * main)`)
- Added unified Ctrl+B backgrounding for both bash commands and agents - pressing Ctrl+B now backgrounds all running foreground tasks simultaneously
- Added support for MCP `list_changed` notifications, allowing MCP servers to dynamically update their available tools, prompts, and resources without requiring reconnection
- Added `/teleport` and `/remote-env` slash commands for claude.ai subscribers, allowing them to resume and configure remote sessions
- Added support for disabling specific agents using `Task(AgentName)` syntax in settings.json permissions or the `--disallowedTools` CLI flag
- Added hooks support to agent frontmatter, allowing agents to define PreToolUse, PostToolUse, and Stop hooks scoped to the agent's lifecycle
- Added hooks support for skill and slash command frontmatter
- Added new Vim motions: `;` and `,` to repeat f/F/t/T motions, `y` operator for yank with `yy`/`Y`, `p`/`P` for paste, text objects (`iw`, `aw`, `iW`, `aW`, `i"`, `a"`, `i'`, `a'`, `i(`, `a(`, `i[`, `a[`, `i{`, `a{`), `>>` and `<<` for indent/dedent, and `J` to join lines
- Added `/plan` command shortcut to enable plan mode directly from the prompt
- Added slash command autocomplete support when `/` appears anywhere in input, not just at the beginning
- Added `--tools` flag support in interactive mode to restrict which built-in tools Claude can use during interactive sessions
- Added `CLAUDE_CODE_FILE_READ_MAX_OUTPUT_TOKENS` environment variable to override the default file read token limit
- Added support for `once: true` config for hooks
- Added support for YAML-style lists in frontmatter `allowed-tools` field for cleaner skill declarations
- Added support for prompt and agent hook types from plugins (previously only command hooks were supported)
- Added Cmd+V support for image paste in iTerm2 (maps to Ctrl+V)
- Added left/right arrow key navigation for cycling through tabs in dialogs
- Added real-time thinking block display in Ctrl+O transcript mode
- Added filepath to full output in background bash task details dialog
- Added Skills as a separate category in the context visualization
- Fixed OAuth token refresh not triggering when server reports token expired but local expiration check disagrees
- Fixed session persistence getting stuck after transient server errors by recovering from 409 conflicts when the entry was actually stored
- Fixed session resume failures caused by orphaned tool results during concurrent tool execution
- Fixed a race condition where stale OAuth tokens could be read from the keychain cache during concurrent token refresh attempts
- Fixed AWS Bedrock subagents not inheriting EU/APAC cross-region inference model configuration, causing 403 errors when IAM permissions are scoped to specific regions
- Fixed API context overflow when background tasks produce large output by truncating to 30K chars with file path reference
- Fixed a hang when reading FIFO files by skipping symlink resolution for special file types
- Fixed terminal keyboard mode not being reset on exit in Ghostty, iTerm2, Kitty, and WezTerm
- Fixed Alt+B and Alt+F (word navigation) not working in iTerm2, Ghostty, Kitty, and WezTerm
- Fixed `${CLAUDE_PLUGIN_ROOT}` not being substituted in plugin `allowed-tools` frontmatter, which caused tools to incorrectly require approval
- Fixed files created by the Write tool using hardcoded 0o600 permissions instead of respecting the system umask
- Fixed commands with `$()` command substitution failing with parse errors
- Fixed multi-line bash commands with backslash continuations being incorrectly split and flagged for permissions
- Fixed bash command prefix extraction to correctly identify subcommands after global options (e.g., `git -C /path log` now correctly matches `Bash(git log:*)` rules)
- Fixed slash commands passed as CLI arguments (e.g., `claude /context`) not being executed properly
- Fixed pressing Enter after Tab-completing a slash command selecting a different command instead of submitting the completed one
- Fixed slash command argument hint flickering and inconsistent display when typing commands with arguments
- Fixed Claude sometimes redundantly invoking the Skill tool when running slash commands directly
- Fixed skill token estimates in `/context` to accurately reflect frontmatter-only loading
- Fixed subagents sometimes not inheriting the parent's model by default
- Fixed model picker showing incorrect selection for Bedrock/Vertex users using `--model haiku`
- Fixed duplicate Bash commands appearing in permission request option labels
- Fixed noisy output when background tasks complete - now shows clean completion message instead of raw output
- Fixed background task completion notifications to appear proactively with bullet point
- Fixed forked slash commands showing "AbortError" instead of "Interrupted" message when cancelled
- Fixed cursor disappearing after dismissing permission dialogs
- Fixed `/hooks` menu selecting wrong hook type when scrolling to a different option
- Fixed images in queued prompts showing as "[object Object]" when pressing Esc to cancel
- Fixed images being silently dropped when queueing messages while backgrounding a task
- Fixed large pasted images failing with "Image was too large" error
- Fixed extra blank lines in multiline prompts containing CJK characters (Japanese, Chinese, Korean)
- Fixed ultrathink keyword highlighting being applied to wrong characters when user prompt text wraps to multiple lines
- Fixed collapsed "Reading X files…" indicator incorrectly switching to past tense when thinking blocks appear mid-stream
- Fixed Bash read commands (like `ls` and `cat`) not being counted in collapsed read/search groups, causing groups to incorrectly show "Read 0 files"
- Fixed spinner token counter to properly accumulate tokens from subagents during execution
- Fixed memory leak in git diff parsing where sliced strings retained large parent strings
- Fixed race condition where LSP tool could return "no server available" during startup
- Fixed feedback submission hanging indefinitely when network requests timeout
- Fixed search mode in plugin discovery and log selector views exiting when pressing up arrow
- Fixed hook success message showing trailing colon when hook has no output
- Multiple optimizations to improve startup performance
- Improved terminal rendering performance when using native installer or Bun, especially for text with emoji, ANSI codes, and Unicode characters
- Improved performance when reading Jupyter notebooks with many cells
- Improved reliability for piped input like `cat refactor.md | claude`
- Improved reliability for AskQuestion tool
- Improved sed in-place edit commands to render as file edits with diff preview
- Improved Claude to automatically continue when response is cut off due to output token limit, instead of showing an error message
- Improved compaction reliability
- Improved subagents (Task tool) to continue working after permission denial, allowing them to try alternative approaches
- Improved skills to show progress while executing, displaying tool uses as they happen
- Improved skills from `/skills/` directories to be visible in the slash command menu by default (opt-out with `user-invocable: false` in frontmatter)
- Improved skill suggestions to prioritize recently and frequently used skills
- Improved spinner feedback when waiting for the first response token
- Improved token count display in spinner to include tokens from background agents
- Improved incremental output for async agents to give the main thread more control and visibility
- Improved permission prompt UX with Tab hint moved to footer, cleaner Yes/No input labels with contextual placeholders
- Improved the Claude in Chrome notification with shortened help text and persistent display until dismissed
- Improved macOS screenshot paste reliability with TIFF format support
- Improved `/stats` output
- Updated Atlassian MCP integration to use a more reliable default configuration (streamable HTTP)
- Changed "Interrupted" message color from red to grey for a less alarming appearance
- Removed permission prompt when entering plan mode - users can now enter plan mode without approval
- Removed underline styling from image reference links
- [SDK] Changed minimum zod peer dependency to ^4.0.0
- [VSCode] Added currently selected model name to the context menu
- [VSCode] Added descriptive labels on auto-accept permission button (e.g., "Yes, allow npm for this project" instead of "Yes, and don't ask again")
- [VSCode] Fixed paragraph breaks not rendering in markdown content
- [VSCode] Fixed scrolling in the extension inadvertently scrolling the parent iframe
- [Windows] Fixed issue with improper rendering
## 2.0.76
- Fixed issue with macOS code-sign warning when using Claude in Chrome integration
## 2.0.75
- Minor bugfixes
## 2.0.74
- Added LSP (Language Server Protocol) tool for code intelligence features like go-to-definition, find references, and hover documentation
- Added `/terminal-setup` support for Kitty, Alacritty, Zed, and Warp terminals
- Added ctrl+t shortcut in `/theme` to toggle syntax highlighting on/off
- Added syntax highlighting info to theme picker
- Added guidance for macOS users when Alt shortcuts fail due to terminal configuration
- Fixed skill `allowed-tools` not being applied to tools invoked by the skill
- Fixed Opus 4.5 tip incorrectly showing when user was already using Opus
- Fixed a potential crash when syntax highlighting isn't initialized correctly
- Fixed visual bug in `/plugins discover` where list selection indicator showed while search box was focused
- Fixed macOS keyboard shortcuts to display 'opt' instead of 'alt'
- Improved `/context` command visualization with grouped skills and agents by source, slash commands, and sorted token count
- [Windows] Fixed issue with improper rendering
- [VSCode] Added gift tag pictogram for year-end promotion message
## 2.0.73
- Added clickable `[Image #N]` links that open attached images in the default viewer
- Added alt-y yank-pop to cycle through kill ring history after ctrl-y yank
- Added search filtering to the plugin discover screen (type to filter by name, description, or marketplace)
- Added support for custom session IDs when forking sessions with `--session-id` combined with `--resume` or `--continue` and `--fork-session`
- Fixed slow input history cycling and race condition that could overwrite text after message submission
- Improved `/theme` command to open theme picker directly
- Improved theme picker UI
- Improved search UX across resume session, permissions, and plugins screens with a unified SearchBox component
- [VSCode] Added tab icon badges showing pending permissions (blue) and unread completions (orange)
## 2.0.72
- Added Claude in Chrome (Beta) feature that works with the Chrome extension (https://claude.ai/chrome) to let you control your browser directly from Claude Code
- Reduced terminal flickering
- Added scannable QR code to mobile app tip for quick app downloads
- Added loading indicator when resuming conversations for better feedback
- Fixed `/context` command not respecting custom system prompts in non-interactive mode
- Fixed order of consecutive Ctrl+K lines when pasting with Ctrl+Y
- Improved @ mention file suggestion speed (~3× faster in git repositories)
- Improved file suggestion performance in repos with `.ignore` or `.rgignore` files
- Improved settings validation errors to be more prominent
- Changed thinking toggle from Tab to Alt+T to avoid accidental triggers
## 2.0.71
- Added /config toggle to enable/disable prompt suggestions
- Added `/settings` as an alias for the `/config` command
- Fixed @ file reference suggestions incorrectly triggering when cursor is in the middle of a path
- Fixed MCP servers from `.mcp.json` not loading when using `--dangerously-skip-permissions`
- Fixed permission rules incorrectly rejecting valid bash commands containing shell glob patterns (e.g., `ls *.txt`, `for f in *.png`)
- Bedrock: Environment variable `ANTHROPIC_BEDROCK_BASE_URL` is now respected for token counting and inference profile listing
- New syntax highlighting engine for native build
## 2.0.70
- Added Enter key to accept and submit prompt suggestions immediately (tab still accepts for editing)
- Added wildcard syntax `mcp__server__*` for MCP tool permissions to allow or deny all tools from a server
- Added auto-update toggle for plugin marketplaces, allowing per-marketplace control over automatic updates
- Added `current_usage` field to status line input, enabling accurate context window percentage calculations
- Fixed input being cleared when processing queued commands while the user was typing
- Fixed prompt suggestions replacing typed input when pressing Tab
- Fixed diff view not updating when terminal is resized
- Improved memory usage by 3x for large conversations
- Improved resolution of stats screenshots copied to clipboard (Ctrl+S) for crisper images
- Removed # shortcut for quick memory entry (tell Claude to edit your CLAUDE.md instead)
- Fix thinking mode toggle in /config not persisting correctly
- Improve UI for file creation permission dialog
## 2.0.69
- Minor bugfixes
## 2.0.68
- Fixed IME (Input Method Editor) support for languages like Chinese, Japanese, and Korean by correctly positioning the composition window at the cursor
- Fixed a bug where disallowed MCP tools were visible to the model
- Fixed an issue where steering messages could be lost while a subagent is working
- Fixed Option+Arrow word navigation treating entire CJK (Chinese, Japanese, Korean) text sequences as a single word instead of navigating by word boundaries
- Improved plan mode exit UX: show simplified yes/no dialog when exiting with empty or missing plan instead of throwing an error
- Add support for enterprise managed settings. Contact your Anthropic account team to enable this feature.
## 2.0.67
- Claude now suggests prompts to speed up your workflow: press Tab to accept or Enter to submit
- Thinking mode is now enabled by default for Opus 4.5
- Thinking mode configuration has moved to /config
- Added search functionality to `/permissions` command with `/` keyboard shortcut for filtering rules by tool name

View File

@@ -6,42 +6,35 @@
Claude Code is an agentic coding tool that lives in your terminal, understands your codebase, and helps you code faster by executing routine tasks, explaining complex code, and handling git workflows -- all through natural language commands. Use it in your terminal, IDE, or tag @claude on Github.
**Learn more in the [official documentation](https://code.claude.com/docs/en/overview)**.
**Learn more in the [official documentation](https://docs.anthropic.com/en/docs/claude-code/overview)**.
<img src="./demo.gif" />
## Get started
> [!NOTE]
> Installation via npm is deprecated. Use one of the recommended methods below.
For more installation options, uninstall steps, and troubleshooting, see the [setup documentation](https://code.claude.com/docs/en/setup).
1. Install Claude Code:
**MacOS/Linux (Recommended):**
```bash
curl -fsSL https://claude.ai/install.sh | bash
```
**MacOS/Linux:**
```bash
curl -fsSL https://claude.ai/install.sh | bash
```
**Homebrew (MacOS/Linux):**
```bash
brew install --cask claude-code
```
**Homebrew (MacOS):**
```bash
brew install --cask claude-code
```
**Windows (Recommended):**
```powershell
irm https://claude.ai/install.ps1 | iex
```
**Windows:**
```powershell
irm https://claude.ai/install.ps1 | iex
```
**WinGet (Windows):**
```powershell
winget install Anthropic.ClaudeCode
```
**NPM:**
```bash
npm install -g @anthropic-ai/claude-code
```
**NPM (Deprecated):**
```bash
npm install -g @anthropic-ai/claude-code
```
NOTE: If installing with NPM, you also need to install [Node.js 18+](https://nodejs.org/en/download/)
2. Navigate to your project directory and run `claude`.
@@ -63,7 +56,7 @@ When you use Claude Code, we collect feedback, which includes usage data (such a
### How we use your data
See our [data usage policies](https://code.claude.com/docs/en/data-usage).
See our [data usage policies](https://docs.anthropic.com/en/docs/claude-code/data-usage).
### Privacy safeguards

View File

@@ -1,31 +0,0 @@
# Settings Examples
Example Claude Code settings files, primarily intended for organization-wide deployments. Use these are starting points — adjust them to fit your needs.
These may be applied at any level of the [settings hierarchy](https://code.claude.com/docs/en/settings#settings-files), though certain properties only take effect if specified in enterprise settings (e.g. `strictKnownMarketplaces`, `allowManagedHooksOnly`, `allowManagedPermissionRulesOnly`).
## Configuration Examples
> [!WARNING]
> These examples are community-maintained snippets which may be unsupported or incorrect. You are responsible for the correctness of your own settings configuration.
| Setting | [`settings-lax.json`](./settings-lax.json) | [`settings-strict.json`](./settings-strict.json) | [`settings-bash-sandbox.json`](./settings-bash-sandbox.json) |
|---------|:---:|:---:|:---:|
| Disable `--dangerously-skip-permissions` | ✅ | ✅ | |
| Block plugin marketplaces | ✅ | ✅ | |
| Block user and project-defined permission `allow` / `ask` / `deny` | | ✅ | ✅ |
| Block user and project-defined hooks | | ✅ | |
| Deny web fetch and search tools | | ✅ | |
| Bash tool requires approval | | ✅ | |
| Bash tool must run inside of sandbox | | | ✅ |
## Tips
- Consider merging snippets of the above examples to reach your desired configuration
- Settings files must be valid JSON
- Before deploying configuration files to your organization, test them locally by applying to `managed-settings.json`, `settings.json` or `settings.local.json`
- The `sandbox` property only applies to the `Bash` tool; it does not apply to other tools (like Read, Write, WebSearch, WebFetch, MCPs), hooks, or internal commands
## Full Documentation
See https://code.claude.com/docs/en/settings for complete documentation on all available managed settings.

View File

@@ -1,18 +0,0 @@
{
"allowManagedPermissionRulesOnly": true,
"sandbox": {
"enabled": true,
"autoAllowBashIfSandboxed": false,
"allowUnsandboxedCommands": false,
"excludedCommands": [],
"network": {
"allowUnixSockets": [],
"allowAllUnixSockets": false,
"allowLocalBinding": false,
"allowedDomains": [],
"httpProxyPort": null,
"socksProxyPort": null
},
"enableWeakerNestedSandbox": false
}
}

View File

@@ -1,6 +0,0 @@
{
"permissions": {
"disableBypassPermissionsMode": "disable"
},
"strictKnownMarketplaces": []
}

View File

@@ -1,28 +0,0 @@
{
"permissions": {
"disableBypassPermissionsMode": "disable",
"ask": [
"Bash"
],
"deny": [
"WebSearch",
"WebFetch"
]
},
"allowManagedPermissionRulesOnly": true,
"allowManagedHooksOnly": true,
"strictKnownMarketplaces": [],
"sandbox": {
"autoAllowBashIfSandboxed": false,
"excludedCommands": [],
"network": {
"allowUnixSockets": [],
"allowAllUnixSockets": false,
"allowLocalBinding": false,
"allowedDomains": [],
"httpProxyPort": null,
"socksProxyPort": null
},
"enableWeakerNestedSandbox": false
}
}

View File

@@ -22,29 +22,23 @@ Performs automated code review on a pull request using multiple specialized agen
- **Agent #4**: Analyze git blame/history for context-based issues
5. Scores each issue 0-100 for confidence level
6. Filters out issues below 80 confidence threshold
7. Outputs review (to terminal by default, or as PR comment with `--comment` flag)
7. Posts review comment with high-confidence issues only
**Usage:**
```bash
/code-review [--comment]
/code-review
```
**Options:**
- `--comment`: Post the review as a comment on the pull request (default: outputs to terminal only)
**Example workflow:**
```bash
# On a PR branch, run locally (outputs to terminal):
# On a PR branch, run:
/code-review
# Post review as PR comment:
/code-review --comment
# Claude will:
# - Launch 4 review agents in parallel
# - Score each issue for confidence
# - Output issues ≥80 confidence (to terminal or PR depending on flag)
# - Skip if no high-confidence issues found
# - Post comment with issues ≥80 confidence
# - Skip posting if no high-confidence issues found
```
**Features:**
@@ -120,23 +114,17 @@ This plugin is included in the Claude Code repository. The command is automatica
### Standard PR review workflow:
```bash
# Create PR with changes
# Run local review (outputs to terminal)
/code-review
# Review the automated feedback
# Make any necessary fixes
# Optionally post as PR comment
/code-review --comment
# Merge when ready
```
### As part of CI/CD:
```bash
# Trigger on PR creation or update
# Use --comment flag to post review comments
/code-review --comment
# Automatically posts review comments
# Skip if review already exists
```

View File

@@ -1,21 +1,17 @@
---
allowed-tools: Bash(gh issue view:*), Bash(gh search:*), Bash(gh issue list:*), Bash(gh pr comment:*), Bash(gh pr diff:*), Bash(gh pr view:*), Bash(gh pr list:*), mcp__github_inline_comment__create_inline_comment
allowed-tools: Bash(gh issue view:*), Bash(gh search:*), Bash(gh issue list:*), Bash(gh pr comment:*), Bash(gh pr diff:*), Bash(gh pr view:*), Bash(gh pr list:*)
description: Code review a pull request
---
Provide a code review for the given pull request.
**Agent assumptions (applies to all agents and subagents):**
- All tools are functional and will work without error. Do not test tools or make exploratory calls. Make sure this is clear to every subagent that is launched.
- Only call a tool if it is required to complete the task. Every tool call should have a clear purpose.
To do this, follow these steps precisely:
1. Launch a haiku agent to check if any of the following are true:
- The pull request is closed
- The pull request is a draft
- The pull request does not need code review (e.g. automated PR, trivial change that is obviously correct)
- Claude has already commented on this PR (check `gh pr view <PR> --comments` for comments left by claude)
- You have already submitted a code review on this pull request
If any condition is true, stop and do not proceed.
@@ -38,15 +34,15 @@ Note: Still review Claude generated PR's.
Agent 4: Opus bug agent (parallel subagent with agent 3)
Look for problems that exist in the introduced code. This could be security issues, incorrect logic, etc. Only look for issues that fall within the changed code.
**CRITICAL: We only want HIGH SIGNAL issues.** Flag issues where:
- The code will fail to compile or parse (syntax errors, type errors, missing imports, unresolved references)
- The code will definitely produce wrong results regardless of inputs (clear logic errors)
**CRITICAL: We only want HIGH SIGNAL issues.** This means:
- Objective bugs that will cause incorrect behavior at runtime
- Clear, unambiguous CLAUDE.md violations where you can quote the exact rule being broken
Do NOT flag:
- Code style or quality concerns
- Potential issues that depend on specific inputs or state
- Subjective suggestions or improvements
We do NOT want:
- Subjective concerns or "suggestions"
- Style preferences not explicitly required by CLAUDE.md
- Potential issues that "might" be problems
- Anything requiring interpretation or judgment calls
If you are not certain an issue is real, do not flag it. False positives erode trust and waste reviewer time.
@@ -56,25 +52,12 @@ Note: Still review Claude generated PR's.
6. Filter out any issues that were not validated in step 5. This step will give us our list of high signal issues for our review.
7. Output a summary of the review findings to the terminal:
- If issues were found, list each issue with a brief description.
- If no issues were found, state: "No issues found. Checked for bugs and CLAUDE.md compliance."
If `--comment` argument was NOT provided, stop here. Do not post any GitHub comments.
If `--comment` argument IS provided and NO issues were found, post a summary comment using `gh pr comment` and stop.
If `--comment` argument IS provided and issues were found, continue to step 8.
8. Create a list of all comments that you plan on leaving. This is only for you to make sure you are comfortable with the comments. Do not post this list anywhere.
9. Post inline comments for each issue using `mcp__github_inline_comment__create_inline_comment`. For each comment:
- Provide a brief description of the issue
- For small, self-contained fixes, include a committable suggestion block
- For larger fixes (6+ lines, structural changes, or changes spanning multiple locations), describe the issue and suggested fix without a suggestion block
- Never post a committable suggestion UNLESS committing the suggestion fixes the issue entirely. If follow up steps are required, do not leave a committable suggestion.
**IMPORTANT: Only post ONE comment per unique issue. Do not post duplicate comments.**
7. Finally, comment on the pull request.
When writing your comment, follow these guidelines:
a. Keep your output brief
b. Avoid emojis
c. Link and cite relevant code, files, and URLs for each issue
d. When citing CLAUDE.md violations, you MUST quote the exact text from CLAUDE.md that is being violated (e.g., CLAUDE.md says: "Use snake_case for variable names")
Use this list when evaluating issues in Steps 4 and 5 (these are false positives, do NOT flag):
@@ -89,18 +72,40 @@ Notes:
- Use gh CLI to interact with GitHub (e.g., fetch pull requests, create comments). Do not use web fetch.
- Create a todo list before starting.
- You must cite and link each issue in inline comments (e.g., if referring to a CLAUDE.md, include a link to it).
- If no issues are found and `--comment` argument is provided, post a comment with the following format:
- You must cite and link each issue (e.g., if referring to a CLAUDE.md, include a link to it).
- For your final comment, follow the following format precisely (assuming for this example that you found 3 issues):
---
## Code review
Found 3 issues:
1. <brief description of bug> (CLAUDE.md says: "<exact quote from CLAUDE.md>")
<link to file and line with full sha1 + line range for context, eg. https://github.com/anthropics/claude-code/blob/1d54823877c4de72b2316a64032a54afc404e619/README.md#L13-L17>
2. <brief description of bug> (some/other/CLAUDE.md says: "<exact quote from CLAUDE.md>")
<link to file and line with full sha1 + line range for context>
3. <brief description of bug> (bug due to <file and code snippet>)
<link to file and line with full sha1 + line range for context>
---
- Or, if you found no issues:
---
## Auto code review
No issues found. Checked for bugs and CLAUDE.md compliance.
---
- When linking to code in inline comments, follow the following format precisely, otherwise the Markdown preview won't render correctly: https://github.com/anthropics/claude-code/blob/c21d3c10bc8e898b7ac1a2d745bdc9bc4e423afe/package.json#L10-L15
- When linking to code, follow the following format precisely, otherwise the Markdown preview won't render correctly: https://github.com/anthropics/claude-code/blob/c21d3c10bc8e898b7ac1a2d745bdc9bc4e423afe/package.json#L10-L15
- Requires full git sha
- You must provide the full sha. Commands like `https://github.com/owner/repo/blob/$(git rev-parse HEAD)/foo/bar` will not work, since your comment will be directly rendered in Markdown.
- Repo name must match the repo you're code reviewing

View File

@@ -1,18 +1,26 @@
---
description: "Cancel active Ralph Wiggum loop"
allowed-tools: ["Bash(test -f .claude/ralph-loop.local.md:*)", "Bash(rm .claude/ralph-loop.local.md)", "Read(.claude/ralph-loop.local.md)"]
allowed-tools: ["Bash"]
hide-from-slash-command-tool: "true"
---
# Cancel Ralph
To cancel the Ralph loop:
```!
if [[ -f .claude/ralph-loop.local.md ]]; then
ITERATION=$(grep '^iteration:' .claude/ralph-loop.local.md | sed 's/iteration: *//')
echo "FOUND_LOOP=true"
echo "ITERATION=$ITERATION"
else
echo "FOUND_LOOP=false"
fi
```
1. Check if `.claude/ralph-loop.local.md` exists using Bash: `test -f .claude/ralph-loop.local.md && echo "EXISTS" || echo "NOT_FOUND"`
Check the output above:
2. **If NOT_FOUND**: Say "No active Ralph loop found."
1. **If FOUND_LOOP=false**:
- Say "No active Ralph loop found."
3. **If EXISTS**:
- Read `.claude/ralph-loop.local.md` to get the current iteration number from the `iteration:` field
- Remove the file using Bash: `rm .claude/ralph-loop.local.md`
- Report: "Cancelled Ralph loop (was at iteration N)" where N is the iteration value
2. **If FOUND_LOOP=true**:
- Use Bash: `rm .claude/ralph-loop.local.md`
- Report: "Cancelled Ralph loop (was at iteration N)" where N is the ITERATION value from above.

View File

@@ -1,7 +1,7 @@
---
description: "Start Ralph Wiggum loop in current session"
argument-hint: "PROMPT [--max-iterations N] [--completion-promise TEXT]"
allowed-tools: ["Bash(${CLAUDE_PLUGIN_ROOT}/scripts/setup-ralph-loop.sh:*)"]
allowed-tools: ["Bash(${CLAUDE_PLUGIN_ROOT}/scripts/setup-ralph-loop.sh)"]
hide-from-slash-command-tool: "true"
---
@@ -11,6 +11,36 @@ Execute the setup script to initialize the Ralph loop:
```!
"${CLAUDE_PLUGIN_ROOT}/scripts/setup-ralph-loop.sh" $ARGUMENTS
# Extract and display completion promise if set
if [ -f .claude/ralph-loop.local.md ]; then
PROMISE=$(grep '^completion_promise:' .claude/ralph-loop.local.md | sed 's/completion_promise: *//' | sed 's/^"\(.*\)"$/\1/')
if [ -n "$PROMISE" ] && [ "$PROMISE" != "null" ]; then
echo ""
echo "═══════════════════════════════════════════════════════════"
echo "CRITICAL - Ralph Loop Completion Promise"
echo "═══════════════════════════════════════════════════════════"
echo ""
echo "To complete this loop, output this EXACT text:"
echo " <promise>$PROMISE</promise>"
echo ""
echo "STRICT REQUIREMENTS (DO NOT VIOLATE):"
echo " ✓ Use <promise> XML tags EXACTLY as shown above"
echo " ✓ The statement MUST be completely and unequivocally TRUE"
echo " ✓ Do NOT output false statements to exit the loop"
echo " ✓ Do NOT lie even if you think you should exit"
echo ""
echo "IMPORTANT - Do not circumvent the loop:"
echo " Even if you believe you're stuck, the task is impossible,"
echo " or you've been running too long - you MUST NOT output a"
echo " false promise statement. The loop is designed to continue"
echo " until the promise is GENUINELY TRUE. Trust the process."
echo ""
echo " If the loop should stop, the promise statement will become"
echo " true naturally. Do not force it by lying."
echo "═══════════════════════════════════════════════════════════"
fi
fi
```
Please work on the task. When you try to exit, the Ralph loop will feed the SAME PROMPT back to you for the next iteration. You'll see your previous work in files and git history, allowing you to iterate and improve.

View File

@@ -174,30 +174,3 @@ if [[ -n "$PROMPT" ]]; then
echo ""
echo "$PROMPT"
fi
# Display completion promise requirements if set
if [[ "$COMPLETION_PROMISE" != "null" ]]; then
echo ""
echo "═══════════════════════════════════════════════════════════"
echo "CRITICAL - Ralph Loop Completion Promise"
echo "═══════════════════════════════════════════════════════════"
echo ""
echo "To complete this loop, output this EXACT text:"
echo " <promise>$COMPLETION_PROMISE</promise>"
echo ""
echo "STRICT REQUIREMENTS (DO NOT VIOLATE):"
echo " ✓ Use <promise> XML tags EXACTLY as shown above"
echo " ✓ The statement MUST be completely and unequivocally TRUE"
echo " ✓ Do NOT output false statements to exit the loop"
echo " ✓ Do NOT lie even if you think you should exit"
echo ""
echo "IMPORTANT - Do not circumvent the loop:"
echo " Even if you believe you're stuck, the task is impossible,"
echo " or you've been running too long - you MUST NOT output a"
echo " false promise statement. The loop is designed to continue"
echo " until the promise is GENUINELY TRUE. Trust the process."
echo ""
echo " If the loop should stop, the promise statement will become"
echo " true naturally. Do not force it by lying."
echo "═══════════════════════════════════════════════════════════"
fi

View File

@@ -0,0 +1,7 @@
{
"name": "swarm-coordination",
"version": "1.0.0",
"description": "Coordinates multi-agent swarms with status polling, file claiming, and checkpoint-based orchestration to prevent conflicts and enable proactive monitoring",
"author": "Anthropic",
"keywords": ["swarm", "multi-agent", "coordination", "orchestration", "parallel"]
}

View File

@@ -0,0 +1,152 @@
# Swarm Coordination Plugin
Coordinate multi-agent swarms with conflict prevention, status polling, and checkpoint-based orchestration.
## The Problem
When multiple agents work in parallel on the same codebase, they can:
- Edit the same files simultaneously, creating conflicts
- Make changes that overwrite each other
- Get stuck in endless loops trying to "fix" each other's code
- Waste effort with duplicate work
## The Solution
This plugin implements three complementary coordination patterns:
### 1. Status Polling (Proactive Monitoring)
The orchestrator periodically spawns lightweight status-checker agents to monitor swarm health:
- Detect stuck or failed agents early
- Identify file conflicts as they emerge
- Enable dynamic load balancing
- Provide real-time progress visibility
### 2. File Claiming (Ownership Convention)
Agents claim file ownership before editing:
- Prevents multiple agents from editing the same file
- Clear ownership registry in `.claude/file-claims.md`
- Agents skip files claimed by others
- Claims released after completion
### 3. Checkpoint-Based Orchestration (Phased Execution)
Separate swarm execution into controlled phases:
1. **Planning** - Agents analyze and plan (read-only, parallel)
2. **Review** - Detect conflicts before implementation
3. **Resolution** - Resolve conflicts with user input
4. **Implementation** - Execute with monitoring
5. **Verification** - Validate results
## Quick Start
### Using the `/swarm` Command
```
/swarm Implement user authentication with JWT tokens and session management
```
The command will guide you through:
1. Initializing coordination files
2. Launching planning agents
3. Reviewing and resolving conflicts
4. Executing implementation with monitoring
5. Verifying completion
### Manual Coordination
For custom workflows, use the individual components:
1. Create coordination files:
- `.claude/swarm-status.json`
- `.claude/file-claims.md`
- `.claude/swarm-plans/`
2. Include file claiming instructions in agent prompts
3. Launch status-checker periodically during execution
## Plugin Contents
### Commands
- `/swarm [task]` - Full orchestrated swarm workflow
### Agents
- `status-checker` - Monitors swarm health (haiku, fast)
- `conflict-detector` - Analyzes plans for conflicts
- `plan-reviewer` - Validates individual agent plans
### Skills
- `swarm-patterns` - Documentation and examples
## Coordination Files
### `.claude/swarm-status.json`
```json
{
"swarm_id": "feature-impl-001",
"task": "Implement new feature",
"phase": "implementing",
"agents": {
"agent-1": {"status": "working"},
"agent-2": {"status": "completed"}
}
}
```
### `.claude/file-claims.md`
```markdown
| Agent ID | File Path | Claimed At | Status |
|----------|-----------|------------|--------|
| agent-1 | src/api/handler.ts | 2025-01-15T10:00:00Z | claimed |
| agent-2 | src/db/schema.ts | 2025-01-15T10:00:00Z | released |
```
## Best Practices
1. **Always use planning phase** - Never skip to implementation
2. **Resolve all conflicts** - Don't proceed with overlapping claims
3. **Poll regularly** - Every 30-60 seconds during execution
4. **Use haiku for status checks** - Fast and cheap
5. **Release claims promptly** - Don't hold after completion
## When to Use
Use this plugin when:
- Multiple agents need to work on the same codebase
- Tasks require parallel execution for speed
- You've experienced agent conflicts before
- You need visibility into swarm progress
## When NOT to Use
Skip this plugin when:
- Single agent is sufficient
- Agents work on completely separate codebases
- Tasks are purely read-only (no file modifications)
## Troubleshooting
### Agents Still Conflict
- Ensure all agents include file claiming instructions
- Verify conflict detection ran before implementation
- Check that claims registry is being read
### Status Checker Shows Stuck Agents
- Check agent logs for errors
- Consider increasing timeout
- May need to reassign work
### Claims Not Releasing
- Verify agent completion is being tracked
- Manually update claims if needed
- Check for orchestrator errors
## Learn More
See the `swarm-patterns` skill for detailed documentation:
- `references/status-polling.md` - Polling patterns
- `references/file-claiming.md` - Claiming conventions
- `references/checkpoint-flow.md` - Phased orchestration
- `examples/simple-swarm.md` - Complete example

View File

@@ -0,0 +1,108 @@
---
name: conflict-detector
description: Analyzes agent implementation plans to detect file conflicts before execution. Used in checkpoint-based orchestration to review plans and identify overlapping file edits.
tools: Read, Glob, Grep
model: sonnet
color: orange
---
You are an expert conflict analyst specializing in detecting potential file conflicts between multiple agent implementation plans.
## Core Mission
Review planned changes from multiple agents and identify any files that would be modified by more than one agent, enabling conflict resolution BEFORE implementation begins.
## Analysis Process
**1. Gather Plans**
- Read `.claude/swarm-plans/` directory for all agent plans
- Parse each plan to extract:
- Files to be created
- Files to be modified
- Files to be deleted
- Dependencies on other files
**2. Build File Map**
Create a mapping of file → agents planning to touch it:
```
src/api/handler.ts → [agent-1 (modify), agent-3 (modify)]
src/utils/helper.ts → [agent-2 (create)]
src/types/index.ts → [agent-1 (modify), agent-2 (modify), agent-3 (modify)]
```
**3. Identify Conflicts**
- **Direct conflicts**: Multiple agents modifying same file
- **Creation conflicts**: Multiple agents creating same file
- **Dependency conflicts**: Agent B depends on file Agent A will modify
- **Deletion conflicts**: Agent modifying file another will delete
**4. Assess Severity**
- **Critical**: Same function/class being modified differently
- **Major**: Same file, different sections
- **Minor**: Related files that might have import issues
- **Info**: Same directory but different files
**5. Generate Resolution Strategies**
For each conflict, suggest:
- Which agent should handle the file
- How to sequence the work
- Alternative approaches to avoid conflict
## Output Format
```markdown
## Conflict Analysis Report
### Summary
- Total files planned for modification: [N]
- Files with conflicts: [N]
- Critical conflicts: [N]
- Agents analyzed: [list]
### Critical Conflicts (Must Resolve)
#### Conflict 1: `src/api/handler.ts`
**Agents involved**: agent-1, agent-3
**Nature**: Both agents plan to modify the `handleRequest` function
**Agent-1 plan**: Add authentication check
**Agent-3 plan**: Add rate limiting wrapper
**Resolution options**:
1. **Sequence**: Have agent-1 complete first, then agent-3 builds on top
2. **Merge**: Combine both changes into a single agent's scope
3. **Split**: Agent-1 handles auth in middleware, agent-3 handles rate limiting in handler
**Recommended**: Option 1 - Sequential execution
---
### Major Conflicts (Should Review)
[Similar format]
### Minor Conflicts (Informational)
[Similar format]
### Conflict-Free Assignments
These agents can proceed in parallel without issues:
- agent-2: Only touches `src/utils/` (no overlap)
- agent-4: Only touches `tests/` (no overlap)
### Recommended Execution Order
1. **Parallel batch 1**: agent-2, agent-4 (no conflicts)
2. **Sequential**: agent-1 (depends on nothing, blocks agent-3)
3. **Sequential**: agent-3 (depends on agent-1 completion)
```
## Quality Standards
- Every conflict includes specific file paths
- Resolution options are actionable
- Recommended execution order is provided
- False positives minimized (understand semantic conflicts, not just file overlap)
## Edge Cases
- **No plans found**: Report "No agent plans to analyze"
- **No conflicts**: Report "All agents have non-overlapping scopes"
- **Circular dependencies**: Flag as critical, require manual resolution
- **Unclear plan scope**: Flag for clarification rather than assuming

View File

@@ -0,0 +1,124 @@
---
name: plan-reviewer
description: Reviews an individual agent's implementation plan for completeness, feasibility, and clarity. Used during the planning phase of checkpoint-based orchestration.
tools: Read, Glob, Grep
model: sonnet
color: blue
---
You are an expert plan reviewer specializing in validating implementation plans for autonomous agents.
## Core Mission
Review an agent's implementation plan to ensure it is complete, feasible, and specific enough to execute without ambiguity. Flag issues before the agent begins implementation.
## Review Process
**1. Parse Plan Structure**
- Verify plan follows expected format
- Check all required sections are present
- Ensure file lists are explicit
**2. Validate Scope**
- Files to modify are clearly listed with full paths
- Changes are described with enough detail
- No vague statements like "update as needed"
**3. Check Feasibility**
- Files mentioned actually exist (or creation is explicit)
- Dependencies are identified
- No impossible or conflicting requirements
**4. Assess Risk**
- High-risk changes flagged (deleting files, changing interfaces)
- Breaking changes identified
- Rollback complexity noted
**5. Verify Completeness**
- All aspects of the task are addressed
- Edge cases considered
- Testing approach included (if applicable)
## Plan Format Expected
```markdown
## Agent Plan: [agent-id]
### Task Summary
[What this agent will accomplish]
### Files to Modify
- `path/to/file1.ts`: [Description of changes]
- `path/to/file2.ts`: [Description of changes]
### Files to Create
- `path/to/new-file.ts`: [Purpose and contents summary]
### Files to Delete
- `path/to/old-file.ts`: [Reason for deletion]
### Dependencies
- Requires: [files/features this depends on]
- Blocks: [what cannot proceed until this completes]
### Implementation Steps
1. [Step 1]
2. [Step 2]
...
### Risks and Mitigations
- [Risk]: [Mitigation]
```
## Output Format
```markdown
## Plan Review: [agent-id]
### Overall Assessment: [APPROVED|NEEDS_REVISION|REJECTED]
### Checklist
- [x] Clear task summary
- [x] Explicit file list
- [ ] Missing: dependency identification
- [x] Feasible changes
- [ ] Issue: vague step description
### Issues Found
#### Critical (Must Fix)
1. **Vague file reference**: "update the handler" - which handler? Specify full path.
2. **Missing dependency**: Plan modifies `types/index.ts` but doesn't list it
#### Warnings (Should Address)
1. **High-risk change**: Deleting `utils/legacy.ts` - confirm no other imports
2. **Missing test plan**: No testing approach specified
#### Suggestions (Optional)
1. Consider breaking step 3 into smaller sub-steps
2. Add rollback strategy for interface changes
### Required Changes for Approval
1. Specify exact file path for "handler"
2. Add `types/index.ts` to files list
3. Confirm deletion safety for legacy file
### Approved File Claims
If approved, agent may claim:
- `src/api/auth.ts`
- `src/middleware/validate.ts`
```
## Quality Standards
- Review is thorough but fast (plans should be concise)
- Issues are specific with suggested fixes
- Approval status is clear and actionable
- File claims are explicit for coordination
## Edge Cases
- **Empty plan**: Reject with "No plan content found"
- **Overly broad scope**: Flag and suggest breaking into multiple agents
- **Conflicts with other plans**: Defer to conflict-detector agent
- **Already-implemented changes**: Flag as potential duplicate work

View File

@@ -0,0 +1,81 @@
---
name: status-checker
description: Monitors swarm progress by reading status files, identifying conflicts, stuck agents, and overall health. Launch periodically during swarm execution to enable proactive coordination.
tools: Read, Glob, Grep
model: haiku
color: cyan
---
You are an expert swarm health monitor specializing in tracking multi-agent coordination status.
## Core Mission
Quickly assess swarm health by reading status files and identifying any issues that require orchestrator intervention.
## Status Check Process
**1. Read Swarm Status**
- Read `.claude/swarm-status.json` for current agent states
- Check timestamps to identify stale/stuck agents (>2 minutes without update)
- Note which agents are active, completed, or failed
**2. Check File Claims**
- Read `.claude/file-claims.md` for current file ownership
- Identify any conflicts (multiple agents claiming same file)
- Note stale claims (agent completed but claim not released)
**3. Analyze Progress**
- Calculate overall completion percentage
- Identify bottlenecks (agents waiting on others)
- Detect circular dependencies or deadlocks
**4. Identify Issues**
- **Conflicts**: Multiple agents editing same files
- **Stuck Agents**: No progress for >2 minutes
- **Failed Agents**: Agents that reported errors
- **Stale Claims**: File claims from completed agents
## Output Format
Return a JSON status report:
```json
{
"timestamp": "[current time]",
"overall_health": "healthy|warning|critical",
"completion_percentage": [0-100],
"active_agents": [
{"id": "agent-1", "task": "description", "status": "working", "last_update": "timestamp"}
],
"completed_agents": ["agent-2", "agent-3"],
"issues": {
"conflicts": [
{"file": "path/to/file.ts", "agents": ["agent-1", "agent-4"], "severity": "critical"}
],
"stuck_agents": [
{"id": "agent-5", "last_update": "timestamp", "duration_seconds": 180}
],
"stale_claims": [
{"file": "path/to/file.ts", "agent": "agent-2", "reason": "agent completed"}
]
},
"recommendations": [
{"action": "pause", "target": "agent-4", "reason": "file conflict with agent-1"},
{"action": "reassign", "target": "agent-5", "reason": "stuck for 3 minutes"}
]
}
```
## Quality Standards
- Fast execution (this runs frequently, keep it lightweight)
- Accurate conflict detection (no false positives)
- Clear, actionable recommendations
- Machine-readable JSON output for orchestrator parsing
## Edge Cases
- **No status file exists**: Report as "no swarm active"
- **Empty status file**: Report as "swarm initializing"
- **All agents completed**: Report healthy with 100% completion
- **Multiple critical issues**: Prioritize by severity (conflicts > stuck > stale)

View File

@@ -0,0 +1,287 @@
---
description: Coordinate multi-agent swarm with conflict prevention, status polling, and checkpoint-based orchestration
argument-hint: [task description]
---
# Coordinated Swarm Orchestration
You are orchestrating a multi-agent swarm to complete a complex task. Follow this checkpoint-based workflow to prevent conflicts and enable proactive monitoring.
## Task Description
$ARGUMENTS
---
## Phase 1: Initialization
**Goal**: Set up swarm coordination infrastructure
**Actions**:
1. Create coordination files:
- `.claude/swarm-status.json` - Agent status tracking
- `.claude/file-claims.md` - File ownership registry
- `.claude/swarm-plans/` - Directory for agent plans
2. Initialize status file:
```json
{
"swarm_id": "[generated-id]",
"task": "[task description]",
"started": "[timestamp]",
"phase": "planning",
"agents": {}
}
```
3. Initialize file claims:
```markdown
# File Claims Registry
| Agent ID | File Path | Claimed At | Status |
|----------|-----------|------------|--------|
```
4. Create todo list tracking all phases
---
## Phase 2: Planning (Parallel, Read-Only)
**Goal**: Have multiple agents analyze the codebase and create implementation plans WITHOUT making changes
**Actions**:
1. Launch 2-4 planning agents in parallel, depending on task complexity. Each agent should:
- Analyze a different aspect of the task
- Create a detailed implementation plan
- List ALL files they intend to modify/create/delete
- Identify dependencies on other files or agents
- **CRITICAL**: Agents must NOT edit any files - planning only
2. Each agent writes their plan to `.claude/swarm-plans/[agent-id].md`:
```markdown
## Agent Plan: [agent-id]
### Task Summary
[What this agent will accomplish]
### Files to Modify
- `path/to/file.ts`: [Description of changes]
### Files to Create
- `path/to/new-file.ts`: [Purpose]
### Dependencies
- Requires: [what this depends on]
- Blocks: [what depends on this]
### Implementation Steps
1. [Step 1]
2. [Step 2]
```
3. Update swarm status as agents complete:
```json
{
"agents": {
"agent-1": {"status": "plan_complete", "plan_file": ".claude/swarm-plans/agent-1.md"}
}
}
```
---
## Phase 3: Conflict Detection
**Goal**: Review all plans and identify conflicts before implementation
**Actions**:
1. Wait for ALL planning agents to complete
2. Read all plans from `.claude/swarm-plans/`
3. Launch the **conflict-detector** agent to analyze all plans
4. Review the conflict report
**If conflicts found**:
- Present conflict report to user
- Ask for resolution preference:
- **Sequence**: Execute conflicting agents one at a time
- **Reassign**: Move conflicting files to single agent
- **Manual**: User provides custom resolution
- Update plans based on resolution
- Re-run conflict detection to confirm resolution
**If no conflicts**:
- Proceed to Phase 4
---
## Phase 4: File Claiming
**Goal**: Register file ownership before implementation begins
**Actions**:
1. For each approved plan, register file claims in `.claude/file-claims.md`:
```markdown
| agent-1 | src/api/handler.ts | 2025-01-15T10:30:00Z | claimed |
| agent-1 | src/utils/auth.ts | 2025-01-15T10:30:00Z | claimed |
| agent-2 | src/db/queries.ts | 2025-01-15T10:30:00Z | claimed |
```
2. Determine execution order based on conflict analysis:
- **Parallel batch 1**: Agents with no conflicts or dependencies
- **Sequential queue**: Agents that must wait for others
3. Update swarm status:
```json
{
"phase": "implementing",
"execution_order": [
{"batch": 1, "agents": ["agent-1", "agent-2"], "parallel": true},
{"batch": 2, "agents": ["agent-3"], "parallel": false, "waits_for": ["agent-1"]}
]
}
```
---
## Phase 5: Implementation with Monitoring
**Goal**: Execute implementation with proactive status monitoring
**Actions**:
1. Launch first batch of implementation agents
2. **Status Polling Loop** (every 30-60 seconds during execution):
- Launch a **status-checker** agent (haiku model for speed)
- Review status report
- If issues detected:
- **Conflict**: Pause later agent, let first complete
- **Stuck agent**: Check logs, consider reassignment
- **Failed agent**: Report to user, decide whether to retry or skip
3. As each agent completes:
- Update swarm status: `"status": "completed"`
- Release file claims in `.claude/file-claims.md`: change status to `released`
- Launch next queued agents that were waiting
4. **Agent Instructions** (include in each implementation agent's prompt):
```markdown
## Coordination Requirements
Before editing any file:
1. Read `.claude/file-claims.md`
2. Verify the file is claimed by YOU (your agent ID)
3. If claimed by another agent, SKIP and note in your results
4. If not claimed, DO NOT edit - report the missing claim
After completing work:
1. Update your status in swarm communication
2. Report files modified for claim release
If you encounter a conflict:
1. STOP editing the conflicted file
2. Report the conflict immediately
3. Wait for orchestrator resolution
```
---
## Phase 6: Verification
**Goal**: Verify swarm completed successfully
**Actions**:
1. Check all agents completed:
- Read final swarm status
- Verify all planned files were modified
- Check for any orphaned claims
2. Run integration checks:
- Build/compile if applicable
- Run tests if applicable
- Check for import/type errors
3. Clean up coordination files:
- Archive swarm status to `.claude/swarm-history/`
- Clear file claims
- Remove plan files
---
## Phase 7: Summary
**Goal**: Report swarm execution results
**Actions**:
1. Summarize:
- Total agents launched
- Files modified/created/deleted
- Conflicts detected and resolved
- Issues encountered
- Total execution time
2. Present to user:
- What was accomplished
- Any items requiring follow-up
- Suggested next steps
---
## Error Handling
**Agent Failure**:
1. Log failure in swarm status
2. Release failed agent's file claims
3. Ask user: retry, skip, or abort swarm
**Unresolvable Conflict**:
1. Pause all conflicting agents
2. Present options to user
3. Wait for manual resolution
**Stuck Swarm**:
1. If no progress for 5+ minutes, alert user
2. Provide diagnostic information
3. Offer to abort and roll back
---
## File Claim Convention (For All Agents)
Include this instruction block in every implementation agent's system prompt:
```markdown
## File Claiming Protocol
You are part of a coordinated swarm. Follow these rules strictly:
1. **Before ANY file edit**:
- Read `.claude/file-claims.md`
- Find your agent ID in the registry
- Only edit files claimed by YOUR agent ID
2. **If file is claimed by another agent**:
- DO NOT edit the file
- Note in your results: "Skipped [file] - claimed by [other-agent]"
- Continue with other work
3. **If file is not in claims registry**:
- DO NOT edit the file
- Report: "Cannot edit [file] - not in approved claims"
- This indicates a planning oversight
4. **Update your progress**:
- After each significant step, your status will be tracked
- If you encounter issues, report them clearly
```
---
## Status Polling Schedule
During Phase 5, launch status-checker agent:
- After initial batch launch: wait 30 seconds, then check
- During active execution: check every 45-60 seconds
- After agent completion: immediate check to launch next batch
- On any reported issue: immediate check
Use **haiku model** for status-checker to minimize latency and cost.

View File

@@ -0,0 +1,80 @@
# Swarm Coordination Patterns
Comprehensive guidance for coordinating multi-agent swarms to prevent conflicts and enable proactive monitoring.
## When to Activate
Activate this skill when:
- Orchestrating multiple agents working on the same codebase
- Implementing features that require parallel agent execution
- Designing workflows where agents might edit overlapping files
- Debugging swarm coordination issues
## Core Concepts
### The Problem with Uncoordinated Swarms
When multiple agents work in parallel without coordination:
1. **File Conflicts**: Multiple agents edit the same file simultaneously
2. **Merge Conflicts**: Changes overwrite each other
3. **Endless Loops**: Agents "fix" each other's code in circles
4. **Wasted Work**: Duplicate effort on same files
### Three-Pillar Solution
This skill teaches three complementary patterns:
1. **Status Polling (Fix 1)**: Orchestrator proactively monitors agent progress
2. **File Claiming (Fix 2)**: Agents claim ownership before editing
3. **Checkpoint Orchestration (Fix 5)**: Plan first, detect conflicts, then implement
## Key Files
### Coordination Files
- `.claude/swarm-status.json` - Central status tracking
- `.claude/file-claims.md` - File ownership registry
- `.claude/swarm-plans/` - Agent implementation plans
### Status File Format
```json
{
"swarm_id": "swarm-20250115-abc123",
"task": "Implement user authentication",
"started": "2025-01-15T10:00:00Z",
"phase": "implementing",
"agents": {
"auth-impl": {"status": "working", "last_update": "2025-01-15T10:05:00Z"},
"db-schema": {"status": "completed", "last_update": "2025-01-15T10:03:00Z"}
},
"execution_order": [
{"batch": 1, "agents": ["db-schema"], "parallel": false},
{"batch": 2, "agents": ["auth-impl", "api-routes"], "parallel": true}
]
}
```
### File Claims Format
```markdown
# File Claims Registry
| Agent ID | File Path | Claimed At | Status |
|----------|-----------|------------|--------|
| auth-impl | src/auth/handler.ts | 2025-01-15T10:00:00Z | claimed |
| auth-impl | src/auth/types.ts | 2025-01-15T10:00:00Z | claimed |
| db-schema | src/db/schema.ts | 2025-01-15T10:00:00Z | released |
```
## References
- `references/status-polling.md` - Detailed polling patterns
- `references/file-claiming.md` - File ownership conventions
- `references/checkpoint-flow.md` - Phase-based orchestration
- `examples/simple-swarm.md` - Basic two-agent swarm
- `examples/complex-swarm.md` - Multi-phase feature implementation
## Quick Start
1. Use `/swarm [task]` command for full orchestrated flow
2. For manual coordination, create the three coordination files
3. Include file claiming instructions in all implementation agents
4. Launch status-checker every 30-60 seconds during execution

View File

@@ -0,0 +1,260 @@
# Simple Swarm Example
A two-agent swarm implementing a feature with coordinated file claiming.
## Scenario
Task: Add user authentication to an Express API
## Initial Setup
### Swarm Status File
`.claude/swarm-status.json`:
```json
{
"swarm_id": "auth-feature-001",
"task": "Add user authentication",
"started": "2025-01-15T10:00:00Z",
"phase": "initialized",
"agents": {}
}
```
### File Claims Registry
`.claude/file-claims.md`:
```markdown
# File Claims Registry
Last updated: 2025-01-15T10:00:00Z
Swarm ID: auth-feature-001
| Agent ID | File Path | Claimed At | Status |
|----------|-----------|------------|--------|
```
## Phase 1: Planning
Launch two planning agents:
**Agent 1 Prompt**:
```
Analyze the codebase and create an implementation plan for:
Adding JWT token validation middleware
You are in PLANNING MODE - DO NOT modify any files.
Output a structured plan with all files you need to modify.
```
**Agent 2 Prompt**:
```
Analyze the codebase and create an implementation plan for:
Adding user login/logout API endpoints
You are in PLANNING MODE - DO NOT modify any files.
Output a structured plan with all files you need to modify.
```
### Agent 1 Plan Output
`.claude/swarm-plans/jwt-middleware.md`:
```markdown
## Agent Plan: jwt-middleware
### Task Summary
Implement JWT token validation middleware for protected routes.
### Files to Modify
- `src/middleware/index.ts`: Export new auth middleware
### Files to Create
- `src/middleware/auth.ts`: JWT validation middleware
- `src/types/auth.ts`: Token payload types
### Dependencies
- Requires: None
- Blocks: Protected routes need this middleware
### Implementation Steps
1. Create auth types
2. Implement JWT validation middleware
3. Export from middleware index
```
### Agent 2 Plan Output
`.claude/swarm-plans/auth-endpoints.md`:
```markdown
## Agent Plan: auth-endpoints
### Task Summary
Implement login and logout API endpoints.
### Files to Modify
- `src/routes/index.ts`: Add auth routes
- `src/middleware/index.ts`: Import auth utilities
### Files to Create
- `src/routes/auth.ts`: Login/logout endpoints
- `src/services/auth.ts`: Authentication service
### Dependencies
- Requires: JWT middleware for logout validation
- Blocks: None
### Implementation Steps
1. Create auth service
2. Implement auth routes
3. Update routes index
4. Update middleware index
```
## Phase 2: Conflict Detection
Analyzing plans:
```
File: src/middleware/index.ts
- jwt-middleware: modify (export new middleware)
- auth-endpoints: modify (import auth utilities)
→ CONFLICT DETECTED
```
### Conflict Report
```markdown
## Conflict Analysis
### Conflicts Found: 1
#### Conflict 1: src/middleware/index.ts
Agents: jwt-middleware, auth-endpoints
Nature: Both agents plan to modify this file
- jwt-middleware: Add export for auth middleware
- auth-endpoints: Import auth utilities
**Resolution Options**:
1. Sequential: jwt-middleware first, then auth-endpoints
2. Merge: Have jwt-middleware handle all middleware/index.ts changes
```
## Phase 3: Resolution
**Chosen Resolution**: Option 1 - Sequential execution
Updated execution plan:
- Batch 1: jwt-middleware (no dependencies)
- Batch 2: auth-endpoints (after jwt-middleware completes)
## Phase 4: File Claiming
Updated `.claude/file-claims.md`:
```markdown
# File Claims Registry
Last updated: 2025-01-15T10:05:00Z
Swarm ID: auth-feature-001
| Agent ID | File Path | Claimed At | Status |
|----------|-----------|------------|--------|
| jwt-middleware | src/middleware/auth.ts | 2025-01-15T10:05:00Z | claimed |
| jwt-middleware | src/middleware/index.ts | 2025-01-15T10:05:00Z | claimed |
| jwt-middleware | src/types/auth.ts | 2025-01-15T10:05:00Z | claimed |
| auth-endpoints | src/routes/auth.ts | 2025-01-15T10:05:00Z | pending |
| auth-endpoints | src/routes/index.ts | 2025-01-15T10:05:00Z | pending |
| auth-endpoints | src/services/auth.ts | 2025-01-15T10:05:00Z | pending |
```
Note: auth-endpoints claims are "pending" until jwt-middleware completes.
## Phase 5: Implementation
### Batch 1: jwt-middleware
Launch jwt-middleware agent with implementation instructions:
```
Execute your approved plan from .claude/swarm-plans/jwt-middleware.md
Only modify files claimed by jwt-middleware in .claude/file-claims.md
```
**Status after 45 seconds** (from status-checker):
```json
{
"overall_health": "healthy",
"agents": {
"jwt-middleware": {"status": "working", "progress": "Creating middleware"}
}
}
```
**Status after 2 minutes**:
```json
{
"overall_health": "healthy",
"agents": {
"jwt-middleware": {"status": "completed"}
}
}
```
### Release Claims & Activate Batch 2
Updated `.claude/file-claims.md`:
```markdown
| jwt-middleware | src/middleware/auth.ts | 2025-01-15T10:05:00Z | released |
| jwt-middleware | src/middleware/index.ts | 2025-01-15T10:05:00Z | released |
| jwt-middleware | src/types/auth.ts | 2025-01-15T10:05:00Z | released |
| auth-endpoints | src/routes/auth.ts | 2025-01-15T10:07:00Z | claimed |
| auth-endpoints | src/routes/index.ts | 2025-01-15T10:07:00Z | claimed |
| auth-endpoints | src/services/auth.ts | 2025-01-15T10:07:00Z | claimed |
| auth-endpoints | src/middleware/index.ts | 2025-01-15T10:07:00Z | claimed |
```
Note: auth-endpoints now also claims middleware/index.ts after jwt-middleware released it.
### Batch 2: auth-endpoints
Launch auth-endpoints agent with implementation instructions.
**Status after 3 minutes**:
```json
{
"overall_health": "healthy",
"agents": {
"jwt-middleware": {"status": "completed"},
"auth-endpoints": {"status": "completed"}
},
"completion_percentage": 100
}
```
## Phase 6: Verification
Checks:
- [x] jwt-middleware completed
- [x] auth-endpoints completed
- [x] All files modified as planned
- [x] No orphaned claims
- [x] Build succeeds
- [x] Tests pass
## Phase 7: Summary
```markdown
## Swarm Completion Report
### Task: Add user authentication
### Duration: 8 minutes
### Agents: 2
### Files Created
- src/middleware/auth.ts
- src/types/auth.ts
- src/routes/auth.ts
- src/services/auth.ts
### Files Modified
- src/middleware/index.ts
- src/routes/index.ts
### Conflicts Resolved
- 1 conflict on src/middleware/index.ts (sequential resolution)
### Status: SUCCESS
```

View File

@@ -0,0 +1,287 @@
# Checkpoint-Based Orchestration
A phased approach to swarm execution that prevents conflicts through planning, review, and controlled implementation.
## Overview
Checkpoint-based orchestration separates swarm execution into distinct phases:
1. **Planning** - Agents analyze and plan (read-only)
2. **Review** - Orchestrator detects conflicts
3. **Resolution** - Conflicts resolved before implementation
4. **Claiming** - Files assigned to agents
5. **Implementation** - Agents execute plans
6. **Verification** - Results validated
## Why Checkpoints?
### Without Checkpoints
```
Launch agents → Agents work in parallel → CONFLICT! →
Agents overwrite each other → Endless fix loops → Chaos
```
### With Checkpoints
```
Launch planning agents → Collect plans → Detect conflicts →
Resolve conflicts → Claim files → Sequential/parallel execution → Success
```
## Phase Details
### Phase 1: Planning (Parallel, Read-Only)
**Purpose**: Gather implementation plans without making changes
**Key Rules**:
- Agents may READ any file
- Agents must NOT WRITE any file
- Each agent produces a structured plan
**Agent Instructions**:
```markdown
You are in PLANNING MODE. Analyze the codebase and create an implementation plan.
CRITICAL RESTRICTIONS:
- DO NOT use Edit, Write, or any file modification tools
- DO NOT execute commands that modify files
- ONLY use Read, Glob, Grep for analysis
Your output must be a structured plan listing:
- All files you need to modify (with full paths)
- All files you need to create
- All files you need to delete
- Dependencies on other components
- Step-by-step implementation approach
```
**Plan Format**:
```markdown
## Agent Plan: [agent-id]
### Task Summary
[1-2 sentence description of what this agent will accomplish]
### Files to Modify
- `src/auth/handler.ts`: Add validateToken() function and update handleRequest()
- `src/types/auth.ts`: Add TokenPayload interface
### Files to Create
- `src/auth/tokens.ts`: Token generation and validation utilities
### Files to Delete
- `src/auth/legacy-auth.ts`: Replaced by new implementation
### Dependencies
- **Requires**: Database schema must include users table
- **Blocks**: API routes cannot be updated until auth is complete
### Implementation Steps
1. Create TokenPayload interface in types
2. Implement token utilities in new file
3. Update handler with validation logic
4. Remove legacy file after verification
### Estimated Scope
- Files touched: 4
- Lines added: ~150
- Lines removed: ~80
- Risk level: Medium (touching auth system)
```
### Phase 2: Conflict Detection
**Purpose**: Identify overlapping file edits before they happen
**Process**:
1. Collect all agent plans
2. Build file → agent mapping
3. Identify conflicts:
- Same file modified by multiple agents
- Delete conflicts with modify
- Creation conflicts
- Dependency cycles
**Conflict Types**:
| Type | Severity | Example |
|------|----------|---------|
| Same file modify | Critical | agent-1 and agent-2 both modify handler.ts |
| Create collision | Critical | Both agents create utils/helper.ts |
| Delete + Modify | Critical | agent-1 deletes file agent-2 modifies |
| Dependency cycle | Critical | agent-1 waits for agent-2, agent-2 waits for agent-1 |
| Same directory | Warning | Both agents add files to src/utils/ |
| Import chain | Info | agent-1's file imports from agent-2's file |
### Phase 3: Resolution
**Purpose**: Resolve all conflicts before implementation begins
**Resolution Strategies**:
**Sequential Execution**:
```markdown
Conflict: agent-1 and agent-2 both modify src/api/index.ts
Resolution: Execute sequentially
- Execution order: agent-1 first, then agent-2
- agent-2 will see agent-1's changes before starting
```
**Scope Reassignment**:
```markdown
Conflict: agent-1 (auth) and agent-2 (logging) both modify middleware.ts
Resolution: Reassign to single agent
- Expand agent-1's scope to include logging changes
- Remove middleware.ts from agent-2's plan
```
**File Splitting**:
```markdown
Conflict: agent-1 and agent-2 both modify large config.ts
Resolution: Split the file
- Create config/auth.ts (agent-1)
- Create config/db.ts (agent-2)
- Update config/index.ts to re-export
```
**User Decision**:
```markdown
Conflict: Complex dependency between agent-1 and agent-3
Resolution: Present to user
"Agents 1 and 3 have interleaved dependencies. Options:
1. Merge into single agent
2. Manual sequencing with intermediate reviews
3. Redesign the task split"
```
### Phase 4: File Claiming
**Purpose**: Register file ownership before implementation
**Process**:
1. For each resolved plan, register claims
2. Update `.claude/file-claims.md`
3. Determine execution batches
**Execution Order Determination**:
```markdown
Given resolved plans:
- agent-1: No dependencies
- agent-2: No dependencies
- agent-3: Depends on agent-1
- agent-4: Depends on agent-2 and agent-3
Execution order:
Batch 1 (parallel): agent-1, agent-2
Batch 2 (after batch 1): agent-3
Batch 3 (after agent-3): agent-4
```
### Phase 5: Implementation with Monitoring
**Purpose**: Execute plans with status tracking
**Process**:
1. Launch batch 1 agents
2. Start polling loop (every 30-60 seconds)
3. As agents complete:
- Release their file claims
- Launch dependent agents
4. Handle issues as detected:
- Stuck agents → investigate/reassign
- Conflicts → pause and resolve
- Failures → report and decide
**Agent Instructions for Implementation**:
```markdown
You are now in IMPLEMENTATION MODE. Execute your approved plan.
Your approved plan is in: .claude/swarm-plans/[your-agent-id].md
Your claimed files are in: .claude/file-claims.md
RULES:
1. Only modify files that are claimed by YOUR agent ID
2. Follow your plan exactly - do not expand scope
3. If you need to modify an unclaimed file, STOP and report
4. Update progress by completing your assigned tasks
```
### Phase 6: Verification
**Purpose**: Validate swarm completed successfully
**Checks**:
- [ ] All agents reported completion
- [ ] All planned files were modified
- [ ] No orphaned file claims
- [ ] Build succeeds (if applicable)
- [ ] Tests pass (if applicable)
- [ ] No unexpected files modified
## Checkpoint Gates
Each phase has a gate that must pass before proceeding:
| Gate | Condition | Failure Action |
|------|-----------|----------------|
| Planning → Review | All planning agents completed | Wait or timeout |
| Review → Resolution | Conflict report generated | Re-run detection |
| Resolution → Claiming | All conflicts resolved | Return to resolution |
| Claiming → Implementation | All files claimed, no overlaps | Fix claim issues |
| Implementation → Verification | All agents completed | Investigate failures |
| Verification → Complete | All checks pass | Fix issues or report |
## State Machine
```
┌─────────────┐
│ INITIALIZED │
└──────┬──────┘
│ Start swarm
┌─────────────┐
│ PLANNING │◄────────────────┐
└──────┬──────┘ │
│ All plans received │
▼ │
┌─────────────┐ │
│ REVIEWING │ │
└──────┬──────┘ │
│ Conflicts identified │
▼ │
┌─────────────┐ │
│ RESOLVING │─────────────────┘
└──────┬──────┘ Need re-plan
│ All resolved
┌─────────────┐
│ CLAIMING │
└──────┬──────┘
│ Files assigned
┌─────────────┐
│IMPLEMENTING │◄───┐
└──────┬──────┘ │
│ │ Next batch
▼ │
┌─────────────┐ │
│ VERIFYING │────┘
└──────┬──────┘ More batches
│ All verified
┌─────────────┐
│ COMPLETED │
└─────────────┘
```
## Benefits
1. **No Conflicts**: Detected and resolved before implementation
2. **Visibility**: Know exactly what each agent will do
3. **Control**: Orchestrator maintains full oversight
4. **Recovery**: Can roll back or adjust between phases
5. **Efficiency**: Parallel execution where safe, sequential where needed

View File

@@ -0,0 +1,233 @@
# File Claiming Convention
A coordination protocol where agents claim file ownership before editing to prevent conflicts.
## Overview
File claiming is a simple but effective convention:
1. Before editing any file, agent checks if it's claimed
2. If unclaimed or claimed by self, proceed
3. If claimed by another agent, skip and report
4. After completion, release claims
## The Claims Registry
Location: `.claude/file-claims.md`
### Format
```markdown
# File Claims Registry
Last updated: 2025-01-15T10:30:00Z
Swarm ID: swarm-20250115-abc123
| Agent ID | File Path | Claimed At | Status |
|----------|-----------|------------|--------|
| auth-impl | src/auth/handler.ts | 2025-01-15T10:00:00Z | claimed |
| auth-impl | src/auth/types.ts | 2025-01-15T10:00:00Z | claimed |
| auth-impl | src/auth/middleware.ts | 2025-01-15T10:00:00Z | claimed |
| db-agent | src/db/schema.ts | 2025-01-15T10:00:00Z | released |
| db-agent | src/db/queries.ts | 2025-01-15T10:00:00Z | released |
```
### Status Values
| Status | Meaning |
|--------|---------|
| `claimed` | Agent is actively working on this file |
| `released` | Agent completed, file available |
| `conflict` | Multiple agents claimed (needs resolution) |
## Agent Instructions
Include this block in every implementation agent's system prompt:
```markdown
## File Claiming Protocol
You are part of a coordinated swarm. Follow these rules strictly:
### Before ANY File Edit
1. Read `.claude/file-claims.md`
2. Find the file you want to edit in the registry
3. Check the claim status:
**If claimed by YOUR agent ID** → Proceed with edit
**If claimed by ANOTHER agent** → DO NOT edit, report:
"Skipped [file] - claimed by [other-agent]"
**If file NOT in registry** → DO NOT edit, report:
"Cannot edit [file] - not in approved claims"
### During Execution
- Only edit files explicitly claimed by you
- If you discover a need to edit an unclaimed file, report it
- Do not modify the claims registry yourself
### After Completion
Report all files you modified so claims can be released.
```
## Claim Lifecycle
```
┌─────────────────────────────────────────────────────────┐
│ PLANNING PHASE │
│ Agent creates plan → Lists files to modify │
└────────────────────────┬────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ CONFLICT DETECTION │
│ Orchestrator reviews all plans → Identifies overlaps │
│ Resolves conflicts → Determines execution order │
└────────────────────────┬────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ CLAIM REGISTRATION │
│ Orchestrator writes claims to registry │
│ Each file → exactly one agent │
└────────────────────────┬────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ IMPLEMENTATION │
│ Agents check registry before each edit │
│ Only edit files claimed by self │
└────────────────────────┬────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ CLAIM RELEASE │
│ Agent completes → Reports to orchestrator │
│ Orchestrator marks claims as "released" │
└─────────────────────────────────────────────────────────┘
```
## Conflict Resolution Strategies
When multiple agents need the same file:
### Strategy 1: Sequential Execution
```markdown
Conflict: agent-1 and agent-3 both need src/api/handler.ts
Resolution:
- agent-1 claims file, executes first
- After agent-1 completes, release claim
- agent-3 claims file, executes second
```
### Strategy 2: Scope Partition
```markdown
Conflict: agent-1 and agent-2 both need src/types/index.ts
Resolution:
- Split file into src/types/auth.ts and src/types/user.ts
- agent-1 claims auth.ts
- agent-2 claims user.ts
- Update index.ts to re-export (claimed by orchestrator)
```
### Strategy 3: Merge Responsibility
```markdown
Conflict: agent-1 (auth) and agent-2 (validation) both need middleware.ts
Resolution:
- Expand agent-1's scope to include validation changes
- Remove middleware.ts from agent-2's plan
- agent-1 handles all middleware changes
```
### Strategy 4: Section-Based Claims
```markdown
Conflict: Multiple agents need same config file
Resolution:
- Claim specific sections rather than whole file
- agent-1 claims: config.ts lines 1-50 (auth section)
- agent-2 claims: config.ts lines 51-100 (db section)
- Requires careful merge at end
```
## Handling Violations
### Agent Edits Unclaimed File
```markdown
Detected: agent-2 modified src/utils/helper.ts (not in claims)
Response:
1. Flag as violation in status report
2. Options:
a. Add retroactive claim if no conflict
b. Revert change if conflicts with another agent
c. Pause agent and request clarification
```
### Agent Edits Another's File
```markdown
Detected: agent-2 modified src/auth/handler.ts (claimed by agent-1)
Response:
1. CRITICAL violation
2. Pause agent-2 immediately
3. Check if agent-1's work is corrupted
4. Options:
a. Revert agent-2's changes
b. Have agent-1 re-do affected work
c. Manual merge by orchestrator
```
## Best Practices
1. **Register claims BEFORE launching agents** - Not during
2. **One file, one owner** - Never have overlapping claims
3. **Include all touched files** - Even read-heavy files if modified
4. **Release promptly** - Don't hold claims after completion
5. **Verify at completion** - Check all claimed files were handled
6. **Track unclaimed edits** - They indicate planning gaps
## Claims Registry Management
### Creating the Registry
```markdown
# File Claims Registry
Last updated: [timestamp]
Swarm ID: [swarm-id]
| Agent ID | File Path | Claimed At | Status |
|----------|-----------|------------|--------|
```
### Adding Claims (Orchestrator Only)
```markdown
| new-agent | src/new/file.ts | [timestamp] | claimed |
```
### Releasing Claims
Change status from `claimed` to `released`:
```markdown
| agent-id | src/file.ts | [timestamp] | released |
```
### Cleaning Up
After swarm completion:
1. Archive registry to `.claude/swarm-history/`
2. Delete or clear current registry
3. Ready for next swarm

View File

@@ -0,0 +1,152 @@
# Status Polling Pattern
Proactive orchestrator monitoring for swarm health and conflict detection.
## Overview
Instead of fire-and-forget agent launching, the orchestrator periodically spawns lightweight "status checker" agents to monitor swarm progress and identify issues early.
## Why Polling Matters
Without polling:
- Orchestrator has no visibility into agent progress
- Conflicts discovered only after damage is done
- Stuck agents waste time until final timeout
- No opportunity for mid-execution corrections
With polling:
- Real-time visibility into agent status
- Conflicts detected and resolved quickly
- Stuck agents identified and reassigned
- Dynamic load balancing possible
## Polling Schedule
### Recommended Intervals
| Phase | Interval | Reason |
|-------|----------|--------|
| Initial launch | 30 seconds | Catch early failures fast |
| Active execution | 45-60 seconds | Balance visibility vs overhead |
| Near completion | 30 seconds | Ensure clean handoffs |
| Post-completion | Immediate | Verify success, launch next batch |
### Adaptive Polling
Adjust frequency based on:
- **More frequent**: High-conflict swarms, many parallel agents
- **Less frequent**: Simple tasks, sequential execution
- **Immediate**: After any agent reports an issue
## Status Checker Agent
The status-checker agent is designed for fast, lightweight execution:
```yaml
model: haiku # Fast and cheap
tools: Read, Glob, Grep # Read-only, no edits
```
### What It Checks
1. **Agent Status**
- Last update timestamp
- Current task progress
- Reported errors or warnings
2. **File Claims**
- Ownership conflicts
- Stale claims from completed agents
- Unclaimed files being edited
3. **Overall Health**
- Completion percentage
- Estimated time remaining
- Bottlenecks and blockers
### Output Format
```json
{
"timestamp": "2025-01-15T10:35:00Z",
"overall_health": "warning",
"completion_percentage": 65,
"issues": {
"conflicts": [{
"file": "src/api/handler.ts",
"agents": ["agent-1", "agent-3"],
"severity": "critical"
}],
"stuck_agents": [{
"id": "agent-2",
"last_update": "2025-01-15T10:30:00Z",
"duration_seconds": 300
}]
},
"recommendations": [
{"action": "pause", "target": "agent-3", "reason": "resolve conflict"}
]
}
```
## Responding to Status Reports
### Healthy Status
```json
{"overall_health": "healthy"}
```
- Continue execution
- Schedule next poll at normal interval
### Warning Status
```json
{"overall_health": "warning", "issues": {...}}
```
- Review specific issues
- Take corrective action if needed
- Increase polling frequency temporarily
### Critical Status
```json
{"overall_health": "critical", "issues": {...}}
```
- Pause affected agents immediately
- Resolve conflicts before continuing
- Consider notifying user for input
## Implementation Example
```markdown
## During Implementation Phase
1. Launch batch 1 agents (agent-1, agent-2)
2. Wait 30 seconds
3. Launch status-checker agent
4. If healthy: continue, schedule next check in 45 seconds
5. If issues:
- Conflicts: Pause later agent, let first complete
- Stuck: Check logs, consider timeout or reassignment
- Failed: Report to user, decide on retry/skip
6. Repeat until all agents complete
```
## Polling vs Event-Driven
| Approach | Pros | Cons |
|----------|------|------|
| Polling | Simple, no agent modification needed | Some latency in detection |
| Events | Immediate detection | Requires agent cooperation |
This plugin uses polling because:
- Works with any agent without modification
- Orchestrator maintains full control
- Simpler implementation
- Haiku model makes polling cheap
## Best Practices
1. **Use haiku for status checks** - Fast and cheap
2. **Don't poll too frequently** - 30 seconds minimum
3. **Act on issues promptly** - Don't just log and continue
4. **Track polling history** - Useful for debugging
5. **Combine with file claims** - Polling detects, claims prevent

View File

@@ -1,100 +0,0 @@
#!/usr/bin/env bash
#
# Comments on a GitHub issue with a list of potential duplicates.
# Usage: ./comment-on-duplicates.sh --base-issue 123 --potential-duplicates 456 789 101
#
set -euo pipefail
REPO="anthropics/claude-code"
BASE_ISSUE=""
DUPLICATES=()
# Parse arguments
while [[ $# -gt 0 ]]; do
case $1 in
--base-issue)
BASE_ISSUE="$2"
shift 2
;;
--potential-duplicates)
shift
while [[ $# -gt 0 && ! "$1" =~ ^-- ]]; do
DUPLICATES+=("$1")
shift
done
;;
*)
echo "Unknown option: $1" >&2
exit 1
;;
esac
done
# Validate base issue
if [[ -z "$BASE_ISSUE" ]]; then
echo "Error: --base-issue is required" >&2
exit 1
fi
if ! [[ "$BASE_ISSUE" =~ ^[0-9]+$ ]]; then
echo "Error: --base-issue must be a number, got: $BASE_ISSUE" >&2
exit 1
fi
# Validate duplicates
if [[ ${#DUPLICATES[@]} -eq 0 ]]; then
echo "Error: --potential-duplicates requires at least one issue number" >&2
exit 1
fi
if [[ ${#DUPLICATES[@]} -gt 3 ]]; then
echo "Error: --potential-duplicates accepts at most 3 issues" >&2
exit 1
fi
for dup in "${DUPLICATES[@]}"; do
if ! [[ "$dup" =~ ^[0-9]+$ ]]; then
echo "Error: duplicate issue must be a number, got: $dup" >&2
exit 1
fi
done
# Validate that base issue exists
if ! gh issue view "$BASE_ISSUE" --repo "$REPO" &>/dev/null; then
echo "Error: issue #$BASE_ISSUE does not exist in $REPO" >&2
exit 1
fi
# Validate that all duplicate issues exist
for dup in "${DUPLICATES[@]}"; do
if ! gh issue view "$dup" --repo "$REPO" &>/dev/null; then
echo "Error: issue #$dup does not exist in $REPO" >&2
exit 1
fi
done
# Build comment body
COUNT=${#DUPLICATES[@]}
if [[ $COUNT -eq 1 ]]; then
HEADER="Found 1 possible duplicate issue:"
else
HEADER="Found $COUNT possible duplicate issues:"
fi
BODY="$HEADER"$'\n\n'
INDEX=1
for dup in "${DUPLICATES[@]}"; do
BODY+="$INDEX. https://github.com/$REPO/issues/$dup"$'\n'
((INDEX++))
done
BODY+=$'\n'"This issue will be automatically closed as a duplicate in 3 days."$'\n\n'
BODY+="- If your issue is a duplicate, please close it and 👍 the existing issue instead"$'\n'
BODY+="- To prevent auto-closure, add a comment or 👎 this comment"$'\n\n'
BODY+="🤖 Generated with [Claude Code](https://claude.ai/code)"
# Post the comment
gh issue comment "$BASE_ISSUE" --repo "$REPO" --body "$BODY"
echo "Posted duplicate comment on issue #$BASE_ISSUE"