feat: add submitted skills review desk
This commit is contained in:
@@ -0,0 +1,25 @@
|
||||
---
|
||||
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.
|
||||
@@ -0,0 +1,7 @@
|
||||
# Review rubric
|
||||
|
||||
Assess six dimensions: discoverability, scope, procedure, safety, resources, and proof.
|
||||
|
||||
For each finding, state the observed evidence, the practical consequence, and the smallest helpful change. Do not call missing files a problem unless the workflow genuinely needs them. A strong review explains why the recommendation belongs in the skill rather than in general agent behavior.
|
||||
|
||||
Test prompts should include one normal request and one boundary case. Assertions should be observable, such as valid JSON, an explicit approval request before mutation, or a report containing file locations.
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
name: skill-rewriter
|
||||
description: Rewrite an existing Agent Skill into a concise, safer, and more discoverable package while preserving its intended capability. Use after a skill review or when the user asks to improve a SKILL.md; do not alter original submissions in place without explicit approval.
|
||||
---
|
||||
|
||||
# Skill rewriter
|
||||
|
||||
Create a separate revised package so the author can compare it with the original. Retain domain-specific facts that are supported by the source; replace generic filler with decisions the agent would otherwise miss.
|
||||
|
||||
## Rewrite flow
|
||||
|
||||
1. Read the original package and any review brief. Keep its intended job and remove only unsupported assumptions, unsafe commands, or instructions that conflict with the requested boundary.
|
||||
2. Write valid frontmatter: a lowercase hyphenated name matching the folder and a description that states capability plus trigger terms.
|
||||
3. Use a short, friendly structure: Purpose, When to use, Inputs, Workflow, Rules, Output, and Verification. Omit headings that add no decision-making value.
|
||||
4. Move conditional detail to `references/`; add a script only for deterministic repeated work and name its prerequisites. Use paths relative to the skill root.
|
||||
5. Add concrete safety gates for mutation, credentials, and external systems. Never preserve a secret in the rewritten package.
|
||||
6. Validate the new package and give the author an end-to-end explanation of the changes and one next evaluation step.
|
||||
|
||||
Read [the rewrite checklist](references/rewrite-checklist.md) for final checks.
|
||||
@@ -0,0 +1,10 @@
|
||||
# Rewrite checklist
|
||||
|
||||
- `name` is lowercase, hyphenated, and matches the folder.
|
||||
- `description` says what the skill does and when to use it.
|
||||
- The default workflow has clear inputs and a concrete result.
|
||||
- Important limits have a reason; rules are not generic boilerplate.
|
||||
- Bundled resources are linked from `SKILL.md` and loaded only when needed.
|
||||
- Commands use relative paths and document prerequisites.
|
||||
- Mutations require an explicit user approval at the moment they occur.
|
||||
- The package has one normal and one boundary-case evaluation prompt.
|
||||
Reference in New Issue
Block a user