Defame1297
60be7b3232
Only 12 of 39 skills carried metadata.version, and adoption tracked which plugin a skill lived in rather than any stated rule: core, gitea and lint were consistent adopters, bin and kyberforge were consistent non-adopters, git was split with one outlier. There was no documented convention, and skill-author's own bump logic was already written as if presence were conditional. metadata.version is now required on every skill. The 19 skills here that never carried one (bin, kyberforge, gitea-files) are seeded at 1.0.0, not 0.1.0 -- that value stays reserved for a skill's actual creation point under skill-author's existing convention. The skill-frontmatter pre-commit hook now fails a SKILL.md missing the field, the same class of failure as a missing name/description. Full rationale in the new ADR. The git-plugin skills that also need this field follow in the next commit, bundled with issue #113's rtk normalization since both touch the same files. Refs: #127 ADR: 0022 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EeH8SCbcrCAQrtymkNuhKP
2.7 KiB
2.7 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
- A 404 may mean an under-scoped token, not a missing path. Every tool here gates on
write:repository, and Gitea masks insufficient scope as 404. Check scopes first. - 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.