TL;DR
- Repeating-content series share a structural fingerprint — same H2 stack, same image placement, same callouts. The block editor opens to a blank canvas every time, so the writer rebuilds the scaffolding from scratch on every post in the series.
- A block-pattern skeleton is the post’s block markup with content slots replaced by placeholder tokens. The skeleton is the jig you build once so every subsequent post in the series ships with the same structural alignment without re-deciding it.
- Bluehost’s 2026 guide reports that designs assembled from saved patterns ship 60 to 70 percent faster than full block-stack rebuilds. The number matches the felt time tax on the eighth post in any repeating series.
- The four-step workflow: build a sample post deliberately, copy its block markup as a skeleton with placeholder tokens, feed the skeleton plus new content to an LLM with a tight substitution prompt, paste the filled markup into a new post via Code editor view.
- Three traps to avoid: skipping the staging-copy preview of the first filled post, trusting the LLM with structural decisions instead of just substitutions, and baking voice decisions into a template that should only own structure.
Three case studies. Same H2 stack. Same callout boxes. Same image placement. Each one took forty minutes to assemble in the block editor before any words went on the page.
This is the silent time tax of repeating-content workflows. Most posts in any series share a structure — recipes, product reviews, case studies, weekly newsletters. The first post in the series gets the structure designed deliberately. Every post after that should ship faster. It does not.
The block editor opens to an empty canvas every time. The writer rebuilds the same scaffolding from scratch. The hands move. The brain disengages. Forty minutes go to motion the writer has done before.
This post is about a four-step workflow that lifts the structural work off the writer’s hands. The skeleton gets built once. After that, the structure ships in seconds and the writing fills in around it.
Why does the same Gutenberg structure still take forty minutes to assemble?
A repeating-content series has a fingerprint. Every post in the series carries the same H2 stack, the same image placement, the same callout boxes, the same closing CTA. The structure is intentional. The writer designed it deliberately when the series launched.
What the block editor does not know: this post is the eighth one in that series. It opens to a blank canvas, exactly as it did for the first post.
The writer drags the same blocks into the same positions. Heading, paragraph, image, paragraph, callout, paragraph, list, image, paragraph. By the third post in the series the moves are muscle memory. By the eighth they are wrist pain. Bluehost’s 2026 block-pattern guide reports that pre-saved patterns can ship designs 60 to 70 percent faster than full rebuilds. The number matches the gut feeling.
The work is not writing. It is reassembly. Reassembly is the kind of work computers do better than humans, given a way to ask.
The way to ask is the block-pattern skeleton plus an AI chat that knows how to fill it.
What is a block-pattern skeleton?
A block-pattern skeleton is the block markup for the post’s structure, with the content slots left empty. To see the markup, open any post in the block editor, click the three-dot menu in the top right, and choose Code editor. The block editor stores every post as HTML-comment-wrapped block markup.
The official syntax is documented in the WordPress block-editor handbook. Each block opens with an HTML comment naming the block type, contains the rendered HTML inside, and closes with a matching comment. Paragraph blocks open with <!-- wp:paragraph -->, headings with <!-- wp:heading -->, images with <!-- wp:image -->. Attributes ride inside JSON braces in the opening comment.
A skeleton is the same markup, but with the words replaced by placeholder tokens. Something like [H1 TITLE], [INTRO PARAGRAPH 1], [CALLOUT TEXT]. The skeleton lives in a text file outside WordPress.
The jig you use once so every cut lines up afterward is the closest analogy. A jig is a fixture a woodworker builds once, then uses to guarantee every subsequent cut sits in the same place. The skeleton plays the same role for the block editor. Build the jig once with care, and reuse it for every post in the series.
This is not the same as a reusable block. Reusable blocks (synced patterns) maintain a live connection to the original, so editing one updates every instance. The skeleton is a one-shot template the writer fills with new content per post. Different tool, different job. Plan the data side too — ACF field design with AI covers the same discipline applied to custom-post-type structure.
How do you actually assemble a post from the skeleton?
The workflow is four steps. None of them require a developer.
Step 1. Build the sample post once. Open the block editor and assemble the post you would ship for the first entry in the series. Pick the H2 wording carefully. Pick the image placement deliberately. Decide which paragraph carries the lead and which carries the conclusion.
Step 2. Copy the block markup as the skeleton. From the block editor’s three-dot menu, choose Code editor. The view switches from the visual editor to the raw block markup. Copy the entire markup into a text file. Replace each content section with a placeholder token, like [H1 TITLE] or [CASE STUDY METRIC]. Save the file as <series>-skeleton.txt.
Step 3. Feed the skeleton plus new content to an AI chat.
You are filling a Gutenberg block-pattern skeleton with new content.
Below is the skeleton (block markup with [PLACEHOLDER] tokens) and
the raw content for the next post in the series. Substitute each
placeholder with the matching content. Preserve every block-markup
comment exactly. Return the filled markup, nothing else.
Skeleton:
<paste the skeleton text file>
Raw content:
<paste your draft headings, paragraphs, captions, etc.>
Step 4. Paste the filled markup into a new post. Open a new post in the block editor. Switch to Code editor. Paste the filled markup. Switch back to the visual editor. The structure lands intact. The visual matches the original sample post except for the new words.
The first sample post still takes forty minutes. Every subsequent post in the series takes the time it took to write the words plus a minute to paste the result. The same compounding payoff shows up in drafting wp-admin snippets with AI, where one tested snippet spares dozens of repeat clicks.
What can go wrong with the workflow?
Three traps catch writers running the workflow on a live post the first time.
Trap 1: skipping the staging copy. A malformed skeleton breaks the post on first save. The block editor will quietly drop blocks it does not recognize. Run the first three filled posts on a staging copy. Save, preview, and confirm the visual matches before you publish.
Trap 2: trusting the LLM with structural choices. Ask the chat to fill the skeleton, not to invent blocks. The skeleton dictates the structure. The LLM substitutes content. Watch for invented block types. A quote block where the skeleton said paragraph. A gallery where it said image. Either case means structural decisions are leaking into a layer they do not belong in.
Trap 3: treating the skeleton as a finished post. A skeleton is a structural fixture, not a piece of writing. Voice decisions belong on the writer’s desk per post. The lead paragraph, the closing reflection — those should never be baked into a template that flattens every post into the same beat.
The disconfirming voice belongs to the Jetpack 2026 block-editor tutorial. Adopting block patterns and the Site Editor can require migrating off a classic theme. The skeleton workflow still functions on individual posts without a block theme. The deeper Site Editor benefits, though, are blocked until the theme migrates. Plan the theme question before the skeleton question.
How do you turn the skeleton into a reusable jig for the whole series?
A pre-built skeleton is two artifacts. The first is the skeleton text file — the block markup with placeholder tokens, saved once. The second is the prompt template above, also saved once.
Pick the next post in your repeating series. Build the sample post deliberately in the block editor. Copy the markup. Replace the content with placeholder tokens. Save. The next post in that series ships in a minute and a paste. Not forty minutes and a wrist.
The math is simple. Designing the jig once is paid back from the second post forward.
The block editor was never the time tax. The reassembly was. The skeleton lifts the reassembly off the writer’s hands and gives back the time the muscle memory was eating. You do not need to be a developer to run it. You need to write one sample post deliberately, copy the block markup once, and trust the LLM with substitution — not with structure.
Other questions worth answering
How do AI generation plugins compare to manual markup substitution?
The plugins generate content inside the block editor. Manual substitution handles structure outside it. Vapvarun’s January 2026 survey names three workflows: Kadence Blocks for inline tone, Essential Blocks shipping 70+ AI-enabled blocks, and AI Editor for layout creation. Pick a plugin for generation, substitution for structural reuse.
When does the PHP registration path pay off compared to pasting raw markup each time?
Roughly three writers, or about ten or more posts in one series, is the practical threshold. The WordPress Block Editor Handbook’s December 2025 reference documents register_block_pattern() as the canonical API, registered from a handler attached to the init hook. The paste-from-text-file path fits one writer running one series. PHP registration fits a team and lands the pattern in every editor’s inserter.
What does the WordPress 7.0 Abilities API change about AI-driven layout creation?
Not yet, in practical terms. Vapvarun’s January 2026 survey frames the WordPress 7.0 Abilities API and the MCP Adapter as infrastructure under development, not shipped product. The substitution path works inside Code editor view today without either. Watch the API when it lands, but until then skeleton-plus-LLM covers the same job.
How do you decide between writing your own markup template and picking a design from the WordPress.org directory?
Two questions decide it. Start from the directory when the post fits a standard shape, like a hero with feature cards. Build your own when the structure carries series-specific voice decisions the directory cannot anticipate. Bluehost’s March 2026 guide notes 200+ free block patterns shipped on the WordPress.org directory.
How should you save your next repeating Gutenberg pattern?
Want a second pair of eyes on a repeating-series skeleton you have been planning? You can contact me here. Send me the topic of the series and one sample post you have already shipped. I will help you turn it into a reusable skeleton, in about an hour of work that saves a workday from there forward. There is no pitch, no upsell, and the conversation is free.