Marcos Paulo
ab2308441c
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>
48 lines
1.5 KiB
Markdown
48 lines
1.5 KiB
Markdown
# 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.
|