Skill Creator: Meta Skill for Skill Lifecycle Management

Create, review, improve, audit, and maintain AI tool skills. Covers the full lifecycle from initial draft through quality validation, cross-skill consistency checks, and trigger optimization.

This skill enforces the conventions established across the custom skill collection. It exists because consistency is what makes skills predictable - a skill that follows the established patterns activates reliably, reads clearly, and plays well with the rest of the collection.

When to use

• Creating a new custom skill from scratch
• Reviewing or improving an existing skill
• Auditing the skill collection for consistency, overlaps, or contradictions
• Validating versions, security references, or CVE mentions in skills
• Optimizing a skill's description for better triggering accuracy
• Checking cross-skill references and "Related Skills" sections
• Troubleshooting why a skill isn't triggering or is triggering incorrectly

When NOT to use

• Reviewing application code for correctness or bugs - use code-review
• Auditing code for AI-generated patterns or style issues - use anti-slop
• Running a full codebase audit across multiple dimensions - use full-review
• Creating inline prompts within application code - use prompt-generator
• Batch-improving a whole skill collection via evaluation loops - use skill-refiner
• Syncing or refreshing third-party skills from upstream - handle that directly in the repo workflow
• Updating project documentation after infrastructure changes - use update-docs
• Writing application code, even if the code is for a tool a skill might use

AI Self-Check

Before returning any generated or modified skill, verify against this list:

• Frontmatter complete: name, description, license, metadata.source (owner/repo for published collections or custom for unpublished skills), metadata.date_added (ISO), metadata.effort (low/medium/high)

• Name spec-valid: lowercase alphanumeric + hyphens only, no leading/trailing/consecutive hyphens, no reserved words (anthropic, claude), matches directory name

• No XML tags in name or description fields (Anthropic platform restriction)

• Description is trigger-optimized: starts with action verbs, includes trigger keywords, mentions related contexts, stays near 200 chars for the collection (240 warn, 600 hard max in validate-spec.sh; platform truncation happens later)

• Compatibility field present (when skill requires specific tools/platforms): quotes values containing colons

• Scope sections present: "When to use" with concrete scenarios, "When NOT to use" cross-referencing related skills by bold name (e.g., use **skill-name**)

• Workflow section with numbered steps: clear, sequential, actionable

• Rules section at the end: non-negotiable constraints in imperative form

• Style compliant: no banned words (per CLAUDE.md/AGENTS.md), ASCII by default except approved markers such as · and output-contract box glyphs. No em-dashes, curly quotes, ligatures, or --; use -. Check SKILL.md and references for banned words

• Target ~500 lines: if over 500, extract to references/ with clear pointers. Hard max 600

• Reference files use references/ relative paths: not hardcoded or tool-specific paths

• All references verified: every tool, CLI flag, IaC resource, config snippet, and example command confirmed against actual docs, --help output, or registry - not assumed from training data. Specifically: tools exist and aren't deprecated/renamed, CLI flags are real (AI models invent plausible ones constantly), Terraform providers/resources match the registry, Ansible modules/params match ansible-doc, Helm values match upstream values.yaml, K8s fields match the target API version. When web access is unavailable, note unverified claims rather than blocking

• Version numbers verified and dated: searched the web for latest stable version of each tool, pinned with date (e.g., "v29.3.0 (March 2026)") so staleness is detectable

• Cross-skill references are valid: every mentioned skill name actually exists

• AI-age awareness: if the skill generates code, config, or structured files (including skill files), include an AI self-check section

• Context budget justified: every section earns its token cost (see references/conventions.md)

• Forward-tested (high-effort skills, when feasible): during review, a subagent used the skill on a realistic task without leaked context. This is a process check on the reviewer, not a content requirement on the skill - the skill does not need a "forward-test" section. The reviewer notes what was tested or skipped and why.

• Current source checked: dated versions, CLI flags, API names, and support windows are verified against primary docs before repeating them

• Hidden state identified: local config, credentials, caches, contexts, branches, cluster targets, or previous runs are made explicit before acting

• Verification is real: final checks exercise the actual runtime, parser, service, or integration point instead of only linting prose or happy paths

• Routing overlap checked: new or edited skills do not steal triggers from better-matched existing skills

• Spec claims verified: frontmatter, metadata, and compatibility guidance match the current Agent Skills specification

Performance

• Keep SKILL.md compact; move deep examples into references loaded on demand.
• Prefer precise triggers over broad keyword lists that cause unnecessary skill loading.
• Run lint/spec checks before prose polishing so structural failures surface early.

Best Practices

• Write skills as operational instructions, not essays about a domain.
• Include clear When to use/When NOT to use routing and realistic AI self-checks.
• Keep public skills tool-agnostic unless a tool is intrinsic to the skill.
• Treat install/copy/link steps as environment-specific. If skills are sourced directly from a repo, edit and verify there instead of distributing to tool dirs unless asked.

Workflow

Before entering any mode, detect the operating context. This skill works on individual skills or collections, whether inside a skill collection repo, a user's own project, or standalone.

Mode routing - pick the mode that matches the user's signal. Retrospective-update requests are explicit permission to edit the library, so do not stop at a report-only pass:

When the signal is ambiguous (e.g., "look at my skill"), ask before committing - Create and Review diverge quickly and re-running wastes context. Modes can chain: Create -> Review, Review -> Optimize, Audit -> per-skill Review for flagged items. For explicit retrospective-update requests, act without asking for confirmation unless the only possible update is destructive or would create a new class-level skill with uncertain scope.

1. Find the collection root (if one exists): check for a skills/ directory (common convention) or any path the user specifies. Different harnesses store skills in different locations - if the default doesn't match, ask or accept a user-supplied path. If no collection is found, skip collection-wide checks (cross-references, trigger overlap, audit mode) and note what was skipped.
2. Check git and create a run branch: