The Build Crew for AI Development
buildcrew commands prepare-commit.md
3.1 kB
Markdown
at main


name: prepare-commit description: Prepare commit message, PR title, and PR description for current changes. Only prepares text by default; asks before committing, pushing, or opening PR. #

/prepare-commit #

Prepare a concise commit message and PR-ready description for the current changes. By default, this command only prepares text. It must ask before committing, pushing, or opening a PR.

Behavior #

If uncommitted changes exist #

Prepare commit and PR text from staged/unstaged diffs.

If no uncommitted changes exist #

Prepare PR text from committed changes:

  • Prefer diff from upstream/base branch to HEAD when available.
  • If only one local commit is relevant, use HEAD^..HEAD.
  • If base branch is unclear, state the assumed base or ask the user.

What to Analyze #

  1. Diff - Inspect changes to understand what was modified, added, or removed.
  2. Tests - Note any test additions, removals, or modifications.
  3. Dependencies - Note any dependency changes.
  4. Breaking changes - Identify if public APIs, schemas, behaviors, or contracts changed.
  5. Frontend changes - If frontend files changed, note UI states, responsive behavior, accessibility, styling system.
  6. Review status - Only include if /review output is visible in the current context.

Output Format #

## Commit Message

<type>(<scope>): <concise summary>

<body if useful>

PR Title Options #

1. [ISSUE-ID] <type>(<scope>): <concise title>
2. [ISSUE-ID] <concise human-readable title>

PR Description #

### Summary
Precise description of the change.

### Why
Why this change was needed.

### Change Type
- New functionality / Bug fix / Refactor / Performance / Security / Docs / Tests / Chore

### Compatibility
Backward compatible / Breaking change.

### Breaking Change Notes
Only if applicable. Include migration guidance and rollout considerations.

### Frontend Notes
Only if frontend code changed. Include UI states, responsive behavior, accessibility, screenshots needed.

### Testing
Commands run or tests observed.

### Review Status
Only include if `/review` output is visible in the current context.

### Notes for Reviewer
Anything important to look at.

Optional Next Actions #

After presenting the prepared text, ask the user:

Would you like me to:
1. Create a commit with this message?
2. Push the branch?
3. Open a PR with `gh`?

Rules for next actions:

  • Never commit unless the user explicitly confirms.
  • Never push unless the user explicitly confirms.
  • Never open a PR unless the user explicitly confirms.
  • Use git for commit/push if available.
  • Use gh for PR creation if available.
  • If gh is unavailable, say PR cannot be created automatically and provide copy-paste PR text.

Anti-Copy-Paste Sentinel #

Optional: include this HTML comment in the PR description to catch unreviewed copy-paste:

<!-- i am a bot. the texts in my PR have been validated and i should be removed -->

Only include if the user or project convention prefers it.