claude
fbec36cb67
Scaffold the course repo and author the full curriculum in dependency-chain order, following the settled build decisions in handoff.md. - Scaffold: course README, vendor-neutral AGENTS.md (dogfoods Module 5), _TEMPLATE.md (the fixed 9-section module shape), root .gitignore, ship config. - Modules 1-2: reference exemplars (locked for tone/depth/lab style). - Modules 3-27: full lessons + runnable labs, each following the template, respecting the chain, vendor/model-agnostic, with "feel the pain" labs. - Module 8 hosting comparison web-researched and date-stamped (as of 2026-06-22), not written from memory; expansion-zone modules carry Verify-before-publish. - Capstone: the full loop end to end on the running tasks-app example. Lab code syntax-checked (Python/shell/YAML); every module has the 7 core template sections. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TfzV5QvtPDz8LJS3Pu5VLT
53 lines
1.4 KiB
Markdown
53 lines
1.4 KiB
Markdown
<!--
|
|
Runbook template — the step-by-step for one operational task.
|
|
|
|
A runbook is read under pressure, often by someone who is not the person who wrote it and not at
|
|
their best (it's 3 a.m., something is on fire). Optimize for "follow it exactly, no thinking
|
|
required." Concrete commands, expected output, and what to do when a step fails.
|
|
|
|
In the Module 3 lab (optional variant) you hand this to the AI to draft a runbook, then review the
|
|
draft as a diff before merging. Write one command/step per line so git diffs stay clean.
|
|
|
|
Delete these HTML comments when you write the real runbook.
|
|
-->
|
|
|
|
# Runbook — <task name>
|
|
|
|
- **Purpose:** <one sentence: what this runbook gets you out of>
|
|
- **When to run:** <the trigger — the alert, the symptom, the request>
|
|
- **Owner:** <team or role responsible>
|
|
- **Last verified:** YYYY-MM-DD
|
|
|
|
## Before you start
|
|
|
|
<!-- Access, tools, or context the operator needs in hand before step 1. -->
|
|
|
|
- <prerequisite>
|
|
|
|
## Steps
|
|
|
|
<!-- Numbered, concrete, copy-pasteable. After a command, say what success looks like so the operator
|
|
knows whether to continue. -->
|
|
|
|
1. <action>
|
|
|
|
```bash
|
|
<command>
|
|
```
|
|
|
|
Expected: <what you should see>
|
|
|
|
2. <action>
|
|
|
|
## Verify
|
|
|
|
<!-- How to confirm the task actually worked, not just that the commands ran without error. -->
|
|
|
|
- <check>
|
|
|
|
## If it goes wrong
|
|
|
|
<!-- The two or three most likely failure modes and what to do about each. Where to escalate. -->
|
|
|
|
- **<symptom>** → <what to do>
|