codebase-to-wordpress-converter
About codebase-to-wordpress-converter
A skill for converting static or React-based frontends into editable WordPress themes while auditing visual structure and technical SEO. Its phased process separates comparison, audit, risk-classified planning, and incremental fixes with validation.
Key features
- 01Phased UI comparison and audit
- 02React and HTML content field mapping
- 03WordPress hooks and dynamic navigation
- 04SEO and CMS editability checks
- 05Incremental fixes with validation
Use cases
- 01Converting a React frontend into a WordPress theme
- 02Migrating a static HTML project to WordPress
- 03Auditing an existing conversion for SEO issues
- 04Tracking UI differences before making fixes
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ sickn33/ agentic-awesome-skills --skill codebase-to-wordpress-converterAfter installing, type/codebase-to-wordpress-converterin Claude Code to confirm it loaded.
Details
From the project READMECodebase to WordPress Converter
Overview
This skill is designed for the high-fidelity conversion of static or React-based frontends into fully functional, CMS-driven WordPress themes. It acts as a Senior WordPress Architect, React Expert, and QA Engineer to ensure a 100% pixel-perfect match while integrating deep WordPress functionality like ACF, dynamic menus, and technical SEO preservation.
When to Use This Skill
- Use when converting a React (CRA/Vite/Next.js) or HTML project into a WordPress theme.
- Use when the client demands a 100% pixel-perfect match with the original source.
- Use when auditing an existing WordPress conversion for structural or SEO flaws.
- Use when you need to ensure technical SEO (Schema, Meta tags, Heading hierarchy) is preserved exactly.
Core Capabilities
Phased Conversion & Audit
The skill follows a strict 4-phase forensic process:
- Phase 1: Forensic UI Comparison: Side-by-side table audit of React components vs. WordPress templates to find discrepancies.
- Phase 2: Full Audit: Deep dive into UI, SEO, CMS Editability, Navigation, Functionality, and Performance.
- Phase 3: Action Plan: Tasks classified as SAFE, RISKY, or BLOCKED to prevent breaking the UI.
- Phase 4: Iterative Fixing: Executing one safe task at a time with validation after each step.
Absolute UI Lock
Use these as visual-parity goals. Security, valid markup and accessible navigation may require a documented structural change; report that tradeoff instead of promising impossible parity:
- No alterations to layout, spacing, typography, or colors.
- Exact preservation of Tailwind or CSS class names.
- Zero changes to DOM structure or HTML nesting.
Step-by-Step Guide
1. Discovery & Forensic Audit
Start by identifying all components in the source code. Create a UI Comparison table comparing the original source output against the target WordPress output.
- Rule: No fixes are allowed during this phase; only detection.
2. Strategic Field Mapping
Map static React/HTML content to dynamic WordPress functions:
- Replace static text with
the_title(),get_field(), orthe_content(). - Replace static paths with
get_template_directory_uri().
3. Implementation of Core Hooks
Ensure every theme includes the foundational WordPress hooks correctly:
- Layout Files (
header.php/footer.php): Must includewp_head()before</head>andwp_footer()before</body>. - Page Templates: Must call
get_header()andget_footer(). register_nav_menus()for dynamic navigation without breaking original HTML structure.
4. Validation & Live Tracker
Maintain a live tracker of Total Issues, Fixed, and Remaining. Every fix must be followed by a confirmation:
- ✅ No UI change
- ✅ No DOM change
- ✅ No class change
Examples
Example 1: Navigation Conversion
// WRONG: Static replacement that adds wrappers
wp_nav_menu(['theme_location' => 'primary']);
// CORRECT: Preserving original Tailwind classes and structure
wp_nav_menu([
'theme_location' => 'primary',
'container' => false,
'items_wrap' => '<ul class="flex space-x-8">%3$s</ul>',
'walker' => new Custom_Tailwind_Walker()
]);
Example 2: Asset Pathing
// Source: <img src="/images/logo.png" />
// WP Conversion:
<img src="<?php echo esc_url( get_template_directory_uri() . "/assets/images/logo.png" ); ?>" alt="Logo" />
Best Practices
- ✅ Do: Use
get_page_by_path()for robust internal linking. - ✅ Do: Implement ACF (Advanced Custom Fields) fallbacks in
functions.php. - ✅ Do: Build Tailwind through the project asset pipeline and enqueue compiled CSS with WordPress hooks; do not rely on a runtime Tailwind configuration in
header.php. Escape dynamic text, attributes and URLs for their output context; preserve intended rich content through approved WordPress filters. - ❌ Don't: Add "div" wrappers or rename classes to "clean up" the code.
- ❌ Don't: Use standard WordPress default styles if they conflict with the original design.
Additional Resources
Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.