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

.claude-plugin/marketplace.json

@@ -15,14 +15,25 @@
       "category": "development"
     },
     {
-      "name": "pr-review-toolkit",
-      "description": "Comprehensive PR review agents specializing in comments, tests, error handling, type design, code quality, and code simplification",
+      "name": "claude-opus-4-5-migration",
+      "description": "Migrate your code and prompts from Sonnet 4.x and Opus 4.1 to Opus 4.5.",
       "version": "1.0.0",
       "author": {
-        "name": "Anthropic",
-        "email": "support@anthropic.com"
+        "name": "William Hu",
+        "email": "whu@anthropic.com"
       },
-      "source": "./plugins/pr-review-toolkit",
+      "source": "./plugins/claude-opus-4-5-migration",
+      "category": "development"
+    },
+    {
+      "name": "code-review",
+      "description": "Automated code review for pull requests using multiple specialized agents with confidence-based scoring to filter false positives",
+      "version": "1.0.0",
+      "author": {
+        "name": "Boris Cherny",
+        "email": "boris@anthropic.com"
+      },
+      "source": "./plugins/code-review",
       "category": "productivity"
     },
     {
@@ -36,39 +47,6 @@
       "source": "./plugins/commit-commands",
       "category": "productivity"
     },
-    {
-      "name": "feature-dev",
-      "description": "Comprehensive feature development workflow with specialized agents for codebase exploration, architecture design, and quality review",
-      "version": "1.0.0",
-      "author": {
-        "name": "Siddharth Bidasaria",
-        "email": "sbidasaria@anthropic.com"
-      },
-      "source": "./plugins/feature-dev",
-      "category": "development"
-    },
-    {
-      "name": "security-guidance",
-      "description": "Security reminder hook that warns about potential security issues when editing files, including command injection, XSS, and unsafe code patterns",
-      "version": "1.0.0",
-      "author": {
-        "name": "David Dworken",
-        "email": "dworken@anthropic.com"
-      },
-      "source": "./plugins/security-guidance",
-      "category": "security"
-    },
-    {
-      "name": "code-review",
-      "description": "Automated code review for pull requests using multiple specialized agents with confidence-based scoring to filter false positives",
-      "version": "1.0.0",
-      "author": {
-        "name": "Boris Cherny",
-        "email": "boris@anthropic.com"
-      },
-      "source": "./plugins/code-review",
-      "category": "productivity"
-    },
     {
       "name": "explanatory-output-style",
       "description": "Adds educational insights about implementation choices and codebase patterns (mimics the deprecated Explanatory output style)",
@@ -81,15 +59,15 @@
       "category": "learning"
     },
     {
-      "name": "learning-output-style",
-      "description": "Interactive learning mode that requests meaningful code contributions at decision points (mimics the unshipped Learning output style)",
+      "name": "feature-dev",
+      "description": "Comprehensive feature development workflow with specialized agents for codebase exploration, architecture design, and quality review",
       "version": "1.0.0",
       "author": {
-        "name": "Boris Cherny",
-        "email": "boris@anthropic.com"
+        "name": "Siddharth Bidasaria",
+        "email": "sbidasaria@anthropic.com"
       },
-      "source": "./plugins/learning-output-style",
-      "category": "learning"
+      "source": "./plugins/feature-dev",
+      "category": "development"
     },
     {
       "name": "frontend-design",
@@ -102,17 +80,6 @@
       "source": "./plugins/frontend-design",
       "category": "development"
     },
-    {
-      "name": "ralph-wiggum",
-      "description": "Interactive self-referential AI loops for iterative development. Claude works on the same task repeatedly, seeing its previous work, until completion.",
-      "version": "1.0.0",
-      "author": {
-        "name": "Daisy Hollman",
-        "email": "daisy@anthropic.com"
-      },
-      "source": "./plugins/ralph-wiggum",
-      "category": "development"
-    },
     {
       "name": "hookify",
       "description": "Easily create custom hooks to prevent unwanted behaviors by analyzing conversation patterns or from explicit instructions. Define rules via simple markdown files.",
@@ -124,6 +91,17 @@
       "source": "./plugins/hookify",
       "category": "productivity"
     },
+    {
+      "name": "learning-output-style",
+      "description": "Interactive learning mode that requests meaningful code contributions at decision points (mimics the unshipped Learning output style)",
+      "version": "1.0.0",
+      "author": {
+        "name": "Boris Cherny",
+        "email": "boris@anthropic.com"
+      },
+      "source": "./plugins/learning-output-style",
+      "category": "learning"
+    },
     {
       "name": "plugin-dev",
       "description": "Comprehensive toolkit for developing Claude Code plugins. Includes 7 expert skills covering hooks, MCP integration, commands, agents, and best practices. AI-assisted plugin creation and validation.",
@@ -134,6 +112,39 @@
       },
       "source": "./plugins/plugin-dev",
       "category": "development"
+    },
+    {
+      "name": "pr-review-toolkit",
+      "description": "Comprehensive PR review agents specializing in comments, tests, error handling, type design, code quality, and code simplification",
+      "version": "1.0.0",
+      "author": {
+        "name": "Anthropic",
+        "email": "support@anthropic.com"
+      },
+      "source": "./plugins/pr-review-toolkit",
+      "category": "productivity"
+    },
+    {
+      "name": "ralph-wiggum",
+      "description": "Interactive self-referential AI loops for iterative development. Claude works on the same task repeatedly, seeing its previous work, until completion.",
+      "version": "1.0.0",
+      "author": {
+        "name": "Daisy Hollman",
+        "email": "daisy@anthropic.com"
+      },
+      "source": "./plugins/ralph-wiggum",
+      "category": "development"
+    },
+    {
+      "name": "security-guidance",
+      "description": "Security reminder hook that warns about potential security issues when editing files, including command injection, XSS, and unsafe code patterns",
+      "version": "1.0.0",
+      "author": {
+        "name": "David Dworken",
+        "email": "dworken@anthropic.com"
+      },
+      "source": "./plugins/security-guidance",
+      "category": "security"
     }
   ]
 }

.github/workflows/remove-autoclose-label.yml

@@ -0,0 +1,42 @@
+name: "Remove Autoclose Label on Activity"
+
+on:
+  issue_comment:
+    types: [created]
+
+permissions:
+  issues: write
+
+jobs:
+  remove-autoclose:
+    # Only run if the issue has the autoclose label
+    if: |
+      github.event.issue.state == 'open' &&
+      contains(github.event.issue.labels.*.name, 'autoclose') &&
+      github.event.comment.user.login != 'github-actions[bot]'
+    runs-on: ubuntu-latest
+    steps:
+      - name: Remove autoclose label
+        uses: actions/github-script@v7
+        with:
+          script: |
+            console.log(`Removing autoclose label from issue #${context.issue.number} due to new comment from ${context.payload.comment.user.login}`);
+            
+            try {
+              // Remove the autoclose label
+              await github.rest.issues.removeLabel({
+                owner: context.repo.owner,
+                repo: context.repo.repo,
+                issue_number: context.issue.number,
+                name: 'autoclose'
+              });
+              
+              console.log(`Successfully removed autoclose label from issue #${context.issue.number}`);
+            } catch (error) {
+              // If the label was already removed or doesn't exist, that's fine
+              if (error.status === 404) {
+                console.log(`Autoclose label was already removed from issue #${context.issue.number}`);
+              } else {
+                throw error;
+              }
+            }

.github/workflows/stale-issue-manager.yml

@@ -0,0 +1,157 @@
+name: "Manage Stale Issues"
+
+on:
+  schedule:
+    # 2am Pacific = 9am UTC (10am UTC during DST)
+    - cron: "0 10 * * *"
+  workflow_dispatch:
+
+permissions:
+  issues: write
+
+concurrency:
+  group: stale-issue-manager
+
+jobs:
+  manage-stale-issues:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Manage stale issues
+        uses: actions/github-script@v7
+        with:
+          script: |
+            const oneMonthAgo = new Date();
+            oneMonthAgo.setDate(oneMonthAgo.getDate() - 30);
+
+            const twoMonthsAgo = new Date();
+            twoMonthsAgo.setDate(twoMonthsAgo.getDate() - 60);
+
+            const warningComment = `This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.`;
+
+            const closingComment = `This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.`;
+
+            let page = 1;
+            let hasMore = true;
+            let totalWarned = 0;
+            let totalClosed = 0;
+            let totalLabeled = 0;
+
+            while (hasMore) {
+              // Get open issues sorted by last updated (oldest first)
+              const { data: issues } = await github.rest.issues.listForRepo({
+                owner: context.repo.owner,
+                repo: context.repo.repo,
+                state: 'open',
+                sort: 'updated',
+                direction: 'asc',
+                per_page: 100,
+                page: page
+              });
+              
+              if (issues.length === 0) {
+                hasMore = false;
+                break;
+              }
+              
+              for (const issue of issues) {
+                // Skip if already locked
+                if (issue.locked) continue;
+                
+                // Skip pull requests
+                if (issue.pull_request) continue;
+                
+                // Check if updated more recently than 30 days ago
+                const updatedAt = new Date(issue.updated_at);
+                if (updatedAt > oneMonthAgo) {
+                  // Since issues are sorted by updated_at ascending, 
+                  // once we hit a recent issue, all remaining will be recent too
+                  hasMore = false;
+                  break;
+                }
+                
+                // Check if issue has autoclose label
+                const hasAutocloseLabel = issue.labels.some(label => 
+                  typeof label === 'object' && label.name === 'autoclose'
+                );
+                
+                try {
+                  // Get comments to check for existing warning
+                  const { data: comments } = await github.rest.issues.listComments({
+                    owner: context.repo.owner,
+                    repo: context.repo.repo,
+                    issue_number: issue.number,
+                    per_page: 100
+                  });
+                  
+                  // Find the last comment from github-actions bot
+                  const botComments = comments.filter(comment => 
+                    comment.user && comment.user.login === 'github-actions[bot]' &&
+                    comment.body && comment.body.includes('inactive for 30 days')
+                  );
+                  
+                  const lastBotComment = botComments[botComments.length - 1];
+                  
+                  if (lastBotComment) {
+                    // Check if the bot comment is older than 30 days (total 60 days of inactivity)
+                    const botCommentDate = new Date(lastBotComment.created_at);
+                    if (botCommentDate < oneMonthAgo) {
+                      // Close the issue - it's been stale for 60+ days
+                      console.log(`Closing issue #${issue.number} (stale for 60+ days): ${issue.title}`);
+                      
+                      // Post closing comment
+                      await github.rest.issues.createComment({
+                        owner: context.repo.owner,
+                        repo: context.repo.repo,
+                        issue_number: issue.number,
+                        body: closingComment
+                      });
+                      
+                      // Close the issue
+                      await github.rest.issues.update({
+                        owner: context.repo.owner,
+                        repo: context.repo.repo,
+                        issue_number: issue.number,
+                        state: 'closed',
+                        state_reason: 'not_planned'
+                      });
+                      
+                      totalClosed++;
+                    }
+                    // If bot comment exists but is recent, issue already has warning
+                  } else if (updatedAt < oneMonthAgo) {
+                    // No bot warning yet, issue is 30+ days old
+                    console.log(`Warning issue #${issue.number} (stale for 30+ days): ${issue.title}`);
+                    
+                    // Post warning comment
+                    await github.rest.issues.createComment({
+                      owner: context.repo.owner,
+                      repo: context.repo.repo,
+                      issue_number: issue.number,
+                      body: warningComment
+                    });
+                    
+                    totalWarned++;
+                    
+                    // Add autoclose label if not present
+                    if (!hasAutocloseLabel) {
+                      await github.rest.issues.addLabels({
+                        owner: context.repo.owner,
+                        repo: context.repo.repo,
+                        issue_number: issue.number,
+                        labels: ['autoclose']
+                      });
+                      totalLabeled++;
+                    }
+                  }
+                } catch (error) {
+                  console.error(`Failed to process issue #${issue.number}: ${error.message}`);
+                }
+              }
+              
+              page++;
+            }
+
+            console.log(`Summary:`);
+            console.log(`- Issues warned (30 days stale): ${totalWarned}`);
+            console.log(`- Issues labeled with autoclose: ${totalLabeled}`);
+            console.log(`- Issues closed (60 days stale): ${totalClosed}`);

CHANGELOG.md

@@ -1,8 +1,149 @@
 # Changelog
 
+## 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
+- Show reason why autoupdater is disabled in `/doctor`
+- Fixed false "Another process is currently updating Claude" error when running `claude update` while another instance is already on the latest version
+- Fixed MCP servers from `.mcp.json` being stuck in pending state when running in non-interactive mode (`-p` flag or piped input)
+- Fixed scroll position resetting after deleting a permission rule in `/permissions`
+- Fixed word deletion (opt+delete) and word navigation (opt+arrow) not working correctly with non-Latin text such as Cyrillic, Greek, Arabic, Hebrew, Thai, and Chinese
+- Fixed `claude install --force` not bypassing stale lock files
+- Fixed consecutive @~/ file references in CLAUDE.md being incorrectly parsed due to markdown strikethrough interference
+- Windows: Fixed plugin MCP servers failing due to colons in log directory paths
+
+## 2.0.65
+
+- Added ability to switch models while writing a prompt using alt+p (linux, windows), option+p (macos).
+- Added context window information to status line input
+- Added `fileSuggestion` setting for custom `@` file search commands
+- Added `CLAUDE_CODE_SHELL` environment variable to override automatic shell detection (useful when login shell differs from actual working shell)
+- Fixed prompt not being saved to history when aborting a query with Escape
+- Fixed Read tool image handling to identify format from bytes instead of file extension
+
+## 2.0.64
+
+- Made auto-compacting instant
+- Agents and bash commands can run asynchronously and send messages to wake up the main agent
+- /stats now provides users with interesting CC stats, such as favorite model, usage graph, usage streak
+- Added named session support: use `/rename` to name sessions, `/resume <name>` in REPL or `claude --resume <name>` from the terminal to resume them
+- Added support for .claude/rules/`.  See https://code.claude.com/docs/en/memory for details.
+- Added image dimension metadata when images are resized, enabling accurate coordinate mappings for large images
+- Fixed auto-loading .env when using native installer
+- Fixed `--system-prompt` being ignored when using `--continue` or `--resume` flags
+- Improved `/resume` screen with grouped forked sessions and keyboard shortcuts for preview (P) and rename (R)
+- VSCode: Added copy-to-clipboard button on code blocks and bash tool inputs
+- VSCode: Fixed extension not working on Windows ARM64 by falling back to x64 binary via emulation
+- Bedrock: Improve efficiency of token counting
+- Bedrock: Add support for `aws login` AWS Management Console credentials
+- Unshipped AgentOutputTool and BashOutputTool, in favor of a new unified TaskOutputTool
+
+## 2.0.62
+
+- Added "(Recommended)" indicator for multiple-choice questions, with the recommended option moved to the top of the list
+- Added `attribution` setting to customize commit and PR bylines (deprecates `includeCoAuthoredBy`)
+- Fixed duplicate slash commands appearing when ~/.claude is symlinked to a project directory
+- Fixed slash command selection not working when multiple commands share the same name
+- Fixed an issue where skill files inside symlinked skill directories could become circular symlinks
+- Fixed running versions getting removed because lock file incorrectly going stale
+- Fixed IDE diff tab not closing when rejecting file changes
+
+## 2.0.61
+
+- Reverted VSCode support for multiple terminal clients due to responsiveness issues.
+
+## 2.0.60
+
+- Added background agent support. Agents run in the background while you work
+- Added --disable-slash-commands CLI flag to disable all slash commands
+- Added model name to "Co-Authored-By" commit messages
+- Enabled "/mcp enable [server-name]" or "/mcp disable [server-name]" to quickly toggle all servers
+- Updated Fetch to skip summarization for pre-approved websites
+- VSCode: Added support for multiple terminal clients connecting to the IDE server simultaneously
+
+## 2.0.59
+
+- Added --agent CLI flag to override the agent setting for the current session
+- Added `agent` setting to configure main thread with a specific agent's system prompt, tool restrictions, and model
+- VS Code: Fixed .claude.json config file being read from incorrect location
+
+## 2.0.58
+
+- Pro users now have access to Opus 4.5 as part of their subscription!
+- Fixed timer duration showing "11m 60s" instead of "12m 0s"
+- Windows: Managed settings now prefer `C:\Program Files\ClaudeCode` if it exists. Support for `C:\ProgramData\ClaudeCode` will be removed in a future version.
+
+## 2.0.57
+
+- Added feedback input when rejecting plans, allowing users to tell Claude what to change
+- VSCode: Added streaming message support for real-time response display
+
+## 2.0.56
+
+- Added setting to enable/disable terminal progress bar (OSC 9;4)
+- VSCode Extension: Added support for VS Code's secondary sidebar (VS Code 1.97+), allowing Claude Code to be displayed in the right sidebar while keeping the file explorer on the left. Requires setting sidebar as Preferred Location in the config.
+
+## 2.0.55
+
+- Fixed proxy DNS resolution being forced on by default. Now opt-in via `CLAUDE_CODE_PROXY_RESOLVES_HOSTS=true` environment variable
+- Fixed keyboard navigation becoming unresponsive when holding down arrow keys in memory location selector
+- Improved AskUserQuestion tool to auto-submit single-select questions on the last question, eliminating the extra review screen for simple question flows
+- Improved fuzzy matching for `@` file suggestions with faster, more accurate results
+
+## 2.0.54
+
+- Hooks: Enable PermissionRequest hooks to process 'always allow' suggestions and apply permission updates
+- Fix issue with excessive iTerm notifications
+
+## 2.0.52
+
+- Fixed duplicate message display when starting Claude with a command line argument
+- Fixed `/usage` command progress bars to fill up as usage increases (instead of showing remaining percentage)
+- Fixed image pasting not working on Linux systems running Wayland (now falls back to wl-paste when xclip is unavailable)
+- Permit some uses of `$!` in bash commands
+
+## 2.0.51
+
+- Added Opus 4.5! https://www.anthropic.com/news/claude-opus-4-5
+- Introducing Claude Code for Desktop: https://claude.com/download
+- To give you room to try out our new model, we've updated usage limits for Claude Code users. See the Claude Opus 4.5 blog for full details
+- Pro users can now purchase extra usage for access to Opus 4.5 in Claude Code
+- Plan Mode now builds more precise plans and executes more thoroughly
+- Usage limit notifications now easier to understand
+- Switched `/usage` back to "% used"
+- Fixed handling of thinking errors
+- Fixed performance regression
+
+## 2.0.50
+
+- Fixed bug preventing calling MCP tools that have nested references in their input schemas
+- Silenced a noisy but harmless error during upgrades
+- Improved ultrathink text display
+- Improved clarity of 5-hour session limit warning message
+
+## 2.0.49
+
+- Added readline-style ctrl-y for pasting deleted text
+- Improved clarity of usage limit warning message
+- Fixed handling of subagent permissions
+
+## 2.0.47
+
+- Improved error messages and validation for `claude --teleport`
+- Improved error handling in `/usage`
+- Fixed race condition with history entry not getting logged at exit
+- Fixed Vertex AI configuration not being applied from `settings.json`
+
+## 2.0.46
+
+- Fixed image files being reported with incorrect media type when format cannot be detected from metadata
+
 ## 2.0.45
 
-- Add support for Azure AI Foundry! See https://code.claude.com/docs/en/azure-ai-foundry
+- Added support for Microsoft Foundry! See https://code.claude.com/docs/en/azure-ai-foundry
 - Added `PermissionRequest` hook to automatically approve or deny tool permission requests with custom logic
 - Send background tasks to Claude Code on the web by starting a message with `&`
 
@@ -54,7 +195,6 @@
 - Improved VS Code extension to respect `chat.fontSize` and `chat.fontFamily` settings throughout the entire UI, and apply font changes immediately without requiring reload
 - Added `CLAUDE_CODE_EXIT_AFTER_STOP_DELAY` environment variable to automatically exit SDK mode after a specified idle duration, useful for automated workflows and scripts
 - Migrated `ignorePatterns` from project config to deny permissions in the localSettings.
-- Fixed messages returning null `stop_reason` and `stop_sequence` values
 - Fixed menu navigation getting stuck on items with empty string or other falsy values (e.g., in the `/hooks` menu)
 
 ## 2.0.34
@@ -126,7 +266,7 @@
 
 ## 2.0.25
 
-- Removed legacy SDK entrypoint. Please migrate to @anthropic-ai/claude-agent-sdk for future SDK updates: https://docs.claude.com/en/docs/claude-code/sdk/migration-guide
+- Removed legacy SDK entrypoint. Please migrate to @anthropic-ai/claude-agent-sdk for future SDK updates: https://platform.claude.com/docs/en/agent-sdk/migration-guide
 
 ## 2.0.24
 
@@ -194,7 +334,7 @@
 - Repository-level plugin configuration via `extraKnownMarketplaces` for team collaboration
 - `/plugin validate` command for validating plugin structure and configuration
 - Plugin announcement blog post at https://www.anthropic.com/news/claude-code-plugins
-- Plugin documentation available at https://docs.claude.com/en/docs/claude-code/plugins
+- Plugin documentation available at https://code.claude.com/docs/en/plugins
 - Comprehensive error messages and diagnostics via `/doctor` command
 - Avoid flickering in `/model` selector
 - Improvements to `/help`
@@ -272,7 +412,7 @@
 - Bash permission rules now support output redirections when matching (e.g., `Bash(python:*)` matches `python script.py > output.txt`)
 - Fixed thinking mode triggering on negation phrases like "don't think"
 - Fixed rendering performance degradation during token streaming
-- Added SlashCommand tool, which enables Claude to invoke your slash commands. https://docs.claude.com/en/docs/claude-code/slash-commands#SlashCommand-tool
+- Added SlashCommand tool, which enables Claude to invoke your slash commands. https://code.claude.com/docs/en/slash-commands#SlashCommand-tool
 - Enhanced BashTool environment snapshot logging
 - Fixed a bug where resuming a conversation in headless mode would sometimes enable thinking unnecessarily
 - Migrated --debug logging to a file, to enable easy tailing & filtering
@@ -402,7 +542,7 @@
 
 ## 1.0.81
 
-- Released output styles, including new built-in educational output styles "Explanatory" and "Learning". Docs: https://docs.claude.com/en/docs/claude-code/output-styles
+- Released output styles, including new built-in educational output styles "Explanatory" and "Learning". Docs: https://code.claude.com/docs/en/output-styles
 - Agents: Fix custom agent loading when agent files are unparsable
 
 ## 1.0.80
@@ -607,7 +747,7 @@
 
 ## 1.0.38
 
-- Released hooks. Special thanks to community input in https://github.com/anthropics/claude-code/issues/712. Docs: https://docs.claude.com/en/docs/claude-code/hooks
+- Released hooks. Special thanks to community input in https://github.com/anthropics/claude-code/issues/712. Docs: https://code.claude.com/docs/en/hooks
 
 ## 1.0.37
 

plugins/README.md

@@ -10,50 +10,21 @@ Learn more in the [official plugins documentation](https://docs.claude.com/en/do
 
 ## Plugins in This Directory
 
-### [agent-sdk-dev](./agent-sdk-dev/)
-
-**Claude Agent SDK Development Plugin**
-
-Streamlines the development of Claude Agent SDK applications with scaffolding commands and verification agents.
-
-- **Command**: `/new-sdk-app` - Interactive setup for new Agent SDK projects
-- **Agents**: `agent-sdk-verifier-py` and `agent-sdk-verifier-ts` - Validate SDK applications against best practices
-- **Use case**: Creating and verifying Claude Agent SDK applications in Python or TypeScript
-
-### [commit-commands](./commit-commands/)
-
-**Git Workflow Automation Plugin**
-
-Simplifies common git operations with streamlined commands for committing, pushing, and creating pull requests.
-
-- **Commands**:
-  - `/commit` - Create a git commit with appropriate message
-  - `/commit-push-pr` - Commit, push, and create a PR in one command
-  - `/clean_gone` - Clean up stale local branches marked as [gone]
-- **Use case**: Faster git workflows with less context switching
-
-### [code-review](./code-review/)
-
-**Automated Pull Request Code Review Plugin**
-
-Provides automated code review for pull requests using multiple specialized agents with confidence-based scoring to filter false positives.
-
-- **Command**:
-  - `/code-review` - Automated PR review workflow
-- **Use case**: Automated code review on pull requests with high-confidence issue detection (threshold ≥80)
-
-### [feature-dev](./feature-dev/)
-
-**Comprehensive Feature Development Workflow Plugin**
-
-Provides a structured 7-phase approach to feature development with specialized agents for exploration, architecture, and review.
-
-- **Command**: `/feature-dev` - Guided feature development workflow
-- **Agents**:
-  - `code-explorer` - Deeply analyzes existing codebase features
-  - `code-architect` - Designs feature architectures and implementation blueprints
-  - `code-reviewer` - Reviews code for bugs, quality issues, and project conventions
-- **Use case**: Building new features with systematic codebase understanding and quality assurance
+| Name | Description | Contents |
+|------|-------------|----------|
+| [agent-sdk-dev](./agent-sdk-dev/) | Development kit for working with the Claude Agent SDK | **Command:** `/new-sdk-app` - Interactive setup for new Agent SDK projects<br>**Agents:** `agent-sdk-verifier-py`, `agent-sdk-verifier-ts` - Validate SDK applications against best practices |
+| [claude-opus-4-5-migration](./claude-opus-4-5-migration/) | Migrate code and prompts from Sonnet 4.x and Opus 4.1 to Opus 4.5 | **Skill:** `claude-opus-4-5-migration` - Automated migration of model strings, beta headers, and prompt adjustments |
+| [code-review](./code-review/) | Automated PR code review using multiple specialized agents with confidence-based scoring to filter false positives | **Command:** `/code-review` - Automated PR review workflow<br>**Agents:** 5 parallel Sonnet agents for CLAUDE.md compliance, bug detection, historical context, PR history, and code comments |
+| [commit-commands](./commit-commands/) | Git workflow automation for committing, pushing, and creating pull requests | **Commands:** `/commit`, `/commit-push-pr`, `/clean_gone` - Streamlined git operations |
+| [explanatory-output-style](./explanatory-output-style/) | Adds educational insights about implementation choices and codebase patterns (mimics the deprecated Explanatory output style) | **Hook:** SessionStart - Injects educational context at the start of each session |
+| [feature-dev](./feature-dev/) | Comprehensive feature development workflow with a structured 7-phase approach | **Command:** `/feature-dev` - Guided feature development workflow<br>**Agents:** `code-explorer`, `code-architect`, `code-reviewer` - For codebase analysis, architecture design, and quality review |
+| [frontend-design](./frontend-design/) | Create distinctive, production-grade frontend interfaces that avoid generic AI aesthetics | **Skill:** `frontend-design` - Auto-invoked for frontend work, providing guidance on bold design choices, typography, animations, and visual details |
+| [hookify](./hookify/) | Easily create custom hooks to prevent unwanted behaviors by analyzing conversation patterns or explicit instructions | **Commands:** `/hookify`, `/hookify:list`, `/hookify:configure`, `/hookify:help`<br>**Agent:** `conversation-analyzer` - Analyzes conversations for problematic behaviors<br>**Skill:** `writing-rules` - Guidance on hookify rule syntax |
+| [learning-output-style](./learning-output-style/) | Interactive learning mode that requests meaningful code contributions at decision points (mimics the unshipped Learning output style) | **Hook:** SessionStart - Encourages users to write meaningful code (5-10 lines) at decision points while receiving educational insights |
+| [plugin-dev](./plugin-dev/) | Comprehensive toolkit for developing Claude Code plugins with 7 expert skills and AI-assisted creation | **Command:** `/plugin-dev:create-plugin` - 8-phase guided workflow for building plugins<br>**Agents:** `agent-creator`, `plugin-validator`, `skill-reviewer`<br>**Skills:** Hook development, MCP integration, plugin structure, settings, commands, agents, and skill development |
+| [pr-review-toolkit](./pr-review-toolkit/) | Comprehensive PR review agents specializing in comments, tests, error handling, type design, code quality, and code simplification | **Command:** `/pr-review-toolkit:review-pr` - Run with optional review aspects (comments, tests, errors, types, code, simplify, all)<br>**Agents:** `comment-analyzer`, `pr-test-analyzer`, `silent-failure-hunter`, `type-design-analyzer`, `code-reviewer`, `code-simplifier` |
+| [ralph-wiggum](./ralph-wiggum/) | Interactive self-referential AI loops for iterative development. Claude works on the same task repeatedly until completion | **Commands:** `/ralph-loop`, `/cancel-ralph` - Start/stop autonomous iteration loops<br>**Hook:** Stop - Intercepts exit attempts to continue iteration |
+| [security-guidance](./security-guidance/) | Security reminder hook that warns about potential security issues when editing files | **Hook:** PreToolUse - Monitors 9 security patterns including command injection, XSS, eval usage, dangerous HTML, pickle deserialization, and os.system calls |
 
 ## Installation
 
@@ -83,6 +54,9 @@ plugin-name/
 │   └── plugin.json          # Plugin metadata
 ├── commands/                # Slash commands (optional)
 ├── agents/                  # Specialized agents (optional)
+├── skills/                  # Agent Skills (optional)
+├── hooks/                   # Event handlers (optional)
+├── .mcp.json                # External tool configuration (optional)
 └── README.md                # Plugin documentation
 ```
 

plugins/claude-opus-4-5-migration/.claude-plugin/plugin.json

@@ -0,0 +1,9 @@
+{
+  "name": "claude-opus-4-5-migration",
+  "version": "1.0.0",
+  "description": "Migrate your code and prompts from Sonnet 4.x and Opus 4.1 to Opus 4.5.",
+  "author": {
+    "name": "William Hu",
+    "email": "whu@anthropic.com"
+  }
+}

plugins/claude-opus-4-5-migration/README.md

@@ -0,0 +1,21 @@
+# Claude Opus 4.5 Migration Plugin
+
+Migrate your code and prompts from Sonnet 4.x and Opus 4.1 to Opus 4.5.
+
+## Overview
+
+This skill updates your code and prompts to be compatible with Opus 4.5. It automates the migration process, handling model strings, beta headers, and other configuration details. If you run into any issues with Opus 4.5 after migration, you can continue using this skill to adjust your prompts.
+
+## Usage
+
+```
+"Migrate my codebase to Opus 4.5"
+```
+
+## Learn More
+
+Refer to our [prompting guide](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-4-best-practices) for best practices on prompting Claude models.
+
+## Authors
+
+William Hu (whu@anthropic.com)

plugins/claude-opus-4-5-migration/skills/claude-opus-4-5-migration/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: claude-opus-4-5-migration
+description: Migrate prompts and code from Claude Sonnet 4.0, Sonnet 4.5, or Opus 4.1 to Opus 4.5. Use when the user wants to update their codebase, prompts, or API calls to use Opus 4.5. Handles model string updates and prompt adjustments for known Opus 4.5 behavioral differences. Does NOT migrate Haiku 4.5.
+---
+
+# Opus 4.5 Migration Guide
+
+One-shot migration from Sonnet 4.0, Sonnet 4.5, or Opus 4.1 to Opus 4.5.
+
+## Migration Workflow
+
+1. Search codebase for model strings and API calls
+2. Update model strings to Opus 4.5 (see platform-specific strings below)
+3. Remove unsupported beta headers
+4. Add effort parameter set to `"high"` (see `references/effort.md`)
+5. Summarize all changes made
+6. Tell the user: "If you encounter any issues with Opus 4.5, let me know and I can help adjust your prompts."
+
+## Model String Updates
+
+Identify which platform the codebase uses, then replace model strings accordingly.
+
+### Unsupported Beta Headers
+
+Remove the `context-1m-2025-08-07` beta header if present—it is not yet supported with Opus 4.5. Leave a comment noting this:
+
+```python
+# Note: 1M context beta (context-1m-2025-08-07) not yet supported with Opus 4.5
+```
+
+### Target Model Strings (Opus 4.5)
+
+| Platform | Opus 4.5 Model String |
+|----------|----------------------|
+| Anthropic API (1P) | `claude-opus-4-5-20251101` |
+| AWS Bedrock | `anthropic.claude-opus-4-5-20251101-v1:0` |
+| Google Vertex AI | `claude-opus-4-5@20251101` |
+| Azure AI Foundry | `claude-opus-4-5-20251101` |
+
+### Source Model Strings to Replace
+
+| Source Model | Anthropic API (1P) | AWS Bedrock | Google Vertex AI |
+|--------------|-------------------|-------------|------------------|
+| Sonnet 4.0 | `claude-sonnet-4-20250514` | `anthropic.claude-sonnet-4-20250514-v1:0` | `claude-sonnet-4@20250514` |
+| Sonnet 4.5 | `claude-sonnet-4-5-20250929` | `anthropic.claude-sonnet-4-5-20250929-v1:0` | `claude-sonnet-4-5@20250929` |
+| Opus 4.1 | `claude-opus-4-1-20250422` | `anthropic.claude-opus-4-1-20250422-v1:0` | `claude-opus-4-1@20250422` |
+
+**Do NOT migrate**: Any Haiku models (e.g., `claude-haiku-4-5-20251001`).
+
+## Prompt Adjustments
+
+Opus 4.5 has known behavioral differences from previous models. **Only apply these fixes if the user explicitly requests them or reports a specific issue.** By default, just update model strings.
+
+**Integration guidelines**: When adding snippets, don't just append them to prompts. Integrate them thoughtfully:
+- Use XML tags (e.g., `<code_guidelines>`, `<tool_usage>`) to organize additions
+- Match the style and structure of the existing prompt
+- Place snippets in logical locations (e.g., coding guidelines near other coding instructions)
+- If the prompt already uses XML tags, add new content within appropriate existing tags or create consistent new ones
+
+### 1. Tool Overtriggering
+
+Opus 4.5 is more responsive to system prompts. Aggressive language that prevented undertriggering on previous models may now cause overtriggering.
+
+**Apply if**: User reports tools being called too frequently or unnecessarily.
+
+**Find and soften**:
+- `CRITICAL:` → remove or soften
+- `You MUST...` → `You should...`
+- `ALWAYS do X` → `Do X`
+- `NEVER skip...` → `Don't skip...`
+- `REQUIRED` → remove or soften
+
+Only apply to tool-triggering instructions. Leave other uses of emphasis alone.
+
+### 2. Over-Engineering Prevention
+
+Opus 4.5 tends to create extra files, add unnecessary abstractions, or build unrequested flexibility.
+
+**Apply if**: User reports unwanted files, excessive abstraction, or unrequested features. Add the snippet from `references/prompt-snippets.md`.
+
+### 3. Code Exploration
+
+Opus 4.5 can be overly conservative about exploring code, proposing solutions without reading files.
+
+**Apply if**: User reports the model proposing fixes without inspecting relevant code. Add the snippet from `references/prompt-snippets.md`.
+
+### 4. Frontend Design
+
+**Apply if**: User requests improved frontend design quality or reports generic-looking outputs.
+
+Add the frontend aesthetics snippet from `references/prompt-snippets.md`.
+
+### 5. Thinking Sensitivity
+
+When extended thinking is not enabled (the default), Opus 4.5 is particularly sensitive to the word "think" and its variants. Extended thinking is enabled only if the API request contains a `thinking` parameter.
+
+**Apply if**: User reports issues related to "thinking" while extended thinking is not enabled (no `thinking` parameter in request).
+
+Replace "think" with alternatives like "consider," "believe," or "evaluate."
+
+## Reference
+
+See `references/prompt-snippets.md` for the full text of each snippet to add.
+
+See `references/effort.md` for configuring the effort parameter (only if user requests it).

plugins/claude-opus-4-5-migration/skills/claude-opus-4-5-migration/references/effort.md

@@ -0,0 +1,70 @@
+# Effort Parameter (Beta)
+
+**Add effort set to `"high"` during migration.** This is the default configuration for best performance with Opus 4.5.
+
+## Overview
+
+Effort controls how eagerly Claude spends tokens. It affects all tokens: thinking, text responses, and function calls.
+
+| Effort | Use Case |
+|--------|----------|
+| `high` | Best performance, deep reasoning (default) |
+| `medium` | Balance of cost/latency vs. performance |
+| `low` | Simple, high-volume queries; significant token savings |
+
+## Implementation
+
+Requires beta flag `effort-2025-11-24` in API calls.
+
+**Python SDK:**
+```python
+response = client.messages.create(
+    model="claude-opus-4-5-20251101",
+    max_tokens=1024,
+    betas=["effort-2025-11-24"],
+    output_config={
+        "effort": "high"  # or "medium" or "low"
+    },
+    messages=[...]
+)
+```
+
+**TypeScript SDK:**
+```typescript
+const response = await client.messages.create({
+  model: "claude-opus-4-5-20251101",
+  max_tokens: 1024,
+  betas: ["effort-2025-11-24"],
+  output_config: {
+    effort: "high"  // or "medium" or "low"
+  },
+  messages: [...]
+});
+```
+
+**Raw API:**
+```json
+{
+  "model": "claude-opus-4-5-20251101",
+  "max_tokens": 1024,
+  "anthropic-beta": "effort-2025-11-24",
+  "output_config": {
+    "effort": "high"
+  },
+  "messages": [...]
+}
+```
+
+## Effort vs. Thinking Budget
+
+Effort is independent of thinking budget:
+
+- High effort + no thinking = more tokens, but no thinking tokens
+- High effort + 32k thinking = more tokens, but thinking capped at 32k
+
+## Recommendations
+
+1. First determine effort level, then set thinking budget
+2. Best performance: high effort + high thinking budget
+3. Cost/latency optimization: medium effort
+4. Simple high-volume queries: low effort

plugins/claude-opus-4-5-migration/skills/claude-opus-4-5-migration/references/prompt-snippets.md

@@ -0,0 +1,106 @@
+# Prompt Snippets for Opus 4.5
+
+Only apply these snippets if the user explicitly requests them or reports a specific issue. By default, the migration should only update model strings.
+
+## 1. Tool Overtriggering
+
+**Problem**: Prompts designed to reduce undertriggering on previous models may cause Opus 4.5 to overtrigger.
+
+**When to add**: User reports tools being called too frequently or unnecessarily.
+
+**Solution**: Replace aggressive language with normal phrasing.
+
+| Before | After |
+|--------|-------|
+| `CRITICAL: You MUST use this tool when...` | `Use this tool when...` |
+| `ALWAYS call the search function before...` | `Call the search function before...` |
+| `You are REQUIRED to...` | `You should...` |
+| `NEVER skip this step` | `Don't skip this step` |
+
+## 2. Over-Engineering Prevention
+
+**Problem**: Opus 4.5 may create extra files, add unnecessary abstractions, or build unrequested flexibility.
+
+**When to add**: User reports unwanted files, excessive abstraction, or unrequested features.
+
+**Snippet to add to system prompt**:
+
+```
+- Avoid over-engineering. Only make changes that are directly requested or clearly necessary. Keep solutions simple and focused.
+- Don't add features, refactor code, or make "improvements" beyond what was asked. A bug fix doesn't need surrounding code cleaned up. A simple feature doesn't need extra configurability.
+- Don't add error handling, fallbacks, or validation for scenarios that can't happen. Trust internal code and framework guarantees. Only validate at system boundaries (user input, external APIs). Don't use backwards-compatibility shims when you can just change the code.
+- Don't create helpers, utilities, or abstractions for one-time operations. Don't design for hypothetical future requirements. The right amount of complexity is the minimum needed for the current task. Reuse existing abstractions where possible and follow the DRY principle.
+```
+
+## 3. Code Exploration
+
+**Problem**: Opus 4.5 may propose solutions without reading code or make assumptions about unread files.
+
+**When to add**: User reports the model proposing fixes without inspecting relevant code.
+
+**Snippet to add to system prompt**:
+
+```
+ALWAYS read and understand relevant files before proposing code edits. Do not speculate about code you have not inspected. If the user references a specific file/path, you MUST open and inspect it before explaining or proposing fixes. Be rigorous and persistent in searching code for key facts. Thoroughly review the style, conventions, and abstractions of the codebase before implementing new features or abstractions.
+```
+
+## 4. Frontend Design Quality
+
+**Problem**: Default frontend outputs may look generic ("AI slop" aesthetic).
+
+**When to add**: User requests improved frontend design quality or reports generic-looking outputs.
+
+**Snippet to add to system prompt**:
+
+```xml
+<frontend_aesthetics>
+You tend to converge toward generic, "on distribution" outputs. In frontend design, this creates what users call the "AI slop" aesthetic. Avoid this: make creative, distinctive frontends that surprise and delight.
+
+Focus on:
+- Typography: Choose fonts that are beautiful, unique, and interesting. Avoid generic fonts like Arial and Inter; opt instead for distinctive choices that elevate the frontend's aesthetics.
+- Color & Theme: Commit to a cohesive aesthetic. Use CSS variables for consistency. Dominant colors with sharp accents outperform timid, evenly-distributed palettes. Draw from IDE themes and cultural aesthetics for inspiration.
+- Motion: Use animations for effects and micro-interactions. Prioritize CSS-only solutions for HTML. Use Motion library for React when available. Focus on high-impact moments: one well-orchestrated page load with staggered reveals (animation-delay) creates more delight than scattered micro-interactions.
+- Backgrounds: Create atmosphere and depth rather than defaulting to solid colors. Layer CSS gradients, use geometric patterns, or add contextual effects that match the overall aesthetic.
+
+Avoid generic AI-generated aesthetics:
+- Overused font families (Inter, Roboto, Arial, system fonts)
+- Clichéd color schemes (particularly purple gradients on white backgrounds)
+- Predictable layouts and component patterns
+- Cookie-cutter design that lacks context-specific character
+
+Interpret creatively and make unexpected choices that feel genuinely designed for the context. Vary between light and dark themes, different fonts, different aesthetics. You still tend to converge on common choices (Space Grotesk, for example) across generations. Avoid this: it is critical that you think outside the box!
+</frontend_aesthetics>
+```
+
+## 5. Thinking Sensitivity
+
+**Problem**: When extended thinking is not enabled (the default), Opus 4.5 is particularly sensitive to the word "think" and its variants.
+
+Extended thinking is not enabled by default. It is only enabled if the API request contains a `thinking` parameter:
+```json
+"thinking": {
+    "type": "enabled",
+    "budget_tokens": 10000
+}
+```
+
+**When to apply**: User reports issues related to "thinking" while extended thinking is not enabled (no `thinking` parameter in their request).
+
+**Solution**: Replace "think" with alternative words.
+
+| Before | After |
+|--------|-------|
+| `think about` | `consider` |
+| `think through` | `evaluate` |
+| `I think` | `I believe` |
+| `think carefully` | `consider carefully` |
+| `thinking` | `reasoning` / `considering` |
+
+## Usage Guidelines
+
+1. **Integrate thoughtfully** - Don't just append snippets; weave them into the existing prompt structure
+2. **Use XML tags** - Wrap additions in descriptive tags (e.g., `<coding_guidelines>`, `<tool_behavior>`) that match or complement existing prompt structure
+3. **Match prompt style** - If the prompt is concise, trim the snippet; if verbose, keep full detail
+4. **Place logically** - Put coding snippets near other coding instructions, tool guidance near tool definitions, etc.
+5. **Preserve existing content** - Insert snippets without removing functional content
+6. **Summarize changes** - After migration, list all model string updates and prompt modifications made

plugins/code-review/commands/code-review.md

@@ -1,65 +1,91 @@
 ---
 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
-disable-model-invocation: false
 ---
 
 Provide a code review for the given pull request.
 
 To do this, follow these steps precisely:
 
-1. Use a Haiku agent to check if the pull request (a) is closed, (b) is a draft, (c) does not need a code review (eg. because it is an automated pull request, or is very simple and obviously ok), or (d) already has a code review from you from earlier. If so, do not proceed.
-2. Use another Haiku agent to give you a list of file paths to (but not the contents of) any relevant CLAUDE.md files from the codebase: the root CLAUDE.md file (if one exists), as well as any CLAUDE.md files in the directories whose files the pull request modified
-3. Use a Haiku agent to view the pull request, and ask the agent to return a summary of the change
-4. Then, launch 5 parallel Sonnet agents to independently code review the change. The agents should do the following, then return a list of issues and the reason each issue was flagged (eg. CLAUDE.md adherence, bug, historical git context, etc.):
-   a. Agent #1: Audit the changes to make sure they compily with the CLAUDE.md. Note that CLAUDE.md is guidance for Claude as it writes code, so not all instructions will be applicable during code review.
-   b. Agent #2: Read the file changes in the pull request, then do a shallow scan for obvious bugs. Avoid reading extra context beyond the changes, focusing just on the changes themselves. Focus on large bugs, and avoid small issues and nitpicks. Ignore likely false positives.
-   c. Agent #3: Read the git blame and history of the code modified, to identify any bugs in light of that historical context
-   d. Agent #4: Read previous pull requests that touched these files, and check for any comments on those pull requests that may also apply to the current pull request.
-   e. Agent #5: Read code comments in the modified files, and make sure the changes in the pull request comply with any guidance in the comments.
-5. For each issue found in #4, launch a parallel Haiku agent that takes the PR, issue description, and list of CLAUDE.md files (from step 2), and returns a score to indicate the agent's level of confidence for whether the issue is real or false positive. To do that, the agent should score each issue on a scale from 0-100, indicating its level of confidence. For issues that were flagged due to CLAUDE.md instructions, the agent should double check that the CLAUDE.md actually calls out that issue specifically. The scale is (give this rubric to the agent verbatim):
-   a. 0: Not confident at all. This is a false positive that doesn't stand up to light scrutiny, or is a pre-existing issue.
-   b. 25: Somewhat confident. This might be a real issue, but may also be a false positive. The agent wasn't able to verify that it's a real issue. If the issue is stylistic, it is one that was not explicitly called out in the relevant CLAUDE.md.
-   c. 50: Moderately confident. The agent was able to verify this is a real issue, but it might be a nitpick or not happen very often in practice. Relative to the rest of the PR, it's not very important.
-   d. 75: Highly confident. The agent double checked the issue, and verified that it is very likely it is a real issue that will be hit in practice. The existing approach in the PR is insufficient. The issue is very important and will directly impact the code's functionality, or it is an issue that is directly mentioned in the relevant CLAUDE.md.
-   e. 100: Absolutely certain. The agent double checked the issue, and confirmed that it is definitely a real issue, that will happen frequently in practice. The evidence directly confirms this.
-6. Filter out any issues with a score less than 80. If there are no issues that meet this criteria, do not proceed.
-7. Use a Haiku agent to repeat the eligibility check from #1, to make sure that the pull request is still eligible for code review.
-8. Finally, use the gh bash command to comment back on the pull request with the result. When writing your comment, keep in mind to:
+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)
+   - You have already submitted a code review on this pull request
+
+   If any condition is true, stop and do not proceed.
+
+Note: Still review Claude generated PR's.
+
+2. Launch a haiku agent to return a list of file paths (not their contents) for all relevant CLAUDE.md files including:
+   - The root CLAUDE.md file, if it exists
+   - Any CLAUDE.md files in directories containing files modified by the pull request
+
+3. Launch a sonnet agent to view the pull request and return a summary of the changes
+
+4. Launch 4 agents in parallel to independently review the changes. Each agent should return the list of issues, where each issue includes a description and the reason it was flagged (e.g. "CLAUDE.md adherence", "bug"). The agents should do the following:
+
+   Agents 1 + 2: CLAUDE.md compliance sonnet agents
+   Audit changes for CLAUDE.md compliance in parallel. Note: When evaluating CLAUDE.md compliance for a file, you should only consider CLAUDE.md files that share a file path with the file or parents.
+
+   Agent 3: Opus bug agent (parallel subagent with agent 4)
+   Scan for obvious bugs. Focus only on the diff itself without reading extra context. Flag only significant bugs; ignore nitpicks and likely false positives. Do not flag issues that you cannot validate without looking at context outside of the git diff.
+
+   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.** 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
+
+   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.
+
+   In addition to the above, each subagent should be told the PR title and description. This will help provide context regarding the author's intent.
+
+5. For each issue found in the previous step by agents 3 and 4, launch parallel subagents to validate the issue. These subagents should get the PR title and description along with a description of the issue. The agent's job is to review the issue to validate that the stated issue is truly an issue with high confidence. For example, if an issue such as "variable is not defined" was flagged, the subagent's job would be to validate that is actually true in the code. Another example would be CLAUDE.md issues. The agent should validate that the CLAUDE.md rule that was violated is scoped for this file and is actually violated. Use Opus subagents for bugs and logic issues, and sonnet agents for CLAUDE.md violations.
+
+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. 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
+   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")
 
-Examples of false positives, for steps 4 and 5:
+Use this list when evaluating issues in Steps 4 and 5 (these are false positives, do NOT flag):
 
 - Pre-existing issues
-- Something that looks like a bug but is not actually a bug
-- Pedantic nitpicks that a senior engineer wouldn't call out
-- Issues that a linter, typechecker, or compiler would catch (eg. missing or incorrect imports, type errors, broken tests, formatting issues, pedantic style issues like newlines). No need to run these build steps yourself -- it is safe to assume that they will be run separately as part of CI.
-- General code quality issues (eg. lack of test coverage, general security issues, poor documentation), unless explicitly required in CLAUDE.md
-- Issues that are called out in CLAUDE.md, but explicitly silenced in the code (eg. due to a lint ignore comment)
-- Changes in functionality that are likely intentional or are directly related to the broader change
-- Real issues, but on lines that the user did not modify in their pull request
+- Something that appears to be a bug but is actually correct
+- Pedantic nitpicks that a senior engineer would not flag
+- Issues that a linter will catch (do not run the linter to verify)
+- General code quality concerns (e.g., lack of test coverage, general security issues) unless explicitly required in CLAUDE.md
+- Issues mentioned in CLAUDE.md but explicitly silenced in the code (e.g., via a lint ignore comment)
 
 Notes:
 
-- Do not check build signal or attempt to build or typecheck the app. These will run separately, and are not relevant to your code review.
-- Use `gh` to interact with Github (eg. to fetch a pull request, or to create inline comments), rather than web fetch
-- Make a todo list first
-- You must cite and link each bug (eg. if referring to a CLAUDE.md, you must link it)
+- 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 (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
+## Code review
 
 Found 3 issues:
 
-1. <brief description of bug> (CLAUDE.md says "<...>")
+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, note that you MUST provide the full sha and not use bash here, eg. https://github.com/anthropics/claude-code/blob/1d54823877c4de72b2316a64032a54afc404e619/README.md#L13-L17>
+<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 "<...>")
+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>
 
@@ -67,23 +93,19 @@ Found 3 issues:
 
 <link to file and line with full sha1 + line range for context>
 
-🤖 Generated with [Claude Code](https://claude.ai/code)
-
-<sub>- If this code review was useful, please react with 👍. Otherwise, react with 👎.</sub>
-
 ---
 
 - Or, if you found no issues:
 
 ---
 
-### Code review
+## Auto code review
 
 No issues found. Checked for bugs and CLAUDE.md compliance.
 
-🤖 Generated with [Claude Code](https://claude.ai/code)
+---
 
-- When linking to code, follow the following format precisely, otherwise the Markdown preview won't render correctly: https://github.com/anthropics/claude-cli-internal/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

plugins/swarm-coordination/.claude-plugin/plugin.json

@@ -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"]
+}

plugins/swarm-coordination/README.md

@@ -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

plugins/swarm-coordination/agents/conflict-detector.md

@@ -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

plugins/swarm-coordination/agents/plan-reviewer.md

@@ -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

plugins/swarm-coordination/agents/status-checker.md

@@ -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)

plugins/swarm-coordination/commands/swarm.md

@@ -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.

plugins/swarm-coordination/skills/swarm-patterns/SKILL.md

@@ -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

plugins/swarm-coordination/skills/swarm-patterns/examples/simple-swarm.md

@@ -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
+```

plugins/swarm-coordination/skills/swarm-patterns/references/checkpoint-flow.md

@@ -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

plugins/swarm-coordination/skills/swarm-patterns/references/file-claiming.md

@@ -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

plugins/swarm-coordination/skills/swarm-patterns/references/status-polling.md

@@ -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