okhp3-gpt-skill-conversion-plan

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

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