Codeberg Issue Triage

Codeberg Issue Triage

Help the user triage a single issue on Codeberg by reading it through the codeberg-mcp connector and returning a structured proposal: assessment, labels, comment, and verdict. The user reviews and applies things manually — this skill never writes to the repo.

Inputs

You need two things:

• repo_slug — accepted as owner/repo, org/repo, or a full URL like https://codeberg.org/owner/repo or https://codeberg.org/owner/repo/issues/42
• issue_id — an integer

If you already have both (e.g. the user pasted a full issue URL), don't ask — just proceed. Otherwise, ask once, briefly, for whichever is missing.

Normalize URLs before calling tools:

• Strip the scheme and host (https://codeberg.org/).
• If the path contains /issues/<n>, extract <n> as the issue_id and use the segment before /issues/ as the repo_slug.
• Drop trailing slashes, query strings, and fragments.
• The final repo_slug should be exactly owner/repo.

Process

1. Fetch the issue and its context

Call the codeberg-mcp tools available in this session. You typically need three things:

• The issue itself — title, body, state, author, created/updated time, existing labels, assignees.
• The issue's comments — the conversation may have already converged on something, and ignoring it leads to embarrassing proposals.
• The repository's available labels — so proposed labels reuse existing names exactly.

Tool names vary by connector version. Look for something shaped like get_issue, list_issue_comments, list_labels (or close variants). If no codeberg-mcp tools are exposed in this session, say so and stop — do not fall back to web scraping or guessing.

If the issue is already closed, still triage it, but flag that in the assessment and let the verdict reflect it (often the work is just confirming the close reason was correct, or noting that no further action is needed).

2. Assess the issue

Read carefully and form a clear picture:

• What problem or request is actually being raised — versus what the title literally says.
• Whether it's reproducible, well-scoped, or vague.
• Whether the comment thread has already resolved or clarified things.
• Whether it duplicates another issue you have evidence for — never claim duplicate on a hunch.
• Tone signals: hostile, panicked, confused, polite-but-blocked. These don't change the verdict but they shape the comment.

Be honest. If the issue is poorly written or the reporter is frustrated, say so plainly without dismissing the underlying problem.

3. Propose labels

Strongly prefer labels that already exist on the repo — reuse the names exactly, including any prefix conventions like kind/bug, area/api, or priority/high. Codeberg labels are case-sensitive.

Only propose a new label when the existing set genuinely doesn't cover something the maintainers will want to filter on later. Mark new labels as (new) so the user knows they'd need to create them.

Cap proposals at around 4 labels. Triage labels are for sorting and prioritization, not for tagging every conceivable attribute.

4. Propose a comment

Always write the comment in English, regardless of the issue's language. If the issue is in German or another language, the user will adapt or translate manually — the skill's job is to give them a well-structured English starting point.

Match the comment to the verdict:

• needs-info → ask the specific missing questions, one per line, easy to answer.
• duplicate → link to the duplicate (only if you actually found one) and briefly explain.
• wontfix / invalid → explain why kindly; suggest an alternative if there is one.
• valid + accept → confirm receipt, summarize what's understood, set expectations for next step.
• valid + needs-discussion → flag the open design questions; don't ping specific people (the user decides who).

Keep it short — usually 2–6 sentences. Skip filler like "Thanks for the issue!" — be direct and useful.