audit-code-quality
Skill9 starsChanged 42 days agoMITView on GitHub
Detect and fix repo-wide anti-patterns and consistency drift (naming, organisation, repeated smells). Use when "code smell", "anti-pattern", "technical debt", or "standardize the codebase". This PR/diff review → audit-code-review.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- kensaurus/skillsword for word, first seen Oct 1, 2026
Other versions1 project uses a version of this.
Word for word · 1
- kensaurus/skills★ 9100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository165 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .cursor/rules/approved-plan-execution.mdcCursor rule
- .cursor/rules/skill-workflows.mdcCursor rule
- .cursor/rules/verification-before-completion.mdcCursor rule
- llms.txtllms.txt
- audit-accessibilitySkill
- audit-agent-speedSkill
- audit-analyticsSkill
- audit-auth-flowsSkill
- audit-backend-architectureSkill
- audit-bundle-sizeSkill
- audit-cicdSkill
- audit-codemod-safetySkill
- audit-code-reviewSkill
- audit-db-schemaSkill
- audit-doctrineSkill
- audit-env-paritySkill
- audit-fe-apiSkill
- audit-gate-logicSkill
- audit-i18nSkill
- audit-infra-costSkill
- audit-langfuse-llmSkill
- audit-llm-securitySkill
- audit-monetization-iapSkill
- audit-payment-systemSkill
- audit-performanceSkill
- audit-realworldSkill
- audit-registry-listingSkill
- audit-resilienceSkill
- audit-responsiveSkill
- audit-securitySkill
- audit-skill-conflictsSkill
- audit-ui-statesSkill
- audit-uiux-design-systemSkill
- audit-ux-journeysSkill
- audit-uxSkill
- backend-db-performanceSkill
- backend-error-handlingSkill
- backend-observabilitySkill
- backend-patternsSkill
- backend-realtimeSkill
- burndown-fullSkill
- complete-everythingSkill
- data-pipelineSkill
- data-visualizationSkill
- debug-errorSkill
- debug-fe-be-integrationSkill
- debug-sentry-monitorSkill
- deploy-npmSkill
- deploy-verifySkill
- design-apiSkill
- design-canvasSkill
- design-emailSkill
- design-frontendSkill
- design-generative-artSkill
- design-mobile-firstSkill
- design-motionSkill
- design-prdSkill
- design-systemSkill
- design-themeSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 54
Verify the "inconsistency" isn't intentional.
- Distinctive: line 313
Run the repo's test script and confirm no new failures
- Very specific: line 314
Document any enforced standard in CONTRIBUTING.md or .cursor/rules/
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Code Quality Audit
Degree of freedom: MIXED — Parts 1–2 judgment [HIGH freedom]; convention
greps and Validation [LOW freedom — run exactly].
Audit-and-fix exception. Detect and then fix. Not present-then-stop.
Fix the findings you reported, in the files you named; a repo-wide restyle or rename pass the report did not list is a different session. Edit surgically — the offending hook, key, or import — rather than rewriting whole files. Pre-existing bugs met on the way go in the report as follow-ups. Add or change tests only where the task asks or the repo already keeps them for that surface; one-off greps and scratch scripts stay out of the commit.
Repo-wide React/TypeScript anti-patterns plus naming, organisation, and
pattern consistency. A named PR/diff → audit-code-review.
How to reason
- Observe — quote the smell (
file:line) and whethergit blame/ CONTRIBUTING marks it intentional - Interpret — bug/perf risk, or style-only drift?
- Classify — anti-pattern / naming / organisation / pattern-split / intentional
- Severity — runtime bug or data-fetch
useEffect= High; naming-only = Low
Worked example
Observe:
components/PaymentForm.tsxhas'use server'and auseEffectthat fetches invoices; four sortable lists usekey={i}. Interpret: server action lives in UI; fetch refires on remount; reorder remounts rows. Classify: organisation +useEffect-for-data + index-as-key. Severity: High (actions-in-components); Medium (keys). Finding:PaymentForm.tsx| High | move action tofeatures/*/server/; replace fetch effect with TanStack Query
Before any change [LOW freedom — run exactly]
cat CONTRIBUTING.md .cursor/rules/*.md 2>/dev/null | head -100 # existing conventions
git log --oneline -20 | grep -i "convention\|pattern\|style" # recent decisionsVerify the "inconsistency" isn't intentional. Check git blame before touching working code.
Part 1 — Anti-patterns [HIGH freedom]
React
Props drilling → Context or composition
// Bad: prop drilled through 5+ levels
<Layout user={user}><Sidebar user={user}><UserMenu user={user}><Avatar user={user} />
// Fix: context for global state
const UserContext = createContext<User | null>(null)
const useUser = () => useContext(UserContext)
// Fix: composition for UI concerns
<Layout><Layout.Sidebar><UserMenu /></Layout.Sidebar></Layout>Derived state in useState → useMemo
// Bad
const [items, setItems] = useState([])
const [filtered, setFiltered] = useState([])
useEffect(() => { setFiltered(items.filter(i => i.active)) }, [items])
// Fix
const filtered = useMemo(() => items.filter(i => i.active), [items])useEffect for data fetching → Server Components or TanStack Query
// Fix (Next.js 16 Server Component)
async function DataDisplay() {
const data = await db.getData()
return <div>{data.name}</div>
}
// Fix (client with TanStack Query)
const { data, isLoading } = useQuery({ queryKey: ['data'], queryFn: fetchData })Object/array in dependency array → memoize or destructure
// Bad: new object every render → infinite loop
useEffect(() => { doSomething(options) }, [options])
// Fix
const options = useMemo(() => ({ page, limit }), [page, limit])
useEffect(() => { doSomething(options) }, [options])Index as key in dynamic lists → stable IDs
// Bad
{items.map((item, i) => <Item key={i} />)}
// Fix
{items.map(item => <Item key={item.id} />)}Giant component → composition
// Split by responsibility
export function UserDashboard() {
const user = useUser()
return (
<DashboardLayout>
<UserHeader user={user} />
<UserStats userId={user.id} />
<RecentActivity userId={user.id} />
</DashboardLayout>
)
}TypeScript
// Bad: any
function processData(data: any) { return data.items.map((i: any) => i.name) }
// Fix: proper types + Zod validation
const DataSchema = z.object({ items: z.array(z.object({ id: z.string(), name: z.string() })) })
function processData(data: z.infer<typeof DataSchema>) { return data.items.map(i => i.name) }
// Bad: enums (runtime object, not tree-shakeable)
enum Status { Pending = 'pending', Active = 'active' }
// Fix: union types
type Status = 'pending' | 'active'
// Fix: exhaustive switch
function handle(s: Status): string {
switch (s) {
case 'pending': return 'Waiting'
case 'active': return 'Running'
default:
const _: never = s
throw new Error(`Unknown: ${_}`)
}
}State management
// Rule of thumb:
// URL state (nuqs) → shareable, bookmarkable
// Global state (Zustand) → cross-component, persisted
// Local state (useState) → component-specific, ephemeral
// Stale closure fix
useEffect(() => {
const id = setInterval(() => setCount(c => c + 1), 1000) // functional update
return () => clearInterval(id)
}, [])Architecture
// Circular deps → extract shared code / dependency inversion
// Business logic in components → move to lib/feature/calculations.ts
// God files → feature-based organisation:
lib/
date/format.ts
currency/format.ts
validation/schemas.tsPart 2 — Consistency audit [HIGH freedom; greps LOW]
Naming conventions
| Element | Expected | Check |
| Components | PascalCase | userCard vs UserCard |
| Hooks | use prefix | fetchData vs useFetchData |
| Utils | camelCase | format_date vs formatDate |
| Constants | SCREAMING_SNAKE | apiUrl vs API_URL |
| Files | kebab-case | UserCard.tsx vs user-card.tsx |
| Boolean props | is/has/should | loading vs isLoading |
rg "export (function|const|class) [a-z]" --type tsx # lowercase component exports
rg "use[A-Z]" --type ts # hook patterns
rg "export default" --type tsx -l | head -20 # mixed default/named exportsFile organisation (feature-sliced)
src/
features/{name}/
components/ # UI only
hooks/ # custom hooks
server/ # server actions
types.ts
schemas.ts
components/ui/ # shared primitives
lib/ # global utilitiesRed flags:
- Components in
/libor/utils - Server actions in component files
- Types scattered across component files
- Zod schemas inline in components
rg "z\.object" --glob "*/components/*" # inline schemas
rg "'use server'" --glob "*/components/*" # actions in wrong place
rg "from '\.\." --type tsx | head -20 # relative imports instead of @/Pattern consistency
| Concern | Check |
| Server state | All TanStack Query, or mixed with useEffect? |
| Forms | All React Hook Form, or controlled inputs too? |
| Error handling | Consistent ActionResult shape? |
| Styling | cn() used everywhere? Dark mode via CSS vars? |
| Tests | *.test.ts vs __tests__/? Consistent mocking? |
Coherency report template
# Code Quality Audit
## Summary
- Verdict: [one line — what blocks, what is drift]
- Critical findings: X
## Anti-patterns found
| Pattern | Files | Severity |
|---------|-------|----------|
| useEffect for data | 3 files | High |
| Index as key | 2 files | Medium |
## Naming convention findings
| Element | Expected | Actual | Files |
|---------|----------|--------|-------|
| Components | PascalCase | Mixed | 4 |
## Organisation findings
- Server actions found in: components/PaymentForm.tsx
- Types scattered in: 6 component files
## Priority fixes
1. Move server actions to features/*/server/
2. Replace useEffect data fetching with TanStack Query
3. Standardise component naming to PascalCase
## Conventions to document
1. Decision on default vs named exports
2. Where Zod schemas liveAnti-pattern detection checklist
React checks
- No
useEffectfor derived state - No index keys in dynamic lists
- No objects/arrays in dependency arrays
- Components under 300 lines
- No prop drilling beyond 2 levels
TypeScript checks
- No
any(useunknown+ validation) - No unsafe type assertions
- Exhaustive switch statements
- Zod schemas for all external data
Architecture checks
- No circular dependencies
- Business logic separated from UI
- Files under 400 lines
- Clear module boundaries
Self-critique before applying fixes [LOW freedom — do not skip]
- Evidenced —
file:lineor rg hit, not "the codebase feels messy" - Reproducible — the convention grep still finds it
- Severity justified — High = bug/perf, not naming taste
- Right owner — this PR/diff →
audit-code-review - No-false-safety —
git blamechecked; working intentional code left alone
Validation [LOW freedom — run exactly]
- Typecheck with the repo's own script (
package.json→typecheck, elsetsc --noEmit) - Lint with the repo's own script — not a generic
eslint src/ - Run the repo's test script and confirm no new failures
- Document any enforced standard in
CONTRIBUTING.mdor.cursor/rules/
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

