MANDATORY gate BEFORE any Todoist operation โ orchestrates GTD semantics the CLI alone can't provide (discovering each user's structure, outcome vs activity language, workspace vs personal filtering, horizon alignment). Invoke FIRST for weekly review, outcome coaching, and pattern detection. Triggers on 'clean up outcomes', 'team priorities', 'is this a good outcome', 'weekly review', 'am I overcommitting', 'check my patterns', 'should I take this on', 'scope creep', 'reorder my queue'. (user)
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
MANDATORY gate BEFORE any Todoist operation โ orchestrates GTD semantics the CLI alone can't provide (discovering each user's structure, outcome vs activity language, workspace vs personal filtering, horizon alignment). Invoke FIRST for weekly review, outcome coaching, and pattern detection. Triggers on 'clean up outcomes', 'team priorities', 'is this a good outcome', 'weekly review', 'am I overcommitting', 'check my patterns', 'should I take this on', 'scope creep', 'reorder my queue'. (user)
allowed-tools
["Bash(accomplis:*)","Read","AskUserQuestion"]
Todoist GTD
Setup (do this for the user, don't ask)
Be proactive. If accomplis isn't working, fix it โ don't list commands for the user to run.
1. Install the CLI (if missing)
Install from the source repo โ the marketplace cache ships no pyproject.toml, so a cache/CLAUDE_PLUGIN_ROOT install fails ("does not appear to be a Python project"):
The SessionStart hook (ensure-accomplis.sh) already runs this logic automatically โ you usually don't need to install by hand.
2. Authenticate
accomplis doctor
If doctor reports no token, run accomplis auth for setup instructions, then accomplis auth --token TOKEN to store it (Keychain on Mac, plugin data dir on Linux). No manual env vars or shell profile edits needed.
NEVER echo the API token back to the user. The token is a secret.
Overview
MCP-free Todoist integration using the official Python SDK (v4, httpx-based). Adds semantic understanding of GTD structure and outcome quality coaching on top of the CLI's data access.
Core insight: The CLI provides data. This skill provides meaning.
When to Use
IMPORTANT: Invoke this skill BEFORE making Todoist queries. The CLI doesn't know the user's GTD structure โ this skill does. Without it, you'll query wrong fields (tasks vs sections), miss context (outcomes are sections, not tasks), and produce confusing results.
Use for:
ANY Todoist query or update (load this skill first for context)
Simple task creation that doesn't need GTD framing
Quick queries where you already know the project structure
Discovering the User's Structure
DO NOT assume project names or team member details. Every user's Todoist is different. Discover dynamically:
# Who am I?
accomplis whoami# What projects exist?
accomplis projects
# What's the structure of a specific project?
accomplis sections --project "Project Name"# Who's on a shared project?
accomplis collaborators --project-id "<id>"
The Universal GTD Pattern in Todoist
Regardless of how each user names their projects, look for this structure:
GTD Concept
Where in Todoist
How to Find
Desired Outcomes
Sections in an outcomes project
Look for projects named like "Desired Outcomes", "Goals", "OKRs"
Next Actions
Tasks under outcome sections, or in context projects
Look for projects named with @ prefix or action-oriented names
Waiting For
Tasks in a waiting/follow-up project
Look for "@Wait", "Waiting For", or similar
Someday/Maybe
Tasks in a someday/backlog project
Look for "@Someday", "Someday/Maybe", or similar
Areas of Focus
Sections in an areas project
Look for "Areas of Focus", "Responsibilities", or similar
Reference
Projects for reference material
Varies by user
Where Outcomes Live: Discover, Don't Assume
Outcomes commonly live as sections in an outcomes project โ but not always, and the same user may use different layouts in different projects. Discover per project by reading what the sections are:
Desired Outcomes (project) Projects - Toolmaking (project)
+-- Built team capacity for... (section) +-- Someday (section = status lane)
| +-- [tasks under it] +-- [outcomes as TASKS at root]
+-- Established new... (section)
= sections ARE outcomes = sections are STATUS LANES,
โ query with `sections` outcomes are tasks โ query with `tasks`
The discrimination test: list a project's sections and read their names.
Names like past-tense achievements ("Built...", "Secured...") โ sections are outcomes
Names like status lanes (Someday, Now/Later, To Do/Doing/Done) โ outcomes are tasks, sections are workflow states
No sections at all โ it's a flat context or task list
Record what you find and use it for the rest of the session rather than re-deriving. When coaching a new user, the sections-as-outcomes layout is the pattern to recommend โ but read before you write.
Workspace vs Personal Projects
The CLI auto-detects workspace (team) projects and filters accordingly:
# Your tasks on a shared project (default)
accomplis tasks --project "Shared Project"# Triage unassigned tasks
accomplis tasks --project "Shared Project" --unassigned
# Everyone's tasks
accomplis tasks --project "Shared Project" --team
# Specific person
accomplis tasks --project "Shared Project" --assignee "Full Name"
GTD Contexts Are Usually Projects
GTD contexts (Waiting For, Work, Somedayโฆ) are usually PROJECTS, not labels. Query with --project, not --label (unless the user genuinely uses labels).
accomplis tasks --project "@Wait"# if their contexts use an @ prefix
accomplis tasks --project "& Waiting For"# if they use an & prefix, or plain names
The prefix is a per-user convention, not a rule โ @, &, emoji, or none at all. Even one user's convention changes over time. Discover it fresh: list all projects and look for the short, action-situation names (Work, Home, Waiting, Someday, Agendas) clustered under a common prefix.
GTD Methodology
Horizons of Focus
GTD organises commitments across six horizons. Each horizon informs the ones below it:
Horizon
Focus
Question
Review Cadence
H5: Purpose
Why do I exist in this role?
"What's my unique contribution?"
Annual
H4: Vision
What does success look like in 3-5 years?
"Where am I heading?"
Quarterly
H3: Goals
What do I want to achieve in 1-2 years?
"What milestones matter?"
Quarterly
H2: Areas of Focus
What are my ongoing responsibilities?
"Am I covering all my areas?"
Monthly
H1: Projects/Outcomes
What multi-step results am I committed to?
"What's on my plate?"
Weekly
Ground: Actions
What's the next physical action?
"What do I do right now?"
Daily
In Todoist mapping:
H1-H2 live in outcomes and areas projects
Ground level lives in context projects (@Work, @Wait, etc.)
H3-H5 are typically in annual/strategic projects or outside Todoist
The Five Steps of GTD Mastery
Capture โ Get everything out of your head into a trusted system
Clarify โ Decide what each item is and whether it's actionable
Organise โ Put things where they belong (project, context, waiting, someday)
Reflect โ Review regularly (weekly review is the critical habit)
Engage โ Choose what to do with confidence
Natural Planning Model
When creating or coaching on outcomes, use this framework:
Purpose โ Why are we doing this? What's the strategic reason?
Vision โ What does wild success look like?
Brainstorming โ What are all the ideas, concerns, loose ends?
Organising โ What's the sequence? What depends on what?
Next Actions โ What's the very next physical action?
Use this when: Creating new outcomes, reviewing stale outcomes, or when someone is stuck on "where do I start?"
Tier 2 vs Tier 3: The Critical Distinction
Tier 2 (Outcomes) ask: "What do I want to have achieved?"
Tier 3 (Projects/Actions) ask: "What do I need to do?"
Quick test:
"Write the strategy doc" -> Tier 3 (activity)
"Team has clear Q4 direction" -> Tier 2 (achievement)
The pattern: Past-tense verb, describes what's different when done, includes the "so what".
Activity (Tier 3)
Achievement (Tier 2)
Write the docs
New team members can onboard within a day
Build rate limiter
API stays responsive under peak load
Attend conference
Established voice in industry discussions
Complete audit
Audit trail catches anomalies before users notice
Canon vs House: Which Rule Are You Applying?
Two layers, and coaching goes wrong when they're conflated โ say which one you're invoking:
Allen (canon): a Project is ANY desired result requiring more than one action step. The list is a complete inventory โ 20-30 in flight is normal, and dull projects are still projects. Never "demote" a dull-but-real multi-step commitment off the list. Desirable FRAMING applies to everything; that's writing discipline, not tier privilege.
House (the two-tier design): within the full visible inventory, a highlighted 3-5 are the delegated outcomes โ the review tier, typically marked p1 in Todoist (or whatever marking the user's team has adopted โ discover it). THOSE, read side by side across a team, should add up to team strategy. NB the API and CLI invert the app's scale: the UI's P1 is --priority 4, and unmarked is 1.
The "3-5 outcomes" target applies to the highlighted tier ONLY. Applying it to the whole inventory is a category error โ it pressures people to delete real commitments instead of marking priorities.
Coaching words before fixing structure wastes the polish. Run a board review in this order:
Structure โ Check for sync automations and mirrors BEFORE diagnosing duplication as mess (systemctl --user list-units | grep -iE 'todoist|sync', launchd agents, cron โ one user had a systemd timer deliberately twinning team-assigned tasks into a personal project; edits go to the canonical side, which the automation's own description usually names). Then twin boards, duplication across horizon layers, orphaned/unassigned cards.
Altitude โ Census every card: outcome / project / next action / raw capture / already-done. Complete the done, demote the actions, fold the captures (a calendar invite is a date, not a commitment).
Outcome goes: wherever this user's outcomes live โ discover first (see "Where Outcomes Live" above), then match their layout.
# In a sections-as-outcomes project:
accomplis add-section "Built team capacity through documentation" \
--project "OUTCOMES_PROJECT"# In a tasks-as-outcomes project (sections are status lanes):
accomplis add "Built team capacity through documentation" \
--project "OUTCOMES_PROJECT"
Either way, write it as an achievement, not an activity โ that's the part that doesn't vary by user.
Writing Next Actions (GTD Style)
Next actions must be concrete, physical, and start with a verb describing what you'd actually do.
Bad (vague, outcome-ish):
"Sort out the legal stuff"
"2026 planning"
Good (concrete, physical):
"Read the brief and note 3 questions for the meeting"
"Open the deck + outcomes list, draft team plan skeleton"
The test: "What would I actually do when I sit down to do this?"
Create a follow-up item in the appropriate context project
Outcome stays assigned to delegator until the conversation happens
Completing vs Deleting Tasks
Always complete, never delete (unless truly erroneous).
Completed tasks preserve history for future planning
Duplicates should be completed with a note
Obsolete items should be completed (still counts as "resolved")
This governs your recommendations, not just your tool calls. In review prose, the phrase to reach for is "complete it with a note" โ for duplicates, dead items and drifted somedays alike. A user who hears "kill it" or "write it off" deletes history the system was preserving; completion resolves the item and keeps the record.
Anti-Patterns
Bad Practice
Why Wrong
Better
Guessing where outcomes go
Mismatches the user's layout
Discover first, then match it
Tier 3 project as outcome
Inflates outcome count
Challenge: "Activity or achievement?"
Completing without reflection
Loses learning
Prompt for resolution notes
Joint ownership
No clear driver, item drifts
One owner per outcome
No next action on active outcome
Outcome stalls invisibly
Every active outcome needs at least one next action
Review Cadences
Daily Review (~10-15 mins)
Three parts: Clarify, Check Lists, Calendar.
Clarify โ Process inboxes to empty (email, Todoist inbox, other capture points)
Check Lists โ Quick scan: agenda items for today, stale waiting-fors, projects missing next actions
Calendar โ Next 7 days, agendas for today's meetings
Weekly Review (~45-60 mins)
Three phases: Get Clear, Get Current, Get Creative (Allen's canonical labels).
Get Clear โ Mind sweep all capture points, process every inbox to zero
Get Current โ Review all projects, next actions, waiting-fors, calendar
Get Creative โ Review someday/maybe, notice what's missing, generate ideas
5+ outcomes in the highlighted review tier -> "Can you really advance all of these?" (the full inventory can hold 20-30 โ see Canon vs House above)
All outcomes high priority -> "If everything is critical, nothing is focused โ which 3-5 are the review tier?"
Strategic gaps:
Outcome has no tasks -> "Stuck, deprioritized, or needs rescoping?"
No outcomes in an area of focus -> "Dormant area โ intentional?"
"Should I take this on?":
Ground the answer in the whole system before advising โ one unscoped accomplis tasks sweep covers every project, and whatever it surfaces belongs in the answer. Connect what you find by name: the Inbox twin (is this ask already half-captured?), the Someday neighbour (adjacent parked ambition โ its moment, or its competitor), the outcome it would or wouldn't advance, and the honest load picture in waiting-fors and actions. Full method: references/PATTERNS.md.
Staleness:
Outcome unchanged 4+ weeks -> "Stuck, deprioritized, or needs rescoping?"
Quality:
Outcome reads like activity -> "This is what you're doing, not achieving"
Missing success criteria -> "How will you know when it's done?"
Note: Replace OUTCOMES_PROJECT, PROJECT, SECTION with the user's actual project/section names discovered via accomplis projects and accomplis sections.
Remember
The CLI is plumbing. This skill is meaning.
Discover structure dynamically โ never assume project names, prefixes, or where outcomes live
Outcomes are usually sections, sometimes tasks โ read the sections to tell which
"Project" means different things in different contexts
Challenge activity language -> frame as achievement
