triage-inbox

triage-inbox

Tell the user (or JobClaw) what each email is and what to do about it. Hard rules: ../_shared/RULES.md. All enums, the decision table, the extraction-fields shape, and the suggested-action vocabulary live in ../../knowledge/status/taxonomy.md — read it first; don't re-derive.

Inputs

Single mode

• A pasted email: from, subject, body, optional thread (prior messages), optional date.

Batch mode

• --in inbox/incoming.json:

  { "emails": [ { "email_id": "...", "from": "...", "subject": "...", "body": "...", "date": "YYYY-MM-DD", "thread": ["..."] } ] }
  

If the input has only a body (no from/subject), warn but proceed — class confidence will be low unless body is decisive.

Method

1. Read the taxonomy. ../../knowledge/status/taxonomy.md — the 10 classes, the extraction-fields contract, the suggested-action vocab.

2. For each email, classify into exactly one class. Mutually exclusive; pick the most specific match (e.g., a "we received your application" auto-message is info, not screen; a take-home request is assessment, not interview-invite). Use the body + subject + sender domain together — sender alone is unreliable.

3. Extract fields per the taxonomy's Extraction fields block (only fields the email genuinely provides — never invent):

   • company, role, job_id
   • dates[] — proposed slots / deadlines / start dates (ISO + time + tz + label)
   • links[] — { url, kind ∈ schedule|assessment|portal|other }
   • asks[] — verbatim recruiter asks ("send updated CV", "share notice period")
   • deadline — single hard cutoff if explicit
   • sentiment ∈ {neutral, positive, negative}
   • confidence ∈ {high, medium, low} — your own confidence in the classification

4. Suggest one action from the taxonomy's vocab (reply-schedule | reply-accept | reply-decline | reply-ask | reply-info | acknowledge | ignore | escalate). Map per the decision table; always suggest escalate for class other or any classification with confidence: low.