prior-art-reference

name	prior-art-reference
description	Standing pointer to the broader landscape of open-source agent harnesses, meta-harnesses, governance layers, multi-agent orchestrators, and usage/cost observability sidecars that solve problems adjacent to MultiTable. **Consult proactively** when (a) the user explicitly names a project — Mastra, OpenHarness, "Microsoft Agent Governance Toolkit", Cordum, CrewAI, LangGraph, "Strands Agents", "Harness SDK", VoltAgent, MetaGPT, ruflo, "Claude Flow", artificial (the Go harness), "Claude Squad", OpenCode (sst/opencode), Archon, CodexBar, awesome-agent-harness, awesome-harness-engineering, "9 open-source agent orchestrators" — or asks "is there an OSS project that does X", "what's prior art for Y", "similar projects to MultiTable", "harness comparison", "agent governance frameworks", "meta-harness", "multi-agent orchestrator", "cross-provider usage limits", "menu-bar usage tracker"; **AND ALSO** (b) work is stuck on a persistent bug that's resisted two or more fix attempts in an area covered by the parallels table (provider adapters, permission/governance, multi-agent, parallel-agent isolation, model catalog, usage limits, sandboxing, workflow templates, observability); (c) scoping a non-trivial new feature in any of those areas — read this *before* designing rather than after; (d) hitting an unfamiliar protocol/wire-shape question that another harness has likely already solved. Reference only — not a provider, not implying any port.
allowed-tools	Read, Grep, Glob, Bash, WebFetch

prior-art-reference

A curated directory of ~16 open-source projects that overlap with MultiTable's problem space: unified harnesses over multiple AI coding agents, governance/policy layers, parallel-agent isolation, and multi-agent orchestration. Future sessions consult this skill before designing a new feature, to check what comparable projects already do.

This skill is a standing pointer. It is reference only — read it to compare and steal ideas at the design level, not to port code. Any decision to copy code is a separate, case-by-case decision and is not implied by this skill loading.

The dedicated omnigent-reference skill handles MultiTable's closest single sibling (omnigent-ai/omnigent) at much greater depth. This skill is the broader landscape around it.

When to consult this skill proactively

The skill exists so MultiTable doesn't re-derive solved problems. Reach for it freely — don't wait for the user to name a project. Three concrete triggers:

1. Persistent bug (two or more failed fix attempts)

If you've tried to fix a bug twice and it's still broken — especially in an area another harness has clearly solved (per reference/parallels.md) — stop and check prior art before a third attempt. Likely candidates:

• Permission/approval flow bugs → OpenHarness, Microsoft Agent Governance Toolkit, omnigent
• Streaming/delta accounting bugs → Mastra, OpenCode, the provider whose protocol you're adapting
• Session resume / persistence bugs → omnigent, LangGraph (checkpointing), Mastra (threads)
• Parallel-session isolation bugs → Claude Squad (git-worktree-per-agent)
• Usage-limit / rate-limit parsing bugs → CodexBar (53+ providers)

Pull the relevant project's source via WebFetch or gh api, find the analogous code path, and compare. A second design point almost always exposes the assumption you missed.

2. Complex new feature

Before writing a non-trivial feature in any concept area listed in reference/parallels.md, read what the listed projects already do. This is cheap (1–2 WebFetch calls) and shapes the design — don't ship a v1 that the existing harnesses already iterated past. Mention what you found to the user as part of the plan, with project names cited.

3. Unfamiliar protocol / wire-shape question

If MultiTable is about to integrate a new transport, parse a new event stream, or implement a new gating mechanism, the odds are high that one of these projects already faced it. Search their repos first; you may save a day.

In all three cases: cite each project by name, don't blend concepts (see pitfalls), and remember — this skill authorizes reading their code for inspiration, not porting it. Any decision to copy code is a separate, case-by-case call.

Strict isolation note

• These projects are external prior art, not MultiTable providers. There is no Mastra/CrewAI/LangGraph adapter under packages/daemon/src/agent/providers/, and there shouldn't be — adding one is a separate user-directed decision, not something this skill authorizes.
• Never blend concepts from multiple projects into a single recommendation as if they were one design. Cite each source by name when you reference it.
• URLs decay. Before quoting current behavior (APIs, feature lists, license terms), verify with WebFetch against the URLs in reference/projects.md or gh api repos/<owner>/<repo>.

Quick task → file map

What you want	Read
The full project list with TL;DRs and URLs	reference/projects.md
MultiTable concept → which projects to consult	reference/parallels.md
Mis-uses and cautions	pitfalls.md

Decision tree: where do I look?

"Is there an OSS project that does <X>?"
├── Which MultiTable concept does <X> map to? ───── reference/parallels.md
├── Need the project's URL, TL;DR, or relevance ─── reference/projects.md
└── Want to read the actual source                ─── reference/projects.md → URL → WebFetch / gh api

When to not use this skill

• The user is working on an existing MultiTable provider (Claude, Codex, Hermes, Grok, Cursor). Use that provider's dedicated skill instead.
• The user is asking how omnigent specifically does something — use omnigent-reference.
• The user is asking about Claude API / Anthropic SDK semantics — use claude-api or claude-agent-sdk.