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
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
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
- Mermaid CLI doesn't work (puppeteer issues)
- Solution: Disable mermaid in batch mode
6.2. challenge: CI/CD secrets
- 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