tcw-cli 2.0.2__tar.gz → 2.1.2__tar.gz

{tcw_cli-2.0.2/tcw_cli.egg-info → tcw_cli-2.1.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: tcw-cli
-Version: 2.0.2
+Version: 2.1.2
 Summary: Taxonomy · Capabilities · Work — a storage-abstracted framework for describing and evolving a software project.
 License:                                  Apache License
                                    Version 2.0, January 2004
@@ -229,6 +229,28 @@ They link by one-directional pointers — a capability names the taxonomy terms
 involves, a work item names the capability it changes — and never copy each
 other's content.
 
+## Contents
+
+- [The problem](#the-problem)
+- [What it looks like](#what-it-looks-like)
+- [Why many repositories is the case it is built for](#why-many-repositories-is-the-case-it-is-built-for)
+- [What it deliberately refuses](#what-it-deliberately-refuses)
+- [What adopting it costs](#what-adopting-it-costs)
+- [Who it's for](#who-its-for)
+- [Storage abstraction (the prime directive)](#storage-abstraction-the-prime-directive)
+- [Install](#install)
+  - [As a plugin (recommended)](#as-a-plugin-recommended)
+  - [As a Python package](#as-a-python-package)
+  - [In a cloud environment](#in-a-cloud-environment)
+- [Quickstart](#quickstart)
+- [Working from your Jira tickets](#working-from-your-jira-tickets)
+- [Documentation](#documentation)
+- [Skills — the judgment layer](#skills--the-judgment-layer)
+  - [Reading a lifecycle stage](#reading-a-lifecycle-stage)
+  - [Review agents and slash commands](#review-agents-and-slash-commands)
+- [Status](#status)
+- [Further reading](#further-reading)
+
 ---
 
 ## The problem
@@ -407,8 +429,9 @@ Or, in the Claude **web app** or **desktop app**, open the plugin directory, add
 by installing `tcw-cli` from PyPI with `pipx`, so one installed mid-session
 cannot run until the next one begins. That first session needs network access. It
 installs over an existing `pipx install tcw-cli` rather than beside it, and
-leaves a development checkout (`pip install -e .`) alone. Run `/tcw-doctor` any
-time `tcw` goes missing or looks wrong.
+leaves a development checkout (`pip install -e .`) alone. If `tcw` goes missing
+anyway, `pipx install tcw-cli` is the whole fix — the **`tcw-plugin`** skill
+carries the cases where it is not.
 
 In **Codex** (skills only, no slash commands):
 
@@ -439,6 +462,89 @@ additionally requires **Node.js ≥ 22.12**; every other command is Python-only.
 Released wheels carry the prebuilt web assets, so there is no frontend build step
 and no network needed after install.
 
+### In a cloud environment
+
+A cloud agent session — Claude Code on the web, a Codex container, a CI job —
+starts from a clean image and is thrown away when it ends, so a `tcw` you install
+by hand is gone by the next one. Install it **from your repository**, with a
+session-start hook, and every session gets it without anyone remembering to.
+
+Add a script to your repository:
+
+```sh
+#!/usr/bin/env bash
+# Make `tcw` available in a disposable agent container.
+# Exit 0 on every path — a session must start even when this cannot finish.
+set -u
+
+command -v tcw >/dev/null 2>&1 && exit 0
+
+# pipx where it exists; otherwise install into the container's own interpreter.
+# That is the right answer *here* and nowhere else: the container is disposable
+# and single-purpose, so there is no user environment to damage.
+if command -v pipx >/dev/null 2>&1; then
+    pipx install tcw-cli >/dev/null 2>&1 || echo "tcw: pipx install tcw-cli failed"
+elif ! python3 -m pip install tcw-cli >/dev/null 2>&1 &&
+    ! python3 -m pip install tcw-cli --break-system-packages >/dev/null 2>&1; then
+    echo "tcw: pip install tcw-cli failed — the tcw CLI is not available."
+fi
+
+# An install that landed outside PATH is installed and unusable. $CLAUDE_ENV_FILE
+# is the harness's own channel for repairing that.
+if ! command -v tcw >/dev/null 2>&1 && [ -n "${CLAUDE_ENV_FILE:-}" ]; then
+    userbin="$(python3 -m site --user-base 2>/dev/null)/bin"
+    [ -x "$userbin/tcw" ] && echo "export PATH=\"$userbin:\$PATH\"" >>"$CLAUDE_ENV_FILE"
+fi
+
+exit 0
+```
+
+Then wire it to `SessionStart` in your repository's `.claude/settings.json`:
+
+```json
+{
+    "hooks": {
+        "SessionStart": [
+            {
+                "hooks": [
+                    {
+                        "type": "command",
+                        "command": "\"${CLAUDE_PROJECT_DIR}\"/scripts/tcw_session_setup.sh"
+                    }
+                ]
+            }
+        ]
+    }
+}
+```
+
+Three things make the difference between a hook that helps and one that wastes a
+session:
+
+- **Exit 0 on every path, and print only on failure.** A hook that fails the
+  session start over a missing CLI has cost more than the CLI was worth.
+- **Print to stdout.** Claude Code adds a `SessionStart` hook's stdout to the
+  agent's context, where it will be read; stderr becomes a transcript notice
+  nobody sees.
+- **Check for `tcw` first.** The hook runs every session, including the ones
+  where a previous install is still there.
+
+**If your work store lives in another repository**, the container holds only the
+repository it cloned, so the board is declared but absent. Run `tcw provision`
+after the install — it obtains what the checkout does not have, and does nothing
+on a machine that already holds it. See
+[Working across repositories](docs/guide/multi-repo.md).
+
+Installing the **plugin** in such a session is a separate step from installing the
+CLI, and only needed where the harness does not carry your plugins in: append
+`claude plugin marketplace add brocef/TCW` and `claude plugin install tcw@tcw` to
+the same script, guarded on `command -v claude`.
+
+This repository's own [`scripts/remote_session_setup.sh`](scripts/remote_session_setup.sh)
+is the same pattern written for a _contributor_ rather than a user — it installs
+the checkout with `pip install -e` instead of the release from PyPI, and installs
+the plugin from the checkout too. Read it as the worked example.
+
 ## Quickstart
 
 ```sh
@@ -464,6 +570,79 @@ studies your code, proposes a first draft, refines it with you, and writes it.
 
 ---
 
+## Working from your Jira tickets
+
+A project can name the Jira Cloud site it uses, read its tickets, and take one as
+a work item.
+
+```sh
+tcw work tracker list              # tickets the configured query selects
+tcw work tracker show ENG-482      # one ticket, and whether it is yours to take
+tcw work tracker import ENG-482    # take the ticket and get a work item for it
+tcw work tracker link <slug> ENG-482       # take it for an item you already have
+tcw work tracker unlink <slug> --reason "wrong ticket"
+```
+
+Configuration goes in the node's `tcw-config.yaml`:
+
+```yaml
+work:
+    tracker:
+        provider: jira-cloud
+        base-url: https://yourcompany.atlassian.net
+        candidate-query: assignee = currentUser() AND status = "To Do"
+        credentials:
+            email-env: TCW_JIRA_EMAIL
+            token-env: TCW_JIRA_API_TOKEN
+        transitions:
+            claim: Start Progress
+        timeout-seconds: 15 # optional
+```
+
+**Credentials are named, never stored.** The file holds the names of two
+environment variables; TCW reads them at the moment it makes a request, so a token
+cannot be committed by accident.
+
+`tracker show` reports two different things, and the distinction matters:
+
+- **claimable** — whether this ticket currently offers the transition you
+  configured as the claim.
+- **exclusive** — whether your Jira workflow would actually refuse a second person
+  trying to take the same ticket.
+
+Many Jira workflows allow a status change from any status, including the one it
+leads to. On a workflow like that, two people who both take one ticket both
+succeed and neither is told. So a ticket that has been started reports
+`not exclusive` when that is the truth, and a ticket that has not been started
+reports `not determined`, because it cannot show you what happens to the second
+person. Making a workflow exclusive is a Jira administration change, not something
+TCW can do for you.
+
+**Taking a ticket.** `tracker import` moves the ticket through your configured
+claim transition, assigns it to you if nobody had it, and then checks Jira again:
+only when the ticket really is started and yours does it create a backlog item. The
+ticket's text goes into the item as its raw input, with a link back, and the item's
+request still gets written the usual way. A ticket assigned to someone else is
+refused, and so is one that is already closed.
+
+Running `import` again for the same ticket gives you the same item rather than a
+second one, and if the first run took the ticket but stopped before creating the
+item, the second run finishes the job. One ticket can deliberately become several
+items with `--part api`, `--part web`, and so on. `unlink` removes a wrong binding
+and keeps a record of it with your reason; it never changes the ticket in Jira.
+
+Two limits to know. On a workflow that lets anyone start a ticket from any status,
+two people can both take the same ticket, and TCW does not stop that. And two runs
+by the same Jira account at the same moment can both create an item.
+
+Two guarantees worth stating plainly. A project with no `tracker` block behaves
+exactly as before, with no new required setting and no network access. And
+`tcw validate` never contacts the tracker, which matters because projects commonly
+run it when closing a work item — finishing your work must not depend on Jira being
+reachable.
+
+---
+
 ## Documentation
 
 | Document                                                             | Covers                                                                                                                 |
@@ -483,21 +662,22 @@ Every command group also has `--help`, and a `check` that validates its tree.
 
 ## Skills — the judgment layer
 
-The CLI is the _mechanism_. Fourteen skills in [`skills/`](skills/) supply the
-_judgment_ that drives it — the parts a deterministic tool cannot decide. Eight
+The CLI is the _mechanism_. Fifteen skills in [`skills/`](skills/) supply the
+_judgment_ that drives it — the parts a deterministic tool cannot decide. Nine
 carry a distinct procedure; the other six all compose one lifecycle stage and
 are listed together at the end.
 
-| Skill                                                      | What it does                                                                                                                           |
-| ---------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
-| [`tcw-work`](skills/tcw-work/SKILL.md)                     | Plans a request through spec and plan, drives implementation and verification, triages the inbox, runs the lifecycle, decomposes epics |
-| [`tcw-capabilities`](skills/tcw-capabilities/SKILL.md)     | The capability-delta planning check, contradiction detection, and the ledger flip at completion                                        |
-| [`tcw-taxonomy`](skills/tcw-taxonomy/SKILL.md)             | Declaring vocabulary and features, linking them, and federating shared vocabulary                                                      |
-| [`tcw-plugin`](skills/tcw-plugin/SKILL.md)                 | Installs and repairs the CLI; the source of the `/tcw-doctor` procedure                                                                |
-| [`tcw-report`](skills/tcw-report/SKILL.md)                 | Reporting a `tcw` bug or suggestion upstream to [this project's issues](https://github.com/brocef/TCW/issues)                          |
-| [`tcw-triage-issues`](skills/tcw-triage-issues/SKILL.md)   | Sweeps **your** project's GitHub issues and turns the ones worth doing into work items                                                 |
-| [`documentation-sync`](skills/documentation-sync/SKILL.md) | Keeps README, changelogs, release notes, and driving skills moving with the code that changes them                                     |
-| [`tcw-post-mortem`](skills/tcw-post-mortem/SKILL.md)       | Finds which lifecycle stage could first have caught a problem, once one has surfaced                                                   |
+| Skill                                                      | What it does                                                                                                                                               |
+| ---------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [`tcw-work`](skills/tcw-work/SKILL.md)                     | Plans a request through spec and plan, drives implementation and verification, triages the inbox, runs the lifecycle, decomposes epics, searches the board |
+| [`tcw-capabilities`](skills/tcw-capabilities/SKILL.md)     | The capability-delta planning check, contradiction detection, and the ledger flip at completion                                                            |
+| [`tcw-taxonomy`](skills/tcw-taxonomy/SKILL.md)             | Declaring vocabulary and features, linking them, and federating shared vocabulary                                                                          |
+| [`tcw-plugin`](skills/tcw-plugin/SKILL.md)                 | Installs the CLI from PyPI, and maps the other skills                                                                                                      |
+| [`tcw-report`](skills/tcw-report/SKILL.md)                 | Reporting a `tcw` bug or suggestion upstream to [this project's issues](https://github.com/brocef/TCW/issues)                                              |
+| [`tcw-triage-issues`](skills/tcw-triage-issues/SKILL.md)   | Sweeps **your** project's GitHub issues and turns the ones worth doing into work items                                                                     |
+| [`documentation-sync`](skills/documentation-sync/SKILL.md) | Keeps README, changelogs, release notes, and driving skills moving with the code that changes them                                                         |
+| [`tcw-post-mortem`](skills/tcw-post-mortem/SKILL.md)       | Finds which lifecycle stage could first have caught a problem, once one has surfaced                                                                       |
+| [`autonomous-work`](skills/autonomous-work/SKILL.md)       | Drives work items to completion unattended, consulting two read-only advisors wherever the lifecycle would ask you                                         |
 
 They name `tcw` commands and never reimplement tool logic: mechanism stays in the
 binary, judgment stays in the skills.
@@ -515,13 +695,16 @@ The other five bake their stage in and ask only for the work item, which is
 optional: `tcw-work-stage-request`, `tcw-work-stage-spec`,
 `tcw-work-stage-plan`, `tcw-work-stage-implement`, `tcw-work-stage-verify`.
 
+### Review agents and slash commands
+
 Three read-only review agents ship alongside them — `tcw-verifier`,
 `tcw-backlog-auditor`, and `tcw-post-mortem`, which accelerates the skill of the
 same name — plus slash commands for each skill's main procedure
 (`/tcw-plan-work`, `/tcw-drive-work-to-completion`, `/tcw-verify-work`,
-`/tcw-process-inbox`, `/tcw-triage-issues`, `/tcw-audit-work-backlog`,
-`/tcw-taxonomy-init`, `/tcw-capabilities-init`, `/tcw-docs-sync-setup`,
-`/tcw-cut-version`, `/tcw-post-mortem`, `/tcw-doctor`).
+`/tcw-process-inbox`, `/tcw-work-search`, `/tcw-triage-issues`,
+`/tcw-audit-work-backlog`, `/tcw-consolidate-plans`, `/tcw-taxonomy-init`,
+`/tcw-capabilities-init`, `/tcw-docs-sync-setup`, `/tcw-cut-version`,
+`/tcw-post-mortem`).
 
 ---
 

{tcw_cli-2.0.2 → tcw_cli-2.1.2}/README.md

@@ -13,6 +13,28 @@ They link by one-directional pointers — a capability names the taxonomy terms
 involves, a work item names the capability it changes — and never copy each
 other's content.
 
+## Contents
+
+- [The problem](#the-problem)
+- [What it looks like](#what-it-looks-like)
+- [Why many repositories is the case it is built for](#why-many-repositories-is-the-case-it-is-built-for)
+- [What it deliberately refuses](#what-it-deliberately-refuses)
+- [What adopting it costs](#what-adopting-it-costs)
+- [Who it's for](#who-its-for)
+- [Storage abstraction (the prime directive)](#storage-abstraction-the-prime-directive)
+- [Install](#install)
+  - [As a plugin (recommended)](#as-a-plugin-recommended)
+  - [As a Python package](#as-a-python-package)
+  - [In a cloud environment](#in-a-cloud-environment)
+- [Quickstart](#quickstart)
+- [Working from your Jira tickets](#working-from-your-jira-tickets)
+- [Documentation](#documentation)
+- [Skills — the judgment layer](#skills--the-judgment-layer)
+  - [Reading a lifecycle stage](#reading-a-lifecycle-stage)
+  - [Review agents and slash commands](#review-agents-and-slash-commands)
+- [Status](#status)
+- [Further reading](#further-reading)
+
 ---
 
 ## The problem
@@ -191,8 +213,9 @@ Or, in the Claude **web app** or **desktop app**, open the plugin directory, add
 by installing `tcw-cli` from PyPI with `pipx`, so one installed mid-session
 cannot run until the next one begins. That first session needs network access. It
 installs over an existing `pipx install tcw-cli` rather than beside it, and
-leaves a development checkout (`pip install -e .`) alone. Run `/tcw-doctor` any
-time `tcw` goes missing or looks wrong.
+leaves a development checkout (`pip install -e .`) alone. If `tcw` goes missing
+anyway, `pipx install tcw-cli` is the whole fix — the **`tcw-plugin`** skill
+carries the cases where it is not.
 
 In **Codex** (skills only, no slash commands):
 
@@ -223,6 +246,89 @@ additionally requires **Node.js ≥ 22.12**; every other command is Python-only.
 Released wheels carry the prebuilt web assets, so there is no frontend build step
 and no network needed after install.
 
+### In a cloud environment
+
+A cloud agent session — Claude Code on the web, a Codex container, a CI job —
+starts from a clean image and is thrown away when it ends, so a `tcw` you install
+by hand is gone by the next one. Install it **from your repository**, with a
+session-start hook, and every session gets it without anyone remembering to.
+
+Add a script to your repository:
+
+```sh
+#!/usr/bin/env bash
+# Make `tcw` available in a disposable agent container.
+# Exit 0 on every path — a session must start even when this cannot finish.
+set -u
+
+command -v tcw >/dev/null 2>&1 && exit 0
+
+# pipx where it exists; otherwise install into the container's own interpreter.
+# That is the right answer *here* and nowhere else: the container is disposable
+# and single-purpose, so there is no user environment to damage.
+if command -v pipx >/dev/null 2>&1; then
+    pipx install tcw-cli >/dev/null 2>&1 || echo "tcw: pipx install tcw-cli failed"
+elif ! python3 -m pip install tcw-cli >/dev/null 2>&1 &&
+    ! python3 -m pip install tcw-cli --break-system-packages >/dev/null 2>&1; then
+    echo "tcw: pip install tcw-cli failed — the tcw CLI is not available."
+fi
+
+# An install that landed outside PATH is installed and unusable. $CLAUDE_ENV_FILE
+# is the harness's own channel for repairing that.
+if ! command -v tcw >/dev/null 2>&1 && [ -n "${CLAUDE_ENV_FILE:-}" ]; then
+    userbin="$(python3 -m site --user-base 2>/dev/null)/bin"
+    [ -x "$userbin/tcw" ] && echo "export PATH=\"$userbin:\$PATH\"" >>"$CLAUDE_ENV_FILE"
+fi
+
+exit 0
+```
+
+Then wire it to `SessionStart` in your repository's `.claude/settings.json`:
+
+```json
+{
+    "hooks": {
+        "SessionStart": [
+            {
+                "hooks": [
+                    {
+                        "type": "command",
+                        "command": "\"${CLAUDE_PROJECT_DIR}\"/scripts/tcw_session_setup.sh"
+                    }
+                ]
+            }
+        ]
+    }
+}
+```
+
+Three things make the difference between a hook that helps and one that wastes a
+session:
+
+- **Exit 0 on every path, and print only on failure.** A hook that fails the
+  session start over a missing CLI has cost more than the CLI was worth.
+- **Print to stdout.** Claude Code adds a `SessionStart` hook's stdout to the
+  agent's context, where it will be read; stderr becomes a transcript notice
+  nobody sees.
+- **Check for `tcw` first.** The hook runs every session, including the ones
+  where a previous install is still there.
+
+**If your work store lives in another repository**, the container holds only the
+repository it cloned, so the board is declared but absent. Run `tcw provision`
+after the install — it obtains what the checkout does not have, and does nothing
+on a machine that already holds it. See
+[Working across repositories](docs/guide/multi-repo.md).
+
+Installing the **plugin** in such a session is a separate step from installing the
+CLI, and only needed where the harness does not carry your plugins in: append
+`claude plugin marketplace add brocef/TCW` and `claude plugin install tcw@tcw` to
+the same script, guarded on `command -v claude`.
+
+This repository's own [`scripts/remote_session_setup.sh`](scripts/remote_session_setup.sh)
+is the same pattern written for a _contributor_ rather than a user — it installs
+the checkout with `pip install -e` instead of the release from PyPI, and installs
+the plugin from the checkout too. Read it as the worked example.
+
 ## Quickstart
 
 ```sh
@@ -248,6 +354,79 @@ studies your code, proposes a first draft, refines it with you, and writes it.
 
 ---
 
+## Working from your Jira tickets
+
+A project can name the Jira Cloud site it uses, read its tickets, and take one as
+a work item.
+
+```sh
+tcw work tracker list              # tickets the configured query selects
+tcw work tracker show ENG-482      # one ticket, and whether it is yours to take
+tcw work tracker import ENG-482    # take the ticket and get a work item for it
+tcw work tracker link <slug> ENG-482       # take it for an item you already have
+tcw work tracker unlink <slug> --reason "wrong ticket"
+```
+
+Configuration goes in the node's `tcw-config.yaml`:
+
+```yaml
+work:
+    tracker:
+        provider: jira-cloud
+        base-url: https://yourcompany.atlassian.net
+        candidate-query: assignee = currentUser() AND status = "To Do"
+        credentials:
+            email-env: TCW_JIRA_EMAIL
+            token-env: TCW_JIRA_API_TOKEN
+        transitions:
+            claim: Start Progress
+        timeout-seconds: 15 # optional
+```
+
+**Credentials are named, never stored.** The file holds the names of two
+environment variables; TCW reads them at the moment it makes a request, so a token
+cannot be committed by accident.
+
+`tracker show` reports two different things, and the distinction matters:
+
+- **claimable** — whether this ticket currently offers the transition you
+  configured as the claim.
+- **exclusive** — whether your Jira workflow would actually refuse a second person
+  trying to take the same ticket.
+
+Many Jira workflows allow a status change from any status, including the one it
+leads to. On a workflow like that, two people who both take one ticket both
+succeed and neither is told. So a ticket that has been started reports
+`not exclusive` when that is the truth, and a ticket that has not been started
+reports `not determined`, because it cannot show you what happens to the second
+person. Making a workflow exclusive is a Jira administration change, not something
+TCW can do for you.
+
+**Taking a ticket.** `tracker import` moves the ticket through your configured
+claim transition, assigns it to you if nobody had it, and then checks Jira again:
+only when the ticket really is started and yours does it create a backlog item. The
+ticket's text goes into the item as its raw input, with a link back, and the item's
+request still gets written the usual way. A ticket assigned to someone else is
+refused, and so is one that is already closed.
+
+Running `import` again for the same ticket gives you the same item rather than a
+second one, and if the first run took the ticket but stopped before creating the
+item, the second run finishes the job. One ticket can deliberately become several
+items with `--part api`, `--part web`, and so on. `unlink` removes a wrong binding
+and keeps a record of it with your reason; it never changes the ticket in Jira.
+
+Two limits to know. On a workflow that lets anyone start a ticket from any status,
+two people can both take the same ticket, and TCW does not stop that. And two runs
+by the same Jira account at the same moment can both create an item.
+
+Two guarantees worth stating plainly. A project with no `tracker` block behaves
+exactly as before, with no new required setting and no network access. And
+`tcw validate` never contacts the tracker, which matters because projects commonly
+run it when closing a work item — finishing your work must not depend on Jira being
+reachable.
+
+---
+
 ## Documentation
 
 | Document                                                             | Covers                                                                                                                 |
@@ -267,21 +446,22 @@ Every command group also has `--help`, and a `check` that validates its tree.
 
 ## Skills — the judgment layer
 
-The CLI is the _mechanism_. Fourteen skills in [`skills/`](skills/) supply the
-_judgment_ that drives it — the parts a deterministic tool cannot decide. Eight
+The CLI is the _mechanism_. Fifteen skills in [`skills/`](skills/) supply the
+_judgment_ that drives it — the parts a deterministic tool cannot decide. Nine
 carry a distinct procedure; the other six all compose one lifecycle stage and
 are listed together at the end.
 
-| Skill                                                      | What it does                                                                                                                           |
-| ---------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
-| [`tcw-work`](skills/tcw-work/SKILL.md)                     | Plans a request through spec and plan, drives implementation and verification, triages the inbox, runs the lifecycle, decomposes epics |
-| [`tcw-capabilities`](skills/tcw-capabilities/SKILL.md)     | The capability-delta planning check, contradiction detection, and the ledger flip at completion                                        |
-| [`tcw-taxonomy`](skills/tcw-taxonomy/SKILL.md)             | Declaring vocabulary and features, linking them, and federating shared vocabulary                                                      |
-| [`tcw-plugin`](skills/tcw-plugin/SKILL.md)                 | Installs and repairs the CLI; the source of the `/tcw-doctor` procedure                                                                |
-| [`tcw-report`](skills/tcw-report/SKILL.md)                 | Reporting a `tcw` bug or suggestion upstream to [this project's issues](https://github.com/brocef/TCW/issues)                          |
-| [`tcw-triage-issues`](skills/tcw-triage-issues/SKILL.md)   | Sweeps **your** project's GitHub issues and turns the ones worth doing into work items                                                 |
-| [`documentation-sync`](skills/documentation-sync/SKILL.md) | Keeps README, changelogs, release notes, and driving skills moving with the code that changes them                                     |
-| [`tcw-post-mortem`](skills/tcw-post-mortem/SKILL.md)       | Finds which lifecycle stage could first have caught a problem, once one has surfaced                                                   |
+| Skill                                                      | What it does                                                                                                                                               |
+| ---------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [`tcw-work`](skills/tcw-work/SKILL.md)                     | Plans a request through spec and plan, drives implementation and verification, triages the inbox, runs the lifecycle, decomposes epics, searches the board |
+| [`tcw-capabilities`](skills/tcw-capabilities/SKILL.md)     | The capability-delta planning check, contradiction detection, and the ledger flip at completion                                                            |
+| [`tcw-taxonomy`](skills/tcw-taxonomy/SKILL.md)             | Declaring vocabulary and features, linking them, and federating shared vocabulary                                                                          |
+| [`tcw-plugin`](skills/tcw-plugin/SKILL.md)                 | Installs the CLI from PyPI, and maps the other skills                                                                                                      |
+| [`tcw-report`](skills/tcw-report/SKILL.md)                 | Reporting a `tcw` bug or suggestion upstream to [this project's issues](https://github.com/brocef/TCW/issues)                                              |
+| [`tcw-triage-issues`](skills/tcw-triage-issues/SKILL.md)   | Sweeps **your** project's GitHub issues and turns the ones worth doing into work items                                                                     |
+| [`documentation-sync`](skills/documentation-sync/SKILL.md) | Keeps README, changelogs, release notes, and driving skills moving with the code that changes them                                                         |
+| [`tcw-post-mortem`](skills/tcw-post-mortem/SKILL.md)       | Finds which lifecycle stage could first have caught a problem, once one has surfaced                                                                       |
+| [`autonomous-work`](skills/autonomous-work/SKILL.md)       | Drives work items to completion unattended, consulting two read-only advisors wherever the lifecycle would ask you                                         |
 
 They name `tcw` commands and never reimplement tool logic: mechanism stays in the
 binary, judgment stays in the skills.
@@ -299,13 +479,16 @@ The other five bake their stage in and ask only for the work item, which is
 optional: `tcw-work-stage-request`, `tcw-work-stage-spec`,
 `tcw-work-stage-plan`, `tcw-work-stage-implement`, `tcw-work-stage-verify`.
 
+### Review agents and slash commands
+
 Three read-only review agents ship alongside them — `tcw-verifier`,
 `tcw-backlog-auditor`, and `tcw-post-mortem`, which accelerates the skill of the
 same name — plus slash commands for each skill's main procedure
 (`/tcw-plan-work`, `/tcw-drive-work-to-completion`, `/tcw-verify-work`,
-`/tcw-process-inbox`, `/tcw-triage-issues`, `/tcw-audit-work-backlog`,
-`/tcw-taxonomy-init`, `/tcw-capabilities-init`, `/tcw-docs-sync-setup`,
-`/tcw-cut-version`, `/tcw-post-mortem`, `/tcw-doctor`).
+`/tcw-process-inbox`, `/tcw-work-search`, `/tcw-triage-issues`,
+`/tcw-audit-work-backlog`, `/tcw-consolidate-plans`, `/tcw-taxonomy-init`,
+`/tcw-capabilities-init`, `/tcw-docs-sync-setup`, `/tcw-cut-version`,
+`/tcw-post-mortem`).
 
 ---
 

{tcw_cli-2.0.2 → tcw_cli-2.1.2}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "tcw-cli"
-version = "2.0.2"
+version = "2.1.2"
 description = "Taxonomy · Capabilities · Work — a storage-abstracted framework for describing and evolving a software project."
 readme = "README.md"
 requires-python = ">=3.11"
@@ -35,4 +35,11 @@ include = ["tcw*"]
 
 [tool.pytest.ini_options]
 testpaths = ["tests"]
+# The repository root on sys.path, so `from evals import ...` resolves. The
+# eval-harness tests import it, and `evals` is deliberately not a published
+# package (`packages.find` includes only `tcw*`), so the editable install does
+# not put it there. `python -m pytest` happened to work anyway — that form puts
+# the current directory on sys.path and bare `pytest` does not — which is why
+# CI, which runs bare `pytest`, was the only place this failed.
+pythonpath = ["."]
 norecursedirs = [".venv", "build", "dist", "*.egg-info"]

tcw_cli-2.1.2/tcw/__init__.py

@@ -0,0 +1 @@
+__version__ = "2.1.2"

{tcw_cli-2.0.2 → tcw_cli-2.1.2}/tcw/capabilities/cli.py

@@ -9,7 +9,8 @@ from tcw.store.base import AmbiguousRef
 from tcw.store.fs import FsCapabilitiesStore, find_node, git_root
 
 NAME = "capabilities"
-SUBCOMMANDS = {"init", "list", "show", "path", "add", "search", "check", "set", "reset", "extends", "drift"}
+SUBCOMMANDS = {"init", "list", "show", "path", "add", "search", "check", "set", "reset", "rm",
+               "extends", "drift"}
 DEFAULT_SUBCOMMAND = "show"  # `tcw capabilities <path>` == `tcw capabilities show <path>`
 
 
@@ -129,6 +130,19 @@ def _reset(args: argparse.Namespace) -> int:
     return 0
 
 
+def _rm(args: argparse.Namespace) -> int:
+    st = _store()
+    if st is None:
+        return 1
+    try:
+        st.remove(args.id)
+    except (ValueError, RefError) as e:              # AmbiguousRef carries its own message
+        print(f"tcw capabilities rm: {e}", file=sys.stderr)
+        return 1
+    print(f"Removed capability {args.id}")
+    return 0
+
+
 def _search(args: argparse.Namespace) -> int:
     st = _store()
     if st is None:
@@ -294,6 +308,10 @@ def add_subparser(sub: argparse._SubParsersAction) -> None:
     prst.add_argument("id", metavar="path")
     prst.set_defaults(func=_reset)
 
+    prm = g.add_parser("rm", help="remove a local capability")
+    prm.add_argument("id", metavar="path")
+    prm.set_defaults(func=_rm)
+
     pse = g.add_parser("search", help="search names + bodies")
     pse.add_argument("query")
     pse.set_defaults(func=_search)

{tcw_cli-2.0.2 → tcw_cli-2.1.2}/tcw/cli.py

@@ -535,6 +535,15 @@ def main(argv: list[str] | None = None) -> int:
     except ValueError as error:
         print(f"tcw: {error}", file=sys.stderr)
         return 1
+    except yaml.YAMLError as error:
+        # A malformed YAML file is the user's, not a bug in TCW, so it reads as
+        # a message rather than a traceback. Here rather than at each of the
+        # twenty-odd `load_yaml` calls that do not catch it: refusing is already
+        # the right answer at every one of them — `init` must not overwrite a
+        # config it cannot read — and only the presentation was wrong. The
+        # loader's message names the file.
+        print(f"tcw: {error}", file=sys.stderr)
+        return 1
     except subprocess.CalledProcessError as error:
         # Deliberately generic: the only policy here is "a git subprocess
         # failed", which is true of every component. git's own diagnostic has