Features

Features shows what's being built: each feature with its task checklist, done criteria, decisions and milestones. It's your project's work board.

Where features come from

You rarely need to add them by hand. Features come in four ways:

• The agent records them on its own. When it starts something with several steps, it creates the feature, with done criteria, and one task per step, and checks each one off as it finishes. If the request is vague, it asks 2 or 3 quick questions first; if it's clear, it gets started right away.
• Approved plans. When you approve a plan in the agent's planning mode, it becomes a feature with a checklist.
• You ask for one. With /faundr:planning or /faundr:feature, which start with planning (see below).
• What already existed. In a project that had code before Faundr, /faundr:inventory lists what the app already does and, with your OK, records each item as done (see below).

How Faundr spots a feature

• In your request. Before the agent reads each request, Faundr checks on your computer, without AI, whether it looks like new work ("add a reports tab", "let's move to phase 2", "I want to improve the login"). If it does, it reminds the agent to record the feature and its milestones before starting. Questions, commits and one-off fixes don't get the reminder.
• At the end of the response. If the conversation changed 4 or more files and nothing was recorded, Faundr asks the agent to record what was done (once per conversation). Small tweaks don't need it.

Existing projects

When you link a project that already has code and no features, the agent offers, once, to take an inventory. If you accept, or run /faundr:inventory, it:

1. uses the code map (without reading the whole project) to list 5 to 15 things the app already does, in words a user would use;
2. shows you the list and asks what to record;
3. records the approved items as done, with the note "Already existed before Faundr", and anything half-built as in progress, with what's left.

That way the board shows the whole project, including what was built before Faundr.

Tabs

Each row shows the title, the next step ("Now: …", "Planned · after…", "Done · next milestone: …") with the owner's name at the end, the progress bar (one segment per task, white when done) and when it was last touched.

Tasks that don't belong to any feature are grouped under Tasks without a feature. The search box at the top looks through feature and task names.

Two tags keep the board from going stale:

• Stalled: the feature is in progress, but nobody has touched it in over 14 days. Hover over the tag for a tip. /faundr:resume flags stalled features too.
• Discarded: someone decided it won't get done. It drops out of the tabs and only shows under All, along with its tasks.

A feature's page

Click a feature to open its page:

• Owner: who created or started the feature (see "Feature owner" below).
• How it will work: the feature's diagram, if you asked for one (see below).
• Tasks: the checklist. Click a task's icon to change its status (to do → in progress → done), or add a task with the field at the bottom. The now tag marks the task in progress. uncommitted marks a task completed while there were changes outside git; the tag disappears on the next commit.
• Done when: the done criteria, item by item, each marked Met, Not met or Not checked yet.
• Milestones: the previous milestone ("Comes after") and the next one. Both are clickable.
• Decisions: the technical decisions made during this feature.
• Discard: takes the feature out of the tabs (it stays under All). On a discarded feature, the button becomes Restore, which brings it back. Only people who can edit the project see the button.

Tidying up the board

Over time, the board fills up with features that got finished without anyone checking them off, and milestones that are never going to happen. To clean it up, run /faundr:tidy-board (or just say "the board is out of date"). The agent:

1. checks every feature in progress and every next milestone against the commits and the code, starting with stalled and older ones;
2. sorts them into Done (with proof: the commit or the file), Discard (the plan changed, it went stale or it duplicates another one), Keep (with what's still missing) and Not sure (no proof either way, so it asks you instead of guessing);
3. shows you the proposal and asks before applying it;
4. applies only what you approve: it checks off the tasks that are already done and discards what you picked.

A feature only moves to Completed once all its tasks are done. You can undo a discard with the Restore button.

Feature owner

Every feature has an owner, so two people don't work on the same thing without knowing it:

• Whoever creates or starts a feature becomes its owner. Older features without an owner go to the first person who works on them (records a task, marks one done, checks the criteria).
• Tasks follow the feature's owner. A task handed to someone else (faundr claim) stays with them and shows "with <name>" below the title.
• Another person's agent warns before touching it. If it's about to record or check off tasks in a feature that belongs to someone else, it stops, says who owns it and only continues if the person confirms. Nobody gets locked out; it's only a warning.
• Change or release ownership: on the feature's page, the owner and the organization's admins can pick another owner or "No owner". Everyone else just sees the name. In the terminal, faundr own takes over the current feature and faundr disown leaves it without an owner.

Plan before building

When you ask for something new, the agent doesn't jump straight into code. It plans with you first (/faundr:planning, which also runs on its own when a request is new work, and inside /faundr:feature):

1. It sizes the request and tells you in one line: quick task (no questions), feature or multiple milestones. You can always say "just start".
2. It looks at the project before asking. Whatever the code, the map and the team's decisions already answer, it figures out on its own. You only answer what's your call.
3. It asks a few questions about the request: 2 to 4 per round, 3 rounds at most, each with options and a recommendation. For a payments request, for example, it asks "Pix or card?" and skips questions that already have an answer, like "who is it for?". A vague answer ("fast", "simple") gets a follow-up question with numbers or examples.
4. It asks what would make it fail: "if you only got half, what stays?" and "what would make you say it went wrong, even if it works?".
5. It shows a short summary for you to approve: what's in, what's left for later, the "done when" and the list of what it decided on its own (technical choices, or things that don't change what you see). Nothing gets built before your OK.

Once you approve, everything goes to the dashboard: the feature, its tasks, the next milestones, your choices as decisions and the "done when" as done criteria. No plan file is created in the project.

How it will work (diagram)

When a feature has a flow with several parts (screen, server, database, an outside service) or an error path that matters, the agent offers to draw how it will work. It's optional because it uses more tokens than usual. You can ask at any time: "draw how this feature will work".

As soon as the agent draws it, the canvas opens in your browser on its own and the agent waits for your response.

• Approve and build: that's your OK. The agent continues right away without asking again.
• Request changes: write what's wrong and what you want instead (optional). The agent gets it immediately, redraws and the canvas opens again.
• If you don't respond within about 9 minutes, the agent waits once more and then asks in the terminal.
• Only people who can edit the project (Owner, Admin or Member) can approve or request changes; Viewers see the status.

After that, the diagram lives on the feature's page under How it will work, with its status (waiting, approved or changes requested) and an Open canvas button. On the canvas you can zoom and drag, and clicking a piece opens its explanation. How to read the diagram:

• Lanes (the bands on the left) show who does what: the person, the screen, the server, the database, an outside service.
• The shape of a piece shows its type: a pill for the person and for the outcome (the outcome is white), cut corners for a yes-or-no question, a dashed border for an outside service, a double border for what the person sees when something goes wrong.
• The line shows the path: thick is the main path, dashed is when something goes wrong and dotted is going back to try again.

Each time the agent redraws, the version goes up and the dashboard updates instantly. When the checklist is finished, Faundr asks the agent to check each done criterion and mark whether it was met, with a note on how it checked. That way "done" means what you agreed on.

Working in milestones

For big pieces of work, the agent records the following milestones from the start, for example "Email login" → "Google login (phase 2)" → "Password recovery (phase 3)". Each milestone:

• stays in Next milestones while nothing has started on it;
• is brought up by Faundr at the start of a session, when the current checklist finishes, in the handoff note and in /faundr:resume;
• becomes the current feature once work on it starts.

Current feature

Each linked folder has a current feature: new tasks go into it, the agent receives it at the start of every session and it's what shows in the status line. It changes when a new feature is created, or with faundr focus "<name>".

Commands