A workflow for project management: notes to tasks, tasks to status
This template turns meeting notes into proposed tasks, holds them for the project lead to confirm, then creates them on your board and sends a status digest. It reads and writes your tracker; it does not replace it.
Last reviewed 7 October 2026
Starting point
The status rests on the Trello board automation workflow, which finds a list, creates a card with a checklist and adds a comment, and the multi integration daily digest, which compiles GitHub, Trello and calendar data with a model summary. Both are test fixtures.
The library has a template, chatflow, MCP server or governed template that covers part of the job. You assemble the rest in Studio.
What this template does
Project work leaks at the edges of meetings. Someone says they will do something, the notes record it vaguely, and three weeks later no card exists. The project lead owns the plan and the status report, and spends time each week copying actions into the tracker and chasing for updates.
The template handles the two repeated jobs. First, it extracts action items from notes, proposes owners and dates, and flags what is unclear. Second, it reads the board, the issue list and the calendar and writes a digest. People still own the plan: nothing lands in a tracker until the lead has read the list, and owners or dates change only with a person's yes.
The workflow, step by step
Steps marked as approval gates pause the run until a named person approves. Nothing after a gate runs before that decision, and the decision is recorded.
- 01
Receive the notes
Notes arrive as pasted text, a document or an email forwarded to the flow. The run stores them with the meeting name, date and attendee list. The attendee list matters later, because owners are proposed only from it. - 02
Extract action items
An agent lists each action with a proposed owner, a proposed date and the sentence it came from. Where the notes are vague it marks the item unclear rather than filling the gap. The list goes to the project lead as a proposal. - 03
Project lead confirms the list
The Studio approval step pauses the run for the named lead, who edits owners and dates, removes items and confirms. Creating tasks notifies people, so nothing is created before this. The confirmed list is the only input to the next step.Approval gate: a named person approves before the next step runs. - 04
Create the tasks
For each confirmed item the flow creates a card or issue in the tracker, adds a checklist where the item has parts, and comments with a link to the notes. Duplicates are checked by title before creating. Task identifiers return to the run. - 05
Build the status digest
On a schedule, the flow reads open cards, issues, pull requests and the week's calendar. A code step finds overdue and unowned items. A model writes a short digest that cites each item by name, not a figure it has computed itself. - 06
Propose changes, do not make them
Where the digest suggests moving a date or reassigning work, the flow lists it as a proposal for the lead. A date or owner changes only after a person approves it. The digest goes to the team channel afterwards.Approval gate: a named person approves before the next step runs. - 07
Record
Each run keeps the notes, the proposed and confirmed lists, the task identifiers, the digest text and any approved changes with the approver and time. The next digest starts from this record, not from memory.
What it can do, cannot do, needs approval for, and records
Can
- Extract action items from meeting notes
- Create cards or issues after confirmation
- Read boards, issues and calendars
- Write a status digest that cites its items
Cannot
- Create tasks before the lead confirms
- Assign work to someone not in the attendee list
- Move deadlines or owners on its own
- Decide priorities or scope
Requires approval
- The first list of tasks from any set of notes
- Reassignments and date changes
- Closing or deleting items
Records
- Notes as received
- Proposed and confirmed lists
- Task identifiers in the tracker
- Digest text and the items it cited
- Approved changes with approver
What the library holds for this job
| Asset | Type | Covers | Role in this flow |
|---|---|---|---|
| Trello Board Automation | Workflow template | Part of the job | Finds the to-do list, creates a card, adds a checklist and a comment; the task creation step builds on it. |
| Multi Integration Daily Digest | Workflow template | Part of the job | Fetches GitHub issues and pull requests, Trello cards and calendar events, then summarises with a model; the digest step builds on it. |
| Create a To-Do List for a Project | Prompt | Used inside the flow | A starting prompt for turning a goal into tasks. |
| Create Meeting Agenda | Prompt | Used inside the flow | A starting prompt for agendas before the meeting. |
| Linear MCP | Marketplace sample listing | Sample listing, no template behind it | A sample Marketplace listing for issues, projects and cycles; no template is seeded behind it. |
Integrations this flow uses
- Trello: Board where cards and checklists are created.
- Asana: The same task creation for teams on Asana.
- Jira: Issue creation and search for engineering work.
- Slack: Where the digest is posted to the team.
The full list of tools Studio connects to is on the integrations page.
What you supply, and what this page does not cover
- You supply the tracker, the board or project to write to, and the credentials. The fixtures write to whichever board they are pointed at.
- Estimates, dependencies and critical path are not computed. The digest reports what the tools hold.
- Sensitive meetings should not be sent to a model you have not cleared for that data.
Common questions
- Does it replace a project manager?
- No. It does the copying and the weekly reading, which are the repeatable parts. The plan, the priorities, the people and the hard conversations remain with the project lead, who also confirms every first list of tasks.
- Which trackers does it work with?
- The library has fixtures for Trello, Asana and Jira, and the integration catalogue lists others. You point the flow at the tracker you use. Test one create and one read on a sandbox board before connecting a live project.
- Why not let it create tasks directly from the notes?
- Creating a task notifies someone and sets an expectation. A wrong owner or date from a vague sentence costs trust. A short review by the lead is cheap by comparison, and you can relax it once the lists come out right.
- Can the digest invent numbers?
- It is told to cite items from the tools, and a code step does any counting. A model can still misstate things, so keep the digest short, link to the source items, and read the first few before the team sees them.