Refine skill design
Skill LaWebcapsule/d9-skills/skills/skillops/refine-skill-design
Audit and refactor existing SKILL.md files using meta-audit model for intent, logic, constraints, and examples. Align to spec v2.2.From its SKILL.md
npx -y skills add LaWebcapsule/d9-skills --skill refine-skill-designAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its file declares
Copied from the file, not written here
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
5.7 KB, ~1.3k tokens by cl100k_base, as published. Nobody here has run it
Skill: Refine Skill Design
Purpose
Audit and improve an existing SKILL.md to maximize its ASQM score. Apply a structured meta-audit across 4 dimensions: intent clarity, behavioral logic, constraint precision, and example quality. Produce an optimized version with a clear diff summary.
Core Objective
Primary Goal: Take any SKILL.md and return an improved version scoring >=17 ASQM (validated threshold).
Success Criteria:
- Every section is present and well-formed (frontmatter, Purpose, Triggers, Behavior, Restrictions, Self-Check)
- Intent is unambiguous — another agent reading this skill would behave identically
- Constraints use hard/soft boundary separation
- At least 2 examples including 1 edge case
- The diff summary explains every change with rationale
Acceptance Test: The refined skill passes verify-skill-structure.mjs and scores >=17 on ASQM dimensions.
Triggers
- Called after
format-skillgenerates a new SKILL.md (quality gate before PR) - Called manually when a skill's ASQM score drops or needs improvement
- Called by
curate-skillswhen a skill fails quality checks
Behavior
Step 1: Parse and validate structure
Check the SKILL.md for required sections:
✅ YAML frontmatter (name, description — Agent Skills standard; license, metadata optional)
✅ Purpose section
✅ Triggers section
✅ Behavior section (with numbered steps)
✅ Restrictions section (hard/soft boundaries)
✅ Self-Check section (checkbox list)
⚠️ Examples section (at least 2, including 1 edge case)
Step 2: Meta-audit across 4 dimensions
1. Agent-native (0-5): Can an AI agent execute this skill without ambiguity?
- Are triggers machine-detectable?
- Are actions concrete (not vague like "consider" or "think about")?
- Are outputs well-defined?
2. Cognitive (0-5): Is the skill cognitively well-structured?
- Single responsibility (one clear job)?
- Appropriate abstraction level (not too broad, not too narrow)?
- Clear decision points (if X then Y, not "use judgment")?
3. Composability (0-5): Does it play well with other skills?
- Clear input/output contract?
- Named handoff points to related skills?
- No overlap with existing skills (check
related_skills)?
4. Stance (0-5): Are constraints precise and enforceable?
- Hard boundaries use "NEVER", "MUST", "ALWAYS"
- Soft boundaries use "prefer", "when possible", "by default"
- No contradictions between constraints
Step 3: Apply improvements
For each dimension scoring <4, make targeted improvements:
- Rewrite vague triggers as concrete conditions
- Replace advisory language with actionable steps
- Add missing examples or edge cases
- Separate hard from soft constraints
- Add self-check items for gaps
Step 4: Output
Present the result as:
## Refine Report: [skill-name]
### Scores (before → after)
| Dimension | Before | After | Change |
|---------------|--------|-------|--------|
| Agent-native | 3 | 5 | +2 |
| Cognitive | 4 | 4 | 0 |
| Composability | 3 | 5 | +2 |
| Stance | 4 | 5 | +1 |
| **Total** | **14** | **19**| **+5** |
### Changes
| Section | Change | Reason |
|---------|--------|--------|
| Triggers | Added concrete conditions | Was too vague for agent detection |
| Restrictions | Split hard/soft | Mixed severity confused boundaries |
| Examples | Added edge case | Only had happy path |
### Version Suggestion
1.0.0 → 1.1.0 (minor: improved quality, no behavioral change)
Restrictions
Hard boundaries
- NEVER remove existing examples or restrictions without replacement
- NEVER change the core purpose/intent of the skill
- NEVER introduce dependencies on external services
- NEVER auto-apply changes — always present diff for human review
Soft boundaries
- Prefer minimal changes over rewrites (smallest diff that maximizes score)
- Prefer adding examples over rewriting existing ones
- When two phrasings score equally, keep the original
Self-Check
- All required sections present and well-formed?
- Each ASQM dimension scored and justified?
- Diff summary includes rationale for every change?
- Version bump suggestion follows semver?
- Refined skill passes structural validation?
- No meaning/intent drift from original?
Examples
Example 1: Improving a weak trigger
Before (agent_native: 2):
## Triggers
Activate when you notice a deployment issue.
After (agent_native: 5):
## Triggers
Activate when ALL of the following are true:
- A `pnpm build` or `npm run build` command was just executed in `plugins/`
- The build output does NOT include the expected extension files in `extensions/`
- OR: a deployment command was run without a prior build step in the session
Example 2 (edge case): Skill that's already good
Input: A skill scoring 18/20 (validated).
Output:
## Refine Report: preserve-directus-code-identifiers
### Scores (before → after)
All dimensions >=4. No changes needed.
### Recommendation
This skill is already at validated quality. Consider:
- Adding a 3rd example if the skill is frequently referenced
- No version bump needed
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most design frontend skills give in ~1.3k tokens
Counted across 1,169 of the 1,878 authors here whose files we hold, read 2026-08-07
- Use CSS variables for color consistencyin 72 of 1169, across 23 files
- Commit to one bold aesthetic direction before codingin 72 of 1169, across 27 files
- Match implementation complexity to the aesthetic visionin 70 of 1169, across 20 files
- Add atmospheric background effects and texturesin 57 of 1169, across 9 files
- Use unexpected spatial compositions and layoutsin 56 of 1169, across 8 files
- Implement real working codein 55 of 1169, across 7 files
- Vary themes and aesthetics across different designsin 48 of 1169, across 7 files
- Launch chromium in headless modein 47 of 1169, across 4 files
- Close the browser when donein 47 of 1169, across 4 files
- Run provided scripts with help flag firstin 47 of 1169, across 4 files
- Wait for network idle statein 47 of 1169, across 4 files
- Use descriptive selectors for elementsin 47 of 1169, across 4 files
Said here and by no other author read
- validate required sections are present
- improve any dimension scoring below four
- rewrite vague triggers as concrete conditions
- replace advisory language with actionable steps
- separate hard constraints from soft constraints
- include rationale for every change in the report
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.