0x0w1/jig/jig-doctor

jig Doctor

Use this repository skill to diagnose the installed jig state across every supported target and scope. This skill never modifies files or settings.

Distribution Model

Each CLI is installed on its own, but diagnosis inventories all of them before judging any one instance.

• Claude Code plugin is host-managed and may be enabled at project, local, user, or managed scope. Its skills are namespaced as /jig:<skill> and its host version is not compared with file payload tags.
• Claude Code standalone is a compatibility installation under .claude/skills or ~/.claude/skills. A current installation has a .jig-installation ledger plus per-skill .jig-provenance; a verified legacy copy may have no ledger yet.
• Codex plugin is host-managed too, installed user-global through codex plugin add jig@jig from the same payload as the Claude Code plugin. Its skills are namespaced jig:<skill> and it carries no jig version stamp.
• Codex legacy files are the retired .agents/skills/jig-* installation the jig installer used to write. It still loads, but the installer no longer targets Codex; report it as a migration to the plugin, owned by jig-update.
• Antigravity has no plugin system. Its project and global rules files carry independent managed blocks and version stamps; skill roots differ by scope.

Installation Inventory

Use this exact contract, shared with jig-update. Inventory all rows before deciding that jig is absent or healthy.

<!-- jig:start installation-inventory -->

<!-- jig:end installation-inventory -->

Use scripts/inspect-claude-standalone.sh from this skill once for each standalone root. It reports absent, source-mirror, verified, legacy-unledgered, ledger-invalid, partial, provenance-conflict, or non-owned without writing anything. Only verified and legacy-unledgered roots count as update-compatible installations; the other non-absent states are diagnostic context with an explicit finding.

GitHub Profile

Before any gh command, resolve the host from JIG_GITHUB_HOST, local jig.githubHost, then github.com, and resolve the profile from JIG_GITHUB_PROFILE, then local jig.githubProfile. If a profile is configured, read its credential with gh auth token --hostname <host> --user <profile> without printing it and run every gh command with that credential through GH_TOKEN (github.com or *.ghe.com) or GH_ENTERPRISE_TOKEN (other hosts). Verify gh api user --jq .login matches the profile. Do not use gh auth switch; fall back to the globally active account only when neither the environment nor local config selects a profile.

Checks

1. Complete installation inventory: inspect all eleven rows in the shared contract, regardless of which agent invoked the skill.

• Use claude plugin list --json as the primary plugin inventory. Use project, local, and user settings as fallback and to prove those exact scopes; an unscoped text match proves only that the plugin exists. Report host-managed version data without comparing it with file payload tags. If the CLI and every settings source are unavailable, mark only that plugin inventory as skipped.
• Run the standalone inspector for both project and user roots. non-owned means an ordinary user skill root and is not a jig defect. source-mirror means the jig repository's development copy and is not an installed payload. Report legacy-unledgered, ledger-invalid, partial, and provenance-conflict distinctly; the latter three belong to jig-update but must remain untouched by doctor.
• Detect the Codex plugin from the Codex configuration, not from this repository: codex plugin list --json when the CLI is available, otherwise [plugins."jig@jig"] in ${CODEX_HOME:-~/.codex}/config.toml. It installs user-global, so there is one row and it is unrelated to which directory is current. Report enabled = false as installed but disabled.
• Detect Codex legacy files and Antigravity project/global independently from each rules file's own jig managed block. File existence alone is not installation evidence. Read the version and skills= from that same block; a stamp without skills= means the full default set.
• Skill roots are target- and scope-specific: project Antigravity and Codex legacy files use ./.agents/skills, global Codex legacy files use ~/.agents/skills, and global Antigravity uses ~/.gemini/config/skills. Shared project files do not merge the two rules-file instances.

1. Version and selection, per instance: resolve the latest release tag once (gh api repos/0x0w1/jig/releases/latest --jq .tag_name) and report each detected instance independently.

• Claude Code plugin: host-managed version and plugin-managed selection.
• Claude Code standalone: ledger version and exact <manifest skill>=<directory> mappings. A verified legacy root has unknown version and selection until its first successful jig-update; do not claim it is current.
• Codex plugin: host-managed, like the Claude Code plugin. It reports no jig version; never guess one and never compare it with a file payload tag.
• Codex legacy files and Antigravity: that instance's rules-file stamp and skills= selection. Never reuse the first stamp found for another target or scope.

1. Drift and provenance, per instance:

• Both plugins are updated by their host; verify enabled state but do not compare plugin files.
• For each versioned file installation, read that version's dist/files.tsv. A missing catalog means the release shipped SKILL.md only. Compare every selected payload path and report missing and mismatched files separately. main, custom, and unknown versions cannot prove fixed-payload drift.
• Antigravity payload path: dist/antigravity/.agents/skills/jig-<skill>/<path>. Codex legacy files were installed from the retired dist/codex/ tree, whose content was identical, so compare them against the Antigravity path for any release that no longer ships dist/codex/. Resolve the installed root from the inventory row rather than assuming project scope.
• Standalone unprefixed mappings such as github-sync=github-sync compare with the plugin payload. Prefixed mappings such as github-sync=jig-github-sync compare with the prefixed Antigravity payload. Before comparing content, require the ledger mapping, skill directory, SKILL.md, and exact .jig-provenance to agree; use the inspector status as the finding category.
• A payload mismatch is drift. A missing selected file is a partial installation. A file the payload does not list is a leftover. Report leftovers without deleting them; only jig-update may remove one, with confirmation.

1. Pending migrations, per versioned instance: for each installed version behind latest, read every newer release note (gh release view <tag> --repo 0x0w1/jig), then merge and de-duplicate the needed items while retaining the affected target/scope list.

• Count line-anchored markers only (^<!-- jig:start migration-auto -->$ and ^<!-- jig:start migration-manual -->$); notes often name these markers in prose, and a substring search would count those mentions as blocks.
• Report the counts and quote the manual items in full; those need a human decision and are what makes a release major.
• Do not evaluate whether an item was already applied and never run one. jig-update owns execution.
• Skip this check when an instance has no installed version or is already latest.

Checks 5–10 diagnose repository state, not global installation state. Run them only when the current directory is a Git worktree and at least one project-scoped jig instance belongs to that repository. A user/global-only inventory must not turn whichever directory happens to be current into the diagnostic target; report repository checks as not applicable instead.

1. Branch protection (optional feature — absence is not automatically a defect): gh api repos/<owner>/<repo>/branches/<branch>/protection for main and develop. jig guarantees exactly two things, so those are the only two this check judges: allow_force_pushes.enabled == false and allow_deletions.enabled == false. Required pull-request reviews, required status checks, push restrictions, and admin enforcement are the repository's own; they are reported as present and never as drift. Classify the response with scripts/classify-protection.sh from the github-sync skill of the same installation rather than comparing fields by eye.

Preserve the HTTP result and body separately. Generic 404, authentication/rate-limit errors, malformed responses, and incomplete flags are unreadable, not evidence that protection is absent.

Read the answer before judging it:

Distinguish 403 from 404. Branch protection on a private repository requires a paid plan, so most personal projects answer 403, and reporting that as "unprotected" turns a plan limit into a permanent red mark.

When protection is absent for any reason, check whether a ruleset covers the branches instead: gh api repos/<owner>/<repo>/rulesets. A 403 here means the same plan limit — report the check as skipped. jig never creates or edits rulesets; a repository governed by one is reported as protected by a ruleset and left alone.