Hakadorio
Local-first task manager where you describe what you need and the agent figures out the rest.
Most task managers make you do the work of a task manager: decide structure, assign categories, estimate effort, break down subtasks. That friction is fine if you're already organized. It's a blocker if you're in the middle of something and just need to capture 'set up the staging environment before Thursday, coordinate with DevOps.' A local-first system with an AI layer should be able to take that sentence and create a structured, actionable task — without sending your work data to a third-party server.
- FastAPI backend with a local-first data model — all task data stays on device by default, with optional sync for collaboration.
- Claude API integration for natural language task creation: a single sentence gets parsed into structured task attributes (title, due date, dependencies, subtasks) via tool use.
- TypeScript frontend that keeps the interaction surface minimal — the AI does the structuring, the UI gets out of the way.
- Claude's tool use API handles entity extraction and task decomposition deterministically: the model fills a schema, not freeform text, so the output is always parseable without a second LLM call.
Local-first as a hard constraint, not a preference
Task data often contains sensitive work context — project names, deadlines, dependencies between people. Defaulting to cloud sync would be fine for personal tasks but breaks in professional contexts. Local-first flips the default: data stays local unless the user explicitly opts into sync.
Tool use over prompt-parsed JSON
Early prototypes asked Claude to 'return a JSON object with these fields.' Parsing was fragile — the model would occasionally add markdown fences, explanatory text, or vary key names. Tool use enforces the schema at the API level, so the output is always valid and the backend never needs a fallback parser.
Active development. NL task creation, local persistence, and basic frontend are working. Subtask decomposition and optional sync in progress.
Contributing to an open-source project with multiple stakeholders is a different constraint than solo projects — design decisions need buy-in, not just correctness. The most useful skill has been writing clear proposals for changes rather than just opening PRs.