intake Documentation

From requirements in any format to verified implementation.

intake is an open-source CLI tool that transforms requirements from multiple sources and formats (Jira, Confluence, PDFs, Markdown, YAML, images, DOCX, free text) into a normalized and verifiable specification that any AI agent can consume.

intake = Chaotic Requirements (N sources, N formats) -> Executable Spec -> Any AI agent

Prerequisites

Python 3.12+
API key from an LLM provider (Anthropic, OpenAI, Google, etc.)

Installation

pip install intake-ai-cli

The CLI command is called intake:

intake --version
intake doctor

For local development:

git clone https://github.com/your-org/intake-cli.git
cd intake-cli
pip install -e ".[dev]"

Guides

Document	Description
Core:

Document	Description
Architecture	System architecture, modules, data flow and design decisions
CLI Guide	Complete reference for all 15 commands/subcommands with all their options
Configuration	All `.intake.yaml` options, presets and environment variables

Pipeline:

Document	Description
Pipeline	How the 5-phase pipeline + feedback loop works in detail
Input Formats	The 11 parsers + 3 API connectors, what they extract and how they auto-detect
Connectors	Direct API connectors: Jira, Confluence, GitHub
Plugins	Plugin system: protocols, discovery, hooks and how to create plugins
Verification	Acceptance checks engine, reporters and CI/CD
Export	6 export formats for AI agents
Feedback	Feedback loop: failure analysis and spec amendments

Operations and enterprise:

Document	Description
Deployment	Docker, pre-commit hooks and deployment patterns for teams
CI/CD Integration	GitHub Actions, GitLab CI, Jenkins, Azure DevOps
Security	Threat model, secrets management, redaction, compliance
Workflows	Patterns for teams of all sizes: individual to enterprise

Reference:

Document	Description
Best Practices	Tips, recommended patterns and how to get the most out of it
Troubleshooting	Common errors, diagnostics and FAQ

Quick Start

# 1. Verify that the environment is ready
intake doctor

# 2. Generate a spec from a Markdown file
intake init "OAuth2 authentication system" -s requirements.md

# 3. Generate from multiple sources
intake init "Payment gateway" -s jira.json -s confluence.html -s notes.md

# 4. Quick mode for simple tasks (only context.md + tasks.md)
intake init "Fix login bug" -s notes.txt --mode quick

# 5. From a URL
intake init "API review" -s https://wiki.company.com/rfc/auth

# 6. Verify the implementation against the spec
intake verify specs/payment-gateway/ -p .

# 7. Export for a specific agent
intake export specs/payment-gateway/ -f claude-code -o .
intake export specs/payment-gateway/ -f cursor -o .
intake export specs/payment-gateway/ -f copilot -o .

# 8. From direct API connectors (requires config)
intake init "Sprint tasks" -s jira://PROJ/sprint/42
intake init "RFC review" -s confluence://ENG/Architecture-RFC

# 9. Feedback loop: analyze failures and suggest fixes
intake feedback specs/payment-gateway/ -p .

# 10. Manage plugins
intake plugins list

# 11. Task tracking
intake task list specs/payment-gateway/
intake task update specs/payment-gateway/ 1 done --note "Implemented"

The 6 Spec Files

Each generated spec contains:

File	Purpose
`requirements.md`	What to build. Functional and non-functional requirements.
`design.md`	How to build it. Architecture, interfaces, technical decisions.
`tasks.md`	In what order. Atomic tasks with dependencies.
`acceptance.yaml`	How to verify. Executable checks: commands, patterns, files.
`context.md`	Project context for the agent: stack, conventions, state.
`sources.md`	Complete traceability: each requirement mapped to its original source.

Additionally, spec.lock.yaml is generated for reproducibility (source hashes, costs, timestamps).