mirror of
https://github.com/anthropics/claude-code.git
synced 2026-02-19 04:27:33 -08:00
Compare commits
15 Commits
claude/add
...
v2.1.11
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
923d727492 | ||
|
|
fb3a947cb5 | ||
|
|
2961ddcafe | ||
|
|
fd8f3801b9 | ||
|
|
26315247e7 | ||
|
|
5a91286a82 | ||
|
|
3196f36cee | ||
|
|
7d22b6e167 | ||
|
|
19a829ba68 | ||
|
|
18979efb8d | ||
|
|
f77acdf149 | ||
|
|
c13cf781ef | ||
|
|
cc70d3ab50 | ||
|
|
250b257c4e | ||
|
|
dec754edc9 |
5
.github/workflows/claude-dedupe-issues.yml
vendored
5
.github/workflows/claude-dedupe-issues.yml
vendored
@@ -17,16 +17,19 @@ jobs:
|
||||
permissions:
|
||||
contents: read
|
||||
issues: write
|
||||
id-token: write
|
||||
|
||||
steps:
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Run Claude Code slash command
|
||||
uses: anthropics/claude-code-base-action@v1
|
||||
uses: anthropics/claude-code-action@v1
|
||||
env:
|
||||
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
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"
|
||||
|
||||
109
.github/workflows/claude-issue-triage.yml
vendored
109
.github/workflows/claude-issue-triage.yml
vendored
@@ -11,65 +11,12 @@ jobs:
|
||||
permissions:
|
||||
contents: read
|
||||
issues: write
|
||||
id-token: write
|
||||
|
||||
steps:
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Create triage prompt
|
||||
run: |
|
||||
mkdir -p /tmp/claude-prompts
|
||||
cat > /tmp/claude-prompts/triage-prompt.txt << 'EOF'
|
||||
You're an issue triage assistant for GitHub issues. Your task is to analyze the issue and select appropriate labels from the provided list.
|
||||
|
||||
IMPORTANT: Don't post any comments or messages to the issue. Your only action should be to apply labels.
|
||||
|
||||
Issue Information:
|
||||
- REPO: ${{ github.repository }}
|
||||
- ISSUE_NUMBER: ${{ github.event.issue.number }}
|
||||
|
||||
TASK OVERVIEW:
|
||||
|
||||
1. First, fetch the list of labels available in this repository by running: `gh label list`. Run exactly this command with nothing else.
|
||||
|
||||
2. Next, use the GitHub tools to get context about the issue:
|
||||
- You have access to these tools:
|
||||
- mcp__github__get_issue: Use this to retrieve the current issue's details including title, description, and existing labels
|
||||
- mcp__github__get_issue_comments: Use this to read any discussion or additional context provided in the comments
|
||||
- mcp__github__update_issue: Use this to apply labels to the issue (do not use this for commenting)
|
||||
- mcp__github__search_issues: Use this to find similar issues that might provide context for proper categorization and to identify potential duplicate issues
|
||||
- mcp__github__list_issues: Use this to understand patterns in how other issues are labeled
|
||||
- Start by using mcp__github__get_issue to get the issue details
|
||||
|
||||
3. Analyze the issue content, considering:
|
||||
- The issue title and description
|
||||
- The type of issue (bug report, feature request, question, etc.)
|
||||
- Technical areas mentioned
|
||||
- Severity or priority indicators
|
||||
- User impact
|
||||
- Components affected
|
||||
|
||||
4. Select appropriate labels from the available labels list provided above:
|
||||
- Choose labels that accurately reflect the issue's nature
|
||||
- Be specific but comprehensive
|
||||
- Select priority labels if you can determine urgency (high-priority, med-priority, or low-priority)
|
||||
- Consider platform labels (android, ios) if applicable
|
||||
- If you find similar issues using mcp__github__search_issues, consider using a "duplicate" label if appropriate. Only do so if the issue is a duplicate of another OPEN issue.
|
||||
|
||||
5. Apply the selected labels:
|
||||
- Use mcp__github__update_issue to apply your selected labels
|
||||
- DO NOT post any comments explaining your decision
|
||||
- DO NOT communicate directly with users
|
||||
- If no labels are clearly applicable, do not apply any labels
|
||||
|
||||
IMPORTANT GUIDELINES:
|
||||
- Be thorough in your analysis
|
||||
- Only select labels from the provided list above
|
||||
- DO NOT post any comments to the issue
|
||||
- Your ONLY action should be to apply labels using mcp__github__update_issue
|
||||
- It's okay to not add any labels if none are clearly applicable
|
||||
EOF
|
||||
|
||||
- name: Setup GitHub MCP Server
|
||||
run: |
|
||||
mkdir -p /tmp/mcp-config
|
||||
@@ -96,11 +43,61 @@ jobs:
|
||||
|
||||
- name: Run Claude Code for Issue Triage
|
||||
timeout-minutes: 5
|
||||
uses: anthropics/claude-code-base-action@v1
|
||||
uses: anthropics/claude-code-action@v1
|
||||
env:
|
||||
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
with:
|
||||
prompt_file: /tmp/claude-prompts/triage-prompt.txt
|
||||
github_token: ${{ secrets.GITHUB_TOKEN }}
|
||||
allowed_non_write_users: "*"
|
||||
prompt: |
|
||||
You're an issue triage assistant for GitHub issues. Your task is to analyze the issue and select appropriate labels from the provided list.
|
||||
|
||||
IMPORTANT: Don't post any comments or messages to the issue. Your only action should be to apply labels.
|
||||
|
||||
Issue Information:
|
||||
- REPO: ${{ github.repository }}
|
||||
- ISSUE_NUMBER: ${{ github.event.issue.number }}
|
||||
|
||||
TASK OVERVIEW:
|
||||
|
||||
1. First, fetch the list of labels available in this repository by running: `gh label list`. Run exactly this command with nothing else.
|
||||
|
||||
2. Next, use the GitHub tools to get context about the issue:
|
||||
- You have access to these tools:
|
||||
- mcp__github__get_issue: Use this to retrieve the current issue's details including title, description, and existing labels
|
||||
- mcp__github__get_issue_comments: Use this to read any discussion or additional context provided in the comments
|
||||
- mcp__github__update_issue: Use this to apply labels to the issue (do not use this for commenting)
|
||||
- mcp__github__search_issues: Use this to find similar issues that might provide context for proper categorization and to identify potential duplicate issues
|
||||
- mcp__github__list_issues: Use this to understand patterns in how other issues are labeled
|
||||
- Start by using mcp__github__get_issue to get the issue details
|
||||
|
||||
3. Analyze the issue content, considering:
|
||||
- The issue title and description
|
||||
- The type of issue (bug report, feature request, question, etc.)
|
||||
- Technical areas mentioned
|
||||
- Severity or priority indicators
|
||||
- User impact
|
||||
- Components affected
|
||||
|
||||
4. Select appropriate labels from the available labels list provided above:
|
||||
- Choose labels that accurately reflect the issue's nature
|
||||
- Be specific but comprehensive
|
||||
- Select priority labels if you can determine urgency (high-priority, med-priority, or low-priority)
|
||||
- Consider platform labels (android, ios) if applicable
|
||||
- If you find similar issues using mcp__github__search_issues, consider using a "duplicate" label if appropriate. Only do so if the issue is a duplicate of another OPEN issue.
|
||||
|
||||
5. Apply the selected labels:
|
||||
- Use mcp__github__update_issue to apply your selected labels
|
||||
- DO NOT post any comments explaining your decision
|
||||
- DO NOT communicate directly with users
|
||||
- If no labels are clearly applicable, do not apply any labels
|
||||
|
||||
IMPORTANT GUIDELINES:
|
||||
- Be thorough in your analysis
|
||||
- Only select labels from the provided list above
|
||||
- DO NOT post any comments to the issue
|
||||
- Your ONLY action should be to apply labels using mcp__github__update_issue
|
||||
- It's okay to not add any labels if none are clearly applicable
|
||||
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
|
||||
claude_args: |
|
||||
--model claude-sonnet-4-5-20250929
|
||||
|
||||
127
.github/workflows/oncall-triage.yml
vendored
127
.github/workflows/oncall-triage.yml
vendored
@@ -16,74 +16,12 @@ jobs:
|
||||
permissions:
|
||||
contents: read
|
||||
issues: write
|
||||
id-token: write
|
||||
|
||||
steps:
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Create oncall triage prompt
|
||||
run: |
|
||||
mkdir -p /tmp/claude-prompts
|
||||
cat > /tmp/claude-prompts/oncall-triage-prompt.txt << 'EOF'
|
||||
You're an oncall triage assistant for GitHub issues. Your task is to identify critical issues that require immediate oncall attention.
|
||||
|
||||
Important: Don't post any comments or messages to the issues. Your only action should be to apply the "oncall" label to qualifying issues.
|
||||
|
||||
Repository: ${{ github.repository }}
|
||||
|
||||
Task overview:
|
||||
1. Fetch all open issues updated in the last 3 days:
|
||||
- Use mcp__github__list_issues with:
|
||||
- state="open"
|
||||
- first=5 (fetch only 5 issues per page)
|
||||
- orderBy="UPDATED_AT"
|
||||
- direction="DESC"
|
||||
- This will give you the most recently updated issues first
|
||||
- For each page of results, check the updatedAt timestamp of each issue
|
||||
- Add issues updated within the last 3 days (72 hours) to your TODO list as you go
|
||||
- Keep paginating using the 'after' parameter until you encounter issues older than 3 days
|
||||
- Once you hit issues older than 3 days, you can stop fetching (no need to fetch all open issues)
|
||||
|
||||
2. Build your TODO list incrementally as you fetch:
|
||||
- As you fetch each page, immediately add qualifying issues to your TODO list
|
||||
- One TODO item per issue number (e.g., "Evaluate issue #123")
|
||||
- This allows you to start processing while still fetching more pages
|
||||
|
||||
3. For each issue in your TODO list:
|
||||
- Use mcp__github__get_issue to read the issue details (title, body, labels)
|
||||
- Use mcp__github__get_issue_comments to read all comments
|
||||
- Evaluate whether this issue needs the oncall label:
|
||||
a) Is it a bug? (has "bug" label or describes bug behavior)
|
||||
b) Does it have at least 50 engagements? (count comments + reactions)
|
||||
c) Is it truly blocking? Read and understand the full content to determine:
|
||||
- Does this prevent core functionality from working?
|
||||
- Can users work around it?
|
||||
- Consider severity indicators: "crash", "stuck", "frozen", "hang", "unresponsive", "cannot use", "blocked", "broken"
|
||||
- Be conservative - only flag issues that truly prevent users from getting work done
|
||||
|
||||
4. For issues that meet all criteria and do not already have the "oncall" label:
|
||||
- Use mcp__github__update_issue to add the "oncall" label
|
||||
- Do not post any comments
|
||||
- Do not remove any existing labels
|
||||
- Do not remove the "oncall" label from issues that already have it
|
||||
|
||||
Important guidelines:
|
||||
- Use the TODO list to track your progress through ALL candidate issues
|
||||
- Process issues efficiently - don't read every single issue upfront, work through your TODO list systematically
|
||||
- Be conservative in your assessment - only flag truly critical blocking issues
|
||||
- Do not post any comments to issues
|
||||
- Your only action should be to add the "oncall" label using mcp__github__update_issue
|
||||
- Mark each issue as complete in your TODO list as you process it
|
||||
|
||||
7. After processing all issues in your TODO list, provide a summary of your actions:
|
||||
- Total number of issues processed (candidate issues evaluated)
|
||||
- Number of issues that received the "oncall" label
|
||||
- For each issue that got the label: list issue number, title, and brief reason why it qualified
|
||||
- Close calls: List any issues that almost qualified but didn't quite meet the criteria (e.g., borderline blocking, had workarounds)
|
||||
- If no issues qualified, state that clearly
|
||||
- Format the summary clearly for easy reading
|
||||
EOF
|
||||
|
||||
- name: Setup GitHub MCP Server
|
||||
run: |
|
||||
mkdir -p /tmp/mcp-config
|
||||
@@ -110,11 +48,70 @@ jobs:
|
||||
|
||||
- name: Run Claude Code for Oncall Triage
|
||||
timeout-minutes: 10
|
||||
uses: anthropics/claude-code-base-action@v1
|
||||
uses: anthropics/claude-code-action@v1
|
||||
env:
|
||||
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
with:
|
||||
prompt_file: /tmp/claude-prompts/oncall-triage-prompt.txt
|
||||
github_token: ${{ secrets.GITHUB_TOKEN }}
|
||||
allowed_non_write_users: "*"
|
||||
prompt: |
|
||||
You're an oncall triage assistant for GitHub issues. Your task is to identify critical issues that require immediate oncall attention.
|
||||
|
||||
Important: Don't post any comments or messages to the issues. Your only action should be to apply the "oncall" label to qualifying issues.
|
||||
|
||||
Repository: ${{ github.repository }}
|
||||
|
||||
Task overview:
|
||||
1. Fetch all open issues updated in the last 3 days:
|
||||
- Use mcp__github__list_issues with:
|
||||
- state="open"
|
||||
- first=5 (fetch only 5 issues per page)
|
||||
- orderBy="UPDATED_AT"
|
||||
- direction="DESC"
|
||||
- This will give you the most recently updated issues first
|
||||
- For each page of results, check the updatedAt timestamp of each issue
|
||||
- Add issues updated within the last 3 days (72 hours) to your TODO list as you go
|
||||
- Keep paginating using the 'after' parameter until you encounter issues older than 3 days
|
||||
- Once you hit issues older than 3 days, you can stop fetching (no need to fetch all open issues)
|
||||
|
||||
2. Build your TODO list incrementally as you fetch:
|
||||
- As you fetch each page, immediately add qualifying issues to your TODO list
|
||||
- One TODO item per issue number (e.g., "Evaluate issue #123")
|
||||
- This allows you to start processing while still fetching more pages
|
||||
|
||||
3. For each issue in your TODO list:
|
||||
- Use mcp__github__get_issue to read the issue details (title, body, labels)
|
||||
- Use mcp__github__get_issue_comments to read all comments
|
||||
- Evaluate whether this issue needs the oncall label:
|
||||
a) Is it a bug? (has "bug" label or describes bug behavior)
|
||||
b) Does it have at least 50 engagements? (count comments + reactions)
|
||||
c) Is it truly blocking? Read and understand the full content to determine:
|
||||
- Does this prevent core functionality from working?
|
||||
- Can users work around it?
|
||||
- Consider severity indicators: "crash", "stuck", "frozen", "hang", "unresponsive", "cannot use", "blocked", "broken"
|
||||
- Be conservative - only flag issues that truly prevent users from getting work done
|
||||
|
||||
4. For issues that meet all criteria and do not already have the "oncall" label:
|
||||
- Use mcp__github__update_issue to add the "oncall" label
|
||||
- Do not post any comments
|
||||
- Do not remove any existing labels
|
||||
- Do not remove the "oncall" label from issues that already have it
|
||||
|
||||
Important guidelines:
|
||||
- Use the TODO list to track your progress through ALL candidate issues
|
||||
- Process issues efficiently - don't read every single issue upfront, work through your TODO list systematically
|
||||
- Be conservative in your assessment - only flag truly critical blocking issues
|
||||
- Do not post any comments to issues
|
||||
- Your only action should be to add the "oncall" label using mcp__github__update_issue
|
||||
- Mark each issue as complete in your TODO list as you process it
|
||||
|
||||
7. After processing all issues in your TODO list, provide a summary of your actions:
|
||||
- Total number of issues processed (candidate issues evaluated)
|
||||
- Number of issues that received the "oncall" label
|
||||
- For each issue that got the label: list issue number, title, and brief reason why it qualified
|
||||
- Close calls: List any issues that almost qualified but didn't quite meet the criteria (e.g., borderline blocking, had workarounds)
|
||||
- If no issues qualified, state that clearly
|
||||
- Format the summary clearly for easy reading
|
||||
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
|
||||
claude_args: |
|
||||
--mcp-config /tmp/mcp-config/mcp-servers.json
|
||||
|
||||
26
CHANGELOG.md
26
CHANGELOG.md
@@ -1,5 +1,31 @@
|
||||
# Changelog
|
||||
|
||||
## 2.1.11
|
||||
|
||||
- Fixed excessive MCP connection requests for HTTP/SSE transports
|
||||
|
||||
## 2.1.10
|
||||
|
||||
- Added new `Setup` hook event that can be triggered via `--init`, `--init-only`, or `--maintenance` CLI flags for repository setup and maintenance operations
|
||||
- Added keyboard shortcut 'c' to copy OAuth URL when browser doesn't open automatically during login
|
||||
- Fixed a crash when running bash commands containing heredocs with JavaScript template literals like `${index + 1}`
|
||||
- Improved startup to capture keystrokes typed before the REPL is fully ready
|
||||
- Improved file suggestions to show as removable attachments instead of inserting text when accepted
|
||||
- [VSCode] Added install count display to plugin listings
|
||||
- [VSCode] Added trust warning when installing plugins
|
||||
|
||||
## 2.1.9
|
||||
|
||||
- Added `auto:N` syntax for configuring the MCP tool search auto-enable threshold, where N is the context window percentage (0-100)
|
||||
- Added `plansDirectory` setting to customize where plan files are stored
|
||||
- Added external editor support (Ctrl+G) in AskUserQuestion "Other" input field
|
||||
- Added session URL attribution to commits and PRs created from web sessions
|
||||
- Added support for `PreToolUse` hooks to return `additionalContext` to the model
|
||||
- Added `${CLAUDE_SESSION_ID}` string substitution for skills to access the current session ID
|
||||
- Fixed long sessions with parallel tool calls failing with an API error about orphan tool_result blocks
|
||||
- Fixed MCP server reconnection hanging when cached connection promise never resolves
|
||||
- Fixed Ctrl+Z suspend not working in terminals using Kitty keyboard protocol (Ghostty, iTerm2, kitty, WezTerm)
|
||||
|
||||
## 2.1.7
|
||||
|
||||
- Added `showTurnDuration` setting to hide turn duration messages (e.g., "Cooked for 1m 6s")
|
||||
|
||||
@@ -70,5 +70,3 @@ See our [data usage policies](https://code.claude.com/docs/en/data-usage).
|
||||
We have implemented several safeguards to protect your data, including limited retention periods for sensitive information, restricted access to user session data, and clear policies against using feedback for model training.
|
||||
|
||||
For full details, please review our [Commercial Terms of Service](https://www.anthropic.com/legal/commercial-terms) and [Privacy Policy](https://www.anthropic.com/legal/privacy).
|
||||
|
||||
<!-- Test line for bug testing -->
|
||||
|
||||
@@ -6,7 +6,7 @@ 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.
|
||||
- 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:
|
||||
@@ -61,10 +61,13 @@ Note: Still review Claude generated PR's.
|
||||
If NO issues were found, post a summary comment using `gh pr comment` (if `--comment` argument is provided):
|
||||
"No issues found. Checked for bugs and CLAUDE.md compliance."
|
||||
|
||||
8. Post inline comments for each issue using `mcp__github_inline_comment__create_inline_comment`. For each comment:
|
||||
8. Create a list of all comments that you plan on leaving. This is only for you to make sure you are comfortable with the comments. Do not post this list anywhere.
|
||||
|
||||
9. Post inline comments for each issue using `mcp__github_inline_comment__create_inline_comment`. For each comment:
|
||||
- Provide a brief description of the issue
|
||||
- For small, self-contained fixes, include a committable suggestion block
|
||||
- For larger fixes (6+ lines, structural changes, or changes spanning multiple locations), describe the issue and suggested fix without a suggestion block
|
||||
- Never post a committable suggestion UNLESS committing the suggestion fixes the issue entirely. If follow up steps are required, do not leave a committable suggestion.
|
||||
|
||||
**IMPORTANT: Only post ONE comment per unique issue. Do not post duplicate comments.**
|
||||
|
||||
|
||||
Reference in New Issue
Block a user