Flownix
Начать
Sections
On this page

An existing repository

The code exists, the documentation does not. How to describe what is already written and carry on from there.

The situation

The product has been in development for a year or three. The code exists, the documentation is stale or absent, and knowledge of the system lives in people's heads. A new developer — let alone an agent — spends the first days working out what is going on.

Planning new work in that state is risky: an agent that does not know the decisions already taken will propose what was rejected.

What you do

Read the assembled spec. The agent describes the system as it looks from the code — including what you consider a temporary solution you meant to replace. A gap between "as it is" and "as intended" is best closed straight away, or it sets.

Confirm the component mapping. The skill proposes links and states the ground for each; you accept or reject. It never links silently, and for good reason: a missed link is visible, a wrong one is visible to nobody and corrupts that component's progress permanently.

What the agent does

Three calls, one per step. Read the result between them rather than firing them back to back:

in the agent session, from the repository root
/flownix-init
/bootstrap-spec
/map-components

What sits behind that:

  1. /flownix-init — organization, project, the .flownix file. Answer "no" to the strict mode question: turning it on before a spec exists means hitting the gate on the very first task.
  2. /bootstrap-spec — the agent walks the repository and documentation, states what the system is, and records the result: the project spec and per-subsystem documents (create_doc_node). Not a digest of code comments — it reads the code.
  3. /map-components — create_component for each real part of the system, cross-checked against build manifests, then set_node_components over the work already accumulated. Every link is proposed with a stated ground and waits for your yes.

What comes out

A project that knows its own system: a spec, subsystem documents, a component tree with progress per component. Semantic search is populated — an agent planning a new feature finds the decisions already taken and does not propose the rejected one.

Limits

The spec will be incomplete. It is a base, not a finished artefact: the agent describes what is visible in the code and cannot guess intentions the code does not carry. It grows as you work.

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

Mapping costs your time. Confirming links is yours to do — skipping that step throws away the point of the exercise.

On a large repository, bootstrapping is not instant. The agent reads code, not an index.

Next