spardanviro

MultiAgentGameStudio — Testing skill for Claude Code

Testing community

Claude Code plugin for spec-driven multi-agent builds.

How to install MultiAgentGameStudio

This entry records only its repository, not the path inside it, so there is no exact command to give. Open spardanviro/MultiAgentGameStudio and copy the folder into ~/.claude/skills/, or the file into ~/.claude/agents/.

What MultiAgentGameStudio does

Claude Code plugin for spec-driven multi-agent builds. A Main Architect splits a spec into module folders with one owner each; agents implement them in parallel isolated git worktrees under hook-enforced write scopes. Each accepted module lands as its own commit on a per-run branch, reviewers gate every stage, and rework runs close the loop.

Alternatives in Testing

Deslop Reborn — One iteration of the IronClaw Reborn de-slop loop — take ONE Reborn crate, fan out parallel review sub-agents 12.6k ★
Debug — You are tasked with helping debug issues during manual testing or implementation 10k ★
Sentient — Test prompt to showcase claude code hook blocking a dangerous rm -rf command 3.4k ★

README

MultiAgentGameStudio

**module-pipeline** is a Claude Code plugin that builds a project from a written spec using a team of agents. The work is split into modules, and each module agent is fenced into its own folder. Agents write in parallel, each accepted module becomes its own git commit, reviewers check every stage, and failed work goes back into a planned rework run.

This repository is a Claude Code plugin marketplace that contains that one plugin, in [`plugins/module-pipeline`](plugins/module-pipeline/).

**Status:** covered by unit and workflow-harness tests, but not yet run end to end in a real Claude Code session. Expect rough edges and please open an issue if something breaks.

Why
What it does
How a run works
Requirements
Install
Quick start
Commands
The task manifest
Results and statuses
The rework loop
Finishing a run
Files it writes
Tips for good results
Troubleshooting
Repository layout and development

Why

Letting several agents write the same codebase at once usually goes wrong in predictable ways. Two agents edit the same file. One "fixes" another's code to unblock itself. Nobody can say which change came from which agent. Reviews happen too late, or not at all.

module-pipeline makes every one of those a rule the tooling enforces, instead of something a prompt merely asks for:

Problem	What the plugin does
Agents overwrite each other	Every module owns exactly one folder. The manifest is rejected if two modules own the same or nested folders.
An agent reaches outside its area	A `PreToolUse` hook blocks edits outside the module's allowed files while the agent works,