Turn Into Skill
This is a packaging-and-save workflow, not a request for a proposal. A skill
is the lightweight path for a repeatable job that mostly needs guidance and
existing app actions. Use turn-into-app when the job needs a dedicated UI,
new persistent domain state, or a distinct app route.
Default behavior
- With no argument, use the current thread as the source.
- With a named skill, local workflow, transcript path, or attachment, read that
source and package it immediately.
- Do not ask the user to restate context already present in the source.
- Default to a personal skill unless the user explicitly asks for a team,
organization, or all-app skill, or passes
shared as the scope.
- If the current thread only discusses creating a skill, do not package that
meta-workflow unless the user explicitly asks for it.
- Treat an explicit
/turn-into-skill invocation as authorization to save the
resulting skill, but never overwrite an existing skill at the target path
unless the user clearly asks to update it.
1. Extract the repeatable workflow
Read the full source before writing. Reduce it to a concise working brief:
- the repeatable job and the user outcome;
- when the skill should trigger;
- required inputs, context, permissions, and integrations;
- the ordered steps and the one to three judgment-heavy decisions;
- expected outputs, verification, retry, and failure boundaries.
Preserve the useful judgment from the source, not its transcript. Do not turn
one-off answers, private data, customer data, secrets, or unverified claims into
the skill's contract. If no repeatable job can be identified, stop and report
what is missing instead of inventing generic guidance.
2. Author the skill
Create a single SKILL.md with:
- a short hyphen-case name and a description under 40 words that says what the
skill does and when to use it;
user-invocable: true so it can be selected from the app's / picker;
scope: both so the saved skill can guide the app runtime and connected
coding agents;
- concise sections for purpose, trigger, inputs, workflow, verification, and
failure or retry behavior.
Write imperative, reusable instructions. Keep exact action names, field rules,
and decision criteria when they matter. Use placeholders for credentials and
provider data. Do not paste the source transcript, large dumps, or ephemeral
thread details into the saved skill.
Choose a new slug when the target path already exists. Read an existing skill
before changing it, and update it only when the user explicitly requested an
update.
3. Save at the requested scope
Skills are resources at skills/<slug>/SKILL.md.
| User intent |
Save path |
| Just me or personal reuse |
Use the resources tool with action: "write", scope: "personal", visibility: "workspace", and the generated skill content. |
| Shared organization or app reuse |
Use the resources tool with action: "write", scope: "shared", visibility: "workspace", and the generated skill content. |
| Every workspace app |
Use create-workspace-resource with kind: "skill", scope: "all", the generated path, name, description, and content. |
| Only selected apps |
Use the workspace resource flow with scope: "selected" only when the user names the app set. |
For an all-app workspace skill, use the workspace resource action when it is
available. If the current app does not expose it, discover or delegate to the
configured Dispatch workspace agent. Do not silently save a personal skill and
report it as shared. If organization approval is queued, report that the skill
is pending approval rather than claiming it is active.
Set visibility: "workspace" for an explicitly requested saved skill. Use
agent_scratch only for temporary drafting, then promote or rewrite it before
reporting the skill as saved.
4. Verify and hand off
After saving, read the exact skills/<slug>/SKILL.md resource back at the
target scope. Confirm that the frontmatter name, trigger description, and full
workflow body are present. If the read-back fails or the save returned an
approval request, say so plainly and include the actual pending state.
Report:
- the skill name and path;
- whether it is personal, organization-wide, or selected-app;
- the trigger users can invoke from
/;
- the verification result and any approval or setup still required.
Related skills
turn-into-app — package the same source as a UI-bearing app with buttons,
agent handoffs, and a domain workflow.
create-skill — general skill format and authoring rules.
capture-learnings — lightweight memory for preferences and corrections,
rather than reusable workflows.
self-modifying-code — safety boundaries when the agent edits app source.
1---2name: turn-into-skill3description: Capture a proven thread or workflow as a reusable Agent-Native skill and save it as a personal or organization resource. Use when a user invokes `/turn-into-skill` or asks to save a workflow for reuse.4---56# Turn Into Skill78This is a packaging-and-save workflow, not a request for a proposal. A skill9is the lightweight path for a repeatable job that mostly needs guidance and10existing app actions. Use `turn-into-app` when the job needs a dedicated UI,11new persistent domain state, or a distinct app route.1213## Default behavior1415- With no argument, use the current thread as the source.16- With a named skill, local workflow, transcript path, or attachment, read that17 source and package it immediately.18- Do not ask the user to restate context already present in the source.19- Default to a personal skill unless the user explicitly asks for a team,20 organization, or all-app skill, or passes `shared` as the scope.21- If the current thread only discusses creating a skill, do not package that22 meta-workflow unless the user explicitly asks for it.23- Treat an explicit `/turn-into-skill` invocation as authorization to save the24 resulting skill, but never overwrite an existing skill at the target path25 unless the user clearly asks to update it.2627## 1. Extract the repeatable workflow2829Read the full source before writing. Reduce it to a concise working brief:3031- the repeatable job and the user outcome;32- when the skill should trigger;33- required inputs, context, permissions, and integrations;34- the ordered steps and the one to three judgment-heavy decisions;35- expected outputs, verification, retry, and failure boundaries.3637Preserve the useful judgment from the source, not its transcript. Do not turn38one-off answers, private data, customer data, secrets, or unverified claims into39the skill's contract. If no repeatable job can be identified, stop and report40what is missing instead of inventing generic guidance.4142## 2. Author the skill4344Create a single `SKILL.md` with:4546- a short hyphen-case name and a description under 40 words that says what the47 skill does and when to use it;48- `user-invocable: true` so it can be selected from the app's `/` picker;49- `scope: both` so the saved skill can guide the app runtime and connected50 coding agents;51- concise sections for purpose, trigger, inputs, workflow, verification, and52 failure or retry behavior.5354Write imperative, reusable instructions. Keep exact action names, field rules,55and decision criteria when they matter. Use placeholders for credentials and56provider data. Do not paste the source transcript, large dumps, or ephemeral57thread details into the saved skill.5859Choose a new slug when the target path already exists. Read an existing skill60before changing it, and update it only when the user explicitly requested an61update.6263## 3. Save at the requested scope6465Skills are resources at `skills/<slug>/SKILL.md`.6667| User intent | Save path |68| --- | --- |69| Just me or personal reuse | Use the `resources` tool with `action: "write"`, `scope: "personal"`, `visibility: "workspace"`, and the generated skill content. |70| Shared organization or app reuse | Use the `resources` tool with `action: "write"`, `scope: "shared"`, `visibility: "workspace"`, and the generated skill content. |71| Every workspace app | Use `create-workspace-resource` with `kind: "skill"`, `scope: "all"`, the generated path, name, description, and content. |72| Only selected apps | Use the workspace resource flow with `scope: "selected"` only when the user names the app set. |7374For an all-app workspace skill, use the workspace resource action when it is75available. If the current app does not expose it, discover or delegate to the76configured Dispatch workspace agent. Do not silently save a personal skill and77report it as shared. If organization approval is queued, report that the skill78is pending approval rather than claiming it is active.7980Set `visibility: "workspace"` for an explicitly requested saved skill. Use81`agent_scratch` only for temporary drafting, then promote or rewrite it before82reporting the skill as saved.8384## 4. Verify and hand off8586After saving, read the exact `skills/<slug>/SKILL.md` resource back at the87target scope. Confirm that the frontmatter name, trigger description, and full88workflow body are present. If the read-back fails or the save returned an89approval request, say so plainly and include the actual pending state.9091Report:9293- the skill name and path;94- whether it is personal, organization-wide, or selected-app;95- the trigger users can invoke from `/`;96- the verification result and any approval or setup still required.9798## Related skills99100- `turn-into-app` — package the same source as a UI-bearing app with buttons,101 agent handoffs, and a domain workflow.102- `create-skill` — general skill format and authoring rules.103- `capture-learnings` — lightweight memory for preferences and corrections,104 rather than reusable workflows.105- `self-modifying-code` — safety boundaries when the agent edits app source.