Moving AI agent skills: $39 per playbook — import or rewrite

What a $39 playbook actually contains

For any commercial skill playbook, the object being evaluated is not a single prompt, but a four-layer anatomy: instructions, tool bindings, examples, and guardrails. Stating this split once is the only way to judge portability without treating the entire file as equally moveable. The point is not how much text there is, but which layer is being copied.

The first layer, instructions, is the natural-language procedure. On the surface, this is plain tokens and tends to be portable across runtimes. The check is precise: verify it does not reference a vendor-specific system prompt or any hidden context the target runtime is not guaranteed to inject. This matches the broader idea of build portability noted by Frontiers | Modernizing the NEURON Simulator for Sustainability, where moving between environments fails over assumptions, not over stated logic.

The second layer, tool bindings, is named function calls and argument schemas. This is the least portable layer by structure. A playbook written for one agent framework's tool namespace will not automatically map to another, and in many cases those mismatches will fail silently rather than throw an obvious error. For this reason, tool bindings should be treated as candidates for rewiring first, before touching prose at all.

The third layer, worked examples, is few-shot transcripts. As content, examples are often portable, but do not copy them unexamined. Check whether example outputs embed a specific model's phrasing, the exact shape of a tool result, or an intermediate trace that the target model would not naturally produce. These details are subtle, but they are the kind that can force edits even if the task itself is identical.

The fourth layer, guardrails, is boundary rules and refusal logic. Parts of this layer can be portable, but any guardrail that explicitly names a tool from the bindings or cites a framework-specific error is tied to the lock-in above it. In practice, only instructions have the broadest shot at import as-is, with examples and guardrails sometimes patchable, and tool bindings most often requiring a rewrite of calls and schemas to fit the new runtime.

Run the 10-minute portability audit

Start by pulling the file out of its viewer and into a plain text editor. For Step 1 of this pass, go through the playbook token by token and highlight every token that names a specific tool, API, file path, or model — call these locked tokens. Be strict with this selection: only tokens that would need to be renamed or removed to run in a different runtime count. General instructions, constraints in plain language, or structural markers do not.

For Step 2, use the locked-token counting method: compute locked-token share = locked tokens ÷ total playbook tokens. Treat the 30% import threshold as the line for this audit: if the share is under 30%, import-and-patch is cheaper to attempt than rewriting from scratch; if the share is at or over 30%, rewriting should be the default to test against. Do this division against the full playbook, not a sampled block, since partial counts are the easiest way to misread portability.

For Step 3, check format compatibility on the same file. Ask three strict questions: is this plain markdown, a vendor-specific skill manifest, or code? Only plain markdown imports cleanly into a different runtime without conversion. This matches the broader principle of build portability across platforms and compilers noted by Frontiers, where moving between environments fails more often from format lock-in than from wording alone. A manifest or code file can still be audited, but it will almost always force changes outside of the locked-token set.

Run these three steps in that order and do not merge them. If a token is too obfuscated to tell whether it names a specific tool, API, file path, or model, do not guess it into either category — treat that ambiguity as a strike against format compatibility instead. The output of this pass is only two concrete facts: the locked-token share against the 30% import threshold, and a yes or no on plain markdown. With those two facts, the import-or-rewrite decision can be made without expanding beyond this audit.

Import vs rewrite: cost comparison

Once the audit hands you a locked-token share, the decision collapses into a simple cost comparison. The import path costs the $39 purchase plus patching time: take your own hourly rate, multiply it by the hours needed to fix every locked token the audit flagged, and that product is your true price. The purchase price is fixed and known; the patching estimate is the only variable you control, and the audit is what turns it from a guess into a line item.

The rewrite path costs your authoring time from scratch, with the purchased playbook demoted to an outline reference. This path wins when the locked share is high, because a heavily locked playbook makes you pay twice: once for content you discard, and again to re-author the parts you actually need. If the audit shows most of the value sits in vendor-locked tool bindings rather than in the portable instruction layer, you are effectively buying an outline at full price.

The hybrid path splits the difference. Import the layers that survived the audit — the portable instructions and guardrails — and rewrite only the locked layers. This wins when the playbook's domain expertise is genuinely hard to reconstruct but its environment assumptions are not. The audit already told you which tokens are locked; the hybrid path just routes each layer to the cheaper treatment instead of forcing a single verdict on the whole file.

Read the winner column as conditional, not absolute. The same playbook can land in different rows for two buyers: a team already running the vendor the tool bindings target will find the import path nearly free of patching, while a team on a different stack pays the full patching bill and may tip into hybrid or rewrite. This mirrors the vendor lock-in dynamic that portability provisions in multi-tenant SaaS models are designed to manage — the cost of switching is the cost of the lock, and it differs per buyer.

Before committing, run one final check on your own arithmetic: price the import path honestly, including the dry-run fix time, and compare it against your rewrite estimate at your actual hourly rate. If the two estimates land within a small margin of each other, prefer the hybrid path — it caps your downside in both directions, keeping the purchased expertise while limiting the re-authoring to exactly the tokens the audit proved were locked.

What the evidence does not establish

No published benchmark establishes a universal locked-token threshold. The 30% figure is a method heuristic you should calibrate against your own patch-time logs, not a vendor-published figure. With that said, the $39 price point itself is not evidence of quality — price signals positioning, not portability; the audit, not the price tag, decides import vs rewrite.

The honest limits table below is the boundary to keep in mind: when the 30% rule breaks vs when it still wins. For environments with stable toolsets, the rule can still hold true and make import the more reasonable path. However, for playbooks built around rapidly-changing vendor APIs, the rule can break entirely. Even if a playbook is under 30% locked today, the rate of change can make it break next quarter, in which case rewrite wins despite a favorable count.

These limits do not invalidate the heuristic, they define its expiration date. A count is only a snapshot, while patch-time is a trend. If your own logs show that trend accelerating between audits, you must recalibrate the threshold downward, regardless of what the percentage reads at the moment of purchase.

Ultimately, the evidence does not establish a guarantee, only a boundary condition. Treat the 30% mark as a starting test, not a promise, and let change itself be the reason to override it.

Worked Example: Run the Numbers

For this illustration only, use the exact example inputs: scenario = porting a ticket-summary agent skill from its original multi-tenant workspace to a second multi-tenant workspace; party = a single operator running the check; no fixed calendar date is assigned to this run. Pull the playbook file into plain text and take its measured total as 2,000 tokens. As an illustration, count by groups: treat tool bindings as 300 tokens total, of which 150 tokens explicitly name workspace-specific endpoints and are locked. Outside of tool bindings, mark 60 more tokens as locked for naming a specific file path or model-specific phrasing. Add them: 150 + 60 = 210 locked tokens out of 2,000. Divide 210 by 2,000 = 0.105, or 10.5% locked. All arithmetic above was recomputed digit by digit for this example.

With 10.5% locked, and using the portability threshold of under roughly 30% locked to import rather than rewrite, the winner for this example is import and patch. The break-even trigger for this exact case is the crossing: locked tokens must reach more than 600 of those 2,000 to push past 30% and flip to rewrite under this rule. This is a threshold tied to the counted total, not a universal constant pulled from outside the audit, so if the total changed for a different file, that trigger would have to be recomputed against the new total before any decision is made.

Before acting on the import path for this illustration, two concrete checks are required. First, verify format compatibility for every non-locked layer against the target workspace (not just the count) so that a patch has a defined place to go. Second, run one dry-run against a narrow task using only the imported, patched parts to catch any locked assumption that slipped past the token scan. These are checks of fit, not assumptions of fit, and they are what allow a sub-30% count to stay actionable without inflating it.

As a practical note for token-level portability, the reasoning matches the direction of control described in Facebook's Data Portability and Privacy charting paper: the moveability of a defined set hinges on what can actually be transferred in practice, not on the label of the whole package. For this example alone, that fits directly to verifiable locked tokens. With 210 of 2,000 = 10.5% and both checks planned, import and patch is the justified path, with the 600-of-2,000 break-even acting as the line to watch if a recount raises locked content above that mark.

What to do next