Skill Maker

Own the requested skill outcome in one continuous workflow. A request to make and publish a skill includes authoring, validation, repository publication, a real installation and checking the public link. Do not stop at a scaffold or hand the remaining release chores back to the user.

One request should be enough. Batch independent inspection, write the coherent package together, then perform dependent validation and publication in order. Reuse established repository and installer facts rather than rediscovering them every time. This is a workflow, not a promise that Git, installation and indexing can happen in one tool call.

Resolve only what matters

Infer the purpose, representative request, destination repository, audience and publication scope from the conversation and existing skills. Ask only for missing information that materially blocks the requested result; continue independent work while waiting. Choose a clear lowercase hyphenated name when the user delegates naming.

Inspect the target repository instructions and existing work before changing it. Preserve session ownership, dirty files, existing skills, authentication and remotes. Use an owned worktree for shared repositories. Prefer updating the existing skill over adding overlapping skills with competing triggers. For managed or bundled skills, keep the maintained extension in user-owned source and use a small explicit routing hook if the user requests integration; report that managed updates may replace the hook.

Local creation is not permission to publish. A request to publish authorizes that requested destination and package, subject to the project's release gates. Reuse approval already given; do not infer authority to release unrelated code, make a private repository public or expose its history.

Author the useful package

Create skills/<name>/SKILL.md for a repository collection, or the host's discoverable user skill directory for a local-only skill. Use YAML frontmatter with name and description. Make the description explain the actual capability and when to select it. Use a license field only when the package has that license.

Write the decisions another capable agent needs: intended outcome, operating steps, concrete permission boundaries, completion evidence and recovery from likely failures. Preserve the user's scope and project-specific conventions. Do not turn one machine's paths, credentials, preferred model or standing permissions into portable defaults.