setup

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