Skip to content

Block development: static vs dynamic blocks - #24

Open
luisherranz wants to merge 4 commits into
WordPress:trunkfrom
luisherranz:block-development-static-vs-dynamic-blocks
Open

Block development: static vs dynamic blocks#24
luisherranz wants to merge 4 commits into
WordPress:trunkfrom
luisherranz:block-development-static-vs-dynamic-blocks

Conversation

@luisherranz

Copy link
Copy Markdown
Member

What

Teach the block-development skill how to choose between static and dynamic rendering when creating a new block, and add eval scenarios to verify the decision.

Why

The skill had no guidance on this decision. Agents would default to whichever pattern they'd seen most in training data, leading to inconsistent choices: sometimes static when dynamic was clearly needed (e.g., Interactivity API blocks, blocks in template parts), and sometimes dynamic for simple presentational blocks where static is fine. A priority-ordered checklist eliminates the guesswork.

How

  • Add references/static-vs-dynamic-blocks.md: a "first YES wins" decision checklist covering external data, evolving markup, Interactivity API, block themes, server-side needs, content portability, and simple presentational blocks.
  • Update SKILL.md step 3 ("Pick the right block model") to point to the new reference and simplify the interactivity guidance into a single line that loads wp-interactivity-api.
  • Add 8 new eval scenarios (6 dynamic, 2 static) that each test a different decision point from the checklist, including one adversarial case where a lower-priority signal (portability) conflicts with a higher-priority one (server-side auth).
  • Update the existing block-create-interactive-inner-blocks eval to include the static-vs-dynamic decision step, since Interactivity API requires dynamic rendering.
@github-actions

github-actions Bot commented Feb 25, 2026

Copy link
Copy Markdown
Contributor

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: luisherranz <luisherranz@git.wordpress.org>
Co-authored-by: karmatosed <karmatosed@git.wordpress.org>
Co-authored-by: jonathanbossenger <psykro@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@luisherranz

Copy link
Copy Markdown
Member Author

@Jameswlepage, any guidance on how to run the evals to test that they work?

@karmatosed

Copy link
Copy Markdown
Member

@luisherranz right now this branch is out of date, so I would suggest working on that first then we can approach the evals. That is of course if you want to work on getting this in still, if not please comment and we can close. I am going through and trying to triage some cleanup.

@bgrgicak
bgrgicak requested a review from a team July 8, 2026 07:43
@jonathanbossenger

Copy link
Copy Markdown
Contributor

FWIW the skill itself looks good, so we just need to update the branch.

@luisherranz

Copy link
Copy Markdown
Member Author

@copilot can you fix the CI problem?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

3 participants