gitea/skills/wiki-to-issue/SKILL.md

---

name: wiki-to-issue description: Turn one Gitea wiki page into an issue in the same repository. Parse the link with tools/gitea-link.sh, read the page through jsc-gitea:wiki, draft title and body as a sub agent, then create the issue with tools/issue.sh - labels picked from the repository's existing set per the jsc-ask decision tree, project board attached or reported as manual when the site has no board API. A request without a wiki link stops the skill immediately: never guess the repository or the page. Use when a wiki page has to become trackable work; not for issues drafted from scratch, and not for syncing an issue that already exists.

wiki-to-issue — a wiki page becomes an issue

The wiki link is the only input. Everything else — repository, page name, host — comes out of that link.

Steps

1. Link gate. Run tools/gitea-link.sh parse {url} on the link the user gave. Exit 3, no link in the request, or kind=issue (this skill reads wiki pages, not issues) all mean the same thing: stop and report which one it was. Never ask for a repository name instead, and never fall back to the working directory's remote — a page written into the wrong repository's issue tracker is public and hard to take back. Completion condition: kind=wiki, and repo, page and host are known.
2. Read the page with jsc-gitea:wiki (wiki-get {repo} {page}). Exit 4 means the page does not exist — stop and report the page name. Take the page's absolute URL from wiki-url in the same pass; it goes into the issue body. Completion condition: the page's markdown and its absolute URL are both in hand.
3. Draft the issue — this step MUST run as a sub agent. Title: the page's first heading, or the page name when it has none. Body: the page content in Traditional Chinese, opening with a 「來源：{絕對網址}」 line so the issue points back at the wiki. Convert [[display|page]] links to absolute URLs (wiki-url), because [[...]] resolves only inside a wiki. Drop personal data — an issue is read by more people than a wiki page. Completion condition: title and body file exist, the body carries the source line, and no [[...]] link is left in it.
4. Labels come from what the repository already has. Run tools/issue.sh labels {repo}, propose the fitting ones with a reason each, and confirm per jsc-ask:ask rules — every option states its impact scope (a label drives filters and board rules, so a wrong one routes the work to the wrong queue). Turn the confirmed names into ids with tools/issue.sh label-ids. An empty label list, or nothing fitting: ask whether to create the issue with no label, and record that answer. Never invent a label that the repository does not have. Completion condition: the user has confirmed a label set — possibly empty — and its ids are resolved.
5. Project board. Run tools/issue.sh projects {repo}. Exit 3 means this Gitea has no board API: say so plainly, and hand the user the board URL the script printed so they can drag the issue in themselves. A board list comes back: let the user pick one per jsc-ask:ask rules, attach it, and report the failure verbatim if the attach call is refused. Completion condition: the issue is either attached to a board, or the report states in one line that the board link is still outstanding and who has to do it.
6. Create the issue: tools/issue.sh create {repo} {title} {body-file} [--labels {ids}]. Report the index= and url= it prints. Completion condition: the issue URL is reported to the user, together with the labels applied and the board status from step 5.

Rules

• One wiki page, one issue. Splitting a page into several issues is analysis work, not conversion — hand that to jsc-sdlc:analyze.
• The issue body stays Traditional Chinese per the STE100 rule, and keeps the source line at the top.
• Creating an issue is an outward-facing action: the title, body, labels and board pick are confirmed with the user before the create call, never after.