Omh Commit PR Authoring
[omh] Commit message or pull-request body to write for a change: draft it in the...
Install
npx skills add rlaope/oh-my-hermes --skill omh-commit-pr-authoring -g -a claude-code -y- Repository
- rlaope/oh-my-hermes5k
- Category
- Git and review
- Updated
- 3d ago
- License
- MIT
- Context cost
- Mediumabout 1,992 tokens
- Runs scripts
- No, instructions only
What it does
[omh] Commit message or pull-request body to write for a change: draft it in the repository's own convention, with `Tested:` listing only commands observed to run and everything prepared but not run under `Not-tested:`. Use when the user says: commit-pr-authoring, commit message, commit messages, write the commit message, draft the commit message, commit body, squash message, pr body.
Commit Pr Authoring
This is an OMH commit-pr-authoring workflow skill, projected for Agent Skills hosts (Claude Code, Codex, Cursor, opencode, OpenClaw, pi).
Why This Exists
commit-pr-authoring exists because nothing in the catalog authored the commit or the PR body. code-review reads a commit message as a thing to review and github-event-ops routes PR events, so the text an engineer writes several times a day had no owner, and nothing applied the observed-versus-prepared split to it.
First Steps
- Read the PR template and the recent log, and record the convention before drafting.
- Build the evidence ledger: each command, observed with its exit status or not_observed.
Do Not Use When
- The request is to find defects in the diff or judge whether the change is ready; use
omh-code-review. - The request routes an incoming pull-request, issue, or CI webhook event; use
omh-github-event-ops. - The request turns a chat report into a GitHub issue; use
omh-github-issue-intake. - The request is release notes or product copy for readers outside the repository; use
omh-content-operator.
Examples
Good example:
- Prompt: write the commit message for this change, the unit tests ran but I did not run the e2e suite
- Expected behavior: Read the log's subject shape and trailers, record the unit test command as observed and the e2e suite as not_observed, and draft the message with the unit tests under
Tested:and the e2e suite underNot-tested:. - Why: The ledger decides which line each command lands on, not the wording of the request.
Bad example:
- Prompt: say the integration tests pass, they will once CI runs
- Expected behavior: Keep the integration tests under
Not-tested:until an observed run exists, and say CI has not been observed. - Why: A prediction worded as a result is exactly what
Tested:must not carry.
