# Lisa Parity Skill Creator > Author a new Lisa skill end-to-end — scaffold the SKILL.md frontmatter (name/description/allowed-tools), write the pass-through command, follow hyphen naming, place files under plugins/src/base, and rebuild plugins. Lisa-native reimplementation of the upstream skill-creator plugin. NO drift pin: upstream publishes no semver, so it is not drift-trackable. - Skill: `codyswanngt/lisa-parity-skill-creator` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add codyswanngt/lisa-parity-skill-creator` - Raw SKILL.md: https://api.skillmd.com/api/skills/codyswanngt/lisa-parity-skill-creator/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: codyswanngt (https://skillmd.com/u/codyswanngt) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/codyswanngt/lisa-parity-skill-creator --- # Skill Creator Author a new, working Lisa skill (and its pass-through command) from a one-line description. This is the Lisa-native equivalent of the upstream `skill-creator@claude-plugins-official` plugin, reimplemented from scratch against Lisa's conventions so the same capability is available to the Codex, agy, and Copilot runtimes (Cursor reads `.claude-plugin/` natively). ## Not drift-trackable This skill intentionally carries **no `synced-from` pin**. The upstream `skill-creator` plugin publishes **no semver** (its cache version resolves to `unknown`), so a `@unknown` pin would be unparseable and meaningless to `scripts/plugin-parity-drift.mjs`. **Drift is tracked manually** — re-review the upstream plugin by hand whenever the curated plugin set is refreshed. Do **not** add a `synced-from` line to skills generated by this skill unless they reimplement a semver-versioned upstream plugin. ## When to use - A reusable workflow, checklist, or piece of domain knowledge keeps recurring and deserves a named, invokable skill. - You are reimplementing an upstream third-party plugin command/skill for cross-agent parity (see `analyze-plugin` / `implement-plugin-parity`). - The user asks to "create a skill", "add a command", or "scaffold a skill". If the knowledge is narrow or one-off, prefer a rule in `.claude/rules/` instead — skills are for broad, repeatable capabilities. When unsure whether content warrants a skill, run it past the `skill-evaluator` agent first — it is the six-rung ladder router, a skill is only one rung, and it may recommend a cheaper or stronger destination instead. ## Where skills live Lisa skills are **build output** for downstream projects. The source of truth is `plugins/src/`, never the generated `plugins/lisa*` artifacts: | Source directory | Builds artifact | Use for | | --- | --- | --- | | `plugins/src/base/` | `plugins/lisa` | Skills that ship to **every** stack | | `plugins/src//` | `plugins/lisa-` | Stack-specific (typescript, expo, nestjs, cdk, harper-fabric, rails) | Lisa-repo-only skills (parity tooling, wiki ingestion, `lisa-*` meta-skills) live at the **root** `.claude/skills/` and `.claude/commands/`, NOT under `plugins/src` — they are not relevant to downstream projects. Decide placement first: - Ships to downstream projects → `plugins/src/base/skills/lisa-/SKILL.md` - Only meaningful inside the Lisa monorepo → `.claude/skills//SKILL.md` ## Naming - Base-plugin skills use the **`lisa-` prefix** on the directory and frontmatter `name`: `lisa-implement`, `lisa-git-commit`, `lisa-tracker-write`. No spaces, no camelCase, no underscores. - The directory name and the frontmatter `name` must match exactly. - Commands live flat under `commands/` — Claude Code prefixes plugin commands with the plugin name, so `commands/git/commit.md` → `/lisa:git:commit` and `commands/implement.md` → `/lisa:implement`. (Per-agent variant generators nest them under `commands/lisa/` for harnesses without plugin-name namespacing; never author that nesting in source.) - **Commands** surface as `/lisa:*` (colon). **Skills** surface as `/lisa-*` (hyphen). Never share a bare name like `implement` across both surfaces. ## SKILL.md frontmatter Skills support **only** these frontmatter keys (they do **not** support `argument-hint` or `$ARGUMENTS` substitution — those belong on the command): ```yaml --- name: lisa-my-skill # required — matches the directory name description: "One or two sentences." # required — when to use + what it does allowed-tools: ["Read", "Edit", "Write", "Bash"] # optional — least privilege synced-from: @@ # ONLY for semver upstream reimplementations --- ``` - **`name`** — the hyphen identifier, byte-identical to the directory. - **`description`** — write it so the model knows *when* to reach for the skill, not just what it does. Lead with the trigger. This is the single most important field for discoverability. - **`allowed-tools`** — grant the minimum set. A read-only review skill needs no `Write`/`Edit`. Omit the key entirely to inherit the caller's tools. - **`synced-from`** — add **only** when the skill reimplements an upstream plugin that publishes a real semver. Grammar: `name@marketplace@version` (e.g. `sentry@claude-plugins-official@1.0.0`). Omit for upstreams with no semver (note that in the body instead, as this skill does). ## The command pass-through pattern Every skill should have a thin command that is the user-facing entry point. Commands support `description`, `argument-hint`, and `$ARGUMENTS`; they delegate straight to the skill: ```markdown --- description: "Same human-facing summary as the skill, phrased for the picker." argument-hint: "" --- Use the /lisa-my-skill skill to . $ARGUMENTS ``` The command carries the `argument-hint` and forwards `$ARGUMENTS`; the SKILL.md carries the actual logic. Keep the two descriptions consistent. ## Scaffolding walkthrough 1. **Decide placement** — downstream (`plugins/src/base`) vs. Lisa-only (`.claude`). For base, both a skill and a command directory entry are needed. 2. **Pick the name** — `lisa-`, hyphenated, unique. Check it does not collide: `ls plugins/src/base/skills/` and `ls plugins/src/base/commands/`. 3. **Create the skill** at `plugins/src/base/skills/lisa-/SKILL.md` with the frontmatter above and a body that follows house style — see `plugins/src/base/skills/lisa-quality-review/SKILL.md` for the canonical shape (title, "When to use", numbered checklist/steps, explicit "Rules"/"Output" sections). Write real, actionable guidance, not TODOs. 4. **Create the command** at `plugins/src/base/commands/.md` (or a nested `commands//.md` for a colon-namespaced command) using the pass-through template. 5. **Rebuild the artifacts** so the generated plugins match source: ```bash bun run build:plugins ``` Then commit **both** `plugins/src/...` and the regenerated `plugins/lisa*`. The `🧩 Plugins Sync` CI check (and `bun run check:plugins` locally) fails if artifacts drift from source — never hand-edit `plugins/lisa*`. 6. **Verify discoverability** — confirm the skill appears as `/lisa-` and the command resolves to `/lisa:` (or `/lisa::` when nested). ## Body house style - Open with an `#` H1 title in Title Case. - Add a `## When to use` section that names the triggers. - Use numbered steps for procedures, checklists for review-style skills. - End with an explicit `## Rules` (hard constraints) and/or `## Output` section. - Write in plain, imperative English. Prefer concrete examples over abstraction. - Reference sibling skills by their hyphen name (e.g. "delegate to `lisa-git-commit`"). ## Rules - Never edit `plugins/lisa*` directly — edit `plugins/src/` and rebuild. - Skill frontmatter must not contain `argument-hint` or `$ARGUMENTS`. - The directory name, `name` field, and command filename must match exactly. - Add `synced-from` **only** for semver-versioned upstream reimplementations. - Do not include `/coding-philosophy` in task `skills` metadata — it auto-loads. - One skill, one responsibility. If a skill grows two jobs, split it.