Tcw report

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 tcw-work).From its SKILL.md

Install

npx -y skills add brocef/TCW --skill tcw-report

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

2.7 KB, as published. Nobody here has run it

Reporting an issue or suggestion to TCW

Feedback about TCW itself — a tcw bug, a rough edge in a skill, a feature idea, a suggestion — goes to the project's issue tracker on GitHub, not into the user's local tcw work store. (tcw work tracks changes to their project; it is not a channel to the TCW maintainers.)

File it here: https://github.com/brocef/TCW/issues

Before filing

Search first. Skim the open (and recently closed) issues for the same symptom or idea; if one exists, add your detail there instead of opening a duplicate.
Pick the kind: a bug (something is broken or behaves wrong) or a suggestion / feature (something should exist or work differently). Use the matching skeleton below.
Grab the version. For a bug, run tcw --version and include the output — most reports are unactionable without it.

Bug skeleton

**Title:** <one line: what breaks, where>

### Environment

- tcw version: <output of `tcw --version`>
- OS / platform: <e.g. macOS 14, Ubuntu 24.04>
- Install method: <pipx / pip --user / editable / other>

### Steps to reproduce

1. <exact command or action>
2. <...>
3. <...>

### Expected vs. actual

- Expected: <what should have happened>
- Actual: <what happened — paste the error / output verbatim>

### Remediation

<proposed fix, workaround you found, or "unknown — needs investigation">

Suggestion / feature skeleton

**Title:** <one line: the change you want>

### Motivation

<the problem or friction today — why the status quo falls short>

### Description

<what you are proposing, concretely — the command, flag, behavior, or wording>

### Benefits

<who it helps and how; what it unlocks or simplifies>

Keep it concrete: a real command, a real error, a real scenario beats an abstract description. When it touches TCW's design, note which axis it concerns (taxonomy / capabilities / work) so it lands with the right maintainer context.