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.
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.
Upstream — iASSET skills
Define and version the skills library (spec, commit, CI spec/sec, CI MR, etc.).
Development — spec skill
Invoke the skill that processes the spec: AC, DoD, test descriptions (seasonal rentals).
Implementation
Code and tests (Next.js: `app/`, `lib/`, Route Handlers); feature branch.
Commit — dedicated skill
Another skill for message format, scope, ticket link (hook or local command).
Push
Triggers the CI pipeline on branch / MR.
CI — spec + sec skill
Verify diff + files against spec and security — without runtime decorators.
CI — lint → spec+sec → tests → MR skill
Order aligned with the diagram; then a human validates the MR.
Recommended CI order
Lint + typecheck → skill spec + sécu (sur le diff) → tests → skill MR → revue 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.
| Pillar | CLI lever (example) | Note |
|---|---|---|
| [A] | Skills + policy (--policy) | Workspace/tool rules; prompts separate `app/`, `lib/`, Route Handlers. |
| [S] spec | Skills (`gemini skills`) | Versioned playbooks for AC/DoD/tests before the first commit. |
| [S] sec | Policy + prompts | Constrain the agent; MCP for doc/linter context if needed. |
| [E] | Headless `gemini -p` + hooks | CI or Git hook: same CLI as local, JSON output to fail the job. |
| [T] | Prompt or 'tests' skill | Complement 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 — UI
App Router, RSC, formulaires réservation
Next.js — API
app/api/.../route.ts
Données
Annonces, créneaux, voyageurs
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.
# 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.