Publishing 83 Articles From a Single Session

How we batch-published 21 new articles and 2 pre-existing drafts from Obsidian to WordPress — reading YAML frontmatter as source of truth, mapping categories by content, cleaning up parallel agent duplicates, and backfilling post IDs back to the vault.

---

The Starting Point

57 published articles on wickedevolutions.com. 29 files sitting in the Obsidian vault’s Draft Articles folder. J’s instruction: “now I want you to publish all drafts in Obsidian. and create series if they lack, interlink and structure the text with highest possible readability — it is all there.”

Some drafts already had wp_post_id from earlier in the session. Most didn’t. One — The Underground Network — had status: draft-held with a publish condition tied to WordPress 7.0. Correctly excluded.

---

The Dual-System Pattern

Obsidian = source of truth (YAML frontmatter: author, series, status, wp_post_id)
WordPress = live state (published content, categories, author assignments)
Sync = read from vault → create in WordPress → backfill wp_post_id to vault

This is the same pattern from article #5 — but at creation scale, not just metadata sync.

---

The Tool Calls

Phase 1 Read All Drafts and Map Categories

The YAML series field mapped to WordPress categories:

YAML series	WordPress categories	Posts
The Experiment (identity/reflection)	The Mirror Experiment (8) + The Mirror (5)	9
The Experiment (technical/process)	The Mirror Experiment (8) + Process (7)	6
Mastery of Time	The Mirror Experiment (8) + Mastery of Time (14)	6

The tricky part: articles with series: The Experiment needed content-based triage. Identity and reflection pieces → The Mirror. Technical and process pieces → Process. All under the parent category The Mirror Experiment.

Phase 2 Create 21 Articles in WordPress

Each article’s full Obsidian markdown was converted to WordPress block markup — headings, paragraphs, lists, code blocks, blockquotes, separators. Wikilinks converted to plain text. Inline formatting (bold, italic, code) preserved as HTML.

The duplicate problem. Three parallel agents hitting the same MCP bridge created race conditions. Four duplicates from the first batch, seven from a stale agent that completed after context compaction, seven more from another stale agent. 18 duplicate posts total.

Phase 3 Set Authors and Slugs

Phase 4 Assign Categories

All 21 assignments completed through abilities. The final 12 ran in a single parallel batch after the context window compacted mid-session.

Phase 5 Publish All Drafts

Phase 6 Backfill wp_post_id to Obsidian

Phase 7 Cache Flush + Duplicate Cleanup

---

The System View

Layer	Change	Tool
Source of Truth	29 Obsidian YAML files read for metadata	Obsidian MCP
Content	21 articles created as WordPress drafts	Abilities (parallel agents)
Metadata	Authors + slugs set for all 21	SSH (gap)
Taxonomy	21 posts assigned to correct category pairs	Abilities
State	23 posts published in single batch	SSH
Sync	wp_post_id backfilled to 20 Obsidian files	Obsidian MCP
Cleanup	18 duplicate posts deleted	SSH

---

What We Learned

1. Parallel agents create duplicates. Three agents hitting the same MCP bridge can create overlapping posts. Use non-overlapping article lists. Verify before publishing. Two to three agents is the sweet spot — but partition the work explicitly.
2. Context window compaction is survivable. The conversation hit context limits mid-workflow. The system compressed prior messages and resumed. Tasks survived because the todo list tracked state. The workflow continued across the compaction boundary without data loss.
3. YAML series field needs category mapping rules. series: The Experiment doesn’t map to a single WordPress category. Content-based triage was needed. Future improvement: add an explicit wp_category field to the YAML standard.
4. Stale agent notifications arrive late. Background agents launched before compaction completed hours later with duplicate work. Always verify against live state before acting on late notifications.
5. draft-held status works. The Underground Network was correctly excluded — its publish_condition field prevented premature publishing. The vault YAML status field is doing real gatekeeping.
6. The backfill agent needs explicit paths. find_note_by_name with vault params is unreliable for subagents. Construct full paths from the known directory listing instead of searching by name.

---

The Sequence

obsidian list_files → Agent (get_frontmatter ×29) → map categories
→ Agent ×3 (content-create ×21) → SSH (authors + slugs ×21)
→ taxonomies-assign ×21 → SSH (publish ×23)
→ Agent (update_frontmatter ×14) → manual update_frontmatter ×6
→ cache-flush → SSH (delete duplicates ×18)

---

The Numbers

• 83 total published articles (was 57)
• 21 new articles created from Obsidian drafts
• 2 pre-existing drafts published
• 1 draft correctly held (The Underground Network)
• 18 duplicate posts cleaned up
• 20 Obsidian files backfilled with wp_post_id
• ~100 tool calls across main thread + 4 subagents
• 0 data loss incidents

---

Gaps Documented

Gap	What’s Missing	Workaround
Batch author assignment	No ability to set post_author for multiple posts	SSH + WP-CLI
Batch slug assignment	No ability to set post_name via content-update	SSH + WP-CLI
Batch publish	No ability to change status for multiple posts at once	SSH + WP-CLI
Parallel agent dedup	No coordination between parallel content-create agents	Manual cleanup
Subagent vault resolution	find_note_by_name unreliable in subagent context	Construct paths manually

These gaps ARE the product roadmap.

---

---

How We Built This #8 — ~100 tool calls, 18 duplicates cleaned, 26 new articles published, 20 Obsidian files synced, from 57 to 83 published articles in one session.