enricobuehler
0eb8f2d0f1
The mattpocock engineering skills (/triage, /to-tickets, /to-spec, /wayfinder,
/diagnosing-bugs, /code-review) all assume a per-repo configuration that this
repo never had: they need to know which tracker to talk to, which label strings
carry the five triage roles, and which docs to read before exploring. Without it
each of them guesses, and the guess is GitHub.
Which is wrong here in a way that fails quietly. This repo's remote is
git.unom.io — Gitea. `gh` is installed on the machine and will happily run
against github.com and find nothing; `glab` and `tea` are not installed at all.
So the tracker doc points at the connected `gitea` MCP server instead, and says
so in the first line, because the failure mode is an agent confidently reporting
an empty issue list.
Two traps in that MCP surface are worth the words they take:
- `issue_write` applies labels by numeric ID and `remove_label` takes a
`label_id`, while `list_issues` filters by label *name*. Applying a label
therefore needs a `label_read` lookup first — passing the name silently
gets you nowhere.
- unom/punktfunk has no labels defined at all, on the repo or on the org
(checked both). The first triage run has to create the five before it can
apply any of them.
Gitea writes are outward-facing — a shared instance that mails on activity — so
the doc encodes the standing rule as a gate: reads are free, every write waits
for a go-ahead, subagents included.
Domain docs are single-context: one CONTEXT.md and one docs/adr/ at the root.
Neither exists yet and neither should be created pre-emptively; /domain-modeling
writes them when a term or a decision actually gets resolved. Twenty-seven
crates and nine client platforms is the shape of a repo that eventually wants a
CONTEXT-MAP.md, so the switch path is written down — but they serve one domain
today, and a glossary split four ways before it has a single entry is just four
empty files.
AGENTS.md rather than CLAUDE.md because neither existed, and the cross-tool
convention costs nothing here.
1.6 KiB
Triage Labels
The skills speak in terms of five canonical triage roles. This file maps those roles to the actual label strings used in this repo's issue tracker.
| Label in mattpocock/skills | Label in our tracker | Meaning |
|---|---|---|
needs-triage |
needs-triage |
Maintainer needs to evaluate this issue |
needs-info |
needs-info |
Waiting on reporter for more information |
ready-for-agent |
ready-for-agent |
Fully specified, ready for an AFK agent |
ready-for-human |
ready-for-human |
Requires human implementation |
wontfix |
wontfix |
Will not be actioned |
When a skill mentions a role (e.g. "apply the AFK-ready triage label"), use the corresponding label string from this table.
Edit the right-hand column to match whatever vocabulary you actually use.
These labels do not exist yet
As of setup, unom/punktfunk has no labels defined — not on the repo, not on the unom org.
The first triage run has to create them with mcp__gitea__label_write
(method: "create_repo_label", name, color as #RRGGBB, optional description).
Creating labels is a write to a shared instance, so it falls under the ask-first rule in
issue-tracker.md — propose the five, then create them once the user agrees.
Remember the ID trap from issue-tracker.md: applying a label needs its numeric ID from
label_read, not the name in the table above.