A team's tool builds Cursor, Claude Code and Antigravity skills from one source

The problem: skills that drift apart

As dev.to reported, a team at longwave-ai-lab built a tool to fix a common mess in the AI coding world. People publish instruction files for coding agents: CLAUDE.md for Claude Code, .cursor/rules/*.mdc for Cursor, and SKILL.md files for Claude Code and Google Antigravity. A skill here means a reusable set of instructions an agent loads when it needs them.

The authors say that two weeks after launch, most such repositories share four failures. The author edits one file and forgets the others, so users of different tools run different versions. Everything is dumped into one huge instruction file. Sales pages are vague and break when pasted into Gumroad's editor. And the test script claims to verify things while only checking that files exist.

Their answer is the AI Skill & DevTool Commercialization Factory, an 8-stage Node.js program with no outside dependencies. The code is published on GitHub under the MIT licence.

One source, six generated outputs

The idea is simple: humans edit only two things. One is a manifest file describing the product, its pricing tiers and test fixtures. The other is a set of four rule documents. Running the compile command then produces everything else.

The outputs include:

• A short root index for CLAUDE.md and GEMINI.md, kept under 200 lines (about 950 tokens, the small units models read) so the agent is not flooded at startup.
• Cursor rule files with the header fields Cursor needs to know when to attach a rule.
• Skill files for Claude Code and Google Antigravity.
• Small runnable checkers, called linters, extracted from the rule documents.
• An llms.txt index and a command-line installer.
• Two zip archives that keep the free starter separate from the paid bundle.

The authors claim the short index preserves 95.1% of the model's startup attention budget. That figure is theirs and is not independently checked here.

Testing the tests

The most interesting part is the audit. The authors warn about what they call Potemkin verification: a test that always says PASS because it checks too little. Their remedy is to run every linter twice. First it gets a file that should fail, such as a CLAUDE.md with 205 lines or a Cursor rule missing its header. If the linter reports success, the audit itself fails. Then it gets a good file and must report success.

This is the mutation-testing idea: break something on purpose and see whether the checks notice. The post puts 239 checks in this first, rule-based layer, alongside file completeness, manifest validation and image-size checks.

A second layer covers semantic judgement by an outside language model. When that judge is skipped with a flag for offline runs, the report does not invent a perfect score. It records that the evaluation was not run, the verdict as undetermined, and the probability as empty.

A bug that bites bilingual projects

The team also describes a regex trap they hit while testing a bilingual English and Vietnamese product. In JavaScript, the word-boundary marker \b only understands plain ASCII letters. Accented letters, such as those in the Vietnamese word for 'and', count as non-word characters, so a pattern built on that marker never matched.

They replaced it with Unicode-aware lookarounds and the u flag. Anyone writing checks for text in French, Vietnamese or any accented language could run into the same problem.

Marketing built into the pipeline

The tool goes beyond code. One module converts a Markdown sales page into HTML that Gumroad's editor accepts, turning tables into lists because that editor strips table tags. Another module sets rules for social posts: no outbound links in the main post, a cap of 3 posts a week, and a text-similarity check that blocks a draft if it scores above 0.50 against recent posts.

The post also cites academic papers for several design choices, and some of its claims about reach penalties and recall loss come from the authors. Treat those as the team's framing rather than settled fact. This is one team's account of its own product, and the source shows no independent review or user results.