fantastic-admin/basic: a Vue admin shell built for AI coding agents

What fantastic-admin/basic is, and who it is aimed at

Fantastic-admin describes itself as an AI-oriented management system framework, compatible with PC and mobile. The basic edition in this repository is the free tier; the README notes that some listed features belong to a professional edition. The target reader is a front-end team that already knows Vue and wants a pre-built admin shell rather than a blank Vite project: routing, layout, theming, permissions and i18n are part of the framework, not something you assemble from five separate packages.

The distinguishing claim is the AI angle. The repository root contains AGENTS.md, CLAUDE.md, a .agents/ directory and a skills/ directory, and the feature list says the framework ships an AI-friendly engineering base with multiple built-in Skills. In practice that means the repository carries instruction files that coding agents read, so an assistant editing this codebase has project-specific conventions available without you writing them. That is a concrete artefact you can inspect, not a marketing phrase. What the README does not do is explain what each Skill contains or how an agent is expected to load it; that detail is left to the official site and the files themselves.

The stack and the monorepo layout

The README lists Vue 3.6, Vite 8, Pinia, UnoCSS, VueUse, TypeScript, ESLint and Stylelint. The root package.json confirms the tooling side: pnpm is the package manager, pinned as pnpm@11.24.0, and the engines field requires Node ^22.22.2, ^24.15.0 or >=26.0.0. There is a preinstall hook running npx only-allow pnpm, so npm and yarn are rejected before dependencies resolve. A postinstall hook installs simple-git-hooks, wiring a pre-commit hook to pnpm lint-staged.

The layout is a pnpm workspace: apps/, packages/, scripts/ and skills/ sit at the top level, alongside pnpm-workspace.yaml. The dev, build and serve scripts all delegate to tsx scripts/cli.ts with a --mode flag, so the build pipeline is a TypeScript CLI rather than raw Vite invocations. Dependencies use the catalog: protocol, which means versions are centralised in the workspace catalog instead of repeated per package. That is a deliberate choice: it keeps versions consistent across apps and packages, but it also means editing a dependency version is a workspace-level change, not a local one. The root package is private, so this repository is a source distribution, not a published npm package you install as a dependency.

Installing fantastic-admin/basic and running it

The README does not contain install steps. It says to download a stable release archive from the GitHub Releases page rather than pulling source directly, because a direct pull may contain unreleased content. So the first step is a download, not a clone. The README also points to the official site at fantastic-admin.hurui.me and a backup address at fantastic-admin.pages.dev, which is where setup documentation lives.

Once you have the archive extracted, the root package.json defines the commands. Because of the preinstall hook, pnpm is required:

pnpm install

After install finishes, the postinstall hook registers the git hooks. Then the dev server is started through the workspace CLI, not through a bare vite command:

pnpm dev

Under the hood this runs tsx scripts/cli.ts --mode=dev. The same CLI handles production and preview, so the mode flag is the switch you will use most:

pnpm build
pnpm serve

If you want the full lint pass before committing, the root script chains three checks rather than one:

pnpm lint

That runs lint:tsc (which filters to apps/* and runs each app's lint script), lint:eslint across the repository with --cache --fix, and lint:stylelint over apps and packages for css, scss and vue files, also with --cache --fix. Note that two of the three fix files in place, so run it on a clean working tree if you want to review what changed. The README does not document a rollback path or a way to disable the git hooks during install.

Theming, navigation and the professional-edition boundary

The feature list is where the framework's scope becomes clear. It advertises 18 default theme schemes that can be extended, 7 navigation menu modes, a page keep-alive strategy with fine-grained control, full permission verification, internationalisation with RTL support, and 19 reserved slots for extending product content. The 7 menu modes matter more than the theme count: navigation shape is the part of an admin panel that is hardest to change later, and having several modes built in means the framework anticipates that products change shape as they grow.

The README prefaces the whole feature list with a note that some items are professional-edition capabilities. It does not say which ones. That is the single most important thing to verify before you commit, because the list mixes base and paid features in one block. The repository you are reading is explicitly the basic edition, so treat every line as unconfirmed until you check the official site. The 19 slots are the other number worth thinking about: slots are extension points, and a slot you do not fill is inert. Their value depends on whether your product needs to inject content into layouts the framework already owns.

Where fantastic-admin/basic is the wrong choice

The README's download section is the honest signal. It tells you to take a release archive instead of pulling source, which means the documented path is a download-and-extract workflow rather than a git-based one. If your team expects to clone, branch and merge upstream changes, the project itself is warning you that main may carry unreleased content. That is a real friction point for teams used to tracking a framework as a git remote.

The pnpm-only constraint is the second boundary. The preinstall hook runs npx only-allow pnpm, so an environment that cannot use pnpm cannot install this at all. Combined with the Node engine range (^22.22.2, ^24.15.0 or >=26.0.0), older CI images will fail before any code runs. And because the root package is private and dependencies resolve through catalog: entries, you are adopting a workspace, not a library. If you wanted an npm package to add to an existing app, this is not that. Finally, the AI-facing files (AGENTS.md, CLAUDE.md, .agents/, skills/) are useful only if your workflow actually uses an agent that reads them; otherwise they are extra files in the root with no effect on the running application.

How it compares with vue-element-admin and assembling your own stack

The topics list places fantastic-admin alongside vue-element-admin, and the comparison is instructive. vue-element-admin is the long-standing Vue 2 era reference admin, built around Element UI. fantastic-admin/basic is Vue 3.6 and Vite 8 with Pinia and UnoCSS, and its README makes a point of letting you choose the third-party UI library rather than binding the framework to one. That is the actual difference in approach: vue-element-admin is a complete application you fork and trim, while fantastic-admin/basic is a workspace with apps and packages, where the UI library is a decision you keep.

The second alternative is assembling the stack yourself: Vite plus Vue Router plus Pinia plus an admin template. You get exactly the dependencies you want and no professional-edition boundary to reason about. You also write the permission layer, the keep-alive strategy, the theme system and the navigation modes from scratch. The trade is control versus the 18 themes and 7 menu modes that already exist here. If your navigation model is unusual, the built-in modes may not fit and the framework's structure becomes overhead rather than help.

Licence and the cost of staying current

The repository is MIT licensed, and the badge in the README labels it as the open-source agreement. MIT is permissive, so the basic edition can be used, modified and redistributed under its terms. The README's note that some features belong to a professional edition is a separate matter from the licence: it tells you the free tier is a subset, not that the licence restricts you. Which specific features sit behind that line is not stated in the README, so read the official site before assuming a listed capability is included. This is not legal advice; read the LICENSE file and the official site for the terms that apply to you.

Upgrade cost is visible in the release history: v6.2.0 on 2026-06-12, v6.3.0 on 2026-07-04 and v6.4.0 on 2026-08-30. That is roughly monthly minor releases, and the root package.json carries a taze script (taze minor -wIr) plus bumpp for releases, so the maintainer's workflow is built around keeping dependencies current. For a fork, that cadence is the cost: minor releases arriving monthly mean rebasing your customisations against a moving base. The README recommends release archives over source pulls, which suggests the intended upgrade path is downloading a new archive rather than merging a branch. The last push to the repository was on 2026-08-30.

Editorial conclusion

Adopt fantastic-admin/basic if you are starting a Vue 3 admin panel and want an AI coding assistant to work inside it: the repository carries AGENTS.md, CLAUDE.md, .agents/ and skills/ directories, and the stack is pinned to Vue 3.6, Vite 8, Pinia, UnoCSS and TypeScript. Do not adopt it if you need a framework whose README walks you through setup, or if you cannot tolerate a pnpm-only workspace enforced by a preinstall hook. Before committing, open the official site at fantastic-admin.hurui.me and confirm the basic edition covers the features you need, since the README marks some capabilities as professional-edition only, and check whether the 18 themes and 7 menu modes are enough for your product's navigation model.

Frequently asked questions

Official sources

1. fantastic-admin/basic on GitHub
2. License: MIT
3. Project website
4. README
5. Releases