80 lines
3.6 KiB
Markdown
80 lines
3.6 KiB
Markdown
---
|
|
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.
|