Learning path · 5 steps
Assemble one incident handoff from two assistant reviews
Keep two bounded, read-only reviews in view while you build a single incident handoff. One assistant checks the runbook against configuration; the other reads the synthetic event timeline. Herdr holds the conversations while you compare their claims and combine only the findings the files support.
In this guide 6 sections
These walkthroughs use the downloadable synthetic support-service project. Work in a disposable copy so you can compare the proposed changes with the original defects. Each tool needs separate authorized access; the starter includes no production credentials or incident data.
What you will build
An incident handoff with two checked inputs
Create runbook-review.md, timeline-review.md and one final handoff.md. The two assistants inspect the same unmodified synthetic bundle, but return their notes in conversation so they cannot overwrite a shared report.
Included example files
A small support-service project
Synthetic code, logs, a deliberately stale runbook, and six support tickets. The JavaScript uses Node.js 22+ with no packages or network calls. Product accounts and model access are separate.
- operations/rollouts.csv
- operations/checkout.log
- operations/config.json
- operations/runbook.md
Give each review a distinct place
Start Herdr in the starter folder and open two panes or tabs, using assistants you have already configured. Arrange a read-only environment if preventing edits matters. Name the tasks in your own notes so the folder and purpose of each conversation remain clear.
Terminal commandherdrCheck before continuingBoth conversations point at the same untouched starter bundle; neither has a shared output file to edit.
Review the runbook against configuration
Give the first assistant the narrow configuration question. The expected disagreements are deliberately present in the fixture; the assistant still needs to show where they come from.
Request to adaptCompare operations/runbook.md with operations/config.json. Return both sides of every conflicting setting with file references. Distinguish checked-in values from deployed state. Do not edit or infer settings from outside this bundle.Check before continuingThe note identifies 5000 versus 2000 ms and two versus zero automatic write retries.
Read the timeline independently
Give the second assistant the event question. An independent question is useful here because a documentation mismatch and an outage cause are different claims; combining them too early can produce an attractive but unsupported story.
Request to adaptRead operations/rollouts.csv and operations/checkout.log. Explain the observed order of events, including the successful request after the rollout. What cannot be concluded without downstream telemetry? Return a cited note without editing files.Check before continuingThe note includes rollout at 09:10, timeouts at 09:12/09:13, success at 09:14 and no causal verdict.
Step away and return deliberately
Detach with Ctrl+B followed by Q while the host remains running. Reattach with herdr and inspect each actual conversation. Use status as an attention cue; if a label is uncertain, read the pane rather than assuming a task finished.
Terminal commandherdrCheck before continuingYou can find both tasks and any unanswered questions. A server restart is distinguished from a live detach.
Write one handoff from checked findings
Save the two reviewed notes, then write handoff.md with observations, configuration disagreements, open questions and next evidence to obtain. Check each cited line yourself. If you later allow parallel edits, switch to separate copies or worktrees before combining changes.
Check before continuingThe handoff contains both useful findings without claiming that stale documentation or the rollout caused the timeouts.
Check the finished project
node -e "console.log(require('fs').readFileSync('operations/config.json','utf8'))"Compare the configuration printed above with the handoff: 2000 ms, zero automatic write retries, revision r18. The handoff must retain the later successful request and the absence of downstream telemetry. Then confirm that you can return to both original conversations on the still-running host.
Tool guides for this path
An authored walkthrough using the synthetic starter project and linked official tool documentation. Baseline fixture behavior and the local evaluator were checked. The assistants, review service and model calls were not run for this path.
Browse all learning paths