Archive (message → mail like it skips the inbox)

Shorthand for /filter auto-archive based on sender + subject. Input is one message: a screenshot, its sender and subject typed out, or both. Output is a filters.js rule that archives mail from that sender whose subject marks it as the same kind, written and synced by the filter skill.

This skill settles what a bare "archive this" leaves open — the action, the scope, the key — so the usual run asks nothing. Everything else belongs to filter: the session-title prefixes, where the spec lives, the dedupe, the sync and the report.

Examples in this file are invented; the privacy rule in AGENTS.md applies to it.

Procedure

1. Hand off to filter

Invoke the filter skill (Skill tool) with the args auto-archive based on sender + subject, followed by anything the user typed, and follow it end to end. The steps below amend the filter steps they name; where they are silent, filter stands.

2. Settle the open choices (filter steps 2–3)

Unless the user's words say otherwise:

• Archive only. The mail skips the inbox; no label is added and nothing is trashed.
• Mail like this one. "These" means the message's own kind, not everything its sender sends.
• Sender and subject together, even when the sender sends nothing else today: the subject keeps a later security alert from the same address in the inbox.

3. Find the message's kind (filter steps 1–2)

If the screenshot shows several messages and nothing singles one out — an open message, a selected row, a typed sender — ask which, with 🚙 set first.

Survey the sender with search_threads on from:<address> (the domain, when the local part rotates), pageSize 50, paging back until a full page adds no new kind — kinds the sender has stopped sending do not matter. The message's own kind is the family; the other kinds are the "sender's other mail" that filter step 2's fragment must not match, and they keep going where they go today.

Family vs. the sender's other kinds	Rule
A fragment the whole family has and no other kind does	sender + that fragment — the usual case
No such fragment, but a List-Id only the family has	sender + List-Id
No such fragment, and the sender sends no other kind	sender alone — say so in the report
No such fragment, and other kinds exist	not expressible — say so and ask, with 🚙 set

Reuse the from the spec already has for this sender, if it has one (filter step 4's grep finds it), so the sender's conditions differ only by subject.

4. Keep every label (filter step 4)

Archiving adds to what the mail gets today; it never swaps a label out. An entry that already labels this mail keeps doing so:

• A broader condition (*@acme.com → Newsletters) stays as it is, and the archive condition goes in an archive-only entry. Gmail stacks the two filters, and in Proton a label never conflicts with a folder.
• The same condition moves to an entry with that label plus archive — never to an archive-only entry, which would drop the label.

An entry that already archives this mail makes the request a duplicate. If the screenshot shows the message in the inbox anyway, that is the match skill's step 4 — mail older than the filter, an unsynced filter, or a gmail NO MATCH — not a reason for a second rule.

5. Repeat the account test on the rendered rule (filter step 5)

After the edit, repeat filter step 2's account test on the gmail term the matcher prints for the new condition, back to the oldest date step 3 surveyed (after:). Every thread it returns must be the family; anything else is mail the filter would archive by mistake — lengthen the fragment and check again before syncing. The rendered term is what the filter will actually run: the glob as the renderer translated it, and every address a widened from reaches.

6. Report (filter step 7)

Add one line naming the sender's other kinds — the mail this rule leaves where it was. The message itself stays where it is too: the rule is for mail still to come.