/omh-commit-pr-authoring

name: "omh-commit-pr-authoring"
description: "[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."
metadata:
  hermes:
    tags: [workflow, oh-my-hermes, verification]
    category: verification
    phase: commit-pr-authoring
    role: reviewer
    quality_tier: evidence-ledger-gated

Commit Pr Authoring

This is a Hermes-native `commit-pr-authoring` workflow skill.

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 `code-review`.
• The request routes an incoming pull-request, issue, or CI webhook event; use `github-event-ops`.
• The request turns a chat report into a GitHub issue; use `github-issue-intake`.
• The request is release notes or product copy for readers outside the repository; use `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 under `Not-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.

Completion Checklist

• The convention read names the template and log sample it drew from.
• Every `Tested:` entry maps to an observed ledger row with its exit status.
• Every prepared, skipped, or unobserved command is under `Not-tested:` with its reason.
• Nothing was committed, pushed, or opened by OMH.

Recovery Notes

• If no run records exist, draft with an empty `Tested:` and every command under `Not-tested:`, and ask for the observed output.
• If the repository has no template or visible convention, say so and use a plain subject and body rather than importing one.

Workflow Lane

• Current lane: **Coding handoff** (`idea-to-deploy`, `llm-app-dev`, `cto-loop`, `deploy-and-monitor`, `code-review`, `build-failure-triage`, `verification-gate`, `security-safety-review`, `+28 more`) - coding owners, handoffs, review, CI, and merge evidence.
• If intent belongs to another lane, hand back to `oh-my-hermes` or name the adjacent workflow.
• Shared product, routing, compatibility, and evidence rules: `omh-routing/references/skill-common-rail.md`.

Use When

Use when a change is ready to record and the user wants its commit message or pull-request body written: the repository's template and recent log read first, the subject and body in that convention, the trailers the repo requires, and a `Tested:` line that lists only commands observed to run, with everything prepared but not run under `Not-tested:`. OMH prepares the text; the commit, the push, and the PR are the user's or the executor's.

Strong routing signals: `commit-pr-authoring`, `commit message`, `commit messages`, `write the commit message`, `draft the commit message`, `commit body`, `squash message`, `pr body`, `pr description`, `pull request body`, `pull request description`, `draft the pr`, `write the pr`, `pr template`, `tested trailer`, `not-tested trailer`, `lore trailers`

Catalog Metadata

Category: `verification` Phase: `commit-pr-authoring` Hermes role: `reviewer` Quality tier: `evidence-ledger-gated` Reasoning demand: `standard`

Quality bar:

• Read the template and at least the last few commits before writing a word, and record what was found.
• Build the evidence ledger first; the `Tested:` and validation sections are projections of it, not prose.
• Write the subject in the repository's shape and the body as why the change exists, not a restated diff.
• Load `references/commit-and-pr-conventions.md` for trailer, sign-off, and template-section mapping instead of improvising them.
• Put `Closes #N` on its own line only when every success criterion of that issue is met.

Handoff policy:

Keep the convention read, the drafted text, and the evidence ledger in Hermes. The commit, the push, and opening the PR are executor or user actions; OMH never performs them, and a command reaches `Tested:` only from an observed run record.

Required inputs:

• the change: the diff, the staged files, or the branch compared with its base
• the repository's PR template and a sample of its recent commit log
• the commands that ran for this change, each with its observed exit status
• the commands that were prepared, planned, or skipped, and why
• the issue or goal the change closes, when there is one

Expected outputs:

• repo_convention_read/v1
• evidence_ledger/v1
• commit_message_draft/v1
• pr_body_draft/v1 when a PR is being opened

Artifact expectations:

• repo_convention_read/v1 names the template path, the subject shape and trailers seen in the recent log, and the sign-off rule, or says which of them was not found
• evidence_ledger/v1 lists