My Prompt Was Hard to Reuse, So I Turned It into a Skill

I had written plenty of Skills for myself. Preparing one for public use showed me that effective instructions were not enough: it also needed provenance, assets, checks, limitations, and a clear release boundary.

MarinaPublished 2026-08-31Updated 2026-10-28English · 8 min read阅读中文版 ↗

While organizing the Skills I had written, the first problem was practical rather than technical. If they stayed on my machine, most of their value was simply saving me rework next time. But uploading SKILL.md to GitHub with a line saying “feel free to use it” would not convince even me that it was ready for someone else.

My Skills usually begin with a specific problem. A task keeps recurring. I have made a few mistakes and gradually learned where the process needs a firm check and which judgments the model can handle. It may begin as a prompt, then acquire reference files, checking scripts, and reusable assets. By that point, much of its value is outside the prompt itself.

I chose interactive-html-demo for the first public release. Its purpose is narrow: turn a linear explanation into a single HTML file that people can click through, reset, and demonstrate directly in a browser. The Skill already had a working output, and whether it worked was relatively easy to verify. It was a useful starting point for establishing release standards.

An effective prompt is not yet a deliverable Skill

A prompt mainly tells the model what to do this time. A Skill must explain which rules still apply next time, in another environment, or when someone else uses it.

What is missing between them is an operating boundary, not simply more text.

Saving only a prompt	Making a publishable Skill
Depends on the original chat context	Explains when it should and should not activate
Tells the model what to generate	Defines inputs, steps, outputs, and failure paths
Produces something that looks complete	Checks the result with scripts or a browser workflow
Assumes the author remembers the history	Records provenance, adaptations, and licenses in the repository
Explains problems after they happen	Identifies simulated capabilities, known limits, and recovery methods in advance

This became one of my main concerns: stop putting responsibilities back into the prompt when structure should carry them. A prompt often keeps growing because the system has nowhere else to keep state, check results, and responsibility boundaries.

What I actually put in the package

The first version was not a complex framework. It contained only the kinds of files needed to make a release:

interactive-html-demo/
├── SKILL.md
├── agents/openai.yaml
├── assets/single-file-starter.html
├── references/acceptance-checklist.md
├── scripts/validate_interactive_html.mjs
├── PROVENANCE.md
└── RELEASE.md

SKILL.md defines the workflow and boundaries. The starter is a real single-file artifact that can be opened. The validator catches structural omissions, while the acceptance checklist retains the checks that need a browser. Provenance and release records solve another problem: when I return later, I do not have to guess who wrote this version, what it drew from, or which checks it passed.

OpenAI’s Skills documentation defines a Skill as a folder containing instructions, resources, and optional scripts. That structure is useful because it does not require every judgment to fit in one file. Details that are needed only under certain conditions can live in references; deterministic checks can belong to scripts.

The first interactive-html-demo release: seven files covering the workflow, agent entry point, starter, checks, provenance, and release records. — Figure 1. Responsibilities drawn from the first release's file list and the article. These groups explain the files; they do not add directory requirements.

Why the first artifact was a single HTML file

I often need to explain a complex process, product idea, or report to someone else. A static document can explain the structure. Some judgments become clear only after a click: what happens when the button is pressed, whether the state changes, how to recover from failure, and whether the presenter can jump to the important screen.

A single HTML file works well here. It is easy to share and does not require the recipient to install a project environment first. Its core path can still work on an unreliable connection.

But “clickable” does not mean “free to simulate anything.” The starter explicitly says Interactive prototype · Simulated demo and requires visible feedback for every action. A viewer must be able to distinguish a real backend call, a front-end simulation, and something that has not been verified.

These boundaries are unglamorous, but they matter. The most dangerous demo is not the one that looks less polished. It is the one that leads people to believe it has capabilities that do not exist.

How I decided it was ready to publish

I set a modest release standard: prove that this version delivers what it promises, without trying to prove how impressive it is.

For the first release, the validator ran 15 static checks: 15 passed, with 0 warnings and 0 errors. Browser acceptance covered desktop, tablet, and phone widths, checking horizontal overflow, navigation, state changes, retry behavior, and the final path. I separately scanned for local paths, client information, old usernames, and placeholder content.

Those numbers are not downloads or evidence of effectiveness. They show only that the structure was complete and the important paths worked in the agreed environment. Whether the Skill suits someone else’s work still depends on actual use and feedback.

Release evidence should answer “what did I actually check?” rather than use a few numbers to imply popularity.

Explain the provenance before opening the source

I now have several kinds of Skills. Some were written from scratch, some adapted from open-source projects, and others reorganized from public material. They cannot all be labeled original.

The site was called HEADFIRST at the first release and now uses Marina Current. The current page retains three provenance labels:

MARINA CURRENT ORIGINAL: built from my own problem, rules, and implementation.
OPEN-SOURCE ADAPTATION: retains the upstream project, license, and an explanation of the changes.
REFERENCE-BASED REBUILD: draws on public methods but redesigns the structure, wording, and implementation; provenance still needs review before release.

The labels directly determine whether a Skill can be published, what must be retained, and which part I can take responsibility for. If I cannot explain its source, I would rather wait.

The first interactive-html-demo release was labeled HEADFIRST ORIGINAL and uses the MIT License. Other Skills will be audited individually. I will not dump the local directory into a public repository all at once.

What the website, article, and GitHub each do

I did not stop at creating a GitHub repository.

GitHub holds the full source, license, and release records. The Skill detail page helps a first-time visitor understand the purpose and operate the real starter before deciding whether to install it. This article preserves the making of it: why I divided it this way, where I stopped to check, and which judgments could be reused later.

The three entry points refer to the same thing but serve different tasks. This takes a little more maintenance, though it is easier to read than putting all the background, instructions, and source explanation into one README.

A reader first learns why the Skill was made in the article, tries the starter on the detail page, then checks the source, installs, and modifies it on GitHub. — Figure 2. The reading path described in the article. The three entry points have different responsibilities; this is not user conversion data.

I will not publish every Skill at once

The first version needs to complete one path: someone reads the article and understands why the Skill exists, goes to the detail page and tries it, then reaches GitHub and can inspect the provenance, install it, and make changes.

If that path does not work, adding more Skills only adds maintenance. The next step is actual feedback: where people get stuck understanding, installing, or using it; which checks help them; and which parts I mistake for clear because I already know them well.

Update: the library now has three public Skills. Recording problems other people encounter and revising from those observations is more useful next. The process above remains a record of the first release.

Start with a specific task

Try asking: “Make a single-file HTML prototype for a paid pilot signup flow, with plan selection, information entry, confirmation, and retry after failure. Use fictional information and label the simulation.” This is an invocation example, not a completed client project.

The expected output is an HTML file that opens in a browser. Check that all four states can be reached, inputs survive a failure, and the flow works at phone width. The installation package and first-release acceptance record are in the GitHub release notes.