- qwen_delegate MCP tool: src/qwen-delegate.ts (testable core, subprocess spawn/timeout/parse) + src/qwen-delegate-server.ts (thin MCP stdio wiring) - test/qwen-delegate.test.ts (node:test, mocked spawn) - docs/agents/* + CLAUDE.md from /setup-matt-pocock-skills (Gitea issue tracker via tea CLI, default triage labels, single-context domain docs) - research/qwen-mcp-delegation.md, corrected after confirming qwen-code runs natively on Windows (no WSL) against a local OpenAI-compatible proxy Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CRnb5Gqdu7gVTQrwAqFdfJ
3.2 KiB
Issue tracker: Gitea
Issues and specs for this repo live as issues on this repo's Gitea instance (git.arthurerlich.de, haylan/delegate-ai-mcp). Use the tea CLI for all operations — it auto-detects the repo and remote login from git remote -v/tea login list when run inside this clone.
Conventions
- Create an issue:
tea issue create --title "..." --description "..."(-Lto add labels,-ato assign). - Read an issue:
tea issue <index> --comments. - List issues:
tea issue list --state open --labels "..." --fields index,title,state,labels,comments. - Comment on an issue:
tea comment <index> "..."(shorthand fortea comment add). - Apply / remove labels:
tea issue edit <index> --add-labels "..."/--remove-labels "...". - Close:
tea issue close <index>, thentea comment <index> "..."first if a closing note is needed (tea issue closehas no--commentflag).
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.)
When set to yes, PRs run through the same labels/states as issues, using the tea pull equivalents (tea pull list, tea pull <index> --comments, tea issue edit <index> --add-labels/--remove-labels — labels/comments are shared machinery between issues and PRs in Gitea's API). Gitea shares one number space across issues and PRs, so a bare #42 may be either — tea issue <n> and tea pull <n> both resolve by index; try the one implied by context.
When a skill says "publish to the issue tracker"
Create a Gitea issue: tea issue create --title "..." --description "...".
When a skill says "fetch the relevant ticket"
Run tea issue <index> --comments.
Wayfinding operations
Used by /wayfinder. The map is a single issue with child issues as tickets.
- Map: a single issue labelled
wayfinder:map, holding the Notes / Decisions-so-far / Fog body.tea issue create --title "..." --labels wayfinder:map. - Child ticket: an issue referencing the map. Gitea's CLI/API here has no native sub-issue or issue-dependency graph like GitHub's, so track structure in the body: put
Part of #<map>at the top of the child body, and keep a task list of children in the map body. Labels:wayfinder:<type>(research/prototype/grilling/task). Once claimed, assign the ticket to the driving dev (tea issue edit <n> --add-assignees <user>). - Blocking: no native dependency graph — use a
Blocked by: #<n>, #<n>line at the top of the child body. A ticket is unblocked when every blocker referenced there is closed (check each withtea issue <n> --fields state). - Frontier query: list the map's open children (
tea issue list --state open --labels wayfinder:<type>, cross-referenced against the map's task list), drop any with an open blocker (per theBlocked byline) or an assignee; first in map order wins. - Claim:
tea issue edit <n> --add-assignees <your-gitea-username>— the session's first write. - Resolve:
tea comment <n> "<answer>", thentea issue close <n>, then append a context pointer to the map's Decisions-so-far.