Flownix
Начать
Sections
On this page

Plan a feature

How an intent becomes a task tree: what the agent does, what you decide, and where the line runs.

Planning is where human and agent split the work most sharply. The agent decomposes and records; you decide what to build at all and in what order. The second part cannot be delegated, and the product does not pretend otherwise.

How to start

in the agent session
/plan-feature Magic-link sign-in: an email with a link instead of a password,
the link lives 15 minutes, one link means one sign-in.

You can skip naming the skill — it is picked up from the sense of the request:

in the agent session
we need CSV export for reports, break it into tasks

Describe the outcome, not the implementation. "We need magic-link sign-in, the link lives 15 minutes" is an intent. "Create a magic_links table and a POST /auth/magic endpoint" is already a decomposition — and you have just done the part the agent does better.

What happens

Search first, create second

The agent searches by meaning, not by title: something similar may have been planned under a different name. When it finds one, it proposes extending it or adding a dependency — and records that decision in a comment.

This is how the product defends against the classic tracker disease: a second identical task nobody knew about.

Top-down decomposition

LevelWhen it is created
epiconly for a genuinely large body of work
featurea shippable capability — something you can release
planthe approach: goals, order, risks
taskone concrete unit of work, one sitting

The shallowest tree that fits is chosen. An extra level helps nobody: it adds a click and no meaning.

The spec as a separate document

Besides the tasks, the agent writes a doc node: what the product becomes once the feature ships. Not a checklist — a description of behaviour that stays useful after every task is closed.

Tasks reference it. In strict mode that reference is mandatory: it is what the close gate checks against.

Dependencies

add_dependency states "A cannot start until B is done". This is not graph decoration: the execution skill reads dependencies and will not pick up a task whose blocker is still open.

What you do

Check the decomposition. Three questions catch almost everything:

  • Is each task doable in one sitting? If not, it is a plan, not a task.
  • Does each have acceptance criteria? Without them a task is closed by feel.
  • Do dependencies reflect a real order, or just caution? A spurious dependency stalls work for nothing.

Cut scope. Agents decompose thoroughly; thorough and needed are different things. A task you have no intention of doing this quarter is clutter.

Say what the agent cannot know. Deadlines, priorities, agreements with people, the reasons behind "it is historical".

Common misses

Too fine. Fifteen ten-minute tasks are one task with a checklist inside. Splitting for the sake of splitting turns a tree into a to-do list.

Too coarse. "Do authentication" is a feature, not a task. The tell: the description does not fit into acceptance criteria.

A plan instead of an intent. If you spell out the implementation in your request, the agent will formalise your version rather than propose a better one.

Next