tcw

Drives `tcw capabilities` — the Capabilities axis of TCW (what a user can do). Use when a tcw work item has a product (user-facing) delta, or when coordinating capability wording across repos. The taxonomy axis is the `taxonomy` skill, the work axis the `work` skill.

Drive a TCW work item from wherever it is through implementation, stopping for user verification before closeout.

Stop the work in hand gracefully, write down what resuming needs, and wait for the user.

Plan a TCW work item from an existing item or the user's chat request, producing the lifecycle planning artifacts in the work item folder.

Triage raw entries in the TCW work inbox into tracked work items.

Verify a finished TCW work item with the user and record the acceptance decision.

Changes how a project that already uses TCW is configured. Use when a user wants to set up or change lifecycle bindings (skills or commands run at a stage or transition), hook limits, the Definition of Done, documentation entries that track which documents a change must update, an external tracker, where a store lives, connected projects, or inherited taxonomy or capabilities. Getting TCW working in the first place is the `setup` skill.

Use when completing a coding task and deciding whether documentation needs updating. Use when code changes have been made and you need to check if README, changelog, guides, or other docs should reflect those changes. Use when a project has documentation entries — from `tcw work docs`, or a `## Documentation Sync` section in its CLAUDE.md — and a change may have fired one. Use after completing development work to update release notes and changelogs. Use when the user asks to cut a new version of a project.

Use when asked to work TCW items autonomously, unattended, or "without asking me" — drives one or more items to completion via the commands-drive-work-to-completion skill, consulting read-only advisors in place of every human checkpoint (by default Codex and an Opus subagent; a project can name its own).

Teaches a TCW user how to report a bug, issue, or suggestion back to the TCW project by filing a GitHub issue on the TCW repository, and hands them a ready-to-fill skeleton for each kind of report. Use when a user hits a `tcw` bug, wants to request a feature, or has feedback on TCW itself — not for tracking the user's own project work (that is the `work` skill).

Triages the GitHub issues on **your own project's** repo and turns the ones worth acting on into `tcw work` items. Use when a user wants to check their project's GitHub issues, work through the issue backlog, or convert issues into tracked work. Most issues should not become work items, so triage decides first and every issue gets an offered reply. To file an issue *upstream to the TCW project* instead, that is the `extras-report` skill.

Use when a TCW work item surfaced a problem worth understanding — verification rejected the work, a spec claim turned out false, or something shipped that should not have. Finds which lifecycle stage could first have caught it.

Gets TCW working where it does not work yet. Use when a project does not use TCW yet, when the `tcw` CLI is missing, broken, or stale (not on PATH, `tcw --version` fails, or a plugin update left it behind), when an existing TCW project needs its stores or connected projects on a new machine, or when starting a taxonomy or capabilities ledger from an existing codebase. Changing the configuration of a project that already works is the `configure` skill.

Drives `tcw taxonomy` — the Taxonomy axis of TCW (the registered Vocabulary + Feature registry). Use when declaring or maintaining a project's registered language and features. The capabilities axis is the `capabilities` skill, the work axis the `work` skill.

Drives the `tcw work` change-tracking CLI — the Work axis of TCW (Taxonomy · Capabilities · Work). Use when planning, starting, implementing, verifying, or completing a tcw work item; resuming one across sessions; triaging a docs/work/inbox request; decomposing an item into child items; or coordinating a cross-node epic. Does not reimplement the CLI.

Turns an idea for a piece of work into a tracked TCW work item, or adds it to the item or inbox entry that already covers it, after checking the board and the work inbox and recording blockers, references and origin.

Read a TCW lifecycle stage in one piece — the stage's own working document composed with the instructions this project resolves for it. Use when working a lifecycle stage (inbox, request, spec, plan, implement, verify, postmortem) for a work item, instead of opening the stage document and running the CLI separately.