Serendipity
1a1254f045
CI - 构建、测试和质量检查 / Rust 代码检查 (push) Has been cancelled
CI - 构建、测试和质量检查 / 单元测试 (push) Has been cancelled
CI - 构建、测试和质量检查 / 代码格式检查 (push) Has been cancelled
CI - 构建、测试和质量检查 / Clippy 代码质量检查 (push) Has been cancelled
CI - 构建、测试和质量检查 / 构建可执行文件 (claude_code_rs, macos-latest, x86_64-apple-darwin) (push) Has been cancelled
CI - 构建、测试和质量检查 / 构建可执行文件 (claude_code_rs, ubuntu-latest, x86_64-unknown-linux-gnu) (push) Has been cancelled
CI - 构建、测试和质量检查 / 构建可执行文件 (claude_code_rs.exe, windows-latest, x86_64-pc-windows-msvc) (push) Has been cancelled
- 添加 Rust GUI 桌面应用程序入口点 - 添加 TypeScript/JavaScript 项目基础结构文件 - 包含组件、工具、命令、服务和工具定义 - 添加配置文件如 .gitignore、.gitattributes 和 LICENSE - 包含图片资源和演示文件 - 为各种功能模块添加占位符和类型定义
71 lines
4.5 KiB
Markdown
71 lines
4.5 KiB
Markdown
---
|
|
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
|