git-mpm/skills/gitea/SKILL.md

name, description, tools

name	description	tools
gitea	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".	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:

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.