Territorial Assistant

How the timesheet assistant works

Every fifteen minutes the daemon ingests window and browser events from ActivityWatch, compacts them into activity blocks and resolves as many as it can with learned rules: this repository is that client, this URL host is that project. Only the ambiguous remainder goes to Claude. Blocks become raw intervals per client, intervals are merged into cognitive sessions with a 15-minute margin and a 45-minute gap tolerance, and each session is enriched with what was actually done using commits and transcripts from that window.

The result is a proposal in a Discord thread, one per day. I answer in plain English ("S2 is ACM, Maintenance & DevOps milestone"), the bot revises, learns the rule, and on approval registers one time entry per session and project through the Invoices MCP endpoint. Incomplete days are refused rather than half-registered.

The marketing assistant

The second module treats expertise as the product. It gathers the week's git history, pull requests and transcripts, extracts what happened and what the lesson was, then scores each item as an angle a GIS manager or CTO would care about even without knowing the project. Monday brings a digest of candidates in Discord; I pick and assign each to a blog, the assistant drafts in a thread, opens a pull request against the site on approval, and prepares LinkedIn posts once the article is live. The knowledge base persists between weeks, so low-scoring items can be revived later.

Design constraints

Stages communicate only through the database so any of them can be re-run. Claude is invoked through the local CLI with structured output schemas, no tools and no session persistence, so assistant-generated calls never contaminate the transcripts the assistant later reads. A gate reads the subscription usage endpoint and drains a priority queue only when budget would otherwise go unused: interactive replies first, timesheets second, marketing last.