Git Ops

Git Ops (router)

The single front door for all git operations in this repo. The user is Blake — not a developer, so expect plain language, not "commit", "push", or "merge". For every request:

1. Translate what Blake said into one of the three operations (or the full backup).
2. Run the right skill(s) in the order that cannot get stuck.
3. Report back in plain language — never make Blake read git jargon.

Don't reimplement the git operations here — invoke the leaf skills with the Skill tool and follow their workflows; they own the actual commands. Decide which run and in what order. (Exception: the read-only status check below runs git directly, since it only looks and changes nothing.)

The three operations

Read what he meant (intent map)

Match Blake's words to an intent. When more than one could fit, prefer the fuller action — a non-dev who says "save it" usually means "make sure it's safe," which is the full backup, not just a local commit.

When in doubt, do the full backup. It never loses work and never gets stuck.

Capture phrasings that didn't cleanly match

When a request's wording wasn't in the table above and had to be inferred rather than matched, that's a genuinely new phrase worth learning. After the git work is done, silently hand it to blake-os:feedback as a vocabulary item: Blake's exact words and the meaning taken from them. Don't ask permission and don't interrupt — it runs in the background so Brent can fold that wording in for next time. Skip phrasings the table already covers; blake-os:feedback de-dupes, but there's no need to hand it repeats.

The full backup chain

Run the leaf skills in this order — it is the order that always completes in one pass:

1. blake-os:git-commit — save his work first. This is safe even if GitHub has newer changes; committing while behind is fine.
2. blake-os:git-sync — now the working area is clean, so pulling the latest always merges cleanly (a dirty working area is the one thing that makes sync stall, and step 1 already cleared it).
3. blake-os:git-push — now everything's up to date, so the upload always succeeds.

Do not sync before committing. If there are unsaved edits and GitHub also moved, sync-first hits a dead end ("commit first") and needs a second pass. Commit-first avoids that every time.

If any step stops and hands off, stop the chain — explain in plain language, and don't push partial state.

Checking status (no changes made)

When Blake just wants to know where things stand, don't run a leaf skill — read it directly and translate:

git fetch origin 2>/dev/null || true
git status --short --branch
git rev-list --left-right --count @{u}...HEAD 2>/dev/null   # "<behind>	<ahead>"

Then tell him, for example:

• ahead 0 / behind 0, clean → "Everything's saved and backed up. You're all set."
• ahead 2 / behind 0 → "Your work is saved on this computer but not yet on GitHub. Want me to upload it?"
• behind 3 / ahead 0 → "GitHub has 3 newer changes you don't have yet. Want me to grab them?"
• dirty tree → "You have edits that aren't saved yet. Want me to save and back them up?"

Speak plain — always

Translate every outcome out of git-speak before reporting it:

End a full backup with one reassuring line, e.g. "All done — your work is saved and backed up to GitHub."

Guardrails — never work around these

When a leaf skill stops, surface it in plain language and end the turn — for an error, put the exact text beneath the plain summary so Blake can forward it to Brent. Don't work around a stop by retrying, hand-editing, or dropping to raw git, and don't reclassify a real stop as "a person needs to do this" to keep moving. The operations never to run, in any case:

• Never force-push, reset, or rebase.
• Never auto-resolve a merge conflict — guessing a side can silently delete Blake's work.
• Never stage .env, keys, tokens, or credential files.
• Never invent a remote or create branches — everything goes to the current branch.