docs: record agent-skills setup (Gitea+tea tracker, triage labels, domain docs)

This commit is contained in:
haylan committed 2026-10-14 16:05:30 +02:00
1 parent c20a4f0226
commit f51e83713a
4 files changed
+142

No files matched your search

+14
View File
@@ -67,3 +67,17 @@ hidden, color?, steps?, request{settings,headers,body}, permissions[{action,reso
injected content must have frontmatter stripped; serve prints its Basic-auth password.
- Agent `steps` replaces `maxSteps`; `temperature`/`top_p` go under `request.body` (not yet sent by
the runner — avoid).
## Agent skills
### Issue tracker
Issues live in this repo's Gitea Issues (`git.arthurerlich.de`), driven via the `tea` CLI; relations are body conventions (`Part of #`, `Blocked by:`) since Gitea has no sub-issues. See `docs/agents/issue-tracker.md`.
### Triage labels
Default five-role vocabulary (`needs-triage`, `needs-info`, `ready-for-agent`, `ready-for-human`, `wontfix`), label strings equal to role names. See `docs/agents/triage-labels.md`.
### Domain docs
Single-context: one `GLOSSARY.md` + `docs/adr/` at the repo root. See `docs/agents/domain.md`.
+51
View File
@@ -0,0 +1,51 @@
# Domain Docs
How the engineering skills should consume this repo's domain documentation when exploring the codebase.
## Before exploring, read these
- **`GLOSSARY.md`** at the repo root, or
- **`GLOSSARY-MAP.md`** at the repo root if it exists: it points at one `GLOSSARY.md` per context. Read each one relevant to the topic.
- **`docs/adr/`**: read ADRs that touch the area you're about to work in. In multi-context repos, also check `src/<context>/docs/adr/` for context-scoped decisions.
If any of these files don't exist, **proceed silently**. Don't flag their absence; don't suggest creating them upfront. The `/domain-modeling` skill (reached via `/grill-with-docs` and `/improve-codebase-architecture`) creates them lazily when terms or decisions actually get resolved.
## File structure
Single-context repo (most repos):
```
/
├── GLOSSARY.md
├── docs/adr/
│ ├── 0001-event-sourced-orders.md
│ └── 0002-postgres-for-write-model.md
└── src/
```
Multi-context repo (presence of `GLOSSARY-MAP.md` at the root):
```
/
├── GLOSSARY-MAP.md
├── docs/adr/ ← system-wide decisions
└── src/
├── ordering/
│ ├── GLOSSARY.md
│ └── docs/adr/ ← context-specific decisions
└── billing/
├── GLOSSARY.md
└── docs/adr/
```
## Use the glossary's vocabulary
When your output names a domain concept (in an issue title, a refactor proposal, a hypothesis, a test name), use the term as defined in `GLOSSARY.md`. Don't drift to synonyms the glossary explicitly avoids.
If the concept you need isn't in the glossary yet, that's a signal: either you're inventing language the project doesn't use (reconsider) or there's a real gap (note it for `/domain-modeling`).
## Flag ADR conflicts
If your output contradicts an existing ADR, surface it explicitly rather than silently overriding:
> _Contradicts ADR-0007 (event-sourced orders), but worth reopening because…_
+62
View File
@@ -0,0 +1,62 @@
# Issue tracker: Gitea (via tea CLI)
Issues and specs for this repo live as Gitea issues on
`git.arthurerlich.de/haylan/mattpocock-skills-opencode`. Use the `tea` CLI for all operations;
the `gitea-tea` skill has command recipes. `tea` infers the repo from `git remote` inside this clone.
**One-time human step (not done yet):** `tea logins add` for `https://git.arthurerlich.de`
(token from the web UI: Settings → Applications). Until then, tracker operations fail.
## Conventions
- **Create an issue**: `tea issues create -t "<title>" --description-file -` (stdin for
multi-line bodies). Labels: `-L needs-triage,bug` (comma-separated; must exist — see Labels).
- **Read an issue**: `tea issues <number> --comments`.
- **List issues**: `tea issues list --state open -f index,title,state,labels,assignees`
(add `body,comments` to `--fields` when a skill needs full content).
- **Comment**: `tea comments <number> "<body>"`.
- **Apply / remove labels**: `tea issues edit <number> -L "<label>"` / `--remove-labels "<label>"`.
- **Assign**: `tea issues edit <number> -a <username>`.
- **Close**: comment the reason, then `tea issues close <number>`.
Gitea has **no sub-issues and no native blocked-by links**. Relations are body conventions:
- **Parent/child**: `Part of #<parent>` as the first line of the child body, plus a task list of
children in the parent body.
- **Blocking**: `Blocked by: #<n>, #<n>` near the top of the child body. A ticket is unblocked
when every listed blocker is closed.
### Labels
The five triage labels plus `wayfinder:map` and `wayfinder:research|prototype|grilling|task` must
exist before first use. After login, create missing ones with `tea labels create`; check with
`tea labels list`.
## Pull requests as a triage surface
**PRs as a request surface: no.** _(Set to `yes` if this repo treats external PRs as feature
requests; `triage` reads this flag.)_ Gitea shares one number space across issues and PRs: resolve
a bare `#42` with `tea issues 42`, falling back to `tea prs 42`.
## When a skill says "publish to the issue tracker"
Create a Gitea issue as above.
## When a skill says "fetch the relevant ticket"
Read it with `tea issues <number> --comments`.
## Wayfinding operations
Used by `wayfinder`. The **map** is a single issue with **child** issues as tickets.
- **Map**: issue labelled `wayfinder:map`, holding the Notes / Decisions-so-far / Fog body.
- **Child ticket**: `Part of #<map>` first body line, listed in the map's task list. Labels:
`wayfinder:<type>` (`research`/`prototype`/`grilling`/`task`). Once claimed, assigned to the
driving dev.
- **Blocking**: `Blocked by: #<n>` line (no native equivalent).
- **Frontier query**: list the map's open children (`tea issues list --state open`), drop any
whose `Blocked by:` names an open issue or that has an assignee; first in map order wins.
- **Claim**: `tea issues edit <n> -a <username>`, the session's first write.
- **Resolve**: `tea comments <n> "<answer>"`, then `tea issues close <n>`, then append a context
pointer to the map's Decisions-so-far (edit the map body).
+15
View File
@@ -0,0 +1,15 @@
# 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 "Label in our tracker" column to match whatever vocabulary you actually use.