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>
This commit is contained in:
@@ -0,0 +1,41 @@
|
||||
---
|
||||
name: skill-reviewer
|
||||
description:
|
||||
Review an Agent Skill package and produce a kind, evidence-backed improvement
|
||||
brief. Use when assessing a SKILL.md, its trigger, instructions, scripts,
|
||||
references, safety, or evaluation readiness; do not rewrite the package unless
|
||||
asked.
|
||||
---
|
||||
|
||||
# Skill reviewer
|
||||
|
||||
Review the submitted package before proposing changes. Preserve the author's
|
||||
intent: this is a constructive assessment, not a replacement of their domain
|
||||
expertise.
|
||||
|
||||
## Review flow
|
||||
|
||||
1. Read `SKILL.md` and list bundled files. Check frontmatter validity,
|
||||
package-name alignment, and whether the description says both what the skill
|
||||
does and when it applies.
|
||||
2. Identify the narrow job, the expected inputs, safe boundaries, a default
|
||||
workflow, and observable output. Mark any claim you cannot verify as a
|
||||
question, not a defect.
|
||||
3. Recommend only additions that change execution: a small RULES section for
|
||||
real invariants, a script for repeated fragile work, a reference for
|
||||
conditional detail, or eval cases for behavior that matters.
|
||||
4. Flag secrets, destructive actions, network calls, and unclear approval
|
||||
boundaries prominently. Never copy credentials into review artifacts.
|
||||
5. Return a friendly brief with: what already works, highest-value improvements,
|
||||
suggested package layout, and a small set of realistic test prompts.
|
||||
|
||||
## Quality bar
|
||||
|
||||
- Prefer precise activation language over broad phrases such as "use for code."
|
||||
- Keep the main instructions lean; send conditional or lengthy material to
|
||||
`references/` and explain exactly when to read it.
|
||||
- Favor evidence and defaults over generic rules or tool menus.
|
||||
- Recommend scripts only when they remove repeated, error-prone mechanics;
|
||||
document prerequisites and use relative paths.
|
||||
|
||||
Read [the review rubric](references/review-rubric.md) when scoring a package.
|
||||
Reference in New Issue
Block a user