MoAI-Cowork switched to Apache-2.0 one second after its 1.0.0 tag

Three releases in under three hours, with a licence change between them

The release history is worth reading as a sequence rather than a list, because the timestamps are the story. v1.0.0 was published at 06:27:01 on 2026-08-10, v1.1.0 at 06:27:02, and v1.2.0 at 09:17:06 the same morning. Each carries a descriptive name rather than a bare version. v1.0.0 reorganised the version scheme and unified seventeen plugins at 1.0.0, alongside a second design system version. v1.1.0 switched the project to Apache-2.0 and fully permitted commercial use of the outputs. v1.2.0 added an open source credit page and an MCP guide section, and renamed the connection tools with an moai-mcp- prefix. Two consecutive tags one second apart means the licence change shipped as an increment on a release that had just been cut, which is fast enough that anyone pinning 1.0.0 is on a different legal footing from anyone pinning 1.1.0. The repository is Apache-2.0 today, with a LICENSE-OUTPUT.md for output terms and both NOTICE and TRADEMARKS.md in the tree.

One rule file, and Claude.md is only an import line

The most reusable engineering decision here is how the same marketplace serves two desktop apps with different conventions. When the setup step finishes, it generates a project instruction file in which AGENTS.md is the canonical version, and CLAUDE.md contains nothing but a single import line pointing at it. Everything the project knows therefore lives in one file that both apps read, and the app-specific file is a pointer rather than a copy. That avoids the usual failure where two rule files drift apart and an agent gets contradictory instructions depending on which app you opened. The tree backs this up: there is an AGENTS.md at the repository root, an .agents directory, a .claude-plugin directory for the Claude manifest and a .codex directory for the other side. The README is explicit that the same marketplace is published through both manifests and that the rules file is generated per app, with CLAUDE.md and AGENTS.md named as the pair. The generated file also carries the project-specific agent and skill chain design, and guidance on external service API keys where one is needed.

The PM plugin routes and never does the work itself

The central design choice is that there is no swarm and no orchestrator loop. There is one entry plugin, moai-pm, whose entire job is to interview you once. You type the project command, the PM asks about your goal and your deliverables in interview form, reads the answers to detect what work is actually needed, and assembles the right coworkers and skills into an ordered chain. Once you confirm, it writes the rule file described above. After that, you stop typing skill names and simply describe what you want in one line of natural language, and the skills run themselves in sequence. The README states the boundary plainly: the PM does not do the work itself, its role is to work out who suits the task and assemble the team. The concrete example is document conversion being handled by one skill that produces a PPTX file and quality review being handled by another that strips the characteristic tics out of AI prose. Eighteen roles are listed in the README table, spanning a general coworker, writer, story creator, marketer, media creator, seller, officer, analyst, lawyer, accountant, recruiter, customer service manager, consultant, career coach, tutor, designer and a social poster.

The Makefile checks for vendored code drift on every canonical sync

The repository ships a Makefile whose first two lines give away how it was produced. It identifies itself as a project makefile for a different sibling project name, and says it was generated by an init command and should be customised as needed. In other words this repository is one instance of a shared scaffold rather than a hand-written build. What sits in that scaffold is more interesting than the header.

mcp-core-sync: ## Copy moai-mcp-core canonical source into every adopting MCP server
	@python3 scripts/sync-mcp-core.py

mcp-core-check: ## Fail if any vendored moai-mcp-core copy has drifted from canonical
	@python3 scripts/sync-mcp-core.py --check

One target runs the CI mirror locally and is described as covering lint, vet, test and cross-compile. Two targets operate on a shared MCP core: one copies the canonical source into every adopting MCP server, and the other runs the same script with a check flag whose stated purpose is to fail if any vendored copy has drifted from canonical. A third runs that core's test suite through pytest inside the shared plugin directory. The drift check is the part that matters for adoption, because a marketplace that copies one implementation into many server packages will otherwise rot in whichever copy nobody updates.

Installing needs an administrator on one app and not on the other

The two install paths are not symmetric, and the README is candid about why. On the Claude Cowork side you add the marketplace yourself from settings or plugins, then install the entry plugin from the plugin list, and the recommended companion is the general coworker plugin because it carries the shared text-output review core. On the ChatGPT Work side a workspace administrator has to import the marketplace first, entering the repository URL as the source and leaving the path empty because the marketplace lives at the repository root. If you are not an administrator, the instruction is to ask one. The practical consequence is that a ChatGPT Work rollout is an administrative task while a Claude Cowork rollout is a personal one, which matters for any team that has to standardise across a workspace. External service connections are authenticated separately from plugin installation, so a plugin being installed does not mean the third-party service behind it is connected. Later, when a task turns out to need a role you did not install, the setup step is supposed to detect that and prompt you to add it.

The README keeps placeholder comments where screenshots should be

Two things in the repository deserve to be called out because they are unfinished rather than wrong. First, the README contains two HTML comments marking the slots where marketplace-registration and plugin-installation screenshots should go, each one noting that a link should be supplied to replace a TODO line with a real image. That is an honest gap: the installation walkthrough currently relies on text and on an external documentation site rather than on pictures of the actual screens. Second, the plugin roster in the README is explicitly not authoritative. It says the exact current roster lives in the marketplace manifest file and that the table is a role summary, which is the right way to write it, though it also means the visible table can lag. The table lists eighteen roles while the 1.0.0 release note refers to seventeen plugins being unified at 1.0.0, and reconciling those two numbers means reading the manifest rather than either document.

The design target is Korean office work, not English developer tooling

The project explains its own existence in terms of who gets stuck. The audience is people who are not comfortable with English menus and developer-centric interfaces, people who have to think each time about what to type in, and people looking for tools that handle Korean business context. That context is specific and it shows up in the role list rather than in an abstract claim. The office role covers Hangul documents, Word, Excel, PowerPoint, PDF and Notion. The commerce role covers the Smart Store, Coupang, direct-to-consumer selling, product detail pages and advertising. The analyst role covers public data, actual transaction prices, auction results, stocks and statistical lookups. The lawyer role covers contract review, compliance, patents and real-estate registered names. The consultant role covers government grants and an office suite product by name. The media role is the one place English tool names appear, naming three external image and video services. The output side is regulated too: Korean polite register is treated as a requirement rather than a nicety.

Editorial conclusion

MoAI-Cowork fits a Korean-speaking team that does not write software but has real documentation, commerce and compliance work, and that wants a fixed set of expert roles rather than one general assistant. It does not fit anyone who needs the plugins to run their own code, because the package is prompt and workflow material rather than an execution environment, and it does not fit anyone who installed before 2026-08-10 and assumes the output terms they agreed to still hold. Before you commit, read LICENSE-OUTPUT.md separately from LICENSE, since the two were introduced days apart and say different things, check TRADEMARKS.md and NOTICE, and expect the exact plugin roster to be whatever .claude-plugin/marketplace.json says rather than what the README table lists.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. modu-ai/moai-cowork on GitHub
3. Project website
4. README
5. Releases