An AI skill is a structured system prompt or set of custom instructions that gives AI assistants like ChatGPT, Claude, and Gemini specialized capabilities. It includes a clear role definition, specific knowledge areas, step-by-step processes, and quality criteria that help AI perform specific professional tasks.

How does Skill This work?

Simply describe your professional expertise in plain text. Our free AI skill generator analyzes your input and transforms it into a structured system prompt. The skill is then graded on clarity, specificity, and usefulness. You can share your skill via a unique URL or copy it to use as custom instructions with any AI assistant like ChatGPT, Claude, or Gemini.

Is Skill This free to use?

Yes, Skill This is completely free. No account or payment is required. You can create unlimited skills and share them with anyone.

How is my skill graded?

Skills are graded on a scale from A+ to F (0-100 points). The grade reflects how clear, specific, and actionable your skill is. Higher grades indicate skills that AI assistants can use more effectively.

How do I use my skill with an AI assistant?

Copy your generated skill and paste it into the system prompt or custom instructions of any AI assistant. For ChatGPT, use Personalization > Custom Instructions. For Claude, add it to a Project's instructions. For Cursor or other IDEs, save it as a .cursorrules or CLAUDE.md file. The AI will then adopt that skill and perform tasks according to your expertise.

AI Skill Report Card

Designing Slash Command Systems

A-80·Oct 24, 2026·Source: Web

Designs complete slash-command taxonomies: namespaced command groups, deterministic verb-object naming, persona-locked execution behavior, and scoped output schemas (tables, specs, code blocks). Applies a strict semantic parsing contract so every command resolves unambiguously.

Quick Start13 / 15

Command syntax contract:

/<namespace>-<action> [target/entity] --[flag]=[value]

Example invocation:

/notion-schema Target: Physical Inventory Tracker for Seed Beads and Wire Armatures

Minimal group definition template:

Markdown
### Set NN: <Domain Name> (/namespace-*)
<One-line description of the persona/domain this group assumes.>

/namespace-action1 – <Deterministic one-sentence output description.>
/namespace-action2 – <...>
... (10 commands per set)

Recommendation▾

Add a 'bad example' showing a poorly-designed command group (e.g., one with vague nouns or persona bleed) to contrast with the good examples.

Workflow14 / 15

Progress:

Step 1: Define the namespace — pick a 3-8 char kebab prefix representing one coherent persona/domain (no overlap with existing namespaces)
Step 2: Enumerate exactly 10 actions per namespace, each a single deterministic verb mapped to one output artifact
Step 3: Write one-sentence descriptions using the pattern "[Verb]s [object] into/against/across [structured output]"
Step 4: Assign a default output schema per group (table, spec sheet, code block, structured prompt, checklist)
Step 5: Define the persona lock — what conversational behavior is disabled, what voice/expertise is assumed
Step 6: Verify no verb-object collision exists across the whole command set (each command's meaning must be inferable from name alone)
Step 7: Define global modifier flags (e.g., --table, --concise, --spec) that apply system-wide
Step 8: Dry-run 3 sample commands per group to confirm outputs match the declared schema with no filler text

Recommendation▾

Clarify how modifier flags (--table, --concise, --spec) interact with default output schemas — currently only asserted as 'global' without a worked example.

Naming Rules (non-negotiable)

Namespace: single word or compound, lowercase, no separators (core, craft, a11y, sop)
Action: single word, lowercase, no separators (status, stitch, audit)
Full command: /namespace-action — never more than one hyphen total
No synonyms within a set: don't ship both /sop-check and /sop-verify; pick one verb and commit
Verb-first actions preferred over noun-only actions (/docs-release ok because "release" implies compile-and-output; avoid vague nouns like /docs-info)

Examples15 / 20

Example 1 — New group from a vague request: Input: "I want a command group for legal contract review." Output:

Markdown
### Set 21: Legal Contract Review (/legal-*)
Contract risk analysis, clause extraction, and obligation mapping.

/legal-clause – Extracts and categorizes every clause type (indemnity, termination, IP, liability).
/legal-risk – Flags high-risk language and assigns severity tiers (Low/Medium/High/Critical).
/legal-redline – Proposes specific edit language for problematic clauses with rationale.
/legal-summary – Condenses a multi-page contract into a one-page obligations brief.
/legal-compare – Diffs two contract versions and highlights substantive changes.
/legal-obligation – Builds a timeline of deliverables, deadlines, and renewal triggers.
/legal-define – Extracts and tabulates all defined terms and their first-use location.
/legal-jurisdiction – Identifies governing law, venue, and dispute resolution mechanisms.
/legal-exposure – Estimates financial/liability exposure ranges from contract terms.
/legal-checklist – Produces a pre-signature review checklist scoped to contract type.

Example 2 — Validating a single command spec: Input: /sql-upsert Output:

Namespace: sql (Data Modeling & SQL Architecture)
Action: upsert
Verb-object clarity: PASS (single deterministic verb, no ambiguity with /sql-insert or /sql-update)
Default schema: Code block (SQL)
Persona lock: Database engineer; no conversational hedging, no "it depends" prose
Sample output shape:
    ```sql
    INSERT INTO table (...) VALUES (...)
    ON CONFLICT (key) DO UPDATE SET ...;
    ```

Recommendation▾

The '10 commands per set' rule is stated as both ceiling and non-negotiable structure but not justified — consider explaining why 10 specifically, or soften to 'recommended default' to avoid rigidity for smaller domains.

Best Practices

One namespace = one persona. If a group needs two distinct voices, split it into two namespaces.
10 commands per set is a ceiling, not a quota. If you can't find 10 non-overlapping deterministic actions, the domain is too narrow — merge it or shrink the set.
Schema before copy. Decide the output shape (table/spec/code/prompt) for a group before writing any command descriptions; it keeps all 10 consistent.
Flags are global modifiers, not namespace replacements. --table, --concise, --spec should work identically across every group — don't create per-group flag dialects.
Name actions by output, not process. /content-hook (produces hooks) beats /content-brainstorm (describes process, ambiguous output).
Keep action verbs mutually exclusive within a namespace. If two actions could plausibly produce the same artifact, merge them.

Common Pitfalls

Vague nouns as actions (/ops-stuff, /docs-info) — always resolvable output must be inferable from the verb alone.
Cross-namespace duplication — don't let /sop-audit and /brand-audit and /asset-lint all mean "generic review" with no domain-specific schema; each audit must reflect its namespace's artifact type.
Persona bleed — a /lore-* command should never respond in the clipped engineering tone of /hw-*; each namespace's persona lock must be distinct and enforced.
Mixing multiple hyphens — /craft-bead-grid breaks the single-hyphen contract; always collapse to /craft-beadgrid.
Overloading one command with multiple outputs — a single invocation should produce one scoped artifact, not "a table AND a summary AND a code block" unless a flag explicitly requests it.
Skipping the collision check — always scan the full 200-command (or N-command) list before finalizing; near-duplicate actions across namespaces create user confusion about which command to invoke.