Project dashboard
Code quality
Quality shows whether your code is well written and lean. AI-written code usually works and still piles up problems that only surface later: an error swallowed silently, a function nobody can follow, three copies of the same snippet, a package installed for something the language already does.
The check never blocks your agent. Findings go to the dashboard, and the agent gets a summary at the start of each session.
Two layers
| Layer | When | What it looks at |
|---|---|---|
| Non-AI check | Automatically: in full at the start of each session, and on the edited files at the end of every response | Fixed rules about the code's structure. It runs on your computer and only sends the findings. |
| AI review | When you ask: /faundr:quality | The agent reads what changed (or the whole project, with --full) and finds what fixed rules can't see. It only reports issues and changes nothing. |
What the non-AI check looks for
| Type | Examples |
|---|---|
| Hidden failure | An error caught and ignored, a promise with no error handling. |
| Weak type | any, @ts-ignore and other ways of switching off type checking. |
| Too complex | Functions with too many paths (lots of ifs, loops and conditions). |
| Too much code | Unused code, duplicated snippets, commented-out code, packages the language already covers. |
| Cleanup | Leftover debugging, old TODOs. |
| Tests | Tests that are skipped or marked "only this one". |
| AI instructions | CLAUDE.md mentions a file or script that no longer exists. |
| Performance | Unbounded lists, database queries inside a loop, foreign keys without an index. |
| Project tool | Errors your project's own tsc and ESLint already report. |
Unused code, duplicated snippets, the complexity ranking and tsc/ESLint only run in the full check at the start of the session.
Supported languages
The non-AI check works without installing anything in JavaScript and TypeScript (including React Native, Vue, Angular, Svelte and Astro), Python, Flutter and Dart, PHP, Go, Java, Kotlin, C#, Rust, C, C++, Dockerfiles, HTML and CSS. It reads the code on its own; tsc and ESLint only come into play if your project already has them. The full table is in Supported languages.
What the AI review looks for
Too much code (always with a concrete replacement), hidden failures, types that don't protect anything, complexity, comments that lie, tests that don't protect anything and broken CLAUDE.md rules. The agent only logs a finding when its confidence is 80 or higher, with proof in the code. At the end, it sums up how much you can cut ("−120 lines, −2 packages possible") or says "Lean. Good to go."
The status card
It sits at the top of every tab. It shows how many issues are open and how many are high, when the last check ran, the counters (High, Open, New (7 days), Fixed) and a line for the last AI review, with a 0 to 4 score per topic.
This is also where you'll find the Remind your agent not to write too much code switch. It sends 6 lines to the agent at the start of every session, reminding it to prefer what the language and the project already have. It's off by default.
Tabs
| Tab | What it shows |
|---|---|
| Issues | The Q-n findings, filtered by type, by status (Open, Fixed, Ignored) and by New only: the ones that appeared in the last 7 days, after the first check. |
| By file | Open issues grouped by file, most serious first. |
| Most complex | The 10 files with the most possible paths, with the worst function in each. The detail view has a ready-made request asking your agent to simplify it. |
| Too much code | What you can cut, grouped by action: packages to replace or remove, duplicated code, unused code, AI review findings and commented-out code. Validation, error handling, security, accessibility and tests are never on the cut list. |
| Shortcuts | The deliberate shortcuts marked in the code (see below). |
| By session | The size of each session: lines of code and test added and removed, files and new issues. It warns you when more than 100 lines changed with no tests alongside them. |
A finding's detail view explains What it is, Why it matters and How to fix, with the file, line and rule. The buttons:
- Fix with AI copies
/faundr:quality-fix Q-n. The agent fixes it without changing what the app does, asks for your OK before touching several files or removing packages, and only closes the issue once the check stops finding it. - Ignore asks for a reason: Intentional, False positive or Later (30 days), which brings it back on its own after 30 days.
Findings from your own skills
If you already use a code review skill that isn't Faundr's, you can connect it to the dashboard with /faundr:skills. Every time it runs, the agent records what it found at the end of the response:
- each issue becomes a Q-n here, tagged via /name, and counts toward Launch and Insights like any other;
- when the skill runs again and the issue is gone, it closes on its own;
- each skill only closes its own findings, and only in the files it looked at.
See how to connect one in Workflows.
Deliberate shortcuts
Sometimes the simple version is the right call for now, with a better one later. Mark the shortcut in the code so it doesn't turn into forgotten debt:
// faundr: search by name only, improve once we pass 1,000 products
The format is // faundr: <the shortcut's limit>, <when to improve it>. The Shortcuts tab lists all of them with the file, who wrote it and how long ago. Shortcuts that don't say when to improve show up first.
Project rules
A project rule is something the team doesn't want to see in the code, such as "no direct fetch calls in screens". It becomes a file in .faundr-regras/, which goes into git with the rest of the project, and the check starts flagging every place it appears:
!faundr quality-rule "No fetch in screens" --pattern "\bfetch\(" --files "src/components/**" --message "Use the client in src/lib/api.ts"Memory rules with a forbidden pattern work the same way. See Memory.
Skipping a snippet
On the line above a snippet that breaks a rule on purpose:
// faundr-ignore <rule>: <reason>
For a whole file, use faundr-ignore-file <rule>.
Commands
Code quality shows whether the code is well written and lean: silently swallowed errors, weak types (any, @ts-ignore), overly complex functions, commented-out code, packages the language already covers, skipped tests, AI instructions (CLAUDE.md) that mention files or scripts that don't exist, unused code, duplicated snippets and the tsc and ESLint errors the project already has. The check runs on your computer, without AI, and only the findings go to the dashboard. Run these commands in your AI agent, from the folder linked to the project.
The check runs automatically when your AI agent starts and after every response where it changed files (only on the edited files). Unused code, duplicated snippets, the most-complex ranking and tsc/ESLint only run in the full check (at the start of the session). At the end of every response, Faundr also measures the size of the session's changes (lines of code and of tests). Deliberate shortcuts are marked in the code with // faundr: <limit>, <when to improve>. It never blocks the agent: findings come here and the agent gets a summary at the start of the session.
/faundr:quality [--full | --files <files>]AI quality review: the agent reads what changed (or the whole project, with --full) and records what the automatic check can't see, like what can be cut and what to replace it with, hidden errors, types that don't protect, confusing names and broken CLAUDE.md rules. Only findings with confidence of 80 or higher are recorded, each with proof in the code. It only reports and changes nothing.
e.g. /faundr:quality --full
/faundr:quality-fix [Q-<n> | --all]Fixes an issue without changing what the app does (without an argument: the open high-severity ones, one at a time; with --all, every open one without stopping). It asks for your approval before touching several files, deleting a file or removing a package (with --all, it leaves those for a list at the end), and only closes the issue once the check no longer finds it.
e.g. /faundr:quality-fix Q-3
/faundr:quality-scanRuns the full check now and summarizes what it found, by type.
!faundr quality-rule "<name>" --pattern "<regex>" --message "<why and what to use instead>" [--files "src/**"] [--severity alta|media|baixa]Creates a house rule: something the team doesn't want to see in the code (e.g. direct fetch calls in screens, a banned library). It becomes a file in .faundr-regras/ that goes into git, and the check starts pointing out where it appears.
e.g. !faundr quality-rule "No fetch in screens" --pattern "\bfetch\(" --files "src/components/**" --message "Use the client in src/lib/api.ts"
!faundr quality-ladder on|offTurns on or off the reminder that keeps the agent from writing too much code (6 lines at the start of every session). You can also turn it on here in the dashboard, on the status card.
e.g. !faundr quality-ladder on
!faundr quality-show [Q-<n>]Lists open issues, or shows one with what it is, why it matters and how to fix it.
e.g. !faundr quality-show Q-3
!faundr quality-resolve Q-<n>Reruns the check and only closes the issue if it is really gone. The agent runs this after fixing.
e.g. !faundr quality-resolve Q-3
!faundr quality-ignore Q-<n> --reason <reason> --note "<why>"Removes it from the list with a reason: false-alarm, on-purpose or later (comes back on its own in 30 days). You can also use the Ignore button here in the dashboard. In code, a faundr-ignore <rule>: reason comment applies to the next line.
e.g. !faundr quality-ignore Q-3 --reason on-purpose --note "deleting the temp file is optional"
!faundr quality-reopen Q-<n>Reopens an ignored issue.
e.g. !faundr quality-reopen Q-3