DEV Community: Franck LEBAS

LLM Code Reviews on pre-commit : A Solo Dev’s New Best Friend?

Franck LEBAS — Wed, 15 Apr 2026 10:38:48 +0000

Hi, Franck here 🎤

As a solo developer, I write a lot of code alone. The problem ? I’m terrible at reviewing my own work. I always think “it looks good enough”… until I spot a dumb bug two days later.
I got tired of shipping code with blind spots. So I built a small open-source tool:

francklebas / llm-review-framework

llm-review-framework

LLM-powered code review as a pre-commit hook. Works with any LLM provider, any project.

Install

curl -fsSL https://raw.githubusercontent.com/francklebas/llm-review-framework/main/install.sh | bash

Setup a project

cd your-project
llmfwk init

The interactive setup will:

Ask which LLM provider to use (Gemini, Ollama, Claude, OpenAI, Mistral, Groq, GitHub Copilot, or custom)
Check if the provider CLI is installed (and offer to install it)
Let you pick a model
Check if pre-commit is installed (and offer to install it)
Optionally create project-specific prompts from templates
Write .llm-review.yaml and .pre-commit-config.yaml

How it works

On every commit, the llm-codereview hook:

Reads your .llm-review.yaml config
Gets the staged diff
Loads review prompts (project-specific or base defaults)
Sends everything to your LLM provider
Outputs a markdown code review

The output is readable by you and exploitable by the LLM in your editor (Claude Code, opencode, Cursor, etc.).

Prompts

Base prompts (built-in)

If you skip project-specific prompts during llmfwk…

View on GitHub

It turns any LLM into a pre-commit code reviewer that runs automatically on every git commit.

Why I Needed This ?

In a team, you open a PR and get feedback.
As a solo dev, you’re on your own. Self-review checklists quickly become wishful thinking.
I wanted something simple that:

Gives honest, consistent feedback
Runs locally or with any provider
Doesn’t slow me down
Doesn’t assume my code is perfect (spoiler: it never is)

How It Works (Really Simple)

Install it once:

curl -fsSL https://raw.githubusercontent.com/francklebas/llm-review-framework/main/install.sh | bash

In any project, run:

llmfwk init

A quick interactive wizard asks:
Which LLM do you want ? (Ollama, Gemini, Claude, Groq, OpenAI, Mistral, Copilot, or custom)
Which model ?
It sets up the pre-commit hook for you ! 🎉

And... that’s it.
From now on, every commit triggers a review. The tool grabs your staged changes, sends them to your LLM with solid prompts (SOLID, security, anti-patterns, error handling, etc.), and shows you a clean Markdown review in the terminal.

Voir un exemple de review générée

### Review of `auth.py`
- **Security**: The hardcoded API key on line 42 should be moved to an environment variable.
- **Style**: Function `login_user` is too long, consider refactoring.

If something looks off — you fix it and commit again.

Make It Understand Your Project

You can add two files to give it context (the context project is in the parent directory) :

codereview-context.md → your stack, architecture choices, naming rules
codereview-guidelines.md → what you care about most in this project

The LLM then reviews your code like someone who actually knows your codebase.

Why I Like It

Works completely locally with Ollama → zero cost, zero data leak...
Super fast with Groq when I’m in a hurry
Fully customizable
AGPL-3.0 and 100% FOSS

It’s not magic, and it won’t replace human review when you have teammates. But for solo work, it’s a game-changer: I now commit with much more confidence.

Try It

Go to the repo:

Tester llm-review-framework sur GitHub 🚀

Run the install, do llmfwk init in one of your projects, and make a small change + commit. You’ll see the difference immediately.

I’d love to hear what you think, especially if you’re also a solo dev fighting the same problem.
What’s your current trick to avoid shipping "mediocre" code alone ?

Happy coding (and reviewed commits)! 🚀😁

AURORA Commerce Pro: adding Sanity support without touching the storefront

Franck LEBAS — Wed, 01 Apr 2026 15:37:25 +0000

When I published my first article about AURORA Commerce, a former colleague left a comment that stuck with me:

"The idea is great, but your repo-as-database approach assumes a technical operator. What about non-technical clients who need a visual CMS interface?"

He was right. And it was exactly the limitation I hadn't addressed publicly.

So I fixed it. Here's how.

The constraint

The original AURORA Commerce storefront reads products from YAML files via Nuxt Content:

const { data: products } = await useAsyncData('products', () =>
  queryCollection('products')
    .where('active', '=', true)
    .all()
)

This works beautifully for a technical operator. For a client who needs to update a product description on a Tuesday afternoon without touching a terminal - it doesn't.

The naive fix would be to hardcode Sanity queries throughout the storefront pages. But that means the storefront becomes coupled to a specific CMS. Swap providers and you're touching every page.

I wanted something cleaner.

The adapter pattern

The idea is simple: introduce a single resolver between the API routes and the data source. Storefront pages don't query products directly - they call API routes. API routes call the adapter. The adapter knows where data comes from. Nothing else does.

Storefront pages
      ↓
API routes (/api/products, /api/products/[slug])
      ↓
getCatalogAdapter(event)
      ↓
NuxtContentAdapter | SanityAdapter | YourCustomAdapter
      ↓
CatalogProduct (normalized)
      ↓
mapProductForApi(product, locale)
      ↓
ProductApiItem (locale-aware response)

The core files:

server/utils/catalog/
  types.ts         # CatalogProduct, ProductApiItem, CatalogAdapter
  map.ts           # mapProductForApi + resolveLocale
  adapters/
    index.ts       # Resolver — reads CATALOG_PROVIDER env var
    content.ts     # Nuxt Content (YAML) implementation
    sanity.ts      # Sanity implementation

The contract

Two interfaces define the whole system.

CatalogAdapter is the contract every provider must implement:

// server/utils/catalog/types.ts
export interface CatalogAdapter {
  listProducts: (event: any) => Promise<CatalogProduct[]>
  getProductBySlug: (event: any, slug: string) => Promise<CatalogProduct | null>
}

CatalogProduct is the normalized internal shape - same fields, same types, regardless of the source. The storefront never sees raw Sanity or YAML data.

ProductApiItem is what the API routes actually return - locale-aware, with priceCents already computed:

export interface ProductApiItem {
  id: number
  name: string        // resolved from title / titleFr
  slug: string
  description: string // resolved from description / descriptionFr
  priceCents: number  // Math.round(price * 100) — euros in YAML, cents to the client
  imageUrl: string
  imageUrls: string[]
  sizes: string[]
  // ... rest of the fields
}

That priceCents conversion happens in map.ts, not in the checkout route. One place, no surprises.

The resolver

Switching providers is an environment variable:

# Use Nuxt Content YAML (default)
CATALOG_PROVIDER=content

# Use Sanity
CATALOG_PROVIDER=sanity
SANITY_PROJECT_ID=your_project_id
SANITY_DATASET=production
SANITY_API_VERSION=2025-01-01
SANITY_TOKEN=optional_read_token

The resolver in adapters/index.ts reads CATALOG_PROVIDER and returns the right adapter. API routes call it once:

// server/api/products.get.ts
export default defineEventHandler(async (event) => {
  const adapter = getCatalogAdapter(event)
  const locale = resolveLocale(event) // reads ?locale= query param
  const products = await adapter.listProducts(event)
  return products.map((p) => mapProductForApi(p, locale))
})

resolveLocale reads the locale query param and returns 'fr' | 'en'. The locale resolution stays server-side - mapProductForApi picks the right field (titleFr vs title, descriptionFr vs description, etc.) before sending the response.

No if/else scattered across the codebase. No Sanity imports in storefront pages. The checkout route is unchanged.

The Sanity adapter

The Sanity adapter is a set of pure functions - no class, no instance state:

// server/utils/catalog/adapters/sanity.ts
export const sanityAdapter: CatalogAdapter = {
  async listProducts() {
    const client = createSanityClient()
    const raw = await client.fetch(`*[_type == "product"]`)
    return raw.map(normalizeSanityProduct)
  },

  async getProductBySlug(_, slug) {
    const client = createSanityClient()
    const raw = await client.fetch(
      `*[_type == "product" && (slug.current == $slug || slug == $slug)][0]`,
      { slug }
    )
    return raw ? normalizeSanityProduct(raw) : null
  }
}

The slug query handles both Sanity's native slug.current shape and plain string slugs - useful when migrating data from YAML.

Normalizing images

Sanity images can come in three different shapes depending on how the schema is set up:

const normalizeImages = (value: unknown): string[] => {
  if (!Array.isArray(value)) return []

  return value
    .map((image) => {
      // Plain URL string
      if (typeof image === 'string') return image

      // Sanity asset reference with resolved URL
      if (image?.asset?.url) return String(image.asset.url)

      // Direct URL field
      if (image?.url) return String(image.url)

      return ''
    })
    .filter(Boolean)
}

If your Sanity schema uses asset references without URL projection, add url to your GROQ query. The adapter handles the rest.

Full product normalization

const normalizeSanityProduct = (entry: any): CatalogProduct => ({
  productId: Number(entry.productId || 0),
  title: String(entry.title || ''),
  titleFr: optionalString(entry.titleFr),
  slug: normalizeSlug(entry.slug),
  price: Number(entry.price || 0),
  category: String(entry.category || 'tailoring') as CatalogProduct['category'],
  images: normalizeImages(entry.images),
  sizes: toStringArray(entry.sizes),
  sizeChart: Array.isArray(entry.sizeChart) ? entry.sizeChart : [],
  reviews: Array.isArray(entry.reviews) ? entry.reviews : [],
  // bilingual fields follow the same optionalString pattern
})

If Sanity changes its schema, only this function needs updating. The storefront, the cart, and the Stripe checkout don't know.

One more thing: image resilience

Sanity image URLs can occasionally fail - CDN misses, unpublished assets. The product page now handles this gracefully:

// app/pages/produit/[slug].vue
const failedPrimaryImages = ref<string[]>([])

const primaryImageSrc = computed(() => {
  if (selectedImage.value) return selectedImage.value
  return product.value?.imageUrls.find(
    (img) => !failedPrimaryImages.value.includes(img)
  ) || product.value?.imageUrl || ''
})

const handlePrimaryImageError = () => {
  const current = primaryImageSrc.value
  if (current) failedPrimaryImages.value.push(current)
  const next = product.value?.imageUrls.find(
    (img) => !failedPrimaryImages.value.includes(img)
  )
  selectedImage.value = next || ''
}

Failed images are tracked in a ref. The computed picks the next available one automatically. No broken image placeholder, no flash - just a silent fallback.

Adding your own adapter

The architecture is open by design. Adding Contentful, Hygraph, or a custom REST API is four steps:

Create server/utils/catalog/adapters/your-cms.ts
Export a CatalogAdapter object with listProducts and getProductBySlug
Normalize your CMS payload into CatalogProduct
Register your provider in adapters/index.ts
Set CATALOG_PROVIDER=your-cms

The storefront pages, the cart, and the Stripe checkout don't change. That's the point.

What this unlocks

The original Starter was honest about its constraint: YAML works for a technical operator, not for a client who needs a visual interface.

The Pro tier addresses that directly. Same storefront, same Stripe integration, same bilingual setup - but the catalog source becomes a configuration choice, not an architectural constraint.

→ Live demo
→ AURORA Commerce on Gumroad - Starter €29 / Pro €59

Thanks to Robin for the feedback that drove this iteration.

Built with Nuxt 4, Vue 3, Nuxt Content v3, Sanity, Pinia, Tailwind CSS, Stripe, and Bun.

No database, no problem: e-commerce with Nuxt Content and Stripe

Franck LEBAS — Tue, 31 Mar 2026 14:47:19 +0000

I've been building frontends for a while now, and one thing that still surprises me is how much infrastructure we accept as a given for small e-commerce projects. A database. An admin panel. A CMS subscription. A backend to glue it all together.

For a curated catalog of 10 to 50 products, that's a lot of moving parts.

I wanted to see how far I could go in the other direction. The result is AURORA Commerce — a Nuxt 4 storefront where products live in YAML files, payments go through Stripe, and the infrastructure cost is zero.

Here's how I built it and why it might be the right approach for your next project.

The idea: your repo is your database

Instead of querying a database or calling a CMS API, product data lives directly in the repository:

content/
  products/
    heavyweight-crewneck-charcoal.yml
    linen-midi-dress-terracotta.yml
    oxford-button-down-shirt-white.yml

Each file is a complete product record:

productId: 6
title: "Heavyweight Crewneck - Charcoal"
titleFr: Sweat Crewneck Heavyweight - Charbon
slug: heavyweight-crewneck-charcoal
price: 109
category: sweats
badge: Core line
highlight: Brushed cotton 420 g/m2
description: "Oversize sweatshirt in ultra-soft brushed cotton. 420 g/m2 weight,"
  reinforced collar, and premium finishes. The staple you never take off.
descriptionFr: Sweat oversize en coton brosse ultra-doux 420 g/m2. Col renforce,
  finitions soignees. Le basique premium que tu portes tous les jours.
images:
  - https://your-cdn.com/product-1.jpg
  - https://your-cdn.com/product-2.jpg
  - https://your-cdn.com/product-3.jpg
sizes: [S, M, L, XL]
fabricWeightGsm: 420
origin: Knit in France, made in Portugal
sizeChart:
  - { size: S, chestCm: 90, waistCm: 74, lengthCm: 67 }
  - { size: M, chestCm: 95, waistCm: 79, lengthCm: 68 }
  - { size: L, chestCm: 100, waistCm: 84, lengthCm: 69 }
  - { size: XL, chestCm: 106, waistCm: 90, lengthCm: 70 }
reviews:
  - { author: Theo G., city: Nantes, rating: 5, date: '2026-03-07',
      quote: The weight is perfect and the finish feels way above standard sweatshirts. }

Add a product by duplicating a file. Update a price by changing a number. Deploy on push. No dashboard, no migration, no API key to rotate.

It sounds almost too simple. It kind of is — and that's the point.

Querying with Nuxt Content v3

Nuxt Content v3 handles the YAML parsing and exposes a typed query API. Fetching the full catalog:

// pages/boutique.vue
const { data: products } = await useAsyncData('products', () =>
  queryCollection('products')
    .where('active', '=', true)
    .order('productId', 'ASC')
    .all()
)

A single product by slug:

// pages/produit/[slug].vue
const { data: product } = await useAsyncData(`product-${slug}`, () =>
  queryCollection('products')
    .where('slug', '=', slug)
    .first()
)

Nuxt Content generates a typed collection from your YAML schema automatically. You get autocomplete on product.sizeChart, product.titleFr, product.fabricWeightGsm — the whole thing. TypeScript is happy. You are happy.

The Stripe integration

The checkout flow is straightforward:

User builds a cart (Pinia)
Frontend calls a server route with the cart items
Server creates a Stripe Checkout session and returns the URL
Frontend redirects

The server route is the only backend code in the project:

// server/api/checkout-session.post.ts
import Stripe from 'stripe'

export default defineEventHandler(async (event) => {
  const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!)
  const body = await readBody(event)

  const session = await stripe.checkout.sessions.create({
    mode: 'payment',
    line_items: body.items.map((item: CartItem) => ({
      quantity: item.quantity,
      price_data: {
        currency: 'eur',
        unit_amount: item.price * 100, // YAML stores euros, Stripe wants cents
        product_data: {
          name: item.title,
          images: [item.thumbnail],
        },
      },
    })),
    success_url: `${process.env.NUXT_PUBLIC_APP_URL}/success`,
    cancel_url: `${process.env.NUXT_PUBLIC_APP_URL}/panier`,
    shipping_address_collection: {
      allowed_countries: ['FR', 'BE', 'CH', 'DE', 'GB', 'SE'],
    },
  })

  return { url: session.url }
})

One detail worth noting: I use price_data instead of a Stripe price ID. This means products don't need to exist in the Stripe dashboard at all — the source of truth stays in the YAML files. One less thing to keep in sync.

Bilingual without a translation library

The storefront supports English and French natively. No i18n library, no translation files. The strategy is simple: bilingual fields directly in the YAML (title / titleFr, description / descriptionFr), combined with Nuxt's built-in routing strategy (prefix_except_default):

/boutique     → English
/fr/boutique  → French

A small composable resolves the right field based on the active locale:

// composables/useLocaleField.ts
export function useLocaleField() {
  const { locale } = useI18n()

  function t(en: string, fr?: string): string {
    return locale.value === 'fr' && fr ? fr : en
  }

  return { t }
}

Usage in templates:

<h1>{{ t(product.title, product.titleFr) }}</h1>
<p>{{ t(product.description, product.descriptionFr) }}</p>

The copy lives with the product. No keys to manage, no files to synchronize.

Design tokens in one place

The entire visual identity is controlled from tailwind.config.ts:

theme: {
  extend: {
    colors: {
      brand: {
        primary: '#0A0A0A',
        accent: '#C9A96E',
        surface: '#F8F6F2',
      },
    },
    fontFamily: {
      display: ['Cormorant Garamond', 'serif'],
      body: ['DM Sans', 'sans-serif'],
    },
  },
}

Change brand.accent once and every button, badge, and highlight updates across the storefront. No component hunting.

When this makes sense — and when it doesn't

This approach works well when:

Your catalog is small and curated (under ~200 products)
You want zero ongoing infrastructure cost
You're comfortable with a git-based workflow for content updates
You want full ownership — no platform lock-in

It's not the right fit if you need real-time inventory management, a non-technical client who needs a visual CMS, or complex product variants across multiple axes.

For the CMS case specifically: the architecture supports swapping queryCollection for a Sanity or Contentful client behind a shared adapter interface. The rest of the storefront doesn't need to change.

The result

A full storefront — home, shop, product detail, cart, Stripe checkout, success and cancel pages, bilingual, dark mode, SEO-ready — deployable on Vercel in under an hour.

→ Live demo
→ AURORA Commerce on Gumroad — Starter €29 / Pro €59

If you have questions or want to discuss the architecture, drop a comment. Happy to talk about it.

Built with Nuxt 4, Vue 3, Nuxt Content v3, Pinia, Tailwind CSS, Stripe, and Bun.