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>
42 lines
1.8 KiB
Markdown
42 lines
1.8 KiB
Markdown
---
|
|
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.
|