▲ 3 r/nextjs
I built a minimal Next.js + Hono + Prisma monorepo template — the README's most important section is what it doesn't include
Every monorepo starter I tried was either a single Next.js app pretending to be full-stack, or a kitchen sink with auth, tRPC, Stripe, and 40 dependencies I'd spend a weekend ripping out.
So I made the template I wanted: the smallest honest version of a real architecture.
What's in it:
- Next.js frontend + a standalone Node-hosted Hono REST API (real HTTP between them, not a route handler cosplaying as a backend)
- Prisma + PostgreSQL with versioned migrations and an isolated test database
- Zod contracts in a shared package — the web app never touches Prisma types
- pnpm workspaces + Turborepo, with API tests that hit real HTTP
- One tiny task CRUD example that proves the browser → API → database path, then gets deleted
What's deliberately NOT in it: auth, deployment config, seed data, tRPC, GraphQL, component libraries, background jobs. The README lists everything excluded and why. You add only what your product needs.
MIT licensed. Repo: https://github.com/aka-luan/next-hono-prisma-monorepo-template
Happy to hear what you'd cut or add — the whole point is keeping it minimal, so "you should add X" needs to fight for its life.
u/eliaff — 14 days ago
Made a skill that audits your CLAUDE.md/AGENTS.md ecosystem for stale facts and archives the history. First run cut my required reading 75%
This came out of a real cleanup this week, figured others probably have the same problem brewing.
The setup: docs that agents must read every session (CLAUDE.md, AGENTS.md, whatever they point to) accumulate finished work. Mine hit 1,085 lines and most of it was history. But the bigger issue was stale claims. Things like a component that got renamed weeks ago still being referenced in gotchas, "awaiting merge" on merged work, wrong file:line refs, and a design spec still crowned "source of truth" after the code had legitimately moved past it. That last one is nasty because an agent doing UI work will "fix" correct code back toward the stale spec.
How the skill works:
Inventory every md file, weighted by how often agents read it. A 150-line file on the required list costs more than a 400-line file nobody reads.
Diagnose, read-only. Six rot patterns, and every finding gets verified against code first. Doc says X, grep says otherwise, that's a finding. Doc says "awaiting merge", git merge-base --is-ancestor says it shipped, finding.
Report and stop. It doesn't rewrite anything until you approve.
Execute: archive old content verbatim to docs/archive (diff-verified against HEAD so nothing gets mangled), rewrite live docs with facts re-checked at write time, collapse done checklists, keep recurring gotchas.
Docs-only commit.
One detail I'd flag: the execute phase is written so you can hand the bulk rewriting to a cheaper model with a spec of pre-verified facts. Do review that diff though. In my run the subagent turned "Premium unlocks manual moderation" into a table cell that said moderation: manual, which is a different product. Small diff, wrong meaning.
Numbers from the first run: roadmap 445 to 33 lines, design spec 443 to 181, pricing 197 to 52.
Install:
npx skills add aka-luan/doc-cleanup
MIT, one file, no deps. If you've hit rot patterns beyond the six it covers I'd genuinely like to hear them.
u/eliaff — 15 days ago
▲ 160 r/ClaudeAI
Asked Claude what in my docs was hurting its reasoning. The answer changed how I think about CLAUDE.md files
Context: ~3 weeks building a product almost entirely with agents. I was disciplined about docs the whole time. Milestones checked off as they shipped, design decisions logged, gotchas recorded. If anything I over-documented.
Then on a whim I asked Claude to "evaluate what might be hurting agents' thinking" in the repo docs. Some of what it found:
- The three docs on my read-before-you-code list totaled 1,085 lines, and roughly 75% was finished work. Fully-checked checklists, phase completion logs, old verification notes. Pure history that every session was paying to read.
- My pricing doc stated the enabled payment methods two different ways in the same file. One of them had a line number reference that didn't exist anymore.
- A table had been "corrected" by a footnote three paragraphs below it, but the table itself was never edited. Guess which one an agent reads.
- Two features were marked "awaiting merge/deploy" that had been on main for days.
- A hard rule in AGENTS.md pointed at a sibling repo via a Windows path (A:\Dev\...). I moved to WSL a while back. The rule was impossible to follow and no agent ever flagged it, they just silently failed at it.
What actually bothered me is that agents trust these files more than they trust their own searches. That's by design, it's what the files are for. But it means the doc doesn't have to be wrong in an obvious way to do damage. It just has to be slightly behind the code.
I turned the cleanup process into a skill so it's repeatable. It inventories the md files, checks every claim against the actual code before flagging it (git merge-base for the "awaiting merge" claims, grep for the file references), reports what it found, and only rewrites after approval. Nothing gets deleted, history moves to docs/archive.
End result was 1,085 lines of required reading down to 266.
Repo if anyone wants it (MIT, single SKILL.md): https://github.com/aka-luan/doc-cleanup
Curious how others handle this. Do you ever prune your CLAUDE.md or does it just grow?
u/eliaff — 15 days ago