Agent skill

Governance Encoder

by murphytrueman in murphytrueman/design-system-ops

Turn written governance rules into enforcement that runs: ESLint, Stylelint, dependency-cruiser and CODEOWNERS config traced to sources, plus GOVERNANCE.md for rules with no executable form.

MITAuto-check passedDevelopment

Install Governance Encoder

skills CLI
$ npx skills add murphytrueman/design-system-ops --skill governance-encoder -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install murphytrueman/design-system-ops governance-encoder --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/murphytrueman/design-system-ops.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/governance-encoder .claude/skills/governance-encoder && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
governance-encoder
GitHub stars
203
Token cost
~2.6k tokens
SKILL.md length
1,377 words
Files
1
Skills in repo
36
Repo updated
First seen
Licence
MIT

At a glance

Turn written governance rules into enforcement that runs: ESLint, Stylelint, dependency-cruiser and CODEOWNERS config traced to sources, plus GOVERNANCE.md for rules with no executable form.

  • Works in 5 steps: Inventory the rules and the enforcement… → Map each rule to a tool → Write the configuration → …
  • Tasks that involve Linting and formatting
  • SKILL.md covers Before you begin: verify…, Context, Boundaries and Configuration, plus 6 more sections
  • Calls npx and changeset

What it does

Governance Encoder is an agent skill from murphytrueman/design-system-ops. Turn written governance rules into enforcement that runs: ESLint, Stylelint, dependency-cruiser and CODEOWNERS config traced to sources, plus GOVERNANCE.md for rules with no executable form. Triggers: governance as code, enforce our rules, lint our rules. Pipeline files: cicd-integration.

Its SKILL.md is about 2.6k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Linting and formatting and CI/CD. It works with ESLint. The repository describes itself as: Claude Code skills for the work that keeps a design system alive. The licence is MIT.

When your agent uses it

  • Tasks that involve Linting and formatting
  • Tasks that involve CI/CD

Example prompts

  • “/governance-encoder”

Requirements

  • Node.js
  • Pre-approved tools (allowed-tools): Read, Write, Grep, Glob, Bash(cat:*), Bash(find:*), Bash(head:*), Bash(ls:*), Bash(npx eslint:*), Bash(npx stylelint:*), Bash(npx depcruise:*)

Workflow steps

5 steps, taken from the step headings in SKILL.md.

  1. Inventory the rules and the enforcement that already exists
  2. Map each rule to a tool
  3. Write the configuration
  4. Calibrate against the codebase
  5. Summarise in chat

What it can do on your machine

Read from SKILL.md and the folder at commit f167898. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Read
    • Write
    • Grep
    • Glob
    • Bash(cat:*)
    • Bash(find:*)
    • Bash(head:*)
    • Bash(ls:*)
    • Bash(npx eslint:*)
    • Bash(npx stylelint:*)

    …and 1 more on the same allowed-tools line.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • npx
    • changeset

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use npx, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Governance Encoder loads about 2.6k tokens when it runs. Until then it costs about 77 tokens; SKILL.md has 1,377 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~77
When it runs · the whole SKILL.md, loaded when a task matches
~2.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from murphytrueman/design-system-ops at commit f167898, republished under its MIT licence (© murphytrueman). 1,377 words, ~2,626 tokens.

Download SKILL.mdSave it as .claude/skills/governance-encoder/SKILL.md (or your agent's skills folder).
name
governance-encoder
description
Turn written governance rules into enforcement that runs: ESLint, Stylelint, dependency-cruiser and CODEOWNERS config traced to sources, plus GOVERNANCE.md for rules with no executable form. Triggers: governance as code, enforce our rules, lint our rules. Pipeline files: cicd-integration.
allowed-tools
Read, Write, Grep, Glob, Bash(cat:*), Bash(find:*), Bash(head:*), Bash(ls:*), Bash(npx eslint:*), Bash(npx stylelint:*), Bash(npx depcruise:*)
references
../../knowledge-notes/component-governance.md, ../../knowledge-notes/design-to-code-contract.md, ../../knowledge-notes/output-discipline.md

Governance encoder

A skill for turning the governance rules a team has written down into enforcement that actually runs: linter rules, dependency boundaries, code ownership and CI checks, each traced to the document it came from. Rules with no executable form are written to a short governance page that says who checks them and when, so nothing is presented as automated when it isn't.

Before you begin: verify references

Confirm that every path in this skill's frontmatter references: exists relative to this SKILL.md. If any is missing, stop: the install is incomplete, usually because a flattening installer (for example npx skills install) dropped the repo-root knowledge-notes/ directory. Tell the user to reinstall by a method in 1-INSTALL.md and run verify-install.sh from the install root. Proceed without the references only if the user explicitly says to, and then say in the output that it was produced without the pack's reference material.

Context

Most design system governance lives in documents: contribution guidelines in a wiki, naming conventions in a README, token rules in a Slack thread from a year ago. They are enforced by review, when a senior reviewer happens to notice. That model breaks at scale, and it breaks completely for coding agents, which never read the wiki.

The tools that enforce rules already exist. ESLint has a naming-convention rule. Stylelint can forbid raw values in colour properties. dependency-cruiser can stop an atom importing an organism. CODEOWNERS can require the system team's review on token files. A design system's governance-as-code is not a new rule engine; it is those tools, configured to the team's rules, with each rule pointing back at the sentence that justifies it. This skill writes that configuration. An earlier version wrote JSON rules that nothing executed and called them "enforced automatically"; that is exactly the gap this version closes.

Boundaries

This skill encodes rules that exist. It doesn't decide what the rules should be (decision-record records that), write the CI workflow that runs the linters (cicd-integration), or audit compliance (token-compliance, naming-audit, component-api-validator do that). If the team has no written rules and can't state any, there is nothing to encode; say so and suggest contribution-workflow.

Configuration

If .ds-ops-config.yml exists, follow the configuration-and-recurring knowledge note (../../knowledge-notes/configuration-and-recurring.md). This skill reads:

  • system.framework, system.styling, system.component_paths, system.tokens
  • governance.severity_model — how the team maps rule weight to linter levels (default: block-on-merge rules are error, review-prompting rules are warn)
  • governance.categories — which rule categories to look for (default: all below)

Step 1: Inventory the rules and the enforcement that already exists

Read before asking. Sources, in order:

  • CONTRIBUTING.md, PR and issue templates, review checklists
  • READMEs in the token and component directories, a style guide, decision records
  • Existing lint config: eslint.config.* or .eslintrc*, .stylelintrc*, .dependency-cruiser.*, CODEOWNERS, commitlint, Changesets config
  • package.json scripts and the CI workflow, for what already runs

For each rule found, one row:

Rule (one sentence)Source (path or URL)Enforced today byExecutable form
Component export names are PascalCaseCONTRIBUTING.md#namingPR reviewESLint @typescript-eslint/naming-convention
Component styles use semantic tokens, never primitivestokens/README.mdnobodyStylelint declaration-property-value-disallowed-list
Token file changes need the system team's reviewCONTRIBUTING.md#tokenshabitCODEOWNERS
New components need a design review before mergewikinobodynone: GOVERNANCE.md

Then ask only for what the files don't say: rules that live in the team's heads (each becomes a row with source team), rules that are written but nobody wants enforced, and how strict the team wants to be at first.

Step 2: Map each rule to a tool

Use the executable form that already exists in the ecosystem. The table is the menu; pick per rule, per stack.

Rule kindTool and ruleNotes
Component or file namingESLint @typescript-eslint/naming-convention; unicorn/filename-case for filesVue: vue/component-definition-name-casing
Boolean prop prefixes, handler names@typescript-eslint/naming-convention with a typeProperty selector and prefixPartial: it can't tell a boolean prop from a boolean local. Mark it warn and say so
No raw colour, spacing or type values in stylesStylelint stylelint-declaration-strict-value on the token-backed propertiesTailwind: eslint-plugin-tailwindcss no-arbitrary-value
No primitive tokens in component stylesStylelint declaration-property-value-disallowed-list matching the primitive prefix (`/var(--color-(bluegray
No local re-implementations or deep importsESLint no-restricted-imports (block @system/*/src/*, block copied-in paths)
Layer boundaries (atoms don't import organisms)dependency-cruiser rules, or eslint-plugin-boundariesOnly if the codebase has layers
Accessibility basics in JSX or templateseslint-plugin-jsx-a11y (React), eslint-plugin-vuejs-accessibility (Vue)Runtime a11y is accessibility-per-component's job
Deprecated components and tokens must not be newly used@typescript-eslint/no-deprecated on @deprecated JSDoc; no-restricted-imports for removed pathsPairs with deprecation-process
Every exported component has docseslint-plugin-jsdoc require-jsdoc on exported components; a stories-present check is a script for cicd-integration
Token, theme or contribution files need system-team reviewCODEOWNERSRequires branch protection or rulesets, which cicd-integration documents
Every release has a changelog entryChangesets (changeset status in CI) or commitlint with conventional commitsWhich one is the team's call; encode the one they use
Design review, accessibility audit, decision record before mergeNo executable form. GOVERNANCE.md with owner and checkpoint; a PR template checkbox at mostNever claim these are automated
Show full SKILL.md (546 more words)Show less

Step 3: Write the configuration

  • Edit the config files that exist; don't replace them. Add rules to the existing ESLint or Stylelint config and keep the team's other settings. If no config exists for a tool, write one and say it's new; don't add a tool the team hasn't chosen without asking.
  • Trace every rule. Above each added rule, a comment: // GOV: <rule sentence> — source: CONTRIBUTING.md#naming. In JSON configs that can't carry comments, put the trace in GOVERNANCE.md next to the rule id.
  • Real names. The primitive-token pattern, the package name in no-restricted-imports, the paths in CODEOWNERS all come from the repository, not from the example in Step 2.
  • Severity from the team's model. First encoding usually ships as warn; Step 5 says when a rule is ready to become error.
  • GOVERNANCE.md (in docs/ or beside CONTRIBUTING.md): one table of every rule from Step 1 with its source, its tool and rule id or "manual", who checks it and at which point (PR review, release, quarterly), and the exception route the team stated. Then a "Proposed, not yet policy" list for anything you suggested that no source supports, each with a one-line reason, for the team to accept or delete. An exception process is written only if the team has one; don't invent approval levels.

Step 4: Calibrate against the codebase

Run each tool in report mode against the repository (npx eslint . --format json, npx stylelint "**/*.css" --formatter json, npx depcruise src) and count current violations per added rule. Report the counts. A rule that fires four hundred times on day one ships as warn with a note that it needs a cleanup pass (a token-compliance run gives the list); a rule that fires zero times may be misconfigured, so confirm it fires on a known-bad line before trusting the zero, per the empty-result rule in the output-discipline note. Don't fix violations in this run.

Step 5: Summarise in chat

  • Headline: rules encoded (by tool), rules written to GOVERNANCE.md as manual, rules proposed
  • Files: every config written or edited, with the rule count added to each
  • Calibration: violations per rule today, and which rules are safe to promote to error
  • Next: cicd-integration to run these in CI and document branch protection; token-compliance for the cleanup list; decision-record for any rule the team argued about
  • Scope: the block from the output-discipline note: sources inspected, sources not reached (wikis, Slack, people), and the note that the encoded set is what was found, not everything the team believes

Quality checks

  • Every added lint rule carries a trace comment with a source path or team; no rule exists in the config that isn't in the Step 1 table
  • No rule is described as automated unless a tool in the config runs it; process gates live in GOVERNANCE.md with a human checkpoint
  • Token prefixes, package names and paths in the config are the repository's, not the examples'
  • Existing config files were edited, not overwritten, and the summary says what was added to each
  • Every rule was run in report mode and its current violation count is in the summary, with a known-bad probe confirming any zero
  • Proposed rules are in their own list with a reason each, and none is in a config file
  • The output ends with a Scope block

© murphytrueman, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/governance-encoder of murphytrueman/design-system-ops.

Open the folder on GitHubat commit f167898

Compare with similar skills

Governance Encoder next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Governance Encoder compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Governance Encoder this skillmurphytrueman/design-system-ops203—~2.6kAutomated safety check: PassMIT
Modern Web GuidanceJetBrains/skills3643 repos~1.4kAutomated safety check: PassApache-2.0
Frappe Testing CicdImpertio-Studio/Frappe_Claude_Skill_Package187—~3.2kAutomated safety check: NotesMIT
Lint Newgetsentry/sentry46k—~1.8kAutomated safety check: PassCustom licence
Typescript Styletjx666/vscode-mcp106—~961Automated safety check: PassCustom licence
Configuration GeneratorArabelaTso/Skills-4-SE253—~2.8kAutomated safety check: NotesApache-2.0

Similar skills

  • Modern Web Guidance

    JetBrains/skills

    Official

    Search tool for modern web development best practices. An agent skill from JetBrains/skills.

    364 GitHub starsUsed in 3 repos~1.4k tokens
    DevOps & CloudAuto-check passed
  • Frappe Testing Cicd

    Impertio-Studio/Frappe_Claude_Skill_Package

    A skill your agent uses when setting up CI/CD pipelines for Frappe apps, configuring GitHub Actions test workflows, or adding linting and security scanning.

    187 GitHub stars~3.2k tokensUpdated 21 days ago
    DevOps & CloudAuto-check: notes
  • Lint New

    getsentry/sentry

    Official

    Create a new ESLint rule with tests for eslintPluginScraps. An agent skill from getsentry/sentry.

    46k GitHub stars~1.8k tokensUpdated today
    DevelopmentAuto-check passed
  • Typescript Style

    tjx666/vscode-mcp

    TypeScript code style and repo conventions for VSCode MCP — inference vs explicit types, ESM import suffixes, zod schema contracts, async VSCode/Node APIs, JSON-safe IPC results, JSDoc for public…

    106 GitHub stars~961 tokensUpdated 2 mo ago
    DevelopmentAuto-check passed
  • Configuration Generator

    ArabelaTso/Skills-4-SE

    Generate configuration files for applications, services, and infrastructure.

    253 GitHub stars~2.8k tokensUpdated 1 mo ago
    DevOps & CloudAuto-check: notes
  • Biome

    managedcode/dotnet-skills

    Use Biome in .NET repositories that ship Node-based frontend assets and want a fast combined formatter-linter-import organizer for JavaScript, TypeScript, CSS, JSON, GraphQL, or HTML.

    486 GitHub stars~1.7k tokensUpdated yesterday
    DevelopmentAuto-check passed

More from murphytrueman/design-system-ops

All 36 skills in this repo
  • Agent Instructions

    murphytrueman/design-system-ops

    Write the AGENTS.md that tells coding agents how to use this design system: where things live, sourced rules, how to check work, what not to do; Claude, Cursor or Copilot pointers on request.

    203 GitHub stars~2.3k tokensUpdated 14 days ago
    Auto-check passed
  • AI Component Description

    murphytrueman/design-system-ops

    Write a six-section prose description (purpose, props, anti-patterns, composition, accessibility, examples) for a Figma component's description field so LLMs read it via MCP.

    203 GitHub stars~4.7k tokensUpdated 14 days ago
    Auto-check passed
  • Change Communication

    murphytrueman/design-system-ops

    Write release notes, a migration guide and a team announcement for a design system change that is already decided, scaled to its impact.

    203 GitHub stars~3.4k tokensUpdated 14 days ago
    Auto-check passed
  • Codebase Index

    murphytrueman/design-system-ops

    Generate machine-readable index files in .ai/index/ (component inventory, uses/usedBy graph, stats) for AI agents.

    203 GitHub stars~4.7k tokensUpdated 14 days ago
    Auto-check passed
  • Codemod Generator

    murphytrueman/design-system-ops

    Generate tested jscodeshift/postcss codemods for design system migrations: token renames, prop renames or removals, import paths, component swaps.

    203 GitHub stars~4.9k tokensUpdated 14 days ago
    Auto-check passed
  • Component API Validator

    murphytrueman/design-system-ops

    Audit prop APIs across a component library: naming consistency, boolean/default patterns, type coverage, exported types, breaking changes between versions.

    203 GitHub stars~4.3k tokensUpdated 14 days ago
    Auto-check passed

Works with

Questions about Governance Encoder

What does Governance Encoder do?

Turn written governance rules into enforcement that runs: ESLint, Stylelint, dependency-cruiser and CODEOWNERS config traced to sources, plus GOVERNANCE.md for rules with no executable form. Governance Encoder is an agent skill from murphytrueman/design-system-ops.md for rules with no executable form.

When should I use Governance Encoder?

Governance Encoder fits situations like: tasks that involve Linting and formatting; tasks that involve CI/CD.

How do I install Governance Encoder in Claude Code?

Run `npx skills add murphytrueman/design-system-ops --skill governance-encoder -a claude-code`. Or copy the skill folder (skills/governance-encoder in murphytrueman/design-system-ops) into .claude/skills/governance-encoder in your project. Claude Code loads it when a task matches its description.

How do I install Governance Encoder in Codex?

Run `npx skills add murphytrueman/design-system-ops --skill governance-encoder -a codex`. Or copy the skill folder (skills/governance-encoder in murphytrueman/design-system-ops) into .agents/skills/governance-encoder in your project. Codex loads it when a task matches its description.

Can I use Governance Encoder in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add murphytrueman/design-system-ops --skill governance-encoder -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/governance-encoder, .gemini/skills/governance-encoder, .github/skills/governance-encoder and .opencode/skills/governance-encoder in your project.

What does Governance Encoder need to run?

Going by SKILL.md and its folder, Governance Encoder needs the command-line tools its instructions call (npx and changeset). Our summary lists: Node.js. Its frontmatter pre-approves these tools: Read, Write, Grep, Glob, Bash(cat:*), Bash(find:*), Bash(head:*), Bash(ls:*), Bash(npx eslint:*), Bash(npx stylelint:*), Bash(npx depcruise:*).

Does Governance Encoder access the network?

SKILL.md contains no URLs. Its commands use npx, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Governance Encoder safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Governance Encoder use?

Governance Encoder is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Governance Encoder use?

About 2.6k tokens (SKILL.md is roughly 11k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Governance Encoder?

Skills that share tags, products or a category with Governance Encoder: Modern Web Guidance (JetBrains/skills, 364 stars), Frappe Testing Cicd (Impertio-Studio/Frappe_Claude_Skill_Package, 187 stars), Lint New (getsentry/sentry, 46k stars) and Typescript Style (tjx666/vscode-mcp, 106 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Governance Encoder?

murphytrueman (a GitHub user) maintains it in murphytrueman/design-system-ops, which has 203 GitHub stars. The repository holds 36 skills in this directory. The repository was last updated on September 24, 2026.

Source: murphytrueman/design-system-ops on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.