OneDro1d Set it up
The kits

The OneDroid kit

The kit to build your
dark software factory.

In a dark software factory, AI agents do the work, mission in and verified software out, and evidence, not the agents' word, decides what ships. It takes four parts. They are in the order that gives you the most for the effort, and testing comes first: the difference between vibe coding and agentic engineering is good testing.

Tell your coding agent:

Read https://onedroid.ai/kit and set me up with the kit.
Stop and ask me wherever it needs my decision or my login.
The four parts The steps

For you

The four parts, and why you need each.

You don't need to know any of these names yet. Each part says what problem it solves, what it does, and what it costs.

1

Testing: OneDroid Argus

Why you need it. An agent reporting "done, all tests passing" is a claim, not a fact. An agent that tests its own work tests its own reading of the ticket, and a model that can see its checker learns to satisfy the checker.

What it does. Automated end-to-end testing for AI-written code. A separate tester, your QA engineer or an agent but never the builder, writes each check from the ticket and the acceptance criteria, before the build: what to trigger, where to look, what a healthy answer is. The checks run against the running system with nothing mocked. Your coding agent's credential can ask for a run and read the verdict, and cannot read a check or an expected value. The checks stay as regression checks for the next change.

What it costs. In one measured experiment, Claude Code built a feature for $1.01 to $1.97 a run, and the independent tester's session, which wrote the checks once for the whole feature, cost about $5.30 (the experiment, its figures and its limits). The runner is open source under MIT; the hosted control plane is open to sign up and evaluate. How OneDroid Argus works.

2

Eyes and hands: OneDroid Synapse

Why you need it. To do real work, an agent has to reach the tools you already use: your documents, your tickets, your calendar, your email. Wired one config file at a time, those connections are invisible to the people responsible for them.

What it does. A gateway between your agents and your accounts. You connect the services you choose (Google Workspace, Atlassian, Slack and others), and your agents connect once. Access exists only for accounts you connect, limited to the permissions you grant, and every tool call is authenticated, policy-checked and logged while the hub's activity logging is on (fail-open: a logging failure never blocks a call), to an audit log you own.

What it costs. Free on the hosted shape, whatever the size of your team. No credit card. What OneDroid Synapse does.

3

Memory and context: OneDroid Engram

Why you need it. A model session ends and takes everything with it. The next tool starts from nothing, so the same context gets re-pasted, re-explained and re-discovered, by every agent, every time.

What it does. Versioned, permissioned memory in a Postgres you control with your own database, or one OneDroid hosts, searched by vector, keyword and graph at once, and reachable by any MCP client behind any model. What one agent wrote, the next one can find. Every write is a commit: diff any two versions, or restore a previous one in one call.

What it costs. Included with a Synapse account, and it runs on its own too. Free on the hosted shape, whatever the size of your team. What OneDroid Engram does.

4

The method: the Dark Factory kits

Why you need it. Parts 1 to 3 are tools. The method is how your agents use them together: who does what, in which order, what has to be proven before work moves on, and what always stops for you.

What it does. Product owner, architect, test-first developer and QA, each a skill your agent runs in order. Acceptance criteria become a failing test list before any code is written. An adversary gate checks the evidence for each claim (test output, diffs, exit codes) without redoing the work, and work that fails the gate goes back. Hooks enforce what must not depend on the model choosing to comply: a rule in a prompt is a request, a hook is a control. An autonomy policy says what the agents decide alone, what they log, and what always stops for a human.

What it costs. Nothing. Open source under Apache-2.0, with no paid tier. It lives in a private GitHub repository you own. What the kits are.

Where it stops for you: your sign-ups and logins (OneDroid Argus, Synapse, Engram and GitHub), which kit, the name of your repo, and the tools you connect. No script signs in for you or grants access on your behalf.

For your agent

The steps, in the same order, each with its check.

Agent: do the parts in order. Every step ends with a check: run it, and do not move on until it passes. Stop and ask the human at the steps marked HUMAN, and whenever a runbook says to stop (a setup that is somebody else's, a tool that is missing). Never report a step as done without its check. Where a step links to a runbook, the runbook wins over this summary if the two ever disagree.

Part 1 · Testing: OneDroid Argus

01

Get an account and the CLI

HUMAN: create an account at argus-dev.onedroid.ai (e-mail, Google or Microsoft). It is the evaluation environment: for testing, with no promise that data is kept, so keep production data out of it. Then follow the OneDroid Argus quickstart from its step 1. Without access to a release, build the CLI from the open-source runner:

git clone https://github.com/OneDro1d/argus-runner
cd argus-runner
go build -o argus ./cmd/argus
./argus version

Check: argus version prints its version. It needs no token.

02

Keep the tester and the builder apart

The session that writes the checks is never the session that writes the code. The tester's credential writes, seals and reveals; the builder's can start a run and read the verdict, never a scenario or an expected value. Set the two up as Set up a tester and a builder says.

Check: the tester and the builder use different credentials, and the coding agent holds only the builder's.

Part 2 · Eyes and hands: OneDroid Synapse

03

Create a hub and connect the agent

HUMAN: sign in at synapse.onedroid.ai, create a hub, then Manage → API Tokens → Create token. The token is shown once. Then connect Claude Code with one command and open a new session, because tools load only when a session starts.

claude mcp add --transport http synapse \
  https://synapse.onedroid.ai/agent/mcp \
  --header "Authorization: Bearer <token>"
claude mcp list

Check: claude mcp list shows synapse … ✓ Connected. Enabling a service on the hub and saving the human's login for it are two different actions, and only the second lets the agent call anything: if the agent connects and sees no tools, this is why. The full walk-through is the quickstart, part 1.

Part 3 · Memory and context: OneDroid Engram

04

Write one thing, search it back

Through the Synapse hub, where the Engram connection is already on, or HUMAN: sign in at engram.onedroid.ai and create a library token for https://engram.onedroid.ai/mcp. Then write a note into a namespace with engram_write and find it with engram_search.

Check: the write returns an object id, and the search returns that object. The full walk-through is the quickstart, part 2.

Part 4 · The method: the Dark Factory kits

The runbook is START-HERE.md in the public repository. Execute it top to bottom; the steps below summarise it.

05

Check the tools

You need git, jq, bash, python3, gh and claude, and a gh login that can see the repository. HUMAN if gh is not logged in: gh auth login.

for c in git jq bash python3 gh claude; do command -v "$c" >/dev/null && echo "ok       $c" || echo "MISSING  $c"; done
gh auth status
claude -p 'Reply with the single word: ok' --output-format text

Check: every tool prints ok, gh auth status shows an account that can see the kit, and the last command prints ok. A tool is missing: tell the human which, and stop.

06

Clone the method and list the kits

Seven kits today: method-core (the method itself), dev (writing and shipping code), knowledge-worker (documents rather than code), agent-ops, code-review, distributed-systems, frontend.

git clone https://github.com/OneDro1d/dark-factory
cd dark-factory
bash starter-kit/instance/bootstrap.sh --kit list

Check: the list prints the kits, method-core among them. Pick one before the next step.

07

Make the human's own copy

HUMAN: choose the kit, a name for the setup and the GitHub owner. The bootstrap writes a new directory beside the checkout, pinned to today's commit, and the copy goes to a private repository.

bash starter-kit/instance/bootstrap.sh <name> --kit <kit>
cd ../<name>
git init -q
git add -A
git commit -q -m "my agent setup, from kits/<kit>"
gh repo create <owner>/<name> --private --source . --remote origin --push

Check: gh repo view <owner>/<name> --json visibility -q .visibility prints PRIVATE. From here on, run from the new directory and follow its START-HERE.md.

08

Add this machine and install

Every machine gets its own record under instances/, named as START-HERE.md step 3 says. Then install from that record.

bash install.sh --lock=instances/<machine>/loom.lock.json

Check: read the exit code, not the last line. 0 means installed and proven, 1 means a precondition failed and nothing was installed, 2 means the result does not match the record.

09

Connect the human's tools

HUMAN, one item at a time. The hub from step 03 is the one to record here: it gives the agent memory across sessions and connectors to the systems the human already uses. The method also runs without one. Then open a new session, because tools and hooks load only when a session starts.

Check: df-preflight --report shows no drift on a hub or connector the record declares (unknown means it could not look, which is neither a pass nor a failure).

10

Validate

A fresh session exercises every gate the kit installs and commits its report to the human's repo by itself.

bash boot-kit/scripts/validate.sh --kit-root "$PWD" --headless

Check: exit 0, a new VALIDATE-REPORT-*.md on the repo's main, and its Broken section says nothing is broken. Show the human that section word for word.

No skill system?

For ChatGPT, Gemini or a plain API model, paste DARK-FACTORY-PRIMING.md into the conversation. It inlines every stage skill and the adversary gate.

Only the skills?

Each skill is also served from this site: the skills index lists them, and each lives at /.well-known/skills/<name>/SKILL.md. You skip the lockfile, the pins and the validation that way.

Something went wrong?

START-HERE.md ends with a table of the failures people actually hit. For hub and token errors, the troubleshooting page has the one probe that tells them apart.

Testing first. Always.

The difference between vibe coding and agentic engineering is good testing. That is why the kit starts there. Questions about the kit or about testing what your agents build: write to us.

michal@onedroid.ai