issue

Create, update, and search issues without caring which tracker the repo uses. One skill, four trackers — GitHub (via gh), GitLab (via glab), Linear (via its MCP server) or local files — picked per-repo by a small committed config, which also settles which host a forge-native tracker talks to. The skill drafts the issue from your free-text description plus the session context, shows it once, and writes it only after you confirm — or just prints the command when you ask for a plan.

Opted out? If the repo config sets issue to false, this skill is disabled for the repo — stop immediately and tell the user the issue skill is turned off in .tituskirch-skills.json. An absent issue block is not disabled (it falls back to detection/defaults). Check .issue == false on the resolved config before any action — and before indexing .issue.tracker. A missing jq or config exits non-zero too, so a pass is not evidence the config was read.

Workflow

1. Load config & cache (guided setup on first run)

• Config — resolve .tituskirch-skills.json via templates/resolve-config.sh, never by reading the raw file (REFERENCE.md states how, missing jq included). The issue.* section holds the tracker and rules; the root grillWith holds the interview engine — three states, so it is read by presence, never as a label-or-off. Resolution per setting: config → native → built-in default.
• No / incomplete config, or /issue setup → run the guided setup (step below). Setup is also where the catalog cache is first filled.
• Catalog cache — read $(git rev-parse --git-common-dir)/tituskirch-skills/issue (JSON). Reuse when younger than ~3 days and the tracker is unchanged; refresh when missing, stale, the tracker changed, or the user passes --refresh. Label staleness in the plan header (Catalogs (cached, 2d ago): …).

Config/cache schema, the full setup flow, and tracker recipes: REFERENCE.md.

2. Determine the tracker

From issue.tracker (github | gitlab | linear | local). A forge-native tracker also needs its host, resolved per repo — config, then the origin remote, then whatever the CLI is already authenticated against (REFERENCE.md); never resolve it once and reuse it across repos. Then check availability: GitHub → gh repo view --json nameWithOwner; GitLab → glab repo view against the resolved host; Linear → confirm the Linear MCP tools are present and authenticated; local → the issue directory (nothing to authenticate). Unavailable/unauthenticated → say so, naming the host that was tried, and point to the fix (glab auth login --hostname …, authenticate the Linear MCP); don't guess another tracker.