Hi, I’m a junior dev from Korea, so sorry if my English sounds a bit awkward.
I use Cursor a lot, and I kept running into one small but annoying problem.
Every time I opened a new chat, I had to explain the same repo rules again: run the tests, don’t touch generated files, follow this project structure, etc.
Last week the agent edited an auto-generated file, and I only noticed after CI failed. That was the point where I thought, okay, I need a better way to handle this.
So I started moving those instructions into the repo instead of repeating them in chat. Mostly AGENTS.md, plus a few small check scripts. Cursor’s agent can read them, so I don’t have to explain everything again every session.
I cleaned this up into a small open source kit.
The idea is simple: give the agent one prompt, let it read the kit, inspect your repo, and add only a small set of durable rules/checks. It is not meant to copy a huge template into your project.
I’m still a junior and still learning, so I’m sure there are rough edges.
Hey, great work, and it really doesn’t feel like “yet another .cursorrules template.” Don’t worry about your English, it’s all clear.
What stood out when I took a closer look:
A prompt-first approach instead of an installer is the right call. “Inspect the repo, add the minimum, don’t overwrite files without explaining why” solves the main pain with these kits. They usually dump a huge template that nobody maintains later.
Splitting “harness health” and “agent effectiveness” is a strong and honest move. It’s clear you’re not selling the illusion that scanning a repo automatically means fewer agent mistakes. Measuring separately via task outcomes is exactly what many similar projects are missing.
A dogfood repo on Django and fixture tests by profiles is a good sign this isn’t just a README, it’s actually being tested.
A couple thoughts:
Cursor natively reads AGENTS.md and project rules, so your kit fits the existing mechanism well. Docs if useful: Rules | Cursor Docs
Small communication nuance: /harness doctor, /harness review, etc are prompt-driven steps, not built-in Cursor slash commands. It’s worth calling that out clearly in the README so new users don’t look for them in the editor command palette.
Since you’re already using the /harness ... syntax, in Cursor you can make them real custom slash commands via files in .cursor/commands/ project-level or ~/.cursor/commands/ global. Then they show up as real commands in the palette, not just a prompt convention, and the communication issue goes away. This could be a strong kit feature too. It wouldn’t just describe steps, it would install ready-to-use commands directly in Cursor.
Overall, no, you didn’t overdo it. The problem is real, and the solution is thoughtfully designed. Let me know how feedback and adoption go, I’d love to see where this heads.
Thank you so much for taking the time to look at it deeply.
To be honest, my English is not very good, so I may not be able to express everything perfectly. But your feedback was very clear and helpful to me.
I’m really glad that the difference between harness health and agent effectiveness made sense. That was one of the points I wanted to be honest about, because I didn’t want to pretend that a repo scan alone can prove better agent performance.
Your point about /harness doctor and /harness review is also very important. I think you’re right — I should make it clearer in the README that they are prompt-driven workflows, not built-in Cursor slash commands.
And the idea of turning them into real Cursor custom slash commands is honestly very interesting. I didn’t think deeply about that yet, but it sounds like a strong next step for the kit. I’ll look into .cursor/commands/ and see how I can make that part more practical.
Thanks again. As a beginner developer, this kind of thoughtful feedback really helps me improve the project.