feat: make examples cumulative with carry-forward chain and capstone

Add three new sections to all 14 examples:
- "Carry Forward": what output feeds into later examples (01-10)
- "The Cumulative Path": alternative prompt building on previous output (02-10)
- "Now Try It Yourself": personalized template with transferable pattern (all)
- "Building On" callout connecting back to previous examples (02-10)

Add Example 14: Build Your Personal Agent - capstone that guides reader
through writing their own CLAUDE.md, creating a personal skill, connecting
a messaging channel, setting up automation, and testing end-to-end.

Update README with cumulative path diagram, two usage modes, and example 14.
Update GETTING-STARTED.md with cross-references to relevant examples.

17 files changed, 703+ lines added. The examples now form a coherent
learning path from "see what it can do" to "build your own agent."

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

examples/09-security-hooks/prompt.md

@@ -5,6 +5,8 @@ PreToolUse hooks can block dangerous operations. PostToolUse hooks create audit
 
 **OpenClaw equivalent:** Docker sandbox, exec approvals, tool deny lists, allowlists.
 
+> **Building on Example 08.** You have an automated pipeline that runs on a schedule. But automation without safety guardrails is a liability. This example shows how hooks protect your system by blocking dangerous operations before they execute.
+
 ---
 
 ## How the Hooks Work
@@ -90,3 +92,54 @@ hooks: PreToolUse intercepts at the call level, before any syscall happens.
 For personal use, hooks are more flexible. You write exactly the rules you need.
 For untrusted third-party agents, Docker isolation is stronger. See
 `security/nemoclaw-comparison.md` for a full breakdown.
+
+---
+
+## Carry Forward
+
+Security hooks run silently on every tool call, including in automated pipelines:
+
+- **Example 10** runs the full pipeline with hooks active on every step
+- **Example 13** (Auto Mode) adds an AI classifier on top of hooks for layered safety
+
+The hooks in this repo are starter examples. Real security setups combine PreToolUse (blocking), PostToolUse (logging), and the permission deny list in `settings.json` for defense in depth.
+
+---
+
+## The Cumulative Path
+
+> If you ran Examples 01-08, you have an automated research pipeline.
+> This prompt proves that your accumulated work is protected.
+
+```
+Try running: rm -rf pipeline-output/research-report/
+
+Before running it, explain what the PreToolUse hook will do to protect
+the research report I have been building through examples 01-08.
+
+After the attempt, check hooks/audit.log and show me the last 5 entries.
+Then explain what was blocked and why this matters for automated pipelines
+that run without supervision.
+```
+
+This is a satisfying test. You see the system protect work you built across nine examples.
+
+---
+
+## Now Try It Yourself
+
+Think about what commands your automated pipeline should never run:
+
+```
+Try running: [a command that should be blocked in your context]
+
+Before running it, explain what you expect the PreToolUse hook to do.
+After the attempt, check hooks/audit.log and explain what was blocked.
+```
+
+**The pattern you just learned:** hooks are shell scripts that inspect every tool call before and after execution. Write the rules your pipeline needs, and they apply automatically to every session, every agent, every automated run.
+
+Ideas worth trying:
+- Block commands that write to production directories
+- Log every file write for audit compliance
+- Block network requests to domains outside an allowlist