How to use a Righthand with CircleCI

Quick answer

Use Righthand to prepare a CircleCI workflow receipt showing which jobs ran and which approvals remain. A passed test job does not prove the deploy job executed.

Start with a reviewable deliverable, keeping CircleCI as the accepted home for its records. This guide uses an explicitly approved snapshot or browser read; it does not assume that every provider API action is exposed by your Righthand connection.

Evidence and access

CircleCI documents workflow orchestration and manual approval gates. See the official CircleCI reference. Provider capabilities and Righthand's available tools are separate checks.

Use the approved project's pipeline and workflow receipts with commit references, branch, job names, statuses, and owner-defined required checks. Verify the required tools and owner-approved scope through Righthand integrations; use the supplied packet when a native read is unavailable.

Define the objects and authority

Include these fields in the working input: workflow ID, pipeline ID, commit SHA, branch, job, state, required approval, artifact reference. These are the requested review columns, not a promise that every provider endpoint returns them under those exact names.

Approving jobs, rerunning work, and deploying require operator authority. Keep blocked, skipped, and completed states explicit.

Illustrative first-run brief

Use the owner-provided CircleCI snapshot or approved read-only view. Review the supplied release workflow against the accepted job list. Identify failed jobs and unfulfilled approval dependencies. Do not approve, retry, or deploy. Run once for the agreed sample, using America/Los_Angeles for the review deadline and preserving source timestamps separately. Return the draft in this conversation by Friday at 3 PM Pacific for the release operator to review. Include source references and missing fields. Do not write records, spend money, change permissions, or send external messages. Stop and report an unavailable source rather than substituting another account.

Expected result and verification

Tests can pass while deployment waits on a hold job. The receipt states that the release is not yet deployed.

Match workflow and commit IDs and check the actual deploy job's terminal state. Record the source cutoff, applied filters, and items excluded from the sample. The reviewer should be able to follow each consequential finding back to an original object. A well-written summary is not evidence that a proposed action happened. If a later write is authorized, verify its specific result separately before changing the task's status.

Illustrative input and draft output

These synthetic entries show the requested review, not live account results or a provider field schema.

Common failure and recovery

A rerun can create new job IDs or different artifact context. Keep the intended run and latest relevant evidence distinct.

If a workflow passed while a required job was skipped, retain the skip and ask the release owner whether the acceptance criterion was actually met.

FAQ

What should the reviewer verify first?

Verify pipeline, workflow, job IDs, commit, branch, and terminal results. A passed optional workflow does not establish all required release checks ran.

How should a repeat run be scoped?

Preserve exact commit and workflow IDs between reviews. Inspect retries and skipped jobs separately; do not combine results from different commits into one release receipt.

For connection and permission details, use Righthand Docs. Review Pricing alongside any separate provider charges before expanding the workflow.