Publishing

DocSlime publishes three related surfaces: the Rust CLI, the reusable agent-skill pack, and the static documentation site. A build or deployment is not complete until its expected artifact and user-facing behavior are verified.

Artifacts and destinations

Recommended conventions, not mandates

DocSlime recommends considering two complementary standards when they fit a project’s release model:

• Semantic Versioning communicates compatibility through MAJOR.MINOR.PATCH. DocSlime uses SemVer for CLI releases because the CLI has a public command and template contract.
• Conventional Commits use type(scope): description to make change intent readable by people and release tooling. fix commonly corresponds to a patch, feat to a minor change, and a declared breaking change to a major change when SemVer applies.

These are suggestions, not requirements. A project should document and preserve an existing convention that already works. DocSlime guidance must not introduce commit linting, rewrite history, or change version automation without explicit team agreement.

Continuous integration

.github/workflows/ci.yml validates the CLI, site, agent skills, and branch policy. Only staging may open a pull request to main; feature branches target staging.

Before publishing, run:

cargo fmt --check
cargo test
cargo clippy --all-targets -- -D warnings
npm ci
npm run build

CLI and Homebrew release

Distribution is configured through cargo-dist. A SemVer tag runs .github/workflows/release.yml, builds macOS/Linux artifacts, creates the GitHub Release, publishes the installer, and updates the Homebrew tap.

Verify more than workflow completion:

1. Confirm the GitHub Release contains the expected version and target artifacts.
2. Confirm the Homebrew tap points at that release and its checksums.
3. Install or upgrade through Homebrew and run docslime --version.
4. Scaffold a throwaway repo and confirm the current template tree is emitted.

Skill distribution

The .agents/skills/docslime-* directories are the canonical source. Validate them before release, then verify a fresh npx skills add DecisionNerd/DocSlime install contains the same skill set and instructions.

Documentation site

npm run build

docmd reads docs/ and writes the static site to site/. Deployment configuration is outside the CLI; current build and runtime status must be verified through the configured host rather than inferred from generated files alone.

Rollback

• Revert or supersede a bad documentation/site deployment from the last known-good source commit and rebuild.
• For a bad CLI release, stop promotion, document the impact, and issue a corrected version; do not move an immutable published tag.
• For a bad Homebrew formula, restore the last known-good formula or publish the corrected release, then verify installation through Homebrew.

Official references

• Semantic Versioning 2.0.0
• Conventional Commits 1.0.0
• cargo-dist documentation
• docmd Quick Start
• docmd Deployment Overview