一键导入
mai-orchestrate
Use when coordinating work across multiple agents via teams. Create tickets, delegate, track deps, monitor progress, run reviews — all through mai.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when coordinating work across multiple agents via teams. Create tickets, delegate, track deps, monitor progress, run reviews — all through mai.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when a repo needs durable mai-backed context so every agent sees rules, rationale, and hazards before editing code. Covers promoting chat knowledge into tickets, constraints, warnings, ADRs, artifacts, and reviews; mirroring critical items into AGENTS.md; and enforcing mai context usage through arrival rituals, delegation templates, review gates, and verification.
Use when recording architecture decisions (ADRs). Decisions are kind:decision notes attached to code via --target, queryable via mai ls/context, and optionally materialize as markdown files. Covers detection triggers, tier system, comment templates, and anti-patterns.
Use when working in any git repo with maitake. Check for notes before touching files, leave notes after meaningful work. This is the base agent contract — all other mai skills build on it.
Use when setting or checking project rules that all agents must follow. Constraints show up in mai context alongside tickets and warnings. They stay open until the rule changes.
Use when creating, reviewing, or merging pull requests through mai. Git-native PRs stored as notes — no GitHub, no Forgejo, no platform lock-in. Covers creation, review (accept/reject), submission (merge), auto-close, and diff inspection.
Use when conducting research, oracle investigations, or delphi consultations. Save findings as mai notes with proper tags and structure.
| name | mai-orchestrate |
| description | Use when coordinating work across multiple agents via teams. Create tickets, delegate, track deps, monitor progress, run reviews — all through mai. |
mai ticket "Fix auth race condition" -p 1 -l auth --target src/auth.ts \
-d "Token refresh has a race condition. Add single-flight mutex."
# → tre-5c4a
mai ticket "Write auth tests" -p 2 -l test
# → tre-1111
mai ticket "Implement auth fix" -p 1 -l fix
# → tre-2222
mai dep tre-2222 tre-1111 # fix depends on tests first
mai dep tree tre-2222
# tre-2222 [open] Implement auth fix
# └── tre-1111 [open] Write auth tests
mai ticket "Review auth changes" -p 1 -l review \
--target src/auth.ts --target src/http.ts
# → rev-1234
teams delegate [{
"text": "Execute tre-5c4a. Run: mai show tre-5c4a to read the ticket. Run mai context on target files before working. Comment progress with mai add-note. Close with mai close when done.",
"assignee": "fix-auth",
"model": "openai-codex/gpt-5.4"
}]
teams delegate [{
"text": "Review rev-1234. Use mai-review skill. Leave findings on files with mai add-note --file. Include AC and REJECT in every finding.",
"assignee": "reviewer",
"template": "review"
}]
teams delegate [{
"text": "Fix the review findings on rev-1234. Run mai context on each target file to see findings. Fix each one. Comment your fixes with mai add-note --file.",
"assignee": "fixer",
"template": "fix"
}]
mai create "Investigate token refresh options" -k ticket -l research \
-d "Research mutex vs single-flight vs channel-based approaches."
# → res-4567
teams delegate [{
"text": "Execute res-4567. Research and post findings with mai add-note.",
"assignee": "oracle",
"template": "oracle"
}]
Every worker follows the same pattern:
# 1. Read the ticket
mai show <ticket-id>
# 2. Check file context
mai context <target-file> # see warnings, constraints, review findings
# 3. Work...
# 4. Comment progress (file-specific when relevant)
# Long notes: write to /tmp first, pipe in (see mai-agent skill for the pipe pattern)
mai add-note <ticket-id> "progress update"
mai add-note <ticket-id> --file src/auth.ts "added mutex here"
# 5. Close when done
mai close <ticket-id> -m "summary of what was done"
mai ls # open work queue (sorted by priority)
mai ls -k ticket # only tickets
mai ls -l review # review tasks
mai search "auth" # find related notes, tickets, decisions
mai search "auth" -k ticket # search within tickets only
mai ready # unblocked — can start now
mai blocked # waiting on deps
mai dep tree <epic-id> # full work breakdown
mai closed # recently completed
mai doctor # health stats
The full review-fix-approve cycle:
# 1. Create review ticket
mai ticket "Review: feature X" -l review --target src/foo.ts --target src/bar.ts
# 2. Delegate to reviewer
teams delegate [{"text": "Review ...", "template": "review"}]
# → reviewer leaves findings on files with AC/REJECT
# 3. Delegate to fixer
teams delegate [{"text": "Fix review findings on ...", "template": "fix"}]
# → fixer reads mai context, fixes, comments
# 4. Delegate re-review
teams delegate [{"text": "Re-review ...", "template": "review"}]
# → re-reviewer verifies, approves, closes
mai link tre-5c4a rev-1234 # ticket ↔ review
mai dep tre-impl tre-design # impl depends on design
mai show tre-5c4a # see all links and deps
mai show, not the task text.mai context on target files. This is how they see warnings, constraints, and findings.--file on all findings. Fix agents see findings in-place.