Issue Triage

Triage a newly opened GitHub issue on this project (a Rust CLI tool for managing git worktrees).

Issue to triage: $ARGUMENTS

Step 1: Setup

Load /running-in-ci first (CI environment rules, security).

Follow the AD FONTES principle throughout: reproduce before fixing, evidence before speculation, test before committing.

Step 2: Read and classify the issue

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. Descriptions of changed behavior ("no longer works", "used to work") strongly signal a bug even with a terse body.
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

Step 3: Check for duplicates

Skip for questions and other.

# Search open issues for similar problems
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-*'

# Check open PRs
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 7. Don't create a duplicate fix.

Step 4: Investigate existing functionality

Feature requests only.

Search the codebase to check whether the requested feature already exists.

Extract the core ask — What specific behavior does the requester want?
Search for implementations — Grep for relevant function names, config keys, CLI flags, and domain terms in src/, src/cli/, docs/, and config.
Read key files — If searches find hits, read the relevant source to understand what already exists and how it works.
Check docs and help text — Look for user-facing documentation of the feature (--help, docs/content/, config reference).

Record what you found (or didn't find) for use in step 7.

Step 5: Reproduce the bug

Bug reports only.

Understand the report — What command was run? What was expected? What actually happened?
Find relevant code — Search the codebase for the functionality described
Write a failing test — Add a test to the appropriate existing test file that demonstrates the bug. Don't create new test files.

Run the test to confirm it fails:

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

Step 6: Fix (conservative)

Bug reports only.

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

If fixing

Fix the root cause (not just the symptom)
Confirm the test now passes
Run the full test suite and lints:
```
cargo run -- hook pre-merge --yes
```

Create branch, commit, push, and create PR:

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"

Monitor CI until green:
```
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.

If reproduction test works but fix is not confident

Commit just the failing test on a reproduction branch and open a PR:

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.

Step 7: Comment on the 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:

Fix PR created

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.

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.

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.

Bug already fixed

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.

Feature may already exist

Thanks for the suggestion! It's possible that [existing feature — specific behavior, config/flag] already does what you're looking for: [brief description of how it works].

If that's not quite what you had in mind, could you clarify what additional behavior you're looking for? A maintainer will take a look either way.

Feature does not exist

Thanks for the suggestion! I searched the codebase and didn't find an existing implementation of this. [Optionally: the closest related functionality is X, which does Y.]

I'll leave it for a maintainer to evaluate and prioritize.

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.

Duplicate

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