back to home

peteromallet / desloppify

Agent harness to make your slop code well-engineered and beautiful.

View on GitHub
2,578 stars
176 forks
2 issues
PythonHTMLMakefile

AI Architecture Analysis

This repository is indexed by RepoMind. By analyzing peteromallet/desloppify in our AI interface, you can instantly generate complete architecture diagrams, visualize control flows, and perform automated security audits across the entire codebase.

Our Agentic Context Augmented Generation (Agentic CAG) engine loads full source files into context on-demand, avoiding the fragmentation of traditional RAG systems. Ask questions about the architecture, dependencies, or specific features to see it in action.

Source files are only loaded when you start an analysis to optimize performance.

Embed this Badge

Showcase RepoMind's analysis directly in your repository's README.

[![Analyzed by RepoMind](https://img.shields.io/badge/Analyzed%20by-RepoMind-4F46E5?style=for-the-badge)](https://repomind.in/repo/peteromallet/desloppify)
Preview:Analyzed by RepoMind

Repository Overview (README excerpt)

Crawler view

Desloppify - an agent harness to make your codebase 🤌 Desloppify gives your AI coding agent the tools to identify, understand, and systematically improve codebase quality. It combines mechanical detection (dead code, duplication, complexity) with subjective LLM review (naming, abstractions, module boundaries), then works through a prioritized fix loop. State persists across scans so it chips away over multiple sessions, and the scoring is designed to resist gaming. The score gives your agent a north-star, and the tooling helps it plan, execute, and resolve issues until it hits your target — with a lot of tricks to keep it on track. A score above 98 should correlate with a codebase a seasoned engineer would call beautiful. That score generates a scorecard badge for your GitHub profile or README: Currently supports 29 languages — full plugin depth for TypeScript, Python, C#, C++, Dart, GDScript, Go, and Rust; generic linter + tree-sitter support for Ruby, Java, Kotlin, and 18 more. For C++ projects, is the primary analysis path and repositories fall back to best-effort local include scanning. For your agent's consideration... Paste this prompt into your agent: How it works **Scan** runs mechanical detectors across your codebase — dead code, duplication, complexity, test coverage gaps, naming issues, and more. Each issue is scored by dimension (File health, Code quality, Test health, etc.). **Review** uses an LLM to assess subjective quality dimensions — naming, abstractions, error handling patterns, module boundaries. These score alongside the mechanical dimensions. **Triage** is where prioritization happens. The agent (or you) observes the findings, reflects on patterns, organizes issues into clusters, and enriches them with implementation detail. This produces an ordered execution queue — only items explicitly queued appear in . Before triage, all mechanical issues are visible in the queue sorted by impact, which can be noisy. **Execute** is the fix loop: → fix → → . Items come from the triaged queue. Autofix handles what it can; the rest needs manual or agent work. **Rescan** verifies improvements, catches cascading effects, and feeds the next cycle. State persists in so progress carries across sessions. The scoring resists gaming — wontfix items widen the gap between lenient and strict scores, and re-reviewing dimensions can lower scores if the reviewer finds new issues. From Vibe Coding to Vibe Engineering Vibe coding gets things built fast. But the codebases it produces tend to rot in ways that are hard to see and harder to fix — not just the mechanical stuff like dead imports, but the structural kind. Abstractions that made sense at first stop making sense. Naming drifts. Error handling is done three different ways. The codebase works, but working in it gets worse over time. LLMs are actually good at spotting this now, if you ask them the right questions. That's the core bet here — that an agent with the right framework can hold a codebase to a real standard, the kind that used to require a senior engineer paying close attention over months. So we're trying to define what "good" looks like as a score that's actually worth optimizing. Not a lint score you game to 100 by suppressing warnings. Something where improving the number means the codebase genuinely got better. That's hard, and we're not done, but the anti-gaming stuff matters to us a lot — it's the difference between a useful signal and a vanity metric. The hope is that anyone can use this to build something a seasoned engineer would look at and respect. That's the bar we're aiming for. If you'd like to join a community of vibe engineers who want to build beautiful things, come hang out. --- Issues, improvements, and PRs are hugely appreciated — github.com/peteromallet/desloppify. MIT License