DocsQuick StartAI News
AI NewsQUALITY.md on Show HN: An Open-Source Standard for Setting Rules for AI Agents Has Arrived
Industry News

QUALITY.md on Show HN: An Open-Source Standard for Setting Rules for AI Agents Has Arrived

2026-07-02T19:05:21.324Z
QUALITY.md on Show HN: An Open-Source Standard for Setting Rules for AI Agents Has Arrived

An open-source specification called **QUALITY.md** has landed on Hacker News. It attempts to standardize the vague concept of "code quality" using a plain text file, an Agent Skill, and a CLI—so that AI Agents can truly understand a team's rules.

Yesterday a Show HN post popped up on Hacker News—the author introduced something called QUALITY.md, a spec, an Agent Skill, and a CLI combined in one. The project site, getquality.md, looks plain like a static page, but the comment section below was buzzing. Several familiar faces chimed in, including the group that previously built the Agent Skills directory site.

Simply put, this is an attempt to standardize quality constraints for AI coding agents. Cursor has .cursorrules, Claude Code has CLAUDE.md, Aider has its own config, Copilot has its own setup. Every team has a different format, and whenever they switch to a new tool, they must rewrite their rules. The idea behind QUALITY.md is to define a tool-agnostic and model-agnostic open format so that “what counts as high-quality code” becomes a version-controllable, reusable, and verifiable file.

Sounds like EditorConfig, doesn’t it? The author actually acknowledged that comparison in the comments. But QUALITY.md is much more ambitious—EditorConfig cares about indentation and line endings, while QUALITY.md aims to govern naming, structure, test coverage, comment density, API design principles, and even a team’s technical debt preferences.

Screenshot of QUALITY.md homepage showing the combined spec, Skill, and CLI architecture

One file, one Skill, one CLI

QUALITY.md’s design has three layers—this is what distinguishes it from similar projects.

The first layer is the spec itself. A QUALITY.md file in Markdown with YAML frontmatter. The frontmatter stores metadata (version, languages, scope), and the body uses structured paragraphs to describe concrete rules. What’s interesting is that the author didn’t enforce rigid JSON Schema or TOML field definitions, deliberately leaving space for natural language—since quality can’t always be fully quantified.

For example, a typical QUALITY.md might say:

---
name: backend-service-quality
version: 0.3
languages: [go, python]
scope: services/**
---

## Error Handling
- All external APIs must return structured errors; no naked panic throws
- Internal functions may wrap errors, but the error chain must not exceed 3 layers
- Do not print full stack traces to INFO-level logs

## Testing
- New handlers must have integration tests covering the happy path and at least one error branch
- Unit test coverage is not strictly required, but diff coverage must be ≥70%

Looks straightforward, but the key is: this file is readable by both humans and Agents. For humans, it’s part of the team wiki; for Agents, it’s a behavioral constraint.

The second layer is the Agent Skill. QUALITY.md naturally packages itself under Anthropic’s open Agent Skills format—i.e., a directory containing SKILL.md, along with scripts/ and references/. The Skill’s description field tells the Agent: “Activate this Skill when you’re writing code, reviewing code, generating PR descriptions, or evaluating code style.”

This step is arguably the smartest part of the design. The author didn’t reinvent a loading mechanism but instead plugged into the existing Agent Skills ecosystem—Discovery → Activation → Execution. Claude Code, Cline, and a bunch of Agent frameworks based on the Skills spec can consume it directly—no adaptation needed.

The third layer is the CLI. Once installed, you can:

  • quality init interactively generate a project’s QUALITY.md
  • quality lint <file> check a file or diff against the QUALITY.md rules
  • quality explain <rule> make the CLI explain the intent and history behind a rule
  • quality sync convert QUALITY.md into formats like CLAUDE.md, .cursorrules, Copilot instructions, etc.

That last command, sync, is the killer feature. The author clearly understands one thing: you can’t expect every IDE and Agent to instantly support your new format, so instead QUALITY.md acts as a translation layer—the single source of truth for all rules. Write once, use everywhere.

Why this appeared now

Looking back, AI coding agents went through two major reshuffles from last year to this year. The first was improved model capability—Claude 4, GPT‑5, Gemini 3, and so on. “Can it write correctly?” stopped being the main concern. The second was Agentization—moving from completion to autonomous execution. Tools like Claude Code, Codex CLI, and Cursor Agent now let AI actually run tasks inside codebases for extended periods.

The conflict emerged in that second phase. Models don’t lack capability—they lack contextual constraints. An Agent running for ten minutes might modify twenty files, but if it doesn’t know your team’s rules, the output often “looks right but can’t be merged.” So over the past six months, constraint file formats have proliferated:

  • Anthropic’s CLAUDE.md (which became a de facto standard last year)
  • Cursor’s .cursorrules and rules directory
  • Aider’s conventions.md
  • GitHub Copilot’s copilot-instructions.md
  • Various MCP servers exposing rule interfaces

Each tried to be the standard—and as a result, there wasn’t one. Maintaining a single rules file internally is exhausting; syncing it across four or five tools is worse. QUALITY.md’s value proposition boils down to this: No matter what Agent we use, all rules live here.

That’s also why it’s called QUALITY.md rather than AGENT.md or RULES.md. The author clarified in the comments: it’s not a configuration file for Agents—it’s the project’s quality declaration. Agents just happen to read it too. Shifting the semantic subject this way helps with long-term adoption beyond AI contexts—for instance, human reviewers can use it during code reviews.

Relation to Agent Skills and MCP

At this point, you might ask: isn’t this just Agent Skills wrapped in another layer?

The answer is—yes, but not exactly. Physically, QUALITY.md is an Agent Skill compliant with the Skills standard—it can be loaded by any Agent supporting Skills. But it goes further in two ways:

  1. It defines content structure. A regular Skill’s SKILL.md can contain anything. QUALITY.md enforces the inclusion of specific quality dimensions (error handling, testing, naming, documentation, etc.), making cross-project comparison and aggregation possible.
  2. It provides bidirectional conversion. Regular Skills are one-way consumables, while QUALITY.md’s CLI can reverse‑generate other tools’ config files—enabling interoperability.

Its relationship with MCP is even clearer. MCP solves how Agents connect with external tools and data sources—databases, Slack, Jira, code search. QUALITY.md solves how Agents understand internal project rules. MCP equips Agents with limbs; QUALITY.md gives them discipline—one outward, one inward.

Positioning diagram comparing QUALITY.md, Agent Skills, and MCP

Time to nitpick

Praise over—let’s talk issues. The project is still early, at v0.3. The homepage looks like a minimal landing page, and the README examples are tiny. Deploying it in medium or large codebases won’t be easy.

How are rule conflicts handled? In a monorepo, frontend and backend teams almost certainly have different quality preferences. The spec mentions a scope field allowing directory‑based scoping, but when rules conflict (e.g., root QUALITY.md bans any, a subdirectory allows any with comments), how does the Agent decide? The author says “nearest takes precedence” plus “explicit override,” but that’s always harder in engineering practice than on paper.

Are the rules soft or hard constraints? Are QUALITY.md rules just guidance for Agents, or enforced? If hard, you need accompanying linters; if soft, Agents might occasionally decide “violating this once is fine.” The CLI’s lint command currently mixes regex and AST matching, plus some LLM semantic checks—its reliability still needs evaluation.

Bootstrapping the ecosystem. The usual curse of “we’re making a new standard.” You say QUALITY.md is the single source of truth—but if Cursor and Copilot don’t support it natively, and you rely purely on CLI syncing, the user experience will always feel slightly off. The author needs early official buy‑in from major Agents, or risk becoming another unused spec.

The CLAUDE.md relationship is sensitive. Anthropic’s CLAUDE.md already has traction—many projects have one in their root directories. For QUALITY.md to become a higher‑level standard, it must convince teams to migrate. The author’s strategy is for the CLI to import CLAUDE.md into QUALITY.md, providing a migration path—but whether users will actually switch remains to be seen.

Points worth watching

Setting specifics aside, QUALITY.md reflects a larger trend: competition among AI coding tools is shifting from model capability and IDE integration to higher‑level “team engineering conventions.”

Over the past two years, vendors competed on which model they used, whether they offered tab completion, whether they could run Agents. By this year, those capabilities have largely leveled out. The real differentiator is how well a tool fits into existing team engineering practices—your Go code style, your review habits, your naming conventions—Agents have to remember those.

Whoever captures that layer of abstraction could become the next GitHub. QUALITY.md is a personal project, version 0.3, and some commenters even debate its name—but the angle is right. It’s at least more interesting than building yet another IDE or UI wrapper.

A few trends to watch:

  1. Whether Anthropic or GitHub will officially absorb this format into the Agent Skills standard
  2. Whether domestic AI‑coding tools like CodeGeeX, Trae, or Tongyi Lingma will follow suit
  3. Whether the open‑source community will spontaneously create a QUALITY.md template library—like gitignore.io—so that teams using different tech stacks can start instantly.

If you’re currently maintaining a CLAUDE.md or .cursorrules file, take ten minutes to check out getquality.md, run quality init, and compare the generated output with your handwritten one. Early‑stage projects like this often offer value simply by prompting you to clarify your own definition of “quality.”

References

Related Articles

View All

Contact Us

We usually reply quickly during business hours

Scan WeChat

Support: Hub Assistant

WeChat ID: