mail-pimp

Active router for ALL physical mail requests — classifies and routes to the correct mail skill (lob for sending, postscanmail for receiving) before any response. Use when anything involves physical mail, certified letters, virtual mailboxes, or mail tracking.

Model	Source
sonnet	pack: mail

Full Reference

If the request involves physical mail, certified mail, USPS, virtual mailbox, mail scanning, mail tracking, address verification, or any mail service in ANY way — you MUST route through this skill FIRST.

This is not optional. This is not negotiable. You cannot skip this.

Mail Pimp

The orchestration layer for all physical mail expertise. Not documentation — an active router. Every mail request flows through this routing table before any response.

Mandatory Announcement — FIRST OUTPUT before anything else:

┏━ 📬 mail-pimp ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ [one-line description of request/routing]       ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

No exceptions. Box frame first, then route.

Quick Context

The mail pack covers two distinct mail flows: outbound programmatic mail via Lob (letters, postcards, certified mail, address verification) and inbound virtual mailbox management via PostScanMail (receiving, scanning, forwarding, auto-rules). Different APIs, different use cases, one router.

Routing Table

Classify the request. Invoke the matching skill. No response before invocation.

Request Pattern	Skill
Send letter, postcard, certified mail, print and mail	`lob`
Lob API, lob SDK, lob package	`lob`
Track delivery, delivery status, USPS tracking	`lob`
Address verification, CASS certification, USPS address	`lob`
Virtual mailbox, scan mail, check mailbox, PostScanMail	`postscanmail`
Auto-scan rules, mail rules, mail forwarding	`postscanmail`
CMRA, commercial mail receiving agent	`postscanmail`
”Which mail service?”, compare Lob vs PostScanMail	Decision matrix below

Decision Matrix

Signal	Route To
Sending physical mail programmatically	`lob`
Receiving or scanning incoming mail	`postscanmail`
Already using Lob API or lob package in project	`lob`
Already using PostScanMail or CMRA	`postscanmail`
Need both send + receive	Route based on the current action

State Detection

Before routing, check project state:

stack.json → read mail key
package.json deps → detect lob package
.env → check for LOB_API_KEY, LOB_ENVIRONMENT, POSTSCAN_API_KEY

State	Action
`lob` in deps or env	Route to `lob` for sending/verification requests
`POSTSCAN_API_KEY` in env	Route to `postscanmail` for receiving requests
Nothing detected	Use decision matrix, then recommend based on intent

Shortcut Rules

Sending certified mail → lob, no discussion
Checking virtual mailbox → postscanmail, no discussion
Address verification → lob, no discussion
Mail scanning/auto-rules → postscanmail, no discussion

Chaining Patterns

User Says	Chain
”Set up full mail stack”	`lob` (outbound) → `postscanmail` (inbound)
“Mail merge campaign”	`lob` only
”Manage incoming mail”	`postscanmail` only
”Verify addresses then send”	`lob` (both steps)

Hard Rules

Never respond about physical mail before invoking the target skill
No summarizing, planning to invoke, or explaining what you’re about to do
If unclear (send vs receive), ask ONE clarifying question, then route
The skill’s content has the verified facts — always defer to it
Never conflate Lob (outbound API) with PostScanMail (inbound CMRA) — different products, different workflows