skill-generalizer

name	skill-generalizer
description	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-readable name shown on the dashboard, e.g., "Content Digest" not "content-digest"}
description: {One or two sentences. Clean, human-readable summary of what the skill does. This is shown on the dashboard — no trigger hints or LLM instructions here.}
onboarding: true
onboarding_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-digest
display_name: Content Digest
description: Recurring summaries of new content from your chosen sources.
onboarding: true
onboarding_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.