10X WORKFLOW // MODULE 5 // 5 LESSONS
Marcin and Przemek supervise isolated parallel agent work streams with gates and human review
TEAMWORK + SCALE

More autonomy and parallelism without skipping control, isolation or the review queue.

MODULE 5 // TEAMWORK

An agent earns its keep only when it works without you

Teamwork in 10x Workflow: five lessons on an agent working for the team - the smallest helper instead of a platform, an agent built from SDK primitives, review on every PR, a registry of shared skills and async delegation. The module's second thesis: AI artifacts are code - one source of truth, versions, distribution. This module closes the 10xChampion block: one of two projects is enough, and screenshots are the proof.

TEAM CONSTELLATIONSKILL PACKAGES: FROM THE REGISTRY TO EVERY NODETEAMwhat to build, what to buy?TOOLsdk primitives + costsAGENTpulse: every PR, while you sleepREVIEW-CIone version of truthREGISTRYASYNCorders before the action

TEAM CONSTELLATION // CLICK A NODE TO FLY TO A SECTION

Module recap · five lessons in 30 seconds

REMEMBER:

An agent starts earning for the team only once it runs without you.

LESSON 01The Expanse · Belters

AI Internal Builders - what to build, what to buy?

"Out in the Belt nobody waits for a shipment from the inner planets. You take what is at hand and seal the breach before the air runs out."

- a Belter mechanic, at the airlock
DATADECISIONLOCAL GAPSMALLEST HELPERBUY: SAAS WHERE THE RESPONSIBILITY IS PLATFORM-GRADEBUILD: AROUND THE TEAM'S GAP
FIG. 01 // A GAP CLOSED WITH THE SMALLEST TOOL

Belters do not wait for a shipment from the inner planets - they take what is at hand and seal the breach before the air runs out. Internal team tools grow out of the same logic: wherever SaaS carries platform-grade responsibility - auth, billing, compliance - you stay with SaaS. You build only around the team's local gap that no off-the-shelf product knows: data visualization instead of another round of questions to the analysts.

Internal team tools follow one simple rule: wherever SaaS carries platform-grade responsibility - auth, billing, compliance - you stay with SaaS. You build only around the team's local gap that no off-the-shelf product knows.

Input: a real gap in the team's flow. Output: the smallest tool that closes it - and a build vs buy decision made deliberately, not out of momentum. Mechanism: before the first line of code, you ask one question - who takes the responsibility when the tool fails; if the platform does, you buy; if the gap is yours and yours alone, you build the smallest thing that works.

Question
what to build, what to buy?
Guarantee
the smallest tool that closes a real gap
Artifact
an internal helper closing the team's gap
Tools
build vs buy, the smallest helper
GOAL:

whenever someone says "let's build ourselves a tool" - build only around a local gap, buy wherever SaaS carries platform-grade responsibility.

DEEP DIVE // 10x-prdEXPAND ↓
  1. 01WHY

    Before the team builds a tool out of momentum, the gap goes on paper: the PRD defines the problem, the users and the boundaries - and only on that basis do you decide whether to build at all.

  2. 02INPUT → OUTPUT

    Input: shape-notes.md from the discovery stage (or raw notes). Output: context/foundation/prd.md conforming to a locked schema - 10 sections for a greenfield project, 11 for a change in an existing system.

  3. 03MECHANISM

    A 0-4 heuristic scores whether the notes are shaped: a checkpoint block, requirements in FR-NNN format, Given / When / Then scenarios, an explicit business rule. Below the threshold the skill warns outright: what is missing and what it costs the document. Generation happens in memory, with schema validation before anything lands on disk.

  4. 04ANATOMY

    For a change in an existing system: a review of the current state, problem and motivation, personas, success criteria with "what must not break" guardrails, stories, functional and non-functional requirements, Non-Goals and Open Questions.

  5. 05BOUNDARIES

    The skill is a document generator, not a discovery facilitator: it never invents domain decisions, business rules or success criteria. Every gap goes verbatim into Open Questions - a human resolves it, not the generator.

LESSON 02Ender's Game · Building the team

The first team agent - what is an agent made of once you strip away the IDE?

"You do not get a ready-made soldier. You pick him, assemble him from what he has, and measure him in every battle - trust comes after results."

- a training army commander, before the first battle
MODELTOOLSLOOPCONTEXTAGENTCOST METERFORK: READY-MADE SDK VS ASSEMBLE-IT-YOURSELFMETRICS FROM DAY ONE
FIG. 02 // AN AGENT FROM PRIMITIVES, COSTS FROM DAY ONE

Ender does not get a ready-made army - he gets recruits and builds a team out of them: he picks, positions and measures in every battle before he trusts anyone. The first team agent is built the same way: you go one level down, below the IDE, to the SDK primitives - model, tools, loop, context - and assemble from them a new team member whose behavior you understand, because you put it together yourself.

The first team agent is built one level down, below the IDE: from SDK primitives - model, tools, loop, context - you assemble a new team member whose behavior you understand, because you put it together yourself.

Input: the primitives of an agent SDK. Output: an agent assembled deliberately, with a cost meter and metrics from day one. Mechanism: the project's first fork - ready-made SDK vs assemble-it-yourself - settles how much control you need; and you measure costs from the start, because an agent without a meter is a team member whose salary nobody knows.

Question
what is an agent made of once you strip away the IDE?
Guarantee
an agent assembled deliberately, with a cost meter
Artifact
the first team agent + cost metrics
Tools
agent SDKs, cost metrics
GOAL:

before the team trusts the agent - from primitives, deliberately, with a cost meter from day one.

LESSON 03Solaris · The ocean studies its researchers

Code review in the AI era - who watches every PR while you sleep?

"We probed the ocean for years before we understood that it was probing us. Every study leaves a trace in the studied - and in the one who studies."

- station log, Solaris research station
PRMERGEOBSERVER-REVIEWERLOOP: NEXT PR, WITHOUT YOUSEVERITY × IMPACTAGENT COMMENT ON EVERY PRTRIAGE: FIX-WORTHY VS NOISE
FIG. 03 // AN OBSERVER ON EVERY PR, IN A LOOP

The ocean of Solaris cannot be studied from the outside - it responds to observation and sends back to the researchers what they themselves brought in: the observer changes the observed system. Code review in the AI era runs on the same physics: an agent as a pipeline step, triggered without you on every PR - including the one submitted at three in the morning - is observation that shapes both the code and the team, because an author writes differently knowing the review will always come.

Code review in the AI era is an agent as a pipeline step, triggered without you on every PR - including the one submitted at three in the morning, including the one you would not have had the energy to read.

Input: a PR in the team's repository. Output: a CI pipeline in which the agent leaves a comment on every PR - review stops depending on your calendar. Mechanism: /10x-impl-review-ci on GitHub Actions scores changes by severity × impact, and triage separates findings worth fixing from noise - a reviewer who reports everything is just as useless as one who reports nothing.

Question
who watches every PR while you sleep?
Guarantee
review on every PR, not just when you have time
Artifact
a CI pipeline with an agent comment on the PR
Tools
/10x-impl-review-ci, GHA / Claude Code Action, PR comment
GOAL:

the module's thesis - an agent earns its keep only when it works without you: review on every PR, not when you happen to have the energy.

DEEP DIVE // 10x-impl-review-ciEXPAND ↓
  1. 01WHY

    Review on every PR with no human in the loop: an agent in CI compares the diff against the plan the PR declares it implements, and leaves a durable audit trail - a report, inline comments, a verdict.

  2. 02INPUT → OUTPUT

    Input: a PR plus a plan - found by the context/changes/<id>/plan.md convention or a "Plan:" line in the PR description. Output: a reviews/impl-review.md report committed to the PR branch, inline comments on the changed lines and a summary comment with a table of dimensions.

  3. 03MECHANISM

    Diff from the merge-base → three subagents in parallel: drift against the plan (MATCH / DRIFT / MISSING / EXTRA), safety and conformance with neighboring patterns, test coverage → verification commands from the plan → scores across seven dimensions → an APPROVED / NEEDS ATTENTION / REJECTED verdict.

  4. 04ANATOMY OF A FINDING

    Severity (CRITICAL / WARNING / OBSERVATION), impact, dimension, file:line location, detail and a proposed fix with explicit strength, cost and confidence. A limit of 10 findings - related problems get consolidated, and sorting by severity separates findings worth fixing from noise.

  5. 05BOUNDARIES

    The skill asks nothing and edits no code: it reads, analyzes, reports. A missing plan in a PR means a neutral comment and an exit, not a failure. A REJECTED verdict blocks the check only in the workflow - with an override label after a human decision.

LESSON 04Foundation · The Encyclopedia

Shared AI Registry - where does the team get shared skills?

"Empires fall, copies drift. The knowledge that survives is the one with a single source, an edition number and a route to every planet."

- curator of the Encyclopedia, preface to an edition
V1.0.0V1.1.0V2.0.0REGISTRY // ENCYCLOPEDIAIDECLICIDISTRIBUTION BY AUDIENCE, NOT BY FLASHONE VERSION OF TRUTHINSTALL / UPDATE / UNINSTALL
FIG. 04 // ONE SOURCE, VERSIONS, MANY TOOLS

The Encyclopedia Galactica was created so that knowledge would survive the fall of an empire: a single source, an edition number, a route to every planet. A team's shared skills need exactly that, because AI artifacts are code - skills, commands and rules get one source of truth, versions and a distribution mechanism, instead of drifting copies pasted between machines.

AI artifacts are code: skills, commands and rules get one source of truth, versions and a distribution mechanism - instead of drifting copies pasted between machines.

Input: skills and rules scattered across the team's computers. Output: a package registry - a repo with a package definition, released versions and auth, from which everyone installs the same truth. Mechanism: install / update / uninstall like in a package manager, delivering to multiple tools - you pick the distribution channel by the audience meant to use it, not by how flashy the demo looks.

Question
where does the team get shared skills?
Guarantee
one version of truth instead of drifting copies
Artifact
a package registry: package definition + released versions
Tools
/10x-contract, package registry, versioning
GOAL:

the module's second thesis - AI artifacts are code: one source of truth, versioned and distributed, instead of copies drifting apart.

DEEP DIVE // 10x-contractEXPAND ↓
  1. 01WHY

    Register a name or schema that is load-bearing: changing it forces a coordinated update across its consumers. The registry makes future plan reviews flag contract-breaking changes automatically.

  2. 02INPUT → OUTPUT

    Input: a freshly created or newly recognized contract - a schema field, an API endpoint, a frontmatter format. Output: an H2 entry in docs/reference/contract-surfaces.md, which /10x-plan-review greps against the text of every future plan.

  3. 03ANATOMY OF AN ENTRY

    The surface name (the H2 heading is the literal grep target - fully qualified instead of a bare identifier), the canonical file:line definition, owners and consumers, and a breaking-change checklist ready to paste into a migration plan.

  4. 04MECHANISM

    A four-question interview - the user writes the content, the skill suggests nothing upfront → an echo of the entry and confirmation → self-bootstrap of the file on first use → append at the end of the registry.

  5. 05BOUNDARIES

    The file is append-only - revisions are made by a human, by hand, and that friction is deliberate. One entry per invocation. The entry bar: if a rename breaks something only in a local module, it is not a contract and no entry is created.

LESSON 05Red Rising · The Howlers pack

Async and remote agents - how do you delegate work at a distance?

"You do not lead a pack by the hand. Orders and boundaries come before the action - then you operate in the dark, and your report goes back to the commander."

- pack commander, briefing before the drop
COMMANDERORDERS BEFORE THE ACTIONREPORTS RETURN FOR REVIEWSANDBOXNETWORK AND SECRET BOUNDARIES
FIG. 05 // ORDERS BEFORE THE ACTION, CONTROL IN THE REPORTS

The Howlers do not wait for the commander to approve their every move - orders and boundaries are set before the action, then you trust the pack and read the reports that come back. Async and remote agents are the same doctrine: delegation with deferred control - the sandbox and the network and secret boundaries are set before the agent launches, because nobody renegotiates the rules mid-action.

Async and remote agents are delegation with deferred control: the sandbox and the network and secret boundaries are set before the agent launches - and control returns in reports and review.

Input: a task that does not require your presence. Output: an agent working remotely in a sandbox with explicitly drawn boundaries - and a report that comes back for review. Mechanism: responsibility does not disappear with delegation, it changes when it happens - it returns in monitoring and review; you control the outcome, not every move.

Question
how do you delegate work at a distance?
Guarantee
boundaries set before the agent moves; control returns in review
Artifact
a task delegated remotely + a report in review
Tools
sandbox, network/secret boundaries, monitoring
GOAL:

when delegating - boundaries before launch, control in review; responsibility returns, it does not disappear.

DEEP DIVE // 10x-goal-implementEXPAND ↓
  1. 01WHY

    Execute an approved plan with nobody at the keyboard: the autonomous counterpart of /10x-implement for /goal sessions and headless runs. Trust is replaced by explicit policies, not by the agent's good will.

  2. 02BOUNDARIES BEFORE LAUNCH

    The goal condition is written down before launch: file scope, no weakening of tests, a turn limit. A no-interaction policy - nobody is watching, so every decision has a rule set in advance, and doubts are resolved by the conservative interpretation: fewer files, fewer behavior changes, closer to the letter of the plan.

  3. 03MECHANISM

    Each phase's implementation is written by a delegated subagent, but the quality gates run in the main context: plan criteria → a deliberate-break check (the test must go red on deliberately broken code - otherwise it protects nothing) → the full test suite → commits only on green, one per phase.

  4. 04DEVIATIONS

    A divergence between the plan and reality is classified: Minor (a moved file, a changed name) - adapted and reported in one line; Structural (a missing dependency, a different architecture) - a STOP block with resume instructions. When in doubt: Structural.

  5. 05CONTROL IN THE REPORTS

    The goal evaluator reads only the transcript: every gate verdict, commit SHA and adaptation must be narrated in the response - a gate that passed silently does not exist. At most 2 repair attempts per gate, then STOP; manual steps return to the human as a closing checklist.

NEXTCampaign complete · Three badges

Next: campaign complete

10XCHAMPION BLOCK // CRITERIA

The badge is closed by one of two projects - both grow straight out of this module: the observer-reviewer from lesson 03 or the encyclopedia from lesson 04.

project a
a CI/CD pipeline for code review: at least 1 job, logs, a PR with an agent comment
project b
an artifact registry: a repo/registry, a package definition, released versions
rule
1 of 2 projects is enough
proof
screenshots of the working pipeline or registry
THREE BADGES // CLOSING THE CAMPAIGN

Teamwork closes the third and final badge of the campaign. An agent that earns for the team is the finale of a road that started on the launch ramp.

10xbuilder
M1-M3: foundation, chain, scaling, quality - your own code under control
10xarchitect
M4: legacy - someone else's code without fear
10xchampion
M5: teamwork - an agent working for the team, without you
THE FULL CAMPAIGN MAP
foundation
Module 1: Foundation - from an idea to the launch ramp
csc
Core Skills Chain - five jumps of a single unit of work
scaling
Scaling - quality gates, goal, loops
quality
Module 3: Quality - risks first, not files
legacy
Module 4: Legacy - working in inherited systems
docs
Documentation - documentation of the whole campaign
TO WRAP UP:

This is the last module of the campaign - you have the full set: your own code under control, someone else's without fear, and an agent that works for the team. The best next step is to roll out one thing from here at work, still this week.