Handle github issue
Skill Maples7/Apple-Dev-AI-Skills/skills/handle-github-issue
A growing catalog of installable AI skills for Swift, SwiftUI, Xcode, testing, automation, and App Store delivery.
npx -y skills add Maples7/Apple-Dev-AI-Skills --skill handle-github-issueAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Handle a GitHub issue end-to-end using disciplined code review, TDD when applicable, local verification, and structured landing workflow.
SKILL.md
4.6 KB, as published. Nobody here has run it
Handle GitHub Issue
Process any GitHub issue through a structured end-to-end workflow: read → validate → implement with TDD → review → land → cleanup.
Use this skill when you need to:
- Implement a feature or bug fix from a GitHub issue
- Ensure disciplined process (isolated changes, review gates, verification)
- Coordinate across verification, testing, landing, and issue closure
Required Workflow
1. Read and Validate
- Fetch the full issue, comments, linked PRs, and labels from GitHub
- Review the current repository code and context
- Determine if the issue is valid, actionable, and not a duplicate
- If invalid/duplicate/already fixed, comment with evidence and stop
2. Plan and Create Isolation
- Confirm the base branch (e.g.,
main,develop, a feature branch) - Plan the implementation: What code changes are needed? Are there tests to update?
- Create an isolated working branch from the base branch:
- Standard approach:
git checkout -b issue/<number> origin/<base-branch> - Advanced: If your project uses worktree tooling (e.g.,
git worktree, specialized CLI), use that instead for better isolation
- Standard approach:
- Navigate into the working branch or worktree
3. Implement with TDD (When Applicable)
- Identify if a test surface exists (unit tests, integration tests, UI tests)
- If a test exists:
- Write or update the smallest failing test case first
- Make the minimal production code change to pass that test
- Rerun the focused test and verify green
- If no test surface exists:
- Implement the feature/fix directly
- Document rationale in commit message
4. Verify Locally
- Run relevant test suites, build checks, linters, or integration tests
- Capture and report all verification output
- Ensure all checks pass before proceeding
5. Code Review and Cleanup
- Invoke
review-swarmorpre-commit-reviewon the uncommitted or staged diff - Address every actionable finding
- Resolve style, performance, security, and architectural concerns
- Verify review resolution before commit
6. Land and Push
- Commit inside the isolated branch with a clear, descriptive message
- Merge or rebase back to the base branch (use
git mergeorgit rebasedepending on your project) - Push the base branch to GitHub
- Clean up the working branch or worktree:
- Standard:
git branch -d issue/<number>orgit branch -D issue/<number> - Advanced: If you used worktree tooling, use its cleanup command
- Standard:
7. Close and Report
- Comment on the issue with:
- What changed (features/fixes implemented)
- Verification results (tests passed, lints passed, etc.)
- Review findings and how they were resolved
- Commit hash and branch/PR reference
- Close the issue (via GitHub UI or comment with
/closeif supported) - Report any blockers or cleanup issues explicitly
Key Principles
Validate before committing: Always run review and verification BEFORE landing.
Isolated changes: Use branches or worktrees to isolate work from the mainline, preventing accidental interference.
TDD when applicable: If a test surface exists, prioritize writing the test first. If not, implement directly and document why.
Transparent communication: Every step produces reportable evidence (test output, review results, commit hash).
Cleanup discipline: Remove temporary worktrees or branches to keep the repository clean.
When to Stop
Stop early and comment on the issue if any of these are true:
- The issue is a duplicate of another (link the canonical issue)
- The issue is already fixed (cite the commit/PR)
- The issue is invalid or lacks sufficient detail to implement
- The issue requests unsafe or policy-violating behavior
- The verification or review discovers a fundamental blocker
Adapting to Your Project
Projects may customize this workflow via:
- Test framework: XCTest, Swift Testing, Jest, pytest, Vitest, etc.
- Verification tools: SwiftFormat, SwiftLint, cargo test, npm run test, eslint, etc.
- Branch isolation: Standard
git checkout -b, or advanced worktree tools (git worktreeor project-specific CLI) - Review gates: Pre-commit reviews, code review automation, linting, or static analysis
- Base branch strategy:
main,develop, release branches, or other branch hierarchies
Read your project's contribution guide or CONTRIBUTING.md for specifics.
References
See GitHub Issue Agent Workflow for a step-by-step checklist.