Heymark: Managing AI Work Standards

Syncing Skills for Multiple AI Tools from One Place

<Read the Korean version>

Mossland recently released Heymark, an open-source CLI tool designed to manage working rules and Skills for multiple AI coding tools from a single reference document.

Heymark is not a project that creates a new AI coding tool. Instead, it helps existing tools such as Cursor, Claude Code, GitHub Copilot, and Codex refer to the same working standards and context by managing Skills in one place and converting or syncing them into each tool’s required format.

This article focuses less on how to use Heymark and more on why Mossland saw a need for this kind of tool.

Heymark at a Glance

1. Project Rules for AI Tools

To understand why Heymark is useful, it helps to look at how AI coding tools are used inside projects. In modern development environments, tools such as Cursor, Claude Code, and GitHub Copilot are increasingly used to write and review code.

An AI coding tool is a program that suggests or writes code when a user asks it to build a feature. Within the same team, different people may prefer different tools, so it has become increasingly common to use several tools together. As that happens, the question of how to tell AI the rules of a project becomes more important.

1) Project Context AI Does Not Know

AI coding tools can suggest code quickly, but they do not automatically know how a project is structured or operated.

Even when building the same button component, one project may follow a specific folder structure, another may require test files to be written together, and another may strictly maintain certain API call patterns or state management rules.

Without this context, AI-generated output may work technically but still fall outside the project’s existing workflow.

Just as a human developer first learns “how we work here” when joining a team, AI also needs a similar kind of guidance.

2) Skill: A Reusable Work Guide

One way to provide those standards is to organize working instructions into a document. In Heymark, this document is called a Skill. A Skill is a kind of working guide given to AI.

A Skill is slightly different from a one-time prompt used in a single conversation. Instead of repeatedly explaining “In our project, write it this way,” teams can organize frequently used working standards into a document and reuse them across tasks.

The difference between a prompt and a Skill can be summarized like this.

The difference between a one-off prompt and a reusable Skill

This is where the problem begins. Each AI coding tool stores this Skill in a different location and format. The same content has to be moved into a different shape for each tool, and whenever a rule changes, several places need to be updated together.

Heymark focuses less on the answer quality of AI itself and more on the standards and context AI should work within. Its role is to manage Skills in one place and convert and sync them into each tool’s format.

2. Rule Management as AI Coding Tools Increase

1) Scattered Project Context

As discussed earlier, AI does not know a project’s purpose or team rules from the beginning. Developers therefore need to provide the background information that AI should refer to. This information is often called project context.

The Skill mentioned above is the container for this context. The problem is that as more tools are added, the places where this context is stored become scattered as well.

2) Different Skill Storage Locations by Tool

Suppose one project uses both Cursor and Claude Code. If the team’s coding rules change, the rules file read by Cursor and the Skill file read by Claude Code both need to be updated.

If GitHub Copilot or Codex is added, the same instructions have to be managed repeatedly across multiple locations and formats. If even one file is not updated, each AI tool may end up referring to a different standard.

This happens because each tool stores Skills in its own location and format. Based on the structure visible in the repository, the layout looks like this.

As shown above, some tools use .mdc files inside a rules folder, while others place SKILL.md inside a skills folder. This means that even the same content has to be copied into different shapes depending on the number and type of tools being used.

Keeping the same rules in several places increases the management burden. Every rule change requires updates across tool-specific files, and missing even one file can make it unclear which standard is current.

3) Before and After Heymark

The difference becomes clearer when viewed as a Before / After comparison.

Skill management across AI coding tools: before and after Heymark

So how does Heymark gather scattered rules into one source and generate them again in each tool’s format? The flow is shown below.

Scattered rules → Source Skill repository → Heymark conversion and sync → Tool-specific formats → Consistent work standards

3. What Heymark Does

1) Source Skill Repository

Heymark converts and organizes one source document into formats that multiple AI tools can understand. It manages the document in one place and automatically generates and syncs files for each required tool format.

Technically, Heymark performs conversion and synchronization based on a Skill repository written in Markdown. Markdown is a lightweight document format that uses simple symbols such as # or - to represent headings and lists. It is simple enough to write in a plain text editor, but structured enough for computers to read according to consistent rules.

This is also why Heymark uses Markdown as its source format. A document that people can write easily can be accurately converted by machines into the formats required by each AI tool.

2) Conversion and Sync

Based on the public README, Heymark provides four main functions.

• Single source management — Manage Markdown-based Skills in one place.
• Automatic conversion — Generate files in the format each tool requires.
• Selective sync — Sync to all tools at once, or only to selected tools.
• Sample Skills — Try Heymark immediately with sample Skills included in the repository.

3) Supported Tools

Based on the public README, supported tools include Cursor, Claude Code, GitHub Copilot, Codex, Antigravity, and OpenClaw. The repository is released under the MIT License.

In short, the only source people need to manage directly is one Skill repository. Heymark regenerates tool-specific files from that source, so the same standards do not have to be copied repeatedly.

4. Keeping One Source Document at the Center

When the same content is copied into several places, it becomes hard to know which version is current. If one file is updated and the others are missed, different AI tools may refer to different rules inside the same project.

Heymark therefore aims to keep the original document in one place and generate the rest from that source. When a standard changes, teams can update only the original and sync again, making the point of modification clear and reducing the risk of missed or inconsistent updates.

This means coding style, folder structure, testing standards, and review rules can be managed from one repository.

The files each tool needs still exist. The difference is that people do not write each of those files separately. Heymark’s approach is to regenerate them from a single Skill repository.

In software development, this kind of central source is often called a single source of truth.

5. Usage Flow

The commands below are examples that show Heymark’s basic flow. Detailed options are available in the README of the GitHub repository.

The usage flow centers on three commands. link connects a Skill repository to the current project, sync generates the connected Skill in the locations and formats required by each AI tool, and clean removes generated outputs. In simple terms, link connects, sync applies, and clean removes. First-time users can try it immediately with the sample Skills included in the Heymark repository.

npx heymark link [Repository URL] \
  --folder skill-samples

npx heymark sync .

Running these commands automatically creates Skill files in the locations expected by each tool. If users want to apply Heymark only to selected tools instead of all supported tools, they can add the tool names after the command.

npx heymark sync cursor claude-code

Generated outputs that are no longer needed can be removed with clean.

npx heymark clean .

Options and detailed usage are available in the GitHub repository.

6. Why Mossland Released Heymark

Mossland sees AI not simply as a question-and-answer tool, but as part of a working environment that supports development, documentation, review, and experimentation. In this kind of environment, what becomes increasingly important is not only what we ask AI to do, but also the standards and context within which AI works.

Heymark is an open-source CLI tool released to examine whether those standards and context can be organized consistently across multiple AI coding tool formats. When different tools require different formats, Heymark helps avoid copying and editing the same Skill repeatedly by organizing work standards in one Skill repository and converting and syncing them for each tool.

This connects with Mossland’s broader direction of structuring AI-based development workflows more deliberately.

The release is also an attempt to examine how much this approach can reduce the burden of repetitive management. Heymark is released under the MIT License, so it can be used and modified freely within the scope of that public license.

Rather than emphasizing a specific achievement, this release is closer to an experiment and review process around how working standards can be managed more consistently.

7. Closing

To summarize, Heymark is an open-source CLI tool that manages working rules and Skills scattered across multiple AI coding tools from a single source document, then converts and syncs them into each tool format. It is a lightweight CLI-based tool, but it has a clear purpose: reducing the burden of rewriting and managing the same rules separately for each tool in environments that use multiple tools together.

Mossland will continue exploring ways to structure how we work with AI more reliably. Heymark is available through the MosslandOpenDevs GitHub repository and the npm package. Users can try it through the Quick Start example included in the repository README.

Security and Investment Notice

Heymark and the related Mossland experiment pages are shared as part of Mossland’s ongoing technical exploration and open development activities.

When using any open-source tool, GitHub repository, npm package, or external link, please review the source carefully and use it at your own discretion. Users should also follow basic security practices, including checking package sources, reviewing permissions, and avoiding the use of unverified code in sensitive environments.

This article is intended to introduce Mossland’s technical experiment and development direction. It does not constitute investment advice, financial guidance, or a recommendation to buy, sell, or hold any digital asset.

Mossland-Related Links

Experiment Pages

• MOSSLAND NPC: https://npc.moss.land/
• MOSSLAND CITY: https://city.moss.land/
• Alpha: https://alpha.moss.land/
• Signal Map: https://signalmap.moss.land/
• MOSS stance graph: https://media.moss.land/

Development Repositories

• NPC GitHub: https://github.com/MosslandOpenDevs/mossland-npc
• CITY GitHub: https://github.com/MosslandOpenDevs/mossland-city
• Alpha GitHub: https://github.com/MosslandOpenDevs/alpha
• Signal Map GitHub: https://github.com/MosslandOpenDevs/signalmap
• Mossland Media KR GitHub : https://github.com/MosslandOpenDevs/mossland-media-kr
• Heymark GitHub : https://github.com/MosslandOpenDevs/heymark
• npm Heymark: https://www.npmjs.com/package/heymark

Official Channels

• Official Website: https://www.moss.land/
• Disclosure Website: https://disclosure.moss.land/
• Official X: https://x.com/TheMossland
• Official Blog: https://medium.com/mossland-blog
• GitHub (Mossland): https://github.com/mossland
• GitHub (MosslandOpenDevs): https://github.com/MosslandOpenDevs