create-skill

name	create-skill
description	Author a new SKILL.md from a user prompt, or migrate an existing non-spec skill to the Anthropic Agent Skills format.
license	MIT
compatibility	Requires the gini gateway.
allowed-tools	Bash file_write file_patch
metadata	{"gini":{"version":"1.0.0","author":"Gini","category":"meta","requires":{"credentials":[]}}}

Create Skill

You author new skills from a prompt and migrate legacy skills to the Anthropic Agent Skills specification. The goal is one spec-compliant SKILL.md plus optional scripts the agent can later run.

When To Use

• User asks "create a skill for X" or "add a skill that does X".
• User pastes a SKILL.md that is missing required fields or uses the legacy top-level fields (version, author, platforms, prerequisites, requires.connectors).
• User asks "make this work" while looking at a non-spec SKILL.md.

Spec Reference

Required top-level frontmatter keys (Anthropic Agent Skills spec):

• name — max 64 chars, lowercase + digits + hyphens, must equal the parent directory name.
• description — max 1024 chars.

Optional spec keys:

• license — free-form string.
• compatibility — max 500 chars; human summary of environment needs.
• metadata — arbitrary; Gini extensions live under metadata.gini.*.
• allowed-tools — space-separated list of tool names the skill plans to invoke (advisory; recorded in audit trail).

Gini extensions (under metadata.gini):

• version, author, platforms
• prerequisites: { commands, env }
• requires.credentials: [<credential-name>] — the credential names the skill needs, referenced by name (e.g. [LINEAR_API_KEY] for an api-key credential, [google-workspace-oauth] for the Google oauth2 credential). This is the current, preferred form.
• requires.connectors: [{ provider, scopes? }] — still accepted for backward compatibility during the migration window; prefer requires.credentials.

Procedure

1. Confirm the user's intent. If the request is "create a skill that posts to Slack", clarify whether the skill should also read messages, list channels, etc. — surface the cardinality so the design is right.

2. Decide whether the skill needs a credential. Use requires.credentials only when the skill needs a configured account, credential, remote API, or connector-backed local integration. Each entry is a credential NAME — LINEAR_API_KEY for an api-key credential, google-workspace-oauth for the Google oauth2 credential. Check the configured credentials in GET /api/connectors to find the right name. If the skill only needs local commands such as git, gh, jq, or curl, record those under prerequisites.commands and set requires.credentials: []. If the skill truly needs a credential that hasn't been configured yet, name it the way the credential will be stored (the env-var name for an api-key) and tell the user to add it. Do not ask the user to pick between install/skip on unknown credentials — default to forward motion. (requires.connectors: [{ provider }] is still accepted for backward compatibility, but requires.credentials is preferred.)

3. Draft the frontmatter. Use this template:

   ---
   name: <kebab-case-name>
   description: "<one-liner>"
   license: MIT
   compatibility: "<one sentence describing host requirements>"
   allowed-tools: "<space-separated tool names>"
   metadata:
     gini:
       version: 1.0.0
       author: <user-or-"Gini">
       platforms: [<macos|linux|windows>]
       prerequisites:
         commands: [<cli names>]
          []
       
         
         
         
          []
   

Migration Mode

When converting a legacy SKILL.md, the recipe is:

1. Move version, author, platforms, prerequisites, and the credential requirement under metadata.gini.*, landing on the current requires.credentials: [<name>] form. Convert legacy connector declarations to credential names:

   • requires.identities[].kind and requires.connectors[].provider → requires.credentials[] names (e.g. linear → LINEAR_API_KEY, google-oauth-desktop → google-workspace-oauth). The legacy requires.identities / kind: and requires.connectors / provider: shapes are what older SKILL.md files used; requires.connectors is still accepted for backward compatibility, but migrate to requires.credentials when rewriting.

2. Move compatibility to the top level if you can describe the host contract in ≤ 500 chars.

3. Add allowed-tools at the top level when the skill is meant to run under an agent harness that respects it.

4. Re-validate with gini skill validate before installing.

Rules

• Never write a skill without validating first.
• Always check GET /api/connectors for the credentials the new skill will depend on, and reference them by name in requires.credentials. Do not add a credential requirement for local-command-only skills.
• Bundled skills are immutable from the agent's perspective — if the user asks to edit a bundled skill, instead create a user-source copy with the same name. The runtime keeps both as separate rows.
• Do not embed plaintext API tokens or secrets in SKILL.md body.