The easiest health checkup for your codebase. Like a blood test for your code — get a full diagnostic report, catch hidden bugs, vulnerabilities, and code quality issues in minutes.
We give your agent skills, not pills!
When we first launched LetMeCheck, we believed the biggest problem was helping teams identify code quality issues.
After speaking to more founders, agencies, freelancers, and developers, we realized the real challenge runs much deeper.
The problem isn’t just finding issues.
The real challenge is confidently shipping AI-generated code at scale.
Today, AI tools like Claude, Cursor, and ChatGPT help teams ship incredibly fast. But speed often comes with hidden technical debt: bugs, security risks, poor test coverage, complexity, and fragile architecture.
That’s where the blood test analogy became very real for us.
A blood test doesn’t fix your health.
It helps you understand what’s happening inside before problems become serious.
That’s exactly what LetMeCheck does for your codebase.
This relaunch is built around everything we learned from our users.
LetMeCheck now helps you:
→ Analyze your codebase
→ Check for hidden issues
→ Generate custom AI skill files for your coding agents
→ Fix issues faster
→ Rescan and track improvements
The most exciting part of this launch is custom skill generation.
You can now generate project-specific skills for coding agents so they better understand your code quality standards, avoid repeating mistakes, and produce better outputs with less rework and token waste.
Our mission is simple:
Help teams move from working code to confident code.
Because in the AI era, writing code is becoming easy.
Maintaining quality is the real challenge.
We’re excited to hear your thoughts and feedback 🚀
Report
The custom skill generation is the interesting part. Most code-quality tools produce a report the developer has to internalize and remember to apply next time. Piping the diagnostic back into the agent as project-specific skills is a more honest loop, the agent produced the fragility, the agent gets the fix.
Building MotionFy solo with Cursor, the pattern I keep hitting isn't obvious bugs (those get caught fast) but subtle drift, the codebase slowly starts violating conventions I established in month one because the agent doesn't remember them and I don't re-prompt them. That's the class of debt that gets expensive later, and it's exactly what a project-specific skill pack should catch.
Curious about the closed-loop metric side, when you rescan and detect "measurable improvement," what's the definition? Reduction in specific issue types, LOC of hotspot code, or something else? Trying to figure out if the skill packs actually train the agent or just prevent recurrence of the last problem.
@elias_motionfy You nailed the core problem: subtle drift is the expensive debt that most tools miss. That's exactly why we built LetMeCheck — the agent creates the fragility, the agent gets the fix, creating that honest loop you mentioned.
On measurable improvement: We track multiple dimensions when you rescan:
Issue reduction by type (bugs, code smells, security hotspots, vulnerabilities)
But here's the key: the skill packs don't just prevent recurrence — they actively train the agent's behavior. When you generate a skill file, we embed your conventions, patterns, and anti-patterns as context. So next time the agent faces a similar scenario, it doesn't need to guess or re-prompt — it has the specific guardrails baked in.
The closed-loop metric is whether the agent maintains the conventions you care about over time. Not just "did we fix the last bug?" but "is the codebase staying aligned with the standards we defined?"
So yes, it's both preventing recurrence and actively training — the skill file becomes the agent's memory for your project's specific DNA.
Report
@new_user___1542025a3013bd22f1e340b The distinction between "preventing recurrence" and "actively training" is where most tools blur the line, so it's worth pinning down. Prevention is a filter, the agent tries something, the skill pack blocks it. Training would mean the agent internalizes the pattern and stops attempting the wrong thing in the first place. Two very different behaviors, even if the output looks similar in the short term.
Where I'd want to see this go: the second-order effect. If the skill pack is doing its job, over time the number of interventions should drop. The agent asks fewer wrong questions. The initial prompts get shorter because the agent has already absorbed the base conventions. That decay curve is probably the truest signal of "actively training" vs "preventing recurrence", one plateaus, the other slopes down.
Honestly the "codebase staying aligned with the standards we defined" framing is the right north star. Most linting-adjacent tools measure whether individual issues got fixed. You're measuring whether the codebase stops drifting in the first place. That's a harder problem to measure but a much more useful one to solve.
@elias_motionfy you are right, I built letmecheck for myself because i was facing this issue of working with multiple projects at a time and it was not possible for me to:
keep sending the whole context all the time.
explain how something needs to be done specifically for that project.
burn tokens in retrying
depend on AI to write unit tests - most of the time it just hardcoded resposnes to pass the tests :(:(
In order to solve these problems i created a simple platform for me, which is now helping others as well.
At the end of the day you need to be in control of what you are building - you cannot manage what you cannot monitor.
Report
@new_user___1542025a3013bd22f1e340b The "hardcoded responses to pass the tests" bit is the moment every solo builder recognizes but rarely names publicly. It's the class of failure that's technically correct, the tests pass, but functionally useless because it's optimizing for the metric instead of the goal.
Building for yourself first is the honest path. Everyone talks about "build what you'd pay for" but half the time that's rationalization for a product they wanted to build anyway. Building because you literally cannot solve a problem another way is a different thing entirely, the product has a job before it has users.
"You cannot manage what you cannot monitor" is a good line to end on. That's really what the skill packs do, they make the drift visible so you can actually intervene, instead of finding out three months later that the codebase quietly went sideways.
Report
ran it against a side project and it flagged a sneaky sql injection i had missed in a rush. the skill pack idea is clever, feels like a real feedback loop instead of a one-off linter.
@asyabuldukatas The code audit report is generated using industry standard tools like Sonar. This issues are then analysed and represented in human readable format.
A security skill is a narrow guardrail: it tells your AI to watch for vulnerabilities. LetMeCheck scans the full health of your codebase — security, reliability, maintainability, and complexity — then generates a custom skill file tailored to your repo's actual patterns and technical debt.
Fable 5 is a powerful but expensive general model. LetMeCheck doesn't replace your coding agent — it supercharges the one you already use with codebase-specific context. In fact, pair the skill file we generate with a lower-cost model, and you can get Fable 5-like results without the Fable 5 price.
So the difference is: security is just one part of the picture, and we make your existing agent smarter for your specific code, so you don't need to pay for a bigger, pricier engine.
Replies
LetMeCheck.ai
The custom skill generation is the interesting part. Most code-quality tools produce a report the developer has to internalize and remember to apply next time. Piping the diagnostic back into the agent as project-specific skills is a more honest loop, the agent produced the fragility, the agent gets the fix.
Building MotionFy solo with Cursor, the pattern I keep hitting isn't obvious bugs (those get caught fast) but subtle drift, the codebase slowly starts violating conventions I established in month one because the agent doesn't remember them and I don't re-prompt them. That's the class of debt that gets expensive later, and it's exactly what a project-specific skill pack should catch.
Curious about the closed-loop metric side, when you rescan and detect "measurable improvement," what's the definition? Reduction in specific issue types, LOC of hotspot code, or something else? Trying to figure out if the skill packs actually train the agent or just prevent recurrence of the last problem.
LetMeCheck.ai
@elias_motionfy You nailed the core problem: subtle drift is the expensive debt that most tools miss. That's exactly why we built LetMeCheck — the agent creates the fragility, the agent gets the fix, creating that honest loop you mentioned.
On measurable improvement: We track multiple dimensions when you rescan:
Issue reduction by type (bugs, code smells, security hotspots, vulnerabilities)
Complexity metrics (cyclomatic complexity, cognitive load)
Maintainability indicators (duplication density, technical debt ratio)
Reliability scores (test coverage, change risk)
But here's the key: the skill packs don't just prevent recurrence — they actively train the agent's behavior. When you generate a skill file, we embed your conventions, patterns, and anti-patterns as context. So next time the agent faces a similar scenario, it doesn't need to guess or re-prompt — it has the specific guardrails baked in.
The closed-loop metric is whether the agent maintains the conventions you care about over time. Not just "did we fix the last bug?" but "is the codebase staying aligned with the standards we defined?"
So yes, it's both preventing recurrence and actively training — the skill file becomes the agent's memory for your project's specific DNA.
@new_user___1542025a3013bd22f1e340b The distinction between "preventing recurrence" and "actively training" is where most tools blur the line, so it's worth pinning down. Prevention is a filter, the agent tries something, the skill pack blocks it. Training would mean the agent internalizes the pattern and stops attempting the wrong thing in the first place. Two very different behaviors, even if the output looks similar in the short term.
Where I'd want to see this go: the second-order effect. If the skill pack is doing its job, over time the number of interventions should drop. The agent asks fewer wrong questions. The initial prompts get shorter because the agent has already absorbed the base conventions. That decay curve is probably the truest signal of "actively training" vs "preventing recurrence", one plateaus, the other slopes down.
Honestly the "codebase staying aligned with the standards we defined" framing is the right north star. Most linting-adjacent tools measure whether individual issues got fixed. You're measuring whether the codebase stops drifting in the first place. That's a harder problem to measure but a much more useful one to solve.
LetMeCheck.ai
@elias_motionfy you are right, I built letmecheck for myself because i was facing this issue of working with multiple projects at a time and it was not possible for me to:
keep sending the whole context all the time.
explain how something needs to be done specifically for that project.
burn tokens in retrying
depend on AI to write unit tests - most of the time it just hardcoded resposnes to pass the tests :(:(
In order to solve these problems i created a simple platform for me, which is now helping others as well.
At the end of the day you need to be in control of what you are building - you cannot manage what you cannot monitor.
@new_user___1542025a3013bd22f1e340b The "hardcoded responses to pass the tests" bit is the moment every solo builder recognizes but rarely names publicly. It's the class of failure that's technically correct, the tests pass, but functionally useless because it's optimizing for the metric instead of the goal.
Building for yourself first is the honest path. Everyone talks about "build what you'd pay for" but half the time that's rationalization for a product they wanted to build anyway. Building because you literally cannot solve a problem another way is a different thing entirely, the product has a job before it has users.
"You cannot manage what you cannot monitor" is a good line to end on. That's really what the skill packs do, they make the drift visible so you can actually intervene, instead of finding out three months later that the codebase quietly went sideways.
ran it against a side project and it flagged a sneaky sql injection i had missed in a rush. the skill pack idea is clever, feels like a real feedback loop instead of a one-off linter.
LetMeCheck.ai
@srammoa There you go! Thanks for giving it a try!
Yes, intention is to make it valuable - identify and fix!
How does it actually detect the hidden stuff - is it running static analysis, LLM-based review, or some combo of both under the hood?
LetMeCheck.ai
@asyabuldukatas The code audit report is generated using industry standard tools like Sonar. This issues are then analysed and represented in human readable format.
commitify.me
seems like strong to delve deep into security. But the what’s the difference between a skill that checks security + fable 5 vs your app?
LetMeCheck.ai
@mehdigreefhorst Very good question.
A security skill is a narrow guardrail: it tells your AI to watch for vulnerabilities. LetMeCheck scans the full health of your codebase — security, reliability, maintainability, and complexity — then generates a custom skill file tailored to your repo's actual patterns and technical debt.
Fable 5 is a powerful but expensive general model. LetMeCheck doesn't replace your coding agent — it supercharges the one you already use with codebase-specific context. In fact, pair the skill file we generate with a lower-cost model, and you can get Fable 5-like results without the Fable 5 price.
So the difference is: security is just one part of the picture, and we make your existing agent smarter for your specific code, so you don't need to pay for a bigger, pricier engine.