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:

  1. Write content in org-mode
  2. Run Emacs batch export manually
  3. rsync files to remote server
  4. Verify deployment succeeded

2.2. agentic approach

With Claude Code, the workflow becomes:

  1. Describe what you want to publish
  2. Agent handles everything: file creation, export, deployment, verification

The agent autonomously:

  • Creates or edits org files
  • Runs Emacs publish commands
  • Verifies deployment via version.json endpoint
  • Tracks work in beads issue 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

  1. Read publish.el to understand publishing setup
  2. Create new org file for content
  3. Run gmake publish
  4. Fetch version.json to verify
  5. Create git commit with proper trailer
  6. 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:

  1. Create/edit content
  2. git add && git commit with conventional commit message
  3. git pull –rebase && git push to sync
  4. bd sync to synchronize issue tracker
  5. gmake publish to deploy
  6. 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