same cut, every project — repository procedures installed as skills into Claude Code, Codex, and Antigravity, with the repository state converged to match.
Use for ordinary implementation tasks in a repository that has adopted the jig develop/main model: start from develop, create a feature/fix/chore branch, complete changes and tests, squash-merge back into develop locally, and push develop. No pull requests. Execution scope comes from the current request and explicitly…
Use when diagnosing every detected jig installation for Claude Code, Codex, and Antigravity across current project and user scopes, plus repository profile, migration, protection, guard, rubric, README profile, and legacy state. Read-only; fixes are delegated to jig-setup, jig-update, github-sync, version-rubric, and…
Use when releasing this repository from the CLI by promoting develop to main with a fast-forward push, grading the release as patch/minor/major by what installed projects actually pay, computing the next version from the latest tag, and publishing a GitHub release with agent-written notes. No release PR, no…
Use when synchronizing this repository's GitHub setup: main/develop branches, optional branch protection, and the managed local guards (the git pre-push hook plus the native Codex and Antigravity push hooks), including guard cleanup before uninstalling jig. Do not use for creating a release.
Use when writing or updating a project README.md: scan the repository to classify the project type (CLI tool, library, service or app), settle the per-repository README profile at .jig/readme.md, draft a new README when none exists, or compare the existing README's claims (commands, options, paths, links) against the…
Use after installing jig for Claude Code, Codex, or Antigravity to select and verify the repository GitHub CLI profile through JIGGITHUBPROFILE or local git config, finish GitHub repository convergence, or repair an incomplete jig installation without changing the globally active gh account.
Use when updating every detected jig installation for Claude Code, Codex, and Antigravity across current project and user scopes, including Claude Code plugins and existing standalone .claude/skills copies, while preserving each installed skill selection.
Use when creating, reviewing, or re-setting this repository's version grading rubric at .jig/versioning.md: adopt the jig default human-intervention rubric, write a project-specific one, edit one grade, or reset to the default. Owns the rubric file; never runs a release.
Use for ordinary implementation tasks in a repository that has adopted the jig develop/main model: start from develop, create a feature/fix/chore branch, complete changes and tests, squash-merge back into develop locally, and push develop. No pull requests. Execution scope comes from the current request and explicitly…
Use when releasing this repository from the CLI by promoting develop to main with a fast-forward push, grading the release as patch/minor/major by what installed projects actually pay, computing the next version from the latest tag, and publishing a GitHub release with agent-written notes. No release PR, no…
Use when synchronizing this repository's GitHub setup: main/develop branches, optional branch protection, and the managed local guards (the git pre-push hook plus the native Codex and Antigravity push hooks), including guard cleanup before uninstalling jig. Do not use for creating a release.
Use when writing or updating a project README.md: scan the repository to classify the project type (CLI tool, library, service or app), settle the per-repository README profile at .jig/readme.md, draft a new README when none exists, or compare the existing README's claims (commands, options, paths, links) against the…
Use when creating, reviewing, or re-setting this repository's version grading rubric at .jig/versioning.md: adopt the jig default human-intervention rubric, write a project-specific one, edit one grade, or reset to the default. Owns the rubric file; never runs a release.
Use to check whether a repository's history actually followed the jig procedure: conventional squash subjects, Release-Grade trailers on unreleased work, version tag format and placement, the main/develop fast-forward invariant, and a committed rubric. Read-only, exits non-zero on violations, and runs in CI.
Use when a released defect on main must ship before the work already sitting on develop. Branches from main, lands one squashed commit on main through the guard-allowed hotfix push, tags and publishes, then merges main back into develop so the next release still fast-forwards.
Use to audit and clean the debris a long-running jig repository accumulates: task branches whose work already shipped, branches from retired flows, stale remote-tracking refs, tag and release mismatches, an uncommitted rubric, and installer .bak leftovers. Reports first; deletes only what the user confirms.
Use to check whether a repository's history actually followed the jig procedure: conventional squash subjects, Release-Grade trailers on unreleased work, version tag format and placement, the main/develop fast-forward invariant, and a committed rubric. Read-only, exits non-zero on violations, and runs in CI.
Use when a released defect on main must ship before the work already sitting on develop. Branches from main, lands one squashed commit on main through the guard-allowed hotfix push, tags and publishes, then merges main back into develop so the next release still fast-forwards.
Use to audit and clean the debris a long-running jig repository accumulates: task branches whose work already shipped, branches from retired flows, stale remote-tracking refs, tag and release mismatches, an uncommitted rubric, and installer .bak leftovers. Reports first; deletes only what the user confirms.
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: