chore: Update CHANGELOG.md

Updates edit-issue-labels.sh and comment-on-duplicates.sh to read the
issue number from GITHUB_EVENT_PATH (the workflow event payload) instead
of accepting it as a CLI argument. Simplifies the call signature and
keeps the scripts aligned with the triggering issue.

Also updates the /triage-issue and /dedupe command docs to match.

🏠 Remote-Dev: homespace

.claude/commands/dedupe.md

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

.claude/commands/oncall-triage.md

@@ -1,40 +0,0 @@
----
-allowed-tools: Bash(gh issue list:*), Bash(gh issue view:*), Bash(gh issue edit:*), TodoWrite
-description: Triage GitHub issues and label critical ones for oncall
----
-
-You're an oncall triage assistant for GitHub issues. Your task is to identify critical issues that require immediate oncall attention and apply the "oncall" label.
-
-Repository: anthropics/claude-code
-
-Task overview:
-
-1. First, get all open bugs updated in the last 3 days with at least 50 engagements:
-   ```bash
-   gh issue list --repo anthropics/claude-code --state open --label bug --limit 1000 --json number,title,updatedAt,comments,reactions | jq -r '.[] | select((.updatedAt >= (now - 259200 | strftime("%Y-%m-%dT%H:%M:%SZ"))) and ((.comments | length) + ([.reactions[].content] | length) >= 50)) | "\(.number)"'
-   ```
-
-2. Save the list of issue numbers and create a TODO list with ALL of them. This ensures you process every single one.
-
-3. For each issue in your TODO list:
-   - Use `gh issue view <number> --repo anthropics/claude-code --json title,body,labels,comments` to get full details
-   - Read and understand the full issue content and comments to determine actual user impact
-   - Evaluate: Is this truly blocking users from using Claude Code?
-     - Consider: "crash", "stuck", "frozen", "hang", "unresponsive", "cannot use", "blocked", "broken"
-     - Does it prevent core functionality? Can users work around it?
-   - Be conservative - only flag issues that truly prevent users from getting work done
-
-4. For issues that are truly blocking and don't already have the "oncall" label:
-   - Use `gh issue edit <number> --repo anthropics/claude-code --add-label "oncall"`
-   - Mark the issue as complete in your TODO list
-
-5. After processing all issues, provide a summary:
-   - List each issue number that received the "oncall" label
-   - Include the issue title and brief reason why it qualified
-   - If no issues qualified, state that clearly
-
-Important:
-- Process ALL issues in your TODO list systematically
-- Don't post any comments to issues
-- Only add the "oncall" label, never remove it
-- Use individual `gh issue view` commands instead of bash for loops to avoid approval prompts

.claude/commands/triage-issue.md

@@ -0,0 +1,70 @@
+---
+allowed-tools: Bash(./scripts/gh.sh:*),Bash(./scripts/edit-issue-labels.sh:*)
+description: Triage GitHub issues by analyzing and applying labels
+---
+
+You're an issue triage assistant. Analyze the issue and manage labels.
+
+IMPORTANT: Don't post any comments or messages to the issue. Your only actions are adding or removing labels.
+
+Context:
+
+$ARGUMENTS
+
+TOOLS:
+- `./scripts/gh.sh` — wrapper for `gh` CLI. Only supports these subcommands and flags:
+  - `./scripts/gh.sh label list` — fetch all available labels
+  - `./scripts/gh.sh label list --limit 100` — fetch with limit
+  - `./scripts/gh.sh issue view 123` — read issue title, body, and labels
+  - `./scripts/gh.sh issue view 123 --comments` — read the conversation
+  - `./scripts/gh.sh issue list --state open --limit 20` — list issues
+  - `./scripts/gh.sh search issues "query"` — find similar or duplicate issues
+  - `./scripts/gh.sh search issues "query" --limit 10` — search with limit
+- `./scripts/edit-issue-labels.sh --add-label LABEL --remove-label LABEL` — add or remove labels (issue number is read from the workflow event)
+
+TASK:
+
+1. Run `./scripts/gh.sh label list` to fetch the available labels. You may ONLY use labels from this list. Never invent new labels.
+2. Run `./scripts/gh.sh issue view ISSUE_NUMBER` to read the issue details.
+3. Run `./scripts/gh.sh issue view ISSUE_NUMBER --comments` to read the conversation.
+
+**If EVENT is "issues" (new issue):**
+
+4. First, check if this issue is actually about Claude Code (the CLI/IDE tool). Issues about the Claude API, claude.ai, the Claude app, Anthropic billing, or other Anthropic products should be labeled `invalid`. If invalid, apply only that label and stop.
+
+5. Analyze and apply category labels:
+   - Type (bug, enhancement, question, etc.)
+   - Technical areas and platform
+   - Check for duplicates with `./scripts/gh.sh search issues`. Only mark as duplicate of OPEN issues.
+
+6. Evaluate lifecycle labels:
+   - `needs-repro` (bugs only, 7 days): Bug reports without clear steps to reproduce. A good repro has specific, followable steps that someone else could use to see the same issue.
+     Do NOT apply if the user already provided error messages, logs, file paths, or a description of what they did. Don't require a specific format — narrative descriptions count.
+     For model behavior issues (e.g. "Claude does X when it should do Y"), don't require traditional repro steps — examples and patterns are sufficient.
+   - `needs-info` (bugs only, 7 days): The issue needs something from the community before it can progress — e.g. error messages, versions, environment details, or answers to follow-up questions. Don't apply to questions or enhancements.
+     Do NOT apply if the user already provided version, environment, and error details. If the issue just needs engineering investigation, that's not `needs-info`.
+
+   Issues with these labels are automatically closed after the timeout if there's no response.
+   The goal is to avoid issues lingering without a clear next step.
+
+7. Apply all selected labels:
+   `./scripts/edit-issue-labels.sh --add-label "label1" --add-label "label2"`
+
+**If EVENT is "issue_comment" (comment on existing issue):**
+
+4. Evaluate lifecycle labels based on the full conversation:
+   - If the issue has `stale` or `autoclose`, remove the label — a new human comment means the issue is still active:
+     `./scripts/edit-issue-labels.sh --remove-label "stale" --remove-label "autoclose"`
+   - If the issue has `needs-repro` or `needs-info` and the missing information has now been provided, remove the label:
+     `./scripts/edit-issue-labels.sh --remove-label "needs-repro"`
+   - If the issue doesn't have lifecycle labels but clearly needs them (e.g., a maintainer asked for repro steps or more details), add the appropriate label.
+   - Comments like "+1", "me too", "same here", or emoji reactions are NOT the missing information. Only remove `needs-repro` or `needs-info` when substantive details are actually provided.
+   - Do NOT add or remove category labels (bug, enhancement, etc.) on comment events.
+
+GUIDELINES:
+- ONLY use labels from `./scripts/gh.sh label list` — never create or guess label names
+- DO NOT post any comments to the issue
+- Be conservative with lifecycle labels — only apply when clearly warranted
+- Only apply lifecycle labels (`needs-repro`, `needs-info`) to bugs — never to questions or enhancements
+- When in doubt, don't apply a lifecycle label — false positives are worse than missing labels
+- It's okay to not add any labels if none are clearly applicable

.github/workflows/claude-dedupe-issues.yml

@@ -23,13 +23,16 @@ jobs:
         uses: actions/checkout@v4
 
       - name: Run Claude Code slash command
-        uses: anthropics/claude-code-base-action@beta
+        uses: anthropics/claude-code-action@v1
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          CLAUDE_CODE_SCRIPT_CAPS: '{"comment-on-duplicates.sh":1}'
         with:
+          github_token: ${{ secrets.GITHUB_TOKEN }}
+          allowed_non_write_users: "*"
           prompt: "/dedupe ${{ github.repository }}/issues/${{ github.event.issue.number || inputs.issue_number }}"
           anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
           claude_args: "--model claude-sonnet-4-5-20250929"
-          claude_env: |
-            GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 
       - name: Log duplicate comment event to Statsig
         if: always()

.github/workflows/claude-issue-triage.yml

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

.github/workflows/claude.yml

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

.github/workflows/issue-lifecycle-comment.yml

@@ -0,0 +1,27 @@
+name: "Issue Lifecycle Comment"
+
+on:
+  issues:
+    types: [labeled]
+
+permissions:
+  issues: write
+
+jobs:
+  comment:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Setup Bun
+        uses: oven-sh/setup-bun@v2
+        with:
+          bun-version: latest
+
+      - name: Post lifecycle comment
+        run: bun run scripts/lifecycle-comment.ts
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          LABEL: ${{ github.event.label.name }}
+          ISSUE_NUMBER: ${{ github.event.issue.number }}

.github/workflows/non-write-users-check.yml

@@ -0,0 +1,47 @@
+name: Non-write Users Check
+on:
+  pull_request:
+    paths:
+      - ".github/**"
+
+permissions:
+  contents: read
+  pull-requests: write
+
+jobs:
+  allowed-non-write-check:
+    runs-on: ubuntu-latest
+    env:
+      GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+    steps:
+      - run: |
+          DIFF=$(gh pr diff "$PR_NUMBER" -R "$REPO" || true)
+
+          if ! echo "$DIFF" | grep -qE '^diff --git a/\.github/.*\.ya?ml'; then
+            exit 0
+          fi
+
+          MATCHES=$(echo "$DIFF" | grep "^+.*allowed_non_write_users" || true)
+
+          if [ -z "$MATCHES" ]; then
+            exit 0
+          fi
+
+          EXISTING=$(gh pr view "$PR_NUMBER" -R "$REPO" --json comments --jq '.comments[].body' \
+            | grep -c "<!-- non-write-users-check -->" || true)
+
+          if [ "$EXISTING" -gt 0 ]; then
+            exit 0
+          fi
+
+          gh pr comment "$PR_NUMBER" -R "$REPO" --body '<!-- non-write-users-check -->
+          **`allowed_non_write_users` detected**
+
+          This PR adds or modifies `allowed_non_write_users`, which allows users without write access to trigger Claude Code Action workflows. This can introduce security risks.
+
+          If this is a new flow, please make sure you actually need `allowed_non_write_users`. If you are editing an existing workflow, double check that you are not adding new Claude permissions which might lead to a vulnerability.
+
+          See existing workflows in this repo for safe usage examples, or contact the AppSec team.'
+        env:
+          PR_NUMBER: ${{ github.event.pull_request.number }}
+          REPO: ${{ github.repository }}

.github/workflows/oncall-triage.yml

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

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

@@ -1,157 +0,0 @@
-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}`);

.github/workflows/sweep.yml

@@ -0,0 +1,31 @@
+name: "Issue Sweep"
+
+on:
+  schedule:
+    - cron: "0 10,22 * * *"
+  workflow_dispatch:
+
+permissions:
+  issues: write
+
+concurrency:
+  group: daily-issue-sweep
+
+jobs:
+  sweep:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Setup Bun
+        uses: oven-sh/setup-bun@v2
+        with:
+          bun-version: latest
+
+      - name: Enforce lifecycle timeouts
+        run: bun run scripts/sweep.ts
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          GITHUB_REPOSITORY_OWNER: ${{ github.repository_owner }}
+          GITHUB_REPOSITORY_NAME: ${{ github.event.repository.name }}

README.md

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

examples/settings/README.md

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

examples/settings/settings-bash-sandbox.json

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

examples/settings/settings-lax.json

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

examples/settings/settings-strict.json

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

plugins/code-review/README.md

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

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

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

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

plugins/ralph-wiggum/commands/ralph-loop.md

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

plugins/ralph-wiggum/scripts/setup-ralph-loop.sh

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

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

@@ -1,7 +0,0 @@
-{
-  "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

@@ -1,152 +0,0 @@
-# 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

@@ -1,108 +0,0 @@
----
-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

@@ -1,124 +0,0 @@
----
-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

@@ -1,81 +0,0 @@
----
-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

@@ -1,287 +0,0 @@
----
-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

@@ -1,80 +0,0 @@
-# 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

@@ -1,260 +0,0 @@
-# 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

@@ -1,287 +0,0 @@
-# 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

@@ -1,233 +0,0 @@
-# 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

@@ -1,152 +0,0 @@
-# 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

scripts/comment-on-duplicates.sh

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

scripts/edit-issue-labels.sh

@@ -0,0 +1,84 @@
+#!/usr/bin/env bash
+#
+# Edits labels on a GitHub issue.
+# Usage: ./edit-issue-labels.sh --add-label bug --add-label needs-triage --remove-label untriaged
+#
+# The issue number is read from the workflow event payload.
+#
+
+set -euo pipefail
+
+# Read from event payload so the issue number is bound to the triggering event.
+# Falls back to workflow_dispatch inputs for manual runs.
+ISSUE=$(jq -r '.issue.number // .inputs.issue_number // empty' "${GITHUB_EVENT_PATH:?GITHUB_EVENT_PATH not set}")
+if ! [[ "$ISSUE" =~ ^[0-9]+$ ]]; then
+  echo "Error: no issue number in event payload" >&2
+  exit 1
+fi
+
+ADD_LABELS=()
+REMOVE_LABELS=()
+
+# Parse arguments
+while [[ $# -gt 0 ]]; do
+  case $1 in
+    --add-label)
+      ADD_LABELS+=("$2")
+      shift 2
+      ;;
+    --remove-label)
+      REMOVE_LABELS+=("$2")
+      shift 2
+      ;;
+    *)
+      echo "Error: unknown argument (only --add-label and --remove-label are accepted)" >&2
+      exit 1
+      ;;
+  esac
+done
+
+if [[ ${#ADD_LABELS[@]} -eq 0 && ${#REMOVE_LABELS[@]} -eq 0 ]]; then
+  exit 1
+fi
+
+# Fetch valid labels from the repo
+VALID_LABELS=$(gh label list --limit 500 --json name --jq '.[].name')
+
+# Filter to only labels that exist in the repo
+FILTERED_ADD=()
+for label in "${ADD_LABELS[@]}"; do
+  if echo "$VALID_LABELS" | grep -qxF "$label"; then
+    FILTERED_ADD+=("$label")
+  fi
+done
+
+FILTERED_REMOVE=()
+for label in "${REMOVE_LABELS[@]}"; do
+  if echo "$VALID_LABELS" | grep -qxF "$label"; then
+    FILTERED_REMOVE+=("$label")
+  fi
+done
+
+if [[ ${#FILTERED_ADD[@]} -eq 0 && ${#FILTERED_REMOVE[@]} -eq 0 ]]; then
+  exit 0
+fi
+
+# Build gh command arguments
+GH_ARGS=("issue" "edit" "$ISSUE")
+
+for label in "${FILTERED_ADD[@]}"; do
+  GH_ARGS+=("--add-label" "$label")
+done
+
+for label in "${FILTERED_REMOVE[@]}"; do
+  GH_ARGS+=("--remove-label" "$label")
+done
+
+gh "${GH_ARGS[@]}"
+
+if [[ ${#FILTERED_ADD[@]} -gt 0 ]]; then
+  echo "Added: ${FILTERED_ADD[*]}"
+fi
+if [[ ${#FILTERED_REMOVE[@]} -gt 0 ]]; then
+  echo "Removed: ${FILTERED_REMOVE[*]}"
+fi

scripts/gh.sh

@@ -0,0 +1,96 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Wrapper around gh CLI that only allows specific subcommands and flags.
+# All commands are scoped to the current repository via GH_REPO or GITHUB_REPOSITORY.
+#
+# Usage:
+#   ./scripts/gh.sh issue view 123
+#   ./scripts/gh.sh issue view 123 --comments
+#   ./scripts/gh.sh issue list --state open --limit 20
+#   ./scripts/gh.sh search issues "search query" --limit 10
+#   ./scripts/gh.sh label list --limit 100
+
+export GH_HOST=github.com
+
+REPO="${GH_REPO:-${GITHUB_REPOSITORY:-}}"
+if [[ -z "$REPO" || "$REPO" == */*/* || "$REPO" != */* ]]; then
+  echo "Error: GH_REPO or GITHUB_REPOSITORY must be set to owner/repo format (e.g., GITHUB_REPOSITORY=anthropics/claude-code)" >&2
+  exit 1
+fi
+export GH_REPO="$REPO"
+
+ALLOWED_FLAGS=(--comments --state --limit --label)
+FLAGS_WITH_VALUES=(--state --limit --label)
+
+SUB1="${1:-}"
+SUB2="${2:-}"
+CMD="$SUB1 $SUB2"
+case "$CMD" in
+  "issue view"|"issue list"|"search issues"|"label list")
+    ;;
+  *)
+    echo "Error: only 'issue view', 'issue list', 'search issues', 'label list' are allowed (e.g., ./scripts/gh.sh issue view 123)" >&2
+    exit 1
+    ;;
+esac
+
+shift 2
+
+# Separate flags from positional arguments
+POSITIONAL=()
+FLAGS=()
+skip_next=false
+for arg in "$@"; do
+  if [[ "$skip_next" == true ]]; then
+    FLAGS+=("$arg")
+    skip_next=false
+  elif [[ "$arg" == -* ]]; then
+    flag="${arg%%=*}"
+    matched=false
+    for allowed in "${ALLOWED_FLAGS[@]}"; do
+      if [[ "$flag" == "$allowed" ]]; then
+        matched=true
+        break
+      fi
+    done
+    if [[ "$matched" == false ]]; then
+      echo "Error: only --comments, --state, --limit, --label flags are allowed (e.g., ./scripts/gh.sh issue list --state open --limit 20)" >&2
+      exit 1
+    fi
+    FLAGS+=("$arg")
+    # If flag expects a value and isn't using = syntax, skip next arg
+    if [[ "$arg" != *=* ]]; then
+      for vflag in "${FLAGS_WITH_VALUES[@]}"; do
+        if [[ "$flag" == "$vflag" ]]; then
+          skip_next=true
+          break
+        fi
+      done
+    fi
+  else
+    POSITIONAL+=("$arg")
+  fi
+done
+
+if [[ "$CMD" == "search issues" ]]; then
+  QUERY="${POSITIONAL[0]:-}"
+  QUERY_LOWER=$(echo "$QUERY" | tr '[:upper:]' '[:lower:]')
+  if [[ "$QUERY_LOWER" == *"repo:"* || "$QUERY_LOWER" == *"org:"* || "$QUERY_LOWER" == *"user:"* ]]; then
+    echo "Error: search query must not contain repo:, org:, or user: qualifiers (e.g., ./scripts/gh.sh search issues \"bug report\" --limit 10)" >&2
+    exit 1
+  fi
+  gh "$SUB1" "$SUB2" "$QUERY" --repo "$REPO" "${FLAGS[@]}"
+elif [[ "$CMD" == "issue view" ]]; then
+  if [[ ${#POSITIONAL[@]} -ne 1 ]] || ! [[ "${POSITIONAL[0]}" =~ ^[0-9]+$ ]]; then
+    echo "Error: issue view requires exactly one numeric issue number (e.g., ./scripts/gh.sh issue view 123)" >&2
+    exit 1
+  fi
+  gh "$SUB1" "$SUB2" "${POSITIONAL[0]}" "${FLAGS[@]}"
+else
+  if [[ ${#POSITIONAL[@]} -ne 0 ]]; then
+    echo "Error: issue list and label list do not accept positional arguments (e.g., ./scripts/gh.sh issue list --state open, ./scripts/gh.sh label list --limit 100)" >&2
+    exit 1
+  fi
+  gh "$SUB1" "$SUB2" "${FLAGS[@]}"
+fi

scripts/issue-lifecycle.ts

@@ -0,0 +1,38 @@
+// Single source of truth for issue lifecycle labels, timeouts, and messages.
+
+export const lifecycle = [
+  {
+    label: "invalid",
+    days: 3,
+    reason: "this doesn't appear to be about Claude Code",
+    nudge: "This doesn't appear to be about [Claude Code](https://github.com/anthropics/claude-code). For general Anthropic support, visit [support.anthropic.com](https://support.anthropic.com).",
+  },
+  {
+    label: "needs-repro",
+    days: 7,
+    reason: "we still need reproduction steps to investigate",
+    nudge: "We weren't able to reproduce this. Could you provide steps to trigger the issue — what you ran, what happened, and what you expected?",
+  },
+  {
+    label: "needs-info",
+    days: 7,
+    reason: "we still need a bit more information to move forward",
+    nudge: "We need more information to continue investigating. Can you make sure to include your Claude Code version (`claude --version`), OS, and any error messages or logs?",
+  },
+  {
+    label: "stale",
+    days: 14,
+    reason: "inactive for too long",
+    nudge: "This issue has been automatically marked as stale due to inactivity.",
+  },
+  {
+    label: "autoclose",
+    days: 14,
+    reason: "inactive for too long",
+    nudge: "This issue has been marked for automatic closure.",
+  },
+] as const;
+
+export type LifecycleLabel = (typeof lifecycle)[number]["label"];
+
+export const STALE_UPVOTE_THRESHOLD = 10;

scripts/lifecycle-comment.ts

@@ -0,0 +1,53 @@
+#!/usr/bin/env bun
+
+// Posts a comment when a lifecycle label is applied to an issue,
+// giving the author a heads-up and a chance to respond before auto-close.
+
+import { lifecycle } from "./issue-lifecycle.ts";
+
+const DRY_RUN = process.argv.includes("--dry-run");
+const token = process.env.GITHUB_TOKEN;
+const repo = process.env.GITHUB_REPOSITORY; // owner/repo
+const label = process.env.LABEL;
+const issueNumber = process.env.ISSUE_NUMBER;
+
+if (!DRY_RUN && !token) throw new Error("GITHUB_TOKEN required");
+if (!repo) throw new Error("GITHUB_REPOSITORY required");
+if (!label) throw new Error("LABEL required");
+if (!issueNumber) throw new Error("ISSUE_NUMBER required");
+
+const entry = lifecycle.find((l) => l.label === label);
+if (!entry) {
+  console.log(`No lifecycle entry for label "${label}", skipping`);
+  process.exit(0);
+}
+
+const body = `${entry.nudge} This issue will be closed automatically if there's no activity within ${entry.days} days.`;
+
+// --
+
+if (DRY_RUN) {
+  console.log(`Would comment on #${issueNumber} for label "${label}":\n\n${body}`);
+  process.exit(0);
+}
+
+const response = await fetch(
+  `https://api.github.com/repos/${repo}/issues/${issueNumber}/comments`,
+  {
+    method: "POST",
+    headers: {
+      Authorization: `Bearer ${token}`,
+      Accept: "application/vnd.github.v3+json",
+      "Content-Type": "application/json",
+      "User-Agent": "lifecycle-comment",
+    },
+    body: JSON.stringify({ body }),
+  }
+);
+
+if (!response.ok) {
+  const text = await response.text();
+  throw new Error(`GitHub API ${response.status}: ${text}`);
+}
+
+console.log(`Commented on #${issueNumber} for label "${label}"`);

scripts/sweep.ts

@@ -0,0 +1,168 @@
+#!/usr/bin/env bun
+
+import { lifecycle, STALE_UPVOTE_THRESHOLD } from "./issue-lifecycle.ts";
+
+// --
+
+const NEW_ISSUE = "https://github.com/anthropics/claude-code/issues/new/choose";
+const DRY_RUN = process.argv.includes("--dry-run");
+
+const CLOSE_MESSAGE = (reason: string) =>
+  `Closing for now — ${reason}. Please [open a new issue](${NEW_ISSUE}) if this is still relevant.`;
+
+// --
+
+async function githubRequest<T>(
+  endpoint: string,
+  method = "GET",
+  body?: unknown
+): Promise<T> {
+  const token = process.env.GITHUB_TOKEN;
+  if (!token) throw new Error("GITHUB_TOKEN required");
+
+  const response = await fetch(`https://api.github.com${endpoint}`, {
+    method,
+    headers: {
+      Authorization: `Bearer ${token}`,
+      Accept: "application/vnd.github.v3+json",
+      "User-Agent": "sweep",
+      ...(body && { "Content-Type": "application/json" }),
+    },
+    ...(body && { body: JSON.stringify(body) }),
+  });
+
+  if (!response.ok) {
+    if (response.status === 404) return {} as T;
+    const text = await response.text();
+    throw new Error(`GitHub API ${response.status}: ${text}`);
+  }
+
+  return response.json();
+}
+
+// --
+
+async function markStale(owner: string, repo: string) {
+  const staleDays = lifecycle.find((l) => l.label === "stale")!.days;
+  const cutoff = new Date();
+  cutoff.setDate(cutoff.getDate() - staleDays);
+
+  let labeled = 0;
+
+  console.log(`\n=== marking stale (${staleDays}d inactive) ===`);
+
+  for (let page = 1; page <= 10; page++) {
+    const issues = await githubRequest<any[]>(
+      `/repos/${owner}/${repo}/issues?state=open&sort=updated&direction=asc&per_page=100&page=${page}`
+    );
+    if (issues.length === 0) break;
+
+    for (const issue of issues) {
+      if (issue.pull_request) continue;
+      if (issue.locked) continue;
+      if (issue.assignees?.length > 0) continue;
+
+      const updatedAt = new Date(issue.updated_at);
+      if (updatedAt > cutoff) return labeled;
+
+      const alreadyStale = issue.labels?.some(
+        (l: any) => l.name === "stale" || l.name === "autoclose"
+      );
+      if (alreadyStale) continue;
+
+      const thumbsUp = issue.reactions?.["+1"] ?? 0;
+      if (thumbsUp >= STALE_UPVOTE_THRESHOLD) continue;
+
+      const base = `/repos/${owner}/${repo}/issues/${issue.number}`;
+
+      if (DRY_RUN) {
+        const age = Math.floor((Date.now() - updatedAt.getTime()) / 86400000);
+        console.log(`#${issue.number}: would label stale (${age}d inactive) — ${issue.title}`);
+      } else {
+        await githubRequest(`${base}/labels`, "POST", { labels: ["stale"] });
+        console.log(`#${issue.number}: labeled stale — ${issue.title}`);
+      }
+      labeled++;
+    }
+  }
+
+  return labeled;
+}
+
+async function closeExpired(owner: string, repo: string) {
+  let closed = 0;
+
+  for (const { label, days, reason } of lifecycle) {
+    const cutoff = new Date();
+    cutoff.setDate(cutoff.getDate() - days);
+    console.log(`\n=== ${label} (${days}d timeout) ===`);
+
+    for (let page = 1; page <= 10; page++) {
+      const issues = await githubRequest<any[]>(
+        `/repos/${owner}/${repo}/issues?state=open&labels=${label}&sort=updated&direction=asc&per_page=100&page=${page}`
+      );
+      if (issues.length === 0) break;
+
+      for (const issue of issues) {
+        if (issue.pull_request) continue;
+        if (issue.locked) continue;
+
+        const thumbsUp = issue.reactions?.["+1"] ?? 0;
+        if (thumbsUp >= STALE_UPVOTE_THRESHOLD) continue;
+
+        const base = `/repos/${owner}/${repo}/issues/${issue.number}`;
+
+        const events = await githubRequest<any[]>(`${base}/events?per_page=100`);
+
+        const labeledAt = events
+          .filter((e) => e.event === "labeled" && e.label?.name === label)
+          .map((e) => new Date(e.created_at))
+          .pop();
+
+        if (!labeledAt || labeledAt > cutoff) continue;
+
+        // Skip if a non-bot user commented after the label was applied.
+        // The triage workflow should remove lifecycle labels on human
+        // activity, but check here too as a safety net.
+        const comments = await githubRequest<any[]>(
+          `${base}/comments?since=${labeledAt.toISOString()}&per_page=100`
+        );
+        const hasHumanComment = comments.some(
+          (c) => c.user && c.user.type !== "Bot"
+        );
+        if (hasHumanComment) {
+          console.log(
+            `#${issue.number}: skipping (human activity after ${label} label)`
+          );
+          continue;
+        }
+
+        if (DRY_RUN) {
+          const age = Math.floor((Date.now() - labeledAt.getTime()) / 86400000);
+          console.log(`#${issue.number}: would close (${label}, ${age}d old) — ${issue.title}`);
+        } else {
+          await githubRequest(`${base}/comments`, "POST", { body: CLOSE_MESSAGE(reason) });
+          await githubRequest(base, "PATCH", { state: "closed", state_reason: "not_planned" });
+          console.log(`#${issue.number}: closed (${label})`);
+        }
+        closed++;
+      }
+    }
+  }
+
+  return closed;
+}
+
+// --
+
+const owner = process.env.GITHUB_REPOSITORY_OWNER;
+const repo = process.env.GITHUB_REPOSITORY_NAME;
+if (!owner || !repo)
+  throw new Error("GITHUB_REPOSITORY_OWNER and GITHUB_REPOSITORY_NAME required");
+
+if (DRY_RUN) console.log("DRY RUN — no changes will be made\n");
+
+const labeled = await markStale(owner, repo);
+const closed = await closeExpired(owner, repo);
+
+console.log(`\nDone: ${labeled} ${DRY_RUN ? "would be labeled" : "labeled"} stale, ${closed} ${DRY_RUN ? "would be closed" : "closed"}`);