// Use when submitting or preparing a Gerrit change for merge — checking submit requirements, rebasing, resolving comments, and submitting. Triggers on "submit this Gerrit change", "merge this CL", "is this change ready to submit", "check submit requirements".
| name | gerrit-submit |
| description | Use when submitting or preparing a Gerrit change for merge — checking submit requirements, rebasing, resolving comments, and submitting. Triggers on "submit this Gerrit change", "merge this CL", "is this change ready to submit", "check submit requirements". |
Guide for preparing and submitting Gerrit changes for merge.
The Gerrit MCP server must be available and the user must have submit permissions on the target project.
Before submitting, verify all requirements are met using mcp__gerrit__fetch_gerrit_change:
Labels satisfied — All required labels have sufficient votes:
submit_requirements)No unresolved comments — All inline comments must be resolved or addressed
Mergeable — The change can be merged without conflicts (check the mergeable field)
Up to date — The change is based on the current branch head (rebase if needed)
Fetch the change and examine:
submittable field — true if all requirements are metsubmit_requirements — list of conditions and their statuslabels — current votesIf not submittable, report what's missing and stop.
If the change is not based on the current branch head:
Use mcp__gerrit__submit_gerrit_review with the appropriate approval labels if you need to add final votes before submitting.
Submission itself happens through the Gerrit REST API. If the MCP server provides a submit tool, use it. Otherwise, inform the user to submit via the Gerrit web UI.
After successful submission:
Perform any development work on the ambient-ui component. Full workflow instructions.
Deploy a PR's images (api-server, control-plane, runner) to any OpenShift namespace for integration testing. Works on both standard OpenShift clusters and MPP managed clusters. Auto-detects the environment and chooses the right script.
End-to-end development workflow for the Ambient Code Platform. Covers ticket → branch → spec → code → commit → PR → review → deploy → verify. Self-improving: update this skill whenever a failure path is discovered or a shortcut is validated. Git history is the audit trail.
Required context for all frontend work. Loads frontend standards (conventions, React Query patterns, adapter testing requirements) before any code changes. Use when modifying anything under components/frontend/. Triggers on: any frontend code change, UI component work, React Query hooks, API adapter work, frontend bug fix, frontend refactor.
Use when creating or updating Gerrit changes — pushing code for review, amending patch sets, setting reviewers and topics. Triggers on "push to Gerrit", "create a Gerrit change", "upload for review", "update the patch set", "add reviewers to this change".
Use when reviewing a Gerrit change — fetching change details, reading diffs, posting inline comments, and voting with labels. Triggers on "review this Gerrit change", "review change 12345", "look at this Gerrit CL", "code review on Gerrit".