| name | skill-creator |
| description | Create new pi skills from a conversation. Use whenever the user says they want to make a skill, build a skill, create a skill, save a workflow as a skill, or asks "how do I make a skill that does X" — even if they don't say the word "skill" but describe a recurring task they want to capture once and reuse. Make sure to use this skill whenever the user mentions creating, authoring, drafting, or building a skill in any phrasing. |
| license | MIT |
| metadata | {"category":"authoring","source":"Adapted from anthropics/skills/skill-creator (MIT)"} |
| triggers | ["create skill","new skill","build a skill","创建skill","新skill","写一个skill","capture workflow","reusable workflow"] |
Skill Creator
A skill that helps the user author a new pi skill. The final step always
calls the pi_skill_create tool to write
~/.innate/skills/<scope>/<name>/SKILL.md.
High-level loop
- Figure out what the skill should do and when it should trigger.
- Draft the SKILL.md (frontmatter + body) collaboratively with the user.
- Decide the scope — where the skill should live so it loads only where
it's relevant (see below).
- Call
pi_skill_create with that scope to write the file.
- Tell the user to start a new chat session (one that loads that scope) to
pick up the new skill, then try a trigger phrase to see it activate.
Choosing the scope
Scope decides which sessions load the skill. Pick the most specific one that
fits — don't default everything to the broadest scope.
desktop-shell (the default) — general Innate Desktop chats. Use for skills
that aren't tied to a particular app.common — every session, in every host. Use sparingly, only for genuinely
universal skills.components/obsidian/desktop — working a connected Obsidian vault from
Desktop (by absolute path). components/obsidian/common — Obsidian skills
that also apply inside the Obsidian sidebar.components/office/word | .../excel | .../powerpoint — skills for editing
that app inside its Office side-pane. components/office/common for any-app
Office guidance.components/zotero/embedded — skills for the Zotero side-panel;
components/zotero/common for any-mode Zotero guidance.
If the user doesn't say where, ask which app the skill is for (or default to
desktop-shell).
The user may already be partway through this loop ("here's a draft, just
save it") — meet them where they are. Don't force the full interview if
they already know what they want.
Communicating with the user
Skill creators come from across the technical-comfort spectrum. Pay
attention to context cues. In the default case:
- "frontmatter", "YAML" — briefly explain unless the user clearly
knows the terms.
- "trigger phrase", "skill body" — usually fine; explain if asked.
- Always show the SKILL.md text before calling the tool, so the user
can read it and request edits.
Step 1 — Capture intent
Ask just enough questions to draft. If the current conversation already
contains a workflow the user wants captured ("turn this into a skill"),
extract from the history first — don't ask things already answered.
Useful questions:
- What should this skill enable pi to do?
- When should pi reach for it? (what phrases / contexts / tasks)
- What output format does the user expect (free-form reply, file,
table, code, etc.)?
- Are there steps that ALWAYS happen, vs. ones that depend on context?
Don't ask all four at once. Ask the most load-bearing one, draft from
there, and iterate.
Step 2 — Draft the SKILL.md
A skill is a single markdown file with YAML frontmatter:
---
name: <kebab-case-name>
description: <one-line summary of when to use and what it does>
---
<body in markdown — instructions for the model when this skill is active>
The name field
Short kebab-case. Same as the folder name pi-office will create. No
spaces, no slashes, no dots, no leading underscore. Examples:
weekly-status-report, meeting-notes-summarizer, python-test-fixer.
The description field (most important)
Pi shows the name + description in its "available skills" list and uses
the description to decide whether to consult the skill for a given user
request. So this field IS the trigger.
A good description states what the skill does AND when to use it, in
that order. Pi tends to under-trigger skills (defaults to handling
things itself), so be a little forward about when to use it. Example:
Generate a weekly status update from raw notes. Use whenever the user
asks for a status report, weekly update, EOW summary, or wants their
raw notes turned into a structured weekly recap — even if they don't
use the word "report".
The body
The body is what pi sees once the skill activates. Keep it under ~500
lines. The body is for the how (the procedure, the format, the rules);
the description handles the when.
Useful patterns:
- Imperative voice ("Pull the highlights, then group by project").
- A short ## Output format section with a literal template the model
should follow.
- One or two ## Example sections (Input + Output).
- Explain why rules matter when you write them — pi follows
reasoned guidance better than blanket "ALWAYS / NEVER" directives.
What to leave OUT of the body:
- Hardcoded user data (names, paths, secrets).
- Triggering instructions (those belong in
description).
- Long generic preambles ("You are a helpful assistant…").
Step 3 — Write the file
Once the user approves the draft, call:
pi_skill_create(
name="<kebab-case-name>",
description="<the frontmatter description, one line>",
body="<everything below the frontmatter, including the # Title>",
scope="<one of the scopes above; omit for desktop-shell>"
)
The tool writes the file under ~/.innate/skills/<scope>/<name>/SKILL.md
and sets file mode 0600. If a skill with the same name already exists in
that scope, the tool refuses by default; the user can rename or delete the
old one and try again.
Step 4 — Test it
After the file is written, tell the user:
- Open a new chat (the "New session" button) — pi only loads skills
at session start.
- Try a phrase from the skill's description, like "give me a weekly
status update from yesterday's notes".
- If the skill doesn't trigger, sharpen the description: add more
concrete user phrases the skill should match. The body usually
doesn't need changes; the description is what governs triggering.
Anti-patterns
- One-shot prompt squashed into a skill: skills are for reusable
procedures, not single-use answers. If the workflow only fires once,
the user is better off just chatting.
- Skill that just restates "be helpful": if the body doesn't add
procedure beyond what pi already does by default, the skill provides
no value. Skip it.
- Description that names the skill but not the trigger: e.g.
"Helps with weekly reports" doesn't tell pi when to consult it.
Always say "Use when the user…".
Notes
This skill is bundled with Innate under innate-skills/common/skill-creator/.
It is a read-only built-in: the user can't disable or edit it from the UI, and
user skills under ~/.innate/skills/ can't override it (built-in skill dirs are
passed to pi before the user's, and a name collision resolves to the first one
loaded).
Adapted from anthropics/skills/skill-creator (MIT). The original
includes evaluation harness, benchmark scripts, and description
optimization — those depend on subagents and CLI tooling not present
here, so they've been removed.
