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>

skills/issue/SKILL.md

@@ -14,17 +14,22 @@ 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`, `feature`, `refactor`, or `draft` (for ideas
-   not ready for work). If it is not obvious from the request, ask the user
-   (one question).
+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 `type/*` label, 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.
+   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
@@ -35,14 +40,18 @@ always `--login "$GITEA_LOGIN"`, never a literal name (see `/tea:use`).
    ```
    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).
-   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 `type/*` label.
+   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
-(`tea issues <n> --login "$GITEA_LOGIN" -o json`), restructure the body into
+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.