Export

The export phase transforms spec files into a format optimized for a specific AI agent.

intake export <SPEC_DIR> -f <format> -o <output>

Available formats

FormatStatusWhat it generatesTarget agent
architectImplementedpipeline.yaml + spec copyArchitect
genericImplementedSPEC.md + verify.sh + spec copyAny agent
claude-codeImplementedCLAUDE.md + individual tasks + verify.shClaude Code
cursorImplemented.cursor/rules/intake-spec.mdcCursor
kiroImplementedrequirements.md + design.md + tasks.md (Kiro format)Kiro
copilotImplemented.github/copilot-instructions.mdGitHub Copilot

Architect

Generates a pipeline.yaml compatible with architect and a copy of the spec files.

intake export specs/my-feature/ -f architect -o output/

Generated structure

output/
├── pipeline.yaml       # Workflow with one step per task
└── spec/               # Copy of all spec files
    ├── requirements.md
    ├── design.md
    ├── tasks.md
    ├── acceptance.yaml
    ├── context.md
    └── sources.md

pipeline.yaml

name: my-feature
description: "Pipeline generated by intake from spec 'my-feature'"
steps:
  - name: task-1
    agent: build
    prompt: |
      Implement task 1: Setup project structure

      Create the initial project structure with the following files...

      Project context:
      [first 2000 chars of context.md]
    checkpoint: true

  - name: task-2
    agent: build
    prompt: |
      Implement task 2: Implement user model
      ...
    checkpoint: true

  # ... one step per task in tasks.md ...

  - name: final-verification
    agent: review
    prompt: "Verify that the entire implementation meets the spec requirements."
    checks:
      - "python -m pytest tests/ -q"
      - "ruff check src/"
      # ... all required command checks from acceptance.yaml ...

Each step includes:

FieldDescription
nametask-{id} based on the task ID
agentbuild for tasks, review for final verification
promptTitle + description + project context
checkpointtrue — pauses after each task for review
checksOnly in the final step: list of verification commands

Options

The ArchitectExporter accepts include_guardrails (configurable via export.architect_include_guardrails).


Generic

Generates a consolidated SPEC.md, an executable verify.sh, and a copy of the spec files. Compatible with any agent or manual workflow.

intake export specs/my-feature/ -f generic -o output/

Generated structure

output/
├── SPEC.md            # Consolidated Markdown with all sections
├── verify.sh          # Executable bash script
└── spec/              # Copy of all spec files
    ├── requirements.md
    ├── design.md
    ├── tasks.md
    ├── acceptance.yaml
    ├── context.md
    └── sources.md

SPEC.md

A single Markdown file that consolidates:

  1. Project Context — content from context.md
  2. Requirements — content from requirements.md
  3. Design — content from design.md
  4. Tasks — content from tasks.md
  5. Sources — content from sources.md

Useful for pasting directly into an agent’s context.

verify.sh

Self-contained bash script that runs the command checks from acceptance.yaml:

#!/usr/bin/env bash
set -euo pipefail

PROJECT_DIR="${1:-.}"
PASS=0
FAIL=0

check() {
    local name="$1"
    local cmd="$2"
    if (cd "$PROJECT_DIR" && eval "$cmd") > /dev/null 2>&1; then
        echo "PASS: $name"
        PASS=$((PASS + 1))
    else
        echo "FAIL: $name"
        FAIL=$((FAIL + 1))
    fi
}

check "Tests pass" "python -m pytest tests/ -q"
check "Lint clean" "ruff check src/"

echo ""
echo "Passed: $PASS  Failed: $FAIL"

if [ "$FAIL" -gt 0 ]; then
    exit 1
fi

The script:

  • Accepts an optional PROJECT_DIR argument (default: .)
  • Runs each check with the check() function
  • Reports PASS/FAIL for each check
  • Shows totals at the end
  • Exit code 1 if any check failed, 0 if all passed
  • Generated with automatic chmod +x

Usage without intake

The generic exporter allows verification without having intake installed:

# In CI or on the developer's machine
./output/verify.sh /path/to/project

Claude Code

Generates a structure optimized for Claude Code: individual tasks, verification script, and a block in CLAUDE.md.

intake export specs/my-feature/ -f claude-code -o .

Generated structure

./
├── CLAUDE.md                    # Adds/updates "## intake Spec" section
└── .intake/
    ├── spec-summary.md          # Quick reference (requirements, tasks, checks)
    ├── verify.sh                # Executable script with acceptance checks
    ├── tasks/
    │   ├── TASK-001.md          # One task per file with context
    │   ├── TASK-002.md
    │   └── ...
    └── spec/                    # Copy of original spec files
        ├── requirements.md
        ├── design.md
        ├── tasks.md
        ├── acceptance.yaml
        ├── context.md
        └── sources.md

CLAUDE.md

The exporter adds (or replaces) an ## intake Spec section in the existing CLAUDE.md. If it does not exist, it creates it. It includes:

  • Spec summary (number of requirements, tasks, checks)
  • Path to the complete reference (.intake/spec-summary.md)
  • Path to the verification script (.intake/verify.sh)
  • List of individual task files

Individual tasks

Each TASK-NNN.md file contains:

  • Task title and description
  • Files to create/modify
  • Dependencies with other tasks
  • Associated acceptance checks
  • Project context summary

verify.sh

Self-contained bash script that runs the command checks from acceptance.yaml. Works the same as the Generic one but is located in .intake/.


Cursor

Generates a rules file compatible with Cursor in .mdc format (YAML frontmatter + Markdown).

intake export specs/my-feature/ -f cursor -o .

Generated structure

./
├── .cursor/
│   └── rules/
│       └── intake-spec.mdc      # Cursor rules with the complete spec
└── .intake/
    └── spec/                    # Copy of spec files

intake-spec.mdc

The .mdc file uses YAML frontmatter for Cursor metadata:

---
description: "Spec generated by intake: My Feature"
globs: "**/*"
---

# intake Specification: My Feature

## Requirements
[content from requirements.md]

## Design
[content from design.md]

## Tasks
[task summary table with status]

## Acceptance Checks
[checks formatted by type]

Kiro

Generates files in the native Kiro format with requirements, design and tasks as checkboxes.

intake export specs/my-feature/ -f kiro -o .

Generated structure

./
├── requirements.md              # Requirements with acceptance criteria as checkboxes
├── design.md                    # Design document in Kiro format
├── tasks.md                     # Tasks with verification as checkboxes
└── .intake/
    └── spec/                    # Copy of original spec files

Requirements format

Requirements are formatted with acceptance criteria as checkboxes:

## Requirements

### FR-001: User Registration
Users must be able to register with email and password.

**Acceptance Criteria:**
- [ ] Email validation works
- [ ] Password strength check enforced

Tasks format

Tasks include verification checks as checkboxes:

### Task 1: Setup project structure
Description of the task...

**Verification:**
- [ ] python -m pytest tests/ -q
- [ ] ruff check src/

Copilot

Generates instructions for GitHub Copilot in the official customization format.

intake export specs/my-feature/ -f copilot -o .

Generated structure

./
├── .github/
│   └── copilot-instructions.md  # Instructions for GitHub Copilot
└── .intake/
    └── spec/                    # Copy of spec files

copilot-instructions.md

Markdown file with structured instructions for Copilot:

  • Project context (stack, conventions)
  • Functional and non-functional requirements
  • Tasks to implement
  • Acceptance checks

This file is automatically read by GitHub Copilot when working in the repository.


Exporter Protocols

intake supports two generations of protocols for exporters:

V1 — Exporter (core)

@runtime_checkable
class Exporter(Protocol):
    def export(self, spec_dir: str, output_dir: str) -> list[str]: ...

Returns the list of generated files. Used by architect and generic.

V2 — ExporterPlugin (plugins)

@runtime_checkable
class ExporterPlugin(Protocol):
    @property
    def meta(self) -> PluginMeta: ...

    @property
    def supported_agents(self) -> list[str]: ...

    def export(self, spec_dir: str, output_dir: str) -> ExportResult: ...

Returns an ExportResult with more metadata:

@dataclass
class ExportResult:
    files_created: list[str]    # All generated files
    primary_file: str           # Main entry file
    instructions: str           # Message to the user

Used by claude-code, cursor, kiro and copilot.

Adding a new exporter

Option 1: Built-in

  1. Create a file in src/intake/export/ (e.g.: windsurf.py)
  2. Implement ExporterPlugin (V2) or Exporter (V1)
  3. Register it as an entry_point in pyproject.toml and in the manual fallback

Option 2: External plugin

  1. Create a separate Python package
  2. Implement the ExporterPlugin protocol from intake.plugins.protocols
  3. Register as an entry_point in the intake.exporters group

The exporter will be automatically discovered when the package is installed. See Plugins for details.

Note: Exporters are automatically discovered via the plugin system. The ExporterRegistry tries plugin discovery first and falls back to manual registration if it fails.


Shared helpers

The 4 new exporters (V2) share utilities from export/_helpers.py:

FunctionWhat it does
read_spec_file(path, filename)Reads a spec file (returns "" if it does not exist)
parse_tasks(tasks_content)Extracts structured tasks from tasks.md (id, title, description, status)
load_acceptance_checks(path)Loads checks from acceptance.yaml
summarize_content(content, max_lines)Truncates long content with an omitted lines indicator
count_requirements(content)Counts requirements (FR-NNN, NFR-NNN) by headings

export:
  default_format: generic                    # architect | claude-code | cursor | kiro | copilot | generic
  architect_include_guardrails: true         # Guardrails in pipeline.yaml
  architect_pipeline_template: standard      # Pipeline template
  claude_code_generate_claude_md: true       # Generate CLAUDE.md when exporting for Claude Code
  claude_code_task_dir: .intake/tasks        # Directory for task files
  cursor_rules_dir: .cursor/rules            # Directory for Cursor rules

The default format can be overridden with --format in the CLI:

# Uses the config default
intake init "My feature" -s reqs.md

# Override with a specific format
intake init "My feature" -s reqs.md -f claude-code
intake export specs/my-feature/ -f cursor -o .