Workflows

These skills cover the full lifecycle of a change. Most work runs through the middle phases; the situational Chart phase up front is for tasks too big or foggy to plan in one pass.

Phase	When to use it	Skills
Chart (situational)	Huge or foggy initiatives whose route can't fit in one session	/trackbed:discovery:wayfinder
Clarify	Requirements are vague, contested, or half-formed	/trackbed:discovery:interview (--siw for tracked SIW work)
Spec	Turn intent into a written source of truth	/trackbed:docs:feature-spec, /trackbed:siw:init
Break down	Split the spec into tracked issues	/trackbed:siw:generate-phases
Transfer	Make Linear the implementation source of truth	/trackbed:siw:transfer-to-linear
Implement	Build one issue at a time	/trackbed:linear:issue-implement, /trackbed:linear:issue-to-pr
Review & verify	Check quality before shipping	/trackbed:pr:code-review, /trackbed:verify:run

Most tasks begin at Clarify or Spec and flow into SIW, the local Markdown-based workflow for refining a specification and its first issue set. Approved work then transfers one way to Linear for implementation and Pull Requests. Use /trackbed:research whenever a phase needs a cited answer from primary sources, and ask for a throwaway prototype when a disposable experiment would settle one design question.

Feature specs, API design, Linear implementation planning, review resolution, agent-readiness recommendations, skill authoring and review, and completion verification weigh user experience (UX), developer experience (DX), and agent experience (AX) together. They:

• preserve established behavior and contracts outside the intended change;
• make intentional changes and material tradeoffs explicit;
• support regression claims with relevant checks.

Unchanged or inapplicable dimensions are fine; the principle never requires extra scope.

Prepare with SIW, implement with Linear

SIW refines non-trivial work into a spec-driven initial issue set, then migrates the durable planning context into Linear.

/trackbed:siw:init                         # link or create a spec, set up siw/ directory
/trackbed:siw:spec-audit                   # validate and refine the specification
/trackbed:siw:generate-phases              # break the spec into phased issues
/trackbed:siw:transfer-to-linear           # migrate specs, decisions, milestones, and issues
/trackbed:workflow:cleanup-artifacts --siw # retire local SIW files after verified transfer

See docs/siw.md for the full workflow reference.

Implement and ship a Linear issue

/trackbed:linear:issue-to-pr DISC-202 --strict --ship    # implement, review, verify, and open the PR
/trackbed:linear:issue-to-pr DISC-202 --continue --ship  # resume after an interrupted session

1. Preflight: checks Linear's target branch and confirms there is no existing Pull Request or remote branch for it. Needs a clean tree unless you pass --continue.
2. Start: moves a Backlog issue to the team's started status, preferring In Progress; any other state asks first unless --launch-confirmed covers an unstarted issue. Renames a detected Conductor workspace, best-effort.
3. Implement the issue with /trackbed:linear:issue-implement.
4. Review: freezes the issue's requirements and runs review convergence on the branch.
5. Ship (--ship only): opens the PR and runs /trackbed:pr:fix-ci until CI and review feedback are clear.
6. Hand off: summarizes what was built, what review found, and what to check when you review it.

Flag	Effect
--ship	Open the PR and stabilize CI; without it, the run stops after verification
--strict	Give every review finding an evidence-based disposition; forces the full review profile
--cycles <1-5>	Fix-and-rerun budget for review convergence (default 2)
--depth balanced|full	Raise the review profile above the branch's risk floor; it never lowers it
--adversarial-review	Also get a review from the model provider opposite your host on medium- and high-risk work; you decide any of its findings the run wants to reject
--continue	Resume on the issue's exact unpublished branch; the issue must already be started and every changed path must belong to it
--launch-confirmed	Count an earlier yes as the start confirmation, for unstarted issues only; /trackbed:linear:next cloud launches set it

/trackbed:code:plan-to-pr runs the same pipeline for one PR_PLAN_*.md file. The shipping guide covers preconditions, status changes, and the handoff in full.

Review and ship a PR

/trackbed:pr:code-review    # run specialized review agents on your branch
/trackbed:pr:resolve-review # fix the findings
/trackbed:pr:create         # restructure commits and open the PR
/trackbed:pr:fix-ci         # iterate until CI passes
/trackbed:pr:shape-up       # later: rebase, fix CI, answer AI reviewers as needed

/trackbed:pr:create and /trackbed:pr:fix-ci run unattended, including history rewrites and force-pushes; add --manual to keep their prompts. The shipping guide covers all five skills that work this way.

/trackbed:pr:shape-up also runs without prompts of its own: it rebases with a lease, pushes CI fixes, and posts replies to AI reviewers, but never to people. See shaping up an open Pull Request.

More review skills cover product, convention, UX, and GitHub-reviewer flows. Which one should you use?

Need	Use
How much review the branch needs, which review commands to run, and which decisions need a human	/trackbed:pr:triage-risk
Anything in the branch that looks strange, unusual, or unnecessary	/trackbed:pr:gut-check
Independent review by a provider different from the active Claude Code or Codex host	/trackbed:pr:adversarial-review
Code-quality findings on your local branch	/trackbed:pr:code-review
Final code-review pass before commit, ship, or closeout	/trackbed:pr:code-review --loop
Convention drift and overcaution vs. established codebase practice	/trackbed:pr:convention-review
Needless complexity and unlikely-edge-case hedging vs. what the task requires	/trackbed:pr:overengineering-review
Product-value, flow, copy, and edge-case review, plus UX, visual, and accessibility review when UI files changed	/trackbed:pr:product-review
Which PRs wait on your review, and where each one stands	/trackbed:pr:review-queue
Review someone else's GitHub PR as the assigned reviewer	/trackbed:pr:github-review
Triage and respond to review comments on your own PR	/trackbed:pr:github-review-reply
Rebase, fix CI, and answer AI reviewer comments on your open PR in one run	/trackbed:pr:shape-up
Implement fixes from local review findings	/trackbed:pr:resolve-review
Whether an open PR's title and body still match the branch diff	/trackbed:pr:generate-description --check

/trackbed:pr:github-review is report-only by default; it writes a pending review or submits one only when you explicitly ask. A re-review covers only what changed since your last review, and --stack maps a whole stack first. Review skills handle stacked Pull Requests one layer at a time, and interrupted reviews resume within 24 hours. The review guide covers reviewer models, review convergence, stacks, and GitHub write rules.

New work starts from the repository's workbench branch. Set it with git config --local trackbed.baseBranch <branch> when it differs from the remote default; the shipping guide explains how the skills choose it.

/trackbed:pr:stack uses stack numbers for remote checkout and whole-stack merges. Checkout recovery restores the original branch before retrying. Partial merges stop on stack-number collisions. Links preserve supplied PR identifiers; bare leading numbers require stack-number and local-branch collision checks, while explicit PR URLs bypass numeric selection.

Before a stack rebase or sync changes a branch checked out in another Conductor workspace, /trackbed:pr:stack and /trackbed:pr:rebase name that workspace and wait for your confirmation. They resolve conflicts where gh-stack paused them and pass --accept-base-change only when you approve it.

Inspect and test a live app

/trackbed:browse http://localhost:3000         # navigate, screenshot, inspect
/trackbed:qa http://localhost:3000             # structured QA with evidence
/trackbed:product:review http://localhost:3000 # whole-product experience review

Quick utilities

/trackbed:verify:run          # run tests, linting, and type checks for changed code
/trackbed:setup               # report missing local workflow dependencies
/trackbed:visual:explain      # generate an HTML diagram or explainer page
/trackbed:docs:to-markdown    # convert PDF, Word, Excel, or images to Markdown
/trackbed:code:refactor-pass  # simplification + AI-slop pass on recent changes
/trackbed:code:work-from-plan # route and execute a standalone implementation plan

All skills are listed in the reference below. Background skills, such as commit-message guidance, run automatically.