What if there are multiple unrelated changes?

Decide whether to create separate commits for each logical change or combine them into a single commit. The tool can guide you, and you should update the changelog accordingly.

Should I always update CHANGELOG.md?

Update the changelog for new features, bug fixes, breaking changes, or deprecations. Skip minor typos, internal refactors, or docs-only changes.

Can I force push or push to main?

The guide warns against unnecessary force pushes. Use a normal push and push to a feature branch; avoid force-pushing to main/master unless explicitly requested.

push

npx machina-cli add skill NorthShoreAutomation/trellis/push --openclaw

Files (1)

SKILL.md

1.8 KB

User Input

$ARGUMENTS

You MUST consider the user input before proceeding (if not empty).

Commit and push the current changes to the remote repository.

Instructions

Run git status to see all staged and unstaged changes
Run git diff --staged and git diff to understand what changed
If beads is configured (.beads/ directory exists and bd command available):
- Run bd sync --from-main to pull latest beads updates (if not on main branch)
- Run bd list --status=in_progress to see if any issues should be closed with bd close <id>
- If bd commands fail, warn user but continue with git operations
Update the CHANGELOG.md file for any changes that should be documented for a subsequent release:
- New features, bug fixes, breaking changes, deprecations
- Skip for minor typos, internal refactoring, or documentation-only changes
Stage all relevant changes with git add
Write a commit message that:
- Uses a single concise subject line (50 chars or less if possible)
- Follows conventional commit format when appropriate (feat:, fix:, refactor:, docs:, chore:, etc.)
- Focuses on WHAT changed and WHY, not HOW
Commit the changes
Push to the current branch with git push (use -u origin <branch> if no upstream is set)
Do NOT create a pull request

Important

Keep the commit message short and meaningful
If there are multiple unrelated changes, ask the user if they want separate commits or one combined commit
Do not include files that look like secrets (.env, credentials, etc.) without asking
NEVER use --force or --force-with-lease unless explicitly requested by the user
Warn the user if they request a force push to main/master branches

Source

git clone https://github.com/NorthShoreAutomation/trellis/blob/main/skills/push/SKILL.mdView on GitHub

Overview

This skill commits current work, updates CHANGELOG.md for release notes, and pushes to the remote repository. It guides you through diff review and encourages concise, conventional commit messages. When a .beads setup exists, it can run bead-related checks before pushing.

How This Skill Works

The tool checks repo state with git status and git diff to view changes. If beads is configured, it runs bd sync --from-main and checks for in_progress items to close. It updates CHANGELOG.md for release-worthy changes, stages relevant changes with git add, writes a concise commit message following conventional formats, commits, and pushes to the current branch (using -u origin <branch> if needed).

When to Use It

You finished a feature or bug fix and want to document it with a changelog entry and push to the remote
You’re preparing a release and need to ensure CHANGELOG.md reflects new changes before pushing
You’re collaborating on a branch and want to share work with teammates via git push
You use beads to track tasks and may sync or close issues with bd commands before pushing
There are multiple unrelated changes and you need guidance on creating separate commits or a single combined commit

Quick Start

Step 1: Run git status to see staged and unstaged changes
Step 2: Run git diff --staged and git diff to review exactly what changed
Step 3: Stage changes with git add, write a concise commit message (50 chars or less) in conventional form, commit, and push

Best Practices

Run git status and review git diff before staging any changes
Update CHANGELOG.md only for new features, fixes, breaking changes, or deprecations
Keep commit messages concise (around 50 chars) and describe WHAT changed and WHY
Do not include secrets or credentials in commits; avoid --force unless explicitly requested
If there are multiple unrelated changes, decide on separate commits or a single combined commit and communicate this

Example Use Cases

git status; git diff --staged; edit CHANGELOG.md; git add .; git commit -m 'feat: add user login'; git push
git status; git diff; git add CHANGELOG.md; git commit -m 'docs: update changelog for release'; git push
bd sync --from-main; bd list --status=in_progress; git add .; git commit -m 'feat: integrate payments'; git push
git status; git diff; git add .; git commit -m 'fix: resolve startup crash'; git push -u origin feature/xyz
git status; git diff; git add .; git commit -m 'refactor: reorganize auth module'; git push

Frequently Asked Questions

Add this skill to your agents