Add skills/gitea/SKILL.md

2026-05-24 23:57:55 -05:00
parent 41d0022b92
commit 3d8d76f16d
1 changed files with 79 additions and 0 deletions
@@ -0,0 +1,79 @@
+---
+name: gitea
+description: >
+  Interact with the MPM Gitea server at git.mpm.to using the REST API. Use this
+  skill when the user wants to work with Git repositories, issues, pull requests,
+  releases, file contents, or webhooks on git.mpm.to. Triggers on phrases like:
+  "show repos", "list repositories", "create a repo", "open an issue", "create
+  an issue", "list issues", "close an issue", "show pull requests", "list PRs",
+  "merge a PR", "create a release", "tag a release", "list releases", "read a
+  file", "view file contents", "update a file", "commit a file", "manage
+  webhooks", "add a webhook", "list webhooks", "delete a webhook", "what's in
+  the repo", "who has access", "show me the code", "gitea".
+tools:
+  - Bash
+---
+
+# Gitea skill — git.mpm.to
+
+## Connection details
+
+- **Base URL**: `https://git.mpm.to/api/v1`
+- **Auth header**: `Authorization: token e82a7235b948fbbeea60329422fcac89fa5a5ce8`
+- **Content-Type**: `application/json` for POST/PATCH/PUT requests
+
+## Standard curl pattern
+
+Every API call follows this structure:
+
+```bash
+curl -s \
+  -H "Authorization: token e82a7235b948fbbeea60329422fcac89fa5a5ce8" \
+  -H "Content-Type: application/json" \
+  "https://git.mpm.to/api/v1/ENDPOINT"
+```
+
+For write operations (POST, PATCH, PUT, DELETE), add `-X METHOD` and `-d '{...}'` as needed.
+
+Always pass `-s` (silent) to suppress progress output. Pipe through `python3 -m json.tool` or `jq` when presenting structured results to the user if those tools are available; otherwise format the raw JSON in a readable way in your response.
+
+## How to handle requests
+
+1. Identify the operation type from the user's request.
+2. Refer to the appropriate reference file in `references/` for the exact endpoint, parameters, and response shape.
+3. Construct the curl command and run it via Bash.
+4. Parse the JSON response and present the relevant fields in a clean, human-readable format. Do not dump raw JSON at the user.
+5. If the response contains an error field or a non-2xx HTTP status, report the error clearly and suggest corrective action.
+
+## Inferring missing context
+
+- If the user doesn't specify an owner/org, check if the result from `/api/v1/user` or `/api/v1/repos/search` can help narrow it down. Ask the user to clarify if still ambiguous.
+- If the user says "the repo" without naming one, ask which repo they mean, or list repos for them to pick from.
+- For destructive operations (delete, merge, close), always confirm with the user before proceeding.
+
+## Reference files
+
+Detailed endpoint specs, parameters, and example responses are in the `references/` directory:
+
+| Topic | File |
+|---|---|
+| Repositories | `references/repos.md` |
+| Issues | `references/issues.md` |
+| Pull requests | `references/pull-requests.md` |
+| Releases & tags | `references/releases.md` |
+| File contents | `references/content.md` |
+| Webhooks | `references/webhooks.md` |
+
+Read the relevant reference file before constructing any API call to ensure correct parameter names and endpoint paths.
+
+## Pagination
+
+Most list endpoints return paginated results. Use `?limit=50&page=1` query params. If the user may need more results, inform them and offer to fetch additional pages.
+
+## Presenting results
+
+- Format repository lists as a table or clean list with name, description, visibility, and last-updated.
+- Format issues and PRs with number, title, author, status, and date.
+- For file contents, show the decoded content (base64-decode `content` field: `echo "BASE64" | base64 -d`).
+- For releases, show tag name, title, date, and whether it's a pre-release.
+- For webhooks, show URL, events it fires on, and active status.