The Weekly Review Skill: A Full Health Check of Your Whole App

Every change to a client app gets checked before it ships. But some problems only show when you look at the whole app at once. So once a week we run a full review of everything. We call it full-review-weekly. It is part of the review system we describe in How We Review AI-Written Code. This post explains it in depth: first in plain English for founders, then in full detail for developers.

The Plain-English Version (for Founders)

Think of your app like a house. Checking each new room as it’s built is good. But once in a while you still need a full inspection, top to bottom, including the rooms nobody touched this year.

The weekly review is that inspection. It does five jobs:

1. It reads every file. Not just what changed this week. Bugs hide in the space between changes: two parts that were each fine can be wrong together.

2. It throws out false alarms. Review tools flag things that look wrong but are fine. A second check opens the code behind every serious problem and confirms it’s real. You only see what matters.

3. It runs expert checks. Security, data safety, speed, database design, and structure, each looked at on its own.

4. It remembers last week. Every problem from last week gets checked again: fixed or still open. Anything still open two weeks in a row becomes top priority. Nothing gets quietly forgotten.

5. It spots patterns. If the same kind of mistake shows up all over the app, the fix isn’t one line of code. The report suggests a new rule so the mistake stops coming back.

What you get: one summary, problems ranked from most to least serious, the top five fixes to make next, and what got fixed since last week.

What it found on one of our apps: in one run on October 18, 2026, it read 504 files, confirmed 4 critical and 85 important problems, and threw out 72 false alarms. One was a payment change that could get lost. Another was a checkout a first-time customer couldn’t finish. The next day, 17 fixes shipped, 13 with a new test.

The Technical Version (for Developers)

Why a separate weekly run

Diff review, like pr-review, only sees what changed. It can’t catch drift in code nobody touched, problems that span files, or the same mistake repeated across the codebase. The weekly run reads whole files and keeps history between runs.

It works on any TypeScript or JavaScript web app, with a root layout (app/, lib/) or a src/ layout.

Phase 0: Tool checks

Source: standard tools, used as is. The order and how failures become findings are custom.

Each runs, and the run keeps going on failure:

• npm run lint
• npm run typecheck, or npx tsc --noEmit if there’s no script
• npm run test
• npm run db:migrations:check
• npm audit --omit=dev

A failing tool is logged as a finding. A missing script is logged too, as a test gap. It never runs database wipes or resets.

Phase 1: Slices

Source: custom.

A script splits the codebase into slices by folder and lists any file it didn’t cover, so nothing is skipped silently. Each slice gets two subagents, one after the other:

• Code pass. Bugs, wrong logic, edge cases, unsafe input, missing auth checks, leaked secrets, unbounded loops and queries, silent catches, weak types.
• Architecture pass. Every file against all 13 rules. Each finding names the rule, like R12: UPDATE has no user_id predicate.

Phase 2: Verify

Source: custom.

One more subagent opens the code behind every critical and important finding and marks it CONFIRMED or FALSE, with a one-line reason. Only confirmed findings count in the summary and the tally. Specialist findings go through the same step.

Phase 3: Specialists

Source: custom, except the security checklist, adapted from everything-claude-code (MIT).

Up to three run at once, each scoped to the whole codebase:

Specialist	Looks for
Security	Auth, API routes, middleware, secrets
Ownership and locking	Every UPDATE/DELETE/upsert checked for a user_id predicate, and FOR UPDATE on read-then-write
Scale	Slow queries, missing indexes, N+1, unbounded SELECT, missing LIMIT
Schema	Missing constraints and business-rule gaps in schema.dbml
Module borders	Cross-module imports, vendor code outside adapters
Architecture fit	Current shape, god files, recommended structure per business area
Boundaries	API contracts, JSON parsing, null handling, row mappers, error contracts
Types, tests, dead code	Unsafe types, test gaps, unused exports and stale shims

Architecture fit is the advice step. It catches the growth-stage architecture mistakes before they get expensive. It names the shape the app has today, flags god files, and recommends the simplest structure that fits each area. The full ladder, from plain CRUD to microservices, is in How We Review AI-Written Code.

Phase 4: Follow-up

Source: custom.

Last week’s confirmed findings are checked against the code as it is now: FIXED or OPEN. Anything open two runs in a row moves up to critical.

Phase 5: Summary

Source: custom.

SUMMARY.md gives the counts, the confirmed critical and important findings by category, one short block per specialist, and the top five next actions.

Phase 6: Pattern tally

Source: custom.

A cumulative file counts findings by category across runs, measured in slices affected:

• 2 to 3 slices: suggest an edit to a coding standard or architecture rule, with exact wording.
• 4 or more: suggest a new checker, or tighten the one that should have caught it.
• Already covered by a rule, still 4 or more: the rule isn’t working; suggest a lint rule or test that enforces it.

It only suggests. You decide what to change.

Every finding is one line

severity | category | file:line | issue | fix

Categories come from a fixed list, so trends can be counted week over week: correctness, security, ownership, locking, validation, error handling, type safety, nullability, boundary leak, module borders, query safety, scale, migration safety, dead code, test gap, simplification.

It survives a crash

Source: custom.

A full run is long. Every phase writes its own file to disk before it reports back, and a PROGRESS.md checklist tracks what’s done. If the run dies from a crash or a token limit, the next start picks up at the first unfinished step.

What’s custom, what’s built in, and why

Claude Code has no built-in whole-codebase review. Its /code-review is diff-only and has no memory between runs. So most of this skill is custom. Where a solid standard tool already does the job, we use it as is.

Part	Source	Why
Lint, type check, tests, npm audit	Standard tools, used as is	The same job in every codebase. Rebuilding them adds nothing.
Security checklist	Adapted from everything-claude-code (MIT)	A solid open checklist already existed. We adapted it to fit this process.
Slicing and the two full-file passes	Custom	A general reviewer can’t read 500 files in one go, and doesn’t know your 13 rules.
Verify pass	Custom	Without it, false alarms bury the real findings and the report stops being trusted.
Ownership, scale, schema, module, architecture-fit, boundary, type, test, and dead-code specialists	Custom	Each targets a failure we kept finding in AI-written code.
Follow-up, pattern tally, resume	Custom	No standard tool remembers past runs or proposes new rules.

Our rule of thumb: use the default when the job is the same for every codebase. Go custom when the check depends on your rules or on a failure that keeps coming back.

Where a senior developer steps in

The weekly run finds candidates. A senior developer on our team decides what they mean. For security-sensitive code (auth, payments, permissions, personal data, anything that deletes or moves data), how much gets read by hand depends on how sensitive the code is and what stage the app is at.

Stage	What gets read by hand
MVP	The weekly run is optional. When it runs, critical findings get fixed. No line-by-line reads.
Pre-launch	A full weekly run, then a senior developer reads all security-sensitive code line by line before real users arrive.
In production, making money	The run happens every week. A senior developer reads every critical and important finding in security-sensitive code, checks the fix by hand, and reads changes there before merge.

---

Get the Kit Free

full-review-weekly is part of our free Claude Code plugin, along with pr-review, the 13 rules, and every check they call. In Claude Code, run:

/plugin marketplace add kbventures/ingenix-code-review
/plugin install code-review-kit@ingenix

Then run /code-review-kit:full-review-weekly for a whole-app check. Read the skill itself on GitHub.

---

Want This Run on Your App?

If your app was built fast with AI and you’re not sure what’s hiding in it, we’ll run the full weekly review and walk you through the report: what’s broken, what’s risky, and the first three fixes that matter most.

Book a Free Discovery Call