Files

T

Marcos Paulo ab2308441c 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>

2026-09-06 16:03:23 -03:00

1.5 KiB

Raw Blame History

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

# 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.

1.5 KiB Raw Blame History

MISSION.md Format

Template

Rules

1.5 KiB

Raw Blame History