Get card
Download
runbook-resolver@1.0.0.yamlClone
npx -y darkprint clone runbook-resolver@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.
Match the routed alert to a runbook in the versioned store and return it as Markdown, pinned to the revision that was current when the incident opened.
used in 1 blueprint
Specification
115 words · handed to the agentBuild a lookup key out of the routed alert on query, its label plus the affected service, and pull the three closest runbooks from the versioned store. Drop anything scoring below 0.4 and emit the best of the rest on runbook as Markdown, with its preconditions and its steps intact and in their original order. Resolve it at the store revision that was current when the incident opened, not at the tip, and write that revision into the output: an edit landing mid-incident must not change the runbook that is already being carried forward. If nothing clears 0.4, emit nothing, no runbook is a better answer than a runbook that does not fit the alert.
Interfaces
1 in · 1 outInputs
1| Name | Data type | Required | Description |
|---|---|---|---|
| query | json | required | The routed alert, whose label and affected service form the lookup key. |
Outputs
1| Name | Data type | Description |
|---|---|---|
| runbook | markdown | The matched runbook at a pinned revision, preconditions and steps intact. |
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
16 declaredWho the node is. The id is the key the DOT pins.
- id
- runbook-resolver
- name
- Runbook Resolver
- type
- tool
- phases
- none declared
What it does, and the prose the agent is handed when the graph runs.
- action27 words
- Match the routed alert to a runbook in the versioned store and return it as Markdown, pinned to the revision that was current when the incident opened.
- spec115 words
- Build a lookup key out of the routed alert on
query, its label plus the affected service, and pull the three closest runbooks from the versioned store. Drop anything scoring below 0.4 and emit the best of the rest onrunbookas Markdown, with its preconditions and its steps intact and in their original order. Resolve it at the store revision that was current when the incident opened, not at the tip, and write that revision into the output: an edit landing mid-incident must not change the runbook that is already being carried forward. If nothing clears 0.4, emit nothing, no runbook is a better answer than a runbook that does not fit the alert.in full above - model
- whatever the graph supplies
- agent
- not named
- skill
- skills/runbook-resolver.md
- tools
- Vector store, Git
- mcp
- qdrant, git
- params
- k: 3, min_score: 0.4
What arrives, what leaves, which nodes it expects to hear from, and what may not.
- inputs
- query : json
- outputs
- runbook : markdown
- dependencies
- intent-router
- cannot
- no type is refused
- will_not
- resolve a runbook at any revision but the one current when the incident opened
The keys the static analysis reads. Nothing here instructs the agent.
- risk_markers
- none
- notes44 words
- Pinning the revision matters more than the match. A runbook that changes mid-incident is how the mitigation that runs stops being the mitigation that was reviewed.
githere reads the factory's own versioned store, which is why no external-access marker is inferred from it.
The card's own version, and who wrote it.
- version
- 1.0.0
- author
- autogen
- provenance
- not stated
Version history
1 version published- runbook-resolver@1.0.0currentsha256:f87c06df3b820b2b5bafd371bd130edebd54629b22eea78db4288c008ad59fde
pinned byIncident Commander
autogen/incident-commander
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.