resolve-issues
Streamlines issue resolution via isolated development environments and test-driven development.
Install
mkdir -p .claude/skills/resolve-issues && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/9087" && unzip -o skill.zip -d .claude/skills/resolve-issues && rm skill.zipInstalls to .claude/skills/resolve-issues
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Resolves GitHub issues using isolated worktrees and test-driven development. This skill should be used when the user asks to "resolve an issue", "fix issue #123", or needs to implement a solution for a specific GitHub ticket using a structured workflow.Key capabilities
- →Create isolated git worktrees for specific issues
- →Rename git branches to standard project conventions
- →Enforce TDD lifecycle (RED-GREEN-REFACTOR)
- →List and filter GitHub issues via CLI
- →Automate PR reference via commit keywords
How it works
It orchestrates git worktree commands to create side-effect-free development environments and enforces a testing-first workflow.
Inputs & outputs
When to use resolve-issues
- →Fixing GitHub issues
- →Structuring pull requests
- →Isolated feature development
About this skill
Resolve GitHub Issues
Execute issue resolution workflow using isolated worktrees, TDD methodology, and agent collaboration.
Context
- Current git status: !
git status - Current branch: !
git branch --show-current - Existing worktrees: !
git worktree list - Open issues: !
gh issue list --state open --limit 10 - GitHub authentication: !
gh auth status
Requirements Summary
Use isolated worktrees to avoid disrupting main development. Follow TDD cycle (red → green → refactor) with agent support. Reference issues in commits using auto-closing keywords. See references/requirements.md for protected PR workflow and commit standards.
Phase 1: Issue Selection and Worktree Setup
Goal: Select target issue and prepare isolated development environment.
Actions:
- Review open issues from context and select based on priority and
$ARGUMENTS - Check existing worktrees to determine if reuse is possible
- Use the EnterWorktree tool with a descriptive name (e.g.,
fix-456-auth-redirect) to create an isolated session - Rename the auto-generated branch to match conventions: run
git branch -m <type>/<issue>-<description>(seereferences/workflow-details.mdfor naming) - Verify issue acceptance criteria and dependencies
Phase 2: TDD Implementation
Goal: Implement fix using test-driven development with agent collaboration.
Actions:
- Plan implementation approach and assess architectural impact
- Write failing tests that verify issue is resolved (RED phase)
- Implement minimal code to make tests pass (GREEN phase)
- Refactor while keeping tests green (REFACTOR phase)
- Run quality validation commands to keep the TDD cycle honest (see
references/workflow-details.mdfor project-specific checks)./github:create-prre-runs the full gate in Phase 3 and is the authoritative pre-PR check.
Phase 3: PR Creation and Cleanup
Goal: Hand PR creation to /github:create-pr so the quality gate and the review loop run. Cleanup happens only after the merge, which may be many turns later.
Actions:
- Push branch to remote with
git push -u origin <branch-name> - CRITICAL: Do NOT call
gh pr createhere. InvokeSkill("github:create-pr", "<issue reference>")— e.g.Skill("github:create-pr", "Closes #456"). It is the plugin's only PR-creating path and owns the quality/security gate, the auto-closing-keyword linkage, the non-default-branch warning, and the mandatory/github:review-prhandoff. Seereferences/pr-creation-handoff.mdfor the full contract. Creating the PR directly skips all of it.- Append
--draftto the arguments if the fix requires further feedback before review - Append
--no-monitoronly when the user explicitly opts out of the review loop
- Append
- This skill does not resume here.
/github:create-prreports the PR URL, and/github:review-prthen owns the PR for the rest of its life: a persistent Monitor spanning turns, the triage/fix/push rounds, and the merge decision it asks the user to make. Do NOT wait inline, do NOT re-report the URL, and do NOT run Phase 4 speculatively.
Phase 4: Post-Merge Cleanup (later turn, fallback)
Trigger: The PR from Phase 3 has actually merged — normally a later turn, after /github:review-pr completed its merge decision. /github:review-pr's closeout now owns the post-merge cleanup (worktree removal via ExitWorktree action:"remove", switch to main, sync with origin), so this Phase runs only as a fallback when that cleanup was skipped: the user chose "Don't merge", an interrupt left the worktree behind, or this is a fresh session that cannot ExitWorktree the worktree created by an earlier session. Never assume the worktree is gone — verify first.
Actions:
- Verify the merge with
gh pr view <PR#> --json state -q .statereturningMERGED; never assume. - Check
git worktree listwhether the issue worktree still exists. If/github:review-pralready removed it, skip straight togit fetch --prune. - If it persists: CRITICAL: confirm still on the issue branch before
ExitWorktree action:"remove". If checkout drifted ontomain/develop, stop — removing would delete a long-lived branch. Remote head may already be gone; that is fine. - Use the ExitWorktree tool with action "remove" to clean up worktree and branch.
- If uncommitted changes exist, ExitWorktree refuses; confirm with the user before setting
discard_changes: true
- If uncommitted changes exist, ExitWorktree refuses; confirm with the user before setting
git fetch --pruneto sync remote-tracking branches.- Document resolution and any follow-up tasks
References
- Requirements:
references/requirements.md- Worktree setup, TDD, and commit standards - PR Creation Handoff:
references/pr-creation-handoff.md- Why PRs delegate to /github:create-pr - Workflow Details:
references/workflow-details.md- Issue selection, TDD cycle, agent collaboration - Quality Validation:
references/quality-validation.md- Node.js/Python validation commands (shared) - Examples:
references/examples.md- Commit message examples
When not to use it
- →Quick documentation fixes requiring no testing
- →Refactoring that spans across multiple existing branch contexts
- →Projects without an existing test suite
Prerequisites
Limitations
- →Requires familiarity with git worktree concepts
- →Dependent on an existing and functional project test suite
How it compares
It maintains workspace hygiene by ensuring no unfinished work bleeds into the main branch, forcing strict test coverage before completion.
Compared to similar skills
resolve-issues side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| resolve-issues (this skill) | 0 | 3mo | Review | Intermediate |
| dependency-upgrade | 26 | 5mo | Review | Intermediate |
| finishing-a-development-branch | 4 | 3mo | Review | Beginner |
| positron-pr-helper | 1 | 3mo | Review | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by FradSer
View all by FradSer →You might also like
dependency-upgrade
wshobson
Manage major dependency version upgrades with compatibility analysis, staged rollout, and comprehensive testing. Use when upgrading framework versions, updating major dependencies, or managing breaking changes in libraries.
finishing-a-development-branch
obra
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
positron-pr-helper
posit-dev
Generates well-structured PR bodies with dynamically fetched e2e test tags
workflow-patterns
wshobson
Use this skill when implementing tasks according to Conductor's TDD workflow, handling phase checkpoints, managing git commits for tasks, or understanding the verification protocol.
mflux-pr
filipstrand
Make a clean PR in mflux (inspect diff, quick verification, commit, push, open PR) using repo conventions.
resolve-checks
flowglad
Resolve all failing CI checks and address PR review feedback on the current branch's PR. Runs tests locally, fixes failures, incorporates valid review comments, and resolves addressed feedback. Use when CI is red, after receiving PR feedback, or before merging.