Use when executing an implementation plan from a GitHub Project board, committing directly to main with Closes trailers.
Use when executing an implementation plan from a GitHub Project board, committing directly to main with Closes trailers.
npx skills add https://github.com/dnldxn/claptrap --skill gh-implement复制此命令并粘贴到 Claude Code 中以安装该技能
Use when starting a new design or spec to interview the user, answer open questions, and draft a specification.
Use when starting a new design/spec that should be saved as a GitHub Issue on the Project board after user approval.
Use when breaking a GitHub spec issue into implementation plan sub-issues on the Project board, optionally updating the spec issue body with meaningful new constraints or decisions.
Use when a Claptrap workflow needs to update or resync `.planning/state.html` after spec, plan, implementation, review, merge, or archive changes.
Use when you have a written plan and are ready to execute it in the current workspace.
Use when writing implementation plans after a design or spec has been approved.
| name | gh-implement |
| description | Use when executing an implementation plan from a GitHub Project board, committing directly to main with Closes trailers. |
OPERATION OVERRIDE: The instructions in this file take precedence over conflicting instructions in any other Skills.
REQUIRED SUB-SKILLS: Use subagent-driven-development. On implementation, test, push, or status-update failure, use systematic-debugging. Before the final commit, use requesting-code-review.
Work from the target repository root so scripts and gh commands detect the correct GitHub repo. Use absolute paths to this skill when the target repo does not contain skills/github-projects/gh-implement/.
Safe script paths from the target repo root:
uv run <path-to-this-skill>/scripts/gh_state.pyuv run <path-to-this-skill>/scripts/gh_status_set.py --issue <number> --status "In progress"Check board state first with uv run <path-to-this-skill>/scripts/gh_state.py. Confirm selected plan(s) with the user before changing status or code. The user may give a spec number or a plan number.
Preflight direct-main safety before status or code changes: verify git branch --show-current is main, run git status --short, inspect git diff, and note any unrelated dirty files that must not be staged. If remote sync matters, run git fetch and verify main is not behind before committing.
Set status. If the parent spec is Backlog or Up Next, set the spec to In progress with gh_status_set.py. Set each selected plan to In progress before implementing it.
Read the plan issue body: gh issue view <plan-number> --json body --jq .body. Use subagent-driven-development step by step against the plan body.
Before the final commit, re-run git status --short and git diff, stage only files for the implemented plan, and leave unrelated user changes untouched.
Commit directly to main; do not create branches or PRs. Use this commit format:
<subject>
<body>
Closes #<plan>
Refs #<spec>
After the commit pushes successfully, set the plan to Done with gh_status_set.py.
If all plans for the spec are complete, prompt before closing the spec issue and setting the spec to Done.
Dispatch modes:
gh api repos/{owner}/{repo}/issues/{spec}/sub_issues --jq '.[].number', sort by issue number, and implement all open plans in that order.If a command reports missing project scopes, run gh auth refresh -s project,read:project, then retry.
main, after checking status/diff, and after staging only intended files.Done until the commit has pushed successfully.systematic-debugging before retrying.