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.
What Lands in Your Repo
One click exports everything as Markdown and JSON into a single folder:
10xs/ ├── PRD.md ├── README.md ├── CLAUDE.md ├── architecture/ │ └── generated/ │ ├── BLUEPRINT.json │ └── DECOMPOSITION.json ├── governance/ └── doctrine/
No vendor lock-in. Your files, your repo, your tools.
This complete system is what we call a Project OS.
One export. Everything connected. Ready to build.
What You Do Next
- 1Download the export
- 2Drop the 10xs/ folder into your repo
- 3Open it with Claude Code, Cursor, VS Code, or your preferred tools
- 4Start executing the first scoped task
Full Artifact List
Every Project OS export produces these artifacts:
| 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 |
All paths are relative to 10xs/.
Getting Started (5 Steps)
Quickstart: One prompt
Hand the exported 10xs/README.md to your AI tool and let it handle setup:
You are software architect. Read 10xs/README.md and set up this project accordingly — initialize the repo, configure the AI adapter, enrich CLAUDE.md with stack choices, triage the decomposition, and write the first microtask instruction.
The Architect will walk through all 5 steps below in a single session.
Prefer to do it manually? 5 steps▾
Step 1: Initialize your repo
Commit the export so you have a clean baseline to diff against.
Step 2: Configure your AI tool
Copy 10xs/CLAUDE.md to the config location for your tool (see table below).
Step 3: Enrich CLAUDE.md
Fill in concrete stack choices, repo conventions, and project-specific rules.
Step 4: Triage the Decomposition
Review the generated epics and stories. Flag duplicates or oversized tasks.
Step 5: Write the first instruction
Pick a microtask, create an instruction file in 10xs/workflow/instructions/.
AI tool configuration:
| Tool | Setup |
|---|---|
| Claude Code | cp 10xs/CLAUDE.md CLAUDE.md |
| Cursor | cp 10xs/CLAUDE.md .cursorrules |
| Windsurf | cp 10xs/CLAUDE.md .windsurfrules |
| GitHub Copilot | mkdir -p .github && cp 10xs/CLAUDE.md .github/copilot-instructions.md |
| Cline | cp 10xs/CLAUDE.md .clinerules |
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, validated increment. The exported standards ensure consistent quality across sessions and team members.
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.
Directory Structure
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 │ ├── 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.
Getting Started FAQ
What is a Project OS?▾
A Project OS is the complete set of requirements, architecture, and tasks generated by 10xs — structured so a team or AI coding tool can execute it. It exports as a single folder you drop into your repo.
What does it contain?▾
The export produces a 10xs/ folder. See the folder tree above for the full structure. Key files:
CLAUDE.md— AI tool adapterPRD.md— Your project requirementsREADME.md— Onboarding guideMERGE_GUIDE.md— Safe re-import instructionsVERIFICATION_CHECKLIST.md— Integrity manifestarchitecture/generated/— Blueprint, decomposition, export statusgovernance/— Quality standards and version trackingdoctrine/— Role definitions and workflow standards
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 your team works, not what you build.
Where should I place the 10xs/ folder?▾
Anywhere in your repository. The CLAUDE.md adapter uses relative paths to reference standards and architecture files.
my-project/10xs/— Repository root (recommended)my-project/governance/10xs/— Subdirectorypackages/my-app/10xs/— Monorepo
The only requirement is that 10xs/CLAUDE.md can resolve paths relative to the 10xs/ folder.
How do I get started after downloading?▾
Three steps:
- Extract the zip and place the
10xs/folder in your repo root - Copy
10xs/CLAUDE.mdto your project root — Claude Code readsCLAUDE.mdautomatically from the project root - Start a Claude Code session in your project — your AI tool picks up the project rules automatically
Claude Code reads CLAUDE.md from the project root on every session start. The adapter references standards documents inside 10xs/, so your assistant discovers and follows project rules without any manual prompting.
Export & Updates FAQ
How do exports work?▾
Each export is a point-in-time snapshot. The export engine reads your current PRD, blueprint, and execution plan, assembles your system artifacts, and generates a zip file client-side.
No data is stored server-side after generation. The zip contains only the 10xs/ folder — extract it into your repo root or any directory. No files outside 10xs/ are created or modified.
Can I re-export after making changes?▾
Yes. Incremental exports are supported.
Safe to overwrite (machine-managed)
10xs/architecture/generated/10xs/governance/10xs/CLAUDE.md,10xs/PRD.md,10xs/README.md
Never overwrite (user-managed)
10xs/workflow/— Your execution artifacts, session notes, reports10xs/architecture/local/— Your local architecture decisions
See 10xs/MERGE_GUIDE.md in your export for the complete guide.
What is a partial decomposition export?▾
When you export before fully decomposing all stories:
- Stories with microtasks — full task breakdown exported
- Stories without microtasks — exported at story level only
The EXPORT_STATUS.json file records completeness: totalStories, storiesWithMicrotasks, and exportType ("complete", "partial", or "story-level-only").
You can return to the Decompose page, generate remaining microtasks, and re-export.
System Rules & Configuration FAQ
What does the doctrine/ folder contain?▾
10xs/doctrine/ contains six standards documents that guide your AI tools:
ROLE_ARCHITECT.md— Architect role definition and authorityROLE_CODING_ASSISTANT.md— Coding assistant expectations and quality gatesTASK_WORKFLOW.md— Task decomposition and completion protocolSESSION_CONTINUITY.md— Handoff and context preservation rulesQA_VALIDATION.md— Validation and evidence requirementsCLEAN_ARCHITECTURE.md— Code quality and file size standards
These files are version-pinned. Your AI assistant reads them via the CLAUDE.md adapter.
What is the project configuration?▾
The project configuration (10xs/governance/GOVERNANCE_PROFILE.yaml) defines the rules your AI assistant follows when breaking work into microtasks:
minHours/maxHours— time budget per taskmaxFiles— maximum implementation files per taskmaxDependencies— dependency limit per taskenforcementMode—warn(advisory) orblock(hard stop)
These rules prevent scope creep and keep each task small, reviewable, and auditable.
What are execution contracts?▾
An execution contract formally binds a task to its rules before work begins. It captures the task scope, file budget, time estimate, and dependencies — then locks them with a SHA-256 hash.
When the task completes, a validation engine evaluates the work against the contract. Same inputs always produce identical outputs — no randomness.
This creates an auditable paper trail: what was planned, what was delivered, and whether the execution rules were met.
How does the validation engine work?▾
The validation engine evaluates completed work against its execution contract. It checks file counts, time spent, and rule compliance, then produces a result:
- Pass — all rules met, task can be approved
- Warn — advisory limits exceeded, review recommended
- Fail — hard limits exceeded, task cannot proceed
The enforcement mode in your project configuration controls whether violations produce warnings or hard blocks.
Can I extend or customize the system rules?▾
Yes, at two levels:
- Project configuration overrides — change
enforcementMode, file limits, or time budgets in the configuration file - Local architecture decisions — add project-specific decisions in
10xs/architecture/local/(never overwritten on re-export)
Standards documents (10xs/doctrine/) are version-pinned and updated automatically. Editing them directly is not recommended — your changes would be overwritten on the next export.
AI Tool Integration FAQ
What AI tools work with the Project OS?▾
The export includes a CLAUDE.md adapter optimized for Claude-based tools. However, the system is LLM-agnostic.
The README.md in your export includes a compatibility table for other tools (Cursor, Windsurf, Copilot, Cline) with setup instructions for each.
How do I customize the CLAUDE.md adapter?▾
The CLAUDE.md file lives at your project root (copied from 10xs/CLAUDE.md during setup). It connects your project standards to Claude Code. You can edit it to add your own rules. Common customizations:
- Project name and stack — update the header context
- Base branch — set your default branch for feature branches
- Custom rules — add project-specific coding standards
- Path overrides — adjust if you place
10xs/in a subdirectory
Keep the adapter concise (under 200 lines). It should reference standards documents, not duplicate them.
How do I prompt my AI assistant to follow the Project OS?▾
No special prompting is needed. The workflow is:
- Copy
10xs/CLAUDE.mdto your project root (Claude Code reads it automatically) - The adapter references
10xs/doctrine/— your assistant discovers your project rules on its own - Execution rules enforce file limits, time budgets, and quality gates on every task
No prompt engineering required. Claude Code loads CLAUDE.md from the project root at every session start. The system handles the rest — constraints, evidence requirements, and role definitions are all embedded in the standards that the adapter points to.
Can I use the Project OS with non-Claude tools?▾
Yes. The system is LLM-agnostic. The export includes a CLAUDE.md adapter optimized for Claude, but the standards work with any AI coding tool:
- Cursor — copy project rules to
.cursorrules - Windsurf — copy to
.windsurfrules - GitHub Copilot — reference in instructions file
- Cline — reference in configuration
See the README.md in your export for tool-specific setup instructions and the full compatibility table.
Versioning & Progress FAQ
How does kernel versioning work?▾
Every export includes 10xs/governance/KERNEL_VERSION.json with three version fields:
- Kernel version — bumped when system rules change
- Artifact schema version — bumped when schema structure changes
- Generator version — bumped when decomposition logic changes
Plus a version hash — a fingerprint of the resolved system rules. If the kernel version matches your current export, standards files are unchanged and do not need updating.
What happens during version upgrades?▾
Every export includes 10xs/governance/KERNEL_VERSION.json with a version hash — a fingerprint of the resolved rules.
When you re-export:
- Same hash — rules unchanged, standards files identical
- Different hash — rules updated, review
MERGE_GUIDE.mdfor safe overwrite paths
Your work artifacts (10xs/workflow/) and local decisions (10xs/architecture/local/) are never overwritten regardless of version changes.
How do I track execution progress?▾
The 10xs/workflow/ directory is your project's work history. It is user-managed and never overwritten on re-export:
workflow/session_handoffs/— context for each work sessionworkflow/task_reports/— completion reports with evidenceworkflow/execution_contracts/— formal task bindings
This gives you a complete audit trail of what was planned, delivered, and validated — entirely within your repository.