← All docs

docs / workflows.md

Workflows

Features describe what the system can do. Workflows describe how those features fit together when you actually work on something.

These are the four most common end-to-end patterns. Each one describes a real coding task, what the assistant does at each step, and what you experience as the developer driving it.

Onboarding to a new codebase

You join a project. You don't know its layout, its frameworks, its conventions, or where the bodies are buried. The first session with the assistant could go one of two ways: a slow tour built from twenty file reads, or a structured one-page summary with everything you need to start contributing.

cix gives you the second one.

Adding a feature

You're asked to add functionality to an existing project. Without an index, the assistant either reinvents helpers that already exist or misplaces files in folders the team has agreed not to use.

With cix, the workflow becomes: orient → search for existing parts → reuse where appropriate → create the new pieces → enforce that they land in the right places.

Refactoring with confidence

You want to rename a function, change a signature, or move a module. The hard part isn't the change — it's finding everything that depends on the thing you're changing.

cix's impact analysis converts that anxious sweep-and-pray exercise into a structured task list. You see what depends on the target, decide deliberately, and move forward.

Pre-release cleanup

You're approaching a release. The team agreed to clean up dead code, fix naming inconsistencies, and patch any structural drift before tagging. Without an index, this is a multi-day manual review. With cix, it is a structured pass driven by orientation, audit, and impact analysis.

A real run of this workflow on a Laravel + Vue project surfaced eleven distinct issues — including a hardcoded credential in a production-served directory — in a fraction of the tool calls and tokens an indexer-free pass needed.

What these have in common

Every workflow above starts with the same step: let the assistant orient itself. A single query gives it the project's stack, structure, request surfaces, and schema overview.

Every workflow above ends with the same step: let the assistant verify, not assume. Whether that's checking convention compliance before a file write, running impact analysis before a rename, or auditing the project state before a release.

The middle is different for each. The bookends are the same.

The general shape

For any task more involved than a one-line edit, cix shifts the AI assistant's behavior from:

Read until I have enough context, then write.

to:

Query for what I need, query again to verify, then write — and only the parts that are missing.

This is the difference between an assistant that reads twenty files to make a small change and one that reads two. Multiplied across a team, across a year, the savings are not subtle.

Where to go next

For end-to-end measurement of these workflows on real projects, see the case studies.