# Comprehensive Plugin Features Extraction Prompt

Use this prompt template for extracting features from any WordPress/Divi plugin. Replace `Divi BodyCommerce` with the actual plugin name.

---

## Main Prompt

```
I need you to create a comprehensive list of ALL user-facing features for the Divi BodyCommerce plugin. This list will be imported into a Supabase RAG database to be used by an n8n agent for support tickets, documentation, and blog posts.

## Your Task

1. **Thoroughly explore the codebase** to identify every user-facing feature
2. **Categorize each feature** with complete metadata for RAG processing
3. **Distinguish between internal and external features** accurately
4. **Check for duplicates** and ensure each feature appears only once
5. **Organize features** by logical groupings (modules, categories, etc.)

## What Counts as a "User-Facing Feature"

Include features that:
- ✅ Users actively configure or interact with
- ✅ Solve business problems or user needs
- ✅ Are visible in the UI (frontend or backend)
- ✅ Represent capabilities worth documenting/marketing
- ✅ Control major behavior, display, or functionality
- ✅ Are configurable settings that affect output/behavior

Exclude:
- ❌ Internal implementation details (API endpoints, handlers, internal functions)
- ❌ Code structure/organization details
- ❌ Developer-only technical details
- ❌ Features that are purely internal-facing (not user-visible)

## Metadata Schema

Each feature must include this metadata format:

```
- **Feature Name** - Brief description of what the feature does.
  - Metadata: `module: [MODULE_NAME] | component_type: [TYPE] | layer: [LAYER] | platform: [PLATFORM] | category: [CATEGORY] | requires: [DEPENDENCIES] | use_case: [USE_CASE]`
```

### Metadata Fields Explained

**module**: The parent module/component this feature belongs to
- Use module names like: `FilterPosts`, `ArchiveLoop`, `FilterPostsItem`, `PostTitle`, `Thumbnail`
- Use `core` for plugin-wide features not tied to a specific module

**component_type**: The type of component
- `module` - A full module/component
- `filter_type` - A specific filter type
- `template` - Template/layout option
- `ui_helper` - UI enhancement/helper
- `server_feature` - Server-side capability
- `setting` - A configurable setting
- `core_feature` - Core plugin functionality

**layer**: Where the feature operates
- `frontend` - User-facing frontend
- `backend` - Backend/admin area
- `server_side` - Server-side processing
- `settings` - Settings/configuration area
- `both` - Both frontend and backend

**platform**: Which platforms it supports
- `divi_4` - Divi 4 only
- `divi_5` - Divi 5 only
- `gutenberg` - Gutenberg blocks
- `common` - All platforms
- Use comma-separated for multiple: `divi_4,divi_5`

**category**: Feature category
- `filtering` - Filtering/search capabilities
- `rendering` - Display/rendering features
- `ui` - User interface elements
- `performance` - Performance optimizations
- `configuration` - Configuration options
- `core` - Core plugin functionality

**requires**: Optional dependencies (comma-separated if multiple)
- `woocommerce` - Requires WooCommerce
- `acf` - Requires Advanced Custom Fields
- `pro` - Requires pro version
- Omit if no dependencies

**use_case**: CRITICAL - Internal vs External
- `external` - Marketing/documentation-worthy, user-facing capability
- `internal` - Support-only, fine-grained technical detail

## Use Case Determination Guidelines

### Use `external` for:

1. **Query/Filtering Capabilities**
   - Post type selection, category/tag filtering, taxonomy filtering
   - Search functionality, ACF field filtering
   - WooCommerce product filtering (price, attributes, rating, stock)
   - Date range filtering, custom field filtering
   - Sorting options, pagination modes

2. **Display/Rendering Features**
   - Layout options (grid, list, masonry)
   - Template selection (loop templates, custom layouts)
   - Result display methods
   - Map integration, grouping by taxonomy
   - List/grid switcher, result count display

3. **Design Customization (Major)**
   - Loop template design customization
   - Button style customization
   - Grid column configuration
   - Major layout options (side panel, inline, etc.)

4. **User-Facing Functionality**
   - Ajax filtering, instant updates
   - Load more, infinite scroll
   - Mobile toggle, responsive features
   - Filter synchronization
   - URL parameter filtering

5. **Integration Features**
   - WooCommerce compatibility
   - ACF integration
   - WPML translation support
   - Gutenberg block support

6. **Performance Features (User-Visible)**
   - Caching capabilities (transient, Redis, Memcached)
   - Performance optimizations users can configure

### Use `internal` for:

1. **Granular Styling Details**
   - Specific padding/margin values
   - Icon sizes, colors (unless it's a major customization feature)
   - Border radius, box shadow details
   - Font sizes, spacing values

2. **Technical Implementation Details**
   - CSS selectors, element IDs
   - Specific field names, column mappings
   - Internal configuration options
   - Developer-only settings

3. **Fine-Tuning Options**
   - Placeholder text customization
   - Button text customization (unless it's a major feature)
   - Icon selection (unless it's a major UI feature)
   - Specific delay/buffer values

4. **Support-Only Settings**
   - Options that support teams need but aren't marketing-worthy
   - Very specific technical configurations
   - Implementation details that don't represent capabilities

## Exploration Strategy

### Step 1: Initial Discovery
1. Read the main plugin file (`[plugin-name].php`)
2. Check for a `changelog.txt` or `CHANGELOG.md` file
3. List the directory structure to understand organization
4. Look for module definitions (check for `module.json` files, module directories)

### Step 2: Module Exploration
For each module/component:
1. Read module configuration files (`module.json`, `config.php`, etc.)
2. Read renderer files (`Renderer.php`, `render.php`, etc.)
3. Check for settings/configuration components
4. Look for filter types, display types, etc.

### Step 3: Feature Extraction
For each module, extract:
- All configurable settings
- All filter types
- All display options
- All UI helpers
- All templates
- All integration features

### Step 4: Cross-Reference
1. Check frontend JavaScript files for UI features
2. Check backend PHP files for server-side features
3. Look for integration files (WooCommerce, ACF, etc.)
4. Check settings/admin pages

### Step 5: Categorization
1. Assign each feature to its parent module
2. Determine component_type, layer, platform, category
3. Identify dependencies (requires field)
4. **CRITICALLY** determine use_case (internal vs external)

### Step 6: Organization
1. Group features by logical sections
2. Use clear section headers
3. Ensure features are in the most appropriate section
4. Check for duplicates across sections

### Step 7: Validation
1. Verify no duplicates exist
2. Ensure all features have complete metadata
3. Verify use_case assignments are accurate
4. Check that all user-facing features are included

## Common Areas to Check

- **Module definitions**: Look for `module.json`, `config.php`, module directories
- **Renderer files**: `Renderer.php`, `render.php`, frontend output files
- **Settings components**: React/JSX components, settings panels
- **Filter types**: Check for filter type definitions, filter item modules
- **Templates**: Look for template directories, template picker options
- **Integration files**: WooCommerce, ACF, WPML integration files
- **Admin pages**: Settings pages, configuration screens
- **Frontend assets**: JavaScript files for UI features
- **Changelog**: Often lists features that might be missed

## Output Format

Create a **JSON file** with an array of feature objects. This format is easier to import into Supabase and use with n8n.

### JSON Structure

```json
{
  "features": [
    {
      "name": "Feature Name",
      "description": "Description of what this feature does.",
      "section": "Section Name (optional, for organization)",
      "module": "ModuleName",
      "component_type": "setting",
      "layer": "frontend",
      "platform": ["common"],
      "category": "ui",
      "requires": null,
      "use_case": "external"
    }
  ]
}
```

### Field Details

- `name`: Feature name (string)
- `description`: What the feature does (string)
- `section`: Optional section/category for organization (string or null)
- `module`: Parent module name (string)
- `component_type`: One of: module, filter_type, template, ui_helper, server_feature, setting, core_feature
- `layer`: One of: frontend, backend, server_side, settings, both
- `platform`: Array of platforms: ["divi_4"], ["divi_5"], ["gutenberg"], ["common"], or multiple like ["divi_4", "divi_5"]
- `category`: One of: filtering, rendering, ui, performance, configuration, core
- `requires`: Array of dependencies like ["woocommerce"], ["acf"], ["woocommerce", "acf"], or null if none
- `use_case`: Either "external" or "internal"

### Example JSON Output

```json
{
  "features": [
    {
      "name": "Ajax Loaded Filtering",
      "description": "Updates results instantly with Ajax (no page reload) when filters, sorting, or pagination are used.",
      "section": "Core / UX",
      "module": "core",
      "component_type": "core_feature",
      "layer": "both",
      "platform": ["common"],
      "category": "core",
      "requires": null,
      "use_case": "external"
    },
    {
      "name": "WooCommerce HPOS Compatibility",
      "description": "Fully compatible with WooCommerce High-Performance Order Storage for modern WooCommerce setups.",
      "section": "Core / UX",
      "module": "core",
      "component_type": "core_feature",
      "layer": "backend",
      "platform": ["common"],
      "category": "core",
      "requires": ["woocommerce"],
      "use_case": "external"
    }
  ]
}
```

### Important JSON Formatting

- Use proper JSON syntax (quotes, commas, brackets)
- Ensure all strings are properly quoted
- Use `null` for optional fields when not applicable
- Use arrays for `platform` and `requires` (even if single value)
- Validate JSON before finalizing (use a JSON validator)

## Quality Checklist

Before finalizing, verify:

- [ ] All modules have been explored
- [ ] All filter types are documented
- [ ] All display options are included
- [ ] All templates are listed
- [ ] All UI helpers are documented
- [ ] All integration features are included
- [ ] All settings are categorized
- [ ] No duplicates exist
- [ ] All metadata is complete
- [ ] use_case is accurately assigned (not too conservative!)
- [ ] Features are organized logically
- [ ] Only user-facing features are included (no internal implementation details)

## Important Reminders

1. **Be thorough** - Explore the entire codebase, don't just look at obvious files
2. **Don't be too conservative** - If a feature is user-configurable and solves a problem, it's likely `external`
3. **Check for duplicates** - Same feature might appear in multiple sections
4. **Module assignment** - Every feature should be assigned to a module (use `core` if none)
5. **Complete metadata** - Every feature needs all metadata fields
6. **User-facing focus** - Only include features users interact with or configure

## Start Here

Begin by:
1. Reading the main plugin file
2. Exploring the directory structure
3. Identifying all modules
4. Systematically extracting features from each module
5. Categorizing with complete metadata
6. Organizing into logical sections (use `section` field in JSON)
7. Validating for completeness and accuracy
8. **Output as valid JSON** - ensure proper JSON formatting

Take your time and be thorough. It's better to be comprehensive than to miss features.

**CRITICAL**: Output must be valid JSON format, not Markdown. Use the JSON structure shown above.
```

---

## Usage Instructions

1. Copy the prompt above
2. Replace `Divi BodyCommerce` with your actual plugin name
3. Replace `[plugin-name]` with the actual plugin file name
4. Send to a new AI session
5. The AI should systematically explore and document all features

## Expected Output

The AI should produce a markdown file similar to `plugin-features.md` with:
- Complete feature list
- Accurate metadata for each feature
- Proper use_case assignments (not too conservative)
- No duplicates
- Logical organization
- Only user-facing features