| name | git-push-and-tag |
| description | Final-phase skill that stages beads, commits, pushes to the remote branch, and labels the GitHub issue as "Ready". Invoked by issue-to-beads as the last step after all beads have been filed, reviewed, and synced. Can also be used standalone when you have synced beads on an issue branch that need to be committed and pushed. |
| context | fork |
Git Push and Tag
Stages the .beads/ directory, commits, pushes the branch, and labels the corresponding GitHub issue as "Ready". This is the final step in the issue-to-beads workflow.
Prerequisites
- Must be on an issue branch (pattern:
<issue-number>-<slug>)
- Beads must already be synced (
bd sync has been run or will be run here)
- The
gh CLI must be authenticated for the target GitHub repo
- The
bd CLI must be available on PATH
- The
.beads/ directory must exist with filed beads
Workflow
Step 1: Pull latest changes
git pull --rebase
If this fails due to conflicts, stop and ask the user how to resolve them.
Step 2: Sync beads
bd sync
This ensures the JSONL index is up to date with the beads on disk.
Step 3: Stage the beads directory
git add .beads/
git add .plan/
Stage .beads/ (the filed beads) and .plan/ (the approved plan artifact). Do not stage unrelated changes. If there are other files that should be committed, ask the user before staging them.
Step 4: Commit
Infer the issue number and title from the current branch name. The branch follows the pattern <issue-number>-<slug> (e.g., 42-add-user-authentication).
git rev-parse --abbrev-ref HEAD
git commit -m "Add beads for issue #<number>: <title-from-slug>"
Replace <number> with the issue number extracted from the branch name, and <title-from-slug> with the slug portion converted back to readable text (hyphens to spaces).
Step 5: Push
git push -u origin <branch-name>
If the push fails (e.g., due to remote changes), try:
git pull --rebase
git push -u origin <branch-name>
If it still fails, stop and ask the user for help.
Step 6: Label the GitHub issue
Confirm the issue number with the user before labeling:
I inferred issue #<number> from branch <branch-name>. Should I add the "Ready" label to this issue?
After confirmation:
gh issue edit <number> --add-label "Ready"
If the label doesn't exist on the repo, show the error and suggest the user create it manually or pick a different label.
Step 7: Verify
git status
This must show the branch is up to date with the remote. If it doesn't, diagnose and fix before declaring success.
Error Handling
- Push fails: Suggest
git pull --rebase and retry once. If still failing, ask the user.
- Label fails: Show the error message. Common causes: label doesn't exist, insufficient permissions, wrong issue number. Suggest manual labeling as a fallback.
- Commit fails (nothing to commit): Run
git status to diagnose. The beads may already be committed, or bd sync may not have produced changes. Ask the user how to proceed.
- Branch name doesn't match pattern: Ask the user to provide the issue number manually.
