repo-publish

Repo Publish

End-to-end pipeline for taking a project from "I made changes" to "live on a remote". Runs quality gates, generates an intelligent multi-commit history, pushes, and verifies the deploy.

When to Use

Use this skill when:

• The user says "publish", "release", "ship it", "push to remote", "deploy this"
• A project has accumulated local changes that need to land cleanly
• A version bump or release needs to be cut
• The user explicitly asks to run the full landing-the-plane workflow

Do not use this skill for:

• Single quick commits the user is doing themselves
• Documentation-only edits (use the project's own docs workflow)
• Anything involving secrets/credentials (the scripts will skip those files)

Workflow Decision Tree

Start here. Pick the lane based on the user's intent:

User wants to publish
  ├─ Has local changes? ──── no ──► Just push / bump version
  ├─ Want a release? ──── yes ──► [Release mode](#release-mode)
  └─ Just routine commit? ──────► [Push mode](#push-mode)

Push Mode

For ordinary commits that need to land.

Step 1 — File remaining work

Run the issue tracker step:

bd ready              # What's pending
bd show <id>          # Inspect any blockers
bd update <id> --status in_progress  # Claim work

If you can't bd, ask the user how they track issues for this project. Don't silently skip it — issue hygiene is part of the gate.

Step 2 — Run quality gates

Inspect package.json, pyproject.toml, Makefile, or whatever exists and run whatever the project defines as "test + lint + build":

# Node
npm test && npm run lint && npm run build

# Python
pytest && ruff check . && mypy .

# Go
go test ./... && go vet ./...

# Rust
cargo test && cargo clippy -- -D warnings

# Makefile-driven
make test lint build

If a gate fails, stop. Report which gate failed and the relevant error. Don't try to fix the code in the same publish flow — open a fix-PR first.

For projects without an obvious test command, run ls to find the closest script and ask the user.