# Implement Github Issue > Implement a GitHub issue end to end. Use when Codex is asked to take a GitHub issue, issue URL, or issue number, read the issue and comments, gather repository context, make the code change, run validation, review the diff, and create a pull request. - **Type:** Skill - **Install:** `agentstack add skill-bambam955-skills-implement-github-issue` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [bambam955](https://agentstack.voostack.com/s/bambam955) - **Installs:** 0 - **Category:** [Developer Tools](https://agentstack.voostack.com/c/developer-tools) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [bambam955](https://github.com/bambam955) - **Source:** https://github.com/bambam955/skills/tree/main/skills/workflow/implement-github-issue ## Install ```sh agentstack add skill-bambam955-skills-implement-github-issue ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Implement GitHub Issue Turn a GitHub issue into a reviewed pull request. Start from the issue, build only the context needed to implement it, validate the change, review your own diff critically, and open the PR only when the branch is in a defensible state. ## Invocation - Treat a bare number after the skill name as the GitHub issue number in the current repository. - Example: `$implement-github-issue 56` means to implement issue `56`. ## Workflow ### 1. Read the issue - Fetch the issue title, description, comments, labels, and linked references with `gh issue view`. - Extract acceptance criteria, constraints, rollout notes, and ambiguity that could change implementation. - If the issue is thin, inspect linked code, pull requests, or nearby docs before asking the user. ### 2. Build context - Check the working tree first with `git status --short`; do not overwrite unrelated local changes. - Use `rg` to find the relevant code paths, tests, feature flags, config, and recent history. - Read the smallest set of files that explains the current behavior and the expected change. - Ask the user only when a product decision or acceptance criterion cannot be inferred from the issue or code. ### 3. Prepare the branch - Stay on the current branch if it is already the intended feature branch. - Otherwise create a branch named `-`. - Keep the branch scoped to the issue. Avoid opportunistic cleanup unless it is required for the fix. ### 4. Implement - Make the code changes directly unless the user explicitly asked for design or planning first. - Match the repository's conventions for architecture, naming, formatting, tests, and commit messages. - Add or update tests when behavior changes. If test coverage is not practical, record why. - Work carefully in dirty trees and preserve existing user changes. ### 5. Validate - Run the narrowest useful checks first, then broaden only as needed. - Prefer repository-native test, lint, and build commands. - Fix failures, flaky assumptions, and generated diffs before moving on. - If a required validation step cannot run, capture the exact reason and resulting risk. ### 6. Review your own diff - Read the diff as a reviewer, not the author. - Check for correctness, regressions, missing tests, edge cases, naming problems, and accidental scope growth. - Tighten the code, tests, or docs before opening the PR. - Confirm `git status` is clean except for intentional changes. ### 7. Commit, push, and open the PR - Create logical commits with Conventional Commit messages. - Push the branch and create the pull request with `gh pr create`. - Write a PR title and description that reference the issue and always include: `## Summary` `## Testing` - The testing steps should be in checklist form so that reviewers can make clear to an author what worked and didn't work for them. - Create a draft PR instead of a ready PR when validation is incomplete or open questions remain. ## Operating Rules - Prefer `gh` for issue and pull request operations. - Prefer `rg` for repository search and gather only the context needed for the task. - Always use Conventional Commit messages for commits created during this workflow. - Never overwrite unrelated local changes or revert work you did not make. - Never open a ready PR with known failing validation unless the user explicitly wants a draft for early feedback. - Surface blockers early when credentials, permissions, CI failures, or missing product decisions prevent completion. ## Pull Request Checklist - The implementation matches the issue's acceptance criteria. - The diff is scoped, readable, and limited to intentional changes. - Validation covers the changed behavior well enough for the repository. - The branch name follows `-`. - Every commit uses Conventional Commits. - The branch is pushed and the PR description includes `## Summary` and `## Testing`. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [bambam955](https://github.com/bambam955) - **Source:** [bambam955/skills](https://github.com/bambam955/skills) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-bambam955-skills-implement-github-issue - Seller: https://agentstack.voostack.com/s/bambam955 - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.