daymade/claude-code-skills/skill-creator

Skill Creator

Create or improve a reusable capability, verify the user's actual outcome, and deliver the declared source, package or installed result. Start at the unfinished stage. Preserve an existing skill's name, supported work and user-owned data.

Use the current user's authorization and actual host capabilities before these defaults. A tool's availability, a long conversation or the word “optimize” does not authorize history access, new capabilities, agent fan-out or publication.

Resolve the task before acting

1. Identify the result, supported inputs, triggers, authorized deliverables and

stopping condition from the conversation. Ask only for information or a real unresolved choice that changes the work; reuse answers and existing authorization. Distinguish creating a skill, editing one, optimizing this creator and doing a one-off task. Do not turn the last into reusable tooling without authorization.

1. Find the existing owner before creating or reallocating a capability. For that

decision, search current project and installed/source skills by capability vocabulary, including project skills and profiles; verify coverage before claiming none exist. Read the ownership decision. For a narrow edit with unchanged ownership, retain the verified mapping and proceed. Reuse the maintained execution owner and keep our verified increment with the workflow that needs it; preserve the dependency update path. Keep distinct permission or lifecycle boundaries distinct.

1. Establish canonical source ownership before writing; see

Edit Skills at Source Location. For an existing skill, freeze its complete bundle and inventory its jobs, interfaces, failure/recovery cases and variants before the first edit; see Step 4.

1. List the proposed changes, then select the lowest verification tier that can

falsify them. Keep evaluation authorization separate from risk classification. Record the tier, reason and default evidence in the existing plan/TodoList when available. Add generic eval JSON/viewer tasks only after that pipeline is authorized. Continue with the applicable source workflow below, retaining the common gates.

Verification depth router (run before choosing any workflow)

Read change verification before classifying a change or launching evidence work. Apply its complete boundaries:

Materially adding or rewriting a reference changes the runtime loading surface: start at Tier 2, escalating for a Tier-3 trigger. A long file, subjective output, uncertain scope or an additional benchmark request does not determine the tier.

Paired evaluation is separately authorized. Run it when the user explicitly requests A/B, baselines, benchmarking, repeated trials, a viewer or multi-agent evaluation; otherwise explain the decision it would resolve and obtain opt-in. Declare distinct roles, necessary isolated arms/shards, total units and capped concurrency before launching. Do not pre-launch downstream grading/viewer work. Cancellation stops the heavy pipeline and remains in force until reauthorized; retain necessary safety, preservation and the independently required review.

Select source workflows without losing the lifecycle

These are source and execution adaptations, not mutually exclusive products. Classify verification and establish ownership before any specialized exit. Return from the selected workflow to compatible editing, validation and delivery gates; record which generic mechanics its verification protocol replaces.

An ordinary optimization does not authorize earlier-history mining. Do not open raw transcripts in this context or send raw paths/content to agents. No history access is a valid route when the live conversation and current bundle suffice. For approved artifacts, admission requires the user's endorsement; “registered” is not “distilled,” and approval of facts is not approval of a reusable template.

Ground the draft and its execution

Before adding technical or methodology claims, read grounding these claims. Verify landed claims against the actual target ref, not its commit message. Retrieve the current official authoring practices and read the applicable phases of development methodology before authoring. Retrieve established domain methods as well as infrastructure prior art; preserve the user's private methodology. Verify technical assertions against observed behavior/current authority, or mark their evidence limits. Treat “unsupported” as a hypothesis and investigate alternative documented paths.

• For external facts, code/config/SOP changes or validation warnings, follow

knowledge grounding and document alignment. Update directly affected examples/help/docstrings before the first freeze; live, replay and synthetic evidence support different claims.

• When an affected job depends on another Skill/tool, required data or permission,

installation, account setup, a service or a human step, follow first use and recovery before drafting. This includes instruction-only handoffs across owners; classify by the executed job, not whether the bundle contains scripts. Use the intended-consumer boundary when choosing readiness and result evidence. Probe readiness, execute authorized preparation, resume from the first unmet condition and verify the original usable result. Skip this route for reference-only work or self-sufficient transforms only when no execution prerequisite is affected.

• For persisted formats/partial updates, permission-sensitive checks or large

command output, follow the affected stateful verification recipe. A truncated response is not a complete read; use its complete-read recipe. For provider/default-route/enable-switch changes, use its Operational route changes recipe: preserve the original user result and exercise the actual downstream consumer, including asynchronous/device removal and human-review exits. A reachable pointer alone does not prove the handoff runs.

• For any necessary review/eval input copies, declare exact immutable inputs,

cumulative bytes, reserve and session owner, then use materialization prepare → run → finish. Finish after success, failure or interruption; preserve modified inputs/evidence.

• For overlapping installed skills, follow

precedence and coexistence. Run the official-creator presence check there; absent/already configured means continue silently. Installing a global routing hook requires authorization.

Use imperative instructions, clear failure/recovery exits and observable command outcomes. Keep one canonical definition per contract; place conditional detail under its owner with an action-time loading pointer. Keep user-mutable data outside update-owned bundles. Match instructions and verification to the actual host and production reader, rather than assume one host's tools or renderer apply everywhere.

CRITICAL: Edit Skills at Source Location

Read source location and activation before source checks or availability claims. Treat user skill directories, symlinks and plugin caches as installed entries until ownership proves otherwise. Use the fixed command entry for bundled tools from another directory, with absolute artifact paths:

python3 <skill-creator-dir>/scripts/creator.py source_contract check-path <skill-dir> \
  --phase create --repo <source-worktree> --scope marketplace

Stop before writes on invalid or unknown; do not guess an owner. Linked worktrees must name their own repository root while retaining the registered Git identity. Use --scope project for project-local skills. Source, installed identity and a fresh host's actual consumption remain separate observations.

Run bundled Python tools in the creator's locked uv project with uv run --frozen; check prerequisites for the phases actually selected. Reuse the shared cache and project-local environment; do not add per-call overlays for locked dependencies or clean caches as part of ordinary skill work.

Step 4: Edit the Skill