todoist

name	todoist
description	Use whenever Justin asks you to capture, find, complete, schedule, defer, or organize a task — or when you should proactively offer to (e.g. he says 'I need to remember to X', 'follow up on Y next week', 'the next step is Z'). Wraps the 54 `mcp_todoist_*` tools the Doist MCP server exposes. Covers tool selection, write hygiene, the status-project model (Now/Next/Later/Maybe), Obsidian-project linkage, and Justin-specific conventions.
version	2.0.0
author	Hermes Agent
license	MIT
metadata	{"hermes":{"tags":["todoist","task-management","productivity","mcp"],"related_skills":["native-mcp","obsidian"]}}

Todoist (Apollo scope — full Todoist) — ⚠️ DEPRECATED ⚠️

[!warning] DEPRECATION NOTICE: Transitioned to Obsidian TaskNotes (June 23, 2026) Justin has stopped using Todoist entirely. All task management has been migrated to the Obsidian TaskNotes plugin.

• Do NOT use Todoist tools (mcp_todoist_*) to manage or capture tasks unless explicitly requested.
• All active tasks are now stored as individual Markdown files under /home/justin.guest/Developer/obsidian-vault/TaskNotes/Tasks/.
• Completed or dropped tasks are archived under /home/justin.guest/Developer/obsidian-vault/TaskNotes/Archive/.
• Conventions & Schema: Refer to /home/justin.guest/Developer/obsidian-vault/TaskNotes/Setup.md and the .cursor/rules/tasknotes.mdc rule file for all active task management schemas, statuses (open, now, next, soon, later, done, dropped), and workflows.

Justin's legacy task system. Todoist Pro account (uid 49270620), shared between Hermes and Apollo via Doist's official MCP server (@doist/todoist-mcp, stdio, env TODOIST_API_KEY). One token, one task list — both agents see the same Todoist, but they have different scopes. Clio doesn't have it.

Apollo's scope: everything in Todoist. Hermes is restricted to tasks labeled hermes; Apollo operates across the full task list.

Justin's Todoist model (the new shape — read this twice)

As of May 2026, Justin uses simple Projects to represent statuses. The structure is:

• Top-level Projects represent status-based buckets:
  • Inbox (id 6VGcQ7r6HW5r87j9) — capture/triage bucket; tasks with no project go here
  • Now (id 6gj6m9W3hQMgpWFp) — actionable now
  • Next (id 6gj6mxchHhffC7h9) — review daily & move as appropriate
  • Soon (id 6gj6mCC4GffrVfwJ) — review weekly & move as appropriate
  • Maybe Later (id 6gj6mGwQ95rW9Hw8) — review monthly & move as appropriate
  • Shopping (id 6gh9QhMVFjJpMPr9) — shopping list items
• No Work/Home/Other top-level projects or GTD sub-projects are used under this model.
• Labels carry context (area, location, person, status). Infer them from conversation even if not stated explicitly.

Label	Type	Meaning
work	Area	Work tasks
home	Area	Home / personal tasks
@<location>	Location	Where the task needs to happen, e.g. @costco, @office
<person>+	Person	Person the task involves, e.g. nana+, sam+. Suffix +, not prefix — name comes first. (Mnemonic: Japanese "nana-to" = "with nana".)
waiting	Special	Delegated or blocked — waiting on someone/something
hermes	Special	Hermes-originated tasks — do not touch

Label deduction: When Justin asks Apollo to add a task, infer labels from context even if not explicitly stated. A task clearly about work gets work; one about picking something up at a specific store gets @store-name; one involving a specific person gets +person. If ambiguous, leave unlabeled — don't guess. Never infer hermes or add it to any task.

• The hermes label (id 2183843700, teal) is reserved for Hermes-originated tasks. Apollo should not apply, remove, or modify it. If you see it on a task, that means Hermes created it; treat it as a read signal, not something to manage.

When to use

Reactive (Justin asks):

• "Add a task to…" / "remind me to…" / "put X on my list" → add-tasks (default to Inbox)
• "What's on my plate / due today / overdue?" → find-tasks-by-date (start with today, include overdue)
• "What's in Now / Next / Soon?" → find-tasks(projectId="<status-project-id>")
• "Mark X done" → complete-tasks
• "Reschedule X to Friday" → reschedule-tasks (NOT update-tasks — see Pitfalls)
• "Move X to Soon" / "this is blocked, push it to Soon" → update-tasks(tasks=[{id, projectId: "6gj6mCC4GffrVfwJ"}])
• "What did I get done this week?" → find-completed-tasks or get-productivity-stats
• "Add a note to that task" → add-comments (on the task, not the project)
• "What projects do I have?" → find-projects or get-overview (no projectId)

Proactive (offer, then act if confirmed):

• He says "I need to remember…" / "follow up next week…" / "next step is…" → offer to capture as a task. Don't silently create — confirm with one short clarifying line ("Want me to drop this in Todoist as 'X' due Friday?") unless the ask is unambiguous.
• After a long planning conversation produces a list of next actions → offer to batch-add them (add-tasks accepts an array up to 25).
• A meeting note in Obsidian generates obvious action items → offer to mirror them to Todoist (do not auto-sync; Justin sorts manually).
• An Obsidian project note acquires a clear "next action" that isn't yet in Todoist → offer to create the task with the project linked in the description.

Don't use Todoist for:

• Long-form planning, project briefs, meeting notes, research → that's Obsidian (use the obsidian skill). Todoist holds atomic actionable items with a state; Obsidian holds knowledge and project context.
• Recurring habits you'd track in a habit tracker (sleep, exercise) → recurring Todoist tasks work for these but Justin hasn't asked for that pattern; don't impose it.
• Anything Clio-related — Clio doesn't have the integration.

Capture conventions (important)

• Actions only. Todoist is for atomic actionable items with a state. No informational notes, FYIs, or "heads up" entries. If it isn't something Justin will do, don't add it.
• One concrete next action per task. No sub-tasks-as-project-decomposition. If the work is multi-step, either (a) capture only the next concrete action and let the rest stay in Obsidian, or (b) batch-add several atomic tasks each pointing back at the same Obsidian project.
• Descriptions must enable getting started. The description should give Justin everything he needs to begin the task without hunting: where the details live (email thread, Slack channel, Linear issue), direct links or URLs, relevant phone numbers or contact info, deadline if known, and Obsidian project link if applicable. One line per piece of context. If the source has a URL or permalink, always include it. The bar: could Justin open the task cold and immediately know where to go and what to do?
• Default project is Inbox unless Justin names a status project (Now/Next/Soon/Maybe Later) or the task obviously belongs in one. He sorts manually from Inbox. When in doubt, default to Inbox — being too helpful with auto-routing is worse than being too conservative.
• No App Store Connect issue emails. Justin doesn't handle those — engineering does. Skip them when scanning email.

Obsidian linkage convention

Apollo is the agent that bridges Todoist and Obsidian. When linking the two:

• Todoist task → Obsidian: include the linkage in the task description. Use one of:

  • Project: [[Project-Note-Name]] — for tasks tied to a multi-step Obsidian project
  • From: Meetings/2026-05-20 X.md — for action items born out of a meeting note
  • Source: <path or [[wikilink]]> — for tasks generated from any other Obsidian context

  Keep the linkage on its own line so it's easy to scan in the Todoist UI.

• Obsidian project note → Todoist: when you're working in an Obsidian project note and need to track its open actions, query Todoist with a searchText matching the project name (e.g. find-tasks(searchText="Project-Note-Name")). This finds tasks whose descriptions reference the project. There is no formal back-link; the prose reference is the link.

• Following a link: if a task description mentions an Obsidian note and you need context to complete the work, load that note via your Obsidian skill. The agent that follows the link is the agent that does the work — don't try to push Todoist context out to Justin and ask him to look up the note.

Capture from daily notes / email

When scanning Obsidian daily notes or email for action items:

1. Daily notes: check vault root (today's note) AND Daily Notes/ archive (past days). Read the last 7 days.
2. Skip completed items: in daily notes, tasks marked [x] in the Things Log are done — skip them.
3. Skip decisions-already-made: entries in "Decisions Made" sections are not action items.
4. Capture from Open Questions / Blockers: these are the richest source of genuine open actions.
5. Email noise to filter: automated notifications, shipping/delivery, marketing newsletters, payment receipts, parking receipts, calendar invite confirmations, Todoist onboarding emails, App Store Connect issue alerts, Readwise summaries, Substack newsletters.
6. Add descriptions: include context (who to follow up with, relevant issue numbers, deadlines, Obsidian project link) in the task description — not in the content.
7. Batch-add to Inbox: use a single add-tasks call for all captured items, all routed to Inbox. Confirm with Justin first only if the list is large and contains uncertain items.

Justin-specific conventions

1. Don't over-create. One well-shaped task beats five fragmented sub-bullets. When in doubt, ask. Justin would rather get one clarifying question than discover 8 micro-tasks in his Inbox.
2. Inbox is the default destination. Justin sorts manually into Now/Next/Soon/Maybe Later. Don't try to be helpful by routing for him.
3. Priorities default to p4 (Todoist's lowest / unflagged). Only set p1/p2 when Justin explicitly says "urgent", "high priority", "today", or similar. P3 is mid; P4 is the unspecified default.
4. Create tasks when asked, no friction. If Justin says "add X to my list", "create a task for Y", "remind me to Z" — just do it. Default destination is Inbox unless he specifies a status project. Infer labels from context (area, location, people) even if not mentioned explicitly. Don't ask for confirmation on straightforward captures — act, then confirm with one line.
5. Be conservative with deletes. Use complete-tasks to finish a task, NOT delete-object. The completed-task history is useful for retrospectives.
6. Use natural-language dates. dueString: "tomorrow at 3pm", "every monday", "in 2 weeks" — Todoist parses these correctly and preserves Justin's timezone (America/New_York). Don't construct ISO timestamps unless you have a specific reason.
7. Don't touch the hermes label. It's Hermes's identity marker. If a task is labeled hermes, that means the other agent created it. Leave the label alone; otherwise the task is fully in Apollo's scope.

The tool surface (54 tools, organized)

The MCP server registers these as mcp_todoist_<name> (hyphens become underscores). Don't try to memorize all of them — load this skill and reach for the ones below.

Daily-use core

Tool	Use for
find-tasks-by-date	"What's on my plate today / this week / overdue" — accepts startDate='today' to include overdue. Default responsibleUserFiltering='unassignedOrMe' is correct for a personal account.
find-tasks	Text search, project/section/label filtering, or a saved-filter ID. Don't pass both searchText and filter — pick one. For "what's in Now/Next/Soon/Maybe Later" use projectId=<status-project-id>.
add-tasks	Single task or batch of up to 25. Required: content. Common: dueString (natural language), priority, projectId (omit → Inbox), description, labels.
complete-tasks	Pass ids: [...]. Preserves recurrence (next occurrence auto-scheduled).
reschedule-tasks	Preserves recurrence. Use this, NOT update-tasks, when moving a recurring task (see Pitfall 1).
update-tasks	Edit content, description, priority, labels, project moves. Avoid using it to change due date on recurring tasks. Use projectId to move tasks between status projects.

Reading / overview

Tool	Use for
get-overview	Markdown overview. No projectId = all projects + hierarchy. With projectId = that project's full task tree. Great for "show me Now" or "show me Maybe."
user-info	Confirm which Todoist account is connected (sanity check). Returns current local time, daily/weekly goal progress, plan.
find-projects	List projects. Search by name with searchText. Confirms the status-project IDs haven't changed.
find-completed-tasks	Default 7-day window. Set since/until for a custom range. For "what did I get done this week" use responsibleUser = current user from user-info.
get-productivity-stats	Daily/weekly completion counts, goal streaks, karma. The "am I actually moving" stat.
find-activity	Audit log — added/updated/deleted/completed events. Useful for retro questions like "when did I create this?"

Organizing

Tool	Use for
add-projects / update-projects / project-management	Don't restructure the Now/Next/Soon/Maybe Later scheme. Justin owns the top-level project structure. Adding a project to that hierarchy needs explicit direction.
add-sections / update-sections / find-sections	Justin doesn't use sections. Do not add them.
add-labels / update-labels / find-labels	Labels are cross-project tags. Use the existing label scheme (above); don't invent new labels without confirming with Justin. Never touch the hermes label.
add-filters / update-filters / find-filters	Saved queries. Check find-filters for what Justin has set up.

Comments / notes on tasks

Tool	Use for
add-comments	Per-task discussion thread. Use this when you want to leave context on a task that doesn't belong in the description ("Justin said in chat he wants this delayed until Q3", paste from an external source). One comment per task per interaction is the right cadence; don't spam.
find-comments	Read existing comments. Provide ONE of taskId, projectId, or commentId.
update-comments	Edit a comment.

Reminders (Pro feature, available on Justin's account)

Tool	Use for
add-reminders	Three types: relative (minutes before due), absolute (specific time), location (geofence). Justin's timezone is America/New_York; let Todoist parse natural language.
find-reminders / update-reminders	CRUD.

Advanced (use rarely)

Tool	When
get-project-health / analyze-project-health	Limited value under the status-project model (Now/Next/Soon/Maybe Later are buckets, not goal-bearing projects). Don't volunteer.
get-project-activity-stats	Daily completion counts per project, 1-12 week window.
get-workspace-insights	Workspace-level aggregation. Justin is on personal Pro; workspace tools are inert.
add-goals / find-goals / complete-goals / link-goal-tasks	Todoist's goals layer. Don't use unless Justin asks.
find-project-collaborators / manage-assignments / list-workspaces	Multi-user features. Justin is solo; mostly empty results.
delete-object	Destructive. ASK before using. Polymorphic: takes a type + id.
fetch / fetch-object / search	OpenAI-MCP-compat tools. find-tasks etc. are usually more useful.
view-attachment	View a file attached to a comment.
list-resources / read-resource / list-prompts / get-prompt	MCP protocol primitives. Almost never directly useful.
reorder-objects	Manual order changes. Justin orders manually; don't reorder.
project-move	Move project between personal and workspace. Inert for Justin's solo Pro setup.

Workflow patterns

Pattern: capture a task mid-conversation

User says: "I need to follow up with Alex about the proposal next Tuesday."

1. Don't silently create. Confirm shape (and offer to link to an Obsidian project if relevant):

   Want me to add "Follow up with Alex about the proposal" to Inbox, due next Tuesday? I can link it to [[Acme Proposal]] in the description if useful.

2. On confirm, call:

   add-tasks(tasks=[{
     content: "Follow up with Alex about the proposal",
     dueString: "next Tuesday",
     priority: "p4",
     description: "Project: [[Acme Proposal]]"
   }])
   

   Omit projectId → Inbox. Justin triages.