Get card
Download
reply-dispatch@1.0.0.yamlClone
npx -y darkprint clone reply-dispatch@1.0.0There is no repository and no history behind a card. Download hands you the document as it stands, and Clone fetches the same document by name.
Post the approved reply to the channel the ticket arrived on and return the provider's receipt, leaving the thread in whatever state that channel reports.
used in 1 blueprint
Specification
119 words · handed to the agentPost the reply you are handed on approved to the ticket thread named inside it, over the channel that thread arrived on and over no other. Send it exactly as it reached you: you are not authorised to edit, shorten, re-tone or append to a reply that has already been cleared. Send it exactly once, a sent message cannot be recalled, so if the provider has not answered within fifteen seconds, report the timeout and stop rather than sending again. Emit the provider's acknowledgement on receipt in the provider's own terms, delivered, deferred or rejected, and never upgrade a deferral or a rejection into a success. You are done when a receipt is on receipt, whatever that receipt says.
Interfaces
1 in · 1 outInputs
1| Name | Data type | Required | Description |
|---|---|---|---|
| approved | json | required | The QA-cleared reply, together with the thread it belongs to. |
Outputs
1| Name | Data type | Description |
|---|---|---|
| receipt | status | The provider's acknowledgement, delivered, deferred or rejected. |
Dependencies
1The upstream nodes this card expects to receive from. Whenever a blueprint pins this card, each name is checked against a real edge in that graph. A name without a link is not a published card; it refers to a node inside some graph.
Card values
18 declaredWho the node is. The id is the key the DOT pins.
- id
- reply-dispatch
- name
- Reply Dispatch
- type
- tool
- phases
- Deployment
What it does, and the prose the agent is handed when the graph runs.
- action25 words
- Post the approved reply to the channel the ticket arrived on and return the provider's receipt, leaving the thread in whatever state that channel reports.
- spec119 words
- Post the reply you are handed on
approvedto the ticket thread named inside it, over the channel that thread arrived on and over no other. Send it exactly as it reached you: you are not authorised to edit, shorten, re-tone or append to a reply that has already been cleared. Send it exactly once, a sent message cannot be recalled, so if the provider has not answered within fifteen seconds, report the timeout and stop rather than sending again. Emit the provider's acknowledgement onreceiptin the provider's own terms, delivered, deferred or rejected, and never upgrade a deferral or a rejection into a success. You are done when a receipt is onreceipt, whatever that receipt says.in full above - model
- whatever the graph supplies
- agent
- not named
- skill
- skills/reply-dispatch.md
- tools
- Messaging, HTTP fetch
- mcp
- zendesk
- params
- channel: ticket-thread, timeout_s: 15
What arrives, what leaves, which nodes it expects to hear from, and what may not.
- inputs
- approved : json
- outputs
- receipt : status
- dependencies
- reply-qa-check
- cannot
- no type is refused
- will_not
- edit a reply that has already been cleared, report a deferral as a success
The keys the static analysis reads. Nothing here instructs the agent.
- risk_markers
- lupo/pii-handling, irreversible-action
- notes76 words
- This is where the customer's data leaves the process, so
lupo/pii-handlingstays on the card even though the QA gate upstream is what stops an unapproved draft ever reaching it. It is also where the run stops being reversible: a reply posted to a customer thread cannot be unsent, which isirreversible-actionin doc 3 §4's own words. The core vocabulary has no email or ticketing capability, somessagingplushttp-fetchis the closest honest pair.
The card's own version, and who wrote it.
- version
- 1.0.0
- author
- autogen
- provenance
- not stated
Version history
1 version published- reply-dispatch@1.0.0currentsha256:fe5280fcebbe56f07c4ee42c86b9b492024b9ba53210084c117bfcdc84464227
pinned byFrontline Triage
autogen/frontline-triage
A digest is a fingerprint (SHA-256) of the card's content, computed without the author and provenance fields. The same card from two people gets the same digest; any edit gets a new one.
First published version, so there is nothing to compare yet. Versions are never edited in place: the next change arrives as a new version, and the differences between the two documents are listed here.
Community notes (0)
No notes yet.
Nobody has posted about this node card yet.
Sign in to post a note.