Most of a backlog is decided in meetings. Someone says "the export times out for big customers", someone else says "and the invoice page should show credit notes", and both end up in a notes document that nobody opens again. A week later the follow-up is a memory, and the backlog is whatever someone had the energy to type into the tracker.
We built two steps in CodeLynq for that gap: turning notes into tasks, and grooming the backlog those tasks land in. Both propose. A person decides.
Getting the notes in
There are two ways in. You paste raw meeting notes into a project, or you import a meeting from Fireflies. An organization connects Fireflies once with an API key; after that, anyone in a project can pick a recent meeting from a list and choose what to import: the Fireflies summary with its action items, the full speaker-attributed transcript, or "auto", which takes the summary when there is one and the transcript otherwise.
Plaud is not there yet, and we would rather say so here than let you find out in settings. Plaud's only programmatic access today is an MCP server that runs in your own client, which our backend cannot call, so the Plaud card in the app says it is coming. Until that changes, paste the Plaud notes like any other notes. Imports are also a choice you make per meeting: nothing is pulled in on a schedule.
From notes to tasks
The model reads the meeting title and the text and returns only technical work. Each task gets a title, a description, a type (feature, bugfix, refactor or chore) and a priority. "Schedule a follow-up" and "send the client an email" are left out on purpose: a backlog full of calendar reminders is not a backlog.
Every extracted task is created as a draft and stays linked to the meeting note it came from, so six weeks later you can still see which conversation a task started in. Nothing runs. A draft task has no spec yet, and no code is written until a spec is approved.
What extraction does not do is worth knowing. It reads the notes, not your code, so "fix the export" becomes a task with a sensible description and no idea where the export lives. It does not check your existing backlog for duplicates, so the third meeting about the same bug produces the third task about it. And if the model call fails, the note is saved with no tasks. We record the failure on our side, but on your screen it looks like a meeting with nothing in it. If a meeting clearly had work in it and the list is empty, try again.
Grooming: a proposal, not a decision
Once the tasks are in, a project admin can groom the backlog. CodeLynq takes every open task in the project (not archived, not done, not failed) together with what the project knows about itself: its tech stack, architecture principles, coding conventions, domain knowledge and constraints. The model is asked to act as an engineering lead and return, for each task:
- A priority: low, medium, high or critical.
- An estimate: S, M, L or XL.
- A reason: one sentence explaining the estimate.
- A rank: a place in one ordering of the whole backlog, 1 first, weighing dependencies, urgency and value.
Nothing is saved at that point. You get a table with each task, what it was before ("was medium/M") and what is proposed, and you can change any priority, estimate or rank before you apply it, or discard the whole proposal. Applying checks every value against the allowed set and writes an audit entry, so you can see later who accepted a ranking and when. Estimates and ranks stay editable on the task afterwards, by hand.
We made grooming a proposal for the same reason we do not let the AI merge. A ranking is a judgement about your business: which customer is waiting, which deadline is real, which "critical" was said in frustration. The model sees text. It is good at noticing that task seven depends on task two and that a one-line copy change is not an L. It cannot know that the board meeting is on Thursday.
What the estimate is for
The reasoning sentence is there so you can disagree with it quickly. "M: touches the export endpoint and the background job" tells you what the model assumed. If you know the export was rewritten last month, you change it to S and move on.
The estimate also does work later. When a task runs, its size is one of the inputs that decides which model builds it, as we described in what an AI development run actually costs. A wrong XL on a small chore means paying for a stronger model than it needed, which is another reason the estimate is yours to correct.
The honest limit: grooming reads task text and project context, not the repository. An S on a task that touches the one module everybody is afraid of is a guess from the description. The size that holds up comes later, when the spec is drafted against the code and names the files it will change.
The practical version
Treat the meeting as the input and review twice: once when the tasks come out of the notes (delete what is not work, and the duplicates), and once when the grooming proposal comes back (fix the ranks you know better). Neither review takes long, because you are correcting a draft instead of writing one. Then each task goes through a spec before any code is written, which is where spec-driven development starts. If your meetings are recorded, the Fireflies integration is the shortest way to try it.