Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
ahaodev avatar

Shadmin Dev

  • 1 installs
  • 164 repo stars
  • Updated July 27, 2026
  • ahaodev/shadmin

shadmin-dev is a Claude Code skill that applies Shadmin's full-stack feature-development standards for a Go/Gin/Ent backend and a React/TypeScript frontend.

About

shadmin-dev is a Claude Code skill that applies Shadmin's feature-development standards across a Go/Gin/Ent backend and a React/TypeScript frontend. It lays out the clean-architecture layer order for CRUD modules, API routes, controllers, usecases, repositories, Ent schemas, and the matching frontend types, services, hooks, tables, and routes. Developers use it when adding or modifying features so code compiles and follows the project's established patterns.

  • Guides full-stack feature development in the Shadmin project's clean architecture
  • Backend layers: domain, Ent schema, repository, usecase, controller, route, factory (Go + Gin + Ent)
  • Frontend layers: types, services, features, routes, stores (React 19 + TypeScript + Vite + TanStack)

Shadmin Dev by the numbers

  • 1 all-time installs (skills.sh)
  • Ranked #3,830 of 4,347 Backend & APIs skills by installs in the Skillselion catalog
  • Data as of Jul 28, 2026 (Skillselion catalog sync)
At a glance

shadmin-dev capabilities & compatibility

Capabilities
full stack development · crud scaffolding · api development · clean architecture · frontend development
Use cases
api development · frontend · database
IDEs
vscode
From the docs

What shadmin-dev says it does

Guide full-stack feature development through Shadmin's clean architecture, producing code that compiles, passes lint/tests, and follows established patterns.
SKILL.md
Backend (Go + Gin + Ent ORM)
SKILL.md
npx skills add https://github.com/ahaodev/shadmin --skill shadmin-dev

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs1
repo stars164
Last updatedJuly 27, 2026
Repositoryahaodev/shadmin

What it does

Guide full-stack feature and CRUD development in the Shadmin Go/Gin/Ent + React/TypeScript codebase.

Who is it for?

Adding or modifying features and CRUD modules inside the Shadmin project following its clean-architecture layers.

Skip if: Projects that do not use the Shadmin Go/Gin/Ent + React/TanStack stack.

When should I use this skill?

You are adding or modifying a feature, CRUD module, API route, Ent schema, or React page in the Shadmin project.

What you get

A feature is implemented across backend and frontend layers in the correct order following Shadmin conventions.

By the numbers

  • 8 backend layers
  • 6 frontend layers
  • 4-step full-stack workflow

Files

SKILL.mdMarkdownGitHub ↗

Shadmin Feature Development

Guide full-stack feature development through Shadmin's clean architecture, producing code that compiles, passes lint/tests, and follows established patterns. Most features require both backend and frontend changes — this skill covers the end-to-end workflow.

Architecture Overview

┌─────────────────────────────────────────────────────────────────────┐
│  Frontend (React 19 + TypeScript + Vite)                            │
│  Route File → Page Component → TanStack Query Hook → API Service   │
│       ↕ Zustand (auth-store) ↕ Permission checks                   │
├─────────────────────────────────────────────────────────────────────┤
│  HTTP (Axios apiClient ← Bearer Token injection)                   │
├─────────────────────────────────────────────────────────────────────┤
│  Backend (Go + Gin + Ent ORM)                                      │
│  Route → [JWT MW → Casbin MW] → Controller → Usecase → Repository  │
│       ↕ Domain (contracts, DTOs, errors) ↕ Ent (DB, migrations)    │
└─────────────────────────────────────────────────────────────────────┘

Backend layers — each has exactly one responsibility:

LayerDirectoryResponsibility
Domaindomain/Entity structs, DTOs, Repository/UseCase interfaces, errors, response helpers
Schemaent/schema/DB schema → run go generate ./ent after changes
Repositoryrepository/Data access via Ent, domain↔ent conversion, pagination
Usecaseusecase/Business logic, validation, context.WithTimeout
Controllerapi/controller/HTTP parsing only, Swagger annotations, status code mapping
Routeapi/route/Route registration, middleware wiring
Factoryapi/route/factory.goDI: repo → usecase → controller construction
Bootstrapbootstarp/App init, DB, Casbin, seeds (directory name typo is intentional)

Frontend layers:

LayerDirectoryResponsibility
Typesweb/src/types/TypeScript interfaces matching backend DTOs
Servicesweb/src/services/Axios API wrappers, date parsing
Featuresweb/src/features/Page components, tables, dialogs, forms, hooks
Routesweb/src/routes/TanStack Router file-based routing
Storesweb/src/stores/Zustand state (auth, permissions)
Constantsweb/src/constants/Permission strings, enums

Full-Stack Development Workflow

Step 1: Clarify Scope (before writing code)

State explicitly:

  • What entities/fields are involved
  • API endpoints: path, method, request/response shapes
  • Whether Casbin permission checks are needed
  • Frontend: pages, tables, forms, dialogs
  • Permission strings (e.g., system:project:add)

Step 2: List All Touched Files

Group by layer — this catches missing pieces early:

# Backend (implement in this order)
domain/<resource>.go
ent/schema/<resource>.go
repository/<resource>_repository.go
usecase/<resource>_usecase.go
api/controller/<resource>_controller.go
api/route/<resource>_routes.go (or modify system_routes.go)
api/route/factory.go

# Frontend (implement in this order)
web/src/types/<resource>.ts
web/src/services/<resource>Api.ts
web/src/features/<module>/<resource>/components/*-provider.tsx
web/src/features/<module>/<resource>/hooks/use-<resource>.ts
web/src/features/<module>/<resource>/components/*-columns.tsx
web/src/features/<module>/<resource>/components/*-table.tsx
web/src/features/<module>/<resource>/components/*-form-dialog.tsx
web/src/features/<module>/<resource>/components/*-dialogs.tsx
web/src/features/<module>/<resource>/components/*-primary-buttons.tsx
web/src/features/<module>/<resource>/data/schema.ts
web/src/features/<module>/<resource>/index.tsx
web/src/routes/_authenticated/<module>/<resource>.tsx
web/src/constants/permissions.ts (add new permission keys)

Step 3: Implement Backend

Follow the layer order strictly — each layer depends on the one above.

Read `references/backend.md` for complete code templates and patterns.

Quick reference for key conventions:

  • IDs: xid.New().String() in Ent schema DefaultFunc
  • Partial updates: pointer fields in Update*Request (*string)
  • Pagination: embed domain.QueryParams, call domain.ValidateQueryParams()
  • Response: domain.RespSuccess(data) (code=0) / domain.RespError(msg) (code=1)
  • Usecase: every method starts with context.WithTimeout + defer cancel()
  • Errors: sentinel errors in domain, %w wrapping, map to HTTP status in controller
  • Factory: repo → usecase → controller, dependencies from f.db, f.app, f.timeout
  • Routes: protected system routes use casbinMiddleware.CheckAPIPermission()

Step 4: Implement Frontend

Follow the order: types → service → feature module → route file.

Read `references/frontend.md` for complete code templates and patterns.

Quick reference for key conventions:

  • API response: response.data.data (outer .data = Axios, inner .data = domain.Response.Data)
  • Date parsing: API service converts string dates to Date objects
  • Query params: URLSearchParams construction, snake_case to match backend
  • Table state: useTableUrlState hook syncs pagination/filters with URL
  • Dialog state: string-based via context provider (open === 'add' | 'edit' | 'delete')
  • Permissions: usePermission() hook, PERMISSIONS.SYSTEM.RESOURCE.ACTION constants
  • Toast: sonner for success/error notifications
  • Forms: React Hook Form + Zod, single hook handles create/edit
  • Route file: Zod schema validates URL search params with .catch() defaults

Step 5: Wire Permissions

Shadmin uses a dual-layer permission model:

Backend (API access):    Casbin checks (userID, path, method)
Frontend (UI visibility): Permission strings like "system:project:add"

These are linked through the Role → Menu → API Resources binding: 1. Backend auto-scans routes into API resources on startup (bootstrap.InitApiResources) 2. API resource IDs are deterministic: METHOD:/api/v1/path (e.g., GET:/api/v1/system/project) 3. Admin assigns menus to roles, each menu binds to API resources 4. Frontend fetches permissions from /api/v1/resources and stores in Zustand

To add permissions for a new feature: 1. Backend: routes auto-register as API resources on restart 2. Frontend: add permission constants in web/src/constants/permissions.ts 3. Admin panel: create menu entries, bind API resources, assign to roles

Step 6: Generate & Verify

# Backend
go generate ./ent           # If schema changed
go fmt ./... && go vet ./... # Format + static analysis
go test ./...                # Run tests
swag init -g main.go --output ./docs  # If Swagger annotations changed

# Frontend (from web/)
pnpm lint                   # ESLint
pnpm format:check           # Prettier
pnpm build                  # Recommended if routes/build config changed

Key Response Format

// Success (HTTP 200/201)
type Response struct {
    Code int         `json:"code"`    // 0 = success
    Msg  string      `json:"msg"`     // "OK"
    Data interface{} `json:"data"`    // payload
}

// Error (HTTP 400/404/500)
// Code = 1, Msg = error description, Data = nil

// Paginated response (in Data field)
type PagedResult[T any] struct {
    List       []T `json:"list"`
    Total      int `json:"total"`
    Page       int `json:"page"`
    PageSize   int `json:"page_size"`
    TotalPages int `json:"total_pages"`
}

Boundaries

Things to never do:

  • No business logic in controllers — controllers parse HTTP, call usecase, return response
  • No HTTP/permission logic in repositories — repositories do data access only
  • No bypassing Casbin on protected APIs
  • No new globals — use factory's f.db, f.app, f.timeout
  • No inline API calls in React — all API access goes through services/ wrappers
  • No direct localStorage for auth — use useAuthStore
  • No editing `components/ui/` — shadcn-generated primitives
  • No hardcoded menus — menus come from backend /api/v1/resources
  • No unnecessary dependencies — frontend or backend
  • Minimal changes — only touch files relevant to the feature

Reference Files

For detailed code templates and implementation patterns, read these as needed:

  • `references/backend.md` — Complete Go/Gin/Ent code templates for domain, schema, repository, usecase, controller, routes, and factory. Read when implementing backend features.
  • `references/frontend.md` — Complete React/TypeScript code templates for types, API services, feature modules, hooks, tables, forms, dialogs, routes, and permissions. Read when implementing frontend features.

Further Documentation

The docs/getting-started/ directory contains comprehensive guides:

  • quickstart.zh.md / quickstart.en.md — Quick start guide
  • architecture.zh.md / architecture.en.md — Architecture deep-dive
  • development.zh.md / development.en.md — Full CRUD walkthrough with example
  • deployment.zh.md / deployment.en.md — Production deployment guide

Related skills

Backend & APIsbackendfrontend

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.