ROIMVP in prod in 30–45 days — without hiring a senior

≈ €75–105k saved over 10 monthsfrom €4,500/ month (≈ 1/3 of a fully loaded senior's cost)

Agents + iASSET gates · dev & cloud included · pipeline live in 1 week

Calculate my ROI
iASSET framework
Operational guideBusiness example: seasonal rentals

Guide — iASSET & Gemini CLI: from specification to merge request.

Throughline: a seasonal rentals web app (catalog, availability, bookings, guest data). This guide shows how to apply the iASSET framework with Gemini CLI: the specification frames generation and review, and serves as a reference to validate MRs.

Method: skills defined upstream; in dev, a skill to process the spec; at commit, another skill; on push, in CI, a spec + security skill (on the diff — no hidden CI logic); at the end of CI, a skill for a clean MR; then the human takes over.

The CLI exposes: skills, hooks, policy, -p/--prompt, extensions, MCP — no dedicated analyze command.

Next.js (App Router)TypeScriptGemini CLIGitLab CIScaleway (cloud example)

Diagram — iASSET + Gemini CLI method (skills by phase)

Colors: upstream (blue), development (green), Git (purple), CI (pink), human (yellow). The CI 'spec + security' gate analyzes the diff — not the Next.js app runtime.

Step details (aligned with the diagram)

Each phase invokes a different skill (defined upstream). Artifacts (AC, DoD, tests, commit messages) are versioned; in CI, skills operate on the diff and files, not the Next.js runtime.

1

Upstream — iASSET skills

Define and version the skills library (spec, commit, CI spec/sec, CI MR, etc.).

2

Development — spec skill

Invoke the skill that processes the spec: AC, DoD, test descriptions (seasonal rentals).

3

Implementation

Code and tests (Next.js: `app/`, `lib/`, Route Handlers); feature branch.

4

Commit — dedicated skill

Another skill for message format, scope, ticket link (hook or local command).

5

Push

Triggers the CI pipeline on branch / MR.

6

CI — spec + sec skill

Verify diff + files against spec and security — without runtime decorators.

7

CI — lint → spec+sec → tests → MR skill

Order aligned with the diagram; then a human validates the MR.

Recommended CI order

Lint + typecheckskill spec + sécu (sur le diff) → testsskill MRrevue humaine. Tout passe par prompts, skills et policy — pas besoin de conventions framework spécifiques dans la CI.

Real Gemini CLI levers for each iASSET pillar

Vous composez votre workflow avec les briques fournies par la CLI : pas besoin d’une commande analyze — la revue est un prompt structuré (souvent via des skills), des règles policy, et éventuellement des hooks pour l’enchaînement local ou CI.

PillarCLI lever (example)Note
[A]Skills + policy (--policy)Workspace/tool rules; prompts separate `app/`, `lib/`, Route Handlers.
[S] specSkills (`gemini skills`)Versioned playbooks for AC/DoD/tests before the first commit.
[S] secPolicy + promptsConstrain the agent; MCP for doc/linter context if needed.
[E]Headless `gemini -p` + hooksCI or Git hook: same CLI as local, JSON output to fail the job.
[T]Prompt or 'tests' skillComplement to automated tests, not a replacement.

The five iASSET pillars (and Gemini's role)

[A] Architecture

You define where code can be generated (components, Route Handlers, data adapters) and where it remains forbidden (pure business rules in `lib/`). Dedicated skill + policy (paths, tools): no 'analyze' subcommand — review lives in prompts and skills.

[S] Specification

Upstream skills (e.g. asset-spec): AC, DoD, test descriptions. In MR, a headless prompt with spec and diff checks alignment; artifacts remain the source of truth.

[S] Security

In CI, the 'spec + sec' skill operates on the diff and files — not runtime decorators. Policy + prompts bound the agent.

[E] Evaluation

After lint/typecheck: headless `gemini -p` with MR review skill + context (spec, diff). Hooks (pre-push, CI) chain steps. Human review remains mandatory for business.

[T] Testing

Optional 'test plan/gaps' skill; the hard barrier remains Jest (or equivalent). No merge based solely on Gemini output.

Example breakdown (Next.js full-stack)

Schéma de flux — une app, un dépôt

Location saisonnière : pages et composants dans app/, réservation via Route Handlers, règles métier dans lib/.

Next.js — pages & composants

Catalogue, tunnel de réservation

Route Handlers

POST /api/bookings/...

Base de données

Disponibilités, contrats saisonniers

Règle iASSET — isolation du domaine

La génération cible surtout les composants, les handlers et les adaptateurs (paiement, calendrier). Le cœur métier dans lib/ (chevauchements, tarifs, annulation) reste explicite et protégé par vos skills / policy.

[S]pécification & [S]écurité — exemples

Types métier & Route Handler Next.js

Exemple minimal : une commande typée dans lib/, et un POST dans app/api/.../route.ts qui parse le JSON et appelle le service métier. En CI, le skill « spec + sécu » lit le diff — RGPD, idempotence et journaux se vérifient via prompts / policy sur le code source.

// lib/domain/booking.ts — pas d’import Next ici
export type BookingId = string;

export interface CreateBookingCommand {
  idempotencyKey: string;
  listingId: string;
  guestId: string;
  stayFrom: string; // ISO
  stayTo: string;
}

// lib/booking/service.ts
export async function createSeasonalBooking(cmd: CreateBookingCommand): Promise<BookingId> {
  // règles métier + persistance
  throw new Error('à implémenter');
}
// app/api/bookings/seasonal/route.ts
import { NextRequest, NextResponse } from 'next/server';
import type { CreateBookingCommand } from '@/lib/domain/booking';
import { createSeasonalBooking } from '@/lib/booking/service';

export async function POST(req: NextRequest) {
  const body = (await req.json()) as CreateBookingCommand;
  const bookingId = await createSeasonalBooking(body);
  return NextResponse.json({ bookingId });
}

En CI, après le lint, un job « spec + sécu » lance gemini -p sur le diff (skills + policy). Un job ultérieur peut préparer la MR ; la revue humaine reste la dernière étape.

[E]valuation & [T]est — pipeline CI

GitLab CI: job order

La revue via Gemini est un quality gate (prompt + skills + policy), pas un substitut aux tests. La création de MR peut être automatisée (script + API GitLab) ; la description peut être produite par un second appel gemini -p ou un template rempli à partir de la spec.

MR : utilisez un job ou une commande locale qui appelle l’API GitLab (POST /projects/:id/merge_requests) avec titre, description, branche source / cible — la description peut résumer spec + résultats des gates.

.gitlab-ci.yml — extrait (lint → spec+sécu → tests → MR)
# Ordre : lint → skill spec+sécu (diff) → tests → skill MR — pas de décorateur en CI
# CLI : gemini -p + --policy ; pas de sous-commande "gemini analyze"
lint_ts: ...
gemini_spec_security:
  needs: [lint_ts]
  stage: test
  script:
    - | gemini -p "Skill: spec + sécurité sur le diff. Spec: @docs/spec.md" \
      --policy policies/gemini-asset.yaml \
      --include-directories app,lib \
      --output-format json \
      | node scripts/check-gemini-gate.js
unit_tests:
  needs: [gemini_spec_security]
  script: npm run test:ci
gemini_mr_ready:
  needs: [unit_tests]
  script: node scripts/open-or-update-mr.js

Les prompts invoquent vos skills versionnés (gemini skills). check-gemini-gate.js fait échouer le job si la sortie JSON indique des blocages. open-or-update-mr.js peut appeler l’API GitLab pour titre + description ; la revue humaine reste hors pipeline.

Merge definition (checklist)

À adapter à votre politique d’équipe. Objectif : des critères objectifs, pas des promesses chiffrées non sourcées.

  • Referenced specification and acceptance criteria (link or versioned file) — seasonal rentals business rules aligned.
  • Green lint and typecheck on the branch.
  • CI skills (spec + sec, then MR): outputs match your rubric; no auto-merge without human validation if required.
  • Unit/contract tests needed for scope (bookings, overlaps, etc.) are green.
  • At least one human review (non-bot) according to project rules.