Everyday CLI Workflows

These recipes use OWNER/NAME, NUMBER, RUN_ID, and similar placeholders. Inside a checkout, commands with -R/--repo usually infer the repository from the Git remote. Keep -R OWNER/NAME in scripts so the target is unambiguous.

Start the day

try status combines account work and recent operational state. Inside a repository, repo context adds the resolved repository, branch, current pull request, viewer, and recent CI context.

try status
try repo context

Scripts and agents can request JSON output from both commands when they need a stable structured result.

Create and clone a repository

Create a repository with an explicit owner, visibility, and default branch:

try repo create project-name \
  --owner OWNER \
  --private \
  --auto-init \
  --default-branch main \
  --description "Project description"

Clone the server-created history rather than creating a separate local root commit:

try clone OWNER/project-name project-name
cd project-name
try repo context

try repo clone is the grouped equivalent of the root try clone command. Both accept OWNER/NAME, a Trylle repository URL, or an SSH Git URL.

Open a pull request

Create and publish the branch with Git first:

git switch -c feature/short-name
# Edit and test the change.
git add path/to/files
git commit -m "feat: describe the change"
git push -u origin HEAD

Check whether the branch already has an open pull request, then create one with an explicit base and a body file:

try pr current
try pr create \
  --title "Describe the change" \
  --base main \
  --body-file pr-body.md

try pr current exits nonzero when no open pull request exists. Treat that as the expected absence case. In scripts, try repo context is easier when a nullable currentPullRequest field is preferable.

Verify the result and print its URL without opening a browser:

try pr status NUMBER
try browse pr NUMBER --no-open

Review and merge a pull request

Read the pull request, its structured diff, and current checks:

try pr view NUMBER -R OWNER/NAME
try pr diff NUMBER -R OWNER/NAME
try pr status NUMBER -R OWNER/NAME

For a terminal review surface, use the interactive diff viewer:

try diff --pr NUMBER --origin OWNER/NAME

Submit exactly one review decision:

try pr review NUMBER -R OWNER/NAME \
  --approve \
  --body-file review.md

Replace --approve with --request-changes or --comment as appropriate. Inline review comments additionally require the pull request's current head SHA through --commit-id.

Re-check mergeability immediately before merging:

try pr status NUMBER -R OWNER/NAME
try pr merge NUMBER -R OWNER/NAME \
  --method squash \
  --delete-branch

Triage issues

Fetch enough rows before applying local filters, then inspect the issue and its timeline:

try issue list -R OWNER/NAME --state open --per-page 100
try issue view NUMBER -R OWNER/NAME
try issue timeline NUMBER -R OWNER/NAME

Create or comment with a body file when the text is more than a short sentence:

try issue create -R OWNER/NAME \
  --title "Concise issue title" \
  --body-file issue-body.md

try issue comment NUMBER -R OWNER/NAME \
  --body-file comment.md

Preserve unrelated labels with additive changes:

try issue label NUMBER -R OWNER/NAME \
  --add triage \
  --remove needs-info

--set replaces the complete label set. Use it only when replacement is intentional.

Work with a pull request stack

Create each dependent branch from its intended parent branch:

try stack create feature/child

After the child pull request exists, record its parent and inspect the stack:

try stack track --pull CHILD_NUMBER --parent PARENT_NUMBER
try stack log

Navigate and update the current series:

try stack prev
try stack next
try stack restack
try stack sync --pull PARENT_NUMBER

stack restack runs a Git rebase and can stop on conflicts. stack submit pushes the current HEAD to origin before it creates a pull request, so it is both a local Git write and a platform write:

try stack submit

Diagnose CI

Select the exact run ID before reading logs or changing state:

try ci list -R OWNER/NAME --limit 20
try ci view RUN_ID
try ci logs RUN_ID
try ci watch RUN_ID

Cancel only after confirming that the selected run is active:

try ci view RUN_ID
try ci cancel RUN_ID

See the CI documentation for workflow compatibility, usage, and deeper troubleshooting.

Manage variables and secrets

Repository variables are plain text:

try actions variable list -R OWNER/NAME
try actions variable set DEPLOY_REGION us-east-1 -R OWNER/NAME

For a secret, inject the value before the command and avoid shell tracing or logs that reveal expanded arguments:

# DEPLOY_TOKEN is already supplied by a secret manager.
try actions secret set API_TOKEN "$DEPLOY_TOKEN" -R OWNER/NAME
unset DEPLOY_TOKEN
try actions secret list -R OWNER/NAME

Organization-scoped values are available through try org secret, try org variable, or the --org ORG option on try actions leaf commands.

Operate automations and bots

The CLI can inspect and toggle existing automations:

try automation list
try automation runs AUTOMATION_ID --limit 20
try automation disable AUTOMATION_ID
try automation enable AUTOMATION_ID

It does not create automation definitions. Create them through the platform, then use the CLI for routine operations.

The bot commands list existing identities and print or mint their tokens:

try bot list
try bot token BOT_ID

try bot token can return secret material. Do not run it in a transcript or log unless the destination is designed to receive and protect the token. Creating a new bot identity is also a platform operation rather than a CLI command.

Use an uncovered API endpoint

Prefer a first-class command whenever one exists. For a public /v1 endpoint that is not covered, use try api:

try api /v1/example -q owner=OWNER -q repo=NAME
try api /v1/example -X post --input request.json

After a write, verify with a first-class read command or a GET request.