Scaffold Command Laravel Package

Product Decisions This Supports

• Developer-experience (DX) investment sizing. The package answers "how much of our WordPress boilerplate can be generated instead of hand-written?" For a team standing up custom post types and taxonomies repeatedly, wp scaffold post-type / wp scaffold taxonomy (aliases cpt / tax, with --raw for snippet-only output and --theme / --plugin targeting) collapse a recurring 30–60 minute task into a reviewed one-liner. That is a measurable onboarding/ticket-time lever, not a feature.
• Build vs. buy vs. adopt. Because it ships inside WP-CLI, the "buy" cost is zero and the "build" alternative (an internal generator, a starter repo, or a Composer template) only makes sense if you need opinionated conventions this tool won't produce. Default to adopt; revisit only if you find yourself post-processing generated files on every project.
• Standards enforcement. Generated files carry your plugin/theme headers, text domains, .editorconfig, .distignore, .gitignore, and a --ci=<circle|gitlab|bitbucket|github> CI config. That makes it a cheap mechanism for making conventions the path of least resistance across squads and agencies.
• Test-harness bootstrapping as a roadmap item. wp scaffold plugin-tests and wp scaffold theme-tests (PHPUnit config, bin/install-wp-tests.sh, bootstrap, sample test, PHPCS ruleset) are the highest-leverage part of this package. If "we have no automated tests on legacy WordPress code" is on your roadmap, this is a same-day starting point rather than a quarter-long initiative.
• Legacy vs. greenfield routing. The README itself now says scaffolding plugins and themes via wp scaffold is no longer recommended for modern WordPress, and wp scaffold block is explicitly deprecated in favor of @wordpress/create-block. That is a decision input: scope this tool to CPT/taxonomy generation and test scaffolding, and route new block/theme work to the modern toolchain. It also caps how much roadmap you should attach to it.
• Not a differentiator. No customer-visible surface, no revenue path. Treat as internal productivity plumbing — it belongs in an engineering-enablement line item, not a product bet.
• Platform-mismatch check. This is a WordPress-specific WP-CLI package. If the actual product stack is Laravel, the equivalent decision is php artisan make:*, published package stubs, and Pest/PHPUnit bootstrapping — not this package. Confirm the stack before it enters a plan.

When to Consider This Package

Consider it when:

• You are already on WP-CLI (it is bundled — no install step, no new supply-chain surface) and manage more than a handful of WordPress sites.
• You need repeatable, consistent registration code for custom post types and taxonomies across themes or plugins; --raw, --theme=<slug>, and --plugin=<slug> cover both snippet-paste and file-generation workflows.
• You are retrofitting tests onto existing plugins/themes and want PHPUnit + CI config generated in minutes, with WP_TESTS_DIR as the documented integration point.
• You need child themes (wp scaffold child-theme --parent_theme=<slug>) or an _s-based theme with --sassify / --woocommerce options.
• You want scaffolding that is scriptable and CI-friendly — every command takes flags, supports --force, and can --activate / --enable-network for automated environment setup.

Look elsewhere when:

• You are building Gutenberg blocks — use @wordpress/create-block; wp scaffold block is deprecated and will produce outdated build configs.
• You are building block themes or modern plugins needing maintained JS build tooling — the generated plugin ships a Grunt-based Gruntfile.js and grunt-wp-i18n / grunt-wp-readme-to-markdown, which is dated relative to @wordpress/scripts.
• Your stack is Laravel or another non-WordPress PHP framework — nothing here applies.
• You need a full application/boilerplate generator with domain modeling, migrations, or auth — this is file templating, not a framework.
• You require a project with active, first-class maintenance signals on this surface. Release cadence is healthy and it is MIT-licensed and battle-tested, but the maintainers are publicly de-emphasizing plugin/theme/block scaffolding. Do not build a multi-year dependency on the deprecated commands.

How to Pitch It (Stakeholders)

To executives (30 seconds): This is a free, already-installed command-line tool that generates standard WordPress code — custom post types, taxonomies, plugin and theme skeletons, and test/CI configuration. It costs nothing to adopt, carries no new vendor or security surface, and shaves routine setup hours off every WordPress project. It is not a product differentiator and not a strategic bet; it is plumbing that makes engineers faster and makes our code more consistent. Expect modest, compounding time savings and better test coverage on legacy work — not new capability.

To engineering leadership: Adopt it as the default for two things — CPT/taxonomy registration code and PHPUnit/CI bootstrapping — because those are stable, well-tested, and immediately useful. Do not standardize on it for new plugin, theme, or block scaffolds; the maintainers have flagged those paths as superseded by @wordpress/create-block and modern build tooling. Frame it as "one command replaces a wiki page," and set the expectation that we may outgrow the scaffolding half of it.

To the engineering team: Treat the tool as a starting point, not an authority. Generated files should be reviewed and committed like any other code; --force overwrites, so guard it in scripts. The real win is the test harness — wp scaffold plugin-tests --ci=github gets a plugin from zero to a running PHPUnit suite and a CI pipeline in one step, which is the shortest path we have to closing the "untested legacy code" gap.

Risk statement to include in any approval: one known deprecation (wp scaffold block) and one explicit maintainer caveat (plugin/theme scaffolding "no longer recommended" for modern WordPress). Mitigation: restrict usage to non-deprecated commands and keep an exit ramp to @wordpress/create-block and a maintained starter template.