Skip to content
Helmhive Helmhive Helmhive

Request a change

A change request is the input to the governed workflow that ends in a locally tested pull request. Creating one cannot modify a repository; a service Developer must approve an exact plan before any implementation starts.

Create the request

Section titled “Create the request”
  1. Open Changes and choose Request a change, or use the same button on a service page.
  2. Pick the Service. Only active services where you can request changes are listed.
  3. Enter a Title and the Desired outcome. Focus on what should be possible; the plan derives the details. An outcome needs at least ten characters.
  4. Choose Create request. The change opens in Clarifying.

Confirm success criteria

Section titled “Confirm success criteria”

Planning stays blocked until you confirm criteria. You can confirm them straight away from Clarifying; the thread is there when you need it.

  1. Optionally use Add clarification to add context or answer questions. Every clarification moves the change to Criteria needed.
  2. A Developer can ask the AI to draft criteria from the brief and thread. The draft is visible to Developers only; you see it as editable text once it reaches you.
  3. Under Confirm success criteria, write or edit measurable outcomes, one per line, and choose Confirm criteria. The change becomes Ready to plan.

Prepare the plan

Section titled “Prepare the plan”

Choose Prepare implementation plan. Planning binds the current repository commit, the service policy revision, the assigned execution environment, exact affected paths, approved checks, scope, assumptions, risks, rollback text, and an expiry, and hashes all of it. The change shows Planning, then Plan review once a plan is ready for a Developer.

If a plan is rejected, expired, or stale, Prepare a fresh implementation plan creates a new revision; an old approval is never reused.

What you see, and what you do not

Section titled “What you see, and what you do not”

Your change page always shows your title, outcome, clarifications, confirmed criteria, and the safe lifecycle state: which step is running, whether a pull request is open, and a plain-language failure category when something stops. Plans, decisions, review findings, check evidence, commands, agent messages, and raw provider errors are visible only to Developers.

When the pull request opens, the change shows Pull request ready with a link. From there, CI, human review, merge, and release continue in your Git provider.

Section titled “Related”