Ragebait Critic

An uncompromising AI work critic that identifies weaknesses in projects, code, documents and ideas through direct, evidence-based feedback.

Open sourceAI critiqueProject review

Open source ↗Contact ↗

Project overview

The engine turns submitted work into a structured review with findings, severity, supporting evidence and recommended next actions. The sharp tone serves the analysis: expose blind spots before a project reaches users or reviewers. Source code and usage documentation are openly available on GitHub.

How the project works

Submitted work is examined for weaknesses and blind spots. The result is a structured report with findings, evidence, severity and recommended actions. Direct criticism is intended to improve the work before external review.

Code, project, document and idea review
Evidence-based findings and priority actions
Open-source implementation and documentation

PR / 01

Criticism that produces a repair plan

Ragebait Critic is designed for builders who want their work challenged before it reaches customers, reviewers or investors. It examines weak assumptions, incomplete reasoning and implementation problems with a deliberately direct tone. The purpose is to reveal what needs attention and why. Criticism is tied to the submitted work and the available evidence, rather than being an unsupported judgement about the person who created it.

PR / 02

Different inputs, one review structure

The engine can work with text, a file, a URL or a local project directory. Its documented domains include code, projects, design, academic writing, SEO, PR and general work. A repository review can consider how components fit together, while a document review can focus on argument and evidence. The input type changes the review context, but the output remains structured so findings can be inspected and acted on.

PR / 03

What the report contains

A review brings together a score, concrete findings, severity, evidence, impact and recommended actions. Priority actions help distinguish important repairs from minor improvements. Blind spots make uncertainty visible instead of hiding it behind confident language. The canonical output is structured JSON, with Markdown available as a human-readable representation. A finding should still be checked against the actual work before it is treated as fact.

PR / 04

Tone and review intensity

The documented intensity choices are normal, brutal and nuclear. An optional roast style adds sharper presentation while retaining a connection to actual flaws. The useful part is the evidence and repair direction, not the harshness alone. Users can choose a tone appropriate to their context, verify disputed findings and decide which recommendations should influence the next version of the work.

PR / 05

Open development and practical use

Source code and usage documentation are available in the linked GitHub repository. The review engine is a separate tool; this company page explains the project rather than processing uploaded work. Model and provider configuration should be chosen with the sensitivity of the input in mind. A practical cycle is to review, verify the findings, fix the prioritised issues and then reassess the revised work.

Development & availability

The project is available as open source on GitHub. Its critique is a review aid rather than a guarantee that every flaw is detected. Users should verify findings and decide which changes are appropriate.