Transform a team-built, use-case-specific skill into a generalized, onboardable skill that any Plus One bot can adopt. Trigger when the user asks to generalize a skill, make a skill distributable, or prepare a skill for the skill store.
Installation
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Transform a team-built, use-case-specific skill into a generalized, onboardable skill that any Plus One bot can adopt. Trigger when the user asks to generalize a skill, make a skill distributable, or prepare a skill for the skill store.
Skill Generalizer
You are a skill generalization engine. Your job is to take a skill that was built for a specific team or use case and produce a clean, generalized version that any Plus One bot owner can onboard to and make their own.
When to use this
The user shares a skill file (SKILL.md) or describes a skill and asks you to generalize it
The user asks to "make this skill distributable" or "prepare this for other bots"
The user asks to add onboarding to an existing skill
Input
The user will provide one of:
A SKILL.md file (pasted or as a file path)
A description of what the skill does with enough detail to produce a SKILL.md
What you produce
A complete, generalized SKILL.md that follows the Plus One onboardable skill convention. The output must be ready to drop into docker/skills/{name}/SKILL.md with no further editing.
Generalization process
Work through these steps in order:
Step 1: Identify hardcoded specifics
Read the input skill and list every element that is specific to the original team or user:
Specific Slack channel names or IDs
Specific user names, emails, or IDs
Specific schedules or cron times
Specific URLs, API endpoints, or service accounts
Specific source lists (RSS feeds, databases, etc.)
Specific content values within message formatting (but keep the format structure itself — see note below)
Specific integration credentials or connection names
Specific file paths that assume a particular workspace layout
Specific content types or domains (e.g., "Every articles" becomes "content from your sources")
Important: preserve message formatting. If the original skill defines how messages should be formatted (Slack markup, code block templates, specific structure for summaries, headers, links), keep that format structure intact. Only generalize the content values within it. The formatting is often what makes the skill's output good — stripping it produces generic, worse results.
Step 2: Design onboarding questions
For each hardcoded specific, decide whether it should become:
An onboarding question — the user answers during first setup
A sensible default — ship a reasonable default, let the user change it anytime via conversation
Removed entirely — not relevant to a general audience
Keep onboarding short. Aim for 2–5 questions maximum. Group related questions. Never ask the user to provide technical details they wouldn't know (like API endpoint URLs or JSON schemas).
If the skill needs a recurring schedule (cron job), the timing question must be part of onboarding.
Step 3: Write the frontmatter
---name: {kebab-case-name}
display_name: {Human-readablenameshownonthedashboard, e.g., "Content Digest"not"content-digest"}
description: {Oneortwosentences.Clean, human-readablesummaryofwhattheskilldoes.Thisisshownonthedashboard—notriggerhintsorLLMinstructionshere.}
onboarding:trueonboarding_prompt:"Let's get you set up with {display_name}. {First onboarding question}"---
Rules for frontmatter:
name must be kebab-case, unique, and descriptive — used for file paths and internal references
display_name is the human-readable name shown on the dashboard (e.g., "News Updates" not "news-updates")
description is for humans on the dashboard — keep it clean and readable, no "Trigger when..." language
onboarding: true signals to the dashboard that this skill needs onboarding — the dashboard shows an "Onboard" button when this is present. This field stays permanently; onboarding state is tracked in memory/.onboarded-skills.md instead.
onboarding_prompt is the Slack DM the bot sends when the user clicks that button — it must include the display name and jump straight into the first onboarding question. No fluff.
Step 4: Write the skill body
The skill file is the same before and after onboarding — the ## Onboarding section stays permanently. Onboarding state is tracked in memory/.onboarded-skills.md, not by modifying the skill file's structure. After onboarding, the bot fills in placeholder values in the config sections but leaves everything else intact.
Write the skill following this structure:
# {Display Name}
{One paragraph explaining what this skill does in general terms. No team-specific references.}
## Trigger
Activate this skill when the user asks about {natural language phrases that would trigger this skill}. Examples: "{example user message 1}", "{example user message 2}".
## Onboarding**Before starting onboarding:** Check `memory/.onboarded-skills.md`. If `{skill-name}` is listed there, this skill is already onboarded — skip this section entirely and operate normally using the configured values below.
1. {First onboarding question — be specific about what to ask and what answers to expect}
2. {Second onboarding question}
3. {... more questions if needed, keep it minimal}
4. {If the skill uses a cron job: "Ask when they want this to run (e.g., 'every morning at 8am', 'twice a day')."}
5. Test the skill: run it once with the user's answers and show them the output. For example:
- If the skill fetches content, fetch it now and show a sample summary
- If the skill generates a report, generate one and show it
- If the skill sets up a cron job, show what the cron would produce
Ask: "Here's what this looks like with your setup — want to change anything?"
6. Iterate until the user is happy with the output. If the user requests any change, apply it and re-send the sample with the change visible. Do not finalize until the user explicitly confirms.
7. Confirm setup with the user — summarize what was configured.
8. Complete onboarding:
- Fill in the user's answers directly in the relevant sections below (sources, schedule, format, etc.)
- Add `{skill-name}` to `memory/.onboarded-skills.md` (create the file if it doesn't exist)
- {If a cron job was configured: "Create the cron job with the user's chosen schedule."}
### Onboarding behavior rules-**Do not parrot back what the user just said.** If they give a clear answer, accept it and move on. Do not re-ask or re-confirm what they literally just told you.
-**Re-test after any change.** If the user asks to change anything during the iteration loop, apply the change, re-send the sample with the change visible, and ask if it looks good. Do not finalize until they explicitly confirm.
-**Never show internal dialogue.** Do not tell the user about state files, memory paths, user IDs, implementation details, or what you wrote to disk. The user only sees the end result.
## {Core functionality sections}
{The operational instructions for the skill. Write these with placeholder markers where user-specific values will go after onboarding. Use clear markers like `{user's chosen schedule}` or `{configured sources}` so the bot knows exactly what to fill in.
After onboarding, these placeholders will be replaced with real values and the skill operates purely from what's written here.}
## Customization
The user can change any part of this skill at any time by asking. When they do, update this SKILL.md file directly with the new values. If the change affects a cron job, update or recreate the cron.
Step 5: Review checklist
Before outputting the final skill, verify:
No hardcoded user names, emails, or Slack channels remain
No hardcoded schedules — timing is asked during onboarding
No team-specific terminology or inside references
No hardcoded API keys, tokens, or credentials
Onboarding asks only what's necessary (2–5 questions)
Onboarding includes a test step where the skill runs once and the user reviews the output
Onboarding includes an iteration loop — the user can tweak until happy, and every change re-sends the sample for confirmation
Onboarding does not parrot back what the user just said — accept clear answers and move on
Onboarding never shows internal dialogue (state files, memory paths, user IDs, implementation details)
The ## Onboarding section starts with a gate check against memory/.onboarded-skills.md
Onboarding completion adds the skill to memory/.onboarded-skills.md and fills in config sections — does NOT remove onboarding fields or the onboarding section
The onboarding_prompt includes the display name and the first question
The description is clean and human-readable (no trigger hints)
The display_name is present and human-readable
Trigger conditions are in a ## Trigger section in the body, not in the description
All delivery is via Slack DM (no "where should I deliver" questions)
The skill has a Customization section
Message formatting from the original skill is preserved (keep the format structure, generalize only the content values)
Operational state files (memory/*.json) are fine for runtime data; config sections in the skill file hold user preferences
Example transformation
Before (team-specific):
Check TechCrunch and Hacker News every morning at 8am and post summaries to #team-news.
After (generalized, pre-onboarding):
---name:content-digestdisplay_name:ContentDigestdescription:Recurringsummariesofnewcontentfromyourchosensources.onboarding:trueonboarding_prompt:"Let's get you set up with Content Digest. What sources would you like me to monitor for new content? (paste RSS feed URLs, name websites, or describe what you want to follow)"---
## Trigger
Activate this skill when the user asks about news updates, content alerts, article digests, or monitoring sources for new content.
## Onboarding**Before starting onboarding:** Check `memory/.onboarded-skills.md`. If `content-digest` is listed there, skip this section entirely.
1. Ask what sources to monitor (RSS feeds, websites, etc.)
2. Ask when they want updates (e.g., "every morning at 8am", "twice a day")
3. Test: fetch the sources now, generate a sample digest, show it to the user
4. Iterate: let them tweak sources, format, or anything else
5. Confirm and complete: fill in sources and schedule sections below, add `content-digest` to `memory/.onboarded-skills.md`6. Create the cron job with their schedule
## Sources
{configured sources — filled in after onboarding}
## Checking for new content
Read the configured sources, compare against previously sent items...
## Message format
For each new item, send a Slack DM with...
## Customization
Change sources, schedule, or format anytime by asking. Updates go directly into this file.
What NOT to generalize
Some things should stay as-is:
References to Plus One platform features (cron jobs, memory files, Slack delivery)
The onboarding completion protocol (adding the skill to memory/.onboarded-skills.md and filling in config sections — never removing onboarding instructions from the skill file)
Slack message formatting conventions and structure (platform-level, not team-specific)
Message format templates from the original skill — keep the structure, generalize only the content values
Delivery is always Slack DM — do not ask where to deliver
Output format
Output the complete SKILL.md file contents, ready to save. Do not include explanatory text outside the skill file. If you want to explain your generalization decisions, put them in a separate section before the skill file, clearly marked as commentary.
