Back to Details

issue-triage

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Issue Triage

Issue自动分类处理

Triage a newly opened GitHub issue on this project (a Rust CLI tool for managing git worktrees).
Issue to triage: $ARGUMENTS
对本项目（一款用于管理git工作区的Rust CLI工具）中新创建的GitHub Issue进行分类处理。
待处理的Issue： $ARGUMENTS

Step 1: Setup

步骤1：环境准备

Load 
/running-in-ci
first (CI environment rules, security).
Follow the AD FONTES principle throughout: reproduce before fixing, evidence before speculation, test before committing.
首先加载
/running-in-ci
（CI环境规则、安全相关）。
全程遵循AD FONTES原则：先复现再修复，先有证据再推测，先测试再提交。

Step 2: Read and classify the issue

步骤2：阅读并分类Issue

bash
gh issue view $ARGUMENTS --json title,body,labels,author
Classify into one of:
  • Bug report — describes unexpected behavior, includes steps to reproduce or error output
  • Feature request — asks for new functionality or behavior changes
  • Question — asks how to do something or how something works
  • Other — doesn't fit the above categories
If not a bug report, skip to step 6 (comment only).
bash
gh issue view $ARGUMENTS --json title,body,labels,author
将Issue分为以下类别之一：
  • Bug报告 —— 描述意外行为，包含复现步骤或错误输出
  • 功能请求 —— 要求新增功能或修改现有行为
  • 疑问咨询 —— 询问如何操作或功能原理
  • 其他 —— 不符合上述类别的情况
若不是Bug报告，直接跳至步骤6（仅添加评论）。

Step 3: Check for duplicates

步骤3：检查重复项

Before doing any work, check if this issue is already being addressed:
bash
undefined
在开展任何工作前，检查该Issue是否已有相关处理：
bash
undefined

Search open issues for similar problems

搜索相似的开放Issue

gh issue list --state open --json number,title,labels --limit 50
gh issue list --state open --json number,title,labels --limit 50

Check for existing fix branches

检查是否存在已有的修复分支

git branch -r --list 'origin/fix/issue-' git branch -r --list 'origin/repro/issue-'
git branch -r --list 'origin/fix/issue-' git branch -r --list 'origin/repro/issue-'

Check open PRs

检查开放的PR

gh pr list --state open --json number,title,headRefName --limit 50

If a duplicate or existing fix is found, note it for the comment in step 6.
Don't create a duplicate fix.
gh pr list --state open --json number,title,headRefName --limit 50

若发现重复项或已有修复，在步骤6的评论中注明。请勿创建重复修复。

Step 4: Reproduce the bug

步骤4：复现Bug

Follow the AD FONTES principle — reproduce before fixing:
  1. Understand the report — What command was run? What was expected? What actually happened?
  2. Find relevant code — Search the codebase for the functionality described
  3. Write a failing test — Add a test to the appropriate existing test file that demonstrates the bug. Don't create new test files.
  4. Run the test to confirm it fails:
    bash
    cargo test --lib --bins -- test_name
# or for integration tests:
cargo test --test integration -- test_name
If the test passes (bug may already be fixed), note this for the comment.
If you cannot reproduce the bug (unclear steps, environment-specific, etc.), note what you tried and skip to step 6.
遵循AD FONTES原则——先复现再修复：
  1. 理解报告内容 —— 执行了什么命令？预期结果是什么？实际发生了什么？
  2. 定位相关代码 —— 在代码库中搜索相关功能的实现
  3. 编写失败测试 —— 在合适的现有测试文件中添加一个能复现Bug的测试。请勿创建新的测试文件。
  4. 运行测试以确认失败：
    bash
    cargo test --lib --bins -- test_name
# 或针对集成测试：
cargo test --test integration -- test_name
若测试通过（Bug可能已被修复），在评论中注明此情况。
若无法复现Bug（步骤不明确、环境特定等），记录尝试的操作并跳至步骤6。

Step 5: Fix (conservative)

步骤5：保守修复

Only attempt a fix if ALL of these conditions are met:
  • Bug is clearly reproducible (test fails)
  • Root cause is understood
  • Fix is localized (1-3 files changed)
  • Confident the fix is correct
仅当满足以下所有条件时，才尝试修复：
  • Bug可明确复现（测试失败）
  • 已找到根本原因
  • 修复范围局限（仅修改1-3个文件）
  • 确认修复方案正确

If fixing

若进行修复

  1. Fix the root cause (not just the symptom)
  2. Confirm the test now passes
  3. Run the full test suite and lints:
    bash
    cargo run -- hook pre-merge --yes
  4. Create branch, commit, push, and create PR:
    bash
    git checkout -b fix/issue-$ARGUMENTS
git add -A
git commit -m "fix: <description>

Closes #$ARGUMENTS

Co-authored-by: Claude <noreply@anthropic.com>"
git push -u origin fix/issue-$ARGUMENTS
gh pr create --title "fix: <description>" --label "automated-fix" --body "## Problem
[What the issue reported and the root cause]

## Solution
[What was fixed and why]

## Testing
[How the fix was verified — mention the reproduction test]

---
Closes #<issue-number> — automated triage"
  5. Monitor CI until green:
    bash
    gh run list --branch fix/issue-$ARGUMENTS
gh run watch
    If CI fails, diagnose with 
    gh run view <run-id> --log-failed
    , fix, and repeat.
  1. 修复根本原因（而非仅解决表面症状）
  2. 确认测试现在可通过
  3. 运行完整测试套件和代码检查：
    bash
    cargo run -- hook pre-merge --yes
  4. 创建分支、提交、推送并创建PR：
    bash
    git checkout -b fix/issue-$ARGUMENTS
git add -A
git commit -m "fix: <描述>

Closes #$ARGUMENTS

Co-authored-by: Claude <noreply@anthropic.com>"
git push -u origin fix/issue-$ARGUMENTS
gh pr create --title "fix: <描述>" --label "automated-fix" --body "## 问题
[Issue报告的内容及根本原因]

## 解决方案
[修复的内容及原因]

## 测试
[修复的验证方式——提及复现测试]

---
Closes #<issue编号> —— 自动分类处理"
  5. 监控CI直到通过：
    bash
    gh run list --branch fix/issue-$ARGUMENTS
gh run watch
    若CI失败，使用
    gh run view <run-id> --log-failed
    诊断问题，修复后重复上述步骤。

If reproduction test works but fix is not confident

若复现测试可用但修复方案不确定

Commit just the failing test on a reproduction branch and open a PR:
bash
git checkout -b repro/issue-$ARGUMENTS
git add -A
git commit -m "test: add reproduction for #$ARGUMENTS

Co-authored-by: Claude <noreply@anthropic.com>"
git push -u origin repro/issue-$ARGUMENTS
gh pr create --title "test: reproduction for #$ARGUMENTS" --label "automated-fix" --body "## Context
Adds a failing test that reproduces #$ARGUMENTS. The fix is not yet included —
this PR captures the reproduction so a maintainer can investigate.

---
Automated triage for #<issue-number>"
Note the PR number for the comment.
仅将失败测试提交到复现分支并创建PR：
bash
git checkout -b repro/issue-$ARGUMENTS
git add -A
git commit -m "test: 为#$ARGUMENTS添加复现测试

Co-authored-by: Claude <noreply@anthropic.com>"
git push -u origin repro/issue-$ARGUMENTS
gh pr create --title "test: 为#$ARGUMENTS添加复现测试" --label "automated-fix" --body "## 背景
添加了一个能复现#$ARGUMENTS的失败测试。尚未包含修复方案——
此PR用于记录复现步骤，以便维护人员进一步调查。

---
针对#<issue编号>的自动分类处理"
在评论中注明PR编号。

Step 6: Comment on the issue

步骤6：在Issue下添加评论

Always comment via 
gh issue comment
. Keep it brief, polite, and specific. A maintainer will always review — never claim the issue is fully resolved by automation alone.
Stay within what you verified. State facts you found in the codebase — don't characterize something as "known" unless you find prior issues or documentation about it. Don't speculate beyond the code you read. Follow the templates below closely; they are deliberately scoped to leave authoritative analysis to maintainers.
Use the heredoc pattern from 
/running-in-ci
for 
--body
arguments to avoid shell quoting issues (e.g., 
!
getting escaped as 
\!
).
Choose the appropriate template:
始终通过
gh issue comment
添加评论。评论需简洁、礼貌且具体。维护人员会进行审核——绝不声称自动化已完全解决Issue。
仅基于已验证的内容发言。陈述在代码库中发现的事实——除非找到相关的历史Issue或文档，否则不要将某件事描述为“已知”。不要超出所阅读代码的范围进行推测。严格遵循以下模板；这些模板的范围经过刻意限定，以便维护人员进行权威分析。
使用
/running-in-ci
中的heredoc模式处理
--body
参数，避免shell引用问题（例如
!
被转义为
\!
）。
选择合适的模板：

Fix PR created

已创建修复PR

Thanks for reporting this! I was able to reproduce the issue and identified the root cause: [one-sentence explanation].
I've opened #PR_NUMBER with a fix. A maintainer will review it shortly.
感谢您的报告！我已成功复现该问题并找到根本原因：[一句话解释]。
我已创建#PR_NUMBER PR提交修复方案。维护人员将很快进行审核。

Reproduction test only (no fix attempted)

仅添加复现测试（未尝试修复）

Thanks for reporting this! I was able to reproduce the issue — #PR_NUMBER adds a failing test that demonstrates the bug.
Root cause appears to be [brief explanation if known, or "still under investigation"]. A maintainer will take a closer look.
感谢您的报告！我已成功复现该问题——#PR_NUMBER添加了一个能展示Bug的失败测试。
根本原因似乎是[若已知则简要说明，否则填“仍在调查中”]。维护人员将进一步查看。

Could not reproduce

无法复现

Thanks for reporting this! I tried to reproduce this but wasn't able to with the information provided.
Could you share [specific information needed — exact command, config file, git repo structure, OS, shell, etc.]? That would help narrow it down.
A maintainer will also take a look.
感谢您的报告！我尝试复现该问题，但根据提供的信息未能成功。
能否分享[所需的具体信息——准确命令、配置文件、git仓库结构、操作系统、Shell等]？这将有助于缩小问题范围。
维护人员也会查看此Issue。

Bug already fixed

Bug已被修复

Thanks for reporting this! I looked into this and it appears the behavior described may already be fixed on 
main
(the relevant test passes).
Could you confirm which version you're running (
wt --version
)? If you're on an older release, updating should resolve this. A maintainer will confirm.
感谢您的报告！我对此进行了调查，发现描述的行为在
main
分支上可能已被修复（相关测试通过）。
能否确认您使用的版本（
wt --version
）？若您使用的是旧版本，更新后问题应能解决。维护人员将进行确认。

Feature request

功能请求

Thanks for the suggestion! This is a feature request rather than a bug, so I'll leave it for a maintainer to evaluate and prioritize.
感谢您的建议！这是一个功能请求而非Bug，我将留待维护人员评估和排期。

Question

疑问咨询

Thanks for reaching out! This looks like a usage question rather than a bug report.
[Brief answer if obvious from the codebase, or pointer to relevant docs/help text.]
A maintainer can provide more detail if needed.
感谢您的提问！这看起来是使用问题而非Bug报告。
[若从代码库中可找到明确答案则简要回答，或指向相关文档/帮助文本。]
若需要更多细节，维护人员可提供进一步说明。

Duplicate

重复Issue

Thanks for reporting this! This appears to be related to #EXISTING_ISSUE [and/or PR #EXISTING_PR]. I'll leave it to a maintainer to confirm and link them.
感谢您的报告！此Issue似乎与#EXISTING_ISSUE[和/或PR #EXISTING_PR]相关。我将留待维护人员确认并关联它们。"