Match the Issues-Workflow wiki (claude-skills/tea#1): types expand to bug|task|refactor|test|feature|draft (feature becomes a container, task takes over new functionality), add severity/tech/comp label namespaces, an optional "Depends on" section, and templates for test and feature. Milestone/Project containers documented. Refs claude-skills/tea#1 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
3.2 KiB
name, description
| name | description |
|---|---|
| issue | Create a Gitea issue in the project's canonical format. Run when the user asks to file/create an issue, or types /tea:issue. Ensures exclusive type/* labels exist, composes the body from the type's template, and posts via tea api. Format lives in the use skill's references. |
/tea:issue — create an issue in the canonical format
Thin procedure on top of the canonical format defined in
../use/references/issue-format.md.
Read that file first — it is the single source of truth for types, labels,
templates, and language rules. Login rules are the same as everywhere:
always --login "$GITEA_LOGIN", never a literal name (see /tea:use).
Steps
- Read the format: load
../use/references/issue-format.md. - Pick the type —
bug,task,refactor,test,feature(a container for several issues with one business value), ordraft(for ideas not ready for work). If it is not obvious from the request, ask the user (one question). - Ensure labels exist:
tea labels list --login "$GITEA_LOGIN" -o json. For each missing exclusive label (type/*, andseverity/*when used), create it viatea apiwith"exclusive": trueexactly as shown in the format doc. Do NOT usetea labels createfor these — it cannot set exclusivity. Non-exclusivetech/*andcomp/*labels may be created either way; apply them when the technology or component is evident. - Compose title and body per the format: English imperative title without
a type prefix; the type's template with all sections present, in order,
headers in English, prose in Russian;
## Specfilled with a repo path, a URL, or the literalnone— ask the user if you cannot determine which. If the issue depends on others, add a## Depends onsection right after## Spec(one#Nper line); omit it otherwise. - Post via tmp/ + tea api (the body is always multi-line, so entity
commands are off the table — see "Rich payloads" in
/tea:use):The create endpoint takes label IDs (integers), not names — take them from themkdir -p tmp/issue # write {"title": "...", "body": "...", "labels": [<type-label-id>]} as JSON tea api --login "$GITEA_LOGIN" -X POST -d @tmp/issue/<slug>.json \ repos/{owner}/{repo}/issuestea labels listoutput of step 3 (or from the create response). Thelabelsarray holds every applied label: thetype/*ID plus anyseverity/*,tech/*,comp/*IDs. If labels fail to attach on create, fall back toPUT repos/{owner}/{repo}/issues/{n}/labelswith{"labels": [<id>]}. - Report: show the issue URL and the applied labels.
Editing an existing issue
When asked to bring an existing issue to the format: fetch it with the use
skill's script (python3 ../use/scripts/fetch_issue.py <n> relative to this
skill's base dir — writes tmp/issue/<n>/data + comments, prints a compact
index; no --login, it resolves the pin itself), restructure the body into
the type's template without losing information, then
PATCH repos/{owner}/{repo}/issues/{n} with the new title/body and ensure
exactly one type/* label is set.