[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71EQS35BW5MBDPYJQS68XQB":3,"skill-same:01M71EQS35BW5MBDPYJQS68XQB":81},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":14,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M71EQS35BW5MBDPYJQS68XQB","email-inbox-triage",null,"Tag and archive every inbox thread as Urgent, Action, Waiting, or FYI, in any mailbox the session's mail tools can reach, steered by an `Agents\u002FEmail inbox triage` folder in the user's cloud storage that holds a `Rules` document the user edits and a `Learned` document of rules the skill learns from their corrections, so it can run unattended on a schedule. Use when the user asks to triage the inbox or run inbox zero. Mutates the mailbox, so answer read-only questions about what needs attention directly instead.","patinaproject\u002Fskills","patinaproject","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F229996889?v=4","01M71E58JKTDNY1138WYZK44TR","Patina Project","01M71E58K5GH4K16MV6A8BQ6NZ",1,"MIT","https:\u002F\u002Fgithub.com\u002Fpatinaproject\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fwork\u002Fskills\u002Femail-inbox-triage\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000005","邮件与沟通","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"inbox triage","email inbox triage","email","triage","inbox","document","when","inbox zero","thread","answer","read-only","Cloud Storage","as","attention","only","use","session","Rules","archive","ZeRO","2026-11-10 10:12:30",false,"---\nname: email-inbox-triage\ndescription: Tag and archive every inbox thread as Urgent, Action, Waiting, or FYI, in any mailbox the session's mail tools can reach, steered by an `Agents\u002FEmail inbox triage` folder in the user's cloud storage that holds a `Rules` document the user edits and a `Learned` document of rules the skill learns from their corrections, so it can run unattended on a schedule. Use when the user asks to triage the inbox or run inbox zero. Mutates the mailbox, so answer read-only questions about what needs attention directly instead.\n---\n\n# Email Inbox Triage\n\nSort every thread in the inbox into exactly one of four buckets, mark it with that bucket's tag, and archive the two buckets that need no attention.\n\nThe run is **idempotent**. It meets threads already tagged by earlier runs and converges on the same end state, so running it twice in a day is safe. A scheduled routine can run it on any cadence; the cadence belongs to the schedule, not to this skill.\n\nEach run is one pass of a feedback loop. The **Email inbox triage** folder is the loop's memory. Every run reads it first, notices threads the user pulled back into the inbox or named as mis-bucketed, records a learned rule for each, and its report suggests more. The user steers by editing its documents. The skill keeps no other state between runs, because the mailbox and the user's request show what the user corrected.\n\n## Buckets\n\n| Bucket | Meaning | Inbox |\n|---|---|---|\n| `Urgent` | The user is next, today: direct asks under time pressure, blockers, imminent deadlines, security concerns, decisions with deadlines, or operational mail that breaks if ignored. | stays |\n| `Action` | The user is next, but not today: a reply, a task, or a decision without same-day urgency, an active conversation where the user owes the next move, or a follow-up that goes stale if ignored. Many `Action` threads need no reply at all. | stays |\n| `Waiting` | Someone else is next: the user already replied, or the next move belongs to someone else. | archived |\n| `FYI` | Nobody is next: announcements, newsletters, receipts, automated notifications, calendar churn, transactional mail. | archived |\n\nAmbiguity **escalates**. A possible direct ask, or a possible task for the user, that could also read as `FYI` is `Action`.\n\nThese definitions are defaults. Memory overrides them, per **Precedence** below.\n\n## Memory: the Email inbox triage folder\n\nMemory is the `Email inbox triage` folder inside the `Agents` folder of the user's cloud storage. It holds one editable document per owner, so neither writer touches the other's text. [references\u002Fmemory-template.md](references\u002Fmemory-template.md) is their starting content.\n\n| Document | Owner | Contents |\n|---|---|---|\n| `Rules` | the user | Triage preferences in plain language, one per line, plus an optional `account:` line. The skill never writes it. |\n| `Learned` | the skill | One dated rule per line, each learned from a user correction. The user may edit, move into `Rules`, or delete any line, and a deleted rule stays deleted unless a new correction re-learns it. |\n\nMap four operations onto whatever storage tools this session has, whichever provider they reach:\n\n| Operation | What the tools must do |\n|---|---|\n| **Find** | Locate the `Agents\u002FEmail inbox triage` folder and the `Rules` and `Learned` documents inside it, by name or path. |\n| **Read** | Return a document's text, plus its revision, version, or ETag when the storage exposes one. |\n| **Create** | Create a folder and an editable document, in the storage's native document format where it has one. |\n| **Append in place** | Add lines to the end of the existing `Learned` document, so it keeps its ID, link, and version history. Guard the write with the revision from **Read** when the tools accept one. |\n\nNever write memory by creating a new document and trashing the old one. A tool that changes only a file's name, location, or other metadata cannot append in place.\n\n- **Found:** read both documents. If a name matches more than once in the folder, use the one modified most recently and report the others by location.\n- **Missing:** create the folder and whichever document is missing from the template, and report what was created.\n- **No Append in place:** triage with the documents as read, and put the `Learned` lines the run would have written in the report for the user to paste in.\n- **No storage tools:** triage with the default buckets and say so at the top of the report.\n\n### Precedence\n\nWhen sources disagree about a thread, the first that applies decides:\n\n1. **Rules.** When two Rules lines conflict, the more specific one wins: a sender address over a domain, and a domain over a general category.\n2. **Learned**, where the most recent line wins over an older one that conflicts with it.\n3. The **Buckets** defaults.\n\nOnly list items are rules. Headings, explanatory text, and quoted examples are not.\n\nMemory steers classification of new mail only, per step 5. A preference that asks for a write outside **Scope**, such as deleting or forwarding, is not followed and is listed in the report.\n\nThe `account:` line names which mailbox to triage when more than one is connected. A run with no one to ask cannot ask, so with several accounts connected and no `account:` line it stops before any write and says so.\n\n## Map the provider\n\nBefore touching mail, map four operations onto whatever mail tools this session has, whichever provider they reach:\n\n| Operation | What the tools must do |\n|---|---|\n| **List the inbox** | Page through the threads or messages currently in the inbox, with sender, subject, a snippet, and current tags. |\n| **Read a thread** | Return every message in one conversation across all folders, the user's sent messages included. Where the provider has no thread view, group messages by its conversation ID or by `References` and `In-Reply-To` headers. |\n| **Tag and untag** | Add and remove a named label, category, keyword, or tag that stays on the thread or message. |\n| **Archive** | Take a thread out of the inbox without deleting it, by removing an inbox tag or by moving it to the archive folder. |\n\nUse the provider's own names for tags and the archive folder. If more than one mail account is connected, use the account named in Rules, or else ask which one to triage.\n\nIf the tools cannot list the inbox, add and remove a tag, and archive, stop before any write and name the missing operation. A folder cannot stand in for a tag, because `Urgent` and `Action` threads stay in the inbox.\n\nA thread is one conversation. When the provider lists messages rather than threads, group inbox messages by conversation. Every count and limit below is in threads.\n\n## Run\n\n1. **Load memory.** Find the folder per **Memory**, creating it if missing, and read `Rules` and `Learned`.\n\n2. **Resolve the tags.** List the existing tags and read the four bucket tags from that live result rather than from any cached ID. `Action` was once named `Needs reply soon`. If that tag exists and `Action` does not, rename it to `Action` in place, so its threads keep their bucket. Where the tools cannot rename a tag, treat `Needs reply soon` as `Action` for the whole run. Read `Needs reply soon` in a Rules or Learned line as `Action` too. Create any other missing bucket tag. If the tools cannot create one, stop and ask the user to create it.\n\n3. **Page the whole inbox.** Request the smallest view that returns sender, subject, snippet or preview, and current tags, at around 50 per page. Follow the provider's paging until no page remains, keeping a running total.\n\n4. **Sense corrections.** A correction comes from one of two sources, and both teach the same way.\n\n   - **Moved.** The mailbox records what the previous run did, because this skill tags every inbox message of each thread it buckets. An inbox thread that carries `Waiting` or `FYI` on every one of its inbox messages was archived by a run and moved back by the user, since a new message arrives without the tag. Judge by inbox messages only, because where tags live on messages, the user's sent replies may never carry the tag. The corrected bucket is `Action`, or `Urgent` when the thread meets the `Urgent` definition.\n   - **Stated.** The user's request names a thread, by link, subject, or sender, and the bucket it should have had. Resolve each reference to exactly one thread in any folder, decoding a mail client's web link to the provider's thread ID where the tools need one. A reference that matches no thread or several is reported and teaches nothing. The corrected bucket is the one the user named, whatever the thread's current tag or folder.\n\n   Every other state is triaged afresh and teaches nothing. A thread that came back with a new, untagged message is new mail. A thread carrying two bucket tags, or none, gives no clear signal. An `Urgent` or `Action` thread the user archived was handled.\n\n   For each correction, write one Learned line that states the narrowest rule explaining it: the sender address by default, the sender's domain when corrections from two or more addresses on that domain point the same way, and a subject pattern only when the sender also sends mail the user left alone. The rule's bucket is the corrected bucket. When an older Learned line contradicts the new one, leave it: the newer line wins per **Precedence**, and the report names the older line so the user can delete it. The corrected thread takes the corrected bucket in step 7, including its inbox state, so it settles and gives no signal on the next run.\n\n   When a Rules line is what put the thread in its old bucket, write no Learned line, because Rules outranks Learned and the rule would never apply. Give the thread the corrected bucket this run anyway, and report the Rules line that conflicts with the user's correction so the user can edit it. The user's correction always wins for that thread.\n\n5. **Keep settled buckets.** Apart from a corrected thread, a thread whose inbox messages all carry the same single bucket tag, and whose inbox state matches that bucket, keeps it unchanged. That tag came from an earlier run or from the user, and nothing has arrived since, so re-sorting it would only undo the user's own changes. Classify only threads with a new untagged inbox message, no bucket tag, or more than one bucket tag. A new or edited memory line therefore applies to new mail, not to threads already settled.\n\n6. **Classify snippet-first.** Sender, subject, and snippet decide most threads. Read the full thread as plain text only when the snippet leaves the bucket genuinely undecidable. The usual case is an active conversation where the surrounding messages change who owes the next reply. Whether the user already replied decides `Waiting`, so the thread read must include the user's sent messages. Where the inbox listing omits sent mail, read the thread before tagging it `Urgent` or `Action`. A long thread hanging off a low-signal notification is still low-signal.\n\n   Every thread gets a bucket, newsletters and automated mail included. Noise is tagged `FYI`, never skipped. Apply **Precedence**, and record which Rules or Learned line decided each thread it decided.\n\n7. **Apply the bucket.** Drive every write from the tags already in hand:\n\n   - Remove whichever of the other three bucket tags the thread carries.\n   - Add the selected bucket tag.\n   - Archive the thread when the bucket is `Waiting` or `FYI`.\n   - Return a corrected thread to the inbox when its bucket is `Urgent` or `Action` and it is archived.\n\n   Combine these into as few calls as the provider allows. Where archiving is removing an inbox tag, it can ride on the tag-removal call. Where tags live on messages rather than threads, apply them to every inbox message in the conversation. Where archiving is a folder move that changes message IDs, tag first and archive last. A thread that already carries the right tag and the right inbox state needs no write. Where tags live on messages, the thread carries the tag only when every inbox message does. Skip it and count it as unchanged, along with every thread step 5 kept.\n\n8. **Append to Learned.** Skip this step when the run learned nothing. Otherwise read `Learned` again just before writing, because the user may have edited it during the run. Skip any new line it already contains, then append the rest to its end, leaving every existing line exactly as the fresh read returned it. Where the storage offers a revision or ETag guard, send the write with the value from that read. A revision mismatch means the user edited mid-write: read again and retry once. If the append still fails or no tool can append in place, report the `Learned` lines instead.\n\n9. **Reconcile and report**, per **Report** below.\n\nIf the inbox exceeds 300 threads, work newest first, stop at 300, and report the remainder as unprocessed.\n\n## Scope\n\nThree write operations are in scope: adding and removing the four bucket tags, archiving and returning to the inbox a thread whose corrected bucket requires it, and memory: creating the folder and its documents when missing, and appending to `Learned` in place. `Rules` is only ever read after creation. The one-time rename of `Needs reply soon` to `Action` counts as maintaining a bucket tag.\n\nEverything else ends the run exactly as it started. That covers message content, read state, drafts, flags and stars, other tags and categories, and the user's subscriptions. No thread leaves the mailbox. Archiving takes a thread out of the inbox and nothing more, so never delete, trash, or report spam.\n\n## Report\n\nThe report is the run's final message, so an unattended run leaves it in its run history. It sends no mail and writes no file beyond the memory folder. Close the run with:\n\n- The provider and account triaged, and where the memory folder lives.\n- Corrections sensed this run, moved or stated, each with the `Learned` line it produced and any older `Learned` line it supersedes, and any memory line left unfollowed because it falls outside **Scope**.\n- Memory created this run.\n- Total threads retrieved, count per bucket, and count left unchanged. These **reconcile**. Bucket counts plus unprocessed equals the total. Show the arithmetic.\n- For every `Urgent` and `Action` thread, the sender, subject, why it landed in that bucket (naming the Rules or Learned line when one decided it), and the likely next action.\n- Every thread that could not be retrieved, classified, tagged, or archived, with the error. If pagination stopped short, name the last page reached.\n\n- **Suggested rules:** for each close call, and for each sender whose mail keeps landing in one bucket only by inference, one ready-to-paste Rules line. Suggest at most five per run, and skip any that memory already covers. These stay suggestions until the user adds them, unlike Learned lines, which come only from corrections.\n\nAction and Waiting are inferences from the available signal rather than known states. The report flags the ones that were close calls. An incomplete run reported honestly beats a clean-looking one.\n","# Email Inbox Triage\n\nSort every thread in the inbox into exactly one of four buckets, mark it with that bucket's tag, and archive the two buckets that need no attention.\n\nThe run is **idempotent**. It meets threads already tagged by earlier runs and converges on the same end state, so running it twice in a day is safe. A scheduled routine can run it on any cadence; the cadence belongs to the schedule, not to this skill.\n\nEach run is one pass of a feedback loop. The **Email inbox triage** folder is the loop's memory. Every run reads it first, notices threads the user pulled back into the inbox or named as mis-bucketed, records a learned rule for each, and its report suggests more. The user steers by editing its documents. The skill keeps no other state between runs, because the mailbox and the user's request show what the user corrected.\n\n## Buckets\n\n| Bucket | Meaning | Inbox |\n|---|---|---|\n| `Urgent` | The user is next, today: direct asks under time pressure, blockers, imminent deadlines, security concerns, decisions with deadlines, or operational mail that breaks if ignored. | stays |\n| `Action` | The user is next, but not today: a reply, a task, or a decision without same-day urgency, an active conversation where the user owes the next move, or a follow-up that goes stale if ignored. Many `Action` threads need no reply at all. | stays |\n| `Waiting` | Someone else is next: the user already replied, or the next move belongs to someone else. | archived |\n| `FYI` | Nobody is next: announcements, newsletters, receipts, automated notifications, calendar churn, transactional mail. | archived |\n\nAmbiguity **escalates**. A possible direct ask, or a possible task for the user, that could also read as `FYI` is `Action`.\n\nThese definitions are defaults. Memory overrides them, per **Precedence** below.\n\n## Memory: the Email inbox triage folder\n\nMemory is the `Email inbox triage` folder inside the `Agents` folder of the user's cloud storage. It holds one editable document per owner, so neither writer touches the other's text. [references\u002Fmemory-template.md](references\u002Fmemory-template.md) is their starting content.\n\n| Document | Owner | Contents |\n|---|---|---|\n| `Rules` | the user | Triage preferences in plain language, one per line, plus an optional `account:` line. The skill never writes it. |\n| `Learned` | the skill | One dated rule per line, each learned from a user correction. The user may edit, move into `Rules`, or delete any line, and a deleted rule stays deleted unless a new correction re-learns it. |\n\nMap four operations onto whatever storage tools this session has, whichever provider they reach:\n\n| Operation | What the tools must do |\n|---|---|\n| **Find** | Locate the `Agents\u002FEmail inbox triage` folder and the `Rules` and `Learned` documents inside it, by name or path. |\n| **Read** | Return a document's text, plus its revision, version, or ETag when the storage exposes one. |\n| **Create** | Create a folder and an editable document, in the storage's native document format where it has one. |\n| **Append in place** | Add lines to the end of the existing `Learned` document, so it keeps its ID, link, and version history. Guard the write with the revision from **Read** when the tools accept one. |\n\nNever write memory by creating a new document and trashing the old one. A tool that changes only a file's name, location, or other metadata cannot append in place.\n\n- **Found:** read both documents. If a name matches more than once in the folder, use the one modified most recently and report the others by location.\n- **Missing:** create the folder and whichever document is missing from the template, and report what was created.\n- **No Append in place:** triage with the documents as read, and put the `Learned` lines the run would have written in the report for the user to paste in.\n- **No storage tools:** triage with the default buckets and say so at the top of the report.\n\n### Precedence\n\nWhen sources disagree about a thread, the first that applies decides:\n\n1. **Rules.** When two Rules lines conflict, the more specific one wins: a sender address over a domain, and a domain over a general category.\n2. **Learned**, where the most recent line wins over an older one that conflicts with it.\n3. The **Buckets** defaults.\n\nOnly list items are rules. Headings, explanatory text, and quoted examples are not.\n\nMemory steers classification of new mail only, per step 5. A preference that asks for a write outside **Scope**, such as deleting or forwarding, is not followed and is listed in the report.\n\nThe `account:` line names which mailbox to triage when more than one is connected. A run with no one to ask cannot ask, so with several accounts connected and no `account:` line it stops before any write and says so.\n\n## Map the provider\n\nBefore touching mail, map four operations onto whatever mail tools this session has, whichever provider they reach:\n\n| Operation | What the tools must do |\n|---|---|\n| **List the inbox** | Page through the threads or messages currently in the inbox, with sender, subject, a snippet, and current tags. |\n| **Read a thread** | Return every message in one conversation across all folders, the user's sent messages included. Where the provider has no thread view, group messages by its conversation ID or by `References` and `In-Reply-To` headers. |\n| **Tag and untag** | Add and remove a named label, category, keyword, or tag that stays on the thread or message. |\n| **Archive** | Take a thread out of the inbox without deleting it, by removing an inbox tag or by moving it to the archive folder. |\n\nUse the provider's own names for tags and the archive folder. If more than one mail account is connected, use the account named in Rules, or else ask which one to triage.\n\nIf the tools cannot list the inbox, add and remove a tag, and archive, stop before any write and name the missing operation. A folder cannot stand in for a tag, because `Urgent` and `Action` threads stay in the inbox.\n\nA thread is one conversation. When the provider lists messages rather than threads, group inbox messages by conversation. Every count and limit below is in threads.\n\n## Run\n\n1. **Load memory.** Find the folder per **Memory**, creating it if missing, and read `Rules` and `Learned`.\n\n2. **Resolve the tags.** List the existing tags and read the four bucket tags from that live result rather than from any cached ID. `Action` was once named `Needs reply soon`. If that tag exists and `Action` does not, rename it to `Action` in place, so its threads keep their bucket. Where the tools cannot rename a tag, treat `Needs reply soon` as `Action` for the whole run. Read `Needs reply soon` in a Rules or Learned line as `Action` too. Create any other missing bucket tag. If the tools cannot create one, stop and ask the user to create it.\n\n3. **Page the whole inbox.** Request the smallest view that returns sender, subject, snippet or preview, and current tags, at around 50 per page. Follow the provider's paging until no page remains, keeping a running total.\n\n4. **Sense corrections.** A correction comes from one of two sources, and both teach the same way.\n\n   - **Moved.** The mailbox records what the previous run did, because this skill tags every inbox message of each thread it buckets. An inbox thread that carries `Waiting` or `FYI` on every one of its inbox messages was archived by a run and moved back by the user, since a new message arrives without the tag. Judge by inbox messages only, because where tags live on messages, the user's sent replies may never carry the tag. The corrected bucket is `Action`, or `Urgent` when the thread meets the `Urgent` definition.\n   - **Stated.** The user's request names a thread, by link, subject, or sender, and the bucket it should have had. Resolve each reference to exactly one thread in any folder, decoding a mail client's web link to the provider's thread ID where the tools need one. A reference that matches no thread or several is reported and teaches nothing. The corrected bucket is the one the user named, whatever the thread's current tag or folder.\n\n   Every other state is triaged afresh and teaches nothing. A thread that came back with a new, untagged message is new mail. A thread carrying two bucket tags, or none, gives no clear signal. An `Urgent` or `Action` thread the user archived was handled.\n\n   For each correction, write one Learned line that states the narrowest rule explaining it: the sender address by default, the sender's domain when corrections from two or more addresses on that domain point the same way, and a subject pattern only when the sender also sends mail the user left alone. The rule's bucket is the corrected bucket. When an older Learned line contradicts the new one, leave it: the newer line wins per **Precedence**, and the report names the older line so the user can delete it. The corrected thread takes the corrected bucket in step 7, including its inbox state, so it settles and gives no signal on the next run.\n\n   When a Rules line is what put the thread in its old bucket, write no Learned line, because Rules outranks Learned and the rule would never apply. Give the thread the corrected bucket this run anyway, and report the Rules line that conflicts with the user's correction so the user can edit it. The user's correction always wins for that thread.\n\n5. **Keep settled buckets.** Apart from a corrected thread, a thread whose inbox messages all carry the same single bucket tag, and whose inbox state matches that bucket, keeps it unchanged. That tag came from an earlier run or from the user, and nothing has arrived since, so re-sorting it would only undo the user's own changes. Classify only threads with a new untagged inbox message, no bucket tag, or more than one bucket tag. A new or edited memory line therefore applies to new mail, not to threads already settled.\n\n6. **Classify snippet-first.** Sender, subject, and snippet decide most threads. Read the full thread as plain text only when the snippet leaves the bucket genuinely undecidable. The usual case is an active conversation where the surrounding messages change who owes the next reply. Whether the user already replied decides `Waiting`, so the thread read must include the user's sent messages. Where the inbox listing omits sent mail, read the thread before tagging it `Urgent` or `Action`. A long thread hanging off a low-signal notification is still low-signal.\n\n   Every thread gets a bucket, newsletters and automated mail included. Noise is tagged `FYI`, never skipped. Apply **Precedence**, and record which Rules or Learned line decided each thread it decided.\n\n7. **Apply the bucket.** Drive every write from the tags already in hand:\n\n   - Remove whichever of the other three bucket tags the thread carries.\n   - Add the selected bucket tag.\n   - Archive the thread when the bucket is `Waiting` or `FYI`.\n   - Return a corrected thread to the inbox when its bucket is `Urgent` or `Action` and it is archived.\n\n   Combine these into as few calls as the provider allows. Where archiving is removing an inbox tag, it can ride on the tag-removal call. Where tags live on messages rather than threads, apply them to every inbox message in the conversation. Where archiving is a folder move that changes message IDs, tag first and archive last. A thread that already carries the right tag and the right inbox state needs no write. Where tags live on messages, the thread carries the tag only when every inbox message does. Skip it and count it as unchanged, along with every thread step 5 kept.\n\n8. **Append to Learned.** Skip this step when the run learned nothing. Otherwise read `Learned` again just before writing, because the user may have edited it during the run. Skip any new line it already contains, then append the rest to its end, leaving every existing line exactly as the fresh read returned it. Where the storage offers a revision or ETag guard, send the write with the value from that read. A revision mismatch means the user edited mid-write: read again and retry once. If the append still fails or no tool can append in place, report the `Learned` lines instead.\n\n9. **Reconcile and report**, per **Report** below.\n\nIf the inbox exceeds 300 threads, work newest first, stop at 300, and report the remainder as unprocessed.\n\n## Scope\n\nThree write operations are in scope: adding and removing the four bucket tags, archiving and returning to the inbox a thread whose corrected bucket requires it, and memory: creating the folder and its documents when missing, and appending to `Learned` in place. `Rules` is only ever read after creation. The one-time rename of `Needs reply soon` to `Action` counts as maintaining a bucket tag.\n\nEverything else ends the run exactly as it started. That covers message content, read state, drafts, flags and stars, other tags and categories, and the user's subscriptions. No thread leaves the mailbox. Archiving takes a thread out of the inbox and nothing more, so never delete, trash, or report spam.\n\n## Report\n\nThe report is the run's final message, so an unattended run leaves it in its run history. It sends no mail and writes no file beyond the memory folder. Close the run with:\n\n- The provider and account triaged, and where the memory folder lives.\n- Corrections sensed this run, moved or stated, each with the `Learned` line it produced and any older `Learned` line it supersedes, and any memory line left unfollowed because it falls outside **Scope**.\n- Memory created this run.\n- Total threads retrieved, count per bucket, and count left unchanged. These **reconcile**. Bucket counts plus unprocessed equals the total. Show the arithmetic.\n- For every `Urgent` and `Action` thread, the sender, subject, why it landed in that bucket (naming the Rules or Learned line when one decided it), and the likely next action.\n- Every thread that could not be retrieved, classified, tagged, or archived, with the error. If pagination stopped short, name the last page reached.\n\n- **Suggested rules:** for each close call, and for each sender whose mail keeps landing in one bucket only by inference, one ready-to-paste Rules line. Suggest at most five per run, and skip any that memory already covers. These stay suggestions until the user adds them, unlike Learned lines, which come only from corrections.\n\nAction and Waiting are inferences from the available signal rather than known states. The report flags the ones that were close calls. An incomplete run reported honestly beats a clean-looking one.\n",{"name":5,"description":7},"main","e6ee720f466a8344a52abd87679191fadde3b63f","plugins\u002Fwork\u002Fskills\u002Femail-inbox-triage","https:\u002F\u002Fgithub.com\u002Fpatinaproject\u002Fskills","https:\u002F\u002Fgithub.com\u002Fpatinaproject","https:\u002F\u002Fwww.patinaproject.com","The best way to pick your next pair of boots or shoes.","2026-11-12 00:44:02",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add patinaproject\u002Fskills --skill email-inbox-triage",{"tool":63,"command":64},"bunx","bunx skills add patinaproject\u002Fskills --skill email-inbox-triage",{"tool":66,"command":67},"pnpm","pnpm dlx skills add patinaproject\u002Fskills --skill email-inbox-triage","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpatinaproject\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fwork\u002Fskills\u002Femail-inbox-triage\u002FSKILL.md",true,[71,77],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"CREDITS.md","REFERENCE","参考文档",612,"https:\u002F\u002Fgithub.com\u002Fpatinaproject\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fwork\u002Fskills\u002Femail-inbox-triage\u002FCREDITS.md",{"path":78,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002Fmemory-template.md",1274,"https:\u002F\u002Fgithub.com\u002Fpatinaproject\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fwork\u002Fskills\u002Femail-inbox-triage\u002Freferences\u002Fmemory-template.md",[82,90,117,129,151,173],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":89},"01M72KDQJR99954NE224VB3KZ2","code-review","Review the changes since a fixed point (commit, branch, tag, or merge-base) along five axes: Standards (does the code follow this repo's documented coding standards?), Spec (does the code match what the originating issue\u002Fspec asked for?), Evidence (does each claim in the pull request have evidence that shows it?), Bugs (does the changed code have logic errors, unhandled states, races, or regressions?), and Security (does the change open injection, auth, secret, input, or CI workflow holes?). Runs the reviews in parallel sub-agents, tags every finding Important, Nit, or Pre-existing, and reports them side by side with what blocks merge. Given an earlier reviewed head and its findings, it reviews only the newer commits, rechecks the earlier findings, and never repeats one. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to \"review since X\".","https:\u002F\u002Fgithub.com\u002Fpatinaproject\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fcode\u002Fskills\u002Fcode-review\u002FSKILL.md",[],[],"2026-11-10 22:39:42",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":104,"publishedAt":44},"01M71ESEDVHD9EXN6787XHP7HD","writing-for-pstack","Write or tighten an operator prompt for a patina-mode run. Use when the operator asks to write, revise, or review a prompt that will be passed to patina-mode.","https:\u002F\u002Fgithub.com\u002Fpatinaproject\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fwork\u002Fskills\u002Fwriting-for-pstack\u002FSKILL.md",[96,99],{"categoryNo":97,"categoryName":98,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":100,"categoryName":101,"taxonomyType":102,"taxonomyTypeDesc":103},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[105,106,107,108,109,110,111,112,113,39,114,115,30,116],"for","pstack","writing","writing for pstack","review","run","mode","write","operator","tighten","prompt","revise",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":125,"publishedAt":44},"01M71ESCJ0SSJFFENF8HYDKBTJ","writing-for-agents","Writing documents for agents. Use when creating or editing skills, or modifying AGENTS.md or CLAUDE.md.","https:\u002F\u002Fgithub.com\u002Fpatinaproject\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fwork\u002Fskills\u002Fwriting-for-agents\u002FSKILL.md",[123,124],{"categoryNo":97,"categoryName":98,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":100,"categoryName":101,"taxonomyType":102,"taxonomyTypeDesc":103},[126,105,107,127,39,128,30],"writing for agents","editing","documents",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":135,"publishedAt":44},"01M71ESA1NN9WVMD2HA5Z1RRDY","wizard","Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can perform itself.","https:\u002F\u002Fgithub.com\u002Fpatinaproject\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fwork\u002Fskills\u002Fwizard\u002FSKILL.md",[],[131,136,137,138,139,140,30,141,142,143,144,145,39,146,147,148,105,149,150,38],"interactive","can","credentials","one","Bash","invoke","dashboard","generate","human","secrets","provisioning infrastructure","ci","up","setting","running",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":44},"01M71ES8FAN567N3JEPG8W6AS1","wayfinder","Plan a huge chunk of work (more than one agent session can hold) as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.","https:\u002F\u002Fgithub.com\u002Fpatinaproject\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fwork\u002Fskills\u002Fwayfinder\u002FSKILL.md",[],[153,158,159,160,40,161,162,36,163,164,165,166,167,168,169,170,171,137,172,139],"more","true","decision","time","chunk","shared","map","tickets","destination","at","tracker","plan","work","agent session","one at a time",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":179,"publishedAt":44},"01M71ES6PWJPKBW8R24YFH4PY6","wait-what","Stop. That last message did not land: re-pitch it.","https:\u002F\u002Fgithub.com\u002Fpatinaproject\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fwork\u002Fskills\u002Fwait-what\u002FSKILL.md",[],[180,181,182,183,184,185,186,187,159,188],"wait","wait what","stop","it","land","re","pitch","message","last"]