Adapt Skill

Adapt a skill from another AI coding assistant into a properly structured Amplifier SKILL.md. The output must conform to the Agent Skills specification with Amplifier extensions and be immediately usable via /skill-name.

Inputs

• $ARGUMENTS: (Optional) Path to the source skill file or description of what to adapt.

Steps

1. Consult Skills-Assist

Before writing any skill content, load the authoritative skills reference:

load_skill("skills-assist")

Ask skills-assist about:

• Current frontmatter field reference and best practices
• Fork vs inline decision criteria
• Step annotation conventions
• Testing patterns for the type of skill being created

skills-assist is the source of truth for Amplifier skill conventions. The examples in this skill are illustrative samples — consult skills-assist for the complete and up-to-date specification.

Success criteria: You have loaded and consulted skills-assist for the latest skill authoring conventions.

2. Explore the Target Bundle

If the user wants to add the skill to a bundle (e.g., amplifier-bundle-skills), delegate to foundation:explorer to understand the bundle's conventions, existing skills, and structure. If saving to a personal or project directory, skip this step.

Success criteria: You understand the target bundle's skill conventions and can produce a skill that fits in.

3. Read and Analyze the Source Skill

Read the source SKILL.md and identify:

• The skill's purpose and core workflow
• Platform-specific tool names (e.g., Read vs read_file, AskUserQuestion vs natural conversation, Bash(mkdir:*) vs bash)
• Platform-specific paths (e.g., .claude/skills/ vs .amplifier/skills/)
• Platform-specific frontmatter fields that need mapping to Amplifier equivalents or removal (consult skills-assist for the current Amplifier field reference)
• Conventions that don't exist in Amplifier and need alternative approaches
• The interview or interaction model (does it rely on tools Amplifier doesn't have?)

Present a summary of what needs to change — grouped into natural clusters, not a wall of text. Let the user confirm the adaptation plan before proceeding.

Success criteria: You have a clear mapping of source conventions to Amplifier equivalents, and the user has confirmed the approach.

4. Research Source Platform Conventions (if needed)

If the source skill uses unfamiliar fields or conventions, research the source platform's official documentation using web search and web_fetch. Compare the source platform's spec with Amplifier's to identify:

• Fields that map directly (e.g., name, description, allowed-tools)
• Fields that map with translation (e.g., CC's model -> Amplifier's model_role)
• Fields with no Amplifier equivalent (document the gap, decide whether to drop or approximate)

Skip this step if the source conventions are already well understood.

Success criteria: You understand the source platform's skill format well enough to make accurate adaptation decisions.

5. Design the Adapted Skill

Walk through these decisions with the user, grouped into natural clusters (not one question per turn, not everything at once):

Identity and routing:

• Suggested name and description (with trigger phrases for the visibility hook — the description is the ONLY signal the model sees before deciding to load)
• model_role based on the skill's primary cognitive task (consult skills-assist for the full set of available roles)

Execution model:

• Inline vs forked (context: fork). Critical: forked skills CANNOT do multi-turn conversation with the user — the sub-agent runs once and returns. If the skill needs to interview the user, it must be inline.
• Model-invocable vs user-only (disable-model-invocation)
• allowed-tools — minimum set needed, translated to Amplifier tool names (consult skills-assist for the current tool name reference)

Save location:

…