Defame1297
38f1ba4e03
Claude Code's (and Copilot's) native plugin installer has zero awareness of .apm/ nesting -- it convention-scans only flat skills/, agents/, commands/, hooks.json at each plugin's root. Confirmed via strings on the installed claude binary and live installs of git@holocron/gitea@holocron/kyberforge@ holocron, all reporting Skills(0) Agents(0) Hooks(0) post ADR-0015's apm conversion. Root cause (apm_cli/core/plugin_manifest.py): apm's plugin.json compiler deliberately strips skills/agents/commands keys, assuming the host already auto-discovers those convention directories -- it has no model of .apm/ being host-visible at all. Separately, apm's own bundle exporter (apm_cli/bundle/plugin_exporter.py, behind `apm pack --format plugin`) implements the correct .apm/ -> flat mapping, but only ever targeted build/<name>-<version>/, a path nothing in marketplace.json's source: points at. scripts/sync-plugin-content.sh wraps that bundle exporter and copies its agents/, skills/, commands/, instructions/, extensions/, and merged hooks.json back into each plugin's own root as a second tracked compiled-output category -- same governance status as .claude-plugin/plugin.json: generated from .apm/, never hand-edited. tests/ subdirectories are excluded from the mirror (dev fixtures, not host-visible runtime content; several hardcode a relative repo-root walk-up sized for the .apm/-nested depth, which breaks when duplicated one level shallower). Applied for real across all 6 plugins and verified two ways: `claude plugin validate --strict` passes on every real plugin directory, and a live `claude --plugin-dir <path> -p "list skills/agents"` behavioral test confirms content is now actually discovered. Also, from the same issue #90 review round: - scripts/check-manifests.sh pointed at each plugin's root-level plugin.json (checking skills/hooks/mcpServers/agents pointer fields) -- that file was a stale near-duplicate of .claude-plugin/plugin.json nothing else read or wrote, now deleted across all 6 plugins. check-manifests.sh is rewritten to validate .claude-plugin/plugin.json instead, and drops the pointer-field checks entirely (nothing to check -- those fields are correctly absent by design). Content-presence drift is now check-plugin-content-sync's job, a new pre-push hook wired in .pre-commit-config.yaml. docs/adr/0017 records the root cause and decision in full, including two rejected alternatives (patching plugin.json's path fields directly -- apm's compiler strips them on every run; pointing marketplace.json at apm pack's build/ output -- a version-suffixed non-source directory nothing can install from without an extra build step). ADR-0015 and CONTEXT.md are updated to point at it. Refs: #90
69 lines
5.8 KiB
Markdown
69 lines
5.8 KiB
Markdown
---
|
|
name: gitea-labels-milestones
|
|
|
|
description: >
|
|
Use when reading or writing Gitea labels or milestones — listing repo/org labels, creating,
|
|
editing, or deleting a label, resolving label names to the numeric IDs required for applying
|
|
them to an issue or PR, or listing, creating, updating, closing, or deleting a milestone. This is
|
|
a cross-cutting shared skill: `gitea-issues` and `gitea-prs` both compose it whenever they need to
|
|
apply labels or assign a milestone, rather than duplicating label/milestone logic. Also use for
|
|
label inference — mapping a bug report, feature request, or urgency signal in conversation
|
|
context to the repo's `Kind/*`/`Priority/*`/`Status/*` label taxonomy. Do not use for applying
|
|
already-resolved label IDs or milestone IDs to a specific issue or PR — that write goes through
|
|
`issue_write`/`pull_request_write` in `gitea-issues`/`gitea-prs`, not here.
|
|
|
|
compatibility: Requires Gitea MCP server configured with write:issue and write:repository token scopes.
|
|
|
|
metadata:
|
|
category: integration
|
|
source_keys:
|
|
- gitea-mcp-repo
|
|
- gitea-mcp-slim-go
|
|
- context7-websites-gitea
|
|
- context7-gitea-tea-cli
|
|
version: "0.1.1"
|
|
|
|
allowed-tools: Bash mcp__gitea__label_read mcp__gitea__label_write mcp__gitea__milestone_read mcp__gitea__milestone_write
|
|
---
|
|
|
|
## Gotchas
|
|
|
|
- **Label writes take IDs, reads return names.** `label_read` is the only tool that returns full label objects (`id`, `name`, `color`, `description`). Issue/PR responses slim labels down to name strings. Before any label is applied to an issue or PR (in `gitea-issues`/`gitea-prs`), resolve names → IDs here via `label_read method: "list_repo_labels"` — never pass a name string where an ID is expected.
|
|
- **Milestones are referenced by ID everywhere, never by title.** `milestone_write` update/delete take `id`. The one place titles show up as the sole handle is the `pull_request_read` response (see next gotcha).
|
|
- **Milestone representation differs between issues and PRs.** `issue_read` returns `milestone: {id, title}` — an object. `pull_request_read` returns `milestone: "title string"` — title only, no ID. You cannot recover a milestone ID from a PR response directly; call `milestone_read method: "list"` and match by title instead.
|
|
- **Repo labels and org labels are separate pools, never mixed in one call.** `label_read`/`label_write` take either `owner`+`repo` (repo-scoped methods) or `org` (org-scoped methods) — passing both or neither for a given method is a caller error, not something the schema enforces for you. Repo and org labels can both apply to the same issue, but you list/create/edit them through different method values.
|
|
- **`milestone_write` accepts `"update"` and `"edit"` as the same operation.** Both method values map to the identical update call. Prefer `"update"` for consistency with `issue_write`/`pull_request_write`.
|
|
- **`exclusive` is documented as an org-labels-only flag — it isn't what enforces exclusivity here.** Gitea's docs scope the settable/server-enforced `exclusive` flag to org labels only, and the live `label_write` schema for `create_repo_label`/`edit_repo_label` doesn't document accepting it at all. This repo's `Kind/*`, `Priority/*`, `Status/*` groups still behave as one-label-per-scope, but that's a manually-enforced convention this skill implements client-side, not a guaranteed server behavior for repo labels: applying a new label within a scope (e.g. `Priority/High`) must replace any existing label in that same scope, not add alongside it, and nothing on the server enforces that for you. Label inference (see `references/label-inference.md`) must respect this — replace, don't stack.
|
|
- **Pagination is manual on every list call.** `label_read` and `milestone_read` both default to `per_page: 30`. Iterate `page: 1, 2, ...` until the result count is less than `per_page` — there is no cursor or auto-pagination.
|
|
- **Schema requiredness differs between the two tool families.** `milestone_read`/`milestone_write` have `owner` and `repo` as hard-required parameters (the call fails validation without them). `label_read`/`label_write` only hard-require `method` — `owner`/`repo`/`org` are functionally required per method but not schema-enforced, so passing none produces a runtime error from Gitea, not a client-side validation error.
|
|
|
|
## Step 1 — Resolve owner and repo
|
|
|
|
Before any tool call, extract `owner` and `repo` from the git remote (skip this if an orchestrating caller already passed them in):
|
|
|
|
```bash
|
|
git remote get-url origin
|
|
```
|
|
|
|
If origin is not set or the URL is not a Gitea URL, stop and report: "No Gitea remote found — set origin to your Gitea instance URL."
|
|
|
|
## Step 2 — Dispatch
|
|
|
|
| Task | Tool | method |
|
|
|---|---|---|
|
|
| List repo labels | `label_read` | `"list_repo_labels"` |
|
|
| Get one repo label by ID | `label_read` | `"get_repo_label"` |
|
|
| List org labels | `label_read` | `"list_org_labels"` |
|
|
| Create a repo/org label | `label_write` | `"create_repo_label"` / `"create_org_label"` |
|
|
| Edit a repo/org label | `label_write` | `"edit_repo_label"` / `"edit_org_label"` |
|
|
| Delete a repo/org label | `label_write` | `"delete_repo_label"` / `"delete_org_label"` |
|
|
| List milestones | `milestone_read` | `"list"` |
|
|
| Get one milestone by ID | `milestone_read` | `"get"` |
|
|
| Create a milestone | `milestone_write` | `"create"` |
|
|
| Update / close a milestone | `milestone_write` | `"update"` |
|
|
| Delete a milestone | `milestone_write` | `"delete"` |
|
|
|
|
For full parameter detail and step-by-step call sequences, read `references/labels.md` (label operations) or `references/milestones.md` (milestone operations). For mapping conversation context to a label to apply, read `references/label-inference.md`.
|
|
|
|
Applying resolved label IDs or a milestone ID to a specific issue or PR is out of scope here — that's `issue_write`/`pull_request_write` in the composing skill (`gitea-issues`/`gitea-prs`).
|