@stellisoft/stellify-mcp 0.1.37 → 0.1.38

package/dist/index.js

@@ -1509,7 +1509,7 @@ const SERVER_INSTRUCTIONS = `Stellify is a coding platform where code is stored
 // Create MCP server
 const server = new Server({
     name: 'stellify-mcp',
-    version: '0.1.37',
+    version: '0.1.38',
 }, {
     capabilities: {
         tools: {},

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@stellisoft/stellify-mcp",
-  "version": "0.1.37",
+  "version": "0.1.38",
   "mcpName": "io.github.MattStellisoft/stellify-mcp",
   "description": "MCP server for Stellify - AI-native code generation platform",
   "main": "dist/index.js",

package/server.json

@@ -6,12 +6,12 @@
     "url": "https://github.com/Stellify-Software-Ltd/stellify-mcp",
     "source": "github"
   },
-  "version": "0.1.37",
+  "version": "0.1.38",
   "packages": [
     {
       "registryType": "npm",
       "identifier": "@stellisoft/stellify-mcp",
-      "version": "0.1.37",
+      "version": "0.1.38",
       "transport": {
         "type": "stdio"
       },

package/skills/wordpress-import.md

@@ -1,264 +1,317 @@
 ---
 name: wordpress-import
-description: "Use this skill when importing WordPress sites into Stellify. Invoke with /wordpress-import to start the guided workflow. Covers: analyzing WordPress exports, converting post types to Eloquent models, transforming PHP templates to Vue components, migrating forms and plugins, and creating routes and API endpoints."
+description: "Use this skill when importing WordPress sites into Stellify. Invoke with /wordpress-import to analyse a WordPress project and generate resources for custom post types, taxonomies, and fields. Assumes standard WordPress models (Post, Page, Category, Tag, User, Media) are already scaffolded via Stellify."
 license: MIT
+icon: <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><title>wordpress</title><path d="M3.42,12C3.42,10.76 3.69,9.58 4.16,8.5L8.26,19.72C5.39,18.33 3.42,15.4 3.42,12M17.79,11.57C17.79,12.3 17.5,13.15 17.14,14.34L16.28,17.2L13.18,8L14.16,7.9C14.63,7.84 14.57,7.16 14.11,7.19C14.11,7.19 12.72,7.3 11.82,7.3L9.56,7.19C9.1,7.16 9.05,7.87 9.5,7.9L10.41,8L11.75,11.64L9.87,17.27L6.74,8L7.73,7.9C8.19,7.84 8.13,7.16 7.67,7.19C7.67,7.19 6.28,7.3 5.38,7.3L4.83,7.29C6.37,4.96 9,3.42 12,3.42C14.23,3.42 16.27,4.28 17.79,5.67H17.68C16.84,5.67 16.24,6.4 16.24,7.19C16.24,7.9 16.65,8.5 17.08,9.2C17.41,9.77 17.79,10.5 17.79,11.57M12.15,12.75L14.79,19.97L14.85,20.09C13.96,20.41 13,20.58 12,20.58C11.16,20.58 10.35,20.46 9.58,20.23L12.15,12.75M19.53,7.88C20.2,9.11 20.58,10.5 20.58,12C20.58,15.16 18.86,17.93 16.31,19.41L18.93,11.84C19.42,10.62 19.59,9.64 19.59,8.77L19.53,7.88M12,2A10,10 0 0,1 22,12A10,10 0 0,1 12,22A10,10 0 0,1 2,12A10,10 0 0,1 12,2M12,21.54C17.26,21.54 21.54,17.26 21.54,12C21.54,6.74 17.26,2.46 12,2.46C6.74,2.46 2.46,6.74 2.46,12C2.46,17.26 6.74,21.54 12,21.54Z" /></svg>
 metadata:
   author: stellify
 ---
 
 # WordPress Import Skill
 
-You are importing a WordPress site into Stellify by reading its PHP theme files and recreating the site as a structured Laravel application using the Stellify MCP tools.
+You are importing a WordPress site into Stellify. This skill focuses on **analysing what's custom** about the WordPress site and generating only those elements. Standard WordPress functionality (Posts, Pages, Categories, Tags, Users, Media) is handled by Stellify's WordPress scaffold.
 
-**Match the rendering approach of the WordPress site.** If content is server-rendered in WordPress (which most of it will be — posts, pages, archives, navigation), create Blade templates. If a feature uses JavaScript for client-side interactivity (AJAX forms, dynamic filtering, live search, infinite scroll, modals, sliders), create a Vue component for that specific piece. The default is Blade — only reach for Vue when the WordPress source is doing something that genuinely requires JS.
+## Step 1 — Verify WordPress Scaffold
 
-## Step 1 — Identify the Active Theme
+Before proceeding, check that the Stellify WordPress scaffold has been run. Look for the presence of standard WordPress models in the Laravel project:
 
-Look in `./wp-content/themes/` to find the active theme. If there are multiple themes, check for the most recently modified one, or the one with the most template files. If unsure, ask which theme to import.
+- `app/Models/Post.php`
+- `app/Models/Page.php`
+- `app/Models/Category.php`
+- `app/Models/Tag.php`
 
-Before proceeding, ask the user:
+If these don't exist, instruct the user:
 
-> **How do you want to handle the database?**
+> **WordPress scaffold required**
 >
-> **A) Connect to existing WordPress database** — Models map directly to the WordPress tables (`wp_posts`, `wp_users`, etc.) using the existing column names. No migrations, no data copying. Your Laravel app reads and writes to the same database WordPress uses. This is the fastest path.
+> Before importing, you need to run the Stellify WordPress scaffold. This creates the standard models, controllers, and routes that every WordPress site uses.
 >
-> **B) Fresh database** — Create new Laravel migrations with clean column names (`title` instead of `post_title`, etc.). You start with an empty database and can optionally migrate content from WordPress later.
-
-These are the only questions you may ask. Do not ask anything else.
+> Run: `[scaffold command TBD]`
+>
+> Let me know when this is complete.
 
-## Step 2 — Inventory the Theme
+Do not proceed until the scaffold is in place.
 
-Read the full theme directory. Categorise every file:
+## Step 2 — Analyse the WordPress Project
 
-- **Core templates**: index.php, single.php, page.php, archive.php, search.php, 404.php, front-page.php, home.php
-- **Structural partials**: header.php, footer.php, sidebar.php
-- **Template parts**: anything in template-parts/ or patterns/
-- **Functions**: functions.php (and any files it includes/requires)
-- **Styles**: style.css, any CSS/SCSS files
-- **Config**: theme.json if present (block theme configuration)
+Perform a comprehensive analysis of the WordPress site to understand what's custom. This produces a report before any code generation happens.
 
-Print the inventory before proceeding.
+### 2a. Identify the Active Theme
 
-## Step 3 — Analyse functions.php
+Look in `./wp-content/themes/` to find the active theme. If there are multiple themes, check for the most recently modified one, or the one with the most template files. If unsure, ask which theme to import.
 
-Read functions.php thoroughly. Extract:
+Note whether it's a classic PHP theme or a block theme (presence of `theme.json` and HTML templates).
+
+### 2b. Scan for Custom Post Types & Taxonomies
+
+Read `functions.php` and any files it includes/requires. Extract:
+
+- **Custom post types** via `register_post_type()` — capture name, labels, supports array, and any custom rewrite rules
+- **Custom taxonomies** via `register_taxonomy()` — capture name, which post types it attaches to, hierarchical setting
+
+Also check for CPT plugins that store configuration differently:
+- Custom Post Type UI stores config in `wp_options` under `cptui_post_types` and `cptui_taxonomies`
+- Pods, Toolset, and similar plugins have their own storage patterns
+
+### 2c. Scan Plugins Directory
+
+List the contents of `wp-content/plugins/` and categorise:
+
+**Functionality plugins** (affect what the site does — need attention):
+- WooCommerce — e-commerce (major rebuild)
+- Advanced Custom Fields / ACF Pro — custom fields
+- Gravity Forms / Contact Form 7 / WPForms — forms
+- The Events Calendar — event post type
+- Custom plugin folders (not from wordpress.org)
+
+**Low priority** (usually don't need porting):
+- Yoast SEO / Rank Math — SEO meta (can note fields but not critical)
+- Caching plugins (W3 Total Cache, WP Rocket)
+- Security plugins (Wordfence, Sucuri)
+- Backup plugins
+
+**Builder plugins** (affect how templates work):
+- Elementor / Elementor Pro
+- WPBakery / Visual Composer
+- Divi Builder
+- Beaver Builder
+
+Note: If a builder plugin is present, templates may be stored in the database rather than theme files.
+
+### 2d. Database Analysis
+
+If database access is available (direct connection or SQL dump), run these diagnostic queries:
+
+```sql
+-- Custom post types in use (beyond standard post/page/attachment)
+SELECT post_type, COUNT(*) as count
+FROM wp_posts
+WHERE post_status = 'publish'
+  AND post_type NOT IN ('post', 'page', 'attachment', 'revision', 'nav_menu_item', 'wp_template', 'wp_template_part', 'wp_global_styles', 'wp_navigation')
+GROUP BY post_type
+ORDER BY count DESC;
+
+-- Custom taxonomies in use (beyond standard category/post_tag)
+SELECT taxonomy, COUNT(*) as term_count
+FROM wp_term_taxonomy
+WHERE taxonomy NOT IN ('category', 'post_tag', 'nav_menu', 'link_category', 'post_format', 'wp_theme', 'wp_template_part_area')
+GROUP BY taxonomy
+ORDER BY term_count DESC;
+
+-- Custom meta keys (reveals ACF fields, custom meta)
+-- Excludes WordPress internal keys (prefixed with _)
+SELECT meta_key, COUNT(*) as usage_count
+FROM wp_postmeta
+WHERE meta_key NOT LIKE '\_%'
+GROUP BY meta_key
+ORDER BY usage_count DESC
+LIMIT 30;
+
+-- ACF field groups (if ACF is used)
+SELECT post_title, post_name
+FROM wp_posts
+WHERE post_type = 'acf-field-group'
+  AND post_status = 'publish';
+
+-- Shortcodes in content (indicates embedded functionality)
+SELECT post_type, COUNT(*) as posts_with_shortcodes
+FROM wp_posts
+WHERE post_content REGEXP '\\[[a-zA-Z0-9_-]+.*\\]'
+  AND post_status = 'publish'
+GROUP BY post_type;
+
+-- Gutenberg blocks in use (for block themes)
+SELECT
+  SUBSTRING_INDEX(SUBSTRING_INDEX(post_content, '<!-- wp:', -1), ' ', 1) as block_type,
+  COUNT(*) as usage_count
+FROM wp_posts
+WHERE post_content LIKE '%<!-- wp:%'
+  AND post_status = 'publish'
+GROUP BY block_type
+ORDER BY usage_count DESC
+LIMIT 20;
+```
 
-- **Custom post types** registered via `register_post_type()` → these become Laravel models
-- **Taxonomies** registered via `register_taxonomy()` → these become models or enums
-- **Navigation menus** registered via `register_nav_menus()` → these define nav structure
-- **Widget areas** registered via `register_sidebar()` → note for layout
-- **Enqueued scripts/styles** via `wp_enqueue_script/style()` → note any JS dependencies
-- **Custom image sizes** via `add_image_size()` → note for media handling
-- **Theme supports** via `add_theme_support()` → note post formats, thumbnails, etc.
-- **Shortcodes** via `add_shortcode()` → these become Blade includes or components
-- **AJAX handlers** via `wp_ajax_*` → these become API routes
-- **Any included files** → read those too
+### 2e. Produce Analysis Report
 
-## Step 4 — Plan the Laravel Structure
+Present a structured summary before proceeding:
 
-Before calling any Stellify tools, plan:
+```
+## WordPress Site Analysis
+
+### Theme
+- Name: theme-name
+- Type: Classic PHP / Block theme
+- Template files: [count]
+
+### Content Summary
+- Posts: [count]
+- Pages: [count]
+- [custom-type]: [count]
+
+### Custom Post Types
+| Name | Slug | Supports | Count |
+|------|------|----------|-------|
+| Portfolio | project | title, editor, thumbnail | 34 |
+| Testimonial | testimonial | title, editor | 12 |
+
+### Custom Taxonomies
+| Name | Slug | Attached To | Hierarchical | Terms |
+|------|------|-------------|--------------|-------|
+| Project Type | project_type | project | Yes | 5 |
+
+### Custom Fields (non-standard meta keys)
+| Key | Used By | Count |
+|-----|---------|-------|
+| project_client | project | 34 |
+| project_url | project | 34 |
+| testimonial_company | testimonial | 12 |
+
+### Plugins Requiring Attention
+- Advanced Custom Fields Pro — field definitions above
+- Contact Form 7 — 2 forms found
+
+### Content Flags
+- 15 posts contain shortcodes (will need processing during content migration)
+- Page builder detected: Elementor (some layouts stored in database)
+
+### Generation Plan
+**Will generate:**
+- Model: Project (custom post type)
+- Model: Testimonial (custom post type)
+- Model: ProjectType (custom taxonomy)
+- Add fields to models: client, url, company
+
+**Standard (already scaffolded):**
+- Post, Page, Category, Tag, User, Media
+
+**Manual attention needed:**
+- Contact forms (2) — recreate in Laravel
+- Shortcodes in content — process during migration
+- Elementor layouts — extract design intent from theme templates
+```
 
-- **Models:** One per post type (Post, Page, plus any custom types from Step 3)
-- **Controllers:** One per model with index/show actions
-- **Routes:** Match WordPress URL structure (archive at `/`, singles at `/{slug}`, taxonomies at `/category/{slug}`)
-- **Views:** Mirror WordPress template hierarchy — layout from header+footer, index/show views per post type, partials from template-parts
-- **Migrations (Mode B only):** One per model with fields from WordPress core + any custom fields found in templates
+After presenting the report, ask:
 
-## Step 5 — Build in Stellify (Order of Operations)
+> Does this analysis look correct? Ready to proceed with generating the custom resources?
 
-Execute the plan using Stellify MCP tools in this order. This order matters — parent records must exist before children.
+## Step 3 — Generate Custom Resources
 
-### 5a. Create Models, Migrations & Controllers
+For each custom post type and taxonomy identified, create the necessary Laravel resources using Stellify MCP tools.
 
-Use the `create_resources` tool with `api: false` to generate models and controllers together. The `api: false` flag ensures controller methods return data arrays (for Blade views) rather than JSON responses.
+### 3a. Custom Post Type Models
 
-**Route Model Binding with Slugs:** WordPress URLs use slugs (e.g., `/post/my-article-title`). After creating each model with a `slug` field, add a `getRouteKeyName()` method so Laravel's route model binding works correctly:
+For each custom post type, use `create_resources` with `api: false`:
 
-```php
-public function getRouteKeyName(): string
-{
-    return 'slug';
-}
-```
+**Model requirements:**
+- Table name matching the post type slug (e.g., `projects`, `testimonials`)
+- Standard fields: `title`, `slug`, `content`, `excerpt`, `status`, `published_at`, `author_id`
+- Custom fields identified from meta analysis
+- `getRouteKeyName()` returning `'slug'` for URL-friendly routing
+- Relationships to custom taxonomies
 
-Add this method to **Post**, **Category**, **Tag**, and any custom post type models that use slugs in their URLs. Without this, routes like `/post/{post}` will try to look up by ID instead of slug, causing 404 errors.
+**Migration requirements:**
+- All standard fields plus custom fields
+- Foreign keys to users table for author
+- Indexes on slug, status, published_at
 
-**If Mode A (connect to existing WordPress database):**
+**Controller requirements:**
+- `index()` returning paginated published items
+- `show($model)` returning single item
+- Return arrays (Stellify convention), not views or JSON
 
-Create resources that map to the existing WordPress tables. No migrations. Set the model's table and primary key to match WordPress.
+Example model structure:
 
 ```php
-// Example Post model
-class Post extends Model {
-    protected $table = 'wp_posts';
-    protected $primaryKey = 'ID';
+class Project extends Model
+{
+    protected $fillable = [
+        'title', 'slug', 'content', 'excerpt',
+        'status', 'published_at', 'author_id',
+        'client', 'url', // custom fields
+    ];
+
+    protected $casts = [
+        'published_at' => 'datetime',
+    ];
 
-    // Enable slug-based route model binding (WordPress uses post_name for slugs)
     public function getRouteKeyName(): string
     {
-        return 'post_name';
+        return 'slug';
     }
 
-    // Scope to only published posts (not revisions, drafts, etc.)
-    public function scopePublished($query) {
-        return $query->where('post_status', 'publish')
-                     ->where('post_type', 'post');
+    public function author(): BelongsTo
+    {
+        return $this->belongsTo(User::class, 'author_id');
     }
-}
-```
-
-Key WordPress table mappings:
-- Posts & Pages → `wp_posts` (distinguished by `post_type` column: 'post', 'page', or custom types)
-- Categories & Tags → `wp_terms` + `wp_term_taxonomy` + `wp_term_relationships`
-- Users → `wp_users`
-- Post meta / custom fields → `wp_postmeta`
-- Comments → `wp_comments`
-- Navigation menus → `wp_posts` with `post_type = 'nav_menu_item'` + `wp_terms` with taxonomy `nav_menu`
-
-In Blade templates, use WordPress column names:
-- `$post->post_title` (not `$post->title`)
-- `$post->post_content` (not `$post->content`)
-- `$post->post_excerpt` (not `$post->excerpt`)
-- `$post->post_name` (this is the slug)
-- `$post->post_date` (not `$post->published_at`)
-- `$post->post_status` (not `$post->status`)
-
-**If Mode B (fresh database):**
-
-Create new resources with clean Laravel migrations for each model identified in Step 4. Use clean column names (`title`, `slug`, `content`, `excerpt`, `status`, `published_at`, etc.). After the import is complete, suggest a data migration SQL query or artisan command that maps data from the WordPress tables to the new schema.
-
-For each model with a `slug` field, add `getRouteKeyName()`:
-
-```php
-public function getRouteKeyName(): string
-{
-    return 'slug';
-}
-```
-
-### 5b. Refine Controller Methods
 
-`create_resources` (Step 5a) scaffolds controllers automatically. Review and refine the generated methods to ensure they query the right data. Controller methods in Stellify return data arrays — Stellify automatically merges these into the Blade view context. For example:
-
-```php
-// CORRECT for Stellify — returns a data array, Stellify handles the view binding
-public function index(): array
-{
-    return ['posts' => Post::where('status', 'published')->latest('published_at')->paginate(10)];
-}
-
-public function show(Post $post): array
-{
-    return ['post' => $post];
-}
-
-// WRONG — do not return JSON
-public function index()
-{
-    return Post::where('status', 'published')->get();
-}
+    public function projectTypes(): BelongsToMany
+    {
+        return $this->belongsToMany(ProjectType::class);
+    }
 
-// WRONG — do not call view() directly, Stellify handles this
-public function index()
-{
-    return view('posts.index', compact('posts'));
+    public function scopePublished($query)
+    {
+        return $query->where('status', 'published');
+    }
 }
 ```
 
-**Mode A note:** WordPress stores posts, pages, and custom post types all in `wp_posts`, distinguished by the `post_type` column. Controllers must scope queries accordingly — e.g. `Post::where('post_type', 'post')->where('post_status', 'publish')`. It also stores revisions and auto-drafts in the same table, so always filter by `post_status`.
-
-### 5c. Create Routes
-Create route entries mapping URLs to controller methods.
-
-### 5d. Create the Layout (layouts/app.blade.php)
-Read header.php and footer.php. Create a single Blade layout that combines:
-- The HTML structure from header.php (doctype, head, opening body, nav)
-- `@yield('content')` for page content
-- The structure from footer.php (closing elements, footer content)
-
-Translate WordPress functions to Blade:
-- `wp_head()` → `@vite(['resources/css/app.css', 'resources/js/app.js'])` and `<meta>` tags
-- `wp_footer()` → nothing needed (Vite handles it)
-- `wp_nav_menu()` → `@include('partials.nav')`
-- `bloginfo('name')` → `{{ config('app.name') }}`
-- `bloginfo('description')` → `{{ config('app.description', '') }}`
-- `body_class()` → appropriate Tailwind classes
-- `language_attributes()` → `lang="{{ str_replace('_', '-', app()->getLocale()) }}"`
-
-### 5e. Create Blade Views
-For each WordPress template file, read the PHP and create the equivalent Blade view using `html_to_elements`. **All views use `@extends('layouts.app')` and `@section('content')`.**
-
-**⚠️ Multiple Root Elements:** When converting HTML with multiple root-level elements (e.g., `<header>`, `<main>`, `<footer>`), only the first root element gets attached to the route. Make separate `html_to_elements` calls for each root element.
+### 3b. Custom Taxonomy Models
 
-**WordPress → Blade translation guide:**
+For each custom taxonomy:
 
-Mode A uses WordPress column names; Mode B uses clean Laravel names.
+**Model requirements:**
+- Table name matching taxonomy slug (e.g., `project_types`)
+- Fields: `name`, `slug`, `description`, `parent_id` (if hierarchical)
+- `getRouteKeyName()` returning `'slug'`
+- Relationship to associated post types via pivot table
 
-**IMPORTANT:** Inside `@foreach` loops, use `$item` as the loop variable. This matches the Stellify assembler's expectations for `textField`, `hrefField`, `srcField` attributes.
+**Migration requirements:**
+- Main taxonomy table
+- Pivot table linking to each associated post type (e.g., `project_project_type`)
 
-| WordPress | Blade (Mode A) | Blade (Mode B) | Stellify Attribute |
-|-----------|----------------|----------------|-------------------|
-| `the_title()` | `{{ $item->post_title }}` | `{{ $item->title }}` | `textField: "title"` |
-| `the_content()` | `{!! $item->post_content !!}` | `{!! $item->content !!}` | statement with code |
-| `the_excerpt()` | `{{ $item->post_excerpt }}` | `{{ $item->excerpt }}` | `textField: "excerpt"` |
-| `the_permalink()` | `{{ route('posts.show', $item->post_name) }}` | `{{ route('posts.show', $item->slug) }}` | `hrefExpression: "..."` |
-| `the_date()` | `{{ $item->post_date->format('d M Y') }}` | `{{ $item->published_at->format('d M Y') }}` | statement with code |
-| `the_author()` | `{{ $item->author->display_name }}` | `{{ $item->author->name }}` | statement with code |
-| `get_template_part()` | `@include('partials.post-card', ['post' => $item])` | same | s-directive |
-| `have_posts()` | `@foreach($posts as $item)` | same | s-directive pair |
+### 3c. Routes
 
-**Conditional Rendering with `s-directive`:**
+Create routes following WordPress URL conventions where sensible:
 
-WordPress blocks that render conditionally (like `<!-- wp:post-featured-image -->`) use `s-directive` elements. See the MCP tool documentation for the sibling pattern — create an opening directive, content elements, then a closing directive as siblings.
-
-Common WordPress conditionals to convert (use `$item` inside loops):
-- `<!-- wp:post-featured-image -->` → `@if($item->featured_image)` ... `@endif`
-- `<!-- wp:post-excerpt -->` → `@if($item->post_excerpt)` ... `@endif`
-- `<!-- wp:post-comments -->` → `@if($item->comments->count() > 0)` ... `@endif`
-- `<!-- wp:query-no-results -->` → `@if($posts->isEmpty())` ... `@endif` (outside loop)
-
-**Iteration (The Loop):**
+```php
+// Custom post type archives and singles
+Route::get('/projects', [ProjectController::class, 'index'])->name('projects.index');
+Route::get('/projects/{project}', [ProjectController::class, 'show'])->name('projects.show');
 
-WordPress's "The Loop" (`have_posts() / the_post()`) maps to `@foreach` directives. Use `s-directive` elements for the opening `@foreach` and closing `@endforeach`.
+// Custom taxonomy archives
+Route::get('/project-type/{projectType}', [ProjectTypeController::class, 'show'])->name('project-types.show');
+```
 
-**IMPORTANT - Loop Variable:** The default loop variable is `$item`. When creating elements inside a loop:
-1. Do NOT pass raw Blade syntax to `html_to_elements` — it will be stored literally
-2. Create clean HTML first, then use `update_element` to add dynamic attributes:
-   - `textField: "title"` → outputs `{{ $item->title }}`
-   - `hrefField: "slug"` → outputs `href="{{ $item->slug }}"`
-   - `srcField: "featured_image"` → outputs `src="{{ $item->featured_image }}"`
-3. For complex expressions (route helpers, method calls), use:
-   - `hrefExpression: "{{ route('posts.show', $item->slug) }}"`
-   - `srcExpression: "{{ $item->featured_image }}"`
-4. For text with Blade code, create a statement with `create_statement_with_code`, then add its UUID to the element's `statements` array via `update_element`
+## Step 4 — Document Manual Tasks
 
-Example loop structure using `s-directive` siblings:
-```
-1. s-directive with statement: "@foreach($posts as $item)"
-2. article element (content to repeat)
-3. s-directive with statement: "@endforeach"
-```
+Create a summary of items requiring manual attention:
 
-### 5f. Create Partials & Components
-Convert template-parts/ files into Blade partials using `@include`. Static partials receive data via the second argument: `@include('partials.post-card', ['post' => $post])`. If a template part relies on JavaScript for interactivity (e.g. a slider, a filterable gallery, a live search form), create a Vue component instead and ensure it is registered and mounted in `app.js`.
+### Forms
+List each form found with fields and purpose. The user will need to recreate these using Laravel form handling or a package like Laravel Livewire.
 
-### 5g. Style with Tailwind
-Do not try to port WordPress CSS. Read the visual intent from the theme's CSS/theme.json and apply Tailwind utility classes directly in the Blade templates. For example:
-- WordPress container → `<div class="max-w-4xl mx-auto px-4">`
-- WordPress navigation → `<nav class="flex items-center gap-6">`
-- WordPress post grid → `<div class="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-8">`
+### Shortcodes in Content
+List shortcodes found and their apparent purpose. These will need to be:
+1. Processed during content migration (find/replace with HTML)
+2. Or converted to Blade components if they need to remain dynamic
 
-## Step 6 — Review (Optional)
+### Plugin Functionality
+For significant plugins (WooCommerce, membership plugins, booking systems), note that this functionality needs separate planning and is outside the scope of this import.
 
-If requested, summarize what was created and note any WordPress features that couldn't be mapped.
+### Content Migration
+Note that content migration is a separate step. The user will need to:
+1. Export content from WordPress (WP-CLI, plugin, or direct SQL)
+2. Transform data to match new schema
+3. Import into Laravel database
+4. Process/clean embedded shortcodes
+5. Migrate media files and update URLs
 
 ## Important Rules
 
-- **Blade for SSR, Vue for interactivity.** If the WordPress source is server-rendered PHP (posts, pages, archives, menus, layouts), create Blade templates using `@extends`, `@section`, `@include`, `@foreach`, `{{ }}` and `{!! !!}`. If the WordPress source uses JavaScript for interactivity (AJAX, dynamic filtering, sliders, modals, live search, infinite scroll), create a Vue component. When creating Vue components, ensure they are registered and mounted in `app.js` via `createApp` — do not just import them.
-- **Do not ask questions** except the two permitted in Step 1 (which theme, and which database mode). Make reasonable decisions and document them.
-- **Work file by file** — read a WordPress file, create the Stellify equivalent, move to the next.
-- **Show progress** — print what you're reading and what you're creating as you go.
-- **Handle block themes** — if theme.json exists and templates are in HTML with block markup (`<!-- wp:xxx -->`), parse the block structure rather than traditional PHP templates. The output is still Blade (or Vue where the block is interactive).
-- **Style with Tailwind** — do not port WordPress CSS. Interpret the visual intent and use Tailwind utilities.
-- **Be pragmatic** — focus on the core templates that define the site's main pages. Skip hyper-specific template variations unless they're clearly important.
-- **Content handling depends on database mode** — In Mode A (existing DB), the content is already there via the WordPress tables. In Mode B (fresh DB), content is separate and can be migrated later.
+- **Analysis first** — Always complete the full analysis before generating any code
+- **Only generate custom elements** — Standard WordPress models come from the scaffold
+- **Fresh database only** — This skill assumes a clean Laravel database, not connecting to WordPress tables
+- **No template conversion** — Visual design/styling is handled by a separate skill
+- **Document unknowns** — Flag anything that can't be automatically converted
+- **Be pragmatic** — Focus on post types and taxonomies actually in use (have content), not just registered