maitake

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 coordinating work across multiple agents via teams. Create tickets, delegate, track deps, monitor progress, run reviews — all through mai.

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.

Use when performing code review or requesting changes. Leave findings directly on files with acceptance criteria and rejection criteria. Fix agents see findings in-place via mai context.

Use when setting up maitake in a repo for the first time, configuring sync to a remote, or troubleshooting the setup.