agentleFS
OKHP3OKHP3/skillz/.agents/skills/okhp3-gpt-skill-conversion-plan/SKILL.md

okhp3-gpt-skill-conversion-plan

Skill3 starsChanged 2 months agoMITView on GitHub

Plan conversion of an existing Custom GPT into a portable Agent Skill. Use when a GPT already has instructions, knowledge files, actions, conversation starters, test prompts, or usage history and the user needs a capability map, semantic-loss analysis, reusable skill boundary, migration plan, or handoff to okhp3-skill-foundry.

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 3 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Separate portable from platform-bound behavior: Keep reasoning patterns, schemas, rubrics, and public references in the skill.

    line 40
  2. Very specific:

    Use public-safe or synthetic examples.

    line 59
  3. Distinctive:

    Every source capability has a destination, an explicit drop decision, or a blocker.

    line 65
  4. Distinctive:

    Every proposed portable behavior has evidence, an explicit theory label, or a validation task.

    line 66
  5. Very specific:

    Read references/conversion-dossier-schema.md before producing a machine-readable dossier.

    line 76

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

okhp3-gpt-skill-conversion-plan

OverKill Hill P³ · overkillhill.com · github.com/OKHP3

Convert a configured GPT into a durable, runtime-portable skill plan without pretending that GPT configuration and Agent Skill instructions are equivalent. This skill plans and audits the conversion; okhp3-skill-foundry authors and benchmarks the final SKILL.md.

Scope

In scopeOut of scope
Asset inventory, capability mapping, boundary design, portability analysis, semantic-loss tracking, migration sequencing, and Foundry handoffExporting private platform data, bypassing permissions, writing production integrations, or claiming feature parity without verification

Conversion method

  1. Collect the source package. Inventory GPT name and purpose, instructions, knowledge files, actions/apps, starters, examples, eval prompts, user feedback, platform assumptions, version history, and any prompt-chain stages with their outputs. Mark each item available, partial, missing, or unverified and label its claim class.
  2. Map semantics, not wording. For each source behavior record its skill equivalent: trigger description, imperative procedure, reference, script, output contract, safety rule, or unresolved platform dependency. Convert a useful chain stage into a named procedure with inputs, observable exit criteria, and a recovery path. Preserve intent while removing UI-only language. Treat a claimed behavior as unproven until an example, preview result, or evaluation demonstrates it.
  3. Separate portable from platform-bound behavior. Keep reasoning patterns, schemas, rubrics, and public references in the skill. Isolate Builder toggles, ChatGPT-only UI, proprietary connectors, credentials, and undocumented model behavior as adapters or explicit exclusions.
  4. Detect semantic loss. Identify capabilities that cannot transfer cleanly: retrieval ranking, hidden system behavior, tool auth, connector permissions, conversation memory, model-specific formatting, and publishing controls. For each, state impact and a mitigation or acceptance test.
  5. Design the skill boundary. Define trigger phrases, in-scope and out-of-scope work, required inputs, outputs, escalation rules, references, scripts, assets, and version ownership. Avoid cloning an entire GPT when a smaller composable skill is more reliable. Record how the source hierarchy, tool policy, and failure handling will survive the move.
  6. Create a migration backlog. Order work as preserve, rewrite, externalize, replace, verify, or drop. Assign acceptance criteria and dependencies. Never carry secrets or private data into a public skill.
  7. Plan Foundry validation. Propose exactly three distinct eval cases with four evidence-anchored expectations each. Include one semantic-preservation case, one platform-bound loss or adapter case, and one boundary or safety case when applicable. The Foundry should later run with-skill and without-skill comparisons, grade evidence, compute the delta, and iterate.
  8. Issue a disposition: ready_for_foundry, needs_source_artifacts, partial_port, not_a_skill, or blocked_by_permissions. Explain what must happen next.

Required output

Return these sections in order:

  1. Conversion verdict with disposition, portability confidence, semantic-loss risk, and blockers.
  2. Source inventory table with asset, status, portable_value, destination, and evidence.
  3. Capability map linking each GPT behavior to a skill construct or adapter.
  4. Semantic-loss register with impact, mitigation, and test.
  5. Skill architecture covering trigger, scope, workflow, outputs, safety, references, scripts, and ownership.
  6. Migration backlog with ordered actions and acceptance criteria.
  7. Foundry handoff using references/conversion-dossier-schema.md.

Use public-safe or synthetic examples. Treat unknown platform behavior as unverified; do not invent an export format or claim that hidden GPT behavior can be reproduced in a SKILL.md.

Quality gates

  • Every source capability has a destination, an explicit drop decision, or a blocker.
  • Every proposed portable behavior has evidence, an explicit theory label, or a validation task.
  • Platform-bound features are isolated from portable method content.
  • Semantic loss is explicit and paired with a mitigation or eval.
  • The proposed skill is smaller and composable where possible.
  • Prompt-chain control language is converted into modular procedures or explicitly dropped; it is never copied as irreversible runtime instruction.
  • Eval expectations test facts supplied by the skill, not generic competence.
  • The handoff tells okhp3-skill-foundry exactly what to build and measure.

Handoff

Read references/conversion-dossier-schema.md before producing a machine-readable dossier. Use evals/evals.json to calibrate eval design. When the verdict is ready_for_foundry, load okhp3-skill-foundry for architecture, drafting, live evaluation, grading, benchmarking, and fix loops.

About

Built by Jamie Hill · OverKill Hill P³ Published at github.com/OKHP3 Part of the OKHP3/skillz Agent Skill library. MIT License -- free to use, fork, and adapt. A nod to the source is appreciated.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.