naudachu
492c27df98
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>
58 lines
3.2 KiB
Markdown
58 lines
3.2 KiB
Markdown
---
|
|
name: issue
|
|
description: 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`](../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
|
|
|
|
1. **Read the format**: load `../use/references/issue-format.md`.
|
|
2. **Pick the type** — `bug`, `task`, `refactor`, `test`, `feature` (a
|
|
container for several issues with one business value), or `draft` (for
|
|
ideas not ready for work). If it is not obvious from the request, ask the
|
|
user (one question).
|
|
3. **Ensure labels exist**: `tea labels list --login "$GITEA_LOGIN" -o json`.
|
|
For each missing **exclusive** label (`type/*`, and `severity/*` when
|
|
used), create it via `tea api` with `"exclusive": true` exactly as shown
|
|
in the format doc. Do NOT use `tea labels create` for these — it cannot
|
|
set exclusivity. Non-exclusive `tech/*` and `comp/*` labels may be created
|
|
either way; apply them when the technology or component is evident.
|
|
4. **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; `## Spec` filled with a repo path,
|
|
a URL, or the literal `none` — ask the user if you cannot determine which.
|
|
If the issue depends on others, add a `## Depends on` section right after
|
|
`## Spec` (one `#N` per line); omit it otherwise.
|
|
5. **Post via tmp/ + tea api** (the body is always multi-line, so entity
|
|
commands are off the table — see "Rich payloads" in `/tea:use`):
|
|
```bash
|
|
mkdir -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}/issues
|
|
```
|
|
The create endpoint takes label **IDs** (integers), not names — take them
|
|
from the `tea labels list` output of step 3 (or from the create response).
|
|
The `labels` array holds every applied label: the `type/*` ID plus any
|
|
`severity/*`, `tech/*`, `comp/*` IDs. If labels fail to attach on create,
|
|
fall back to `PUT repos/{owner}/{repo}/issues/{n}/labels` with
|
|
`{"labels": [<id>]}`.
|
|
6. **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.
|