Agent Skills
› QuixiAI/Hexis
› inbox-triage
inbox-triage
GitHub辅助用户审查收件箱,制定安全的分类与操作计划,在获得用户明确批准前仅展示建议,不自动执行删除或发送等高风险操作。
Trigger Scenarios
用户要求整理邮件
用户希望减少收件箱负载
Install
npx skills add QuixiAI/Hexis --skill inbox-triage -g -y
SKILL.md
Frontmatter
{
"name": "inbox-triage",
"aliases": [
"inbox",
"triage",
"cleanup",
"archive",
"unsubscribe"
],
"category": "communication",
"contexts": [
"chat"
],
"requires": {
"tools": [
"email_list",
"email_read"
]
},
"bound_tools": [
"email_list",
"email_read",
"email_search",
"search_contacts",
"recall",
"remember",
"gmail_reply",
"gmail_label",
"gmail_spam_triage",
"gmail_delete",
"manage_backlog",
"todoist_create_task",
"asana_create_task"
],
"description": "Review an inbox, propose a safe triage plan, and apply only the email actions the user approves"
}
Inbox Triage
Reduce inbox load while keeping classification, replies, and destructive actions under the user's control. Use email-digest instead when the user wants only a summary or memory ingestion.
Workflow
- Set scope. Confirm the account when more than one is connected, then honor the requested folder, query, date range, or message limit. Default to a small recent inbox sample rather than scanning all mail.
- List before reading. Use message metadata to identify likely high-value threads. Read only enough candidate messages to classify them accurately; do not bulk-read the whole mailbox.
- Classify with reasons. Group messages into: reply needed, task or deadline, waiting/reference, safe archive, likely spam, and uncertain. Include message IDs or unambiguous sender/subject labels so the proposed actions are inspectable.
- Show the plan first. Present counts and the proposed action for each thread. Keep uncertain messages out of action batches and ask about them.
- Apply the chosen batch. Only after the user chooses, apply labels, archive, or mark spam to the exact messages approved. Report successes and failures per message.
- Handle replies separately. Draft a reply, show recipients, subject, and body, then send only after explicit approval. A request to triage is not permission to send.
- Capture tasks deliberately. Suggest tasks for real commitments. Create them in the local backlog, Todoist, or Asana only after the user chooses the destination and content.
Control and Failure Boundaries
- Never permanently delete during ordinary triage. Use trash only after an explicit request; permanent deletion requires unmistakable, message-specific authorization.
- Never infer that a newsletter is spam or that silence means approval. Archive, spam, labels, replies, and tasks are separate choices.
- Respect the configured Gmail memory policy. Do not store email-derived content when it says
forget; ask before storage when it saysask; summarize rather than storing raw bodies. - Gmail connection is not autonomous permission. This skill is chat-only and runs because the user asked now.
- If the account is disconnected or a provider action is unavailable, preserve the proposed plan and give the exact connection or manual next step. Do not discard the useful read-only work.
Version History
- 97f625f Current 2026-08-29 01:31


