The Inbox Method: how tasks flow from capture to code

· bombay

Last updated 17 Feb

bombayinbox-methodproductivitytask-managementtools

Every productivity system has the same failure mode: tasks fall through the cracks. You capture an idea in one place, forget to check it, and three weeks later you rediscover it — stale and out of context.

The inbox method is designed to make that impossible.

One rule: everything is a file in a folder

The entire system rests on a simple convention. Every task is a file. Every project has an inbox folder called .in/. There's also a central inbox at ~/Dropbox/.in/ for tasks that haven't been assigned to a project yet.

~/Dropbox/.in/                    # Central inbox — unrouted tasks
~/Dropbox/MyProject/.in/          # Project inbox — project-specific tasks
~/Dropbox/AnotherProject/.in/     # Every project gets one

Files can be anything: markdown notes, screenshots, voice memo transcripts, PDFs. If it's in .in/, it's a task.

Capture from anywhere

Tasks arrive from multiple sources:

  • Voice — "Siri, remind me to add filters to the dashboard." Bombay syncs the reminder and drops it into the central inbox.
  • Drag and drop — Drag a screenshot or file into a project's .in/ folder. The filename often says enough.
  • Manual creation — Create a markdown file with a title and description. Quick, structured, version-controlled.
  • Email/Slack (coming soon) — Forward a message and it becomes a task file.

The key insight: capture should be frictionless. Don't force people to open an app, fill in fields, or choose a category upfront. Just get it into the inbox. Triage comes later.

Readiness states: the lifecycle of a task

Every task has a readiness state that tracks where it is in the pipeline:

unrefined → auto-refined → refined → checked → closed
State What it means Where it lives
Unrefined Raw capture. Might be vague, might be brilliant. .in/ root
Auto-refined AI has investigated it — added context, identified files, estimated scope. Not yet human-reviewed. .in/auto-refined/
Refined Interactively refined with clear acceptance criteria and a "done when" statement. Ready to implement. .in/refined/
Checked AI has completed the work. Awaiting human review. .in/checked/
Closed Human confirmed it's done. .in/closed/

The folder structure mirrors the state, so you can see at a glance how many tasks are at each stage.

The commands: /check and /do

Two commands drive the workflow:

/check pulls tasks into inboxes. It scans Reminders.app, the central inbox, and other sources. Deterministic filters auto-route tasks to the right project. Anything that doesn't match gets presented with AI confidence ratings so you can route it manually.

/do shows available tasks and lets you pick one. It grades each task by AI confidence (can Claude help with this?), shows readiness state, and suggests batch operations when there are enough refined items.

The flow: /check fills the inboxes. /do empties them.

Inbox filters: deterministic first, AI second

Routing tasks to the right project uses a two-stage approach:

Stage 1: Deterministic filters — Rule-based matching defined in inbox-filters.yaml. Filename patterns, content keywords, frontmatter fields. Fast, predictable, no false positives.

- name: bombay-tasks
  filename: "bombay-*"
  destination: ~/Dropbox/Bombay/Repos/bombay/.in/

Stage 2: AI assessment — For tasks that don't match any rule, AI analyses the content and suggests the best project match. Presented with traffic-light confidence so you can override.

First match wins. Deterministic filters handle the common case; AI catches the rest.

Task graduation

Tasks can grow. A simple one-liner might become a multi-phase project. When that happens, the task graduates from a file to a directory:

.in/redesign-nav.md                    # Started as a file
.in/redesign-nav/                      # Graduated to a directory
.in/redesign-nav/README.md             # Original task becomes the brief
.in/redesign-nav/phase-1-research.md   # Sub-tasks inside
.in/redesign-nav/phase-2-prototype.md

If a task outgrows the current repo entirely, it becomes its own project — a new folder in Dropbox with its own .in/, CLAUDE.md, and .code-workspace.

The graduation path: file → directory → project.

Refinement: from vague to actionable

The refinement step is where most task systems fail. An unrefined task like "make the app faster" is useless until someone breaks it down into specific, testable actions.

Bombay's /refine command does this interactively:

  • Asks clarifying questions about scope and intent
  • Identifies relevant files in the codebase
  • Writes acceptance criteria
  • Adds a "done when" statement — the single most important field

A task isn't refined until you can answer: "What will be different when this is done?"

Auto-refinement (/refine auto) does a first pass without human input — researching the codebase, adding context, estimating scope. It's good enough for straightforward tasks and flags complex ones for interactive refinement.

Why this works

Three properties make the inbox method reliable:

  1. Nothing falls through the cracks. Every task is a file. Files don't disappear. Git tracks history. If something was ever captured, it's findable.

  2. State is visible. The folder structure shows you exactly how many tasks are unrefined, refined, in progress, and done. No dashboards needed — just ls.

  3. Automation is layered. Capture is automated (Siri → Bombay). Routing is automated (filters). Refinement can be automated (auto-refine). Implementation can be automated (auto-work). But every stage has a human checkpoint. Nothing ships without review.

The inbox method isn't a todo app. It's a pipeline — from thought to code, with clear stages and no dropped items.

Have questions or feedback? Find me on LinkedIn or GitHub.

Partially written by a human

Back to blog