Skip to main content
These recipes show the common ways to use the command in practice. Each one uses only the options described in the command reference.

​
Review a change before anyone approves it

A reviewer can see exactly what would be sent, without a token and without sending anything:
The output shows the method, the full address and the body, with the token masked. Attach it to the review.

​
Check what is pending, in a script

Read the changes array. An empty array means nothing is pending for that version.

​
Stop a script when a refusal happens

Exit codes tell a script what kind of failure occurred:
With --output json, the refusal details are in result.json, so the script never has to parse the text.

​
Wait for a slow server

Reads are also retried automatically. A write is never retried, so a slow write that times out has to be checked with policy status before it is sent again.

​
Run the approval flow in CI

Keep the checker’s private key out of CI. The signing step runs on the checker’s own machine. A CI job can do the parts that need no key:
log verify is offline. It needs no token and no database, so it is safe to run on every pull request.

​
Use profiles for several environments

Put each environment’s address in the config file, and choose one per command:
The token stays in PARMANA_TOKEN, so the same token is sent to each profile. Do not reuse a production token against a local server.

​
Install shell completion

PowerShell:
bash: