# Setup

> 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.

- Skill: `warpdotdev/setup-3` (Agent Skill)
- Install (CLI): `npx skillmds@latest add warpdotdev/setup-3`
- Raw SKILL.md: https://api.skillmd.com/api/skills/warpdotdev/setup-3/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra, Marketing & Growth
- Author: warpdotdev (https://skillmd.com/u/warpdotdev)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/warpdotdev/setup-3

---


# 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:

```bash
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:

```bash
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:

```bash
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:

```bash
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:

```bash
oz whoami
```

- **Command not found** → if the [Warp app](https://docs.warp.dev/getting-started/installation-and-setup) 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](https://docs.warp.dev/reference/cli#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`:

```bash
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

```bash
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:**

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

**Sentry token:**

```bash
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:**

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

**Local checkout (`REPO_DIR`):**

```bash
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:

```bash
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.