holocron/plugins/gitea/skills/gitea-workflow/SKILL.md

---
name: gitea-workflow

description: >
  Use when a user makes a Gitea request that doesn't already name a specific domain, or asks for a
  general status check — "what's open", "what needs my attention", "gitea status", or bare
  `/gitea-workflow` with no arguments. Resolves the repo's owner/repo once from the git remote, then
  either runs the composed default status view (open issues + open PRs) or routes the request to
  whichever of the 6 domain skills owns it: gitea-issues, gitea-labels-milestones, gitea-prs,
  gitea-branches, gitea-files, gitea-releases. This skill does not execute domain operations itself
  — it composes/routes to the owning skill by name. Do not use when the request already clearly
  names one domain (e.g. "create an issue", "merge PR #12", "cut a release") — invoke that domain
  skill directly instead; this skill exists for the ambiguous/default case, not as a mandatory front
  door.

compatibility: Requires Gitea MCP server configured with write:issue and write:repository token
  scopes (for the composed status view's two list calls). Requires git remote "origin" pointing to
  the Gitea instance for owner/repo resolution.

metadata:
  category: integration
  version: "0.1.0"
  source_keys:
    - gitea-mcp-repo
    - gitea-mcp-slim-go
    - context7-websites-gitea
    - context7-gitea-tea-cli
    - gitea-flat-skill-dispatch

allowed-tools: Bash Skill mcp__gitea__list_issues mcp__gitea__list_pull_requests
---

## Gotchas

- **Issues and PRs share one number space — don't re-implement the disambiguation here.** A bare `#N` with no domain word (e.g. "close #12") is ambiguous: it could be an issue or a PR. Default to routing it to `gitea-issues` — its own `<N>` (get) dispatch already calls `issue_read` and checks `is_pull`, redirecting to `gitea-prs` itself if the number turns out to be a PR. This skill does not duplicate that detection.
- **This skill never re-implements a domain skill's confirmation gates or error recovery.** If a routed request needs a destructive-op confirmation (branch deletion, PR merge, release/tag deletion), that confirmation happens inside the routed skill, not here. Routing here is a handoff, not a re-execution of the target's logic.
- **Owner/repo are resolved once, here, and passed through.** Resolve them in Step 1 before dispatching, so the target domain skill doesn't re-resolve them from the git remote a second time. `gitea-files` in particular never resolves owner/repo itself — it always expects a caller to supply them, so this skill must pass them explicitly when routing there.
- **This skill only ever calls two gitea-mcp tools directly** (`list_issues`, `list_pull_requests`), and only for the composed default status view. Every other operation is a routed call to a sibling skill by name — if you find yourself reaching for another `mcp__gitea__*` tool here, that's a sign the request should have been routed instead.

## Step 1 — Resolve owner and repo

Before the status view or any routed dispatch, extract `owner` and `repo` from the git remote:

```bash
git remote get-url origin
```

If origin is not set or the URL is not a Gitea URL, stop and report: "No Gitea remote found — set origin to your Gitea instance URL."

## Step 2 — Dispatch

| Invocation / trigger phrasing | Route to |
|---|---|
| `/gitea-workflow` (no args), "what's open", "gitea status", "what needs my attention" | **Status (default)** — composed below, no routing |
| "create/get/close/comment on an issue", "what issues are open", "search issues for X" | `gitea-issues` |
| "add/create/edit/delete a label", "list labels", "create/close a milestone", "what labels apply to X" | `gitea-labels-milestones` |
| "open/merge/review a PR", "PR status", "PR diff", "approve/request changes" | `gitea-prs` |
| "list/create/delete a branch", "what commits are on this branch", "show commit `<sha>`" | `gitea-branches` |
| "read/create/update/delete a file in the repo", "what's in this directory", "show the repo tree" | `gitea-files` |
| "cut a release", "publish a prerelease", "tag this commit", "what's the latest release" | `gitea-releases` |
| A bare `#N` with no domain word | `gitea-issues` (see Gotchas — it self-corrects to PR if needed) |

Read the target skill's own `SKILL.md` for its full dispatch table and execution detail — this table only routes; it does not restate each domain's verbs.

## Step 3 — Execute

### Status (default)

Call `list_issues state: "open"` and `list_pull_requests state: "open"` in parallel, both scoped to the owner/repo resolved in Step 1. Report as two sections: open issues, open PRs.

### Routed request

Invoke the matched domain skill (Skill tool), passing along:
- the resolved `owner`/`repo` from Step 1, so it doesn't need to re-resolve them
- the user's original request/intent, so it doesn't need to re-derive what the user asked for

## Step 4 — Report

For the status view: a compact two-section list — issue/PR number, title, labels, milestone (same fields the old flat skill's status view reported).

For a routed request: pass through whatever the target skill reports; don't reformat or re-summarize its output beyond what's needed to present it in the conversation.