bootstrap

Bootstrap

Configure how this repo's skills talk to its tracker and domain docs. The skills resolve two config surfaces at run time — this skill writes both, so both lanes work:

• Triage-graph lane (triage) reads a tracker: preference from the repo's CLAUDE.md, its label strings from docs/agents/triage-labels.md, and its commands from docs/agents/issue-tracker.md. GitHub and Linear only.
• Planning lane (align, cut, propose, review, crucible, build) reads per-repo docs/agents/*.md. GitHub, Linear, GitLab, local-markdown, or a freeform "other".

GitHub and Linear are fully wired for both lanes. If you pick GitLab / local / other, the planning lane works from its seed template while the triage-graph lane has no adapter — flag this to the user rather than pretending it's configured.

This is a prompt-driven skill, not a script. Explore, present what you found, confirm, then write.

Process

1. Explore

Read the repo's starting state — don't assume:

• git remote -v — GitHub? GitLab? No remote?
• CLAUDE.md / AGENTS.md at the root — which exists? Is there already an ## Issue tracker or ## Agent skills section?
• CONTEXT.md / CONTEXT-MAP.md — single- or multi-context?
• docs/agents/ — has this skill run before?
• .scratch/ — a local-markdown convention already in use?

2. Ask which tracker (one question at a time)

Walk the decisions one at a time — present, get the answer, move on. Don't dump them all.

Tracker. Propose the default from the remote (GitHub remote → GitHub; GitLab remote → GitLab; none → local). Offer: GitHub · Linear · GitLab · Local markdown · Other (describe the workflow in a paragraph, recorded as prose).

PRs as a request surface? (GitHub/GitLab only) — yes/no, default no. When yes, /triage pulls external PRs into the same queue. Skip for Linear/local/other.

3. Write surface 1 — the triage-graph preference

Write a tracker: line under an ## Issue tracker section in the repo's CLAUDE.md (create the section if absent):

## Issue tracker

tracker: github

• GitHub — nothing else needed; the tracker doc's pre-flight creates the canonical labels on first use.
• Linear — the workspace is usually shared, so adopt, don't impose: never bootstrap labels. Inspect the live workspace (list_teams, list_issue_statuses, list_issue_labels), map each canonical role onto an existing label / workflow state / Project mechanism, and record the mapping in CLAUDE.md (or docs/agents/triage-labels.md). Where no target exists, ask — don't create taxonomy. Flag any duplicate (a ported label beside a native one). Linear conventions live in issue-tracker-linear.md.
• GitLab / local / other — no triage-graph adapter exists. Set the tracker: line for the record, and tell the user the triage-graph lane (triage) is GitHub/Linear-only — only the planning lane is wired for this tracker.

triage-disclaimer. Ask whether AI-generated triage comments carry > *This was generated by AI during triage.*. Default on for Linear (shared space), off for GitHub (personal). Write triage-disclaimer: off under ## Issue tracker only when the user wants the non-default.

out-of-scope. Ask whether a rejected enhancement is recorded in a .out-of-scope/ file as well as closed: out-of-scope: on. Default off for GitHub and Linear, on for local-markdown. Write out-of-scope: on under ## Issue tracker only when the user wants the non-default. When on, /triage's wontfix writes the record; when off, the reasoning lands in the closing comment alone.

4. Write surface 2 — the planning-lane docs

Seed the per-repo docs from the templates in this folder (let the user edit before writing):

• docs/agents/issue-tracker.md — from issue-tracker-github.md / issue-tracker-gitlab.md / issue-tracker-linear.md / issue-tracker-local.md. For other, write from the user's description.
• docs/agents/triage-labels.md — from triage-labels.md. Seven canonical states plus wontfix across two lanes: inbound (needs-triage, needs-info), planning (needs-alignment, ready-to-propose, awaiting-decision, ready-to-cut, ready-to-build), and wontfix. (No prd label — a spec is its ticket's body, and a ticket holds needs-alignment until its tests are locked or its parent spec is agreed.)
• docs/agents/domain.md — from domain.md. Confirm single-context (CONTEXT.md + docs/adr/) vs multi-context (CONTEXT-MAP.md).

Then add an ## Agent skills block to whichever of CLAUDE.md / AGENTS.md already exists (edit the existing one; never create the second when one is present; ask which to create if neither exists). Update in place if the block already exists — don't append a duplicate.

## Agent skills

### Issue tracker

[where issues live, plus whether external PRs are a triage surface]. See `docs/agents/issue-tracker.md`.

### Triage labels

[one-line summary]. See `docs/agents/triage-labels.md`.

### Domain docs

[single-context or multi-context]. See `docs/agents/domain.md`.

5. Offer the design system

If the repo has a frontend and no DESIGN.md, invoke /design-system — it interviews the brand knobs and writes DESIGN.md plus the token layer. Skip silently for a backend-only repo.

6. Confirm

Show the written config back to the user and name which skills now read from it — the triage-graph lane from ## Issue tracker, the planning lane from docs/agents/*.md. Note they can edit docs/agents/*.md directly later; re-run this skill only to switch trackers.