Building an AI Audit for Things 3

TL;DR

This Claude Code project reads a Things 3 database, evaluates it against explicit task-management rules, and generates an audit report. It separates read-only analysis from approved changes through supported Things interfaces. The checks below describe reusable audit questions, not the contents or score of a private task store.

From Rules to Automated Checks

Documented rules are useful only when a system checks whether its current state still follows them.

The audit checks whether the Inbox is processed, tasks are actionable, tags support useful filtering, real due dates have deadlines, and multi-step goals use projects.

Without feedback, duplicate tasks and ambiguous entries can accumulate. Multi-step work may remain buried in individual tasks, making the underlying structure harder to maintain.

The problem is not discipline. The problem is that Things 3 has no built-in audit. No one tells you your system is drifting. You open it, see your tasks, do some work, and close it. The rot is invisible until it is not.

So I built something to tell me.

What I Built

A Claude Code project that treats Things 3 as a programmable system:

• Read via SQLite. Things 3 stores everything in a local database.
• Write through supported Things interfaces such as AppleScript and URL schemes. Do not modify the application database directly.
• Analyze by scoring the current state against my guide's principles.
• Track everything in a persistent context file that survives between sessions.

Git preserves the audit code, rules and approved analysis history. Keep private task exports out of public repositories. A versioned report is not a complete backup of the application.

The Database

Things 3 keeps its data in a SQLite database buried in a macOS Group Container:

~/Library/Group Containers/JLMPQHK86H.com.culturedcode.ThingsMac/
  ThingsData-<store-id>/Things Database.thingsdatabase/main.sqlite

The database may use write-ahead logging. Use a read-only connection and a consistent read transaction; copying only the main SQLite file can omit changes held in the WAL. Treat the schema and date encodings as implementation details that require validation against the installed Things version.

The Commands

I set up two slash commands in Claude Code:

/sync reads the database and updates a context snapshot with areas, tags, projects, and open tasks, including dates, notes, and checklist items. Run it before an audit so the analysis reflects changes made through the supported apps.

/analyze scores each category against explicit rules, flags violations, and produces specific recommendations. It works like a linter for the task manager.

The Write Rules

Use supported Things interfaces for changes. The vendor calls its synchronization service Things Cloud; this workflow does not depend on an undocumented backend implementation. Direct database edits bypass supported application behavior. For example, AppleScript can create a task:

tell application "Things3"
    set newToDo to make new to do
    set name of newToDo to "Review engineering report"
    move newToDo to list "Today"
end tell

Or the URL scheme for bulk operations:

open "things:///add?title=Review%20report&when=today&tags=quick"

Audit Findings

A useful audit checks for these structural problems without publishing the underlying tasks.

Tags Without Discriminating Power

Check whether each tag supports a meaningful query. A tag assigned indiscriminately offers little filtering value; measure selectivity inside the private audit instead of publishing task-store statistics.

Missing Real Deadlines

Check whether a task has a genuine due date and whether it is recorded as a deadline. A start date expresses when work becomes available, which is a different purpose.

Duplicate Candidates

Group similar titles and compare context to identify possible duplicate intentions. Similar names alone are not enough to delete an entry; review each candidate through the supported application interface.

Project Structure

Check whether multi-step work would be clearer as a project. Promote an entry only after checking its checklist and intended outcome.

Non-Actionable Task Names

Single-word labels and planning artifacts do not specify a completable action. “Draft the introduction” is an action; “work on the document” is not.

Inbox Not Empty

Check for obsolete test entries and stale captures. An audit should propose removals for review rather than silently deleting them.

The Fix Workflow

This is where it gets interactive. Claude proposes changes, I approve or adjust, and it executes via AppleScript. Step by step:

• Delete junk and duplicates
• Process Inbox
• Create projects for multi-step goals
• Move loose tasks into proper projects
• Rename vague tasks to concrete next actions
• Add deadlines where real dates exist
• Replace the one useless tag with a small set of useful ones
• Fix temporal states (Someday tasks with imminent dates)
• Break oversized tasks into project tasks
• Sync and verify

Git preserves the audit history and code. It does not reverse changes made through AppleScript. Before applying changes, use a separate application-data backup or a verified reversal procedure.

Why Automated Checks Help

A scheduled review remains useful. Automated checks complement it by making structural drift visible and repeatable.

The audit provides four practical capabilities:

Explicit criteria. The checker compares task structure with written rules instead of assuming that a vague title will be understood later.

Pattern detection. Grouping tasks by title makes duplicates visible even when they are spread across Anytime and Someday with different dates.

Traceable findings. Each recommendation can identify the rule and record that triggered it.

Reproducibility. Re-running /sync and /analyze with the same scoring rules produces comparable reports.

The Technical Stack

For anyone who wants to build something similar:

• Claude Code - the CLI tool from Anthropic. Slash commands (/sync, /analyze) are defined as skills in the project configuration.
• SQLite - Things 3's local database. Read-only access via sqlite3.
• AppleScript via osascript - for writing changes back safely through Things 3's API layer.
• Git - version control for the context file and analysis history.

The project structure:

todos/
  CLAUDE.md          # Instructions for Claude Code
  docs/
    guide.md         # Things 3 guide (reference for scoring)
    ctx.md           # Current state + analysis + change log

The key insight is CLAUDE.md. This file tells Claude Code everything it needs: where the database is, how to decode dates, never to write directly to SQLite, how to use AppleScript, and what rules to score against. Every new session picks up these instructions automatically.

The Feedback Loop

Treat the scoring rubric as a prompt for inspection. The useful output is an actionable set of checks, with the underlying task data kept private.

Every maintained system needs feedback. Codebases accumulate technical debt; task systems accumulate vague, duplicated, or poorly structured entries.

The useful intervention is a repeatable check that detects drift and proposes inspectable changes. The user still approves those changes before the supported API applies them.

The result is a practical engineering pattern: read safely, evaluate explicit rules, propose a bounded change, apply it through the supported interface, and verify the result.

Reference: Things: exporting your data (documentation checked 20 September 2026).