Question 1

How much of my DingTalk mail ends up in a Jev request?

Accepted Answer

The unread mail and its bodies are converted into the JSON that `jev mail` reads, so the classification call carries that content to TypeSafe. The scripts do the fetching and converting locally and the README says the chain has no second model call, so the exposure is the one classification request per batch plus the triage call for chat. Worth reading the JSON before you run it on a mailbox with anything sensitive in it.

Question 2

Encrypted chats — does it guess a classification or just flag them?

Accepted Answer

It flags and never guesses. Encrypted content is annotated only, so the report says a conversation could not be read rather than showing a classification invented for it. Chat still arrives one row per conversation, from messages that @ you plus unread conversations through `jev triage`, with urgency and the needs_attention, low_confidence and injection markers; the injection flag exists precisely because the text came from other people.

Question 3

Do I need a Node install and a second CLI to use this?

Accepted Answer

Yes. The prerequisites are python3, Node.js to install `dingtalk-workspace-cli`, and a Jev API key, and the flow is npm install -g dingtalk-workspace-cli, then dws auth login -y, then jev setup-key once. After that it is three commands per source: convert with a Python script, classify with jev, render with another script. The examples directory holds synthetic samples, so you can dry-run the renderers before touching a real inbox.

Question 4

How do I stop re-reading conversations I already handled?

Accepted Answer

The scripts keep local state and mark what you have already dealt with, including conversations you have fully read, ones where you spoke last, and repeat senders with a count. That detection is entirely local with no model call, and `--new-only` hides read and replied rows from the report in one flag.

Question 5

What are the exact commands for a first run?

Accepted Answer

Four setup steps then three per source. Install with npm install -g dingtalk-workspace-cli, authenticate with dws auth login -y which needs a QR scan whose session lasts about thirty days, and run jev setup-key once. Then for mail: dws_unread_to_jev.py to produce inbox.json, jev mail --file inbox.json into triage.json, and render_triage.py to emit report.md. Chat uses dws_chat_to_jev.py, jev triage, and render_chat_triage.py in the same shape.

Question 6

What exactly does the classifier decide on?

Accepted Answer

Five buckets on both mail and chat: needs_reply, updates, promotional, sales and spam, each with an urgency rating and the flags a human needs to look. The design stops there. There is no second model call in the chain, so only rows flagged needs_attention, low_confidence or injection need a person, and the reports are rendered mechanically in Python standard library with an excerpt of the source message on each line so you can grep it back in DingTalk.

Question 7

How does it fit into an agent, and what is the companion project?

Accepted Answer

You copy the whole folder into a skills directory, for Hermes that is $HERMES_HOME/skills/, and SKILL.md carries the full flow plus the DingTalk-specific field traps. The examples directory holds synthetic samples, so you can dry-run the renderers without touching a real inbox. The companion jev-mailbox project covers mail that has already been exported, while this one supplies the fetch-and-convert half and the field pitfalls that come with it. MIT.

Jev Dingtalk

Highlights

Questions about this entry

More Jev resources like this

From the Jev community