Agent skill
implement-ticket
Implements a planned GitHub issue by following the implementation plan. Takes a GitHub issue number. Use when the user wants to implement a ticket, work on an issue, or says "implement ticket X" or "do issue
Install this agent skill to your Project
npx add-skill https://github.com/josh-gree/my-claude-skills/tree/main/skills/implement-ticket
SKILL.md
Implement Ticket
Purpose
Execute the implementation plan for a ticket. Follow the plan step by step, then close the ticket when done.
Prerequisites
The ticket MUST have an implementation plan. If no plan exists, tell the user to run /plan-ticket first.
Workflow
Step 1: Verify Environment
Check we have a GitHub remote and are on a clean, up-to-date main/master:
git remote -v
git status
git fetch origin
git rev-parse --abbrev-ref HEAD
git status -uno
STOP if:
- No remote exists → "This skill requires a GitHub remote. Please add one with
git remote add origin <url>first." - Not on main/master → "Please switch to main/master first:
git checkout main" - Uncommitted changes → "Please commit or stash your changes first."
- Behind remote → "Please pull latest changes:
git pull"
Step 2: Identify the Ticket
User will provide a GitHub issue number (e.g., #12 or 12).
If not clear, ask which ticket to implement.
Step 3: Setup Working Branch
Ask the user: "Do you want to use a worktree (allows parallel work on other tickets) or branch in place?"
Option A: Worktree (recommended for parallel work)
Use the /worktree create <branch-name> skill to create an isolated working directory.
Benefits:
- Can work on multiple tickets simultaneously
- Main repo stays on main/master
- Easy to context-switch between tickets
Branch name format: <issue-number>-<short-description>
e.g., 12-add-rate-limiting
Option B: Branch in place
Standard approach, switches the current repo to a new branch:
git checkout main && git pull
git checkout -b <branch-name>
Only proceed once in a clean, ticket-specific environment.
Step 4: Read Ticket and Plan
gh issue view <number> --comments
Extract:
- The original intent (Summary section)
- The implementation plan (Steps)
- The success criteria
If no implementation plan exists, STOP and tell user to run /plan-ticket first.
Step 5: Execute the Plan
Work through each step in the plan:
- Read the step
- Implement it
- Verify it works
- Move to next step
Use the TodoWrite tool to track progress through the steps.
If you hit a blocker:
- Ask the user how to proceed
- Document the issue
- Don't skip steps without user approval
Step 6: Verify Success Criteria
Go through each success criterion and verify it's met:
- Run tests if mentioned
- Check behaviour manually if needed
- Confirm each criterion is satisfied
Step 7: Create PR
Commit and push (already on ticket branch from Step 3):
git add .
git commit -m "<summary of changes>"
git push -u origin HEAD
gh pr create --title "<title>" --body "$(cat <<'EOF'
## Summary
<Brief summary of what was done>
Closes #<issue-number>
EOF
)"
The Closes #<number> will auto-close the issue when PR is merged.
Step 8: Request Review
Tell the user:
- What was implemented
- Any deviations from the plan
- PR URL
Ask them to review and merge the PR. Wait for their confirmation that it's been merged.
Step 9: Clean Up (if using worktree)
Once the user says the PR is ready to clean up:
-
Verify PR is merged
bashgh pr view <pr-number> --json state,mergedAtSTOP if PR is not merged. Tell the user the PR is still open and ask if they want to wait or cancel cleanup.
-
Return to main repo
bashcd <main-repo-path> git fetch origin git checkout main && git pull -
Remove the worktree Use
/worktree clean <branch-name>to remove the worktree and delete the branch. -
Confirm cleanup Report that the worktree has been removed and the ticket workflow is complete.
Guidelines
DO:
- Follow the plan in order
- Verify each step works before moving on
- Ask if something is unclear or blocked
- Run tests frequently
- Commit logical chunks of work
DON'T:
- Implement on main/master branch
- Implement on another ticket's branch
- Start work with uncommitted changes
- Skip steps without asking
- Deviate significantly from the plan without discussing
- Leave tests failing
- Create PR if success criteria aren't met
Handling Issues
Plan step is unclear: Ask the user for clarification before proceeding.
Step doesn't work as expected: Debug and fix if straightforward, otherwise ask user.
Plan is missing something: Point it out, ask if you should add it or proceed without.
Tests fail: Fix them before continuing. If you can't, ask user.
Checklist
- Verify GitHub remote exists and on clean, up-to-date main/master
- Identify which issue to implement
- Ask user: worktree or branch in place?
- Setup working environment (worktree or branch)
- Read issue and extract plan
- Verify plan exists (if not, stop)
- Execute each step in order
- Verify all success criteria
- Create PR with "Closes #X"
- Request review from user
- Wait for user to confirm ready for cleanup
- Verify PR is merged before cleanup
- Clean up worktree (if used)
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
address-pr-comments
Addresses PR review comments by making code changes and posting replies. Takes a PR number or auto-detects from current branch. Use when the user wants to address review feedback, respond to PR comments, fix PR feedback, or says "address comments on PR X".
create-ticket
Creates GitHub issues to capture work that needs to be done. Records intent with context about the codebase, not implementation plans. Use when the user wants to track work, create a ticket, log a task, or says "we want to do X" or "we need to X".
review
Review code using Google's code review principles. Use for ad-hoc file review or as the foundation for PR and codebase reviews.
setup-python-lib
Sets up a new Python library project using uv in the current directory. Creates project structure, installs dev dependencies, and optionally configures git remote. Use when the user wants to initialise a Python library, package, or project with uv.
refine-plan
Refines an existing implementation plan through discussion with the user. Takes a GitHub issue number. Use when the user wants to refine a plan, discuss a plan, change a plan, or says "refine plan X" or "let's discuss the plan for issue
review-pr
Review a pull request using Google's code review principles. Takes a PR number or auto-detects from current branch. Use when the user wants to review a PR, check PR changes, or says "/review-pr 123".
Didn't find tool you were looking for?