skillify

name	Skillify
description	Interview the user about a workflow they keep repeating, then generate a reusable SKILL.md and write it to disk so the next session starts with the skill already loaded.
category	meta
effort	medium
when_to_use	When the user says "we keep doing this same flow" or "can we make this a slash command" or "every time I onboard, I run these same five commands". The trigger is recognising a *repeated* workflow worth capturing — not one-off requests.
allowed_tools	["Read","Write","Bash"]
shell	bash
shell_timeout_s	10
version	1.0.0

Skillify — capture a repeated workflow as a skill

You are going to interview the user, distill what they keep doing into a SKILL.md, and write it to the right place on disk. The output lives at ~/.geny/skills/<id>/SKILL.md (user-scope) or <project>/.geny/skills/<id>/SKILL.md (project-scope) depending on how broadly the workflow applies.

Step 1 — Sniff the context

Before asking anything, glance at the recent conversation. The workflow being captured is probably something the user just did (or just asked to redo). If you can already infer the shape, lead with a one-sentence summary and ask the user to confirm.

# Where would the project-scope skill go?
[ -d .geny/skills ] || mkdir -p .geny/skills
echo ".geny/skills/ ready under $(pwd)"

Step 2 — Interview

Ask, in this order, one question at a time. Wait for an answer before the next question. Don't ask all at once — operators get overwhelmed and answer poorly.

1. What should this skill do, in one sentence? This becomes the description frontmatter field. Push back gently if the answer is vague — "produces a report" is too broad; "produces a markdown summary of changed files between two git refs" is right.

2. What's a short id? kebab-case, ≤ 32 chars, must match [a-z0-9][a-z0-9_-]*. Suggest one based on the description if the user shrugs.

3. What arguments does it take? Ask for argument names and a one-line hint. If none, that's fine — many skills are parameterless.

4. Which tools does it need? Pick from the host's actual tool roster (Read / Write / Bash / Edit / Grep / Glob, plus any custom). Default to [Read, Bash] if the user is unsure.

5. When should the model use it? This is the when_to_use field — extra discovery copy beyond the description. Examples: "When the user asks for a release-note draft."

6. User scope or project scope? User scope if it applies regardless of which repo they're in (e.g. "PR draft generator", "verify"). Project scope if it depends on this codebase's layout (e.g. "run the project's specific test sweep").

Step 3 — Show the draft

Echo the proposed SKILL.md contents to the user. Use a fenced YAML

• markdown block. Ask: "Does this look right? I can adjust before writing."

The shape should be:

---
name: <Human-readable name>
description: <One-line summary>
when_to_use: <Optional: longer discovery copy>
arguments: [<arg1>, <arg2>]   # only if any
argument_hint: "<hint>"        # only if arguments present
allowed_tools: [<tool1>, ...]
category: <utility | workflow | diagnostic | meta>
effort: <low | medium | high>
version: 1.0.0
---

Followed by the markdown body, structured as:

• One-paragraph intro that re-states the goal.
• Numbered steps for the model to follow.
• A short "What to avoid" or "Constraints" section.

Step 4 — Write to disk

Once the user approves, write the file.

User-scope path: ${HOME}/.geny/skills/<id>/SKILL.md Project-scope path: <cwd>/.geny/skills/<id>/SKILL.md

Create the parent directory first; the Write tool needs it. After writing, confirm with:

Wrote skill: /<full path>
Reload skills (or restart the session) to make /<id> available.

Step 5 — Don't loop forever

If, after asking three questions, the user is bored or the answers are all "I dunno", stop. Skillify is for capturing concrete repeated workflows. If there's no repeated workflow, you're manufacturing a skill nobody will use. Tell the user honestly: "This doesn't sound like a recurring flow yet — let's revisit once you've done it a couple more times."

Constraints

• Don't generate more than one skill per invocation. If the user describes two workflows, ask which to capture first.
• Don't include shell blocks (```! / !`...`) unless the user explicitly mentioned a step that needs them. Inline shell is optional, not default.
• Don't ship a draft that uses execution_mode: fork unless the user explicitly wants a separate sub-agent run.
• Validate: after writing, run a quick Read on the file to confirm it landed correctly.