cion-cli 0.1.0

Spec-driven development with full traceability

cion

Most spec-to-code tools generate code and documentation separately, then try to link them after the fact. cion asks the model to produce the traceability graph as it generates — every class and method comes out already tagged with the requirement that justifies it. The links are structural, not scraped. That means impact analysis and coverage are computed from data the model committed to, not from pattern-matching on what it happened to produce.

---

Install

pip install "cion-cli[anthropic]"   # Claude
pip install "cion-cli[openai]"      # GPT-4o
pip install "cion-cli[ollama]"      # local models via Ollama

---

See it in 60 seconds

$ cat requirements.txt
The system is a task management API.
Users can create tasks with a title and due date.
Tasks have a status: todo, in_progress, or done.
Users can list tasks filtered by status.
Users can delete a task by ID.

$ cion run requirements.txt
OK  Traceability graph → graph.json
✓   Written: output/task.py
✓   Written: output/task_repository.py
✓   Written: output/task_service.py
✓   Written: output/task_controller.py

Done!  Run cion coverage or cion trace to inspect the graph.

$ cion trace
Traceability Graph
├── REQ-001  Users can create tasks with a title and due date
│   ├── CLS-001  Task
│   │   └── task.py
│   └── CLS-003  TaskService
│       └── task_service.py
├── REQ-003  Tasks have a status: todo, in_progress, or done
│   └── CLS-001  Task
│       └── task.py
├── REQ-005  Users can list tasks filtered by status
│   ├── CLS-002  TaskRepository
│   │   └── task_repository.py
│   └── CLS-003  TaskService
│       └── task_service.py
└── REQ-007  Users can delete a task by ID
    ├── CLS-002  TaskRepository
    │   └── task_repository.py
    └── CLS-003  TaskService
        └── task_service.py

$ cion impact REQ-001
REQ-001  Users can create tasks with a title and due date
├── Classes (2)
│   ├── Task
│   └── TaskService
├── Methods (3)
│   ├── Task.__init__
│   ├── TaskService.create_task
│   └── TaskController.create_task_endpoint
└── Files (2)
    ├── task.py
    └── task_service.py

---

Commands

Command	What it does
cion run REQUIREMENTS_FILE	Full pipeline: parse → class diagram → code
cion trace	Requirement → class → file tree
cion coverage	Table showing which classes and files cover each requirement
cion impact REQ-ID	Everything that changes if this requirement is modified

cion run options: --provider / -p (anthropic · openai · ollama), --model / -m, --output-dir / -o, --graph / -g.

---

How it works

Three chained LLM calls with structured JSON output:

1. Parse — plain text → requirements[] with sequential IDs and priorities
2. Classes — requirements → class diagram; every class and method carries traces_to: [REQ-...]
3. Code — class diagram → Python files; each file carries traces_to (class IDs) and req_traces (requirement IDs)

The traceability graph (graph.json) is built during generation. cion trace, cion coverage, and cion impact query it directly — no heuristics, no re-parsing the generated source.