Tasks that come out of what you wrote.

Where tasks come from

There are four origins, and all of them leave a trail: every task knows which note, which meeting or which conversation it came from, and the Source button takes you there.

How detection works

While you write the daily note, the AI does three different things at once, and they are worth keeping apart.

• It detects knowledge entities — people, organizations and projects. Every mention links to its Atlas entry, and if the entity did not exist, creating it is proposed.
• It flags task segments — the stretches of text that look like a commitment. The flag lives on top of your text without changing it: what you wrote is never rewritten.
• It scores how clear the action is — read on its own, outside the note, a week from now. If there is no telling what it is about, the task is flagged vague, and very vague when on top of that it hangs off no person and no project; that amber flag follows it all the way to Tasks. The three levels of clarity and the full table are in the vagueness score.

The flag is reversible: the crossed-out eye dismisses it before the close, without touching your text (more in The daily note). The same dismissal is in chat, as a button on the bot's reply, and in Tasks, by right-clicking the provisional task → Discard.

Closing the day: when everything becomes real

Closing the day is the gesture that turns proposals into objects: every segment you did not dismiss is created as a task, with its date and its people, and lands in the planner. Today you close yourself, on the review screen explained in The daily note; past days left open close on their own — it comes switched on, and you turn it off per workspace in Settings.

Until it closes, those tasks half-exist, and it shows: in Tasks they appear as provisional, with an orange ghost and the days they have left. Tapping one takes you to the note it came from, and right-clicking lets you mark it done, give it a project, assign it to someone or discard it. What you cannot do is change its status or open it in the editor: it is not a row yet, it is a proposal.

What a task holds, and who fills it in

A task is born with the minimum: a title and, if the text said so, a date and the people it mentioned. Everything else gets added when it is needed, and none of it is required — a task with no owner, no date range and no project is a task all the same.

When the owner is not declared but the task hangs off exactly one person, the timeline infers it and shows it in italics: it is a guess, and it looks like one. With two related people it picks neither.

The list, the kanban, the calendar and the timeline all open the same editor, and from it you touch everything above — title, description, status, urgent, backlog, owner, deliverable, date and range — and talk it over in the task's comments. There is no screen where you can do more than in another.

Reminders: the task that also pings you

A reminder is a task with an hour: at that hour it reaches you, whether the app is open or not. It lives on the same board as the rest, with its ⏰ 15:30 next to the date — without the hour in sight it would read like any other task —, and the Reminders filter leaves only the ones that will ring. On the calendar it sits on the day and hour of the alert, and over chat, recordatorios lists them.

You ask for one with the / → Reminder menu in the daily note or over chat: "recordame mañana a las 15:30 llamar al contador". The time is yours: if you travel, the alert rings at the local time of wherever you are. How to write one, what happens when you edit or delete the line and which way the alert reaches you, in The daily note; over chat, in WhatsApp and Telegram.

Views: one criterion and one shape

The Tasks screen asks two questions, and it asks them in a single bar: by which criterion the work gets split, and in which shape it gets drawn. Both are picked up top and every combination is remembered, so coming back to Tasks puts you exactly where you were.

There are seven criteria, in two families. Two split the work by a property of the task itself:

Four split it by an Atlas entity — and the columns come out of what the app already linked in your text, with nothing assigned by you:

And the seventh is AI deliverables, which groups not by anything that already exists but by a result the AI proposes: it is further down.

There are three shapes, and switching shape keeps the criterion:

• List — one row per task, grouped by the criterion. It is the one that fits the most on screen, and the only one that shows every entity of a task at once.
• Kanban — one column per group, cards you drag. Dragging means something different under each criterion: under Person it reassigns, under Project it moves the task to another project, under Status it changes the status.
• Timeline — the same columns, laid down on an axis of dates. It is right below.

Two combinations do not exist: Urgency and Status have no timeline —one already has dates for columns, and the other would have the five statuses for rows— and AI deliverables is kanban and nothing else.

What you are not deciding today gets out of the way without being deleted: backlog hides the task from Tasks until you switch on the Backlog filter, and in the editor, The planner skips it until a date keeps it in Tasks but out of the week plan until that day.

A combination you keep coming back to is saved by name as a board, and a board can be shared with someone else or with a team without giving them access to anything else in your space: how that works is in Secondbrain Teams. Your boards live in a side panel, like the Recaps library: it starts closed to leave the screen to the work, opens with a click and closes again on its own once you pick one.

The status board: dragging is changing status

It is the usual kanban —same cards, same dragging— with one difference: the columns are not things in the world but the statuses a task goes through. Which is why dragging here reorders nothing: dropping a card in another column changes its status.

There are five columns and four statuses: backlog is not a status but a separate mark that lives alongside "pending" —what you set aside is still pending, just off the radar—, and it gets its own column because "what did I put off?" and "what do I still have to do?" are two different questions.

1. 1
   Backlog · Pending · In progressThe three you look at every day. Moving between them closes nothing and asks nothing; the drag also clears the opposite mark, so something you pull out of the backlog to work on does not end up carrying both.
2. 2
   Done and CancelledThe two ways of closing. What is closed is not deleted: it stays in the history.
3. 3
   And the way backDragging a card out of Done or Cancelled reopens it, and reopening clears the closing date: a task that came back to the radar cannot go on claiming it was closed on Tuesday.

The last two columns say how far back they look, and that is where you change it: by count —the last 25 or 50, always full—, by period —15, 30 or 90 days, which can come up empty, and that says something too— or all. What you just closed is never cut, however full the cap already is.

Next to the criterion there is a second dropdown that narrows the board to one project, person, organization or label. Mind the difference: it does not group and it does not split the board, not one column moves — it only takes out of sight whatever is not from there. And there is no column configurator and no reordering: the statuses are not a list each person builds, they are the ones there are.

The timeline: when, and for how long

It is the same board laid down on an axis of dates. The rows are the same columns the kanban builds —project, organization, person or label—, and inside each one you can group by any of the other three: projects with their people inside, clients with their projects inside. The top row shows the summary of what is below it and cannot be dragged: it is a calculation, not a date anyone set.

Every task is drawn according to the dates it has, and the difference is information:

• A bar — the task has a declared range: from this day to that one, and the width means something.
• A diamond — the task only has a due date: nobody said how long it takes, so it is not drawn as a one-day bar. The first tug on an edge turns it into a bar.
• An empty lane — the task has no date at all, but it gets a row anyway: drag across its lane to draw the bar, or click once to leave a due date.

Every gesture happens on that same bar:

1. 1
   Sideways: move or stretchFrom the middle, the whole task shifts; from an end, it stretches. While you drag, a little label spells out the dates in words — at month scale three days are ten pixels, and by eye you cannot tell what changed.
2. 2
   Up or down: change rowThe same bar, moved to another row, changes its project, its person or its organization. It is the same gesture as dropping a card in another kanban column, and it does exactly the same thing.
3. 3
   And the axis locksWithin the first few pixels the gesture decides whether it is horizontal or vertical and stays locked until you let go, so moving a bar three weeks never drags it to another row by accident.

At the bottom there is a rail: the scale —days, weeks or months—, one screen back and forward, Today, how many tasks have no date, and a checkbox to also bring in what is done and cancelled, off by default. The axis scrolls endlessly both ways, and the name column on the left widens by dragging its edge.

Deliverables · Hobby: how loose tasks are grouped

When tasks get detected on their own there are many of them, and none is worth much alone. "Ask for the logo", "review the copy", "send Ana the link" are not three things: they are one presentation. A deliverable is that handful of tasks that together produce a result someone is waiting for.

Grouping runs on its own when you open AI deliverables and there are new loose tasks — or when you hit the round button at the bottom right —, in three steps, and each one only does what it is good at:

1. 1
   They get compared by meaningEvery open task is compared to the rest by what it says rather than the words it uses: "ask for the logo" and "send Ana the artwork" resemble each other without sharing a single one.
2. 2
   The ones that resemble each other join upEach task attaches to the group it resembles most, if the resemblance is close enough. Sharing a project or an organization pushes that resemblance up. No AI takes part yet: with the same material, the result is always the same.
3. 3
   AI names and prunesOnly at the end does the AI step in, and only for two things: deciding whether the group holds up as a deliverable and giving it a name that means something. It does not decide the grouping — the previous step already did.

The rules that make the result believable:

• A deliverable has two tasks or more. A one-task deliverable is just the task.
• It never touches a task that already has a deliverable. Regrouping does not overwrite what you arranged by hand.
• Before inventing a new deliverable, it tries to fit the task into an existing one. Without that rule, every run would create duplicates.
• By hand too: holding one card over another creates a new deliverable with both, the name changes from the column header, and a task moves from one to another by dragging it. Automatic grouping is a starting point, not a verdict.

History, archive and undo

The Task history — the clock button at the top of Tasks — gathers what you completed and cancelled, plus definitions and milestones, with date and origin. It is what feeds your weekly reports.

Completing a task archives it, it does not destroy it: it stays searchable and stays linked to its project and its people. And if you got it wrong, from the history you reopen it and it goes back to pending.

When the list has filled up with tasks that got done and nobody ticked, the phone's cleanup goes through them one at a time, in the order that makes sense: it is in the mobile app.

What holds for both

If your team already works in ClickUp or Jira, there is no need to move. secondbrain syncs with both both ways: what the team files there shows up in your tasks, and what comes out of your daily note or a recap goes up there with its date and its people. Each one has its own detail further down: ClickUp and Jira.

1. 1
   Where they connectWorkspace switcher → Edit workspace → Integrations → Tool sync. It is set up from the web or the desktop app; the iPad does not configure it, but what you connected keeps working there.
2. 2
   You authorizeThe ClickUp or Atlassian window opens, you grant access and come back. No keys to copy.
3. 3
   You pick what, and which wayClickUp lists or Jira projects, one by one. Both syncs back and forth; Pull only brings things in: those tasks are visible here but edited there, and carry a lock that says so.

A task lives in a single tool. If you have both connected, a new task is never duplicated: it goes to one place, decided in this order:

• The one you pick on the task. When you create or edit it you get the ClickUp list and Jira project fields. Picking one sets the other to None, and None (Secondbrain only) keeps it here.
• Its project's. If the task is linked to an Atlas project that is a ClickUp list or a Jira project, it goes there.
• The default one. The Default for new tasks button next to each list or project marks where new tasks go when neither step above placed them; once marked it reads ★ Default for new tasks. There is only one per workspace across both tools: marking it in one unmarks it in the other, and clicking the marked one clears it.
• If none of that applies, the task stays in secondbrain.

Two more rules on what goes up: only tasks created after connecting go up on their own —older ones go up if you pick a list or project for them by hand— and private tasks never go up.

When things travel. What you change here goes up right away. What changes there arrives almost instantly, through the notice the tool sends, and on top of that everything is checked again every two minutes in case something got lost on the way. The panel has Sync now, which tells you how many came down (↓), how many went up (↑) and how many conflicts there were.

Statuses. secondbrain has four —Pending, In progress, Done and Cancelled— plus Backlog, which is a mark on Pending. Your tools have whatever statuses your team came up with. The translation goes by each status's category, so it works with any workflow without setting anything up:

And on the way back, when you move a task here, a status from the matching category is picked, preferring the obvious name:

Moving a task within the same category overwrites nothing: if it went from In progress to Code review there, it stays In progress here untouched; if it is Cancelled here, closing it there does not turn it into Done.

If your workflow needs something else, every list or project has a Statuses drop-down where you change the translation one status at a time: Automatic, Pending, Pending + Backlog, In progress, Done or Cancelled. What you changed is marked edited and goes back with reset. And every synced task has a chip with the tool's real status —“Status in Jira: Code review”—: one click and you pick exactly which one to move it to.

ClickUp, in detail

When you connect, all your lists come in switched on and set to Both, and so do the ones you create later in ClickUp; you switch off the ones you do not want. Each ClickUp Workspace you authorize is a separate account, and you can connect more than one. The first read brings every task that is not archived, closed ones included.

• People. The members of your ClickUp team show up in the Atlas on their own. The assignees of a ClickUp task come in as its related people; on the way back, each person is matched to a member by username or email, and if nobody matches, nobody is assigned. Urgency does not travel: here it is worked out from the due date.
• If it changed on both sides, the latest edit wins and it counts as a conflict. Before sending anything up, the task is read again from ClickUp, so a change made there a minute ago is not overwritten. People, tags and groups are merged: what someone removed on one side does not come back.
• Moving a task to another list asks for confirmation, because ClickUp does not move: it deletes it and creates it again over there. Subtasks, comments (as a copy) and attachments are kept; the activity history is lost and the ID changes.

If ClickUp withdraws the app's permission, the account goes to needs reconnecting with the notice “ClickUp stopped authorizing this workspace: connect it again”, and it does not sync until you hit Reconnect. What you had chosen is kept. A list that can no longer be read does not stop everything: it is skipped and the rest carry on.

While the connection is down, that account's tasks are read-only, for you too: whatever you changed here would not reach ClickUp, and could be overwritten on reconnecting. A red strip shows up at the top of Tasks — “Your ClickUp connection is down: 3 tasks are read-only until you reconnect it” — with a Reconnect ClickUp button, and the editor of each of those tasks states that problem and nothing else, with the same button.

Jira, in detail

When you connect, projects come in switched off: you switch on the ones you want to sync —there is a search box when there are many—. Each project gets two choices: direction, Both or Pull, and scope, All —the project's open issues plus the ones closed in the last 30 days— or Mine —only the ones assigned to you; what was already brought in is kept even if it changes hands—. Each Atlassian site is a separate connection, and you can connect more than one.

• The owner. Here the Jira assignee is the task's Owner —in ClickUp, by contrast, assignees come in as related people—. Coming in, the Atlas person is found by email or name; going out, among the people assignable in that project, and it is only assigned when there is exactly one match: with two Martíns, it does not guess. Related people do not travel.
• Statuses go through the workflow. Jira does not let you set any status: it takes a transition. secondbrain picks one the workflow allows, and when closing it fills in the resolution — Won't Do for a cancelled one, Done for a done one. If the workflow does not allow it, it says so (“the Jira workflow does not let it move to…”) and does not insist until you change it again. Note: what tells a closed issue is a cancellation is its resolution, not the status name; if your workflow closes without a resolution, adjust it under Statuses.
• If it changed on both sides, it is settled field by field: if the title changed there and the date here, both stay. Only when the same field changed on both sides does the most recent win, and that counts as a conflict. Labels are added together. In a project set to Pull, Jira always wins.
• New tasks are created as Task, are born in the workflow's initial status and are then moved to the right one. Default for new tasks can only be marked on a project set to Both. If the project has required fields secondbrain does not fill in, the panel warns you first: those tasks will not be able to go up there.
• Moving a task to another project moves the issue: it keeps its history and comments, but the key changes (ABC-12 becomes XYZ-3). Jira requires the Make bulk changes permission for it.

Jira changes arrive instantly through a notice the site sends; if that notice is not active, the panel says so and they arrive every two minutes. If the permission is revoked or access to the site is lost, the connection goes to needs reconnecting and is fixed with Reconnect.

Just like ClickUp, while it is down its tasks are read-only, for you too, with the “Your Jira connection is down…” strip at the top of Tasks and the Reconnect Jira button on the strip and in each task's editor.

In a shared board

A shared board shows every task that meets its conditions, and that includes the ones coming from ClickUp or Jira. The rule behind everything else: secondbrain never writes to your ClickUp or your Jira with your account on someone else's behalf. Whoever gets the board sees those tasks; editing them is a different matter.

Nobody who gets a board can delete tasks or pull them out of the board, wherever they come from. And private tasks never come in.

1. 1
   When you share, it tells youIf the board includes ClickUp or Jira tasks, the share dialog says so before inviting: how many are in today and, if a condition is something a tool brought in — a Jira project, a ClickUp list, a label —, that new tasks from there will come in on their own. Share stays off until you tick I understand: share them anyway, just like with a board with no conditions.
2. 2
   Or you leave them outThe same notice has Don't include ClickUp or Jira tasks in this board: the board is shared with everything else and nothing from the tools, not even what you added by hand. Include them undoes it.
3. 3
   If they show up later, it tells you againIf an already shared board starts bringing in tasks from a tool you had not confirmed — you changed the conditions, you connected Jira afterwards —, a strip with Got it and Don't include them shows up on top of the board. And connecting ClickUp or Jira while you have shared boards is flagged in the integration panel too.

How the person who got the board connects their account. They open a ClickUp or Jira task and hit Connect my … account: the ClickUp or Atlassian permission window opens, they authorize and come back. That connection only identifies them: it syncs nothing and brings no tasks into their space. If they already sync that tool in a workspace of their own, there is no need: that one is used.

The tool decides whether they can edit. Jira says up front whether that account can edit the issue. ClickUp has no way to ask: if the account can see the task it is allowed to try, and if ClickUp refuses, the task turns read-only for that person with the reason. Either way, if the tool says no, nothing changes in secondbrain: no half-saved tasks. If their permission there changes, it is asked again within a few minutes.

New tasks written by whoever got the board stay in secondbrain only: your sync does not push them to your ClickUp or your Jira. If they have an account in the tool, the board shows Also create new tasks in “Backend”, with your Jira account; ticked, they are created there with their account and stay synced like any other. If the tool does not allow it, the task stays in secondbrain and a notice says why. Without an account, the strip offers to connect one. A task someone else wrote can be sent to a list or project by you, picking it by hand.

If your connection goes down, that tool's tasks become read-only for everyone — for you and for whoever got the board —, and they see “The board owner's Jira connection is down”. Everything comes back when you reconnect.