setup

name	setup
description	Set up the Client Release Agent end to end — clone the repo (or reuse an existing clone), verify required tools, create and fill in .env, and validate credentials. Use when the user asks to run the setup skill, or to set up, install, configure, or deploy the client release agent.

setup

Get the Client Release Agent working from scratch. This skill is idempotent: it works whether the repo is already cloned or not, and never overwrites an existing .env.

Repo: https://github.com/warpdotdev/client-release-agent-oss.git

Step 1: Locate or clone the repo

Check whether you are already inside a clone:

git remote get-url origin 2>/dev/null | grep -q 'client-release-agent-oss' && echo "already in repo"

• If already inside the repo, use the current directory as AGENT_DIR and continue.
• Otherwise, check the default location, then clone if needed:

AGENT_DIR="$HOME/client-release-agent-oss"
if [ -d "$AGENT_DIR/.warp/skills" ]; then
  echo "existing clone found at $AGENT_DIR"
else
  git clone https://github.com/warpdotdev/client-release-agent-oss.git "$AGENT_DIR"
fi
cd "$AGENT_DIR"

If the user wants the repo somewhere else, use their path instead. All later steps run from AGENT_DIR.

Step 2: Verify required tools

Check for each required tool:

for tool in git gh jq curl; do
  command -v "$tool" >/dev/null || echo "MISSING: $tool"
done

If anything is missing, offer to install it (e.g. brew install gh jq on macOS, or the appropriate package manager). Then verify GitHub CLI authentication:

gh auth status

If not authenticated, ask the user to run gh auth login (interactive — let them complete it) before continuing.

If the user plans to run these skills as Oz cloud or scheduled agents (skip for purely local use), also verify the Oz CLI:

oz whoami

• Command not found → if the Warp app is already installed, the CLI ships with it. Otherwise, prefer the standalone Oz CLI — there is no need to install the full Warp app just for the CLI. See Installing the CLI; on macOS: brew tap warpdotdev/warp && brew install --cask oz.
• Not authenticated → run oz login (interactive), or for CI/headless environments export WARP_API_KEY.

Step 3: Create .env

Never overwrite an existing .env:

if [ -f .env ]; then
  echo ".env already exists — will fill in missing values only"
else
  cp .env.example .env
fi

Step 4: Fill in configuration

Ask the user which skills they plan to use so you only require the relevant variables:

• Release skills (cherrypick-to-release, cut-new-release-candidate, post-release-status): INTERNAL_REPO, REPO_DIR, GITHUB_ORG, SLACK_BOT_TOKEN, ONCALL_SLACK_GROUP, RELEASE_SLACK_CHANNEL, optionally PUBLIC_REPO.
• Sentry digest (post-daily-new-issues): SENTRY_AUTH_TOKEN, SENTRY_ORG, SENTRY_PROJECT, SENTRY_PROJECT_ID, RELEASE_SLACK_CHANNEL, ONCALL_SLACK_GROUP, optionally RELEASE_VERSIONS_URL.
• Slack replies (respond-to-slack-thread): SLACK_BOT_TOKEN only.

The release-convention variables (RELEASE_CHANNELS, RELEASE_BRANCH_PREFIX, DEFAULT_BRANCH, CHERRYPICK_BRANCH_PREFIX, RC_WORKFLOW_NAME, SYNC_TRAILER_KEY, DIGEST_CHANNEL, status emoji) all have sensible defaults — only ask about them if the user says their conventions differ. See the repo README.md for the full variable reference.

Collect the non-secret values conversationally and write them into .env with edits. For secrets (SLACK_BOT_TOKEN, SENTRY_AUTH_TOKEN):

• Never ask the user to paste a token into the chat, and never echo a token in a command.
• Tell the user to edit .env themselves and paste the tokens in directly, then confirm when done.
• Token guidance:
  • Slack: create a bot token (xoxb-…) at https://api.slack.com/apps with scopes channels:read, channels:history, chat:write, chat:update, usergroups:read, users:read, users:read.email. Install the app to the workspace and invite the bot to RELEASE_SLACK_CHANNEL.
  • Sentry: create an auth token with event:read and project:read at Sentry → Settings → Auth Tokens.

Step 5: Load the environment

set -a; source .env; set +a

Run this in the current session, and tell the user they'll need it in any future session that runs the skills (they can add it to their shell profile, CI, or scheduled-agent environment). Do not print the loaded values.

Step 6: Validate

Run only the checks relevant to the skills the user selected. Print pass/fail per check without revealing secrets.

Slack token:

curl -s -H "Authorization: Bearer $SLACK_BOT_TOKEN" \
  "https://slack.com/api/auth.test" | jq '{ok, team, error}'

Sentry token:

curl -fsS -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" \
  "https://sentry.io/api/0/projects/${SENTRY_ORG}/${SENTRY_PROJECT}/" | jq '{slug, id}'

Also confirm .id matches SENTRY_PROJECT_ID; if not, correct it in .env.

GitHub access to the release repo:

gh repo view "$INTERNAL_REPO" --json nameWithOwner --jq '.nameWithOwner'

Local checkout (REPO_DIR):

git -C "$REPO_DIR" remote get-url origin

The origin should match INTERNAL_REPO. If REPO_DIR doesn't exist, offer to clone INTERNAL_REPO there:

gh repo clone "$INTERNAL_REPO" "$REPO_DIR"

If any check fails, explain the likely cause (bad token, missing scope, bot not in channel, wrong slug) and help fix it before finishing.

Step 7: Summarize

Report which skills are ready to use given the configured variables, and show a couple of example prompts, e.g.:

• Cherry-pick PR #1234 into stable and preview
• Post the daily new-issues digest for on-call

Remind the user: .env is gitignored — never commit it.