メニュー
· Create/review skills: frontmatter, triggers, overlaps, collection consistency, retrospective updates. Triggers: 'skill creator', 'new skill', 'skill audit', 'skill review', 'update skill library'.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
· Audit prose for AI tells in docs, PRs, emails, slides, docstrings. Triggers: 'ai writing', 'sounds like chatgpt', 'ai slop prose', 'llm voice', 'sound human'. Not for code (use anti-slop).
· Audit read-only code slimming: dead code, unused files, duplicate blocks, wrapper removal, commented-out code. Triggers: 'slim codebase', 'dead code', 'unused functions', 'dedupe'. Not for bugs or broad reviews.
· Triage a live incident to localize an unknown failing layer, then route. Triggers: incident, outage, triage, production down, crashloop, 502. Not for known-component debugging (systematic-debugging) or repo audits (deep-audit).
· Run an exhaustive 5-wave repo audit (every applicable lens, up to 30 agents), persist findings, generate phased tasks. Triggers: 'deep audit', 'comprehensive audit', 'full audit', 'mega review', 'deep review', 'audit report'. Not for a quick fixed 4-skill sweep (use full-review).
· Run 4 fixed audits in parallel (code-review, anti-slop, security-audit, update-docs) as a quick quality gate. Triggers: 'full review', 'run all checks', 'full check', 'quad audit', 'review before merge'. Not for exhaustive/wave audits (use deep-audit) or single-dimension checks.
· Instrument and audit observability: metrics, traces, logs, alerts, SLOs, dashboards. Triggers: observability, metrics, tracing, prometheus, opentelemetry, grafana, slo. Not for live diagnostics (cluster-health) or manifests (kubernetes).
| name | skill-creator |
| description | · Create/review skills: frontmatter, triggers, overlaps, collection consistency, retrospective updates. Triggers: 'skill creator', 'new skill', 'skill audit', 'skill review', 'update skill library'. |
| license | MIT |
| compatibility | Optional: git (for freshness and gitignore filtering) |
| metadata | {"source":"iuliandita/skills","date_added":"2026-03-25","effort":"high","argument_hint":"<action> [skill-name]"} |
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.
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
SKILL.md compact; move deep examples into references loaded on demand.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:
| User signal | Mode |
|---|---|
| "create a skill", "new skill for X", "turn this into a skill" | Mode 1 (Create) |
| "review my skill", "improve this skill", "is this skill good" | Mode 2 (Review) |
| "audit the collection", "check all skills", "health check skills" | Mode 3 (Audit) |
| "fix the description", "skill isn't triggering", "trigger overlap" | Mode 4 (Optimize) |
| "review the conversation", "update the skill library", "what did we learn" | Mode 5 (Retrospective Update) |
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.
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.git rev-parse --git-dir. If inside git,
create skill-creator/YYYY-MM-DD-HHMMSS from current HEAD before checks or edits unless
already on a task branch created for this run. Preserve dirty worktrees; branching is for
isolation, not cleanup. Without git, state "branch unavailable" in the final report and
fall back to file modification dates.Understand what the skill should do. Extract from conversation context:
If the user already described the workflow in the conversation (e.g., "turn what we just did into a skill"), extract the steps, tools used, corrections made, and patterns observed.
Before drafting, gather context:
Follow the structural pattern for the skill's effort tier in references/conventions.md (Section 3).
Key elements every custom skill needs:
name, description, license, metadata block (see conventions Section 2)For tool/platform skills, include a Target versions block with pinned versions and dates.
Writing guidelines:
--bare,
Cursor Automations, Codex exec). Avoid blocking on user confirmation in steps that could
run unattended - provide sensible defaults or document assumptions insteadRun through the AI Self-Check above. Then:
effort tier.lint-skills.sh
or validate-spec.sh, verify their expected input shape before trusting the result. Some
collections expect a parent directory containing many skill subdirectories, not a direct path
to one skill. For single-skill validation, stage the skill inside a temporary parent such as
<tmp>/skills/<skill-name>/SKILL.md and run the scripts against <tmp>/skills.SKILL.md to the appropriate location: <collection-root>/<skill-name>/SKILL.md if
inside a collection, or the user's specified path for standalone skills<skill-dir>/references/skill_manage cannot modify the target because the skill lives in an external repo or
non-managed directory, fall back to direct file edits with patch or write_file on the
actual repo paths. Do not stop at the tool limitation if the files are writable and the user
asked for the change in-place.Forward-testing has a subagent use the skill on realistic tasks without seeing your diagnosis. Use it for high-effort skills and for medium-effort skills with multi-step or scripted workflows. Skip it for low-effort wrappers, unavailable subagents, production-only access, long-running infra, missing credentials, or explicit user opt-out; note the skip reason.
If forward-testing only succeeds with leaked context, tighten the skill instead of weakening the test.
Read the SKILL.md and all reference files. No skipping - the whole point is catching issues.
Structural checks:
references/ directory)Content checks:
--help or docs.
For Terraform: confirm provider names and resource type arguments against the registry. For
Ansible: confirm module names and parameters against ansible-doc or Galaxy. For Helm:
confirm chart values against upstream values.yaml. For K8s: confirm API fields against
the target API version. AI invents plausible-sounding arguments for all of these.date_added.AI-age checks:
Compliance checks (for infrastructure skills):
Script-runner reality check: verify helper script input shape. If a single-skill run reports zero skills or odd output, re-run against the collection root and filter for the target.
Use severity ratings:
Present findings to the user and wait for confirmation before editing. The user may want a report only, or may want to fix a subset. In headless mode (no interactive user), report findings and stop unless the original user request explicitly authorized edits. Programmatic callers must pass that authorization through or stop after reporting findings.
Edit the skill files to address confirmed findings. For version updates, always search the web
first - don't guess. Do not modify date_added (it records when the skill was created, used
for historical tracking). If the skill needs a freshness marker, the date_added field serves
that purpose for the initial creation; substantial refreshes are tracked via git history.
After substantial changes, forward-test the skill (see Mode 1, Step 6). Required for high-effort skills after workflow restructuring, reordered steps, or new references. Optional for narrow edits like version refreshes, wording cleanup, or metadata-only fixes. Especially valuable when:
Run a health check across all skills. Useful periodically or after adding/removing skills.
# Detect collection root - adapt to your layout
SKILL_ROOT="${SKILL_ROOT:-skills}"
[[ -d "$SKILL_ROOT" ]] || { echo "No skill collection at $SKILL_ROOT"; exit 1; }
# Check git availability for gitignore filtering and freshness
IN_GIT=false
git -C "$SKILL_ROOT" rev-parse --git-dir &>/dev/null && IN_GIT=true
for skill in "$SKILL_ROOT"/*/SKILL.md; do
dir=$(dirname "$skill")
name=$(basename "$dir")
[[ "$name" == ".backups" || "$name" == ".cook" ]] && continue # tooling dirs, not skills
$IN_GIT && git -C "$dir" check-ignore -q . 2>/dev/null && continue
source=$(grep -m1 '[[:space:]]source:' "$skill" 2>/dev/null | sed 's/.*source: *//' || echo "unknown")
date=$(grep -m1 '[[:space:]]date_added:' "$skill" 2>/dev/null | sed 's/.*date_added: *"//' | sed 's/"//' || echo "unknown")
effort=$(grep -m1 '[[:space:]]effort:' "$skill" 2>/dev/null | sed 's/.*effort: *//' || echo "missing")
if $IN_GIT; then
last_mod=$(git -C "$SKILL_ROOT" log -1 --format=%cd --date=short - "$name" 2>/dev/null || echo "unknown")
else
# Portable: GNU stat then BSD stat; GNU date then BSD date
mtime=$(stat -c %Y "$skill" 2>/dev/null || stat -f %m "$skill" 2>/dev/null || echo 0)
last_mod=$(date -d "@$mtime" +%Y-%m-%d 2>/dev/null || date -r "$mtime" +%Y-%m-%d 2>/dev/null || echo "unknown")
fi
printf "%-25s %-10s %-12s %-12s %s\n" "$name" "$source" "$date" "$last_mod" "$effort"
done
For each skill, check:
skills/*/ directly will overcount unless they filter with
git check-ignoreCompare all skill descriptions pairwise. Flag pairs that share significant trigger keywords without mutual disambiguation (no "When NOT to use" cross-reference).
Flag skills where the last modification (per git history, or file mtime if git is unavailable) is >30 days old AND the skill covers fast-moving domains:
Fast-moving (>30 days = stale risk): docker, kubernetes, ci-cd, terraform, ansible, databases, git, security-audit, code-review (AI-age patterns section), mcp, networking, arch-btw
Slow-moving (>30 days = probably fine): firewall-appliance, command-prompt, prompt-generator, update-docs, skill-creator, full-review, anti-slop, lockpick
If the collection's conventions change significantly, temporarily reclassify skill-creator as fast-moving until the conventions stabilize.
For each stale high-effort skill, search the web for:
Present findings grouped by severity. Include actionable fixes for each finding.
When the user asks to review a completed conversation and update the skill library, capture
reusable class-level learning, not a session log. Patch a loaded or umbrella skill for
reusable workflow, routing, preference, or pitfall changes; create a new skill only when no
class-level fit exists. In the public skills repo, read gitignored instruction files such as
AGENTS.md, but do not force-add them; stage only intended public skill paths and validate.
The description field in frontmatter is the primary triggering mechanism. Optimize it for
accurate activation.
Read the skill's description and identify:
If a collection is available, check which other skills share trigger keywords. Ensure the description differentiates clearly. For standalone skills, skip this step.
Follow these patterns from high-performing custom skill descriptions:
After rewriting, list 5 user prompts that should trigger the skill and 5 that shouldn't. For each, state whether the rewritten description would route correctly and why. This is a heuristic check - actual routing depends on the harness's skill-matching logic, which varies by tool. The goal is catching obvious gaps and false-positive magnets, not deterministic validation.
Edit the skill's frontmatter with the rewritten description. If the skill is part of a collection, run Mode 2 Step 2 (quality checks) to verify no regressions were introduced.
End every run with a human-readable report, even for report-only checks. Include branch, mode, scope, score or "not scored - report only", changed files, finding counts, verification results, skipped checks, and recommended next action.
For edited skills, report before/after checklist pass rate and behavioral or forward-test scores plus keep/reject decisions. For audit-only runs, report structural gate and finding counts instead of inventing a composite.
references/conventions.md - the complete convention guide: frontmatter fields, structural
patterns by effort tier, style rules (ASCII, banned words), reference file organization,
cross-skill patterns, AI Self-Check patterns, and a snapshot inventory of the upstream
collection (useful as a reference, not an authoritative list for other repos)See references/output-contract.md for the full contract.
auditsdocs/local/audits/skill-creator/<YYYY-MM-DD>-<slug>.md. When invoked to answer a question, teach a concept, build a new artifact, or generate content (e.g., Mode 1 create), respond freely without the contract; the existing ## Run Report guidance applies to that build path.P0 | P1 | P2 | P3 | info (see shared contract; only used in audit/review mode).docs/local/prompts/, not reusable skill files.metadata.source, date_added,
effort, "When to use", "When NOT to use", Workflow, and Rules sections.--help, registries, or explicit "unverified" notes. Do not guess.· prefix and shared output-contract box glyphs. No em dashes, curly
quotes, ligatures, or -- dash substitutes. Prose only: never rewrite -- inside code or
fenced blocks - there it is real syntax (SQL comments, CLI -- separators) and must stay.