ci/woodpecker/push/default Pipeline was successful

Details

t3-provision-users: vendor agent skills + per-user install_skills (emo)

Make the admin's Claude Code agent skills available to the `emo` devvm user.
Viktor asked to install Matt Pocock's skills for emo, starting with grill-me
but covering the full set the admin already uses.

The `npx skills` upstream has drifted off that set (diagnose -> diagnosing-bugs
and write-a-skill -> writing-great-skills were renamed; caveman + zoom-out are
no longer published), so reproducing it via npx is impossible and would also
spray ~70 agent dirs into the user's home + add a GitHub-clone + unpinned-CLI
dependency to the hourly root reconcile. Instead vendor a point-in-time
snapshot of the 16 skills (scripts/workstation/claude-skills/) and copy them
per-user, mirroring install_memory: install_skills() copies each skill into
~/.agents/skills/<name> (owned by the user) and symlinks
~/.claude/skills/<name> -> ../../.agents/skills/<name>. if-absent, additive,
best-effort, scoped to the SKILL_USERS allowlist (emo).

find-skills is from vercel-labs/skills (not Matt Pocock) but included since it
is part of the admin's current set.

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

2026-06-23 09:23:37 +00: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 — protects 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