2.1 KiB
2.1 KiB
| type | subtype | title | summary | tags | scope | last_updated | date | last_reviewed | source | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| reference | api-integration | tea CLI: assignees are invisible in issue view | How to assign and verify assignees with the tea (Forgejo/Gitea) CLI — `tea issues <N>` never renders assignees, so verifying a claim needs `tea issues list --fields`. |
|
global | 2026-07-14 | 2026-07-14 | 2026-07-14 | cc-os |
tea CLI: assignees are invisible in issue view
Discovered while claiming a wayfinder ticket on Forgejo (jared/cc-os), where the claim is
the assignee — so a claim you can't verify is a claim you don't have.
The gotcha
tea issues <N> renders title, author, labels, and body — but never the assignees, even
when the issue has them. Reading the issue back is therefore useless as verification: an
assignment that succeeded and one that silently did nothing look identical.
Correct commands
# assign (only valid on `edit`; the flag is --add-assignees, NOT --assignees)
tea issues edit <N> --repo <owner>/<repo> --add-assignees <user>
# verify — the only view that shows them
tea issues list --repo <owner>/<repo> --fields index,title,assignees --output simple
Failure modes seen:
tea issues <N> --add-assignees <user>→flag provided but not defined(the view subcommand takes no edit flags).tea issues list --assigned-to <user>→flag provided but not defined(no such filter; use--fields assigneesand filter locally).- A successful
tea issues editprints the issue body back, which looks like a no-op confirmation and shows no assignee — do not read that as failure, and do not read it as success either. Verify withlist --fields.
Why it matters beyond one repo
Any workflow where assignment carries meaning — wayfinder claim-before-work, "who owns this
ticket" triage — needs a verification step that is not the issue view. Budget one extra
list --fields call.
See cc-os-plugin-skill-naming-convention for the sibling convention set used on that repo.