Project Initialization
telesis init is the entry point for all projects. It auto-detects the project state and
applies the appropriate onboarding mode:
| Mode | Detected when | What happens |
|---|---|---|
| Greenfield | No .telesis/, no docs | AI interview + doc generation |
| Existing project | Docs exist, no .telesis/ | Ingest docs, create config, scaffold |
| Migration | .telesis/ exists | Retrofit missing scaffold artifacts |
Just run telesis init — you don’t need to specify which mode. Telesis inspects your
project and does the right thing.
Options
| Flag | Description |
|---|---|
--docs <path> | Custom docs directory (default: docs/) |
Greenfield Mode
When no project documents or telesis config exist, telesis init runs a full AI-powered
interview.
| |
Telesis opens a multi-turn conversation with Claude. It asks about your project’s purpose, audience, technology, constraints, and goals. Answer naturally — it’s a conversation, not a form. The more context you provide, the better the generated documents will be.
A typical interview takes 5–10 turns. Telesis monitors the conversation and wraps up when it has enough information. You can also end the interview early with Ctrl+C; your progress is saved automatically.
Resuming an Interrupted Interview
If you stop mid-interview (intentionally or due to a crash), run telesis init again. Telesis detects the saved interview state in .telesis/interview-state.json and resumes where you left off. No context is lost.
What the Interview Asks About
The interview adapts to your answers, but it generally covers:
- Project identity — name, owner, primary language, repository URL
- Purpose — what the project does and why it exists
- Users — who uses it and what their needs are
- Architecture — how the system is structured, key components, data flows
- Constraints — technology choices, performance requirements, compliance needs
- Development practices — testing strategy, deployment model, team conventions
- Roadmap — what’s been built, what’s next, what “done” looks like
Existing Project Mode
When telesis init finds documentation files (PRD.md, ARCHITECTURE.md, VISION.md, or
MILESTONES.md) but no .telesis/config.yml, it skips the interview and ingests what exists:
- Creates
.telesis/config.ymlwith project metadata derived from your project - Scaffolds standard directories (
docs/adr/,docs/tdd/,docs/context/) - Generates
CLAUDE.mdfrom existing docs - Reports which docs are present and which are missing
Use --docs if your documentation lives outside the default docs/ directory:
| |
Migration Mode
When .telesis/config.yml already exists (from an older telesis version), init retrofits
any missing scaffold artifacts — skills, hooks, MCP config — without touching your existing
docs or config. This is idempotent: running it on an up-to-date project is a no-op.
Note:
telesis upgradewas removed in v0.31.0. Usetelesis initinstead — it detects migration mode automatically.
Provider Adapter Installation
All modes install a provider-appropriate enforcement adapter:
- Claude Code detected (
.claude/directory exists): installs skills, Claude Code hooks, and MCP config - Generic: installs git pre-commit hook via
telesis hooks install
Generated Documents
After the interview, Telesis generates four documents in docs/:
VISION.md
The foundational “what and why.” This document captures your project’s purpose, design principles, and the mental model behind it. It’s the document you’d hand to someone who asks “what are you building and why?”
VISION.md changes rarely. When it does, it signals a fundamental shift in the project’s direction.
PRD.md
Product requirements. This includes user journeys, functional requirements, implicit requirements (things that must be true but are easy to forget), and — for CLI projects — command documentation.
The PRD grows as features are added. It’s the reference for “what does this project need to do?”
ARCHITECTURE.md
System design. This covers the repository structure, key modules, data flows, dependencies, and architectural constraints. It’s the reference for “how is this built?”
ARCHITECTURE.md is updated whenever the system structure changes — new modules, new data flows, new dependencies.
MILESTONES.md
The development roadmap. Each milestone has a clear goal, a status, and explicit acceptance criteria. Milestones are not vague aspirations; they define what “done” looks like for each phase.
Project Configuration
Telesis also creates .telesis/config.yml with your project metadata:
| |
This configuration is extended later as you enable features like custom review personas, dispatch agents, and pipeline behavior. See the Configuration Reference for all options.
Context Generation
Finally, Telesis generates CLAUDE.md at the project root. This file aggregates context from all project documents into a single file optimized for AI assistant consumption. It’s what keeps Claude Code, Cursor, and similar tools aligned with your project’s intent. See Context Generation for details.
Post-Initialization
After initialization, your project has:
| |
From here, you might:
- Edit the generated documents. They’re yours. Fix anything the interview got wrong. Add context it missed. The documents are the source of truth, and Telesis respects your edits.
- Run
telesis statusto see a summary of your project state. - Run
telesis evalto check the quality of the generated documents. - Run
telesis reviewto review staged code changes against your new spec. - Start a milestone by writing code and using
telesis driftto stay aligned.
Document Evaluation
Telesis can evaluate the quality of your generated documents:
| |
This runs a battery of evaluators that check structural completeness, specificity (are statements concrete or vague?), actionability (can a developer act on this?), coverage (are all expected sections present?), and internal consistency. The output tells you where to focus your editing effort.
For machine-readable output:
| |