DEV Community: Danil Shutsky

AI Factory: Automating AI Agent Project Setup

Danil Shutsky — Thu, 12 Feb 2026 05:44:01 +0000

I'll tell you about a tool I created to speed up project configuration for effective work with AI agents (in my case, Claude Code). I worked with SpecKit for a long time - a great project . It helped me a lot and gave me understanding of working with LLMs. But over time, I started noticing drawbacks that became increasingly frustrating.

The Problem

Before starting work with an AI agent on a project, my standard scenario looked like this:

1. Work Organization

Topic research
Planning (I worked with SpecKit): explaining project structure to the agent, describing the stack and work rules, creating plans and checking them

2. Skills Setup

Search for suitable skills on skills.sh
Copy to .claude/skills/
If needed skill doesn't exist - write from scratch (well, generate to be precise)

3. MCP Server Configuration

Open .claude/settings.local.json and configure MCP servers
Add environment variables

Result: 30-60 minutes of setup before starting real work (I mean vibe-coding). Gradually, I started automating processes and this evolved into the AI Factory project.

What AI Factory Solves

Setup Automation:

ai-factory init → interactively configures everything in 2-3 minutes
Scans existing project (package.json, composer.json, requirements.txt)
Determines stack and downloads appropriate skills from skills.sh
Generates missing skills for your project
Configures MCP servers by choice

Result: from 30-60 minutes of setup to 5-10 minutes.

Unified Context:

.ai-factory/DESCRIPTION.md - always up-to-date project specification for agent context - no need to repeat explanations about what we're working on in each chat

Structured Workflow:

Clear commands: /task for quick tasks, /feature for big features, /fix for bugs
Automatic plans and checkpoints
Conventional commits out of the box

Learning System:

Each fix creates a patch with problem description
Next tasks account for past mistakes
/evolve improves skills based on project experience

AI Factory

The idea is simple: minimal setup, advantage of using specifications for LLM context and code quality with MCP+sub-agents with skills. And work comfort - everything you need is at hand!

GitHub

What prompted its creation? Experience working with SpecKit and OpenSpec. Both tools are good, but in my opinion have drawbacks.

Experience with SpecKit and OpenSpec

I actively used both tools and encountered specific problems:

SpecKit (from GitHub):

Excessive documentation: generates hundreds of lines of specifications, plans and checklists. For small tasks this is overhead
Rigid workflow: hard to skip steps like testing, even when it's not needed
Context problems: many tokens spent on work
Refactoring complexity: when you need to quickly fix a bug, you have to go through the whole cycle /specify → /plan → /tasks → /implement

OpenSpec (simpler):

Validation bugs: often shows validation errors even when everything is correct. openspec validate and openspec show return contradictory results
Control problems: AI sometimes ignores workflow and starts implementation without /openspec:apply command
Complexity for large projects: unclear how to apply for existing large codebases

Common problem for both:

Require manual setup for each project
Require preliminary topic research
Insufficient automation of skills generation and MCP connection

AI Factory takes these moments into account and solves them.

Getting Started

npm install -g ai-factory
ai-factory init

During initialization:

Interactive questions about project and agent
Automatic MCP server setup
Creating .ai-factory.json config

For a new project - will ask about stack. For existing - will analyze code itself and pick what's needed.

Main Commands

Command	Usage	Branch?	Plan?
`/ai-factory.task`	Quick tasks	No	`.ai-factory/plan.md`
`/ai-factory.feature`	Big features	Yes	`.ai-factory/features/<name>.md`
`/ai-factory.fix`	Bugs and errors	No	No
`/ai-factory.implement`	Execute plan	-	-
`/ai-factory.evolve`	Improve skills	-	-

Workflow

For small tasks:

/ai-factory.task → plan → /ai-factory.implement → done

For features:

/ai-factory.feature → branch + plan → /ai-factory.implement → commits → done

For bugs:

/ai-factory.fix → fix + logging + patch → done

Key Features

1. `/ai-factory` - Context Setup

Analyzes project, determines stack, picks skills from skills.sh or generates new ones, configures necessary MCP.

2. Feature and Task Planning

/ai-factory.feature - for large tasks with branch and full plan.
/ai-factory.task - for quick changes without branch.

Both analyze requirements, study codebase, create tasks with dependencies.

3. `/ai-factory.implement` - Executing Created Plan

/ai-factory.implement 5      # work on task #5 if we want to do something specific

Before starting, agent will read all patches from .ai-factory/patches/ - learns from past mistakes.

4. `/ai-factory.fix` - Quick Fixes

Use when it's clear the problem is small. Agent studies problem, applies fix with logging, creates patch for self-learning. No plans - immediate solution and learning.

5. `/ai-factory.evolve` - Skills Self-Learning

/ai-factory.evolve           # All skills
/ai-factory.evolve fix       # Specific skill

Analyzes all patches, finds error patterns, improves skills with your approval.

6. `/ai-factory.skill-generator`

Learning mode - pass URL to generate skills from documentation:

/ai-factory.skill-generator https://fastapi.tiangolo.com/tutorial/

Studies sources, enriches through search, generates full-fledged custom skills.

Self-Learning System

Each fix creates a patch - a document that helps avoid similar errors in the future.

Learning cycle:

/fix → bug → fix → patch → 
next /fix or /implement → reads patches → better code

Patch structure:

Problem and cause
Applied solution
Prevention recommendations
Search tags

Periodically run /ai-factory.evolve - the tool will analyze accumulated patches and improve skills for your project.

Project Structure

project/
├── .claude/skills/          # Skills
├── .ai-factory/
│   ├── DESCRIPTION.md       # Specification
│   ├── PLAN.md             # Current plan
│   ├── features/           # Feature plans
│   ├── patches/            # Learning patches
│   └── evolutions/         # Improvement logs
└── .ai-factory.json        # Config

MCP Servers

GitHub, Postgres, Filesystem are supported. Configuration in .claude/settings.local.json.

Best Practices

Logging: DEBUG/INFO/WARN/ERROR levels, control via LOG_LEVEL
Commits: checkpoints every 3-5 tasks, conventional commits format
Tests: always asked before plan, not added without consent

Tool Development

After active use over several days, I made two releases (v1.1 and v1.2):

v1.1: improved Skill Generator, learning mode

v1.2: patch system, /ai-factory.evolve, feature organization

v1.3. Security First!

Critically important update - protection system against prompt-injection. When downloading skills from skills.sh, we trust external sources with access to your project. Now each skill undergoes mandatory scanning for 10 threat categories - from injections and data leaks to social engineering. Two-level verification (regex + LLM intent analysis) filters out malicious code. /skill-generator scan allows manual file checking.

Also added new skill /ai-factory.improve for refining already created plans - when you understand the plan is good but something is missing.

Of course, I used AI Factory to develop AI Factory).

Conclusion

AI Factory solves specific AI development problems:

✅ Automatic project setup

✅ Spec-driven approach with control

✅ Self-learning from mistakes

✅ Simple workflow

Perfect If You:

Tired of setup before each project
Want structured approach when working with AI
Work on real projects
Have experience with Claude Code or similar tools

About the Future

I now have a team of assistants - experts in different areas. I'm doing projects I wouldn't have taken on before due to lack of stack knowledge.

This is a tool. Developer experience matters - often need to correct proposed solutions. AI is an assistant for specialists, not a replacement for developers.

MoonShine 4: AI-Powered Admin Panel Revolution

Danil Shutsky — Tue, 06 Jan 2026 08:30:14 +0000

November 11, 2025 at 11:11 - this important date will go down in MoonShine history. Four ones = fourth version. Symbolism? Perhaps. But behind these numbers is something more - 11 months of continuous work, with the last 6 in super intensive development mode. In this article, we'll break down all the changes in MoonShine 4: from the new palette and token system to AI-generated interfaces. MoonShine 4 truly changes the rules for working with admin panels. I wrote this article for those interested in open-source/Laravel/Filament/admin panels. Enjoy reading.

MoonShine is an open source admin panel for Laravel projects. And not just for Laravel.

History and Context

The Story of One Decision

When I started working on version four, I could have taken the easy path: a small refactoring, updating dependencies to current versions, updating Tailwind to version 4 - and calling it MoonShine 4. Safe. Planned. Boring.

But deep down, I didn't want such a release. I wanted to do something cool. Each MoonShine release has been a challenge for me, and I want to maintain this trend. And then the decision was made to create a new design. Despite the fact that crowdfunding for the new design raised only a small portion of what was needed. Despite the fact that the main contributors couldn't actively participate. Despite everything.

What Came of It

MoonShine 4 is not just an update. It's a serious transformation:

New design - UI work, taking into account all past mistakes
New architecture - CRUD extracted into a separate module for use outside Laravel with any data type
Design token system - ability to customize every interface element
AI integration - MoonShine Forty-Five - generator for working with Claude Code
Telegram Mini App - quick integration
20+ ready-made palettes - and a generator for creating your own
Comprehensive documentation - documentation almost entirely prepared by the community

Everything in order.

Thanks to Sponsors

I want to immediately say a big thank you again to everyone who supports MoonShine on GitHub, through direct donations and on Boosty. I estimated the design and layout update for MoonShine at $3,000, but we raised much less. The rest had to be added from my own funds. But I'm confident the situation will change for the better.

Release Date 11.11

As for the date 11.11 - it happened by accident. But there's an interesting moment I'd like to share with you. I didn't associate this number with MoonShine in any way, but probably for the last year, I've been periodically looking at the time and seeing 11:11.

Initially, the release was planned for November 1st. But I had to think about a postponement date. I'm choosing a date in the calendar. I look: 11.11. And I think: "How cool! That's 4 ones - that's exactly MoonShine 4!"

We added 4 stripes-sticks to the artwork. And many people wrote: "But those aren't Roman numerals! You wrote it wrong!" But actually, it's 4 ones. And I posted in Telegram with the promo video at 11.11 at 11:11. Such moments are cool. Surely, this will bring great success 😄

What is MoonShine

MoonShine is a convenient and multifunctional admin panel that helps developers quickly create administrative interfaces for their web applications based on the Laravel framework (one of the most popular tools for creating websites in PHP), as well as other frameworks.

Brief overview of MoonShine capabilities:

Ultra-Fast Development (Time Saving):
MoonShine is a ready-made constructor for an admin panel. You don't need to write forms, tables, and buttons for data management from scratch. You use ready-made components, which dramatically speeds up project creation. You can use MoonShine components not only inside the admin panel - with their help, you can build a personal cabinet or an entire project.

Simple Data Management (CRUD):
The main task of an admin panel is to manage information. MoonShine allows you to easily perform all CRUD operations (Create, Read, Update, Delete) for users, orders, articles, and other data in your database or through an API. Everything is intuitive and doesn't require complex code.

AI Assistant (Forty-Five) - Creating Interfaces in One Prompt:
The built-in AI agent MoonShine Forty-Five is your personal assistant. You can literally ask it to create an entire page in one prompt (request), for example: "Make a page with a list of users, a filter, and an add button." This incredibly speeds up work.

Branding and Appearance in 1 Minute:
With the new Palette and Design Token system, you can instantly change the color scheme, fonts, and panel spacing so it looks like your brand. There are 20+ ready-made palettes and a special generator that simplifies this process.

Admin Panel Always With You (Telegram Mini App):
Thanks to Telegram Mini App integration, your admin panel opens right inside Telegram. This means that to work from a mobile phone, you don't need a separate, complex to develop mobile app.

MoonShine vs Competitors

Quickly evaluate the differences between the most popular admin panels for Laravel:

Criteria / Feature	MoonShine	Filament	Orchid	Nova
Performance*	Medium	Low	Medium	Medium
Free	+	+	+	-
Highly Customizable	+	+/-	+/-	-
Detailed Documentation	+	+	+	+
Frequently Updated	+	+	- (Aug 13)	+
Beginner Friendly	+	+	-	+
Color Palette Customization	+	+	-	+
Video Guides	+	+	-	+
Stack	TAL	TALL	LBH	VILT
Any Data Type	+	Eloquent	+	Eloquent
Ability to Use Components	+	+/-	+/-	-
Convenient for MVP Development	+	-	-	-
Ecosystem	+/-	+	+/-	+
Online Demo Availability (quantity)	+ (3)	+ (1)	-	+
Ready-Made Solutions Marketplace	+	+	-	+

* No admin panel received high performance. Not because they're all bad, but because admin panels aren't about performance, they're about speed of implementation.

In fact, MoonShine has a lot in common with Filament. And here everyone chooses a tool to their liking - if you want a lot of sugar and like to use ready-made elements, then Filament is closer to you, but one step to the left - and you already face problems and run to the chat for help. If you consider yourself a developer, then MoonShine will be better here - there are ready-made solutions for popular tasks, and if you need something custom, it's convenient to do it yourself. That was yesterday. And today MoonShine has Forty-Five, and any component can be made in one prompt.

A small advertisement. Here's the result of executing one prompt:

"Make a field with Yandex Maps integration":

And one more difference - MoonShine has already gone beyond Laravel. There's a basic admin panel MoonShine for Symfony, there's the possibility to make an implementation for Yii and other frameworks! If you're interested - write, we'll discuss!

Main Features

New Structure: Order in Code

What are Resources, Pages, Components and Fields (basics for beginners)

Any page opened in a browser within the MoonShine admin panel is called just that - a page. It consists of a template (Layout) which can be different for each page. By default, there's a template for the login page, for CRUD pages, and a template for error pages. And the content of the page is MoonShine components. In MoonShine, everything is broken down into components, each HTML tag is a component, and you can configure your templates and pages with them.

CRUD pages operate with data. By default, data is based on Eloquent models, and pages created for CRUD operations within a specific model are combined into a resource. A resource groups a set of pages with a common data type, helps retrieve data, save and delete: a complete CRUD set. The basis for CRUD pages is, of course, a form for editing them and a table for displaying the entire list. The table and form are also MoonShine components. And how to display data inside is the task of fields, by analogy with fields in tables. With fields, we configure what we display: a text field or a field with an image.

CRUD Module

Everything related to CRUD has been extracted into a separate module. This was done so that CRUD modules can be used outside Laravel. This idea came when I was making an implementation of MoonShine for Symfony. You can take this CRUD module and make it for any framework. Or use it in Laravel for any data type other than Eloquent.

The Problem with the Old Structure (MoonShine 3)

Before version 4, you had to configure the set of fields for all pages from the resource. You could move to separate pages, but that was already an option. With this approach, the resource itself grew, there was a lot of logic about which fields to display on which page. In chats, there were many questions: how do I check which page I'm currently on to properly configure fields? And it seemed convenient - everything in one place, but in fact, it wasn't.

Solution in MoonShine 4

By default, when creating a resource, three pages are also created for the data list, editing/creation, and detailed display. Now this is not an option, and each page has responsibility for everything that happens on it. Also, the main page components - on the index - table, for creation/editing - form, and table on the detail page are extracted into separate layers and can also be overridden and customized.

Tailwind 4 and Design Tokens: Customization Without Limits

What Changed

A lot of work was done to upgrade Tailwind to version 4. Done by Artem Vaco. This is not just a new number in the metrics - the appearance of Tailwind 4 gave great opportunities for working with color schemes and layout. A design token system was created, with which you can quickly customize the appearance.

Design tokens are the basic components of a design system: variables that store colors, sizes, spacing, and typography. In our case, they allow you to quickly make global changes to the layout by changing just one token value.

For example, there's spacing. You can simply override spacing through the main template - and instead of 1.5, set 1.0. And the entire theme will become more compact, since everything here is implemented on spacing.

Any color, any border radius, any padding - everything is implemented on design tokens. You can generally override anything you want.

protected function assets(): array
{
    return [
        InlineCss::make(
            <<<CSS
                :root {
                    --spacing: 0.25rem;
                    --text-xs: 14px;
                    --text-sm: 14px;
                    --ms-btn-icon-size:16px;
                }
                CSS,
        ),
    ];
}

Palettes: Branding in 1 Minute

Problem and Solution

Branding is an important part of an admin panel. And replacing the logo doesn't solve all needs. But if the admin panel uses brand colors, it gives the feeling that the entire panel was written from scratch for business needs, the client will feel maximally comfortable in it! Previously, you had to manually work with styles. Now, using design tokens, you can override all template parameters at once through a separate layer, which we called Palettes.

Palettes - Default and Brand

For the new design, we initially wanted to make a black-and-white palette the default. Since many complained: "MoonShine is a bad admin panel - we don't like the purple color." But later we decided that after all, it's MoonShine - it's already a certain brand that we want to initially demonstrate. And we left the default palette in familiar colors.

But you can switch to another palette in a second or create your own.

final class MoonShineLayout extends AppLayout
{
   protected ?string $palette = NeutralPalette::class;
}

Palette Generator

A palette generator appeared on getmoonshine.app. Here you can see all the box palettes. When you install MoonShine, it will offer you a palette to choose from. Here's the neutral theme, it looked like this.

There are more unusual color schemes, for example, Halloween.

Notably, the palette generator is implemented on MoonShine. There's no additional JS here, no additional CSS, no additional components - completely on MoonShine.

The feature of this generator is that you can customize the palette to the necessary colors, see how it will look and export it for your project. Simple and convenient.

Generating Palettes with Forty-Five

And with Forty-Five, you can generate a color scheme in one prompt and the LLM itself will create a class, put it in the right directory and connect it to the system. But I won't get ahead of myself, I'll tell you about Forty-Five below.

New Design: Creation History

Design History

Often in comments people wrote to me that MoonShine's design is bad, looks scary. But I understood that design is a matter of taste - you can't please everyone. But there were many reviews about weak design of MoonShine 3 and I decided. I wrote to the same person (a cool specialist who made the landing page for Yii3) who last time made the default design for MoonShine 1.5, only now taking into account all the shortcomings. We collected feedback and rolled up our sleeves.

In the end, we succeeded. My opinion - it's fire. But already in the MoonShine chat I saw that again people write: "The design is not very good, we should have used shadcn." But essentially this will always be the case, there will always be people who don't like something.

New Template Capabilities

Layout Customization

In the third version of MoonShine, the sidebar was always pressed to the left side of the screen. And the content area was pressed to it. And you couldn't add a second sidebar (without CSS dances). Now there's the ability to make any sidebar combinations.

Here are sidebars both on the left and right.

Now let's return to customizing the content block. If you need to center the content block, just change the template property:

final class MoonShineLayout extends AppLayout
{
    protected bool $contentCentered = true;

    // …
}

By default false. If we set true, we get the content area in the center.

You can remove the Sidebar and this view is perfect for working with MVPs.

MoonShine Forty-Five: AI Changes the Game

What It Is and Why

MoonShine Forty-Five - LLM-powered admin panel creation assistant.

Why such a name? MoonShine translates as moonshine. Standard 40 proof, and this is a stronger thing - 45. More advanced, stronger - from which there's more pleasure.

The package was created so that your AI agent works with MoonShine at level 80. For now it only supports Claude Code, but I'm sure it has a big future ahead. Taylor Otwell, Nuno Maduro will immediately make reviews and start contributing.

How It Works (Step by Step)

Installation:

npm install -g @moonshine-software/forty-five

And then the principle of operation is like with GitHub SpecKit.

Adding strong MoonShine to the project:

forty-five init

Forty-five will download all necessary guidelines and add its custom commands to Claude Code for work.

Then you call Claude Code, write a Forty-Five command and give a task.

Forty-Five Commands

Currently five commands are available. Let's break them down.

1. /forty-five.palettes

Here, I think, everything is clear. You can generate palettes based on AI. I didn't tell you this, but all those 20 palettes that are in the box were generated in Forty-Five. And then we approved them as MoonShine directors. Plus we fine-tuned them a bit.

Let's strain the agent, let it make us a palette in Batman colors.

Here's what we got. Well, so-so result, probably the idea about Batman wasn't very successful. Or Claude didn't watch Batman.

2. /forty-five.layout

Well, making color schemes isn't the most useful thing. The Layouts command allows you to do more serious tasks. You can use a component approach and build pages with Forty-Five. Under the hood, it has a huge guideline on components with detailed rules for their correct use, which the LLM follows:

If you need a sidebar - Forty-Five will wrap it in <x-wrapper>
If you ask for a "button in the center" - it will add .justify-center
If you say "without borders" - it will apply .border-none to the needed component
Everything with icons, colors and spacing works according to rules understandable to the LLM agent

And you'll get ready-made pages according to your prompt. For example, I simply wrote:

"make a page with a list of users, with a filter and an add button"

This is in one prompt, friends! Everything as ordered. It's possible that if the task wasn't stated very precisely (or the result wasn't quite what you wanted), then you'll need to work additionally on this task together with Forty-Five. For example, add dividers somewhere, play with spacing, and so on.

3. /forty-five.components

This command allows you to quickly generate ready-made UI interface elements based on MoonShine blade components. Tables, modal windows, forms, lists - everything needed to build a user interface.

Under the hood of the command is a huge guideline on the entire MoonShine blade component library:

Correct HTML structure without tag duplication
All necessary wrappers and CSS classes in place
Correct use of slots (slot-based patterns)
All logic for working with icons, badges, buttons

And you'll get ready-made Blade templates as a result, for example:

"create a user table with avatars, name, email, status badges, and action buttons"

4. /forty-five.field

This command allows you to create custom fields for MoonShine. If you need something specific that's not in the standard field set - Forty-Five will generate everything necessary.

Under the hood of the command are detailed guidelines on MoonShine field structure:

Correct PHP class structure with Field inheritance
Blade view with correct wrappers and CSS classes
Alpine.js integration for interactivity
Support for fluent methods for configuration

And you'll get ready-made custom fields according to your prompt. For example, I simply wrote:

"create a rating field with stars from 1 to 5, with the ability to click on a star and select a rating"

Result: PHP class, Blade view with Alpine.js, correct saving to database.

5. /forty-five.component

The last command is for creating custom components. Unlike fields, components are used to decorate the interface and are not directly related to model data.

Under the hood of the command is knowledge about:

The difference between components and fields
Correct component structure
Working with slots and nested components

And you'll get ready-made UI components as a result, for example:

"create a 'statistics card' component - with icon, value, and label"

We get: PHP class with fluent methods, beautiful layout, and icon support.

Using Forty-Five

Forty-Five doesn't just generate code - it understands MoonShine best practices. If the result wasn't quite what you wanted, just clarify the details in the next prompt: "add mass delete capability" or "make the content field mandatory only for published articles". Forty-Five understands the context of your previous generation and makes targeted changes.

Time Saving is Reality

Imagine: instead of an hour of manual work setting up fields, filters, and relationships, you get a ready result in a couple of minutes. Moreover, a result that follows all MoonShine rules, uses the correct components, and is optimized for your needs. Forty-Five is an excellent tool, but it can't guess your thoughts. Everything depends on how well you set the task for it. And you still need to know the documentation. But with the appearance of such tools, the rules of the development game are changing. You can simply connect Forty-Five and get a personal cabinet in one prompt. Or you can make full MVPs.

Telegram Mini App: Admin in Your Pocket

Since the middle of the year, I've been working on one project (Task Manager). Its feature is integration with Telegram Mini App. As it turned out, it's very convenient! Developing such an application is much easier than writing an app for mobile applications. Sometimes I had the idea to make an application for the admin panel, and this is just a suitable elegant solution! And I made a package with Telegram Mini App integration into MoonShine. It's simple to use. Install it, specify the bot token, Mini App URL, user's Telegram ID in the admin panel. That's it! The admin panel can be used in Telegram Mini App. Of course, this doesn't replace the web interface, but surely you've had the need to do something in the admin panel from your phone. With Telegram Mini App, it's much more convenient to do this.

Documentation from the Community

Working on MoonShine 4 Documentation

This time there was a super cool team for documentation, the guys really pleased me. If last time I gathered about 10 volunteers from the community for documentation. But I did about 90% myself.

This time I practically didn't touch the documentation. I wrote that there's a task to make documentation, 11 people volunteered. But all the work was done by Anatoliy, Egor, and Vladislav. And we managed with the documentation exactly on schedule. Plus, the guys not only wrote documentation, they also updated packages for MoonShine 4, offered practical advice - in general, a huge contribution. And I'll have gifts for them: it will be merch and all kinds of useful things. I motivate from my side as I can!

MoonShine School

MoonShine is constantly evolving and everyone can participate in it.

If you ask the guys in the MoonShine chat who helped with documentation, most of them will say that for them it was a very cool experience. Working in a team on MoonShine is like taking a course in teamwork. And writing code is just one of the tasks - the most diverse skills are needed - documentation, design, layout, promotion. I, in turn, will continue to work with the team. Some guys admitted that when there's routine and boredom at work, the hobby of working on MoonShine captivated them, plus they're developing well as specialists. And I myself as a developer have greatly leveled up precisely on MoonShine.

PHPStorm Plugin: Automating Routine

A plugin for PHPStorm by Dima Derepko. Created specifically for working with MoonShine.

Main features:

Provides smart autocompletion for classes, fields, and components.

Simplifies navigation through the project via special icons in the editor - you can quickly navigate between related elements, for example from resources to Eloquent models and back.

In the "New" context menu, a separate MoonShine menu appears for quick creation of typical files: resources, pages, fields, components, layouts, etc. Each file type is generated through a dialog box with corresponding parameters based on a template.

And New Project will immediately create a clean project on Laravel+MoonShine.

For those who work in PHPStorm - I highly recommend trying it!

What's More?

Upgrade Guide: Migration from Version Three

A convenient tool for updating from the third to the fourth version. Egor made an Upgrade Script with Rector under the hood. It will do most of the routine work, and you'll need to manually finish your customizations. If you're planning to upgrade a project from version three to four, I recommend using the script. Then familiarize yourself with the Upgrade Guide - it's not that big.

In general, when preparing the release, we tried as much as possible to maintain compatibility between versions 3 and 4. Somewhere previous versions of classes remain, which are marked as Deprecated. They still work for now, but you should gradually get rid of them - they will be removed in MoonShine 5.

Add-ons Store - Ready-Made Solutions

MoonShine 4 has an official marketplace. This is a section where ready-made solutions for typical tasks are placed.

Imagine: you need a file manager integration. You can spend several hours a day writing from scratch, or you can install a ready-made package in 5 minutes that's already used on hundreds of projects and works like clockwork. That's what the marketplace was created for - so you don't waste time on what someone has already solved before you.

What's Interesting There?

File Manager - file manager with drag-and-drop, image previews, file organization.

MoonShine Roles-Permissions - if you need a system of roles and access rights, this is your choice. Built on the basis of the famous Spatie Laravel Permissions. 12,000+ downloads - one of the most popular packages. Mass role assignment, custom rights - all out of the box.

MoonShine Spatie MediaLibrary - integrates the functionality of the popular Laravel-MediaLibrary package from Spatie, for managing media files in the admin panel.

Two-Factor Authentication - two-factor authentication for the admin panel.

User Impersonation - a cool thing for support. Need to reproduce a client's bug? Log in under their account and see everything with your own eyes. Debugging is much easier.

Sortable tree resource - adds the ability to create and manage tree structures with sorting function (drag-and-drop), for organizing hierarchical data such as categories or menus.

CKEditor or TinyMCE - powerful visual editors.

Language Packs - localization packages for the admin panel interface itself. Russian, Ukrainian, German, Chinese, Romanian - choose any.

The marketplace is growing. People are constantly adding new packages for different tasks. There's a monetization opportunity.

In general, the marketplace is not for show. It's a really useful thing that saves a ton of time on typical tasks. And time in development is money.

Where to Start Working with MoonShine

The answer is simple - with the documentation. We tried to make the documentation friendly for beginners and detailed. Quick start here:
https://getmoonshine.app/docs/4.x/quick-start

Development Plans: What's Next

In the near future, I'll make another panel. In addition to the sidebar, there will be an internal panel. Also, most likely nested menus will be improved so they drop not down but to the side (upd.: already added in MoonShine 4.1).

I'll continue to develop Telegram Mini App. Most likely some components in Telegram style will be added for it. Perhaps there will be a menu at the bottom with main sections to make it even more convenient to use the admin panel from the phone.

Well, I'll develop all kinds of AI integrations - this is already a mandatory tool for a modern developer.

Abundant feedback and suggestions for MoonShine development are welcome!

Conclusion

I really hope that after reading this article you'll try MoonShine in action. And that after this you won't want to use other admin panels. 😊 That's the minimum program. 😊 And perhaps you'll be so inspired that you'll donate, work with the code, or help promote MoonShine, which is especially important. Thanks for your attention! I'm waiting for you in the MoonShine chat.

MoonShine 4 Promo Video

Poor Time Management — The Official Sponsor of Your Burnout

Danil Shutsky — Fri, 13 Jun 2025 11:16:34 +0000

Friends, hello everyone!

In this article, I want to share my experience and observations on time management—how to get everything done without burning out in the vast jungle of endless tasks, projects, and communication.

I should probably start by saying that when I was employed, I didn’t have any issues with time management. My work was organized by project managers and team leads. My job was simply to show up and complete tasks from the task manager. Ah, those were the days!

But I wanted more and started forging my own path. I transitioned from employment to working for myself, and now I have multiple projects and responsibilities:

MoonShine, an open-source project where, in addition to being involved in development, I also mentor core developers, set up organizational processes, and engage with the community.
A YouTube channel that needs to be developed and maintained.
Consulting and temporary outsourced projects—what keeps me financially afloat.
And, of course, articles where I share my experience with you (writing articles, as it turns out, is a very labor-intensive process).

Juggling all these things is incredibly challenging, and it took me a long time to adapt, studying different techniques and applying them in practice. I believe everyone has their own unique work organization system that suits only them. In this article, I’ll share the core principles of my current time management system.

I’ve divided the article into small sections, each highlighting a key rule. To make reading (and later applying these techniques) more engaging, I’ll narrate from the perspective of Mowgli (a modern, fearless developer) hunting (successfully completing tasks) in the jungle (work projects).

1. Don’t Try to Hunt in Different Parts of the Jungle at Once—Otherwise, You’ll Waste Time Moving Between Them

Most of these rules are simple truths that don’t always click right away. The first rule, in my opinion, is the most important—and the hardest habit to break.

Don’t multitask! When my responsibilities across different projects started piling up, I’d switch between tasks throughout the day. I’d be recording a YouTube video, then spot a GitHub issue for MoonShine and immediately jump to that, then hop on a call, then dive into a chat discussion. In the end, these constant switches come at a high cost. By the end of the day, I’d be completely drained, lying in bed thinking, "I worked so much, but barely finished anything." It felt like I was running in place! I’d mastered the marathon of task-switching, but nothing actually got done.

The problem was clear. My solution? Divide the week into dedicated focus areas.

Monday: Ease into the week with lighter (but important) tasks—organizing tasks for other developers, communicating in chats, preparing YouTube content. Basically, administrative work that actually starts brewing on Saturday (more on that later).
Tuesday: Dedicated to recording YouTube content. If I finish early and have energy left, I’ll tackle a task from another day. If something urgent comes up, I’ll check messages—but only if I have the bandwidth.
Wednesday: Open-source day, all things MoonShine. Since MoonShine is a priority, I place it mid-week when I’m fully warmed up and ready for complex tasks. It’s a tough day but the most satisfying.
Thursday: Wrap up unfinished tasks from earlier in the week. Mornings are for family—we have a relaxed breakfast together. Thursday is a chance to catch my breath and tie up loose ends.
Friday: Creativity day—writing articles, planning next steps, and handling outsourced work.
Weekends: You’d think I’d just binge shows or stare at the ceiling, but no. I review the week, spend an hour organizing and planning (tying back to Monday), and then fully relax with family.

This structure is a game-changer. Of course, unplanned sprints, urgent projects, or looming releases sometimes force adjustments (more work, less rest). But knowing what each day holds helps me adapt—I know when to push hard and when to ease up. It’s like a workout split: leg day, back day, chest day.

2. Chew Your Prey Slowly—Better for Digestion

One of my early mistakes was rushing through tasks (probably to "earn" more rest time). I’d hurry to finish something just to move to the next problem—after all, the queue was always full!

But this often backfired: quick solutions usually meant cutting corners, leading to revisiting "finished" tasks later. If you’re lucky, someone else handles the fallout. But if it boomerangs back to you? Hello, Problem #1—more context-switching, re-adapting, and wasted energy.

So remember: Measure twice, cut once. Check everything, take your time, and only then move to the next target in the time-management jungle. Spending a little extra time upfront to nail a task means never circling back to it.

Hasten slowly!

3. The Jungle Is Hot—Don’t Forget to Rest in the Shade

This might be Rule #3, but it’s the toughest. You must learn to listen to yourself and recognize when you’re depleted—whether you need a few days off or even a full week.

The tricky part? Your brain often lies. It whispers in the morning: "Stay in bed an extra hour. Push it to tomorrow—you’re exhausted!" This is an ancient survival trick: "Conserve energy—what if predators attack tomorrow?"

But once you realize your brain can deceive you, it’s like The Boy Who Cried Wolf. We are tired, yet we keep working. Eventually, the brain resorts to extreme measures—your immune system crashes, and you’re bedridden with the flu. Now you’re forced into downtime, which leads back to Rules #1 and #2: scrambling through the jungle, half-chewed prey everywhere!

The solution? Experience. Learn to distinguish laziness from genuine fatigue. Switch to sports, friends, or family time. It’s vital for health and productivity.

4. A Good Hunter Needs Good Sleep

I won’t preach bedtimes here. Instead, let’s talk about the "brain at night" problem—when you’re solving tasks in your head until dawn, and whether you’re actually sleeping is debatable. Often, you’re just trying to remember solutions.

The fix?

Wind down 3 hours before bed.
Keep a notebook or app (like Obsidian or Notion) nearby. Dump ideas there—don’t mentally chew on them. The goal is a clear mind by bedtime.

The proverb "Morning is wiser than evening" is real. Sleep brings clarity—what seemed unsolvable yesterday often clicks effortlessly in the morning.

5. Mowgli Rules the Jungle (Because He Uses Tools)

Humans dominate the jungle not by brute strength but by using tools. Let’s talk time-management tools:

Notebooks, Google/iPhone Notes, Outlook, Trello, Evernote, Asana, Obsidian, Notion… You’ve probably tried some. I used many at once:

Quick notes in iPhone Notes (later migrated to Obsidian).
Personal tasks in Trello/TickTick.
Work tasks in JetBrains Space.
Blog drafts in Obsidian.
Calendar reminders.

Each tool has perks, but over time, this clutter became stressful—I’d waste time just finding where I noted something. Now, I’m streamlining my system around Notion and Obsidian.

Key takeaway: We’re bombarded with information. Relying on memory is futile. Use digital tools to:

Capture thoughts and notes from books/courses (A dull pencil beats a sharp memory).
Store ideas, links, and tasks—then process and organize them. No more lost ideas!

6. Deal with the Monkeys—They’ll Scare Off Your Prey

Distractions are everywhere. My arch-nemesis? Telegram. With endless chats and constant notifications, focus is impossible:

Notification pops up.
Read, ponder a reply, respond.
Lose seconds/minutes.
Reorient to the original task.
Repeat.

The fix?

Mute notifications temporarily. My phone has a 30-minute "focus mode" (only critical calls allowed).
Disable notifications on my laptop.

This creates a distraction-proof barrier—a tweaked version of the Pomodoro technique.

Time to Hunt

Time management is crucial in today’s multitasking world. As my experience shows, it demands discipline and adaptability. Simple rules can boost efficiency and prevent burnout. I hope these tips help you manage tasks better and balance work with life. Remember: Your time is your most valuable resource—only you decide how to spend it.

Do you have your own techniques? Share them in the comments!

MoonShine v3: Key Changes and New Features in the Open-Source Admin Panel for Laravel

Danil Shutsky — Sun, 09 Mar 2025 16:22:02 +0000

MoonShine is an open-source admin panel for Laravel, and on December 10, 2024, the release of MoonShine v3 took place. I have already published an article about the history of the project and discussed the new features.
In this material, I will explain what exactly has changed in MoonShine itself. We will explore improvements in installation and configuration, support for different configuration approaches, enhancements in field management, new integration opportunities with APIs, and better work with components and menus. We will also focus on new front-end capabilities through Alpine.js and the introduction of new systems such as JSON responses and OpenAPI specifications.
Let's take a closer look!

Installation

Documentation

Let's start with the installation. What has changed? Firstly, during the installation, there will be a lot more questions, allowing you to configure the admin panel according to your needs right away. Now, during the installation, you specify whether migrations and notifications are needed and which driver they will work on:

If you have installed MoonShine before and need the default configuration, you can run the installation command with the -Q option to skip the questions during installation:

php artisan moonshine:install -Q

Notifications

Previously, MoonShine used a hardcoded database driver for notifications, but now there is the ability to switch it to any other driver.

If you don't want to use database notifications and prefer, for example, broadcast or another driver, you can replace the default implementation with your own (details are in the documentation).

Let's take the Rush package as an example. In Rush, notification handling is based on WebSockets, and Rush is not tied to MoonShine. It is simply a service container that injects its notification implementation, using the broadcast driver in this case.

Configuration: Array/Object

Documentation

In MoonShine v3, two configuration approaches have been introduced to provide flexibility for different preferences: using an array and using an object.

Array-based Configuration This is the familiar Laravel-style approach, where settings are stored in the moonshine.php file.

return [
    'title' => env('MOONSHINE_TITLE', 'MoonShine'),
    'logo' => '/assets/logo.png',
    'domain' => env('MOONSHINE_DOMAIN'),
    'prefix' => 'admin',
    'auth' => [
        'enabled' => true,
        'guard' => 'moonshine',
    ],
    // …
];

Object-based Configuration This approach is implemented via the MoonShineServiceProvider.

$config
    ->title('My Application')
    ->logo('/assets/logo.png')
    ->guard('moonshine')
    ->authEnable();

The object-based approach was introduced because array-based configuration has certain drawbacks. For example, if there's a typo in the configuration (e.g., writing enable instead of enabled in the auth section), and the project has insufficient test coverage, such an error could make it to production, leaving the project running without authentication.

With the object-based approach, such errors are significantly reduced, as the code can leverage IDE autocompletion, making configuration management more convenient. For instance, you can use the authDisable method to disable authentication, making it easier to control.

Note: Object-based configuration takes higher precedence over settings in the configuration file.

In MoonShine v3, a new parameter called resource_prefix has been introduced, which affects the URL structure. By default, the URL will look like this:

/admin/resource/{resourceUri}/{pageUri}

If resource_prefix is set to an empty value, the URL will look like this:

/admin/{resourceUri}/{pageUri}

Documentation Updates

The documentation for MoonShine v3 has been completely rewritten and is now in Markdown format, hosted on its own platform. A new feature has been added to the documentation: tabs. When multiple approaches are available (e.g., for configuration), you can easily compare how to achieve the same task using the Config approach versus the Provider approach.

Documentation in MoonShine v3 Has Improved Significantly. Here’s What I’d Like to Highlight:

More Examples
Every section of the documentation now includes detailed code examples. Whether it's configuring the menu, working with tables, or adding assets, you can quickly implement these features by copying and adapting the provided examples.
Recipes for Common Tasks
The documentation now features recipes — ready-made solutions for common tasks. This saves time and helps users better understand the system.

For example:

How to implement asynchronous deletion of an item on button click in the background.
Saving site settings via the Dashboard.

English Out of the Box

If you need another localization, you can install the required package from the marketplace. Currently, Russian, Ukrainian, German, and recently added Chinese localizations are available. There are also other localization packages, but some of them have not yet been updated for version 3.

Layout

Documentation
In MoonShine v3, the layout system has been completely revamped. It has become more flexible and developer-friendly, allowing for easy customization of the appearance and behavior of the admin panel. Let's break down the key changes and benefits.

The layout system from MoonShine v2 has been entirely removed. Instead, a new, more flexible and modular system has been introduced, which allows you to easily override the layout on any page.

Default Layout

By default, the layout is set in the MoonShine configuration. However, you can now override it for any page, making the system more flexible:

namespace App\MoonShine\Layouts;

use App\MoonShine\Resources\PackageCategoryResource;
use App\MoonShine\Resources\PackageResource;
use App\MoonShine\Resources\UserResource;
use MoonShine\ColorManager\ColorManager;
use MoonShine\Contracts\ColorManager\ColorManagerContract;
use MoonShine\Laravel\Components\Layout\{Locales, Notifications, Profile, Search};
use MoonShine\Laravel\Layouts\CompactLayout;
use MoonShine\MenuManager\MenuGroup;
use MoonShine\MenuManager\MenuItem;
use MoonShine\UI\Components\{Breadcrumbs,
    Components,
    Layout\Assets,
    Layout\Div,
    Layout\Body,
    Layout\Burger,
    Layout\Content,
    Layout\Favicon,
    Layout\Flash,
    Layout\Footer,
    Layout\Head,
    Layout\Header,
    Layout\Html,
    Layout\Layout,
    Layout\Logo,
    Layout\Menu,
    Layout\Meta,
    Layout\Sidebar,
    Layout\ThemeSwitcher,
    Layout\Wrapper,
    When}; 

final class MoonShineLayout extends CompactLayout
{
    public function build(): Layout
    {
        return Layout::make([
            Html::make([
                Head::make([
                    Meta::make()->customAttributes([
                        'name' => 'csrf-token',
                        'content' => csrf_token(),
                    ]),
                    Favicon::make()->bodyColor($this->getColorManager()->get('body')),
                    Assets::make(),
                ])
                    ->bodyColor($this->getColorManager()->get('body'))
                    ->title($this->getPage()->getTitle()),
                Body::make([
                    Wrapper::make([
                        Sidebar::make([
                            Div::make([
                                Div::make([
                                    Logo::make(
                                        $this->getHomeUrl(),
                                        $this->getLogo(),
                                        $this->getLogo(small: true),
                                    )->minimized(),
                                ])->class('menu-heading-logo'),

                                Div::make([
                                    Div::make([
                                        ThemeSwitcher::make(),
                                    ])->class('menu-heading-mode'),

                                    Div::make([
                                        Burger::make(),
                                    ])->class('menu-heading-burger'),
                                ])->class('menu-heading-actions'),
                            ])->class('menu-heading'),

                            Div::make([
                                Menu::make(),
                                When::make(
                                    fn(): bool => $this->isAuthEnabled(),
                                    static fn(): array => [Profile::make(withBorder: true)],
                                ),
                            ])->customAttributes([
                                'class' => 'menu',
                                ':class' => "asideMenuOpen && '_is-opened'",
                            ]),
                        ])->collapsed(),

                        Div::make([
                            Flash::make(),
                            Header::make([
                                Breadcrumbs::make($this->getPage()->getBreadcrumbs())->prepend(
                                    $this->getHomeUrl(),
                                    icon: 'home',
                                ),
                                Search::make(),
                                When::make(
                                    fn(): bool => $this->isUseNotifications(),
                                    static fn(): array => [Notifications::make()],
                                ),
                                Locales::make(),
                            ]),

                            Content::make([
                                Components::make(
                                    $this->getPage()->getComponents(),
                                ),
                            ]),

                            Footer::make()
                                ->copyright(static fn(): string
                                    => sprintf(
                                    <<<'HTML'
                                        © 2021-%d Made with ❤️ by                                      
                                            CutCode                                        
                                        HTML,
                                    now()->year,
                                ))
                                ->menu([
                                    'https:                                ]),
                        ])->class('layout-page'),
                    ]),
                ])->class('theme-minimalistic'),
            ])
                ->customAttributes([
                    'lang' => $this->getHeadLang(),
                ])
                ->withAlpineJs()
                ->withThemes(),
        ]);
    }
}

MoonShine v3 is a full-fledged UI kit, and you can use its components anywhere. Here’s an example of a Blade template:

<x-moonshine::layout>
   <x-moonshine::layout.html :with-alpine-js="true" :with-themes="true">
       <x-moonshine::layout.head>
           <x-moonshine::layout.meta name="csrf-token" :content="csrf_token()"/>
           <x-moonshine::layout.favicon />
           <x-moonshine::layout.assets>
               @vite([
                   'resources/css/main.css',
                   'resources/js/app.js',
               ], 'vendor/moonshine')
           </x-moonshine::layout.assets>
       </x-moonshine::layout.head>

       <x-moonshine::layout.body>
           <x-moonshine::layout.wrapper>
               <x-moonshine::layout.sidebar :collapsed="true">
                   <x-moonshine::layout.div class="menu-heading">
                       <x-moonshine::layout.div class="menu-heading-logo">
                           <x-moonshine::layout.logo href="/" logo="/logo.png" :minimized="true"/>
                       </x-moonshine::layout.div>

                       <x-moonshine::layout.div class="menu-heading-actions">
                           <x-moonshine::layout.div class="menu-heading-mode">
                               <x-moonshine::layout.theme-switcher/>
                           </x-moonshine::layout.div>
                           <x-moonshine::layout.div class="menu-heading-burger">
                               <x-moonshine::layout.burger/>
                           </x-moonshine::layout.div>
                       </x-moonshine::layout.div>

                   </x-moonshine::layout.div>

                   <x-moonshine::layout.div class="menu" ::class="asideMenuOpen && '_is-opened'">
                       <x-moonshine::layout.menu :elements="[['label' => 'Dashboard', 'url' => '/'], ['label' => 'Section', 'url' => '/section']]"/>
                   </x-moonshine::layout.div>

               </x-moonshine::layout.sidebar>

               <x-moonshine::layout.div class="layout-page">

                   <x-moonshine::layout.header>
                       <x-moonshine::breadcrumbs :items="['#' => 'Home']"/>
                       <x-moonshine::layout.search placeholder="Search" />
                       <x-moonshine::layout.locales :locales="collect()"/>
                   </x-moonshine::layout.header>

                   <x-moonshine::layout.content>
                       <article class="article">
                           Ваш контент
                       </article>
                   </x-moonshine::layout.content>

               </x-moonshine::layout.div>
           </x-moonshine::layout.wrapper>
       </x-moonshine::layout.body>
   </x-moonshine::layout.html>
</x-moonshine::layout>

Themes

Instead of manually specifying colors and classes for theme switching (as was the case in version 2), now it’s enough to specify which Layout to use. For example, you can choose CompactLayout or AppLayout. In the future, adding new themes (e.g., BatmanLayout) will be just as simple — you only need to specify its name.

final class MyLayout extends AppLayout

final class MyLayout extends CompactLayout

Integration of Menu, Assets, and Colors

With the new Layout system, not only visual elements are tied to it, but also the menu, assets, colors, and a set of components. This allows for centralized management of all aspects of the admin panel.

Unlike version 2, where menus and other elements had to be overridden via callback functions inside the Service Provider, now everything is in one place. This simplifies development and makes the code more readable.

Provider as Configuration

In the new system, the Provider is used solely for configuration. You declare the settings, and that’s it — no extra callback functions or complex overrides.

This is especially convenient when you need to create a unique Layout for a specific page or section of the admin panel.

Imagine This: every page of your admin panel can, if desired, have its own template, complete with its own menu, set of assets, and a custom order and list of components. This level of flexibility allows for highly tailored and dynamic admin interfaces.

class CustomPage extends Page
{
   protected ?string $layout = AppLayout::class;

   // ...
}

Components

With the release of MoonShine v3, the number of components has significantly increased, thanks to the new Layout system. Now, each Layout is not just a configuration of the sidebar or topbar, but a full-fledged page customization. You can change any element, starting from the tag, to setting a Favicon or connecting assets for each page individually. All of this is done through classes, without the need to move files into Blade, which simplifies the process and makes it more flexible.

While this approach might seem a bit unusual at first, it opens up endless possibilities for interface customization. Each Layout can have its own design, eliminating the need to use Blade templates for customizations and making the process convenient and intuitive.

Creating a new Layout is simple: you create a template, and during the setup, you’ll be prompted to make it the default. If you agree, this template will automatically be set as the main one in the configuration. Each Layout can have its own assets, and the sidebar and topbar panels can be quickly configured: they can be enabled or disabled as needed, or both can be used simultaneously.

public function build(): Layout
{
   return Layout::make([
       Html::make([
           $this->getHeadComponent(),
           Body::make([
               Wrapper::make([
                   // $this->getTopBarComponent(),
                   $this->getSidebarComponent(),

Key Innovations

Unlimited Menu Nesting
The menu now supports unlimited nesting levels. No matter how many levels you create, the system will handle and display them correctly.
Full Customization of Menu Elements
If you need to replace standard elements, such as the ActionButton, with something completely different, it’s now possible. You can create your own custom view and use it instead of the default elements.
Integration with Packages and Service Providers
If you develop Laravel packages, you can use service providers and the boot method, which supports Dependency Injection (DI). This allows you to inject core components from MoonShine, such as AssetManager or MenuManager, and configure them globally. For example, you can add menu items for all users directly from your package.
Unique Menu for Each Page
Each page can now have its own Layout, and therefore, a unique menu. This allows you to create specialized navigation for different sections, making the interface more intuitive and adaptive.

Icons

Documentation

Basic Icon Setup Icons can now be specified in a simplified format. For example, to add an icon to a button, you only need to specify its name, such as "users". This works the same as before, but now without the need to use the heroicons prefix:

->icon('cog')

However, the real breakthrough in working with icons in MoonShine comes with the MetaStorm plugin for PHPStorm, which provides autocomplete for all system icons:

This allows you to quickly find and insert the desired icons, saving time and simplifying the development process. Special thanks to Dmitry Derepko, the author of this amazing plugin, which has already been highly appreciated by all MoonShine users. Working with icons is just the tip of the iceberg.

Custom Icon Mode You can now use custom icons, including SVGs, via the custom mode. This is especially useful if you want to use icons from third-party packages, such as Blade Icons, or load your own. You can specify the path to the directory with icons so that they are loaded from your project, not from the MoonShine vendor.

->icon(
    svg('path-to-icon-pack')->toHtml(),
    custom: true
)

Using Icon Packages You can use packages like Blade Icons, which provide convenient helpers for working with SVGs. This makes it easy to connect icons from such packages and display them in the interface. There is also a package by JeRabix for integrating the Iconify service (200,000 Open Source icons).

Asset Manager

Documentation

The Asset Manager has been significantly redesigned, becoming a more flexible and powerful tool for managing assets (CSS, JS, and other resources).

Now, the Asset Manager allows you to easily connect and use CSS and JS files. The link and script tags support attributes like defer, as well as "sugar" for simplifying their addition. This makes the process of connecting assets faster and more convenient, minimizing the amount of code.

use MoonShine\AssetManager\Js;

Js::make('/js/app.js');
Js::make('/js/app.js')->defer();
Js::make('/js/app.js')->customAttributes([
    'data-module' => 'main'
]);

Added the ability to embed JS and CSS directly into the code (inline), which is useful for small code snippets that do not require a separate file. You can also now add arbitrary HTML code, such as meta tags or custom links, expanding customization possibilities.

InlineJs::make(<<<'JS'
   document.addEventListener("DOMContentLoaded", function() {
       console.log("Loaded");
   });
JS);

use MoonShine\AssetManager\Raw;
Raw::make('<link rel="preconnect" href="https://fonts.googleapis.com">');

The Asset Manager has become more flexible: assets can be added, modified, and their priorities managed through the add, prepend, and the new modifyAssets methods. The latter allows, for example, adding or removing GET parameters, which is useful for fine-tuning in complex projects.

$assetManager->modifyAssets(function($assets) {
    return array_filter($assets, function($asset) {
        return !str_contains($asset->getLink(), 'remove-this');
    });
});

Integration with DI (Dependency Injection) allows the Asset Manager to be used anywhere in the application, including service providers and packages. This makes it universal and convenient for modular development.

For local asset management, the assets method and the onLoad hook have been added, which load assets only for the active resource or page. This optimizes performance, as resources are loaded only where they are actually needed. You can also set conditions for loading, for example, only for form or edit pages, making the Asset Manager more adaptive.

use MoonShine\AssetManager\Css;
use MoonShine\AssetManager\Js;

protected function onLoad(): void
{
    parent::onLoad();

    $this->getAssetManager()
        ->add(Css::make('/css/app.css'))
        ->append(Js::make('/js/app.js'));
}

Added support for asset versioning, which simplifies cache management and updates. This is especially important for projects where resources change frequently, as it helps avoid issues with outdated file versions.

Color Manager

Documentation

The Color Manager allows you to easily manage the color scheme of your application. It can customize the interface to suit your needs.

The Color Manager is integrated into the system in such a way that it can be used both through DI and directly in the Layout. This makes it a universal tool that can be applied anywhere in your application. For example, if you need to change the color of a button or another interface element, you can easily do so through the Color Manager.

You can set custom colors for various elements, such as buttons, text, or backgrounds, and they will be applied globally. For example, if you want to change the primary color, just set a new value, and all elements using this color will automatically update. This is especially convenient if you want to quickly adapt the interface to a new design or brand.

$colorManager->primary('120, 67, 233');
$colorManager->secondary('236, 65, 118');
$colorManager->successBg('0, 170, 0');
$colorManager->successText('255, 255, 255');
$colorManager->warningBg('255, 220, 42');
$colorManager->warningText('139, 116, 0');
$colorManager->errorBg('224, 45, 45');
$colorManager->errorText('255, 255, 255');
$colorManager->infoBg('0, 121, 255');
$colorManager->infoText('255, 255, 255');

The Color Manager also supports default color settings. This means you can set a base color scheme that will be used throughout the application, but easily override it for individual elements if needed. For example, you can change the button color on just one page without affecting the rest of the application.

Model Resource

Documentation

The Model Resource has become more flexible and user-friendly.

Simplified Base Structure

The basics of working with resources remain the same: fields, tables, and basic methods. However, some features, such as import-export, have been moved to separate packages to avoid overloading the core system. This has made MoonShine more lightweight and modular.

TinyMCE and Markdown Fields

Fields like TinyMCE and Markdown have also been moved to separate packages. This allows developers to connect only the features they actually need in their project. The documentation provides detailed instructions on how to install and use these fields, making the process quick and convenient.

Changes in Button and Action Confirmation Handling

In version 3, the mechanism for handling buttons requiring action confirmation has been redesigned. Previously, clicking a button would immediately send a request, and then a confirmation window would open. This was inconvenient and illogical. Now, the request is sent only after confirmation, making the process more predictable and user-friendly.

updateOnPreview Method

Allows editing a specific field directly in the table (quick field editing). However, now if the connection to the server is lost, the system throws an error, preventing data loss. Also added is the ability to lock editing (using a "lock" icon) to prevent accidental changes.

updateInPopover Method

Another option for editing a specific field directly in the table — in a modal window. This is especially useful if the data in the table takes up a lot of space or requires more complex editing. After changes, the data is automatically updated in the table. This is convenient.

Validation When Updating Data

Previously, the updateOnPreview and updateInPopover methods did not take into account the validation rules set in the resource. Now, validation is performed automatically, preventing the saving of incorrect data.

Flexibility in Working with Tables

In version 3, the ability to customize tables at the resource level has been added. Now you can easily add or modify elements in thead, tbody, and tfoot. For example, you can add additional rows or cells.

Removal of the TD Component

The TD component has been removed, as its functionality is now fully covered by the customWrapperAttributes method, which can add attributes for a cell directly from the field.

Text::make('Title')
   ->customWrapperAttributes(['style' => 'width: 200px;'])

stackFields Field

Allows grouping fields in one table cell, taking into account the data context. For example, depending on the data value, different fields or components can be displayed.

StackFields::make('Stack')->fields(fn(StackFields $ctx) => $ctx->getData()?->getOriginal()->id === 3 ? [
    Date::make(__('moonshine::ui.resource.created_at'), 'created_at')
        ->format("d.m.Y")
        ->sortable(),
] : [
    Date::make(__('moonshine::ui.resource.created_at'), 'created_at')
        ->format("d.m.Y")
        ->sortable(),
    LineBreak::make(),
    Email::make(__('moonshine::ui.resource.email'), 'email')
        ->sortable(),
])

Fields

Documentation

MoonShine 3 has significantly reworked the field system while retaining the core concepts. In particular, the dynamic display of fields using showWhen has been completely rewritten.

Previously, showWhen simply hid fields, but the data continued to be sent in the request. Now, by default, hidden fields are not sent with the request, avoiding redundant data. If you need the old behavior and want to keep hidden fields in the request, you can specify this setting in the config.

Additionally, a new field has been added — RelationRepeater. Previously, the logic was built into JSON, making it cumbersome and cluttered. Now, the logic has been moved to a separate RelationRepeater field, simplifying the structure and improving code readability. Now, if you need to display HasMany relationships in the main form, you can use RelationRepeater. This field simplifies working with relationships, allowing them to be displayed in tabs or other parts of the form.

In MoonShine 3, you can now easily display relationships like HasMany and HasOne in various formats, including tabs. This is especially useful when you need to compactly and conveniently display related data. Here’s one of the recipes for demonstration.

There is also the ability to display HasMany or HasOne in one tab and use TableBuilder in another to beautifully present the data in a table. The interface has become more user-friendly — working with large volumes of related data has become easier.

CRUD Resource

MoonShine 3 now supports CRUD resources, opening new possibilities for working with data via API. In particular, you can use an external API to fetch and display data and perform CRUD operations on them.

When the page loads, data is fetched via API, and even if the API is slow, the page itself loads instantly thanks to the use of lazy load mode. This allows the page to be displayed immediately, with data being loaded as needed, significantly improving the user experience.

You can configure this behavior using the lazy property, which is enabled in the config. After that, pages will load quickly, and API requests will be executed in the background. This is perfect for working with large volumes of data and external services.

As for configuration, MoonShine provides many default pages (e.g., dashboard, profile, error pages, and login). These pages can be easily overridden to suit your needs. The moonshine:publish command allows you to quickly publish all necessary pages and forms. Everything is designed to simplify setup and reduce routine work: you don’t need to start from scratch, just adapt the ready-made components to your tasks.

With this approach, working with CRUD resources becomes not only convenient but also fast, while giving you full control over the appearance and functionality of the pages.

JS

Documentation

In MoonShine 3, the documentation section for working with JavaScript has become much more convenient and functional. Now, if you work with the frontend, you don’t need to figure out how to write class components from scratch — all the details are explained directly in the documentation.

In particular, you can use Alpine.js to create components, simplifying frontend integration. Components are initialized via the x-data directive, and you only need to specify the component name. This allows you to easily manage the state and behavior of components, with all assets being connected through the Asset Manager.

The documentation provides a complete description of all events that can be interacted with via JavaScript, so even a developer with little JS experience can correctly call events and work with them.

SD UI

Documentation

MoonShine 3 introduces an interesting ability to switch the system to JSON response mode, opening new horizons for integration with other platforms. In this mode, MoonShine will send data in JSON format, where each component is represented as an object with its state, type, and other parameters. This is perfect for integrating MoonShine with mobile applications or other frontend solutions.

For example, using this approach, you can create a Flutter app that receives MoonShine components in JSON format. This allows you to modify components on the fly without needing to rebuild the app. This approach also simplifies the creation of custom frontends, where you don’t need to compile each page, but can work with components received via API.

To use this functionality, you need to send a specific header and receive a structure that includes all the components of the page, such as the Dashboard. You will be able to see which components are used, their internal state, and disable some of them or change the display of only the layout if necessary.

This is a great opportunity for developers who want to integrate MoonShine with other systems or build complex frontend solutions on top of it. If anyone is interested in implementing such solutions, I would be happy to help bring this functionality out of beta and further refine it.

API

Documentation

Allows you to switch the admin panel to JSON response mode, enabling integration with other systems via API. In this mode, all data and interactions occur in JSON format, allowing you to work with MoonShine as an API platform.

Also added is a package for generating OpenAPI specifications. With it, you can easily generate documentation for your API. The process is the same as when creating resources in MoonShine: you create the necessary resources, generate the specification, and get documentation that will be available via Swagger UI. All of this is simple to set up and use.

Authentication

Documentation

One of the interesting features is the support for auth pipelines. This mechanism is used for additional data processing, for example, after a user fills out and submits a form. During authentication or data validation, additional modifications or checks can be performed, depending on the settings.

In Conclusion

This is only a part of the innovations introduced in MoonShine v3. As you can see, many improvements have been made to the admin panel, along with new functionality. The article turned out to be quite long, and I’ve only covered the main changes. To describe all the innovations, it would probably take more than one article. MoonShine is evolving almost every day, and new features may have been added while you were reading this article.

Also, I invite you to check out the documentation, which has become much better and more user-friendly.

If you have any questions or suggestions, you can always discuss them in the chat, where active work is underway to fix bugs and improve functionality: MoonShine Telegram Chat

I’m currently working on a comprehensive video guide for MoonShine v3, which will help you dive deeper into the system and use its capabilities to the fullest. Videos are being added to this playlist, which will be regularly updated, so don’t forget to subscribe to the YouTube channel.

Link to the GitHub repository where you can leave stars:

MoonShine GitHub

That’s all for now! Wishing you all the best! Use MoonShine in your projects and be happy!

Release of MoonShine v3. History and Innovations

Danil Shutsky — Sat, 22 Feb 2025 11:00:18 +0000

Hello, colleagues!

I am Danil Shchutsky (CutCode), and for over two years, I have been working on an open-source admin panel for Laravel — MoonShine.

On December 10, 2024, the release of MoonShine v3 took place. In this article, I wanted to share the work done and the main innovations in the project.

So, MoonShine v3 is:

A completely new architecture
No binding to Eloquent ORM and Laravel
Documentation on its own platform in MD format
And many other features

Let me elaborate.

The Journey to MoonShine v3

It was incredibly challenging. Thirteen months of work, with the last six months (or even more) being super-intensive development.

You could say that for the past few months, I’ve been living and breathing this third release of MoonShine. I would fall asleep turning over tasks in my head, wake up either with immediate answers and rush to implement them, or continue facing challenges to make MoonShine exactly the way I envisioned it.

Did I achieve what I wanted by the release of version three? Well, I had to slightly reduce the initially planned functionality and move some of it to the next, fourth release.

It might seem like now is the time for me to take a breather. The release of MoonShine v3 is ready, but... I think the near future will be filled with active feedback: helping with documentation, identifying issues, and addressing inconveniences.

As for guides — they will definitely come. There will be plenty of them, for both beginners and experienced users. If you have any suggestions for guide topics, feel free to propose them in the comments.

MoonShine 3 has grown significantly. By my estimates, it’s about 10 times larger compared to v2.

For me, MoonShine is not just code. Right now, it’s the main focus of my life. In this article, I want to show you the history of MoonShine’s development. You might already be working on open-source projects or planning to do so. There are pros and cons. It’s exhausting, it’s not easy, but I believe that the pros still outweigh the cons.

History of MoonShine Releases

MoonShine v1

Let’s start with the first version. Here’s what MoonShine looked like when it first appeared:

Back then, it wasn’t called MoonShine, but Laravel Admin Panel. There was no MoonShine yet.

Let me remind you that the initial idea came from the CutCode Laravel chat, where the guys said: “Let’s come up with our own open-source project. It’s cool, we’ll work on it together!”

And in this form, I presented it on my YouTube channel: “Guys, here’s our shared open-source project. Let’s do it! Everything you wanted.”

The logo was also different back then — I drew it myself. And here’s what the login page looked like. It was... well, let’s just say it was an eyesore.

At that time, I had just discovered Nova for the first time. I was reading its documentation and thinking: “This is so cool! All these fields (Field), how interestingly everything is implemented!” Inspired by the documentation, I recreated my own version. At some point, I also looked at Filament, borrowed some ideas, and that also influenced me.
As for MoonShine v3, it’s now a completely unique product. There’s nothing borrowed here anymore. I’ve come to the realization that it’s important to follow your own path.

In March 2022, I met Alexander, who created the logo for us:

We moved to a separate repository. Why did I do this? To ensure that the project wasn’t tied to my personal GitHub account. If this is a community-driven project, it would be strange for it to be under the authorship of a single vendor. So, I created a separate GitHub account — MoonShine Software, set up the MoonShine repository there, and on May 12, 2022, we migrated everything to it (this can be considered the official birthday of MoonShine).

After several months of working together with Alexander, on June 8, 2022, we got another contributor — nikitaMai. This likely influenced how MoonShine developed further. It was a turning point when I saw people in chats actually using MoonShine. That alone was enough motivation for me to keep working on it.

Alexander started using MoonShine in commercial projects. However, the design was such that it couldn’t be shown to serious clients. We decided to commission a new design.

By mid-June 2022, we released version 1.50 — with a new design, the one you see now. We gained contributors, and progress started to pick up. The new design was great, but under the hood, everything remained the same. Only the Blade views were updated. Visually, it looked better, but internally, it still had legacy artifacts from version 0.9, which was essentially cobbled together.

But that’s the whole point of our open-source project, MoonShine — to give everyone a chance to contribute: both experienced developers and those who have just read my book, Laravel Ninja Guide, and want to join the project.

By the way, there’s another point. Sasha and I had the idea to make version 2.0 modular. That is, the backend and frontend would be two separate projects, completely isolated. This way, if someone wanted, they could write their own frontend using anything they liked, or keep the frontend and write their own backend. However, this idea remains unrealized for now.

MoonShine v2

So, MoonShine v1 had significant issues with the code, and the release of v2 was meant to address them. In addition to refactoring the code, new challenges emerged. One of them was the task of decoupling from Eloquent ORM. This was probably the main goal for version 2.0 — to create an admin panel that wasn’t hardwired to Eloquent.

And in MoonShine v2, we achieved that. The development process was very exciting. The first cohort of my online course, Internet Store, had just finished, where I met some amazing people. At the time, they might not have been seasoned experts, but when they joined MoonShine and started contributing, they grew into skilled developers.

We started communicating, they liked the idea of MoonShine, and we began working on the second version. First, I created the core, shaping the concept as I envisioned it. Then, starting in August 2022, I brought the others on board. It felt like an avalanche — incredibly intense. We were working like crazy.

Another Alexander joined us, focusing on documentation, but he also did a lot of frontend work. Pull requests from him were pouring in. Plus, there was Ivan, the creator of the new MoonShine Rush package and many features. He, too, was submitting pull requests non-stop. Features like ShowWhen (which allows dynamically controlling the visibility of fields based on the values of other fields, enabling real-time hiding or showing of fields without page reloads) and OnlyLink (used to display a link without the ability to edit, allowing you to show users specific data as a link but preventing them from changing its value) were all Ivan’s work.
During the development of the second version, I felt like Taylor Otwell, reviewing pull requests, helping the team, and giving advice. That’s how MoonShine v2 came to be. However, it didn’t turn out exactly as I had initially planned, and some features were moved to the roadmap for future work.

A special note about the MoonShine documentation — it’s incredibly challenging and crucial work. In fact, writing documentation is often much harder than writing the code itself. Sasha wrote the majority of the documentation for MoonShine v2.

Okay, so MoonShine v2 was ready by November 2023. And I thought: If things are this intense now, what will happen by the release of 3.0?! Probably even more developers will join. The documentation will probably flow like butter!

MoonShine v3

The main goal for v3 was to achieve some level of isolation from Laravel. The idea was to create a monorepo where everything would be split into separate packages: Laravel as a standalone package, AssetManager, MenuManager, UI, and so on. Overall, we can say that MoonShine was decoupled from Laravel, but there are still some dependencies on collections and contracts.

I’ve already experimented with implementing MoonShine on Symfony. Now that Yii3 is coming out, why not try integrating MoonShine with it? However, I’m a proponent of separating the main site and the admin panel — deploying MoonShine+Laravel on a subdomain.

I’ll leave a small spoiler: after the release of v3, I’ll show you an interesting feature of MoonShine v3 that will completely change the way people think about admin panels. The frameworks and programming languages used for projects won’t matter as much anymore.

From November 2023 to May 2024, I collected feedback from users and solidified my thoughts on what v3 should look like. The plan for the MoonShine v3 release was as follows:

May: Create the concept.
June-July: Bring in the rest of the team to polish the code and documentation.
By October: Finish the work. But things didn’t go according to plan. This is where the downsides of open-source come into play, which we’ll talk about now.

There was a lot of work ahead. MoonShine v3 is a completely rewritten admin panel. In May, we held the MoonShine Dev Camp. There were 11 active MoonShine developers, and I shared information about what MoonShine would become, showed the concept, and thought that this core team would grow and continue working.

However, by June, nothing was happening — not even from the core developers. July and August were the same. I was working on MoonShine all day, every day, but no one else was joining in.
Around August, Ivan started contributing. He worked on ShowWhen(), completely upgrading it, and submitted a few other small pull requests.
By September, the coding work was mostly finished, and it was time to move on to the documentation. We were already more than a month behind schedule.

Documentation and PHPStan

Sasha didn’t have enough time to work on the documentation, even though he was our main hope for it. With no other options, I had to take on the documentation myself. I also formed a group of volunteers who offered to help with the documentation, but progress was slow. In the end, I think I wrote about 90% of the documentation myself.

Realizing that we wouldn’t meet the November 1 deadline, I had to push the release to December 10.

In parallel, a frontend developer I knew was working on the platform for the documentation and making adjustments to the admin panel itself. Due to the tight deadlines, we had to reduce the number of frontend tasks by about 50%.

The last week before the release was especially intense. On December 9, Ivan and I did a final sprint to complete the documentation and close the main sections.

A lot of time was spent on the documentation, but we didn’t fully finish it! I think the MoonShine documentation is now even larger than Laravel’s.

But there’s still a lot of work to be done on the documentation, and it might never truly be finished. So, I invite everyone to get involved, contribute, and write. I’d be very grateful.

The Recipes section got a second wind. The number of recipes has grown, and they’re regularly updated and expanded. Now, thanks to the Markdown format, the process of creating and formatting documentation is simpler and faster.

Another thing about the documentation: it’s completely migrated to Markdown. We have our own platform that parses it and makes it look stylish. At first, I didn’t want to write my own solution and considered ready-made options like Mintlify, Docusaurus, GitBook, and others. But each had its drawbacks, such as issues with versioning or language support. Many assume that only English exists and don’t bother with multilingual support. In the end, I had to write our own platform, which took a lot of effort, but I’m very happy with the result. Now we can do whatever we want with it.

What else has changed in terms of code?

In addition to regular tests, we now have mutation tests. PHPStan has leveled up: it was at level 1, and now it’s at level 5. I plan to increase this further. Overall, the entry barrier for contributors has risen.

MoonShine 3, in my opinion, has become more complex for users. By that, I mean it will take some getting used to. Previously, all fields were in the fields method, and we separated them internally using additional methods like showOn/hideOn to control which fields appeared on the list page or the form. This created a bit of a mess. In version 3, everything is moved to separate methods, and the showOn/hideOn field methods have been removed.

Domain

By the way, regarding the domain moonshine-laravel.com. At first, it seemed like a great idea to have the connection to Laravel right in the domain name. Laravel is the most popular PHP framework, and the admin panel was built on it. But with MoonShine v3, things are changing, and the admin panel is outgrowing Laravel. So, we’ve decided to acquire another domain: https://getmoonshine.app.

Different Approaches

What I love about MoonShine v3 is the flexibility to use different approaches. Do you prefer configs the way you’re used to in Laravel? Go ahead, use them. Want to work with objects? No problem, we have a config object with a fluent interface.

Everything is designed for developer convenience. However, we still have a weak spot — the MoonShine/Laravel package. There are still some helpers there, but in the future, we’ll remove them to rely solely on dependency injection.

Now everything is simpler: we’ve introduced configuration injection. No resources, no menu in the provider — everything is flexible and straightforward.

MoonShine Changes the Way We Think About Admin Panels

How does admin panel generation usually go for a project? It’s routine. At least, it always was for me: either I wrote some custom solution (which was very sad) or used a ready-made tool and quickly generated it. I didn’t like any of it. The goal was just to make it work, get the client to accept it, finish quickly, and forget about it like a bad dream.

With MoonShine, it’s a different story. I genuinely enjoy it. For me, creating an admin panel is now an exciting activity. Writing an admin panel in MoonShine is like assembling a constructor. I love building constructors — I even recently bought myself a big car constructor and spent a week assembling it, getting a lot of joy out of it. It takes time, but you enjoy the process. The same goes for MoonShine: you assemble this constructor, enjoy the process, try to make things cleaner, and come up with new solutions. It’s an amazing feeling.

This is exactly the atmosphere I was aiming for — where MoonShine isn’t just a tool for quick generation, but something that brings developers joy and makes them happier.

Community

It’s clear to everyone that MoonShine v3 is an awesome admin panel 😉. But without a community, it’s nothing. Without promotion, it won’t take off. We need to promote the product, write guides, articles, and engage with people. It’s important that people embrace the "MoonShine religion" and spread the word about how great it is. We pour our hearts into it. Right now, it’s my life.

Someone once said that they spent three months building a simple admin panel, but when they tried MoonShine, they created the same thing in just a few days! We strive to make developers happier, even if it leaves us a bit more tired 😎. When you write words of gratitude, it’s incredibly motivating.

I think there are still many challenges ahead. Don’t think that the release of version 3 is the end. There’s still a lot of work to be done.
If you notice errors in the documentation or code, even funny ones, please don’t stay silent. Mention it in the chat, or even better — create an issue. We understand that mistakes happen, but we strive for perfection and are ready to fix them.

Sometimes people write to me: “Oh, I didn’t do much. I just added a comma in the documentation or fixed a doc block in the code. Just a small thing.” But for me, such PRs are incredibly valuable. When you’re focused on complex challenges or core issues, these small details often go unnoticed, so even minor contributions are very important!

Upgrading from MoonShine v2 to v3

The documentation includes a text guide for upgrading from version 2 to version 3. It was written by a community member who updated their own project. There are some points that, in my opinion, might not have been necessary to include, like how to back up the old config to keep it handy. Nevertheless, they described even these small details, as well as what might happen during the upgrade process. Another developer suggested creating a ready-made upgrade script, but they never finished it, probably due to lack of time or motivation.

Ivan updated our demo projects. We have three of them, and he updated all of them in a day. One of the demo projects is quite large, so I don’t think upgrading should be a problem unless your project is very complex.
I also recorded a video guide on upgrading — it’s available on YouTube.

Comparison with Filament

People often ask about comparisons with Filament. My opinion: Filament is a super lightweight tool with a low entry barrier, full of "sugar." MoonShine, on the other hand, is designed for more complex tasks, requires development skills, and doesn’t limit the developer but allows them to build an admin panel faster. Yes, working with MoonShine is probably harder than with Filament, but it’s worth it. However, I haven’t forgotten about beginners, and basic functions like CRUD and UI customization are made as simple as possible.

MoonShine — simple for beginners, limitless for professionals.
But I do plan to create a detailed comparison of Laravel admin panels.

Marketplace Moonshine

One more new feature that came with the third version of MoonShine is the Marketplace. What is it? It’s a place where developers can publish their packages. Of course, we’ll moderate the content to ensure that unnecessary or duplicate solutions don’t appear there. But if you have something interesting, you can create a package and publish it here. It can be either free or paid. The Marketplace is designed to motivate developers to create useful solutions. If you want to write (or have already written) a useful extension for MoonShine, you can message me directly, and we’ll discuss the details.

In commercial projects, development speed is crucial — so ready-made solutions (including paid ones) will be in demand. Paying for ready-made functionality is justified, especially if it saves time and generates income.

In the end, everyone wins, especially the developer using MoonShine.
There’s already a first paid package from MoonShine — Rush. It’s a ready-made integration for web sockets. It supports all popular web socket drivers: Echo, Centrifugo, Socket.io, and even custom solutions. I’ll record a separate video to explain Rush in more detail — it’s a massive package that allows you to easily create "live forms" in MoonShine. You’ll see who is editing a form, which field they’re editing, and you can lock editing to prevent simultaneous changes to a record. Dynamic metrics and values — a lot of useful features for building a truly functional admin panel.

A Few Words About New Features

MoonShine is gradually gaining new capabilities. Now, not only admin panels and MVPs but also personal accounts can be built on MoonShine. Here’s a brief overview of the new features:

Separate layouts: For example, registration, password recovery, and profile pages now have their own layouts, allowing you to adapt pages for specific tasks.
Decorations are now called components: This simplifies understanding MoonShine’s structure. Fields, which were previously isolated, are now also treated as components, making them more integrated into the overall process.
CRUD resource in version 3.0: Now you can use the CRUD resource interface to fully implement your solution or use a ready-made abstraction. This significantly simplifies working with REST API. Tables support lazy loading, minimizing server load.
MoonShine Builder: A package by Ivan that automatically generates resources based on the database structure. It simplifies the process of creating an admin panel and saves time.

Conclusion

This turned out to be a lengthy article, where I focused more on the history of MoonShine v3’s release and the project’s innovations as a whole. Soon, I’ll write another article where I’ll go into detail about the capabilities of the new version of the admin panel.
Thank you for your attention. Use MoonShine and be happy! ❤️

https://getmoonshine.app
https://github.com/moonshine-software/moonshine
https://t.me/MoonShine_Laravel

DEV Community: Danil Shutsky

AI Factory: Automating AI Agent Project Setup

The Problem

What AI Factory Solves

AI Factory

Experience with SpecKit and OpenSpec

Getting Started

Main Commands

Workflow

Key Features

1. /ai-factory - Context Setup

2. Feature and Task Planning

3. /ai-factory.implement - Executing Created Plan

4. /ai-factory.fix - Quick Fixes

5. /ai-factory.evolve - Skills Self-Learning

6. /ai-factory.skill-generator

Self-Learning System

Project Structure

MCP Servers

Best Practices

Tool Development

Conclusion

Perfect If You:

About the Future

Links

MoonShine 4: AI-Powered Admin Panel Revolution

History and Context

The Story of One Decision

What Came of It

Thanks to Sponsors

Release Date 11.11

What is MoonShine

MoonShine vs Competitors

Main Features

New Structure: Order in Code

What are Resources, Pages, Components and Fields (basics for beginners)

CRUD Module

The Problem with the Old Structure (MoonShine 3)

Solution in MoonShine 4

Tailwind 4 and Design Tokens: Customization Without Limits

What Changed

Palettes: Branding in 1 Minute

Problem and Solution

Palettes - Default and Brand

Palette Generator

Generating Palettes with Forty-Five

New Design: Creation History

Design History

New Template Capabilities

Layout Customization

MoonShine Forty-Five: AI Changes the Game

What It Is and Why

How It Works (Step by Step)

Forty-Five Commands

1. /forty-five.palettes

2. /forty-five.layout

3. /forty-five.components

4. /forty-five.field

5. /forty-five.component

Using Forty-Five

Time Saving is Reality

Telegram Mini App: Admin in Your Pocket

Documentation from the Community

Working on MoonShine 4 Documentation

MoonShine School

PHPStorm Plugin: Automating Routine

What's More?

Upgrade Guide: Migration from Version Three

Add-ons Store - Ready-Made Solutions

What's Interesting There?

Where to Start Working with MoonShine

Development Plans: What's Next

Conclusion

MoonShine 4 Promo Video

Links

Poor Time Management — The Official Sponsor of Your Burnout

1. Don’t Try to Hunt in Different Parts of the Jungle at Once—Otherwise, You’ll Waste Time Moving Between Them

2. Chew Your Prey Slowly—Better for Digestion

3. The Jungle Is Hot—Don’t Forget to Rest in the Shade

4. A Good Hunter Needs Good Sleep

1. `/ai-factory` - Context Setup

3. `/ai-factory.implement` - Executing Created Plan

4. `/ai-factory.fix` - Quick Fixes

5. `/ai-factory.evolve` - Skills Self-Learning

6. `/ai-factory.skill-generator`