The GitHub Skill: LLM-Assisted Git Operations from the Agent Loop

Most agent harnesses treat version control as an afterthought — something you handle manually after the agent finishes its research task. The GitHub skill takes the opposite view: if the harness can research a topic, it should also be able to commit its own outputs, open a PR describing what changed, and file an issue if something looks wrong. The skill makes all of that accessible from a single /github invocation.

Twelve operations, one dispatch table

The skill auto-detects the operation from the leading words of the task string — no flags required. A two-word prefix check runs before a one-word check, so pr create routes differently from a bare pr.

Three distinct LLM system prompts

The skill uses three separate system prompts, each producing a different output format. All three call for precise, structured output — the parser is brittle by design, keeping the LLM on a narrow path.

Commit messages — single line, ≤72 characters, imperative mood. The model receives a task hint, a git diff --stat summary, and the first 2,000 characters of the actual diff. The stat summary carries the structural signal (which files changed, how many lines); the diff excerpt grounds the most-changed file. The raw response is stripped of surrounding quotes and truncated at the first newline before committing.

COMMIT_SYSTEM: "One line only, <=72 characters. Imperative mood.
Be specific -- name the file or function when it fits.
Output ONLY the commit message text. Nothing else."

PR titles and bodies — the TITLE: / BODY: format. The model receives the branch's commit log and up to 6,000 characters of the diff against origin/main. A regex parser splits the response into title and body; if parsing fails, the first line becomes the title and the full text becomes the body.

Issue titles and bodies — same TITLE: / BODY: format, but the input is a plain-text problem description rather than a diff. Useful for filing bugs or feature requests without leaving the agent loop.

The push flow

The push operation stages everything, checks whether the cached diff is empty (and returns early if so), then asks the LLM to write the commit message. The model gets the file-change summary and a diff excerpt — not the full diff — to keep the prompt compact and prevent the model from writing commit messages that read like changelogs.

Invocation examples

# Push with LLM-generated commit message
python agent.py "/github push add lit-review output rendering"

# Create a PR (LLM writes title + body from the branch diff)
python agent.py "/github pr create"

# File an issue from a plain-text description
python agent.py "/github issue create synthesis output truncates at 4096 tokens when task has 6 sections"

# List open PRs
python agent.py "/github pr list"

# Show repo info for a named repo
python agent.py "/github repo view nickmccarty/harness-engineering"

Model selection

The skill defaults to GITHUB_MODEL → PRODUCER_MODEL → llama3.2:3b in that order. The 3B model is intentionally small: commit messages and issue descriptions are short-form generation tasks where a smaller model is faster, uses less VRAM, and produces results that are already quite good. LLM call overhead is dominated by git subprocess latency for most operations, so model size rarely matters here.

Prerequisites

Two pre-flight checks run before any gh operation: gh --version to confirm the CLI is installed, and git rev-parse --git-dir to confirm the working directory is a git repository. Both checks exit with a descriptive error message rather than propagating a subprocess failure — the error message includes the install command for gh if it's missing.

The GitHub skill is registered in skills.py as the /github slash command and is available from both the op.py REPL and agent.py direct invocation. For the full skill registry see The op.py CLI.