Measure twice,
code once.

Getting Started

Install Draft as a Claude Code plugin and initialize your project in under a minute. Also available for Cursor, GitHub Copilot, and Gemini.

# Install the plugin
/plugin marketplace add mayurpise/draft
/plugin install draft

# Initialize your project (once)
/draft:init

# Create a feature track
/draft:new-track "Add user authentication"

# Start implementing
/draft:implement

# Verify test coverage (95%+ target)
/draft:coverage

# Validate quality (architecture, security, performance)
/draft:validate

# Check progress
/draft:status

Prerequisites: Claude Code CLI, Git, and Node.js 18+.

Other Editors

Cursor — One command, no clone required:

curl -o .cursorrules https://raw.githubusercontent.com/mayurpise/draft/main/integrations/cursor/.cursorrules

GitHub Copilot — One command, no clone required:

mkdir -p .github && curl -o .github/copilot-instructions.md https://raw.githubusercontent.com/mayurpise/draft/main/integrations/copilot/.github/copilot-instructions.md

Gemini — One command, no clone required:

curl -o GEMINI.md https://raw.githubusercontent.com/mayurpise/draft/main/integrations/gemini/GEMINI.md

Command Reference

Draft provides 12 slash commands for the full development lifecycle.

The Core Problem

AI coding assistants are powerful but undirected. Without structure, they make assumptions, choose arbitrary approaches, and produce code that doesn't fit your codebase.

Problems with Chat-Driven Development

Traditional AI chat interfaces have fundamental limitations that get worse over time.

How Draft Solves This

The Draft Workflow

Draft solves this through Context-Driven Development: structured documents that constrain and guide AI behavior. By treating context as a managed artifact alongside code, your repository becomes the single source of truth.

Step 1: Context — Why it exists

Without context, AI reinvents your project from scratch every session. It guesses your tech stack, ignores your conventions, and builds features that don't fit. /draft:init fixes this by creating persistent files that tell the AI who your users are (product.md), what technologies to use (tech-stack.md), and how your team works (workflow.md). For existing codebases, it also generates architecture.md — a deep system map with mermaid diagrams covering directory structure, entry points, data flows, design patterns, existing module dependencies, and external integrations. This means every future track gets immediate, rich context without re-analyzing the codebase. These files live in git, survive across sessions, and load automatically — so the AI always starts with your ground truth instead of assumptions.

Step 2: Spec & Plan — Why it exists

When you ask AI to "add authentication," it immediately writes code. If the approach is wrong, you discover it during code review — after hours of work. /draft:new-track forces the AI to write a specification and phased plan before touching code. You review the approach in a quick spec PR, not a massive code PR. Disagreements get resolved in a 5-minute document edit instead of a multi-hour rewrite. The plan breaks work into phases with verification steps, so the AI tackles one thing at a time instead of attempting everything at once.

Step 3: Decompose — Why it exists (optional)

For multi-module features, jumping straight to implementation creates tangled code with unclear boundaries. /draft:decompose maps your feature into discrete modules with defined responsibilities, API surfaces, and a dependency graph. This gives you an implementation order (build the database layer before the API layer) and prevents circular dependencies. Each module is small enough to reason about, test independently, and review in isolation.

Step 4: Implement — Why it exists

Even with a plan, AI can drift: skip tests, claim completion without proof, or make sweeping changes across unrelated files. /draft:implement executes one task at a time from the plan, follows the TDD cycle (write test first, then code, then refactor), runs a verification gate before marking anything complete, and triggers a two-stage review at phase boundaries. The AI can only work on what's specified, in the order specified, with proof required at every step.

Step 5: Verify Quality — Why it exists

Passing tests doesn't guarantee good code. AI can violate architectural patterns, introduce security vulnerabilities, or create performance bottlenecks — all while every test passes. /draft:coverage measures test completeness (95%+ target) and classifies uncovered lines. /draft:validate runs context-aware quality checks: architecture conformance (patterns from architecture.md), security scans (hardcoded secrets, SQL injection, XSS), performance anti-patterns (N+1 queries, blocking I/O), and regression risk (blast radius of changes). Both generate reports with file:line references and actionable remediation. Auto-runs at track completion when enabled in workflow.md — non-blocking by default to maintain velocity while surfacing issues.

The Constraint Hierarchy

Each document layer narrows the solution space. By the time AI writes code, most decisions are already made.

Review Before Code

This is Draft's most important feature. In traditional AI coding, you discover the AI's design decisions during code review — after it's already built the wrong thing. With Draft, the AI writes a spec first. You review the approach in a document, not a diff. Disagreements are resolved by editing a paragraph, not rewriting a module.

Practical impact: Faster reviews (approve approach, not implementation details). Fewer rewrites (catch design issues before code exists). Knowledge transfer (specs document why, not just what). Onboarding (new team members read specs to understand features).

Team Workflow: Alignment Before Code

Draft's most powerful application is team-wide: every markdown file goes through commit → review → update → merge before a single line of code is written. By the time implementation starts, the entire team has already agreed on what to build, how to build it, and in what order.

The PR cycle on documents, not code

Why this changes how teams work

Project Structure

Draft uses a set of markdown files to capture project context, specifications, and implementation plans. Each file has a specific purpose.

draft/
├── product.md          # Product vision and goals
├── tech-stack.md       # Technical choices
├── architecture.md     # System map + mermaid diagrams (brownfield)
├── workflow.md         # TDD, commit, validation, architecture mode
├── validation-report.md # Project-level quality checks (generated)
├── jira.md             # Jira project config (optional)
├── tracks.md           # Master track list
└── tracks/
    └── <track-id>/
        ├── spec.md      # Requirements
        ├── plan.md      # Phased task breakdown
        ├── architecture.md # Track modules (optional)
        ├── metadata.json
        ├── validation-report.md # Quality checks (generated)
        └── jira-export.md # Jira stories (optional)

Status Markers

Simple markers track progress throughout specs and plans. Progress is explicit, not assumed.

Jira Integration

Sync tracks to Jira with a two-step workflow. Preview before pushing to catch issues early.

Auto Story Points

Story points are calculated from task count:

TDD Workflow

AI-generated code without tests is a liability — it works until it doesn't, and you have no safety net. When TDD is enabled in workflow.md, Draft forces the AI to prove its code works at every step.

Why this matters for engineers: Every completed task has a test proving it works. You can refactor with confidence, onboard new team members who read tests as documentation, and revert individual tasks without collateral damage. The AI can't claim "it should work" — it has to show evidence.

Architecture Discovery

For brownfield projects, /draft:init doesn't just detect your tech stack — it performs a deep three-phase codebase analysis that generates architecture.md. This document becomes the persistent context every future track references, so the AI never has to re-analyze your codebase from scratch.

Why this exists

Without architecture discovery, every new track starts cold. The AI explores your codebase, builds a mental model, and starts working — then loses that understanding when the session ends. The next track starts the same exploration over again. Architecture discovery pays the analysis cost once during init, then every track, every question, and every implementation gets immediate, rich context about how your system actually works.

Phase 1: Orientation (The System Map)

Scans the codebase to produce a high-level system map with mermaid diagrams.

Phase 2: Logic (The "How" & "Why")

Examines specific files and functions to understand business logic, data flows, and patterns.

Phase 3: Module Discovery (Existing Modules)

Reverse-engineers the existing module structure from import graphs and directory boundaries. This is discovering what already exists — not planning new modules (that's /draft:decompose).

Refresh Mode

/draft:init refresh re-scans the codebase and diffs against the existing architecture.md. It detects new directories, removed components, changed integration points, new domain objects, and new or merged modules — then updates all mermaid diagrams and module documentation to reflect the current state. Changes are presented for review before writing.

Architecture Mode

Standard Draft gives you specs and plans. Architecture Mode goes deeper — it forces the AI to design before it codes. Every module gets a dependency analysis. Every algorithm gets documented in plain language. Every function signature gets approved before implementation begins. This is how you build complex features without the AI creating a tangled mess.

Why Architecture Mode exists

When AI builds a multi-module feature, it makes ad-hoc decisions about module boundaries, function signatures, and data flow. These decisions compound — a bad interface choice in module A cascades through modules B, C, and D. By the time you notice, the entire implementation needs restructuring. Architecture Mode front-loads these decisions into reviewable checkpoints where changes cost minutes instead of hours.

How each checkpoint helps engineers

Implementation Flow

The decomposition process

Before Architecture Mode's checkpoints activate, /draft:decompose maps your feature into modules. Here's what happens concretely:

Revert Workflow

AI makes mistakes. When it does, you need to undo cleanly — not just git reset --hard and lose everything. Draft's revert understands the logical structure of your work. It knows which commits belong to which task, which tasks belong to which phase, and it updates both git history and Draft's tracking state together. You pick the granularity, review what will change, and confirm before anything happens.

Quality Disciplines

AI's default failure mode is to guess at fixes, skip verification, and claim success. Draft embeds three quality agents directly into the workflow — they activate automatically at the right moments and enforce disciplined engineering practices.

Systematic Debugging

The problem: When AI hits an error, it tries random changes hoping something sticks. Each "fix" often introduces new bugs. The solution: When a task is blocked ([!]), the Debugger Agent enforces a four-phase process that mirrors how senior engineers actually debug — understand first, then fix.

Why this matters: After 3 failed hypothesis cycles, the agent escalates to you with everything it has learned and eliminated — no more silent spirals of random attempts. Root cause is documented in plan.md, so the team learns from every bug.

Two-Stage Review

The problem: AI happily moves on to the next phase even if it missed requirements or wrote poor code. The solution: At every phase boundary, the Reviewer Agent runs two sequential checks. Stage 1 catches what's missing. Stage 2 catches what's messy. Only when both pass does the work proceed.

Why this matters: Critical issues (broken functionality, security vulnerabilities) must be fixed before proceeding — no exceptions. Important issues should be fixed. Minor issues are noted but don't block. This prevents both perfectionism paralysis and quality erosion.

Code Coverage

The problem: TDD ensures you write tests, but doesn't guarantee those tests are comprehensive. You can have 100% of your tests passing while 40% of your code is untested. The solution: /draft:coverage runs your project's coverage tool and classifies every uncovered line, so you know exactly what's tested, what's not, and whether that matters.

Systematic Validation

The problem: AI can pass all tests while violating architectural patterns, introducing security vulnerabilities, or creating performance bottlenecks. Tests measure "does it work" but not "is it good." The solution: /draft:validate uses Draft context (architecture.md, tech-stack.md) to catch quality issues tests miss — architecture violations, hardcoded secrets, N+1 queries, missing input validation, and more.

Why this matters: Validation runs automatically at track completion (configurable in workflow.md). Non-blocking by default — issues documented in validation-report.md with file:line references and remediation guidance. Complements coverage (quantitative test metrics) with qualitative codebase health checks.

The Economics

Writing specs feels slower. It isn't. The overhead is constant (~20% for simple tasks), but savings scale with complexity, team size, and criticality.

For critical product development, Draft isn't overhead — it's risk mitigation.

Core Principles

When to Use Draft

Good fit

Overkill

One-line bug fixes, typo corrections, exploratory prototypes you'll throw away, simple config changes.

Constraint Mechanisms

How Draft keeps AI focused and accountable: