Skip to content
Release engineering

Shipping Across npm, GitHub, and Agent Hosts Without Pretending It Is Atomic

End-to-end Codex and Claude Code skill for validating, packaging, publishing, releasing, and verifying portable Agent Skills.

Written by Montasim
2 min read

ship-agent-skill project

The visible feature was only the surface

Releasing a skill spans mutable local state and several independent remote systems, making partial success, version drift, and accidental publication easy.

The system also had to respect concrete constraints. Publishing, pushing, releases, deployment, and catalog changes need separate authorization. Codex and Claude Code require different install destinations but one portable payload. An immutable artifact may already exist when a later stage fails.

My role covered agent workflow design and automation engineering, with responsibility for agent workflow, validation automation, and packaging.

I turned the constraints into boundaries

Agent-facing orchestration in SKILL.md; deterministic preflight/release-gate references; npm installer/package contract and consumer-side tests.

Model release stages separately rather than treating "ship" as blanket permission.

Validate host portability before creating immutable artifacts.

Verify the installed consumer view after registry/release checks, accepting more gates for stronger end-to-end evidence.

The key decision: Model release stages separately.

The implementation had to prove the model

I delivered the work across the full path: Defined an authorization-aware release inventory and workflow. Built deterministic preflight checks. Implemented safe dual-host installation with path/symlink/rollback protections. Tested dry runs, replacement, package contents, and consumer contracts.

The result is concrete: Agents can prepare without publishing. Execute only authorized stages. Distinguish partial remote success. Verify tag, GitHub release, npm package, install command, and catalog state from the consumer side.

The senior engineering lesson was that solving the visible workflow is only half the job. The architecture must also make constraints, failure modes, evidence, and ownership explicit enough for the next change to remain safe.

Working through a similar challenge?

Share your context, constraints, and timeline to start a focused conversation.

Discussion

Join the conversation about this article

0 comments

Loading discussion

Fetching the latest comments.

Leave a reply

Respond to the article or continue the discussion.

Ctrl + Enter to post

Your email stays private. Comments are stored securely.