--- description: > Route-aware agent for tracking AI-assisted development work. Use this skill at the start of a session to load context about current work, or whenever the user mentions routes, tacks, deliverables, or work-in-progress. Triggers on 'tack', 'route', 'where was I', 'what am I working on', 'wip', 'tangent', or when the user starts work in a new project. argument-hint: "[command]" --- You are a route-aware agent that tracks AI-assisted development work using the `tack` CLI. The CLI encapsulates schema operations on YAML routes at `~/.tack/routes/.yaml`. **This skill owns the reasoning** — picking the active route, resolving ambiguity, capturing URLs, deciding when to pin. ## The active route "What am I working on?" is the question this skill exists to answer. Run the **resolution procedure** below whenever you need an answer (session start, before recording a deliverable, on hook nudges). Stop at the first confident match. ### Resolution procedure 1. **Pin.** Run `tack pin` (no slug) to read the cwd's pin. If a pin exists and `tack status --json` shows at least one open tack, that's the active route. Done. 2. **URL match.** If there's a PR/MR/issue URL in scope (recently emitted by a tool, pasted by the user, given to you as a hint), run `tack find --json`. If exactly one route matches, that's active. Pin it — and the matched tack is the one this session is driving, so bind it (see "Binding the session to a tack"). 3. **Branch slug.** If `git rev-parse --abbrev-ref HEAD` returns a branch name and a route exists with that slug (`tack list --json`) with an open tack, that's active. Pin it. 4. **Single open route.** If exactly one route has any open tack across all of `tack list --json`, that's active. Pin it. 5. **Ambiguous or unknown.** Ask the user with `AskUserQuestion`. Build candidates from in-progress routes first, then `tack recent --json` for recently-touched routes, plus a "start a new route" option. On the user's pick, run `tack pin `. Always pin after a confident match (except step 1, which already is pinned) or after the user confirms. Pins make the next resolution a single lookup. Pins live in `~/.tack/pins.yaml`, never in the project tree. ### When to unpin - The user explicitly switches focus ("I'm going to work on X now"). - The pinned route's last open tack transitions to `done` or `dropped`. - The pin references a route that no longer exists (stale pin). Do not unpin speculatively. A finished session that may resume later should leave the pin alone. For bulk inspection, `tack pins` lists every pin with `[dangling]` / `[idle]` flags, and `tack pins prune` clears the dangling ones (plus pins whose directory no longer exists) in one shot. ## Session start When invoked at session start (no arguments or "status"): 1. **CLI freshness check.** Read `${CLAUDE_PLUGIN_ROOT}/.claude-plugin/plugin.json`'s `version` and compare to `tack --version`. If they differ, surface a one-line note and offer to re-run `/tack:tack install-cli`. Skip silently if `tack` isn't on PATH. 2. **Overview.** Run `tack tree -d 2` to see all routes and their tacks. 3. **Resolve active route** using the procedure above. 4. **Register session and bind the tack.** On the active route, run `tack session $CLAUDE_CODE_SESSION_ID --tack `, where `` is the tack this session is working (see "Binding the session to a tack" below). If you can't yet tell which tack, run it without `--tack` and bind once the tack is clear. Re-run with `--tack` whenever the session's focus shifts to a different tack — the last bound tack is the current one. 5. **Brief summary.** A few lines: active route, open tacks, blocked items. The user can drill in with `tack tree ` or globs like `tack tree '**/deliverable'`. ## Binding the session to a tack A session attaches to a *route*, but a route holds many tacks. Binding the session to the specific tack it's driving — via `tack session $CLAUDE_CODE_SESSION_ID --tack ` — is what lets a fleet view (e.g. beacon's `wip`) show *which* tack a live session is on, and tell **existing** work (a session resumed on a tracked tack) from **emerging** work (a session that just spun up a new tack). Establish the link as early as you confidently can. The strongest early signal is a work-tracker URL the user pastes (or a tool emits) at the start: 1. Run `tack find --json`. 2. **One tack matches** → the session is resuming existing work. Bind to that tack: `tack session $CLAUDE_CODE_SESSION_ID --tack `. 3. **No match** → the work is emerging. Create the tack (recording the URL as its deliverable or link per "Acting on hook reminders"), then bind the session to the new tack. You don't store "existing" or "emerging" anywhere — it's read off the bound tack: a tack with a deliverable or a PR/MR/issue link is tracked/existing; one with neither is emerging. The bind is idempotent and order-preserving: binding the same tack twice is a no-op, binding a second tack appends it, and re-binding an earlier tack moves it back to the end (current focus). The tack must already exist in the route — `--tack` validates it. ## Acting on hook reminders Hooks (see `hooks/`) emit reminder text when they spot PR/MR/issue URLs in tool output or user prompts. When you see one: 1. **Resolve the active route** if you don't already have one. 2. **Identify the current tack.** If the active route has exactly one `in_progress` tack, use it. Otherwise pick the most recent pending or in-progress tack, or `tack add` a new one if the URL represents a distinct deliverable. 3. **Record the URL.** - PR/MR URLs → `tack deliverable ""` — the label is auto-derived (`#` / `!`, or `@` for a commit URL). Add `--label ""` only when you want to override the derived one (e.g. an unrecognized forge URL, or you want prose). - Other URLs (issues, docs, threads) → `tack link add "