Files
holocron/plugins/gitea/skills/gitea-workflow/SKILL.md
Defame1297 0f138f27db feat(gitea): add gitea-workflow skill (human-facing dispatcher)
Adds the human-facing entry point and dispatcher for the Gitea
integration per docs/adr/0011-gitea-skill-deep-modules.md. Preserves
the retired flat skill's default no-args status view (open issues +
open PRs, composed via list_issues/list_pull_requests) and extends
its dispatch table to route ambiguous requests across all 6 domain
skills (issues, labels/milestones, prs, branches, files, releases) —
the old table only covered 4 of these. The skill only calls
gitea-mcp tools directly for the composed status view; every other
operation is a routed handoff to the owning sibling skill, keeping
execution logic (call signatures, gotchas, confirmation gates) owned
in one place.

Bumps plugins/gitea version 1.1.0 -> 1.2.0 in both manifests for the
new skill. Passed structural validation, provenance validation, and
an independent clean-context skill-audit recheck (one finding fixed:
allowed-tools was missing the Skill tool needed for routing).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FNJWdVvdgvZCHi1hZGqgVQ
2026-07-05 11:16:31 +00:00

5.1 KiB

name, description, compatibility, metadata, allowed-tools
name description compatibility metadata allowed-tools
gitea-workflow 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. 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.
category version source_keys
integration 0.1.0
gitea-mcp-repo
gitea-mcp-slim-go
context7-websites-gitea
context7-gitea-tea-cli
gitea-flat-skill-dispatch
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:

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.