How We Watermark Text Products (and Why Kit Resellers Hate It)

We watermark every ClaudeKit download three independent ways: a per-buyer LICENSE_HOLDER.md written into the kit at download time, a licensed-to comment injected into the frontmatter of every skill and agent file, and an HMAC-signed download URL that only resolves for the account that paid. None of these stop a determined reseller from stripping text out of a markdown file — nothing does — but together they make a resold copy traceable back to the buyer who leaked it, raise the effort of laundering a kit past the point most resellers bother, and give us a clean evidentiary trail for a refund clawback or a marketplace takedown. This post is the honest version: what we do, what each layer actually buys, and where watermarking text simply cannot help.

Why Would Anyone Watermark a Pile of Markdown?

A ClaudeKit kit is text. MarketingKit is 20 commands, 3 skills, and 2 agents. SEOKit is 19 commands, 4 skills, and 2 agents. Across all 5 kits we ship 101 commands, 19 skills, and 13 read-only agents — every one of them a .md file, a YAML frontmatter block, and prose that Claude Code reads as plain markdown. There is no compiled binary to obfuscate, no server-side execution to gate behind an API key. The moment a buyer has the files on disk, they have the product.

That is the uncomfortable starting point for any text-based digital product, and the kit-reseller economy runs straight at it. The pattern is familiar to anyone who has sold a Notion template or a prompt pack: someone buys once for $14.99, reuploads the contents to a $5 Gumroad listing or a "mega pack" torrent, and undercuts the people who actually built and maintain the thing. We can't make that impossible. We can make it traceable and annoying, and we can be honest with buyers about exactly where the line is.

Our goal is not DRM. It is attribution: if a kit shows up somewhere it shouldn't, we want to know whose download it came from, and we want the original buyer to know that we'll know. Those two facts change behavior more than any encryption scheme we could bolt onto a .md file.

What Are the Three Watermark Layers?

We use three layers in combination because no single layer survives a minimally competent reseller working alone. Here is a summary before we go deep on each:

The combination means a reseller must do three separate things correctly to fully launder a copy. Most don't bother. The ones who do leave a diff that proves deliberate effort.

Layer 1: A Per-Buyer LICENSE_HOLDER.md

The first and most visible layer is a license file generated per download. When you buy a kit and run ck install <kit> (via the claudekits CLI, v0.1.3 on npm), the CLI fetches a build stamped for your account. At the root of that kit is a LICENSE_HOLDER.md that looks roughly like this:

# License Holder
 
This copy of MarketingKit is licensed to:
 
- Account: madni-aghadi (acct_3Kp9...)
- Order: ord_8Qz2... (All-Access, 2026-04-06)
- Download: dl_7Hn4... at 2026-04-06T14:22:08Z
- Fingerprint: 9f2c-... (HMAC-SHA256 of account + order + nonce)
 
Single-seat license. You may use, modify, and run these files for your own
work. You may not redistribute, resell, or republish them. See /pricing for
team and agency terms.

This is deliberately readable. A buyer who opens the kit sees their own name and order ID staring back at them. That is most of the deterrent value: people are far less likely to upload a file with their own account fingerprint baked into it than they are to upload an anonymous one.

The fingerprint itself is an HMAC (a keyed hash) over the account ID, order ID, and a per-download nonce, signed with a server-side secret. We can recompute it from a leaked copy and match it to exactly one order. The buyer can't forge a different valid fingerprint, because they don't have the key.

The obvious objection: "they'll just delete the file." Correct. Which is why it is layer one, not the only layer.

Layer 2: licensed-to Frontmatter Comments

A reseller who knows what they're doing will rm LICENSE_HOLDER.md before reuploading. So the second layer scatters the same attribution across the files the kit can't function without. Every skill and agent ships with YAML-style frontmatter; at download time we inject a comment line carrying a short, salted token tied to the order:

---
name: mkt-humanize
description: Strip 14 AI tells from any draft and restore your voice
# licensed-to: 9f2c-a1b8 (ord_8Qz2) — single-seat; redistribution prohibited
tokens: 1420
---

Across our 5 kits there are 101 command files, 19 skill files, and 13 agent definition files. Stripping LICENSE_HOLDER.md is one delete. Stripping a licensed-to comment from every file without breaking anything is a scripted find-and-replace — doable, but it requires the reseller to understand the format, run the script cleanly across hundreds of files, and not miss one.

We rotate where the token sits and how it's salted between builds, so a strip script written for one buyer's leak doesn't reliably clean the next. Again: not unbreakable. The point is to move "repackage and resell" from a thirty-second drag-and-drop into an actual deliberate engineering act, which most low-effort resellers won't do, and which — when they do — leaves us a removed-comment diff that still says someone went out of their way to launder this specific purchase.

We do not hide invisible zero-width-character watermarks in the prose of the skills. We considered it. We decided against it for reasons covered in the next section: it degrades the product for honest buyers and survives almost nothing.

Layer 3: HMAC-Signed Download URLs

The third layer sits in front of the files entirely. Downloads are not static links. When your client requests a kit, the server issues a short-lived URL signed with HMAC over the account, kit slug, and an expiry timestamp:

GET /dl/marketingkit?acct=acct_3Kp9&exp=1775745600&sig=4b8e2f...e91

If the signature doesn't validate, or the timestamp is past expiry, or the account doesn't hold a live entitlement for that kit, the request 403s. A buyer can't share a working download link, because the link dies in minutes and is bound to their account. This doesn't watermark the content — it gates the distribution channel, so the only way to get the bytes is to authenticate as someone who paid. It also gives us a per-account download log, which is what makes a clawback decision evidence-based rather than a guess.

What Can Watermarking Text Honestly Not Do?

Here is the part the reseller forums get right, and most "protect your digital product" posts skip.

1. It cannot stop copying. Once the markdown is on disk and rendered to a human, that human can retype it, screenshot it, or paste it into another file. Any watermark that survives a human reading the text and rewriting it would have to be in the ideas, and you can't hash an idea.

2. Invisible character watermarks are weak. Zero-width joiners and homoglyph substitutions get stripped by a normalization pass, a copy-paste through a plain editor, or a single tr command. They also risk corrupting code blocks and breaking the actual skill. We don't ship them.

3. A motivated reseller wins on any single file. If someone wants to resell one specific skill badly enough, they can launder it by hand in under five minutes. Watermarking is a probabilistic, deterrence-and-attribution play, not a lock.

4. The value in the skills is not secrecy. Our MarketingKit earns its $14.99/month because /mkt humanize strips 14 specific AI tells and /mkt voice builds a persistent voice file from your real posts — not because the prose is locked away. A leaked, stripped copy is worse than a paid copy: it doesn't receive updates, misses newly added commands, and has no license to use commercially.

5. Downstream re-synthesis cannot be detected. Someone who reads a skill, understands the approach, and writes their own version from scratch is not a pirate. We have no claim on ideas. The watermark targets literal file redistribution, nothing more.

So why bother? Because the economics of reselling depend on low effort and low risk. Per-buyer attribution raises the risk (we can name the leaker). The signed channel and frontmatter tokens raise the effort (no thirty-second repackage). The result isn't zero leaks — it's fewer leaks, and accountability when they happen. That's an honest claim, and it's the one we make.

How Does Watermarking Interact With Token Costs?

Every ClaudeKit skill ships with a measured token count in its frontmatter — we run a tiktoken-compatible counter at pack time, approximately 4 characters per token. The 82,197-token total across all 5 kits is a real measurement, not a marketing estimate. The licensed-to comment we inject adds roughly 15-20 tokens per file, a rounding error relative to skills that run 800-3,200 tokens each.

The LICENSE_HOLDER.md file at kit root is never auto-loaded into a Claude Code session. It sits there for human reading and for audit purposes. Running /mkt humanize or /seo quick-wins does not drag your license metadata into every context window. If you want to verify this yourself, ck tokens <kit> recounts the installed kit and prints the ledger — the license file is excluded from the total.

For a detailed breakdown of where context tokens actually go in skill-heavy workflows, see our post on real context token costs. The short version: 82,197 tokens across 101 commands sounds large until you realize Claude Code only auto-loads a few hundred tokens of skill context per command, not the full kit.

How Does Watermarking Connect to v2 Architecture?

One thing worth naming: in v2 of ClaudeKit, we moved away from reviewer/quality-gate agents (the old "blocking reviewer" pattern where an agent evaluated your deliverable before handing it back). Commands in v2 end with EVIDENCE — a diff, a report, a verified file — not with another agent's approval stamp. This matters for watermarking because it means there is no server-side agent evaluating your output. Everything runs locally on your machine.

That is deliberately honest. You have the files. You run the commands. We don't phone home on every /eng debug or /ecom no-sales invocation. The accountability we get is at download time — the signed URL log — not at execution time. The watermark is the only thread we hold.

This is also why the ck doctor diagnostic and ck list entitlement commands exist: if something looks wrong with your install, you check it locally. We explain the architecture openly in the docs rather than obscuring it, because the value of the kits is the quality of the commands and skills, not a managed service.

For more on how v2 agents work (read-only specialists, no orchestrator pattern), see our post on blocking reviewer gates, which covers why we killed the quality-gate model.

What Is Our Policy When a Leak Shows Up?

We try to be proportionate. If a kit surfaces on a reseller site, we recompute the fingerprint, match it to an order, and follow this process:

1. Verify. Confirm the fingerprint matches an active order, and that the copy contains enough original content to distinguish from independent authorship.
2. File the takedown. Submit a marketplace or DMCA notice using the signed download log as evidence. The log timestamp and HMAC tie the specific file bytes to a specific account ID.
3. Contact the buyer once. Sometimes it's an honest mistake — a shared team drive, a public repo, a contractor who uploaded files they shouldn't have. We'd rather convert that into a team license than burn a customer.
4. Revoke and clawback only on clear, repeated, commercial redistribution. The 14-day money-back guarantee applies to the original honest purchase; it does not protect a buyer who is actively selling our kit for $5 on Gumroad.
5. Never brick a working copy. The files you downloaded keep working offline. The watermark is for attribution, not a kill switch. You will not open Claude Code one day and find your skills gone.

That last point matters to us. We dislike remote kill switches in software products, and we won't ship one. The honest trade is: we can identify a leaked copy and act on it through legitimate channels, and you can rely on a downloaded kit working without a persistent connection to our servers.

How Do Pricing Tiers Affect Watermark Scope?

The license file and frontmatter tokens are the same regardless of tier — every copy is attributable. What differs is scope:

Team and agency licenses (broader device counts, commercial redistribution within your org) are handled on the pricing page. If you need to install a kit across a whole engineering team, the single-seat watermark will flag as a shared copy — reach out before that happens, not after.

The lifetime tier is worth a note: it covers the kit as shipped, not future additions. The watermark in a lifetime copy is tied to the purchase order. If we ship new commands six months later, the lifetime copy doesn't auto-update — but the existing watermarks remain valid for the version you have.

FAQ

Does the watermark slow down Claude Code or add tokens to my context?

No. The licensed-to comment is a single frontmatter line — roughly 15-20 tokens — and Claude Code ignores YAML comments when loading a skill into context. LICENSE_HOLDER.md is never auto-loaded into a session unless you explicitly reference it. The token counts printed by ck tokens <kit> reflect working skill tokens, not watermark overhead.

Can I delete LICENSE_HOLDER.md from my own copy?

You can delete it locally — it's your machine. Deleting it doesn't remove your license, doesn't change how the kit runs, and doesn't trigger anything on our side. It only removes the human-readable attribution. The frontmatter tokens in every skill file and our server-side download log still tie the copy to your order. You are just making it slightly less obvious to yourself.

Why not use proper DRM or encryption?

Because the product is text Claude Code has to read as plaintext. Any scheme that encrypts the skills would have to decrypt them at runtime on your machine, where the decryption key also lives — so it buys nothing against a determined copier and adds friction for every honest user. We chose traceable watermarking over theatrical DRM on purpose. The honest version of "protection" for a text product is: make copying traceable, not make the file unreadable.

What happens to the watermark if I get a refund?

The 14-day money-back guarantee stands. If you refund, your entitlement is revoked and signed download URLs stop resolving for those kits. You are expected to delete the files, same as any returned digital product. We don't pursue honest refunders through the watermark system. The attribution layers exist for commercial resale, not for people who simply decided a kit wasn't for them.

Can the watermark be used to track how I use the kit?

No. The watermark is static — it's baked into the files at download time and doesn't change. There is no phone-home behavior, no telemetry on command execution, and no server receiving signals when you run /seo quick-wins or /eng debug. The only server-side event is the download itself, which is logged like any authenticated file request. What you do with the files after that is your business.

What if a contractor or employee leaks a kit I licensed?

A single-seat license covers 3 devices for your own use. If a contractor working on your project needs kit access, you need a team license. If a contractor takes your files and redistributes them, the watermark points to your account — you would be the buyer of record on any takedown. That's the right incentive: manage who you give access to, or upgrade to a scope-appropriate license. We explain all of this on the pricing page before you buy.

If you are building seriously with Claude Code and want commands that are maintained, measured, and worth protecting, the MarketingKit covers the full content workflow from voice calibration to publication — 20 commands, 3 skills, 16,714 measured tokens. The EngineerKit covers the full dev loop — 25 commands, 4 skills, 20,413 tokens. Either one installs in under a minute with ck install mkt or ck install eng, and the token ledger prints on first install so you know exactly what you're loading.