Porter — the project-inbox intake operator

Porter reads an inbound email and decides what it becomes. A task, a decision to drive, a risk to watch, a record of a meeting, a deliverable awaiting sign-off — or nothing at all. Then it produces the artifact: a ready-to-save project card and, when a reply is owed, a drafted response. You come back to find the inbox already triaged and the work already captured — not a pile of questions waiting for you.

Porter is an operator, not a chatbot. It does not ask you what to do with each email. It applies an explicit decision rubric, makes the call, produces the output, and flags only the few items that genuinely need your judgement. The whole point is that the volume disappears and only the decisions that are truly yours land on your desk.

Built for project managers, consultants, and technical leads who run several projects at once and whose commitments are born in email. Porter turns the inbox into structured project cards instead of a second to-do list you mentally reconcile.

---

▶ Watch the 2-minute walkthrough (2:00)

What it does, in one breath

inbound email  ──►  Porter  ──►  one decision  +  the artifact
                                  ┌─ CARD     → a proposed project card (JSON + body; action-cards also get a log line)
                                  ├─ UPDATE   → an update to an existing card
                                  ├─ REPLY    → a drafted reply, no tracking needed
                                  ├─ FILE     → informative, filed, no action
                                  ├─ DECLINE  → a gracious "no", drafted
                                  ├─ NOISE    → vendor blast / newsletter, filtered
                                  └─ FLAG     → handed to you, with Porter's best-guess proposal attached

Every decision carries a confidence level, the rule that fired, and any gaps Porter refused to guess (an unknown owner is written as owner: ?, never invented). That trace is what makes the output trustworthy enough to act on without re-reading the original email.

Porter works the mailbox in two passes: an inbound pass over the inbox (mail that opens and advances work) and an outbound pass over the Sent folder (mail that closes it). When you've sent the thing a card was tracking, Porter proposes closing that card — so the dashboard never shows as open what you've already delivered. It proposes; it never marks something done that the sent mail doesn't actually deliver.

Use it in 5 minutes

1. Drop this folder into a Claude project (Project Knowledge → upload folder).
2. Edit config.md — your initials, your active projects (a few keywords each), your reply tone, and the two thresholds. Sensible defaults are pre-filled; a first pass takes two minutes.
3. Open a chat and paste one or more emails (or say "process my inbox" if you've wired an email MCP — see config). Porter returns a decision and the artifact for each, then a batch digest: what it carded, what it drafted, and the short list of things flagged for you.

Want to see it work before touching your own data? Paste the three emails in reference/sample-inbox.md and compare Porter's output to the worked decisions in examples.md.

What you come back to (it runs standalone)

Porter doesn't just answer in the chat and forget. Every run it writes to disk, so the work survives the conversation and you can let it run unattended:

• dashboard.html — a self-contained two-tab dashboard you open in a browser. Tab 1: every open action, urgent and late first, by project, with owner-gaps shown as ? — assign. Tab 2: messages to read, per day — the informative mail Porter filed (not noise, not action), grouped by date so you can catch up without reopening the inbox.
• runs/<date>.md — the run digest, written to a file (not just printed), so "what did Porter do this morning" is re-readable.
• mail-log.jsonl — an append-only line per email it ever processed: the durable, queryable record of every decision.

The cards (JSON) are the source of truth; the dashboard and logs are derived and rebuildable. The dashboard is generated by tools/build-dashboard.ps1 (PowerShell 7+), or written directly by Porter when no runtime is available — see reference/outputs.md.

See it now: a fully worked example ships in sample-workspace/ — open sample-workspace/dashboard.html in a browser to see both tabs populated (6 open actions across two projects, a per-day reading list), and sample-workspace/runs/latest.md for the matching written digest.

The folder

porter-intake-operator/
├── README.md                     ← you are here
├── identity.md                   ← who Porter is and the workflow it owns
├── config.md                     ← the settings you fill in (projects, tone, thresholds)
├── rules.md                      ← THE decision logic: outcomes, card-type rubric, edge cases, escalation
├── examples.md                   ← worked decisions, including the hard edge cases
├── reference/
    ├── card-types.md             ← the routable card types + the "which type is this?" disambiguation
    ├── scoring-rubric.md         ← the deterministic gates (noise / action-vs-FYI / new-vs-update / confidence)
    ├── response-templates.md     ← decline / acknowledge / nudge / escalation-summary drafts
    ├── output-format.md          ← exact shape of a per-email decision and the batch digest
    ├── corrections.md            ← the learning ledger: your overrides become rules
    ├── outputs.md                ← what Porter writes to disk each run (log, digests, dashboard)
    ├── email-mcp.md              ← optional: wiring your mailbox in (read + draft, never send)
    ├── sample-inbox.md           ← three emails to test it on right now
    └── schemas/                  ← the bundled JSON Schemas for every card type (so cards validate standalone)
└── tools/
    └── build-dashboard.ps1       ← regenerates the two-tab dashboard from your cards + mail log

Why it can be trusted to act, not just answer

The four things this operator is built to get right — the same four the work is judged on:

1. It decides. Default behaviour is decide and produce the artifact. Kicking a question back to you is the exception, bounded by explicit stop-conditions in rules.md — not the reflex.
2. The edge cases are handled, not hand-waved. "We've decided on the phased approach" is a decision record, not a task. "The vendor missed the date" is no longer a risk — it's an issue. An approval of your own work is not FYI — it unblocks the next step. These are written down as rules, with worked examples.
3. The output is verifiable. Every decision shows its confidence, the rule that fired, and the gaps Porter would not fill by guessing. Low confidence routes to a review flag with a full summary — Porter never quietly downgrades an uncertain call into a confident-looking card.
4. It learns from you. When you override a call, that correction is appended to reference/corrections.md and, when it generalises, becomes a new rule Porter reads before classifying. The rubric is living, not frozen.

Where the cards go

Porter produces cards in the Astrid card format — durable JSON files you own, in a folder, no database. Porter is the intake half: it gets work into the system from your inbox. You can use Porter standalone, or alongside Astrid, which reads the same cards to give you a live portfolio dashboard.

It works fully without Astrid. The complete JSON Schemas for every card type are bundled in reference/schemas/, and reference/card-types.md is the human-readable guide to them — so Porter's cards are valid, self-describing, and usable on their own. Nothing about the intake decision, or the cards it produces, depends on the Astrid dashboard existing; Astrid is what you add later if you want a portfolio view of the cards Porter creates.

Companion: the Astrid card system

Porter writes into the card model published as Astrid (the operational project assistant) and Miles (the meeting reflection coach). Astrid's own documentation names an email→card bridge as "the highest-leverage thing you can add" — Porter is that bridge, expressed as a folder-based operator. The three compose without integration work because they share one data model: the same project.json, the same cards/, the same meetings/.

License

MIT.