Files
marketplace/skills/issue/SKILL.md
T
naudachu 492c27df98 feat: align issue format with wiki workflow spec
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>
2026-08-07 18:06:16 +05:00

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

  1. Read the format: load ../use/references/issue-format.md.
  2. Pick the typebug, 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):
    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.