---
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.