omnifocus-assistant

OmniFocus Assistant

Brain + Hands Architecture: This skill provides the "brain" (methodology, intent interpretation, guidance). The OmniFocus MCP server provides the "hands" (tool execution). Use both together.

Intent Recognition

Step 1: Information or Action?

User wants information → omnifocus_read (read-only)
User wants to change something → omnifocus_write (creates/updates/deletes)
User wants insights → omnifocus_analyze
User wants GTD guidance → Provide advice (no tool call needed)

Reference map

The detail lives in references/. Read a file when its trigger fires — never read them all up front. Read more than one when a request spans them (a weekly review needs the workflow file and the GTD file).

When no row clearly matches, do not answer from general knowledge. These files hold project-specific conventions that used to be unconditionally in context, so a miss silently substitutes generic advice for Kip's actual conventions. On an ambiguous or compound request, read references/intent-to-tool-calls.md first — it maps phrasing to tools and usually disambiguates — then the closest-matching row above. Reading one file too many costs a few hundred tokens; reading one too few silently changes the answer.

What belongs in a references/ file (the extraction rule, adopted from wrap-up PR #7): content whose trigger fires no later than the earliest moment that needs it. The test is direction, not how many places use the content — a file may serve several triggers, so long as every one of them precedes a use. What a reference file may never carry is anything needed before it would be opened: a reader who loads it on the "creating a task" trigger never sees it while deciding whether to create one at all. That content stays resident here — which is why Date Conversion and the three result-reading hazards below are in this file rather than in the topic files they belong to. Group by when it's needed, not by which topic it concerns.