Use whichever fits the moment: the MCP connection when you're working from your IDE (and when importing an existing codebase — the agent needs to read your local files), the chat when you're refining in the browser.
## Prompts That Use the Loop Well
**Lead with reuse:**
> "Add user registration — check the library for an existing flow before writing one"
**Scaffold what's new:**
> "Create a blog posts feature with a Post model, PostController with CRUD methods, and API routes"
**Target precisely** — method-level edits are the platform's native grain:
> "Add a search method to UserController that filters by email"
**Make it prove itself:**
> "Run the tests for the checkout service and fix any failures"
**Build UI from description:**
> "Create a dashboard page with a sidebar, header, and main content area using Tailwind"
## Working Habits
**Let it search first.** If you tell the agent to write something from scratch, it will. Asking it to check the library first is the cheaper, better-tested path.
**Build incrementally.** One feature per pass through the loop beats one giant prompt. Review, sync, repeat.
**Make verification part of the ask.** "…and run it" or "…and write a test" turns generated code into proven code before you ever read it.
**Review like it's a PR.** It leaves Stellify as standard Laravel — read it the way you'd read any contribution.
## Next Steps
- [The MCP Server](/stellify/documentation/mcp-server) - Setup and the full tool reference
- [Code Reuse](/stellify/documentation/code-reuse) - How referencing and copy-on-write work
- [Exporting Code](/stellify/documentation/export) - Sync back and close the loop
---
## Mcp Server
The MCP server is the front door to the Stellify development loop: **connect your editor, let AI find existing code and wire it into your project, sync back or export.** Claude Code, Cursor, VS Code Copilot, Claude Desktop — any MCP-compatible client connects directly to your Stellify project, and instead of reading and rewriting whole files, the agent works with your code the way Stellify stores it: as addressable files, methods, statements, and elements.
This page covers connecting the server and what each tool does. If you want to import an existing codebase, see [Importing with MCP](/stellify/documentation/importing-with-mcp).
## Setup
1. Install the server:
```bash
npm install -g @stellify/mcp
```
2. Generate an API token in [User Settings](/stellify/documentation/user-settings) → **API Tokens**. The token is shown once — store it securely.
3. Add the server to your client's MCP configuration (e.g. `.vscode/mcp.json`, Cursor settings, or Claude Desktop's MCP section):
```json
{
"mcpServers": {
"stellify": {
"command": "npx",
"args": ["@stellify/mcp"],
"env": {
"STELLIFY_API_URL": "https://api.stellisoft.com/api/v1",
"STELLIFY_API_TOKEN": "your-api-token-here"
}
}
}
}
```
The server operates on your **active project** — the one currently open in Stellify. Switch projects in the platform and the agent follows.
## The Development Loop, Tool by Tool
The server is designed reuse-first: before generating anything new, agents search the shared library and your project for existing code to reference — because referencing a proven unit costs a fraction of regenerating it ([Code Reuse](/stellify/documentation/code-reuse) explains the model). One pass through the loop looks like:
1. `search_code` — **find**: check whether the feature (or part of it) already exists in the library
2. `reuse_code` — **wire it in**: reference the unit and its dependencies into your project
3. `create_resources` / `create_file` — **fill the gaps**: scaffold what the library didn't have
4. `create_route` — connect it to a URL
5. `run_migration` — apply the database changes
6. `run_code` / `run_tests` — **prove it**: execute and verify
7. `get_assembled_code` — inspect the final rendered source
8. **Sync back** — commit to your GitHub repo or [export](/stellify/documentation/export); your repo stays the source of truth
Then the next feature, same loop.
## Core Tools
These are always available:
| Tool | Purpose |
|------|---------|
| `get_project` | The active project: name, directories, enabled capabilities |
| `search_code` | Search the reusable-code index for existing units to reference |
| `search_files` / `search_methods` / `search_routes` | Find code in your project |
| `reuse_code` | Reference an existing unit (and its dependency closure) into your project |
| `create_resources` | Scaffold a complete resource stack — Model, Controller, Service, Migration — in one call |
| `create_file` | Create a single file (controller, model, middleware, class, or Vue component) |
| `create_route` / `save_route` | Create or update routes with controller wiring and middleware |
| `run_code` | Execute a method in your project environment and return the result |
| `run_migration` | Apply a migration to your connected database |
| `run_tests` | Run a test file and return per-test results |
| `get_assembled_code` | Render a file's structured data back into standard source code |
## Situational Tool Groups
To keep the agent's context lean, less-common tools load on demand via `load_tools`:
- **editing** — surgical statement-level edits and granular inspection: `save_file`, `save_method`, `create_method`, `create_statement`, `add_method_body`, `replace_method_body`, `delete_*`, `get_file`, `get_method`, `get_statement`, and more
- **frontend** — UI and Vue tools: elements, element trees, HTML-to-elements conversion
- **analysis** — performance and code-quality audits
- **capabilities** — list and enable libraries/packages for the project
- **settings** — read and write project configuration profiles
- **contribute** — `submit_code`, for offering your own code into the shared library
You don't need to manage this yourself — agents load groups as their task requires.
## Execution Semantics
**`run_code`** executes a single method in a sandboxed environment scoped to your project and database, with a timeout (30s default). Schema-changing operations are blocked here by design.
**`run_migration`** is the sanctioned path for schema changes. It applies a migration file to your connected database — use it after scaffolding with `create_resources`.
**`run_tests`** runs every test in a test file and reports pass/fail, failure messages, and duration per test. Test runs are wrapped in a database transaction that is rolled back afterwards, so tests never mutate your project data. Test files export to `tests/Feature` in your Laravel project like any other code.
## The Embedded Chat
You don't have to bring your own agent. The editor's built-in AI chat panel uses the same tool surface — describe what you want and it plans tasks, scaffolds resources, edits methods, and builds UI, with changes appearing live in the editor.
## Next Steps
- [Code Reuse](/stellify/documentation/code-reuse) - Reference proven code instead of regenerating it
- [Importing with MCP](/stellify/documentation/importing-with-mcp) - Bring an existing codebase in
- [Working with AI](/stellify/documentation/ai) - Prompting patterns and workflows
---
## Code Reuse
This is the middle of the Stellify development loop — the part between connecting your editor and syncing back. Most application code has been written before, so when your agent gets a feature request, its first move is to **find** that code, not generate it: Stellify's reuse system lets your project **reference** proven, curated units — whole files or individual methods — and wires them in. Referencing an existing unit costs a fraction of the tokens of regenerating it, and you get code that has already been reviewed and used in real projects. We've published the numbers in [The Economics of Code Reuse](/stellify/economics-of-code-reuse).
## References, Not Copies
When you (or an agent) reuse a unit, Stellify doesn't paste a copy into your project. It creates a **reference** to the canonical unit in the shared library, pinned to a specific version. The canonical code is immutable — it can't change underneath you.
Your project treats a referenced unit like any other file or method: it assembles into your exports, runs in your environment, and appears in your file tree.
## Finding Reusable Code
Agents connected via the [MCP server](/stellify/documentation/mcp-server) do this automatically — `search_code` is the mandatory first step before creating anything new. It searches the shared library at method-level granularity, so an agent can pull in a single proven method rather than a whole file.
In the editor, units with curated alternatives show a variant badge, and public projects in [Constellation](/stellify/documentation/constellation) show how many other projects reference them.
## Editing Referenced Code: Copy-on-Write
Referenced code stays live until the moment you change it. When you edit a referenced unit, Stellify automatically **forks** it:
- Your project gets its own private copy with your edit applied
- The canonical unit and every other project referencing it are untouched
- The fork records its ancestry (`forked_from`), so lineage is preserved
You never need to think about this — edit as normal, and the fork happens transparently.
## Variants
Popular units accumulate curated forks — variants that solve the same problem differently. In the editor you can browse a unit's variants, see how many projects have adopted each, and swap your reference to the variant that fits better.
## Submitting Your Own Code
You can offer your own files and methods into the shared library:
1. Select the unit in the editor and choose **Submit for reuse** (or have your agent call `submit_code`)
2. Add a short note explaining what it does and why it's worth sharing
3. The Stellify team reviews submissions — approved units are locked into the library and become referenceable by other projects
You keep ownership of submitted code, attribution is preserved through fork lineage, and adoption of your units is tracked — you can see how many projects reference your code from Constellation.
Submission requires a subscription. Duplicate submissions (byte-identical to something already in the library) are rejected automatically.
## Why This Matters
Every unit that enters the library makes the next project cheaper to build. Instead of every team paying an AI to regenerate the same registration flow, the flow is written once, reviewed once, and referenced everywhere — with copy-on-write protecting anyone who needs to diverge.
## Next Steps
- [The MCP Server](/stellify/documentation/mcp-server) - The tools agents use to search and reuse
- [Constellation](/stellify/documentation/constellation) - Browse public projects and their reusable code
- [Exporting Code](/stellify/documentation/export) - Referenced code exports like any other code
---
## Importing With Mcp
Open your existing project in your IDE, connect the Stellify MCP server, and tell the agent to import it. The agent reads your local codebase, converts it to Laravel 13 where it isn't already, and recreates it in Stellify as structured, editable code. This works for Laravel projects, legacy PHP frameworks, and non-PHP stacks alike — anything the agent can read, it can rebuild.
## Setup
You need a Stellify account, an API token from [User Settings](/stellify/documentation/user-settings), and an MCP-compatible editor.
Install the server:
```bash
npm install -g @stellify/mcp
```
Then register it with your editor. For VS Code, create `.vscode/mcp.json` in your project root:
```json
{
"mcpServers": {
"stellify": {
"command": "npx",
"args": ["@stellify/mcp"],
"env": {
"STELLIFY_API_URL": "https://api.stellisoft.com/api/v1",
"STELLIFY_API_TOKEN": "your-api-token-here"
}
}
}
}
```
Cursor and Claude Desktop take the same command, args, and environment variables in their respective MCP settings. Full connection details are on [The MCP Server](/stellify/documentation/mcp-server) page.
The import lands in your **active project** — the one currently open in Stellify. Create or switch to the right project before you start.
## Running the Import
With MCP connected, the prompt is the whole interface. Open your project in the IDE and ask:
> Import this project into my Stellify project
The agent scans the structure, identifies the framework, and reports what it found — models, controllers, routes, components — before creating anything. Confirm, and it builds the corresponding files in Stellify using the same tools it uses to write new code (`create_file`, `create_method`, `create_route`).
**Converting from another framework** — name the source and target so the agent transforms rather than transcribes:
> Import this CodeIgniter project and convert it to Laravel 13
> Rebuild this Django application as a Laravel 13 project
> Convert this Express.js API to Laravel with the same endpoints
Framework idioms are mapped, not copied: CodeIgniter Active Record becomes Eloquent, `$this->input->post()` becomes Request objects, custom libraries become service classes, controller patterns become route-model-bound Laravel controllers.
**Importing selectively** — scope the prompt:
> Import just the User model and UserController
> Import all controllers in app/Http/Controllers/Api
> Import the routes from routes/api.php
**Adding context** — the more the agent knows about what matters, the better the result:
> Import the authentication system. The main files are AuthController, the User model, and the auth routes
## What Gets Imported
- **Models** — with relationships, casts, and fillables
- **Controllers** — all methods, including validation and responses
- **Routes** — web and API, with middleware
- **Middleware and services**
- **Vue components** — single-file components with script setup
Directory mapping is what you'd expect: `app/Models` → Models, `app/Http/Controllers` → Controllers, `app/Services` → Services, `resources/js` → JS, `routes/web.php` and `routes/api.php` → your Stellify routes.
## Working Through a Large Import
Don't ask for a 400-file project in one prompt. Import in passes — models first, then controllers, then routes — reviewing in the Stellify editor between passes:
> Import the models first
> Now import the controllers that use those models
If a relationship comes through wrong, say so plainly and the agent fixes the specific models:
> The Post model belongs to User and has many Comments. Update the relationships.
If imported code depends on packages or integrations, ask the agent what [capabilities](/stellify/documentation/project-settings) it needs — it will tell you what to enable and configure.
## After Importing
1. **Review in the editor** — walk the file dropdown; spot-check methods and relationships
2. **Enable capabilities** — auth, storage, mail: whatever the imported code depends on
3. **Connect your database** and run the migrations
4. **Verify** — run key methods with test input, or have the agent write and run a test file
## Tips
- **Import from a clean commit** — a stable snapshot beats a mid-refactor working tree
- **`.gitignore` is respected** — the agent won't read ignored files
- **Describe the architecture up front** — "services hold the business logic, controllers are thin" saves a correction pass later
## Troubleshooting
**Connection refused / timeout** — check the token and `STELLIFY_API_URL`, and that your network allows outbound connections.
**Unauthorized** — the token was revoked (generating a new MCP token revokes old ones) or mistyped. Create a fresh one in User Settings.
**Files missing in Stellify** — check the agent's output for parsing errors on specific files; re-run the import for just those files.
**MCP server not found** — verify the install with `npx @stellify/mcp --version`.
## Next Steps
- [The MCP Server](/stellify/documentation/mcp-server) - The full tool reference
- [Importing WordPress](/stellify/documentation/importing-wordpress) - The dedicated WordPress workflow
- [Code Reuse](/stellify/documentation/code-reuse) - Build the rest reuse-first
---
## Importing Wordpress
Import your WordPress site and rebuild it as a modern Laravel application.
## Philosophy
Standard WordPress functionality (Posts, Categories, Tags) is the same for every WordPress site. Instead of rebuilding this from scratch each time, Stellify provides a **WordPress scaffold** that sets up these standard models, controllers, and migrations. The import skill then focuses only on what's custom about your specific WordPress site.
## Prerequisites
Before importing a WordPress site:
1. **Run the WordPress scaffold first** — Go to Project Settings and click "Scaffold WordPress Core" to create standard models (Post, Category, Tag) with their controllers and migrations
2. **Configure your project database** — Ensure your Stellify project has a database connection configured (Project Settings → Database)
3. **Run migrations** — The scaffold creates migrations that need to be run to create the tables
4. **Visual/styling conversion** — Template styling is handled separately from data structure import
## Quick Start
### Step 1 — Run the WordPress Scaffold
In the Stellify editor, go to **Project Settings** and click **Scaffold WordPress Core**. This creates:
- **Post** model (title, slug, content, excerpt, featured_image, status, published_at, author_id, meta_title, meta_description)
- **Category** model (name, slug, description)
- **Tag** model (name, slug)
- Controllers with CRUD operations
- Migrations with proper relationships (Post belongsToMany Category/Tag, Post belongsTo User)
### Step 2 — Import Content Directly
In the **WordPress Import** panel (Project Settings), enter your WordPress site URL and click **Preview** to see what content is available:
1. **Enter your WordPress URL** — e.g., `https://your-wordpress-site.com`
2. **Add authentication (optional)** — For drafts, private posts, and users, enter `username:app_password`
3. **Select content types** — Choose which content to import (posts, categories, tags, users)
4. **Click Preview** — See counts of available content
5. **Click Import** — Content is imported directly into your Stellify project database
The import runs immediately in the Stellify editor — no need to export your project first. You can see your imported content right away in the editor.
#### Authentication for Private Content
For private content and user imports, create an Application Password in your WordPress dashboard:
1. Go to **Users → Your Profile → Application Passwords**
2. Enter a name (e.g., "Stellify Import") and click **Add New**
3. Copy the generated password
4. Enter `your-username:generated-password` in the Auth field
The import uses the WordPress REST API, which is enabled by default on WordPress 4.7+.
### Step 3 — Export Import Service for Re-syncs (Optional)
If you need to re-import content after deploying your app (e.g., for ongoing content updates), you can scaffold an import service for your exported project:
1. Expand the **Export Import Service** section
2. Click **Add Import Service**
This creates:
- **WordPressImportService** — Pulls content via REST API
- **wp:import artisan command** — CLI tool for running imports
After exporting and deploying your project, you can run:
```bash
# Basic import (public posts, categories, tags)
php artisan wp:import https://your-wordpress-site.com
# Import with authentication (for drafts, private posts, users)
php artisan wp:import https://your-wordpress-site.com --auth=username:app_password --users
# Skip specific content types
php artisan wp:import https://your-wordpress-site.com --skip-posts --skip-tags
```
### Step 4 — Install the Import Skill (Optional)
For a guided import experience with custom post types and ACF fields, add the WordPress import skill to your project:
```bash
mkdir -p .claude/skills/wordpress-import
curl -o .claude/skills/wordpress-import/SKILL.md https://raw.githubusercontent.com/Stellify-Software-Ltd/stellify-mcp/main/skills/wordpress-import.md
```
Add the skill to your `CLAUDE.md`:
```markdown
## Skills
- wordpress-import: Use this skill when importing WordPress sites into Stellify. Invoke with /wordpress-import to start the guided workflow.
```
### Step 5 — Run the Guided Import
Type `/wordpress-import` in your editor to start the guided workflow for custom post types and ACF fields.
## Import Workflow
### Step 1 — Verify WordPress Scaffold
The import skill first checks that standard WordPress models exist (`app/Models/Post.php`, `Category.php`, `Tag.php`). If not, it prompts you to run the scaffold before proceeding.
### Step 2 — Analyse the WordPress Project
The skill performs comprehensive analysis to understand what's custom about your site:
**2a. Identify active theme**
- Classic PHP theme or block theme (theme.json)
**2b. Scan for custom post types & taxonomies**
- Check `functions.php` for `register_post_type()` and `register_taxonomy()` calls
- Detect CPT plugins (Custom Post Type UI, Pods, etc.)
**2c. Scan plugins directory**
- **Functionality plugins** (WooCommerce, ACF, forms) — need attention
- **Low priority** (SEO, caching, security) — usually skip
- **Builder plugins** (Elementor, WPBakery) — affects where templates are stored
**2d. Database analysis**
Run diagnostic queries to find:
- Custom post types actually in use (with content counts)
- Custom taxonomies in use
- Custom meta keys (reveals ACF fields, custom fields)
- Shortcodes embedded in content
- Gutenberg blocks in use
**2e. Produce analysis report**
Structured summary showing:
- Theme info
- Content counts
- Custom post types (name, slug, supports, count)
- Custom taxonomies (name, slug, attached to, hierarchical, term count)
- Custom fields discovered
- Plugins requiring attention
- Content flags (shortcodes, page builder usage)
- Generation plan (what will be created vs what's already scaffolded)
You'll be asked to confirm before proceeding.
### Step 3 — Generate Custom Resources
For each custom post type and taxonomy identified:
**3a. Custom post type models**
- Model, migration, controller with:
- Standard fields (title, slug, content, excerpt, status, published_at, author_id)
- Custom fields from meta analysis
- `getRouteKeyName()` returning 'slug'
- Relationships to custom taxonomies
- Published scope
**3b. Custom taxonomy models**
- Fields (name, slug, description, parent_id if hierarchical)
- Pivot table for relationships
**3c. Routes**
- Following WordPress URL conventions
### Step 4 — Document Manual Tasks
The skill creates a summary of items needing manual attention:
- Forms (list fields and purpose)
- Shortcodes in content (need processing during migration)
- Plugin functionality (WooCommerce, memberships, etc.)
- Content migration steps (export, transform, import, process shortcodes, migrate media)
## Key Rules
| Rule | Description |
|------|-------------|
| **Analysis first** | Complete full analysis before generating any code |
| **Only generate custom elements** | Standard models come from scaffold |
| **Fresh database only** | No WordPress table connection |
| **No template conversion** | Visual design handled by separate skill |
| **Be pragmatic** | Focus on post types/taxonomies that actually have content |
## Before You Start
### REST API Import (Recommended)
The Stellify editor imports directly from your WordPress site via its REST API. No manual export is needed — just enter your WordPress URL and authenticate if required.
**Requirements:**
- WordPress 4.7 or later (REST API enabled by default)
- Site must be publicly accessible (or use authentication for private content)
- For private posts, drafts, and users: Create an Application Password in WordPress
### Manual Export (Alternative)
If REST API access is not available, you can manually export content:
**Option 1: WordPress XML Export**
In WordPress admin: Tools → Export → All content → Download Export File
**Option 2: WP-CLI**
```bash
# Export all content
wp export --dir=./export
# Export specific post types
wp export --post_type=post,page,product
```
**Option 3: REST API (manual)**
```bash
# Export posts
curl "https://yoursite.com/wp-json/wp/v2/posts?per_page=100" > posts.json
# Export pages
curl "https://yoursite.com/wp-json/wp/v2/pages?per_page=100" > pages.json
```
### Gather Your Theme Files
Copy your theme folder locally. The AI will read:
- `header.php`, `footer.php` — Global layout
- `index.php`, `single.php`, `page.php` — Templates
- `functions.php` — Custom functionality (important for CPT detection)
- Template parts in `/template-parts/`
### Note Your Active Plugins
List plugins that add functionality you want to preserve:
- Forms (Contact Form 7, Gravity Forms, WPForms)
- E-commerce (WooCommerce)
- Custom fields (ACF, Meta Box)
- Page builders (Elementor, Beaver Builder)
## WordPress to Stellify Mapping
### Content Types
| WordPress | Stellify | Source |
|-----------|----------|--------|
| Posts | Post model + API | Scaffold |
| Categories | Category model | Scaffold |
| Tags | Tag model | Scaffold |
| Custom Post Types | Custom models | Import skill |
| Custom Taxonomies | Custom models | Import skill |
### Common Functions
| WordPress Function | Stellify Equivalent |
|--------------------|---------------------|
| `the_title()` | `{{ $post->title }}` or `{{ post.title }}` |
| `the_content()` | `{!! $post->content !!}` or `v-html` |
| `the_excerpt()` | `{{ $post->excerpt }}` |
| `get_the_date()` | `{{ $post->published_at }}` |
| `the_post_thumbnail()` | `
For a full CRUD stack, don't create files one by one — use **Create Resources** in the file dropdown (or ask the agent) to generate the Model, Controller, Service, and Migration together, pre-wired.
## Methods
Add a method from the method dropdown, then click the cog (⚙️) on the signature to set its name, parameters, visibility, and return type. The signature is structured data — the method dropdown displays every method with its return type, and exports render the exact typed signature you configured.
Write the body as you normally would:
Each line you write is stored as a statement with its own identity. That's why an agent asked to "add a null check to store()" adds exactly one statement — it isn't rewriting the file and hoping the diff is small.
## File-Level Statements
Imports, class properties, and constants are statements that belong to the file rather than a method. Add them from the file view; they render above your methods.
One thing to know: `use` statements only resolve for classes registered with the platform. If an import doesn't resolve, the class may need a [capability](/stellify/documentation/project-settings) enabled — or a capability request if it isn't supported yet.
## Autocomplete
As you type, suggestions appear scoped to where you are: the method's parameters and local variables, class properties, model attributes, and importable classes from your enabled capabilities. Because the editor knows the actual structure — not just nearby text — suggestions are drawn from what genuinely exists in your project.
Navigate with **↑/↓**, accept with **Tab** or **Enter**, dismiss with **Esc**.
## Running Methods
Click **Run** on any method to execute it against your project environment — no route, no HTTP client, no dump statements. Provide the input as JSON, get the return value back:
This is the same execution path agents use via `run_code` — write a method, run it, fix it, run it again, all without leaving the editor. Schema changes are the one exception: migrations run through the migration runner in [database settings](/stellify/documentation/database-connection), not here. Test files get their own runner too — every test in the file executes and reports individually, wrapped in a transaction that rolls back so your data is untouched.
## Bundling JavaScript
With a JavaScript file selected, the file dropdown offers two ways to bundle:
**Bundler service (recommended).** Run the [Stellify bundler service](https://github.com/Stellify-Software-Ltd/stellify-bundler-service) locally or on a server, point your project settings at it, and choose **Bundle with Service**. It's esbuild under the hood — fast, production-grade output.
**ESM bundler.** Choose **Bundle with ESM** to bundle in the browser with no setup. Slower, but fine for quick iteration before you've stood up the service.
## Next Steps
- [Interface Builder](/stellify/documentation/interface-builder) - The visual side of the same structured model
- [The MCP Server](/stellify/documentation/mcp-server) - Let agents drive these same operations
- [Exporting Code](/stellify/documentation/export) - How structured code becomes standard files
---
## Interface Builder
The Interface Builder is the visual side of the editor: the canvas renders your actual page, and everything on it is a selectable, editable element. Elements are structured data — the same model your PHP methods use — so the UI you build here is just as addressable by agents as your backend code, and assembles to standard Vue templates on export.
## Pick a Route First
The canvas always shows the route in the address bar. Use the route dropdown to switch pages, create new ones, or open **Route Settings** to change the path, name, and controller wiring.
## Select, Then Edit
Click anything on the canvas to select it — the selection gets a dashed outline, and the element tree highlights its position in the page structure.
The element tree is the structural view: expand/collapse with ▼/▶, click to select deeply nested elements the canvas makes hard to hit, and drag to reorder. Use the responsive view buttons to check the page at desktop, tablet, and mobile widths as you go.
## Adding Elements
Click the plus icon in the element tree — the new element is added as a child of the current selection, so select the container first.
Elements come in five types. The type controls which properties the editor offers you — in the final assembled code it disappears entirely:
| Type | Assembles to |
|------|--------------|
| **s-wrapper** | Containers: `div`, `section`, `header`, `nav`… |
| **s-input** | Form controls: `input`, `button`, `textarea`, `select` |
| **s-form** | A `form` with submit handling wired |
| **s-media** | `img`, `video`, `audio` |
| **s-loop** | A repeating element (`v-for`) bound to an array |
Building a big chunk of UI? Don't click it together element by element — describe it to the agent, or paste existing markup and let `html_to_elements` convert it. The result is the same editable tree.
## Editing Properties
The property panel edits the selected element: its tag, Tailwind classes, text content, and attributes like `href` and `src`.
Styling is Tailwind utility classes on the `Classes` field — change a class and the canvas updates immediately. There's no separate CSS pipeline to manage; the classes you set here are the classes in your exported components.
## Wiring Events to Methods
This is where UI meets your code. Select an element, open the **Events** panel, pick an event (`@click`, `@submit`, `@input`, …), and choose which method it calls — the dropdown lists the methods from the Vue files included on this route.
Supported: **MySQL 5.7+**, **PostgreSQL 12+**, **MariaDB 10.3+**.
Until you connect one, your project runs against a managed workspace database — fine for early building, but connect your own before you rely on the data.
---
## Fastest Path: Supabase
The Supabase wizard connects (or creates) a free PostgreSQL database without leaving Stellify:
1. Open **Project Settings → Database** and choose **Supabase**
2. Provide your Supabase access token — the wizard lists your existing projects and can create a new one for you
3. Pick a project; Stellify pulls the connection details and fills them in
Prefer to do it manually? In Supabase, **Settings → Database** has the host, port (`5432`), database (`postgres`), username, and password — paste them into Stellify's connection form.
## Other Providers
Any reachable MySQL/PostgreSQL works the same way: create the database, grab the connection details, enter them in Stellify. For PlanetScale use the Laravel connection preset; for Neon copy the connection string from the dashboard; for a self-hosted server make sure it accepts external connections and the user has full rights on the database.
## Test the Connection
Click **Test Connection** after saving credentials. If it fails, it's almost always one of:
- The database doesn't allow external connections (firewall / IP allowlist)
- Wrong username or password
- The provider requires SSL
---
## Migrations
Migrations are the one kind of code that doesn't run through the normal Run button — schema changes go through the migration runner:
- **In the editor**: **Project Settings → Database → Run Migrations** applies pending migrations
- **From an agent**: the `run_migration` MCP tool applies a specific migration file — agents do this automatically after scaffolding with `create_resources`
Scaffold a resource, run its migration, and the table exists — you can `run_code` the controller against real data immediately.
## Moving Data
**Copy Data** (in database settings) migrates your project's schema and data from the workspace database into your connected database — use it once when you graduate from the workspace default to your own instance.
---
## Next Steps
- [The MCP Server](/stellify/documentation/mcp-server) - run_migration and run_code semantics
- [Project Settings](/stellify/documentation/project-settings) - Everything else in settings
- [Exporting Code](/stellify/documentation/export) - Your exported app connects to this same database
---
## Project Settings
## Overview
Project Settings is where you manage the configuration that applies to your entire application. Access it from the settings icon in the top navigation.
## General Project Settings
Basic project information and configuration.
- **Project Name**: Display name for your project
- **Description**: Brief description of what the app does (used by AI)
- **PHP Version**: Target PHP version for compatibility
## Team Members
Invite collaborators by email, review pending invitations, and set each member's permissions (read, write, execute). See [Collaborators](/stellify/documentation/collaborators) for the full picture, including limits and how simultaneous edits are handled. Subscription only.
## Version Control
Create, switch, merge, and delete branches for your project. See [Version Control](/stellify/documentation/version-control).
- **Default branch**: Usually `main`, used as the base for new branches
- **Commits ahead**: Changes not yet merged to the default branch
- Branch creation requires an active subscription
## Capabilities
View and configure installed packages and integrations. AI checks for capabilities before implementing a feature request. If application framework code is needed that doesn't currently exist or is not fit for purpose, a capability request is raised and you'll be emailed once the capability is available.
Some capabilities need configuration before they can be enabled — for example, Stripe needs your API keys, and the `ai` capability needs provider credentials. Save the required settings first, then enable.
### Capability Statuses
- **Available**: Installed and ready to use
- **Needs Config**: Installed but requires API keys or setup
- **Enable**: Click to add the capability to your project
### Per-Project AI Credentials
Enabling the `ai` capability lets your application code use the Laravel AI SDK with **your own provider keys** (OpenAI, Anthropic, Gemini, and others). Your credentials are stored as a project setting and injected only when your code runs — they're never shared with the platform's own AI features.
## Usage Statistics
View usage metrics and analytics for your project.
## Publish to Constellation
Submit your project for a public listing on [Constellation](/stellify/documentation/constellation), Stellify's app store. Fill in the listing metadata (description, thumbnail, screenshot) and submit for review — on approval, your project becomes public and its code becomes referenceable by other projects.
## Export Project to Desktop
Download your project as standard PHP and Vue files for local development. See [Exporting Code](/stellify/documentation/export).
## GitHub Integration
Connect your project to GitHub for version control and export. Link a repository to enable importing, exporting, and two-way file sync.
## Delete Project
Permanently delete your project. This action cannot be undone.
## Next Steps
- [Code Editor](/stellify/documentation/code-editor) - Write application logic
- [Interface Builder](/stellify/documentation/interface-builder) - Build your UI
- [Exporting Code](/stellify/documentation/export) - Export to GitHub
---
## User Settings
## Overview
User Settings holds everything tied to your account rather than a single project. Open it from your profile icon in the top navigation.
## API Tokens
The section you'll visit first. API tokens are how anything outside the browser talks to your Stellify account:
- **The [MCP server](/stellify/documentation/mcp-server)** — Claude Code, Cursor, and other agents authenticate with this token
- **CI/CD and integrations** — script exports and other API operations
Click **Create New Token** and copy it immediately — it's shown once. Generating a new MCP token revokes the previous one, so update your editor's MCP config when you rotate.
## Profile
Name, email, and avatar.
## Preferences
Editor behavior: dark mode, auto-save, font size, tab size.
## Subscription
Your plan, billing, and invoices. Subscription level determines [branch](/stellify/documentation/version-control) limits, [collaborator](/stellify/documentation/collaborators) seats, and access to features like embedding and library submission.
## Account Security
Password and two-factor authentication.
## Next Steps
- [The MCP Server](/stellify/documentation/mcp-server) - Put that API token to work
- [Project Settings](/stellify/documentation/project-settings) - Per-project configuration
---
## Collaborators
Stellify projects support real multi-user development: invite collaborators by email, control what each person can do, and let the platform handle simultaneous edits safely.
## Inviting Collaborators
Project owners can invite collaborators from Project Settings:
1. Open **Project Settings → Team Members**
2. Enter the collaborator's email address and send the invite
3. They receive an email link; accepting it adds them to the project and switches their editor to it
Invitations expire after 7 days. Pending invites can be revoked before they're accepted.
## Permissions
Each collaborator has granular permissions the owner can adjust:
- **Read** — view the project (the baseline for new collaborators)
- **Write** — edit code, elements, and routes
- **Execute** — run code, migrations, and tests
- **Owner (super)** — full control, including team management and project settings
New collaborators join read-only; the owner grants write/execute as needed.
## Limits
- Collaboration is a subscription feature for the project owner
- A project can have up to 10 collaborators (including pending invites)
- One collaborator without their own subscription is allowed per project; additional collaborators need a subscribed account
## Working in a Shared Project
Collaborators see the shared project in their project switcher and can move between it and their own projects. A collaborator can leave a project at any time from the project menu.
When two people edit the same entity at the same time, Stellify detects it at the field level rather than silently overwriting — see [Edit Conflicts](/stellify/documentation/edit-conflicts).
If you want to work without interference, create a [branch](/stellify/documentation/version-control): branches are isolated per user, so nothing you do on a branch collides with anyone else until you merge.
## Next Steps
- [Edit Conflicts](/stellify/documentation/edit-conflicts) - How simultaneous edits are detected and resolved
- [Version Control](/stellify/documentation/version-control) - Branch-based isolation
- [Project Settings](/stellify/documentation/project-settings) - Where team management lives
---
## Edit Conflicts
When multiple people (or a person and an agent) edit the same project, edits can collide. Because Stellify stores code as structured entities rather than text files, it detects collisions at the **field level** — and never silently overwrites anyone's work.
Conflict detection runs automatically on multi-user projects for shared (main-branch) entities. Work on an isolated [branch](/stellify/documentation/version-control) is exempt — branches can't collide until merge.
## How Detection Works
Every save carries the state the editor originally loaded. When you save, Stellify compares three things: what you loaded, what you're saving, and what's currently stored. If someone else changed the entity since you loaded it **and** your edits touch the same fields, the save is stopped and a conflict is recorded. Nothing is committed — both versions are preserved.
If the other person changed *different* fields, there's no conflict: their changes are pulled in alongside yours.
## Live Reconciliation
The editor also reconciles continuously while you work. If a collaborator saves changes to the entity you have selected, safe fields update in place, and only genuinely clashing fields are flagged — most simultaneous editing never becomes a conflict at all.
## Resolving Conflicts
Open **/conflicts** to see your pending conflicts. Each one shows both versions with the clashing fields highlighted. The person who hit the conflict proposes a resolution:
- **Mine** — keep your version
- **Theirs** — accept the other person's version
- **Merge** — combine, field by field
- **Manual** — write the resolution yourself
- **Abandon** — discard the proposed change entirely
Resolutions are durable: **both parties must agree** before anything commits. The counterparty reviews the proposal and agrees (or counter-proposes); once both have agreed, the resolution is applied automatically. The proposer can also cancel their own proposal at any time.
## Design Principles
- **No lost work** — a conflicting save is parked, never dropped or force-merged
- **Conservative by default** — only fields both users actually touched count as conflicts
- **Agreement, not authority** — neither side can unilaterally impose a resolution on shared code
## Next Steps
- [Collaborators](/stellify/documentation/collaborators) - Inviting people and setting permissions
- [Version Control](/stellify/documentation/version-control) - Branches sidestep conflicts entirely
---
## Constellation
Constellation is Stellify's public app store, at [stellisoft.com/stellify/store](/stellify/store) — where public Stellify projects live. Every listing is a complete, working application whose code you can inspect, reference, and build on — not a screenshot gallery.
## Browsing
Each listed project shows its description, screenshots, and a **"Reused by N projects"** count — how many other projects currently reference code from it. That count is Constellation's social proof: it measures code that other builders actually adopted.
Featured projects showcase what the platform can do end-to-end (for example, an AI/RAG assistant and a subscription billing starter).
## Using Constellation Code
Public projects feed the [code reuse](/stellify/documentation/code-reuse) system. From a listing you can pull units into your own project by reference — pinned, immutable, and copy-on-write when you need to diverge. Your agent can do the same through `search_code` and `reuse_code`.
## Publishing Your Project
Any project owner with a subscription can request a listing:
1. Open **Project Settings** and fill in the listing metadata — name, description, thumbnail, and screenshot
2. Click **Submit for review**
3. The Stellify team reviews the submission; on approval your project becomes public and appears in Constellation
One review request can be pending per project at a time. Until approved, your project stays private.
### What Publishing Means
Publishing makes your project's code publicly visible and referenceable by other projects. You keep ownership; fork lineage preserves attribution, and you can see adoption of your code from your Constellation listing. Public projects remain live code — when you improve them, reviewed updates can become new versions without breaking anyone pinned to older ones.
## Next Steps
- [Code Reuse](/stellify/documentation/code-reuse) - How referencing Constellation code works
- [Sharing & Embedding](/stellify/documentation/sharing) - Share individual pages without publishing the whole project
---
## Sharing
You can share live, working pages from your project with anyone — no Stellify account required — and embed them in other sites.
## Share Links
A share link renders a page of your app publicly:
```
https://stellisoft.com/share/{project-uuid}/{page-uuid}
```
The page runs for real: its controller executes, data loads, and forms and buttons work. Visitors interact with your actual application, not a static preview.
To make a page shareable, mark its route as **public** in the route settings. Only GET routes explicitly marked public are accessible — everything else stays private by default.
## Embedding
Embed a public page in any website with an iframe:
```
https://stellisoft.com/embed/{project-uuid}/{page-uuid}
```
The editor generates the embed code for you — open a public route and choose **Embed** to copy:
- The share URL
- A fixed-size iframe snippet
- A responsive iframe snippet
- Plain HTML link and Markdown variants
Embedding requires the project owner to have an active subscription; plain share links do not.
## Good Uses
- **Demos** — send a working feature to a client before it ships
- **Portfolios** — embed live apps in your personal site instead of screenshots
- **Docs and blogs** — embed a working example right in an article
## Notes
- Share and embed traffic is rate-limited to protect your project
- Unmarking a route as public immediately disables its share and embed URLs
- To make an entire project public and referenceable, see [Constellation](/stellify/documentation/constellation)
## Next Steps
- [Constellation](/stellify/documentation/constellation) - Publish the whole project
- [Routes & Navigation](/stellify/documentation/navigation) - Where route settings live
---
## Export
This is where the Stellify development loop closes. The code your agent found, wired in, and verified leaves as standard Laravel — export individual files, download the entire project, or push straight to your GitHub repository. Your repo stays the source of truth; Stellify is the workbench the code passed through.
## Export Individual Files
Download a single file as standard PHP or Vue:
1. Open the file you want to export
2. Click **Export** (or right-click in the file tree)
3. Choose the format:
- `.php` for controllers, models, classes
- `.vue` for Vue single-file components
- `.js` for JavaScript modules
The exported file is standard code - no Stellify-specific syntax or dependencies.
## Export Entire Project
Download your complete project as a ZIP file ready to use with Laravel:
1. Go to **Project Settings**
2. Click **Download ZIP** in the Export Project section
The ZIP includes everything you need:
- All your PHP files (controllers, models, middleware, classes)
- Vue components
- Routes (web.php and api.php)
- `composer.json` with dependencies based on your project capabilities
- `package.json` for Vue/Vite setup
- Config files generated from your project settings
- `vite.config.js` and `tailwind.config.js`
### Setting Up Locally
1. **Install a fresh Laravel project:**
```bash
composer create-project laravel/laravel my-project
cd my-project
```
2. **Extract the ZIP** into your Laravel directory, replacing existing files
3. **Install dependencies:**
```bash
composer install
npm install
```
4. **Configure your environment:**
- Copy `.env.example` to `.env`
- Set your database credentials
- Run `php artisan key:generate`
5. **Run migrations and start the server:**
```bash
php artisan migrate
npm run dev
php artisan serve
```
Your exported project structure:
```
your-project/
├── app/
│ ├── Http/
│ │ ├── Controllers/
│ │ └── Middleware/
│ └── Models/
├── config/
├── resources/
│ └── js/
│ └── components/
├── routes/
│ ├── web.php
│ └── api.php
├── composer.json
├── package.json
├── vite.config.js
└── tailwind.config.js
```
## Export to GitHub
Push your project directly to a GitHub repository.
### Quick Export
If you've exported before, you'll see a quick export view showing your last target and how many files have changed: