Use cases

Each case is complete: what you come with, what you write, what the agent does in the project and what you end up with. And where the case doesn't fit.

1. From an idea to a task tree

Situation. You have a two-paragraph feature idea and want a plan you can start on, without breaking it down by hand.

What you write:

/plan-feature Export reports to CSV and XLSX. The user picks a period and columns,
the file is built in the background, and a notification arrives when it's ready. Limit: 100,000 rows.

What the agent does:

1. Searches the project by meaning for anything similar — whether there's already an export feature, which components are affected, which decisions were made before.
2. If something is missing, asks with a card: "Notification in the app or by email?" with answer options.
3. Shows the plan in the chat: a feature, 2–3 plans, tasks with acceptance criteria, dependencies.
4. After you say "create it", adds the feature, plans and tasks to the tree, writes the feature spec, binds everything to components and sets dependencies.
5. The "What was done" block links to everything created.

What you get. Feature AF-FEAT-31 with a task tree; every task has a description and acceptance criteria, and dependencies define the order. From here you can hand the tasks to an external agent: /execute-task AF-PLAN-40.

Where it doesn't fit. The agent can't see your code, so the "which files to touch" estimate in the tasks will be general. If precise mapping to code matters, have the external agent refine the tasks against the repository before executing them.

2. A question about the project

Situation. You're back from vacation, or you've just joined the project.

What you write:

What's in progress on billing right now and what's blocked? Why did we drop Stripe?

What the agent does: searches nodes, [decision] comments and documents by meaning, and reads the tasks it finds along with their dependencies.

What you get. A two-part answer: a list of tasks in progress and blocked — with slug chips and what blocks what; and an explanation of the decision with a link to the comment or document where it's recorded. The agent doesn't make things up: if the decision isn't recorded anywhere, it says so.

Where it doesn't fit. The agent only knows what's recorded in the project. Verbal agreements and things that live only in code are unknown to it.

3. A change through the spec

Situation. The project is in strict spec mode and you need to change behavior: the export limit grew from 100,000 to 1,000,000 rows.

What you write:

/spec-first-change The report export limit is now 1,000,000 rows instead of 100,000.

What the agent does:

1. Finds the export spec document and the requirement about the limit.
2. Prepares a spec delta: what changes and why. Validates its format.
3. Submits the delta for approval and stops: only a person can approve it.
4. Writes to you: "Delta … is awaiting approval. Tell me once it's approved and I'll create the task."
5. After you approve it in the interface and say "continue", creates a task linked to the delta. The agent applies the delta to the spec, too, only after you click "Allow" in the confirmation card.

What you get. A spec and a task that don't drift apart: the task can't be closed until the delta is applied. More on this mode: Strict mode.

4. Requirements from a file into tasks

Situation. The client sent a 15-page requirements document in Markdown.

What you do:

1. Upload tz-v3.md to Artifactory — it gets the slug AF-ARTF-14.
2. Write to the agent:

Read AF-ARTF-14 and break the "User account" section down into features and tasks. Leave the rest alone for now.

What the agent does: reads the whole file (text files up to 1 MB), picks out the section, checks it against what's already in the tree, shows a plan, and after you confirm, creates the features and tasks. Each feature's description links to AF-ARTF-14, so these features show up under "Where used" for the file in Artifactory.

Where it doesn't fit. The agent can't read requirements in PDF or DOCX — those are binary files. Save the text as .md or .txt and upload that.

5. Tracker cleanup

Situation. Over six months the tree has piled up duplicates, tasks without components and abandoned drafts.

What you write:

Find tasks without components and duplicates in epic AF-EPIC-5. Show me the list, don't change anything.

What the agent does: reads the subtree, searches for similar tasks by meaning, and shows a table: "duplicate of", "suggested component", "why".

Then you decide item by item: "Bind the components as you suggested, link duplicates 3 and 5 with a duplicates relation and mark them as cancelled." The agent does it; if you ask it to delete something, each deletion comes as a "Confirmation needed" card.

What you get. A clean subtree and agent comments on the changed tasks — you can see who changed what and why. In the action log the changes are signed "Flownix Agent".

6. Reviewing a finished task

Situation. An external agent finished AF-TASK-77 and moved it to "Testing".

What you write:

/review-work AF-TASK-77

What the agent does: reads the task, its acceptance criteria and the executor's comments ([progress], [decision], [done]), checks them against each other point by point, and checks whether the spec delta has been applied.

What you get. A verdict on each acceptance criterion in a comment on the task and a new status: "Done" if everything matches, or "Regression" with a list of what's wrong.

Where it doesn't fit. The built-in agent can't see code or run tests, so it checks only what's recorded in the task: the completeness of the executor's report and compliance with the criteria. Code review is the external agent's job: Reviews.

7. A report in Artifactory

Situation. The team needs a release summary.

What you write:

Put together a summary of the tasks closed in release 0.31: what was done, what was moved and why.
Save it to Artifactory in reports/releases/.

What the agent does: gathers the data, writes a Markdown report and saves it with a description — the file gets a slug, for example AF-ARTF-52, and can be found by semantic search. If a file with that name already exists, the agent asks whether to create a new version.

What you get. A report you can reference by slug from any task or document.

8. Build an agent council

Situation. An architectural decision is coming up, and you want several independent opinions on it.

What you write:

/harness-blueprint I need a council to choose an event store: an architect, a reliability
specialist and a skeptic, with a judge for the final verdict.

What the agent does: runs a short interview (roles, budget, when a person is needed), builds the harness and shows it.

What you get. A ready harness in the project. You start it — from the Harness screen or through an external agent with the /run-harness skill. The built-in agent doesn't start the council itself and doesn't take part in it. More: Harness.

How to phrase requests

• Name the object by slug. AF-FEAT-12 is more reliable than "that feature".
• Separate "show" from "do". "Show me the plan, don't create anything" — the agent only replies. "Create it" — the agent changes the tracker.
• Set boundaries. "Only section 3", "only in epic AF-EPIC-5" — fewer unnecessary actions and credits.
• Answer the agent's questions. The card with options isn't a formality: the agent asks where it could go wrong.