lov-skill-creator

lov-skill-creator

Create every Skill as a portable local source directory named {name}-skill, bind it to the shared user-profile/v1 contract, validate it, and install it into the user's local agent skills directory as lov-{name}. Remote repositories, catalogs, marketplace packages, uploads, and live-channel verification belong to lov-skill-publisher.

Triggers

Activate when

The user wants to "create a skill," "package it as a skill," "generate a Skill Kit," or optimize the Skill generation mechanism.
The user asks to create, scaffold, validate, or locally install an Agent Skill.
The user wants to fully migrate Claude Code's early slash commands into general-purpose Skills, or upgrade an old migration result that only changed file names.

Do not activate when

The user is merely invoking an existing Skill to complete a business task.
The user wants to publish to a remote repository, list in a directory, generate a platform distribution package, or upload a Skill; hand off to lov-skill-publisher。

Architecture

<configured local source root>/
└── {name}-skill/
    ├── SKILL.md
    ├── README.md
    ├── CHANGELOG.md
    ├── LICENSE
    ├── kit.yaml                 # Skill Kit only
    ├── skills/                  # embedded modules, Skill Kit only
    ├── scripts/                 # deterministic local CLIs
    ├── references/              # progressive disclosure
    └── assets/                  # reusable output assets
    ├── skill-card.yaml          # machine-readable trust/release record
    ├── skill-card.md            # human-readable Skill Card
    ├── cases/cases.json         # real Input → Prompt → Output evidence
    └── pricing-card.yaml        # value, boundary, and review basis

<agent skills directory>/
└── lov-{name} -> <local source root>/{name}-skill

Key rules:

Creation ends with a validated, locally discoverable Skill.
Source frontmatter name is lov-{name} and uses kebab-case.
Source top-level fields are limited to name, description, license, compatibility, allowed-tools, depends_on, and metadata.
Required modules live inside a Skill Kit; no external sibling dependencies.
User-specific values come from flags, environment, or a portable profile.
Every generated Skill declares and reads a shared user Profile across sessions; Skill-specific durable records live under skills.<skill_id>.records.
A direct user statement about a durable preference or brand fact is persisted through the generated scripts/profile_store.py entrypoint and reported back.
Every new Skill carries a real user case, a dimension map, a pricing basis, and explicit paid/free distribution states. A scaffold is incomplete until those records are filled and validated.
Skill Publisher is a possible profile value, never a separate implementation mode.
Do not create remotes, releases, catalogs, platform packages, or uploads here.
If the Skill generates, edits, reviews, renders, packages, or publishes text visible to an end user or reader, declare lov-branding-consistency in its top-level depends_on. Preserve source data, quotations, transcripts, legal text, identifiers, and code unless the user explicitly asks to rewrite them.
Classify normal output as authored-prose, microcopy, verbatim, or deterministic-output before scaffolding. Authored prose receives an authorship-integrity contract; microcopy receives branding review; verbatim material remains source-faithful; deterministic output is accepted on correctness and completeness.

Creation Workflow

Step 0: Route legacy command migrations

For raw command files, command directories, archived commands, or partially migrated Skills, first read Slash command migration. Inventory the full requested scope, resolve aliases and existing capabilities, then upgrade each canonical source through the normal workflow below. Use scripts/migrate_command.py for read-only inventory and isolated preparation. Do not treat renaming Markdown, removing host switches, or generating a scaffold as completed migration. A website synchronization request includes the publisher handoff after validation; keep each item's local and live evidence separate.

Step 1: Infer the product shape

Use the request, memory, repository, and supplied examples before asking anything. Ask one question at a time only when a missing answer changes the user-visible outcome. Never ask users to choose technical machinery.

Record these decisions internally:

Problem, supported input, and concrete output.
Two or three realistic examples and Chinese plus English trigger phrases.
Internal context versus content that belongs in the final user-facing result.
Public layer versus protected logic, prompts, keys, rules, or data.
The first real user case: input, minimum prompt/brief, output, and evidence assets. Do not manufacture a case or score to make the card look complete.
The normal output class:
- authored-prose for articles, reports, scripts, letters, and prose where reasoning and editorial choice are part of the result;
- microcopy for labels, descriptions, prompts, notices, and short UI text;
- verbatim for transcripts, quotations, legal text, identifiers, and other source-faithful material;
- deterministic-output for retrieval, storage, deployment, diagnostics, structured data, and binary transformation.
Use --content-class authored-prose or --authored-prose for the first class. Authored prose and microcopy automatically enable lov-branding-consistency; authored prose also generates and routes to references/authorship-integrity.md.

Background details, personal names, and competitor observations are context by default. Include them in generated products only when they serve the end user.

Step 2: Infer implementation and composition

Choose automatically and briefly state the result:

Cloud handler — sensitive proprietary logic must stay off the user's disk.
Instruction-only — judgment, research, conversation, or generation has no useful deterministic local transform.
Python CLI — repeatable parsing, conversion, validation, packaging, or file generation benefits from deterministic execution.
Single Skill — one outcome, or several modes sharing the same context.
Skill Kit — two or more independently useful stages with their own input/output contracts are composed through named pipelines.

Scripts alone do not justify a Kit. Prefer Single when modularity is marginal. For a Kit, list module IDs and named pipeline order before scaffolding.

Step 2.5: Analyze the nearby Skill group before creating a new one

Before scaffolding, inspect the local Skill source root and installed Skill catalog for related capabilities, using their routing descriptions and actual input/output contracts rather than names alone. Record the outcome in references/skill-composition.md for every generated Skill.

Classify each relevant Skill as one of:

upstream atom — independently produces an approved input for this Skill;
core atom — this new Skill owns the requested user-visible outcome;
downstream atom — independently consumes the verified output;
overlap — owns the same outcome and should be extended or selected instead of duplicated; or
not composed — adjacent in topic but adds no meaningful handoff.

For each proposed handoff, state the concrete artifact or contract, the invocation boundary, and who owns the final acceptance criterion. Do not create an external sibling dependency merely because another Skill is related. If multiple stages are required for one user-visible outcome, embed them as a self-contained Skill Kit; otherwise keep the new Skill standalone and describe optional handoffs explicitly. A no-composition conclusion is valid only after the nearby group was inspected.

Step 3: Declare the user Profile contract — always

Every new Skill receives a skill.yaml declaration for user-profile/v1, even when its first invocation has no missing configuration. This is the cross-session connection point for:

user identity, language, timezone, and working defaults;
brand name, website, logo, tone, profile, and design guidance;
workspace/project roots and output locations;
Skill-specific defaults and durable records.

The generated contract reads the shared Profile and writes direct user statements into skills.<skill_id>.records (or the shared user / brand scope when the value is explicitly global). It uses this precedence:

Explicit CLI flags or current request.
Environment variables.
Shared profile JSON.
Safe inferred defaults.
Ask once for only the remaining user-facing values.

When the user directly states a value intended for future sessions, run the generated scripts/profile_store.py record ... --confirm command and report the canonical saved path. Inferred values stay in the current request context.

Every generated Skill remains portable. Never introduce an author-only or Skill Publisher-only branch; different users supply different profile values.

Step 4: Plan contents

Deterministic operations → scripts/ as standalone argparse CLIs.
Domain knowledge → references/.
Reused output files, templates, fonts, or icons → assets/.
Independently triggerable stages → embedded skills/ plus kit.yaml.
User Profile contract → skill.yaml, references/user-profile.md, and the standalone scripts/profile_store.py reader/writer; this is always generated.
Skill trust evidence → skill-card.yaml, skill-card.md, cases/cases.json, and pricing-card.yaml.
Skill group decision → references/skill-composition.md, including nearby Skills inspected, atomic handoffs, overlap decisions, and the final Single-versus-Kit rationale.
Authorship integrity → references/authorship-integrity.md for authored-prose, including a source ledger, seven discourse checks, and explicit non-fabrication boundaries.

Python scripts must be standalone files without package scaffolding. Treat CJK text handling as a core requirement for document and content workflows.

Step 5: Initialize locally

Single Skill:

python3 "$SKILL_DIR/scripts/init_skill.py" <name> \
  --content-class deterministic-output \
  --install-dir "$SKILL_SKILLS_INSTALL_DIR"

For articles, reports, scripts, letters, or other authored prose:

python3 "$SKILL_DIR/scripts/init_skill.py" <name> \
  --content-class authored-prose \
  --install-dir "$SKILL_SKILLS_INSTALL_DIR"

Use microcopy for short audience-visible text, verbatim when source fidelity owns acceptance, and deterministic-output for operational or structured results. --branding-consistency remains an explicit override for unusual mixed-output Skills.

Skill Kit:

python3 "$SKILL_DIR/scripts/init_skill.py" <name> \
  --kit \
  --module <module-a> \
  --module <module-b> \
  --install-dir "$SKILL_SKILLS_INSTALL_DIR"

When embedded stages produce different kinds of output, classify them at the module boundary instead of forcing one rule across the Kit:

python3 "$SKILL_DIR/scripts/init_skill.py" publishing \
  --kit --module research --module draft \
  --module-content-class draft=authored-prose \
  --install-dir "$SKILL_SKILLS_INSTALL_DIR"

Resolve the install directory from an explicit flag, environment variable, shared profile, or the active agent runtime. If it remains unknown, ask once. The initializer must reject an occupied install target instead of overwriting it.

Tool pit: init_skill.py only creates ~/.claude/skills/lov-{name} as an absolute symlink pointing to the true source; to conform to the Lovstudio three-layer chain convention, an intermediate layer must also be added ~/.agents/skills/lov-{name}(absolute, pointing to the true source) and install changed to a relative ../../.agents/skills/lov-{name}，readlink -f before it resolves to the true source (2026-08-20, ab88955).

Tool pit: the skills repository working tree often has a large number of uncommitted changes (other skills' WIP, submodule pointers), andgit add -A / git commit -a will sweep them into the commit; before committing, first git status, and only git add <目标 skill 目录>（2026-08-20, 99c10a0）。

Tool pit: validate_skill.py counts the description as 50–200 characters based on the "text after compact"; mixed Chinese and English easily exceeds 200; write a short version to pass validation first, then expand the body (2026-08-20, 009afde).

Tool pit: in card/case files, dict[str, list[str]] such brace literals will be mistaken by contains_placeholder 's \{[^}]+\} for placeholders; skill-card / cases / pricing files should always avoid brace notation (2026-08-20, 009afde).

Tool pit: ~/lovstudio/coding/skills/skill-creator-skill is anested independent git repository(with its own .git); the parent repository ~/lovstudio/coding/skills treats it as a single untracked directory, and changes to files inside git add from the parent repository will not take effect; to change the skill-creator source, commit within its own repository (2026-08-20, c09a0a1).

For cloud-split implementations, read references/cloud-split.md completely before coding. Keep real logic in the configured cloud handler, return minimal symbolic payloads, render symbols locally, and complete its mandatory preflight audit. Cloud deployment itself is an external publication step when applicable.

Step 6: Implement

Write the source as instructions for an agent, not as notes about this chat:

description is the routing contract: outcome, inputs, and natural Chinese plus English triggers in 50–200 characters.
Add ## Triggers, activation examples, and adjacent non-trigger conditions.
Keep SKILL.md below 500 lines; move detail to relevant references.
Put compatibility and depends_on at the top level. Keep version, tags, card standard, and package-only runtime metadata under metadata.
Keep the NVIDIA-compatible required card fields intact, then add LovStudio's user case, dimension map, pricing basis, and distribution fields.
Keep external Skills optional unless they are embedded Kit modules; expose artifact-level handoffs instead of hidden cross-Skill coupling.
Use AskUserQuestion only for unresolved user-facing product decisions.
Never hard-code private paths or personal brand data in reusable source.
Fill missing visual/content assets with clearly appropriate generated material when the workflow permits; ask for originals only when authenticity materially affects the result.

Human-facing README.md includes a matching version badge, local installation, the Profile contract, examples, dependencies, and quality gate.

Step 7: Validate and install

python3 scripts/validate_skill.py .

Completion requires:

Validation passes with standard YAML.
Every module, local reference, script, and asset resolves.
No unresolved placeholders, private absolute paths, cache files, or compiled Python artifacts remain.
The local install path resolves to this source directory.
A documented activation phrase works and a non-trigger stays outside scope.
Every Skill Kit module and at least one named pipeline are exercised.
Every new Skill has at least one verified Input → Prompt → Output case, three or more named dimensions with evidence, a pricing basis, and explicit paid/free channel states.
references/skill-composition.md records the inspected Skill group, atomic handoffs or overlap decision, and why the result is a Single Skill or Kit.

Stop at the local result unless the user also requests publication. When they do, invoke lov-skill-publisher with the validated source path and requested channels; do not duplicate publishing logic in this Skill.

Design Patterns

Context-aware prefill

Read the request, conversation, memory, and current project.
Prefill all supported fields.
Infer implementation and configuration modes.
Ask only for missing information that changes the user-facing outcome.

Progressive disclosure

Keep the controller lean. Split large theme systems, APIs, examples, platform contracts, and asset catalogs into directly referenced files.

Exclusions

Remote repository creation, pushes, releases, catalogs, marketplace packages, platform uploads, and live publication checks.
INSTALLATION_GUIDE.md; installation belongs in README.md.
Test-framework scaffolding for instruction-only Skills.
__pycache__, compiled Python files, .DS_Store, or unresolved placeholders.
User-specific absolute paths or an internal-only product mode.

For source templates see references/templates.md. For the Skill Card contract see references/skill-card-standard.md. For the Profile contract see references/user-profile.md. Historical migrations remain in references/migration.md.

Runtime context (shared)

Before running, read this Skill package's skill.yaml, and the host provides the skill-runtime/v1 context. The field resolution order is: current request, project context, Skill-specific records, personal Preferences, brand/user Profile, general defaults.

Use only the fields declared in the Manifest; the Profile stores shared user and brand information,skills.<skill_id>.records stores this Skill's persistent records.
Long-term preferences or brand facts stated directly by the user are atomically written back to the Profile via scripts/profile_store.py , and the save path is reported in the result.
required: true When a field is missing, ask the user one focused question according to the Manifest's question configuration.
Errors provide a copyable context_id, field path, and source; diagnostic content avoids secrets, full private paths, and raw configuration.

General feedback loop

When the user raises modification feedback during a Skill-driven task, the following must be executed before continuing the current artifact:

First determine whether the feedback is task-specific(this time only) or reusable(reusable across tasks).
task-specific Modify only the current task, not the Skill.
reusable First determine the scope: for domain rules, first update the corresponding canonical Skill; for rules applicable to all Skills, first update the shared specification.
After completing the rule update, version, lint, and distribution verification, then apply the modification to the current task.
reusable Modifying will invalidate the previous "Confirm," "Continue," and "Go ahead and send"; after completing the modification of the current artifact and reading it back, you must stop and wait for the user's next instruction, without automatically proceeding to publishing, submission, or any other external write.