ASScoding: In Search of the Standard

There was a time when software development was the Wild West. There were no clear conventions, every team improvised, and maintaining a project was more an act of faith than an engineering discipline. Over the years, standards, best practices, and craftsmanship finally emerged.

Today, AI agent–driven development is at that exact same point. The gold rush has started all over again. Everyone is running toward the new tools, each digging on their own land, and no one really knows where the true vein lies.

Modern developer tools —each with its own nomenclature and philosophy— are trying to solve the same problem from different angles: how to give context to an agent, how to teach it to work, and how to ask for concrete results without everything turning into an unmanageable prompt. It is a lawless frontier, where every tool sets its own rules.

Amid this apparent chaos, a common pattern is starting to emerge. Not a formal standard, but a shared structure that appears again and again in recent documentation, real-world repositories, and advanced workflows. A discovery that could change the rules of the game.

Three primitives. Three artifacts. An acronym impossible to forget. ASScoding.

---

The chaos before order

If you look at how development agents work today, you will always find the same concepts, even if they go by different names:

• Instructions or global rules that define how to work
• Capabilities or concrete tools to perform specific tasks
• Requirements for functionality, correctness, or product improvement

And all of this is defined in natural language, slightly formalized in markdown files with the occasional YAML header. This is the new programming language. The new gold everyone is trying to extract.

But that’s where the agreement ends. The tools (ClaudeCode, Copilot, Cursor, Antigravity, etc.) evolve rapidly in a highly competitive environment. And that makes each one solve the same problem in its own way. Everyone digs their own mine, with no coordination, no order.

The problem is that these files are our new programming primitives.

It’s as if the syntax of Java, Python, or TypeScript were different in VS Code, IntelliJ, or Eclipse.

We need —and the industry is slowly converging toward— a common standard for these files, for this new syntax. We need someone to bring order to this lawless prairie. And it seems to be based on three fundamental concepts:

• A: AGENTS.md
• S: skills/*/SKILL.md
• S: specs/*.spec.md

Let’s take a closer look at this trio of aces. ASScoding.

---

AGENTS.md — The law of the land

Initially called rules, this concept was popularized by Cursor with its .cursorrules. Others adapted it in their own way: Copilot with .github/copilot.instructions.md, ClaudeCode with CLAUDE.md, and so on. Everyone planted their flag on the frontier.

At some point, someone proposed the generic name AGENTS.md for these files. Little by little, it started to prevail. And now it is the first major AI-for-development standard. The first discovery that everyone began to follow.

It is the modern equivalent of a system’s Constitution. It is written sparingly, changed rarely, and always respected. It is the code that authority enforces within its jurisdiction.

What should it contain?

• A brief description of the product being built
• The technology stack
• Core developer workflow commands
• A folder map
• Development environment specifics
• Cultural and conversational style guidelines

Fewer lines, shorter sentences. Context is a limited resource.

---

skills/*/SKILL.md — The craft

An agent without explicit skills is just an improviser with a keyboard. A gold prospector without tools, digging blind.

Anthropic deserves credit here for evolving simplistic rule systems into something far more powerful: Skills.

Skills describe how things are done, not what needs to be done today. They are reusable operational knowledge. The techniques experienced miners pass on to newcomers.

A well-written skill:

• States its purpose and invocation conditions
• Explains how to perform the task
• Delegates detail to avoid context overload
• May include examples, templates, static assets, and executable code

Two key properties:

• Automatically discovered through context and workflow
• Not just prose: examples, templates, executable artifacts

This is not prompt engineering. This is craftsmanship.

---

specs/*.spec.md — The job

And finally, the real reason we are here: solving user problems.

Problems, solutions, and acceptance criteria must be fully and correctly specified for agents to act effectively. Without clear specs, you’re shooting blind in a dawn duel.

That structured natural-language description, stored in markdown, is what we call specs.

Specs answer simple questions:

• What problem must be solved?
• What solution is expected at a high level?
• When is it considered done?

Like skills, specs must be detailed, especially when defining the problem. They are the treasure map that tells you where to dig.

Specs do not explain how to do the work. Skills do that. Specs organize action. They are the sheriff’s orders.

---

ASScoding: bringing order to the Wild West

ASScoding means developing software with AI agents using:

• AGENTS.md for global context
• skills/ for operational knowledge
• specs/ for concrete work

It is not a tool or a framework. It is a way of working.

ASScoding assumes that:

• Context is intentional
• Skills are documented
• Specifications are explicit

Exactly like professional software development before AI — when order finally replaced chaos.

---

Conclusion

The name ASS makes people smile. Good.

Useful standards usually emerge informally and pragmatically. Just like gold rushes.

ASScoding doesn’t promise magic. It promises structure, clarity, and interoperability across tools. It promises that after the rush comes order.

In the Wild West of AI-driven development, Agents, Skills, and Specs — ASS — may become the guardian this frontier desperately needs.

The end of ruleless duels.
A code everyone can follow.