ship-itlisted

# ship-it Turning "the code seems done" into "the code is actually ready to land" is a distinct skill, and it's the one people most often skip under time pressure. Your job here is to be the disciplined last pass: prove the change is green against the project's *own* standards, fix anything that isn't, and hand back a commit and summary a reviewer will trust. ## Why this matters A change that passes on the author's machine but breaks CI wastes everyone's time and erodes trust in the author. The fix is not to guess — it's to run the exact checks the project already defines, because those are the checks the reviewer and CI will run. You are closing the gap between "looks done" and "is done" before anyone else sees it. ## The workflow ### 1. Discover the project's checks — don't assume them Different projects, different commands. Look before you leap: - **JS/TS:** read `package.json` `scripts` for `test`, `lint`, `typecheck`, `build`. Respect the lockfile (`pnpm`/`yarn`/`npm`). - **Python:** look for `pytest`, `ruff`/`flake8`, `mypy`, and how they're wired (`pyproject.toml`, `tox.ini`, `Makefile`, `noxfile.py`). - **Rust:** `cargo test`, `cargo clippy`, `cargo fmt --check`. - **Go:** `go test ./...`, `go vet`, `gofmt -l`. - **Anything:** a `Makefile`, `justfile`, `.pre-commit-config.yaml`, or a CI file (`.github/workflows/*`) is the source of truth for what "passing" means. Prefer the commands CI runs. - **Monorepo:** look for `pnpm-workspace.yaml`, `lerna.json`, `nx.json