Claude Skills in Kiro: Portability and Setup Checks

You can move Claude skills into Kiro when they use the shared Agent Skills format, but you should check app-specific instructions before relying on them. Import the complete skill folder, adapt any unsupported behavior, and test both activation and the result. A recognizable file format does not guarantee the same workflow in a different app.

Tools like fenbs keep shared prompts and current project context outside either app, so the reusable procedure and the unfinished work have a common home. This guide focuses on moving one skill; Kiro vs Claude Code covers the broader choice between the tools.

How do you move a Claude skill into Kiro?

Start with one small workflow whose output you can inspect, such as turning approved changes into release notes. Avoid making a complicated publishing procedure your first compatibility test. Keep the original folder while you make a separate copy for adaptation.

1. Read the whole skill, including referenced files and scripts. Identify what it reads, what it changes and what requires permission before execution.
2. Check that the folder contains SKILL.md with a name and description in its opening metadata. Preserve its references, scripts and templates when copying it.
3. In the Kiro IDE, open Agent Steering & Skills, choose +, then Import a skill, and select the local folder. Kiro also documents importing a public GitHub skill folder.
4. For a project-scoped installation, check the skill under .kiro/skills/. Kiro documents ~/.kiro/skills/ for personal skills across local projects; choose the intended scope.
5. Resolve the compatibility checks below, then try the skill on sample input. Review the resulting changes before using the procedure on real work.

These locations and import options come from Kiro’s Agent Skills documentation↗ (opens in a new tab). If you still need to build the source procedure, use how to create a Claude skill; importing an existing skill does not require redesigning its purpose.

For a closer look at the source package before importing, see the guide to Claude skill files.

Which parts of a skill can you carry over?

The Agent Skills specification↗ (opens in a new tab) defines a folder with SKILL.md, opening metadata and instructions, plus optional supporting resources. Its name and description identify the procedure and when to use it. Think of that common structure as packaging: you still need to inspect the contents and the tools they expect.

Claude Code extends the common standard with features such as invocation controls, separate assistant execution and dynamic command output in instructions. Treat those as review points rather than assuming Kiro interprets them identically. Claude Code’s skills reference↗ (opens in a new tab) distinguishes its extensions from the standard fields.

How should you adapt the instructions?

Keep the goal, required inputs and definition of a good result. Rewrite the parts that describe how one app performs the job. For example, “use my release-note command” leaves the destination app guessing; “read the approved change summary and draft a release note without publishing it” defines a result you can check.

Separate permanent procedure from temporary project facts. A release-note skill can explain the required headings, but the current release date and approved changes belong with that release. Otherwise, moving the skill also moves stale assumptions. For examples of narrowly defined procedures, see Claude skills examples.

Write down why you changed each instruction. Keep the approved wording in fenbs Skills and prompts, with a note explaining any local adaptation, so someone reviewing the next copy can understand the difference.

How can you verify that the skill works?

Check discovery, activation and output separately. Seeing a skill in a list proves that the app found it; it does not prove the assistant followed its steps. Kiro documents automatic activation from the description and direct invocation through a slash command in its skill usage guide↗ (opens in a new tab).

• Direct check: invoke the skill by name on a small sample. Confirm that the output follows its required structure and uses the supplied facts.
• Natural request: ask for the same job without naming the skill. Inspect whether the procedure was loaded rather than accepting the assistant’s claim that it remembers it.
• Boundary check: ask an unrelated question. The skill should not force its template onto work outside its purpose.
• Missing-input check: remove one required fact. Confirm that the assistant asks for it or marks it unknown instead of inventing an answer.

For the release-note example, compare both apps using the same fictional change summary. Check that neither invents a launch date, that both distinguish fixes from additions, and that neither publishes anything. Record what you observed, including a failure, without treating one successful attempt as a permanent guarantee.

What should you check when the imported skill fails?

Locate the first failed step. If the skill is missing entirely, inspect its location, filename and opening metadata. If it appears but does not activate, compare your request with the description. If it activates and then stops, inspect the referenced file, command or missing input at that point.

Avoid fixing every failure by adding more instructions. A missing program requires an environment change; a missing project decision requires an answer from a person. Repeating “follow the skill carefully” does not provide either. Preserve the exact failing input and the expected result so you can rerun the useful check after a change.

What context should stay outside the skill?

Keep the procedure reusable and the work record current. Save the project goal, decisions, unfinished tasks and next step separately from the skill folder. A copied workflow cannot tell the next assistant which draft a person approved yesterday unless you supply that fact.

For a hypothetical studio, the skill might describe how to review a handoff. The project record says the client approved the shorter form, one accessibility check remains, and publication is waiting on a person. That distinction matters whenever you switch AI tools: move the method and refresh the facts.

How to do this with fenbs

1. Create a free account and add the project whose workflow you want to reuse. Start with the actual next task rather than a whole prompt collection.
2. Save the approved reusable instructions in Skills and prompts. Record decisions people made in Decisions and rules, keeping unsettled choices open.
3. Use Integrations to connect a supported assistant, such as Claude Code. Ask it to read the project context before adapting the instructions; supply the relevant text and current facts to Kiro yourself.
4. Record the compatibility checks and results with the task. Save Where we left off before stopping, including which adaptation worked, what failed and the next check.

fenbs does not install a skill in Kiro or make its commands compatible. If you only need one local procedure and have no work to share between sessions, a skill folder may be enough. Use the shared record when keeping approved instructions and project facts aligned becomes the harder part.