Example: What You Actually Get
Starting from a one-line brief:
Requirements (PRD)
- •Features: lead management, pipelines, follow-up automation
- •Roles: sales rep, manager
- •Constraints: web app, multi-tenant, role-based access
Architecture (Blueprint)
- •Next.js frontend
- •API / backend service
- •PostgreSQL database
- •Authentication + RBAC
- •Email automation integration
Execution Plan (Microtasks)
- •Set up repo and conventions
- •Implement auth
- •Build lead CRUD
- •Add pipeline UI
- •Add follow-up workflow
Each artifact feeds the next. Requirements drive architecture. Architecture drives tasks.
One Connected System
These pieces don't live as separate files you keep in sync by hand — they're one governed state on your board, and your agent reads all of it live through Connect.
No vendor lock-in either way: if you ever want your own copy, export is still there as a fallback.
This connected system is what we call a Project OS.
One board. Everything connected. Ready to direct.
What You Do Next
- 1Click Connect on your board
- 2Paste the generated MCP config into your tool
- 3Your agent reads the board live — PRD, plan, and governance rules
- 4Direct the first task, and watch it move on the board
Full Artifact List
The Project OS is built from these pieces — the same ones your agent reads live through Connect:
| Artifact | Path | Purpose |
|---|---|---|
| PRD | PRD.md | Product requirements — the "what" and "why" |
| Blueprint | architecture/generated/BLUEPRINT.json | Technical architecture — the "how" |
| Decomposition | architecture/generated/DECOMPOSITION.json | Epics → Stories → Microtasks — the "work plan" |
| Project Model | architecture/generated/PROJECT_MODEL.json | Domain classification and execution profile |
| Standards | doctrine/ | Role definitions, workflow, quality standards |
Paths shown relative to 10xs/ — the same layout you'd get if you took the export fallback.
Getting Started
Connect your agent
Open your board, click Connect, and copy the generated MCP config into your tool. Claude Code, Cursor, Windsurf — any MCP-compatible tool reads the same config.
# Paste the config Connect gives you into your tool's # MCP settings. Your agent connects and reads the board # live — PRD, plan, governance rules, board truth — all # current, nothing to copy or keep in sync by hand.
No folder to place, no per-tool config to hand-write.
Prefer files? Export instead▾
Export is the fallback for people who want their own copy of the files instead of a live connection.
Step 1: Export your current state
One click assembles a zip of your PRD, plan, and governance rules — a snapshot, not the live board.
Step 2: Drop it into your repo
Unzip 10xs/ into your repo root.
Step 3: Point your tool at the files
Most AI coding tools can read a folder of Markdown and JSON directly — check your tool's docs for how it ingests project context.
Development Loop
Architect writes instruction
↓
Coding Assistant executes microtask
↓
Coding Assistant submits completion report
↓
PM / Architect reviews report
↓
Next microtask assignedEach cycle produces a tested, reviewed increment. The governance rules living in your Project OS keep quality consistent across sessions and team members — nothing lands unchecked.
Starting a Session
As Architect:
You are software architect. Review current state and recommend the next task.
As Coding Assistant:
You are coding assistant. Your task: [path to microtask instruction file] Strict adherence to coding standards. Provide completion report.
Inside the Export
You don't need this to get started — your agent reads the board live through Connect. If you take the export fallback anyway, here's the exact layout you get:
Export Structure
10xs/ ├── CLAUDE.md — AI tool adapter ├── PRD.md — Project requirements ├── README.md — Onboarding guide ├── MERGE_GUIDE.md — Re-import instructions ├── VERIFICATION_CHECKLIST.md — Integrity manifest ├── architecture/ │ ├── generated/ — Blueprint, decomposition, status │ │ ├── BLUEPRINT.json │ │ ├── DECOMPOSITION.json — When execution plan exists │ │ └── EXPORT_STATUS.json — Completeness metadata │ └── local/ — Your architecture decisions ├── governance/ — Version tracking, schemas │ ├── GOVERNANCE_PROFILE.yaml │ ├── KERNEL_VERSION.json │ └── SCHEMAS/ │ ├── execution_contract_schema.json │ └── reporting_schema.json ├── doctrine/ — Role definitions, workflow, quality standards │ ├── 00_UNIVERSAL_PRINCIPLES.md │ ├── ROLE_PROJECT_MANAGER.md │ ├── ROLE_ARCHITECT.md │ ├── ROLE_CODING_ASSISTANT.md │ ├── TASK_WORKFLOW.md │ ├── SESSION_CONTINUITY.md │ ├── QA_VALIDATION.md │ └── CLEAN_ARCHITECTURE.md └── workflow/ — Your execution artifacts
Key Concepts
Decomposition is a skeleton, not a plan
The AI-generated decomposition gives you structure — epics, stories, microtask outlines — but each microtask needs a human-reviewed instruction file before execution.
One instruction at a time
Each coding session focuses on a single microtask instruction file. The instruction defines scope (max 5 files), success criteria, and expected evidence.
Evidence-based quality
Every microtask produces a completion report with test results, screenshots, and build verification. Reports that claim success without evidence are rejected.
What the Project OS is
What is the Project OS?▾
The Project OS is the governed state of your project — your PRD, your plan, board truth (what's moving, what's waiting on review, what's done), and the rules your agents follow while they work. It lives on the board and stays current; there's no separate copy to keep in sync.
Your agent reads it live, through Connect. If you'd rather have the files themselves, export is still there as a fallback.
What's actually in it?▾
The governed state your agents read from is made up of:
- Your PRD — the requirements, as they stand right now
- Your plan — the execution plan and the tasks it breaks into
- Board truth — what's moving, what's waiting on review, what's done
- Governance rules — the standards your agents follow: roles, task sizing, review gates
- The decision trail — what was planned, what shipped, and why
None of it is a snapshot. It's the same state your agent reads the moment it connects.
What does it NOT contain?▾
The Project OS does not contain:
- Source code, application code, or generated code
- Dependencies, packages, or lock files
- Infrastructure configuration (Terraform, Docker, CI/CD)
- Secrets, credentials, or environment variables
- Third-party libraries or frameworks
It structures how the work gets directed — not what gets built.
What are the governance rules, exactly?▾
The governance rules are the standards your agents follow whenever they pick up work. They cover:
- Role definitions and authority — who (or what) decides what
- Task workflow — how work gets broken down and handed off
- Session continuity — how context survives between sessions
- Review and evidence requirements — what "checked before it counts" means in practice
- Code and quality standards
They're version-pinned, and your agent reads them through Connect — not a file you hand-configure.
What's actually configurable in the governance rules?▾
A handful of tunables control how work gets sized and reviewed:
minHours/maxHours— time budget per taskmaxFiles— the maximum files a single task can touchmaxDependencies— dependency limit per taskenforcementMode—warn(advisory) orblock(hard stop)
These are what keep each piece of work small, reviewable, and auditable — not a leap of faith.
How your agent reads it
How do I get my agent reading the board?▾
Three steps:
- Open the board and click Connect
- Copy the MCP host config it gives you into your AI tool
- Start a session — your agent reads the live board from there
No files to place, no folder to copy, nothing to keep in sync by hand. Your agent picks up your PRD, plan, and governance rules the moment it connects — and again every time the board changes.
Can I customize what my agent reads?▾
Yes. The governance rules that ship by default cover most projects, but you can adjust them from the board:
- Project context — name, stack, the basics your agent needs up front
- Base branch — your default branch for feature work
- Custom rules — project-specific standards on top of the defaults
Changes take effect immediately — your agent reads the updated rules live, the next time it connects. There's no separate adapter file to keep current.
Does this work with tools other than Claude?▾
Yes. Connect hands you a standard MCP host config — any MCP-compatible AI tool can read the board through it, not just Claude-based ones.
If your tool doesn't speak MCP yet, export still gives you a compatibility path: a fallback you can point older or file-based integrations at.
What stays yours
What's an execution contract?▾
Before an agent starts a task, an execution contract binds it to the rules: scope, file budget, time estimate, dependencies — locked in before work begins.
When the task finishes, that work is checked against the contract it started with. Same inputs, same rules, same result every time — no randomness.
It's what makes handing work off auditable: what was planned, what was delivered, and whether the rules were met.
What happens when a task is checked?▾
Completed work is evaluated against its execution contract — file counts, time spent, rule compliance — and lands in one of three states:
- Pass — every rule met, ready to be approved
- Warn — an advisory limit was exceeded, worth a look
- Fail — a hard limit was exceeded, the task can't proceed
Nothing lands unchecked. The enforcement mode in your governance rules decides whether a violation is a warning or a hard stop.
Can I change how strict the rules are?▾
Yes, at two levels:
- Governance overrides — adjust enforcement mode, file limits, or time budgets for your project
- Local decisions — record project-specific calls that sit alongside the default rules, without editing them directly
The default rules stay version-pinned and update on their own. You're always the one deciding how tight the leash is — that decision doesn't get automated away.
Where's the record of what actually happened?▾
The board keeps a running history of your project's work: session context, completion reports with evidence, and the execution contracts each task was bound to.
It's a complete audit trail — what was planned, what was delivered, what was checked — and it's yours to read at any point, not something you have to reconstruct from files after the fact.
Getting your files out
How does export actually work?▾
Export is the fallback, not the main event — for when you want your own copy of the files. Pick export, and your browser assembles a zip client-side from your current PRD, plan, and governance rules.
Nothing is stored server-side after it downloads. The board stays the live copy; the zip is just a picture of it at that moment.
Do I need to export anything to get started?▾
No. Your agent reads the board live through Connect — nothing to place, copy, or keep in sync by hand.
Export is there for when you want your own copy: no lock-in, take what you have and go.