Defame1297
6cfc3577e2
Finding 13: five blocks of near-identical wording were repeated across skills within a plugin — the gitea "resolve owner and repo" step (5 skills), the 404-masks-403 note (6 files), the manual pagination explanation (8 files), the git plugin's main/master force-push refusal (7 files, some with multiple internal restatements), and the bin skills' domain-glossary/ADR paragraph (5 skills). Tightened each instance in place — same meaning, fewer words — rather than extracting to a shared file, which ADR-0014's one-file-per-skill install constraint rules out. Left the three git skills' structured-result JSON shapes alone (coupled to the separate, out-of-scope git-orchestrate merge candidate, finding 19). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YR2CjVumUbEGWcMikcoXBD
2.6 KiB
2.6 KiB
name, description, compatibility, metadata, allowed-tools
| name | description | compatibility | metadata | allowed-tools | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| gitea-files | Use when reading or writing files or directories in a Gitea repository via the MCP server, rather than the local filesystem (for a local path use Read/Write/Edit) — even when the user does not say "Gitea". Not commit history -> `gitea-branches`. Not pull requests -> `gitea-prs`. | Requires the Gitea MCP server configured with a token scoped to at least write:repository. Tested with a token holding write:issue + write:repository; write:issue is not actually required for any of this domain's five tools. |
|
mcp__gitea__get_file_contents mcp__gitea__get_dir_contents mcp__gitea__get_repository_tree mcp__gitea__create_or_update_file mcp__gitea__delete_file |
Gotchas
- 404 may mean an under-scoped token, not a missing path. These tools gate on
write:repository; check scope before concluding the path is missing. - Reads take
ref(tree_shaonget_repository_tree), writes takebranch_name. One concept, three names — carry the wrong key and the branch is dropped. contentis base64 both ways — except underwithLines: true. Encode before a write, decode after a read; but withwithLines: truecontentis already plain JSON text and the reported"encoding": "base64"is a lie. Decoding it yields garbage.
Inputs
owner, repo and the target branch are caller-supplied. This skill never infers them from a git remote: ask the human when they are not stated, and expect an orchestrating caller to have resolved them already.
Dispatch
Read the reference for the row you land on before making the call.
| Condition | Flow | Reference |
|---|---|---|
| Read one file, list one directory level, or walk the repository tree | Read | references/reading.md — the three read tools, their pagination behaviour, and why neither a directory listing nor a tree entry supplies the SHA a write needs |
| Create, update, or delete a file | Write | references/writing.md — the SHA-first sequence every update and delete depends on, the worked multi-call sequence, and how to triage a write that fails |
A request that reads and then writes runs both flows in that order: fetch the file first, then write with the SHA that call returned.
Handoff
Scope ends at the commit. Gitea's own web UI edits files directly against a branch, so committing straight to a branch is the normal path rather than an escape hatch — hand off to gitea-prs when the change needs review before merging or the target branch is protected, not by default.