How do I install the Git Workflow skill?

Run npx skillmds@latest add blogic-cz/git-workflow-2 in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

What does the Git Workflow skill do?

Automates the full PR lifecycle — create or update a pull request, then aggressively monitor CI checks and review feedback in a continuous loop, fixing failures and addressing comments until the PR is fully green. Also covers push, branch creation, and branch sync workflows. It is listed under Productivity on SkillMD.

Is Git Workflow safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Git Workflow?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Git Workflow free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Git Workflow?

blogic-cz (@blogic-cz) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Git Workflow by blogic-cz — Agent Skill

Name: Git Workflow
Author: blogic-cz

Git Workflow

PR lifecycle automation. Create PR → watch CI + reviews → fix → address → push → repeat until green.

For full bun gh-tool command reference, run bun gh-tool --help or bun gh-tool pr --help. This skill describes the workflow, not the tool surface.

For push, branch creation, and branch sync recipes, see references/push-branch-sync.md.

PR Workflow

Trigger: user says "pr", "pull request", "create PR", "CI failed", "address review comments", "merge when green", or similar.

The entire PR lifecycle runs as one continuous aggressive loop. There is no separate "fix comments" step — it is all one workflow.

Phase 1: Create or Update PR

First check whether a PR already exists:

bun gh-tool pr status

If no PR exists — create branch, commit, push, and open PR in one chain:

git checkout -b <branch> && git add -A && git commit -m "<msg>" && git push -u origin HEAD && bun gh-tool pr create --base <base> --title "<title>" --body "<body>"

If PR already exists — commit, push, and update metadata:

git add -A && git commit -m "<msg>" && git push origin HEAD
bun gh-tool pr edit --pr <pr_number> --title "<title>" --body "<body>"

If already on a feature branch, skip git checkout -b.
Base branch: argument provided by user (default: test).
Branch naming: feat/, fix/, chore/ based on changes.

Local review gate

Before the first commit/push for any non-trivial change, run the code-review skill over the diff and resolve every Critical and Major finding. This is a hard pre-PR gate, not optional cleanup — bun run check proves the paths you wrote pass, not that the logic is right (a coverage gap ships real bugs green: a per-item loop that mislabels output still passes a single-item test). Skip only for trivial/mechanical diffs, and say so.

Do not rely on the Phase 2 GitHub review/watch loop as the first review pass. A bug caught here is a local edit; the same bug caught by CI costs a full round (push, wait, review-bot, fix, rerun). The gate is done when the diff has been read as a reviewer and no Critical/Major finding is open.

PR Body Format

## Summary
<1-2 sentences>

## Changes
- <bullet list>

Commit Message Standard

Every commit MUST use proper conventional commits describing the actual change, not meta-descriptions like "address review feedback" or "fix CI".

Format: <type>(<scope>): <what actually changed>

type: fix, feat, refactor, perf, style, chore, etc.
scope: the module/area affected (e.g., auth, db, ui, api)
message: describe the concrete change, not why you are committing

Good examples:

fix(auth): add null check for session token before redirect
refactor(api): extract validation logic into shared middleware
fix(db): correct JOIN condition in user query

Bad examples (NEVER use these):

~~fix: address review feedback~~
~~fix: resolve CI check failures~~
~~chore: fix issues~~

If a single commit addresses multiple review comments across different scopes, make separate commits per scope rather than one catch-all.

Phase 2: Active Watch Loop

Immediately after PR creation/update, enter the active watch loop. No pause, no waiting for user input.

Inform user: "PR created/updated. Entering active watch loop — monitoring CI and reviews. (say 'stop' to exit)"

LOOP START

Step 1: Take a snapshot and decide what to do next

LOOP CONTRACT — mandatory behavior, not a suggestion:

After PR creation/update, stay inside this loop until LOOP EXIT.
After every fix + push, immediately return to Step 1.
After every reply/resolve pass, immediately return to Step 1.
If CI is still running, the loop is not done.
If visible-open review feedback still exists, the loop is not done.
Do not stop after one pass just because one category is clean.
Do not ask the user whether to continue unless the user said stop or the max-iteration guard is hit.

Always start Step 1 with a snapshot:

bun gh-tool pr review-triage --pr <pr_number>

This returns info, unresolvedThreads, visibleOpenThreads, summary, and checks in one call. Use it as the single source of truth for branching.

After the snapshot, branch immediately:

Checks failed → go to Step 2
Checks passed AND visible-open feedback exists → go to Step 3
Checks passed AND no visible-open feedback → go to LOOP EXIT
Checks still running AND visible-open feedback exists → go to Step 3 (work on feedback while CI runs)
Checks still running AND no feedback → block on CI:

bun gh-tool pr checks --pr <pr_number> --watch

When --watch completes, return to Step 1 for a fresh snapshot.

Do NOT build ad-hoc sleep polling loops around bun gh-tool. If work remains, handle it and then explicitly re-enter Step 1. If nothing remains except CI, use --watch.

Step 2: Handle CI failure

First, decide: flaky or real?
- If the failure looks flaky (timeout, infra/network issue, unrelated service), rerun and return to Step 1:
```
bun gh-tool pr rerun-checks --pr <pr_number>
```
  → Go back to LOOP START
- If the failure looks real, continue below.

Get failed check details:

bun gh-tool pr checks-failed --pr <pr_number>

If the output includes a workflow run and job name, fetch logs:

bun gh-tool workflow job-logs --run <run_id> --job "<job_name>" --failed-steps-only

Analyze the error, fix locally — do not ask, just fix.
Run validation:
```
bun run check
```

Commit and push:

git add -A && git commit -m "<type>(<scope>): <what changed>" && git push origin HEAD

→ Go back to LOOP START

Step 3: Check for reviews and triage feedback

The snapshot from Step 1 already contains threads and summary. Drill into details:

3.1 Inline review threads that still need attention:

Use --visible-open-only — it includes unresolved threads and resolved threads that still have no reply:

bun gh-tool pr threads --pr <pr_number> --visible-open-only

3.2 AI reviewer issue comments (Claude bot, Sentry Seer, etc.):

bun gh-tool pr issue-comments --pr <pr_number> --author claude --body-contains "Claude Code Review"
bun gh-tool pr issue-comments --pr <pr_number> --author sentry-io --body-contains "Sentry"

AI reviewers post findings as general PR comments with severity-tagged items (Critical, Major, Minor), file paths, and line numbers. Parse each comment body to extract actionable items.

3.3 Decision:

If NO visible-open threads AND NO actionable AI comments → PR is clean. → Go to LOOP EXIT
If ANY feedback found → proceed to Step 4

Step 4: Address every comment immediately

Before changing code, create one todo item per actionable comment/finding (use the todo-list tool if available, otherwise maintain an explicit numbered checklist in conversation).

One comment/finding = one tracked item.
Use a short label that identifies the source and problem.
Mark in_progress only while actively handling that single comment.
Mark completed only after the code change and the reply/resolve are both done.

For each comment/finding:

Read the file at the specific line mentioned.
Understand the suggestion — what change is being requested?
Evaluate and act:
- Auto-apply (no confirmation): typos, style fixes, missing types, import cleanup, obvious bugs, performance improvements, security fixes matching CLAUDE.md conventions.
- Apply with judgment: refactoring suggestions that improve clarity, error handling, naming improvements.
- Ask user first: removing functionality, changing public API signatures, contradicting existing patterns, unclear suggestions.
Make the fix immediately — track what was changed and why.

Step 5: Reply to comments and resolve threads

CRITICAL: Every thread MUST have a reply before being resolved.

For inline threads — reply and resolve in one step:

bun gh-tool pr reply-and-resolve --pr <pr_number> --comment-id <comment_id> --thread-id <thread_id> --body "<response>"

For general PR comments — post a reply:

bun gh-tool pr comment --pr <pr_number> --body "<response>"

Response format:

If fixed: "Addressed - [brief description of what was changed]"
If not applicable: "Not applicable - [brief explanation why]"
If positive feedback: "Thanks for the feedback!" or similar acknowledgment
If needs discussion: "Question: [ask for clarification]"

If reply fails with a pending-review validation error: submit the pending review first with bun gh-tool pr submit-review --pr <pr_number>, then retry. If it must be dismissed instead, dismiss it in GitHub first.

Do NOT resolve threads where you asked a question.

Step 6: Validate and push

bun run check

Fix any new issues. Then commit and push:

git add -A && git commit -m "<type>(<scope>): <what changed>" && git push origin HEAD

→ Go back to LOOP START

LOOP EXIT

When reaching here (all checks pass + no visible-open feedback):

Before the final success message, print a comment resolution summary list.

Use a numbered list with one item per handled comment/finding and this fixed structure:

1. Source: inline thread | general PR comment | AI review
   Identifier: <thread_id / comment_id / reviewer label>
   Problem: <short summary of the concern>
   Resolution: <what changed, or why it was not applicable>
   Changed files: <file A>, <file B> | none
   Replied: yes | no | n/a
   Resolved: yes | no | n/a
   Link: <comment or PR URL if available>

If no comments were found, say so explicitly instead of printing an empty structure.

Inform user: "All CI checks passed. All review comments addressed. PR is ready for review!"

Loop exit conditions

Exit the watch loop when:

All checks pass AND no visible-open feedback — natural exit.
User says "stop" or requests to exit.
Maximum 20 iterations reached — ask user if they want to continue.

Git Workflow

File contents

Git Workflow

PR Workflow

Phase 1: Create or Update PR

Local review gate

PR Body Format

Commit Message Standard

Phase 2: Active Watch Loop

LOOP START

Step 1: Take a snapshot and decide what to do next

Step 2: Handle CI failure

Step 3: Check for reviews and triage feedback

Step 4: Address every comment immediately

Step 5: Reply to comments and resolve threads

Step 6: Validate and push

LOOP EXIT

Loop exit conditions

Frequently asked questions

Git Workflow

File contents

Git Workflow

PR Workflow

Phase 1: Create or Update PR

Local review gate

PR Body Format

Commit Message Standard

Phase 2: Active Watch Loop

LOOP START

Step 1: Take a snapshot and decide what to do next

Step 2: Handle CI failure

Step 3: Check for reviews and triage feedback

Step 4: Address every comment immediately

Step 5: Reply to comments and resolve threads

Step 6: Validate and push

LOOP EXIT

Loop exit conditions

Related skills

Frequently asked questions

How do I install the Git Workflow skill?

What does the Git Workflow skill do?

Is Git Workflow safe to use?

Which AI agents work with Git Workflow?

Is Git Workflow free to use?

Who published Git Workflow?