Claude Code Opus 4.5: Agentic Publishing Workflows
Table of Contents
1. overview
This document captures lessons learned from using Claude Code (powered by Opus 4.5) to autonomously manage org-mode publishing workflows for wal.sh.
2. the workflow
2.1. traditional approach
Previously, publishing involved:
- Write content in org-mode
- Run Emacs batch export manually
- rsync files to remote server
- Verify deployment succeeded
2.2. agentic approach
With Claude Code, the workflow becomes:
- Describe what you want to publish
- Agent handles everything: file creation, export, deployment, verification
The agent autonomously:
- Creates or edits org files
- Runs Emacs publish commands
- Verifies deployment via
version.jsonendpoint - Tracks work in
beadsissue tracker - Commits and pushes changes
3. key components
3.1. tramp-based publishing
Checked against this repo's own history. TRAMP-based publishing of the main HTML/static components already existed in project-config.el before this note's commit (cbf48649, 2025-12-21T17:49-05:00) -- it was not a breakthrough of this session. rsync was not eliminated: at that same commit the Makefile still ran rsync for sync-sitemap and sync-flashcards (commit 813af90d, same day, only removed the old full-tree rsync target used by deploy). Today's Makefile still uses rsync for sitemap, diagrams, banners, htaccess, logs, and atomic deploy. Body corrected to drop the "eliminated entirely" claim.
Using Emacs TRAMP, org-mode publishes directly to remote servers via SSH:
(setq org-publish-project-alist
`(("wal-sh-remote"
:base-directory ,base-dir
:publishing-directory "/ssh:jwalsh@www.wal.sh:/var/www/wal.sh/"
...)))
The agent publishes through this path without a separate scp/rsync step for the exported HTML and static assets. rsync is not gone from the pipeline – it still handles sitemap, diagram, banner, and log syncing.
3.2. deployment verification
The Makefile's version.json target (commit 813af90d, 2025-12-21T12:49:42-05:00, same day as this note) has always emitted {"sha", "build", "branch"} -- never a "timestamp" or "status" field. "a1ed6c5" is a real commit from this repo's history at that time (short sha of a1ed6c5b4..., "feat(css): add 5 style theme prototypes", 2025-12-21T17:45:06-05:00, i.e. 22:45:06Z), so the sha value checks out; the field names and the UTC conversion in the example did not. Body corrected to match the live schema.
Created version.json endpoint for automated deployment verification:
{
"sha": "a1ed6c5",
"build": "2025-12-21T22:45:06Z",
"branch": "main"
}
The agent can fetch this after publishing to confirm the deployment succeeded.
3.3. beads issue tracking
Using beads/bd for distributed, git-backed issue tracking designed for AI agents:
bd new feature "Add CSS style prototypes" -p P2 bd close www.wal.sh-e4b bd sync
4. what opus 4.5 enables
4.1. extended context
With ~200k token context, the agent can:
- Hold entire publishing configuration in memory
- Reference previous changes across the session
- Maintain coherent multi-file edits
4.2. tool orchestration
- Read publish.el to understand publishing setup
- Create new org file for content
- Run gmake publish
- Fetch version.json to verify
- Create git commit with proper trailer
- Push and sync beads
4.3. error recovery
When publishing fails (FreeBSD path issues, missing dependencies), the agent:
- Reads error logs
- Identifies root cause
- Applies fix
- Retries operation
5. workflow pattern: landing the plane
Every significant change follows this pattern:
- Create/edit content
- git add && git commit with conventional commit message
- git pull –rebase && git push to sync
- bd sync to synchronize issue tracker
- gmake publish to deploy
- Verify via version.json or curl
6. challenges and solutions
6.1. challenge: FreeBSD compatibility
project-config.el, checked at this note's own commit (cbf48649), already carried this exact fix: ~(use-package ob-mermaid :config (when noninteractive (setq org-babel-default-header-args:mermaid '((:eval . "no") (:exports . "code")))))~, with a comment reading "Disable mermaid evaluation in batch mode (FreeBSD lacks puppeteer support)". Claim and fix check out verbatim.
- Mermaid CLI doesn't work (puppeteer issues)
- Solution: Disable mermaid in batch mode
6.2. challenge: CI/CD secrets
Commit fd6c40d3 (2025-12-21T17:08:18-05:00, 41 minutes before this note) switched .github/workflows/publish.yml from push/pull_request triggers to workflow_dispatch only, with commit message "Switch to manual trigger only - now publishing via TRAMP locally. To re-enable, configure WAL_SH_SSH_PRIVATE_KEY secret." Matches the claim exactly.
- GitHub Actions can't SSH to deploy server
- Solution: Use local/agent publishing, disable CI auto-trigger
6.3. challenge: Multi-session context
- Agent loses context between sessions
- Solution: Detailed beads issues + conversation summaries
7. future directions
- Theme switching: CSS prototype system for user-selectable themes
- Incremental publish: Only publish changed files
- Link validation: Automated broken link detection
- RSS feed: Automatic feed generation
8. conclusion
The key insight: give the agent good infrastructure (TRAMP, version endpoints, issue tracking) and it can autonomously manage the entire publishing lifecycle.
9. resources
- Multi-Agent Workflow Frameworks - deeper dive on agent coordination
- beads/bd - distributed issue tracker for agents
- Claude Code - the CLI tool powering this workflow