Agent skill

Git Workflow

by povvo in povvo/claudikins-kernel

A skill your agent uses when running claudikins-kernel:execute, decomposing plans into tasks, setting up two-stage review, deciding batch sizes, or handling stuck agents — enforces isolation…

MITAuto-check: notesDevelopment

Install Git Workflow

skills CLI
$ npx skills add povvo/claudikins-kernel --skill git-workflow -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install povvo/claudikins-kernel git-workflow --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/povvo/claudikins-kernel.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/git-workflow .claude/skills/git-workflow && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
git-workflow
GitHub stars
128
Token cost
~3.4k tokens
SKILL.md length
1,246 words
Files
12 (incl. references)
Skills in repo
4
Repo updated
First seen
Licence
MIT

At a glance

A skill your agent uses when running claudikins-kernel:execute, decomposing plans into tasks, setting up two-stage review, deciding batch sizes, or handling stuck agents — enforces isolation…

  • Works in 2 steps: Spec Compliance (spec-reviewer, opus) → Code Quality (code-reviewer, opus)
  • Running claudikins-kernel:execute
  • SKILL.md covers When to use this skill, Core Philosophy, Task Decomposition and Review Stages, plus 6 more sections
  • Calls jq and git

What it does

Git Workflow is an agent skill from povvo/claudikins-kernel. Use when running claudikins-kernel:execute, decomposing plans into tasks, setting up two-stage review, deciding batch sizes, or handling stuck agents — enforces isolation, verification, and human checkpoints; prevents runaway parallelization and context death

Its SKILL.md is about 3.4k tokens, which your agent loads only when the skill is triggered. The skill folder holds 12 other files, including reference files (for example `references/batch-patterns.md`, `references/batch-size-verification.md` and `references/branch-collision-detection.md`).

It sits in Development, covering Git workflow. The repository describes itself as: SRE thinking applied to Claude Code, based on Boris Cherny's Q&A. It enforces a strict 4-stage pipeline with gates between each step. You literally cannot skip verification. You… The licence is MIT.

When your agent uses it

  • Running claudikins-kernel:execute
  • Decomposing plans into tasks
  • Setting up two-stage review
  • Deciding batch sizes

Example prompts

  • “/git-workflow”

Requirements

  • Pre-approved tools (allowed-tools): Read, Grep, Glob, Bash, Edit, Write, TodoWrite, Skill, mcp__plugin_claudikins-tool-executor_tool-executor__search_tools, mcp__plugin_claudikins-tool-executor_tool-executor__get_tool_schema, mcp__plugin_claudikins-tool-executor_tool-executor__execute_code

Workflow steps

2 steps, taken from the step headings in SKILL.md.

  1. Spec Compliance (spec-reviewer, opus)
  2. Code Quality (code-reviewer, opus)

What it can do on your machine

Read from SKILL.md and the folder at commit 8b626a4. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Read
    • Grep
    • Glob
    • Bash
    • Edit
    • Write
    • TodoWrite
    • Skill
    • mcp__plugin_claudikins-tool-executor_tool-executor__search_tools
    • mcp__plugin_claudikins-tool-executor_tool-executor__get_tool_schema

    …and 1 more on the same allowed-tools line.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • jq
    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Git Workflow loads about 3.4k tokens when it runs, and up to ~24k if it reads all its reference files. Until then it costs about 68 tokens; SKILL.md has 1,246 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~68
When it runs · the whole SKILL.md, loaded when a task matches
~3.4k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~24k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NotePre-approves every shell command (allowed-tools: Bash)SKILL.md
    allowed-tools: Read, Grep, Glob, Bash, Edit, Write, TodoWrite, Skill, mcp__plugin_claudikins-tool-executor_tool-exe

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from povvo/claudikins-kernel at commit 8b626a4, republished under its MIT licence (© povvo). 1,246 words, ~3,439 tokens.

Download SKILL.mdSave it as .claude/skills/git-workflow/SKILL.md (or your agent's skills folder). This skill also uses 11 other files; get the full folder from GitHub.
name
git-workflow
description
Use when running claudikins-kernel:execute, decomposing plans into tasks, setting up two-stage review, deciding batch sizes, or handling stuck agents — enforces isolation, verification, and human checkpoints; prevents runaway parallelization and context death
allowed-tools
Read, Grep, Glob, Bash, Edit, Write, TodoWrite, Skill, mcp__plugin_claudikins-tool-executor_tool-executor__search_tools, mcp__plugin_claudikins-tool-executor_tool-executor__get_tool_schema, mcp__plugin_claudikins-tool-executor_tool-executor__execute_code

Git Workflow Methodology

When to use this skill

Use this skill when you need to:

  • Run the claudikins-kernel:execute command
  • Decompose plans into executable tasks
  • Set up two-stage code review
  • Decide batch sizes and checkpoints
  • Handle stuck agents or failed tasks

Core Philosophy

"I'd use 5-7 agents per SESSION, not 30 per batch." - Boris

Execution is about isolation, verification, and human checkpoints. Not speed.

The Six Principles
  1. One task = one branch - Isolation prevents pollution
  2. Fresh context per task - context: fork gives a clean slate
  3. Two-stage review - Spec compliance first, then code quality
  4. Human checkpoints between batches - Not between individual tasks
  5. Commands own git - Agents never checkout/merge/push
  6. Features are the unit - Batch at feature level, not task level
Batch Size Guidance (GOSPEL)

Wrong: 30 agents for 10 tasks (3 per task micro-management) Right: 5-7 agents total (feature-level batches)

ScenarioWrongRight
10 tasks, 5 features30 micro-task agents5-7 feature agents
Simple refactor10 agents for tiny changes1-2 feature agents

Default --batch 1 is correct. Features are the unit of work.

Task Decomposition

From a plan, extract tasks that are:

QualityDefinitionExample
AtomicCompletable in one agent session"Add auth middleware" not "Build auth system"
TestableHas measurable acceptance criteria"Returns 401 for invalid token"
IndependentMinimal dependencies on other tasksCan be reviewed in isolation
Right-sizedNot too small (noise) or large (context death)50-200 lines of changes

See task-decomposition.md for patterns.

Review Stages

Two reviewers with different jobs. Never skip either.

Stage 1: Spec Compliance (spec-reviewer, opus)

Question: "Did it do what was asked?"

Checks:

  • All acceptance criteria addressed?
  • Any scope creep (features not in spec)?
  • Any missing requirements?

Output: PASS or FAIL with line references.

Stage 2: Code Quality (code-reviewer, opus)

Question: "Is it well-written?"

Checks:

  • Consistency with codebase style
  • Error handling
  • Edge cases
  • Naming clarity
  • Unnecessary complexity

Output: PASS or CONCERNS with confidence scores.

See review-criteria.md for detailed checklists.

Review Enforcement (MANDATORY)

This is non-negotiable. Violations here break the entire workflow.

The Iron Rule

After EVERY task completes, you MUST spawn BOTH reviewer agents:

  1. spec-reviewer - Spawned via Task(spec-reviewer, {...})
  2. code-reviewer - Spawned via Task(code-reviewer, {...}) (if spec passes)
What "MUST spawn" Means
AllowedNOT Allowed
Task(spec-reviewer, { prompt: "...", context: "fork" })Inline spec check by orchestrator
Task(code-reviewer, { prompt: "...", context: "fork" })"I'll just verify the code looks good"
Waiting for agent output JSONMaking your own compliance table
Reading from .claude/reviews/spec/Skipping because "it's a simple task"
Inline Reviews Are VIOLATIONS

If you find yourself doing ANY of these, you are VIOLATING the methodology:

  • Creating a "Spec Compliance Check" table yourself
  • Writing "Verdict: PASS" without spawning an agent
  • Saying "Let me verify the implementation meets criteria"
  • Checking acceptance criteria in a loop instead of delegating

The orchestrator does NOT review. The orchestrator SPAWNS reviewers.

Pre-Merge Checklist (HARD GATE)

Before ANY merge decision can be offered to the user:

□ .claude/reviews/spec/{task_id}.json EXISTS for each task
□ .claude/reviews/code/{task_id}.json EXISTS for each task
□ Both files contain valid JSON with "verdict" field
□ spec-reviewer verdict is PASS (or user override documented)

If ANY file is missing: DO NOT proceed to merge. You skipped the review.

Why This Matters
  1. Consistency - Every task gets the same rigor, not "looks simple, I'll check it"
  2. Auditability - Review outputs are artifacts, not orchestrator judgments
  3. Separation of concerns - Orchestrator orchestrates, reviewers review
  4. No rationalization - You can't convince yourself your inline check is "good enough"

Verdict Matrix

What happens when reviewers return their verdicts:

Spec ResultCode ResultAction
PASSPASSOffer [Accept] [Revise anyway]
PASSCONCERNSOffer [Accept with caveats] [Fix] [Klaus review]
FAIL*Always [Revise] or [Retry]

See review-conflict-matrix.md for edge cases.

Batch Checkpoint Flow

All tasks in batch complete?
├── No → Wait for remaining
└── Yes →
    All reviews pass?
    ├── No →
    │   Retry count < 3?
    │   ├── Yes → Retry failed tasks
    │   └── No → Escalate to Klaus or human
    └── Yes →
        Present results to human
        └── Human decides: [Accept] [Revise] [Retry]

See batch-patterns.md for decision trees.

Rationalizations to Resist

Agents under pressure find excuses. These are all violations:

ExcuseReality
"30 agents is fine, tasks are independent"More agents = more chaos. 5-7 per session, features as units.
"I'll just checkout main to compare"Agents don't own git. Use git show main:file instead.
"Skip spec review, code looks correct"Spec review catches scope creep. Never skip.
"I'll do the review myself, it's simple"Spawn the reviewer agents. Inline reviews are VIOLATIONS.
"Both passed, auto-merge is safe"Human checkpoint required. Always.
"Context is fine, I'll continue"ACM at 60% = checkpoint offer. 75% = mandatory stop.
"This tiny task doesn't need a branch"One task = one branch. No exceptions. Isolation prevents pollution.
"Retry limit is just a guideline"2 retries then escalate. Infinite retry = infinite waste.
"I'll merge my changes when done"Commands own merge. You own implementation. Stay in your lane.

All of these mean: Follow the methodology. Speed is not the goal.

Show full SKILL.md (510 more words)Show less

Red Flags — STOP and Reassess

If you're thinking any of these, you're about to violate the methodology:

  • "Let me just run git checkout..."
  • "30 tasks, 30 agents, maximum parallelism"
  • "Review passed, no need for human checkpoint"
  • "Context is getting tight but I can finish"
  • "This is simple, don't need isolation"
  • "I'll merge it myself"
  • "Retry limit doesn't apply here"
  • "Spec review is redundant if code review passes"
  • "Let me verify the implementation meets criteria" (SPAWN THE AGENT)
  • "I'll create a quick compliance table" (SPAWN THE AGENT)

All of these mean: STOP. Commands own git. Humans own checkpoints. Reviewers own reviews. You own orchestration.

Robustness Patterns

Things go wrong. Here's how to handle them.

SubagentStop Hook Failure (A-6)

If the capture hook fails, agent output is lost.

Pattern: Write to backup location first, then move to primary.

bash
# Always backup first
echo "$OUTPUT" > "$BACKUP_DIR/agent-$(date +%s).json"
# Then move to primary
mv "$BACKUP_DIR/..." "$PRIMARY"
Malformed JSON Output (A-7)

Agents sometimes produce invalid JSON.

Pattern: Validate required fields before accepting.

bash
REQUIRED='["task_id", "status"]'
jq -e "all($REQUIRED[]; has(.))" "$OUTPUT" || exit 2
Task Branch Directory Export (A-8)

Agents need to know where to work.

Pattern: Export directory as environment variable in SubagentStart hook.

bash
export TASK_BRANCH_DIR="$PROJECT_DIR"
export TASK_BRANCH_NAME="execute/task-${TASK_ID}-${SLUG}"
Model Rate Limiting (A-10)

Opus gets rate limited more than Sonnet.

Pattern: Offer fallback options to human.

  1. Notify: "Opus rate limited. Options:"
  2. Offer: [Wait 60s] [Use Sonnet fallback] [Abort]
  3. If fallback, add caveat to review output
Context Exhaustion Mid-Task (A-11)

Agent runs out of context before finishing.

Pattern: Output partial state and mark as resumable.

json
{
  "status": "partial",
  "files_changed": ["completed work..."],
  "next_steps": ["what remains..."],
  "checkpoint_hash": "sha256:..."
}
Dependency Failure Chains (S-7)

Task Y depends on Task X. Task X fails. What happens to Y?

See dependency-failure-chains.md.

Branch Collision (S-8)

Two tasks accidentally get the same branch name.

See branch-collision-detection.md.

Branch Guard Recovery (S-9)

The git-branch-guard hook blocks something it shouldn't.

See branch-guard-recovery.md.

Batch Size Verification (S-10)

Validating batch sizes before execution starts.

See batch-size-verification.md.

Task Branch Recovery (S-12)

Recovering orphaned branches from crashed sessions.

See task-branch-recovery.md.

Circuit Breakers (S-13)

Preventing cascading failures when operations fail repeatedly.

Pattern: Track failure rate. If threshold exceeded, "open" the circuit - fail fast without attempting.

Circuit: agent_spawn
State: OPEN (3 failures in 60s)
Reset in: 30 seconds

[Wait for reset] [Force close] [Skip operation]

See circuit-breakers.md.

Execution Tracing (S-14)

Debugging execution graphs and understanding what happened.

Pattern: Record spans for each operation. Visualise as waterfall or dependency graph.

Trace: exec-session-xyz
├── batch_1 (45s)
│   ├── task-1 (20s) ✓
│   └── task-2 (25s) ✓
└── batch_2 (60s)
    └── task-3 (60s) ✓

Critical path: batch_1 → batch_2

See execution-tracing.md.

Stuck Detection

SignalThresholdResponse
Tool call flooding20 calls without file changesWarning, then Klaus
Time without progress10 minutesWarning, then Klaus
Repeated failuresSame error 3xPause, offer Klaus
Context burn rateACM at 60%Checkpoint offer
Review timeout5 minutes per reviewerOffer [Wait] [Skip]

Anti-Patterns

Don't do these:

  • Running git checkout/merge/push from agents
  • Batching 30+ tasks in parallel
  • Skipping spec review because "code looks fine"
  • Auto-merging without human checkpoint
  • Ignoring stuck signals
  • Continuing after context warnings

References

Full documentation in this skill's references/ folder:

© povvo, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 11 other files (references) in skills/git-workflow of povvo/claudikins-kernel.

  • SKILL.md
  • references/batch-patterns.md
  • references/batch-size-verification.md
  • references/branch-collision-detection.md
  • references/branch-guard-recovery.md
  • references/circuit-breakers.md
  • references/dependency-failure-chains.md
  • references/execution-tracing.md
  • references/review-conflict-matrix.md
  • references/review-criteria.md
  • references/task-branch-recovery.md
  • references/task-decomposition.md

Open the folder on GitHubat commit 8b626a4

Compare with similar skills

Git Workflow next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Git Workflow compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Git Workflow this skillpovvo/claudikins-kernel128—~3.4kAutomated safety check: NotesMIT
Finishing a Development Branchobra/superpowers297k5 repos~1.9kAutomated safety check: PassMIT
Code Design Rationale Investigatorcursor/plugins11k9 repos~2.6kAutomated safety check: PassNone
Contributor-First PR MergeHKUDS/OpenHarness16k1 repos~847Automated safety check: PassMIT
Migrate Internal Package into GhostTryGhost/Ghost56k—~3.8kAutomated safety check: PassMIT
Create Pull Requestcline/cline70k1 repos~1.6kAutomated safety check: PassApache-2.0

Similar skills

  • Walks the last step of a branch: confirm tests pass, detect the git environment, ask how to integrate, carry out your choice and clean up the worktree.

    297k GitHub starsUsed in 5 repos~1.9k tokens
    DevelopmentAuto-check passed
  • Official

    Digs into why code is shaped the way it is by checking git history, pull requests and connected tools in parallel, then reporting a cited read on the tradeoffs.

    11k GitHub starsUsed in 9 repos~2.6k tokens
    DevelopmentAuto-check passed
  • Merges external GitHub pull requests while keeping the original author credited, and fixes conflicts after the merge instead of rewriting the contribution.

    16k GitHub starsUsed in 1 repo~847 tokens
    DevelopmentAuto-check passed
  • Moves a package from another TryGhost repository into Ghost as an internal workspace package while keeping its Git history, with checkpoints for the steps that need an administrator.

    56k GitHub stars~3.8k tokensUpdated today
    DevelopmentAuto-check passed
  • Opens a GitHub pull request from your current branch with the gh CLI, after reviewing the commits and diff and gathering the details the PR needs.

    70k GitHub starsUsed in 1 repo~1.6k tokens
    DevelopmentAuto-check passed
  • Writes Conventional Commits whose bodies carry action lines recording the intent, decisions and constraints behind a change, not only what changed.

    29k GitHub starsUsed in 1 repo~2.7k tokens
    DevelopmentAuto-check passed

More from povvo/claudikins-kernel

  • Brain Jam Plan

    povvo/claudikins-kernel

    A skill your agent uses when running claudikins-kernel:outline, brainstorming implementation approaches, gathering requirements iteratively, structuring complex technical plans, or facing analysis…

    128 GitHub stars~2k tokensUpdated 5 mo ago
    Auto-check passed
  • Shipping Methodology

    povvo/claudikins-kernel

    A skill your agent uses when running claudikins-kernel:ship, preparing PRs, writing changelogs, deciding merge strategy, or handling CI failures — enforces GRFP-style iterative approval, code…

    128 GitHub stars~3.2k tokensUpdated 5 mo ago
    Auto-check: notes
  • Strict Enforcement

    povvo/claudikins-kernel

    A skill your agent uses when running claudikins-kernel:verify, checking implementation quality, deciding pass/fail verdicts, or enforcing cross-command gates — requires actual evidence of code…

    128 GitHub stars~2.7k tokensUpdated 5 mo ago
    Auto-check: notes

Categories

Questions about Git Workflow

What does Git Workflow do?

A skill your agent uses when running claudikins-kernel:execute, decomposing plans into tasks, setting up two-stage review, deciding batch sizes, or handling stuck agents — enforces isolation…. Git Workflow is an agent skill from povvo/claudikins-kernel.

When should I use Git Workflow?

Git Workflow fits situations like: running claudikins-kernel:execute; decomposing plans into tasks; setting up two-stage review; deciding batch sizes.

How do I install Git Workflow in Claude Code?

Run `npx skills add povvo/claudikins-kernel --skill git-workflow -a claude-code`. Or copy the skill folder (skills/git-workflow in povvo/claudikins-kernel) into .claude/skills/git-workflow in your project. Claude Code loads it when a task matches its description.

How do I install Git Workflow in Codex?

Run `npx skills add povvo/claudikins-kernel --skill git-workflow -a codex`. Or copy the skill folder (skills/git-workflow in povvo/claudikins-kernel) into .agents/skills/git-workflow in your project. Codex loads it when a task matches its description.

Can I use Git Workflow in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add povvo/claudikins-kernel --skill git-workflow -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/git-workflow, .gemini/skills/git-workflow, .github/skills/git-workflow and .opencode/skills/git-workflow in your project.

What does Git Workflow need to run?

Going by SKILL.md and its folder, Git Workflow needs the command-line tools its instructions call (jq and git). Its frontmatter pre-approves these tools: Read, Grep, Glob, Bash, Edit, Write, TodoWrite, Skill, mcp__plugin_claudikins-tool-executor_tool-executor__search_tools, mcp__plugin_claudikins-tool-executor_tool-executor__get_tool_schema, mcp__plugin_claudikins-tool-executor_tool-executor__execute_code.

Does Git Workflow access the network?

SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Git Workflow safe to install?

Our automated static check of SKILL.md found notes only (pre-approves every shell command (allowed-tools: bash)), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does Git Workflow use?

Git Workflow is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Git Workflow use?

About 3.4k tokens (SKILL.md is roughly 14k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 21k tokens, read only when the agent opens those files.

What are the alternatives to Git Workflow?

Skills that share tags, products or a category with Git Workflow: Finishing a Development Branch (obra/superpowers, 297k stars), Code Design Rationale Investigator (cursor/plugins, 11k stars), Contributor-First PR Merge (HKUDS/OpenHarness, 16k stars) and Migrate Internal Package into Ghost (TryGhost/Ghost, 56k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Git Workflow?

povvo (a GitHub user) maintains it in povvo/claudikins-kernel, which has 128 GitHub stars. The repository holds 4 skills in this directory. The repository was last updated on April 22, 2026.

Source: povvo/claudikins-kernel on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.