chore: consolidate the skill packages under .agents/

The repository had two skill directories. `skills/` held the four written
for this project; `.agents/skills/` held the ones the agent context refers
to. Nothing said which an agent should read, and `.agents/ORCHESTRATOR.md`
only ever pointed at the second.

Move the first four into `.agents/skills/` so there is one location, and
add the vendored packages this chapter work used: `animation-vocabulary`
and `improve-animations` (emilkowalski/skills), `teach` (mattpocock/skills),
plus a local `translation` skill and `audit-translations.mjs` for the EN/PT
pairs.

`skills-lock.json` pins the vendored three by source and content hash, so a
later re-vendor is a diff rather than a guess. `.claude/skills/` is
symlinks into `.agents/skills/`, which is what makes them loadable here
without a second copy on disk.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.agents/skills/teach/MISSION-FORMAT.md

@@ -0,0 +1,47 @@
+# MISSION.md Format
+
+`MISSION.md` lives at the workspace root. It captures the _reason_ the user is
+learning this topic. Every teaching decision (what to teach next, which
+resources to surface, which exercises to design) should trace back to this
+document.
+
+## Template
+
+```md
+# Mission: {Topic}
+
+## Why
+
+{1-3 sentences. The concrete real-world goal the user is chasing. What changes
+in their life or work when they have this skill? Avoid abstract framings like
+"to understand X"; push for the underlying outcome.}
+
+## Success looks like
+
+- {A specific, observable thing the user will be able to do}
+- {Another specific thing}
+- {…}
+
+## Constraints
+
+- {Time, budget, prior commitments, learning preferences, anything that bounds
+  the approach}
+
+## Out of scope
+
+- {Adjacent topics the user explicitly does not want to chase right now,
+  protecting the zone of proximal development}
+```
+
+## Rules
+
+- **One mission per workspace.** If the user wants to learn two unrelated
+  things, that is two workspaces.
+- **Concrete over abstract.** "Run a half marathon by October" beats "get
+  fitter." "Ship a Rust CLI to my team" beats "learn Rust."
+- **Push back on vagueness.** If the user cannot articulate why, interview them
+  before writing anything. A bad mission is worse than no mission.
+- **Revise when reality shifts.** Missions change. When the user's goal moves,
+  update this file: don't leave a stale mission steering future sessions.
+- **Keep it short.** If `MISSION.md` runs past a screen, it has stopped being a
+  compass and started being a plan.