You already have a repository

The product does not require starting from zero. If the code exists and the documentation does not — or is stale — the order is different: describe what is there first, plan new work second.

Step 1. Connect and create the project

/flownix-init

Answer "yes" to the question about bootstrapping a spec — that is the next step.

Step 2. Bootstrap the spec from the code

/bootstrap-spec

The agent walks the repository and the documentation, works out what the system is, and records it in the project: the product spec and documents per subsystem. This is not generation from code comments — it reads the code and states what it does.

Why before planning: without a spec, an agent planning a new feature does not know the decisions already taken and will propose what you rejected a year ago.

Step 3. Map the system into components

/map-components

A component is a part of the system: a service, an app, a library, infrastructure. The agent walks the repository, cross-checks directories against the build manifests, and creates one component per real part.

From then on work is linked to components, and "how is the gateway doing" is answered by one query rather than by counting tasks by hand.

Step 4. Carry on as usual

From here the work is no different from a new project: planning and execution. The difference is that the agent now searches accumulated context and knows what has already been decided.

What to expect

The spec will be incomplete. That is fine: it is a base, not a finished artefact. It grows as you work — the update-knowledge skill keeps it current.

Some historical tasks will stay without components. Backfilling is only reliable where there is something to hold on to: a path in the task text, a commit, a review branch. The rest is better left unlinked than linked on a guess.

Next

• Use case: an existing repository
• Skills reference