refactor(gitea): deep modules — split flat dispatch skill into 6 domain skills + orchestrator + agent #67
@@ -12,9 +12,11 @@ explicit confirmation, and treating unexpected 404s as possible masked 403s).
|
|||||||
|
|
||||||
## Before you start
|
## Before you start
|
||||||
|
|
||||||
Requires a Gitea MCP server configured with a token. `list_branches`, `list_commits`, and
|
Requires a Gitea MCP server configured with a token that has `write:repository` scope. This is
|
||||||
`get_commit` work with `write:issue` alone; `create_branch` and `delete_branch` need
|
confirmed for `list_branches`, `create_branch`, and `delete_branch` (Gitea gates reads behind write
|
||||||
`write:repository`. Requires a git remote named `origin` pointing at the Gitea instance.
|
scope for repo-scoped operations); `list_commits` and `get_commit` are inferred to need the same
|
||||||
|
scope by analogy, not explicitly confirmed — see `references/commits.md`. Requires a git remote
|
||||||
|
named `origin` pointing at the Gitea instance.
|
||||||
|
|
||||||
## Usage
|
## Usage
|
||||||
|
|
||||||
|
|||||||
@@ -13,11 +13,11 @@ description: >
|
|||||||
git-history) or for PR-side branch references like cross-repo fork PR heads
|
git-history) or for PR-side branch references like cross-repo fork PR heads
|
||||||
(use gitea-prs).
|
(use gitea-prs).
|
||||||
|
|
||||||
compatibility: Requires Gitea MCP server configured with a token; list_branches, list_commits, and get_commit work with write:issue alone, create_branch and delete_branch require write:repository. Requires git remote "origin" pointing to the Gitea instance.
|
compatibility: Requires Gitea MCP server configured with a token with write:repository scope; this is confirmed to gate list_branches, create_branch, and delete_branch (Gitea gates reads behind write scope for repo-scoped operations), and is inferred by analogy (not explicitly confirmed by source docs) to also gate list_commits and get_commit. Requires git remote "origin" pointing to the Gitea instance.
|
||||||
|
|
||||||
metadata:
|
metadata:
|
||||||
category: integration
|
category: integration
|
||||||
version: "0.1.0"
|
version: "0.1.1"
|
||||||
source_keys:
|
source_keys:
|
||||||
- gitea-mcp-repo
|
- gitea-mcp-repo
|
||||||
- gitea-mcp-slim-go
|
- gitea-mcp-slim-go
|
||||||
|
|||||||
@@ -73,6 +73,9 @@ protected, every time, regardless of how the request is phrased.
|
|||||||
|
|
||||||
## Token scope
|
## Token scope
|
||||||
|
|
||||||
`list_branches` works with `write:issue` alone. `create_branch` and `delete_branch` need
|
All three — `list_branches`, `create_branch`, `delete_branch` — require `write:repository`. Gitea
|
||||||
`write:repository`. All three are verified working empirically under a token with both scopes
|
gates reads behind write scope for repo-scoped operations, so `list_branches` needs the same scope
|
||||||
(`write:issue` + `write:repository`).
|
as the write operations, not `write:issue` alone. An earlier version of this doc claimed
|
||||||
|
`write:issue` alone was sufficient for `list_branches`, based on empirical testing under a token
|
||||||
|
that held both `write:issue` and `write:repository` simultaneously — that test didn't isolate the
|
||||||
|
variable, so it couldn't actually establish `write:issue` alone as sufficient.
|
||||||
|
|||||||
@@ -63,5 +63,11 @@ edge cases, `get_commit` will not.
|
|||||||
|
|
||||||
## Token scope
|
## Token scope
|
||||||
|
|
||||||
Both tools are read-only and work with `write:issue` alone (no `write:repository` needed), verified
|
Both tools are believed to require `write:repository`, even though they're read-only — inferred by
|
||||||
empirically against the deployed server.
|
analogy with the scope-gating principle in `overview.md` (Gitea gates reads behind write scope for
|
||||||
|
repo-scoped operations), not a claim `overview.md` makes for commits by name: its explicit
|
||||||
|
`write:repository` enumeration lists PR, branch, file, release, and tag operations, but doesn't
|
||||||
|
mention commits. An earlier version of this doc claimed `write:issue` alone worked, based on
|
||||||
|
empirical testing under a token that held both `write:issue` and `write:repository`
|
||||||
|
simultaneously — that test didn't isolate the variable either. Treat this as unverified until
|
||||||
|
tested under a token scoped to `write:issue` only (no `write:repository`).
|
||||||
|
|||||||
Reference in New Issue
Block a user