Multiplayer AI Framework

Deep Research is an add-on for either lane. I use it when the work depends on current facts, a market landscape, user evidence, or technical choices that should not come from memory alone.

1. 01

   Project Launch

   Turns an early idea into a decision-ready product brief and launch sequence. It forces clarity on the user, wedge, scope, risks, and evidence before the build accelerates.

2. 02

   Project Build Orchestrator

   Runs a greenfield plan as a sequence of bounded delivery phases. Each phase has an owner, inputs, outputs, gates, and a receipt before the next phase inherits it.

3. 03

   Feature Pipeline

   Handles non-trivial changes to an existing codebase. It inspects reality first, narrows the request, writes an executable ledger, and keeps implementation small enough to review honestly.

4. 04

   Audit and Verify

   Separates building from certification. A fresh reviewer inspects the exact diff, classifies findings, runs the real surface, and repeats after fixes because fixes can introduce new bugs.

5. 05

   Deep Research

   Builds a source-backed answer instead of a fluent guess. It keeps citations close to claims, distinguishes evidence from inference, and makes uncertainty visible.

03 / Coordination

The skills talk through artifacts

“Talk to each other” is easy shorthand, but it can imply more automation than exists. The reliable mechanism is an artifact contract. One skill produces a named file or verified state; the next reads that output and has explicit permission to continue, stop, or return it for revision.

• Briefs and build guides carry the product intent and accepted scope.
• Ledgers and statuses show what is proved, pending, blocked, or deliberately deferred.
• Exact Git SHAs pin review to the code that was actually inspected.
• Proof receipts record raw commands, outcomes, and browser evidence rather than “tests passed” as a vibe.

That structure also makes the system recoverable. A new agent or a human can reconstruct what happened from durable evidence instead of depending on hidden conversation state.

04 / Control

Authority stays separate from capability

An agent may be capable of editing code, opening a pull request, changing infrastructure, or sending a message. That does not mean it has authority to do all of those things. The system treats scope, credentials, deployment, external communication, money, and destructive actions as separate grants.

It also separates implementation from certification. The builder cannot simply declare its own work clean. Review points to an exact base and head SHA, tests run against that state, and any fix changes the state and triggers a refreshed review. This does not guarantee correctness. It makes the evidence specific, repeatable, and harder to hand-wave.

05 / Limits

What this system does not promise

• It does not make models deterministic or eliminate product judgment.
• It does not guarantee bug-free software. Independent review and real-product testing reduce risk; they do not erase it.
• It does not create automatic runtime communication between agents. Coordination depends on tools that can read the shared artifacts.
• It is not universally compatible with every agent host. The public packages are plain skill directories, but each environment may require its own installation convention.
• It does not authorize production deployment, credential use, spending, or external communication on its own.