eser-rules-manager and eser/rules
I've been thinking for a long time about how to make projects with large codebases work properly with agentic tools. For me, the process starting with .cursorrules evolved first to CLAUDE.md, and then continued with Skills after Claude Skills were introduced—a journey of discovery and practical experience.
What I noticed in this process was this: in every new project, I was writing the same instructions from scratch:
- "Write commit messages in this format"
- "Handle errors with this pattern"
- "Follow this convention when writing tests"...
These were things that didn't change from project to project, but I had to explain them again every time.
eser/rules contains the set of rules I've accumulated through this work, refined to a "download and use" level for almost every codebase.
You can find this work on GitHub in the eser/rules repository.
To use it directly with an agentic tool like Claude Code, installation is possible with a single command:
npx degit eser/rules/.claude/skills .claude/skills
Since Claude Code and GitHub Copilot natively recognize the .claude/skills/ directory, no additional configuration is needed. If you're using Cursor, you just need to add a single-line redirect to your .cursorrules file. So whatever tool you use — Claude Code, Copilot, Cursor, or another agent — the same rules work everywhere.
eser-rules-manager
However, as I mentioned above, as I carried this rule set from project to project, I felt something was missing.
Every project has its own nature. The needs of a Go project differ from a TypeScript project, and the expectations of a monorepo differ from a single-module service.
So for me, beyond carrying generalized rules, it became a requirement to make agentic models accept the project's own rules.
At this point, as "a rule that defines rules," I created eser-rules-manager, which I call a meta-skill. This skill works like an orchestra conductor: it organizes existing rules, suggests updates when conventions change, and ensures new rules are placed in the right location.
Thus, while eser/rules provides a direct "foundation," it became possible to define new rules with a command like this while continuing project development within the agentic loop:
/eser-rules-manager never use `interface{}` in go projects, use `any` instead
This skill will edit the existing go-practices skill and add this project-specific rule. If go-practices didn't exist, it would create it automatically.
It also has a powerful side for teams: thanks to these rules added to the repo, everyone contributing to the project — whether human or AI — works from the same playbook. Consistency is automatically ensured in pull requests, code reviews, and refactors.
The project is open source under the Apache 2.0 license and open to contributions. If you've found a better pattern, noticed an inconsistency, or want to add a new skill, I'm waiting for your PRs.