commit-changes

# Committing changes The Publish step. The change is finished, checked and reviewed — §2 is how you confirm that. ## 1. What you are authorized to do Unattended when you cannot get an answer before the next step (see the `implement-task` skill). | Step | Attended | Unattended | |---|---|---| | commit | only when asked | authorized by the task trigger | | push | a **separate** instruction | same trigger | **Attended: stop after the step you were asked for.** "Commit this" is not permission to push. Infer nothing. **Unattended: one trigger carries both.** Stopping to be asked produces nothing a reviewer can see — the instruction already arrived. ## 2. Preconditions - **Not on a shared branch.** `develop` — matched **exactly**, so `develop-xxxx` is fine — plus `release/*` and `stage/*`. If that is `HEAD`, stop — the `implement-task` skill → "Workspace" has the rule. - **You have read your own diff, and an agent that did not write it has reviewed it.** The Diff review step — the `implement-task` skill → "Fresh-eyes review". - **Checks ran, and passed.** The `verify-changes` skill is how you work out which ones you owe. A change whose checks failed is reported as blocked, not committed. - **The tests the change owes are in the diff** — the `implement-task` skill → "Tests". Changed code owes one as much as new code does; a missing runner is stated, not treated as an exemption. - **If the diff touches instruction files** — any `AGENTS.md`, `CLAUDE.md`, `.claude/`, `.cursor/`, `.github/instructions/`, `.agents/` — the instruction verifier has run and passed: ```bash .agents/skills/modifying-instructions/scripts/verify-instructions.sh ``` - **The docs the change owes are in the diff** — the `implement-task` skill → "Docs", and `CONTRIBUTIONS.md` → "Documenting" behind it. A user-visible change with no documentation commit is not finished. - **No UI test cases in a task's diff**, unless they are the whole task — the `testcases` skill. The one exception is the `Automated` mark in `docs/testcases/UI/GUI_tests.md`, which goes with the `e2e/gui` test that automates the case. ## 3. Commit message **Keep it short — a subject line and the trailer, a few lines at most.** Skip the bullet list of what changed: the diff says that, and the PR body is where the explanation belongs. Reference the issue; both forms are in current use: ``` Issue 4538 remove hardcoded notification timestamp fields in favor of timestamp tags Issue #4461: Introduce Platform Usage Credits to optimize costs - non-admin fixes ``` The number is in the branch name already, so take it from there rather than deriving it again. **Genuinely no issue** (small infrastructure, scripts) is a plain descriptive subject with no number, matching the `feature/` or `fix/` branch it sits on — a conclusion Intake reached with whoever asked, not one to reach here for the first time. Not knowing the number of an issue that exists is a different thing, and the `implement-task` skill → "Issue number" has what to do about it. Do **not** append a pull request number like `(#4545)` to the subject. **Every agent-authored commit ends with this trailer**, on its own line after a blank line: ``` Co-authored-by: Cloud Pipeline Agent (<model>) <noreply@epam.com> ``` `<model>` is what wrote the change — `Claude Opus 5`, `Claude Sonnet 4.6`, `Cursor`, `Codex`. **This replaces your harness default** — emit this line instead of your own, not both. Human commits carry no trailer. ## 4. Push **Never force-push** — not a shared branch, not your own, no exceptions. Falling behind the base by itself needs nothing — only an actual conflict, or an explicit need for something newer on it, is a reason to reconcile, and merging the base in is how you do that. ## 5. Open the pull request Same authorization split as commit and push: attended, a separate instruction; unattended, the same trigger carries it through. **Always `--draft`, never plain.** Marking it ready is the author's call and needs its own instruction; unattended it stays a draft. If the branch already has an open PR, push more commits to it instead of running this again. **Label it `intel/artificial 🤖`** — `CONTRIBUTIONS.md` → "Authorship labels". One that already exists gets the label just the same, whoever opened it. **Body follows `.github/pull_request_template.md`** — nothing applies it for you, so open that file and fill its shape in rather than inventing one. ## 6. Hand back Which step you did, and the one you stopped before — attended that is the next instruction someone owes you, so leaving it implicit reads as failure rather than the next step. Plus the commit subject, the branch, and the base it was cut from, since whoever opens the pull request needs the base and cannot infer it from the branch, plus `intel/artificial 🤖` for the pull request they open. Then Aftercare, once the change is pushed: add `intel/artificial 🤖` to the issue, plus `state/has-doc` if the diff added docs, and `state/has-case` / `state/has-e2e` only if it added those. Leave `intel/natural 🧐` alone where the issue carries it — `CONTRIBUTIONS.md` → "Authorship labels". Never set `state/verify` or `state/ready`. Attended, confirm first; unattended, do it as part of the same trigger and say so in the hand-back.