mathews-tom Ship Workflow
Automated release pipeline that takes a feature branch from working state to merged PR. Executes a deterministic sequence of pre-flight checks, testing, review, versioning, and PR creation — stopping immediately on any failure with specific remediation instructions.
Pipeline Overview
pre-flight → merge main → test → review → version bump → changelog → bisectable commits → push → PR
Each step has explicit stop conditions. The pipeline never auto-resolves ambiguity.
Step 1: Pre-flight Checks
Run all three checks before proceeding:
Not on default branch — detect the default branch dynamically:
git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@'If the current branch matches: STOP. Instruct the user to create a feature branch.
Clean working tree —
git status --porcelainmust produce no output. If dirty: STOP. List the uncommitted files and instruct the user to commit or stash.Up-to-date with remote —
git fetch originthen compare local HEAD withorigin/<current-branch>. If the remote is ahead: STOP. Instruct the user to pull or rebase.
If any check fails, STOP with the specific remediation instruction. Do not proceed.
Step 2: Merge Default Branch
git fetch origin
git merge origin/<default-branch>
- If merge conflicts occur: STOP. Report the conflicting files. Do not auto-resolve.
- If clean: proceed.
Step 3: Run Tests
Detect the test command from project configuration using references/project-detection.md:
| Indicator | Test Command |
|---|---|
Makefile with test target |
make test |
package.json with test script |
<detected-pkg-manager> run test |
pyproject.toml with pytest config |
uv run pytest (or detected runner) |
Cargo.toml |
cargo test |
go.mod |
go test ./... |
Gemfile + Rakefile |
bundle exec rake test |
Detection order: check each indicator top-to-bottom; use the first match.
- If tests fail: STOP. Report the failure output. Do not proceed.
- If no test command detected: warn the user and ask whether to proceed without tests.
Step 4: Pre-Landing Review
Invoke the pre-landing-review skill if available. Otherwise, perform a lightweight
diff review against the default branch:
git diff origin/<default-branch>...HEAD
Review the diff for:
- Obvious bugs or logic errors
- Security concerns (credentials, injection vectors)
- Missing error handling on new code paths
Classification:
- CRITICAL findings: STOP. Resolve before proceeding.
- INFORMATIONAL findings: note them for inclusion in the PR description. Proceed.
Step 5: Version Bump
Detect the version strategy from project configuration using references/project-detection.md:
| Indicator | Version Location |
|---|---|
VERSION file |
Update file contents directly |
package.json version field |
Update the field |
pyproject.toml version field |
Update the field |
Cargo.toml version field |
Update the field |
| Git tags only | Create tag at push time |
Default bump level: PATCH.
- For MINOR or MAJOR bumps: STOP. Confirm with the user before proceeding.
- If no version strategy detected: skip the version bump entirely. Note the skip in the PR description.
Step 6: Update Changelog
- If
CHANGELOG.mdexists: prepend an entry in Keep a Changelog format. - If no changelog file exists: skip.
Auto-generate the entry from commit messages since the last tag or release. Group entries by conventional commit type:
## [<new-version>] - <date>
### Added
- feat: ...
### Fixed
- fix: ...
### Changed
- refactor: ...
Step 7: Create Bisectable Commits
Organize staged changes into logical, bisectable commit groups in this order:
- Infrastructure / config changes — build files, CI config, dependencies
- Models / services / core logic — domain layer, business rules
- Controllers / views / API endpoints — presentation and routing
- Version bump + changelog — always last
Each commit uses a descriptive conventional commit message. Each commit should pass tests independently when possible (verify if CI turnaround allows it; otherwise trust the ordering).
If all changes are already committed in a reasonable structure, skip reorganization.
Step 8: Push and Create PR
git push -u origin <current-branch>
Create the PR:
gh pr create \
--title "<conventional-format-title>" \
--body "<generated-body>"
PR body includes:
- Summary of changes (grouped by commit)
- Test results (pass confirmation)
- Version bump details (old → new, or "skipped")
- Any INFORMATIONAL findings from Step 4
Output the PR URL as the final result.
Stop Conditions
The pipeline halts immediately and reports when any of these occur:
| Condition | Step | Action |
|---|---|---|
| On default branch | 1 | Stop, instruct to create feature branch |
| Dirty working tree | 1 | Stop, list files, instruct to commit/stash |
| Behind remote | 1 | Stop, instruct to pull/rebase |
| Merge conflicts | 2 | Stop, report conflicting files |
| Test failures | 3 | Stop, report failure output |
| Critical review findings | 4 | Stop, resolve before proceeding |
| MINOR/MAJOR version bump | 5 | Stop, confirm with user |
Important Notes
- This skill modifies the repository: it creates commits, pushes code, and opens PRs.
- All branch names and test commands are detected dynamically — nothing is hardcoded.
- The version strategy is inferred from project files, not assumed.
- If the
pre-landing-reviewskill is not available, the review step degrades to a lightweight diff scan rather than skipping entirely.