Skip to main content

​
Skill per contributori

Questo repository ha skill locali per mantenere il lavoro guidato dagli agent in linea con gli stessi standard previsti per i contributori umani. L’obiettivo non è l’automazione per se stessa. L’obiettivo è preservare:
  • insiemi di modifiche ristretti e revisionabili
  • documentazione veritiera
  • semver deliberata
  • isolamento pulito dei worktree

​
Skill locali al repo attuali

​
gb-worktree-feature-flow

Usa questa skill quando una modifica dovrebbe passare a un proprio branch e checkout. Standardizza:
  • un worktree per ogni ambito coerente
  • un branch per ogni worktree
  • fette revisionabili invece di modifiche non correlate accumulate
Entrypoint predefinito:

​
gb-oss-release-discipline

Usa questa skill quando una modifica riguarda:
  • il versioning di package.json
  • i tag di release
  • la documentazione per i contributori
  • l’igiene del repository pubblico
Applica la separazione tra:
  • semver come identità di release
  • buildVersion come identità di deployment a runtime
Standardizza anche la disciplina di CI dopo il push:
  • controllare le esecuzioni recenti di GitHub Actions con gh
  • riportare i job o gli step falliti invece di limitarsi a dire che la CI è fallita
  • proporre la prossima correzione quando un workflow è rosso

​
next-forge

Usa questa skill quando un task riguarda la struttura del monorepo, la proprietà dei package condivisi, il lavoro sul design system, Storybook, i feature flag o le convenzioni di deployment ereditate dal template. In questo repo, va letta come riferimento strutturale, non come un comando per attivare ogni superficie di scaffold dormiente. Il confine dell’area di lavoro attiva in README.md rimane la fonte di verità. Standardizza:
  • app autonome e package condivisi
  • Storybook come superficie di revisione per la UI condivisa
  • packages/design-system come unico target shadcn CLI supportato in questo repo
  • pnpm dlx shadcn@latest info -c packages/design-system --json prima del lavoro sulla UI condivisa
  • radix-nova più i token semantici olive come baseline UI condivisa attuale
  • Mintlify come superficie di documentazione di prima classe
  • modifiche strutturali consapevoli dei confini
  • comandi di manutenzione come pnpm boundaries, pnpm bump-deps e pnpm bump-ui
  • la manutenzione delle dipendenze come slice dedicata a livello root invece di aggiornamenti sparsi package per package
  • Biome tramite pnpm lint e pnpm format come percorso di formattazione/lint del repo
  • pnpm build:tracked <target> e pnpm typecheck:tracked <target> per task lunghi di Storybook, Next.js e validazione
  • @repo/database come unico confine del data-plane supportato
  • @repo/auth come unico confine di autenticazione/sessione Supabase supportato
  • nessun accesso diretto a @supabase/supabase-js a livello di data-plane dalle app senza un’esplicita modifica del confine

​
gb-linear-execution

Usa questa skill quando un task riguarda l’organizzazione della roadmap, la pianificazione dei progetti, la suddivisione degli issue, le milestone o la sincronizzazione con Linear. Standardizza:
  • planning/linear/* come pack di pianificazione canonico
  • iniziative, progetti, milestone e issue invece di documenti di roadmap paralleli
  • pnpm linear:sync per l’anteprima e pnpm linear:sync:apply per l’importazione
  • l’attuale forma dell’area di lavoro Linear ancorata al team GB
  • la creazione o l’aggiornamento di un issue Linear quando il lavoro di implementazione rivela un blocco sostanziale, un gap di parità o un gap architetturale

​
Coerenza del repository

Queste skill sono intenzionalmente modellate sulla stessa postura del repository usata in gb-travio-webhooks, preservando al tempo stesso la disciplina strutturale ereditata da next-forge:
  • documentazione diretta
  • PR piccole
  • deployment guidato dal repo
  • comportamento operativo esplicito
  • confini chiari tra app e package
  • superfici di prima classe per documentazione e Storybook

​
Aggiungere altre skill

Quando aggiungi una nuova skill per questo repo:
  1. mantieni l’ambito ristretto
  2. scrivi la skill attorno a un workflow ripetuto, non a un task occasionale
  3. rimanda alla documentazione esistente invece di duplicarla
  4. aggiungi metadata affinché le sessioni future possano scoprirla rapidamente

​
Posizioni attuali

  • .agents/skills/shadcn
  • skills/gb-worktree-feature-flow
  • skills/gb-oss-release-discipline
  • skills/gb-linear-execution
  • skills/next-forge

​
Leggi anche