Build Release Checks with Warp Agent

Use Warp Agent CLI to build an approval-driven release-readiness workflow.

Introduction

30 Second Summary

Release day often exposes tiny gaps that routine coding leaves behind. One missing file can turn a confident handoff into a last-minute scramble.

In this project, you will build an approval-driven release workflow with Warp Agent CLI routed to Gemini 3.8 Flash through your own Google API key. You will diagnose a missing changelog before approving the smallest repair.

What You'll Build

You will demo a controlled terminal workflow that turns a missing changelog failure into a passing release result.

By the end of this project, you'll have:

A free terminal model route that returns a response from Gemini 3.8 Flash through your personal Google API key.
A deterministic release check that blocks a missing changelog before confirming the repaired project is ready.
A reusable /release-readiness command that applies persistent project rules whenever you run the release check.
Secret Mission: Add a parameterized strict mode that also requires a security policy.

Are there any prerequisites?

A macOS device is the only prerequisite. The project covers the complete setup.

Before We Start

This step locks in the purpose of your release-readiness sandbox before the hands-on work begins. You are committing to check required release files while keeping every agent edit under explicit review.

Install Warp Agent CLI and Connect Free Inference

Your approval-driven sandbox needs an agent inside the terminal. It also needs an inference route that does not consume paid Warp usage.

In this step, you will install Warp Agent CLI in macOS Terminal. You will route Gemini 3.8 Flash through your own Google API key.

In this step, get ready to:

Install Warp Agent CLI in macOS Terminal.
Create the free accounts required for your provider route.
Route a Gemini response through your Google API key.

Install Warp Agent CLI

Warp recommends its managed installer for the standalone CLI. This installation method keeps the CLI updated automatically.

Press Cmd+Space on macOS to open the search bar.
Type Terminal into the search bar.
Press Enter to open macOS Terminal.
Install Warp Agent CLI by running this command:

curl -fsSL https://app.warp.dev/download/agent-cli | bash

What Does This Command Do?

This command downloads Warp's official managed installer. The installer adds the standalone CLI to your Mac.

The managed installation can keep itself current. You do not need to choose a version manually.

Verify that your terminal can find Warp by running:

warp --version

What Does This Check Prove?

This command prints the installed Warp Agent CLI version. A version in the output proves that macOS Terminal can find the new binary.

✔️ I see a version number

That first checkpoint is complete. Warp Agent CLI is available from your normal terminal.

Keep macOS Terminal open for the sign-in flow.

ⓧ I do not see a version

Your terminal has not found the new binary. Retry the managed installation before refreshing the terminal session.

Retry the official managed installer by running:

curl -fsSL https://app.warp.dev/download/agent-cli | bash

Why Retry the Installer?

A second run can complete an interrupted download. Read the final installer output for any environment-specific guidance.

Close macOS Terminal after the installer finishes.
Press Cmd+Space to reopen the search bar.
Type Terminal into the search bar.
Press Enter to start a fresh terminal session.
Check the installation again by running:

warp --version

What Should You See?

A successful check prints the installed version. This confirms the fresh terminal session can locate Warp.

Still Missing a Version?

Review the installer output for a failed download or an environment instruction. Confirm that your Mac has an active internet connection before retrying.

help me troubleshoot the Warp Agent CLI installation.

Create your accounts and API key

Warp uses a browser verification flow to connect the terminal session to your account. The terminal displays a verification link plus a device code.

Start Warp's interactive session by running:

warp

What Does This Command Do?

This command starts Warp Agent CLI in the current terminal. Warp displays the browser verification details required for authentication.

The interactive session remains active after sign-in. You will enter agent prompts plus slash commands in this same terminal.

Open the verification link displayed by Warp.
Enter the device code if the browser requests it.
Create your Warp account through the browser flow.
Return to macOS Terminal from earlier.

You should see the Warp prompt ready for input. Your terminal now has an authenticated agent session.

Your Warp Session Is Ready

Warp now knows which account owns this local session. Your next choice determines which provider supplies the model response.

For a new user, Google AI Studio creates a default Google Cloud project plus an API key after the terms are accepted. The project begins on Free Tier.

Keep Billing Disabled

Billing choices can feel risky. This project stays at zero cost when the Google project remains on Free Tier.

Do not select Set up billing. Moving to Paid Tier requires linking a billing account plus adding at least $5 or the equivalent in your currency.

Treat the generated API key like a password. Never capture it in a screenshot or commit it to a project.

Open the official Gemini API key guide in your browser.
Use the guide's Google AI Studio link to open the key setup page.
Sign in with your Google account.
Accept the Google AI Studio terms.
Confirm that the default Google Cloud project uses Free Tier.
Leave Set up billing unselected.
Copy the automatically created API key to your clipboard.

Keep Sandbox Data Separate

Google states that Free Tier content can be used to improve its products. Use only generated sandbox content in this project.

Keep the key on your clipboard until you add it to Warp. Do not paste it into a local file.

No Default API Key?

Confirm that you accepted the Google AI Studio terms with the account you intend to use. Refresh the key page once after completing the terms flow.

help me finish the Google AI Studio Free Tier key setup.

Connect Google inference in Warp

A bring-your-own-key route sends local model requests through your provider account. In Warp, the key icon identifies a model that uses your configured provider key.

Keep This Route Free

Warp Free includes no bundled Warp Agent usage. Your Google key supplies inference for this local session.

Keep Warp credit fallback off. Select the specific Google model with a key icon because Warp Auto models use Warp-provided inference.

Gemini 3.8 Flash input is free of charge within Free Tier rate limits. Its output is also free of charge within those limits.

Google may use Free Tier content to improve its products. Keep this session limited to the release-readiness sandbox.

Open provider key management in the active Warp session by entering:

/api-keys

What Does This Command Do?

This command opens Warp's model-provider key management. Warp accepts the Google key through a masked input plus stores it in secure device storage.

Select Google from the provider list.
Paste your Google API key into the masked input.

Your key should remain hidden while you enter it. The provider entry now has a configured key.

Confirm that Google remains configured in the provider list.
Leave Warp credit fallback off.

You should see credit fallback remain disabled. Failed provider requests cannot consume Warp-provided usage through fallback.

Open the model picker by entering:

/model

What Does the Model Picker Control?

The model picker sets the base model for the active Warp profile. A specific provider model with a key icon uses your Google key.

Select Gemini 3.8 Flash with the key icon.

You should see Gemini 3.8 Flash become the active model. This selection avoids Warp Auto routing.

Open your read-only usage panel by entering:

/usage

What Does the Usage Panel Show?

The usage panel shows your current Warp plan plus available balances. It also shows consumption plus billing links.

Read the current plan shown in the usage panel.

You should see Warp Free as the current plan. This confirms that you have not upgraded to a paid Warp plan.

Before you send the test prompt, what exact reply should a correctly routed model return?

Send the verification prompt to Gemini 3.8 Flash by entering:

Reply with WARP READY only.

What Does This Test Prove?

This prompt requests a short deterministic response from the selected model. A successful reply proves that your authenticated Warp session can reach Gemini through the Google provider route.

You should see WARP READY as the model's response. The reply confirms that your free inference route is working.

Did You Get a Different Reply?

Open the model picker with /model to confirm that Gemini 3.8 Flash is selected.
Open key management with /api-keys to confirm that Google has a configured key.
Check that Warp credit fallback remains off before retrying the prompt.

help me troubleshoot my Warp Google provider route.

That setup hurdle is cleared. Your authenticated terminal agent now answers through your own Free Tier Google route.

Your free agent route is live. Next, you will create a release checker that fails for a deliberate reason.

Make the Release Check Fail on Purpose

Your Warp Agent CLI session is authenticated in macOS Terminal. Gemini 3.8 Flash is ready through your Google API key.

A useful agent workflow needs an observable problem. This step creates a deterministic release checker that deliberately blocks an incomplete release.

The first run leaves CHANGELOG.md absent. That controlled gap gives the agent a real failure to investigate in the next step.

In this step, get ready to:

Create an isolated release lab workspace.
Add the partial release files.
Run the checker to capture its intentional failure.

Create the release lab workspace

Shell mode lets you run one terminal command from the agent input. Warp returns the input to Agent Mode after that command finishes.

In the active Warp Agent CLI session, type ! at the start of the empty input to enter shell mode.
Create the warp-release-lab folder and move into it by running this command:

mkdir -p ~/warp-release-lab && cd ~/warp-release-lab

What Does This Command Do?

The mkdir -p portion creates ~/warp-release-lab inside your home folder. The cd portion makes that folder the active working directory.

Warp returns the input to Agent Mode after the command finishes. New project files now land inside the release lab.

Good. Your isolated workspace is ready for a controlled release failure.

Add the partial release files

The README.md file explains the sandbox. The release-check.sh script turns the release requirements into repeatable file checks.

Nano is a command-line text editor included with macOS. You will use it without leaving the active terminal session.

Type ! into the empty agent input to return to shell mode.
Create README.md inside ~/warp-release-lab by running this command:

nano README.md

What Does This Command Do?

The command opens README.md in Nano. Nano creates the file in ~/warp-release-lab when you save it.

Paste this content into README.md:

# Warp Release Lab

A safe sandbox for practicing approval-driven release checks with Warp Agent CLI.

Run the standard check:

```sh
./release-check.sh
```

What Does This File Explain?

The heading gives the sandbox a clear project name.
The description identifies approval-driven release checks as the lab's purpose.
The command records how to run the standard release check.

Press Ctrl+O to save README.md.
Press Return to confirm the filename.

Nano confirms that it wrote README.md to the workspace.

Press Ctrl+X to close Nano.
Type ! into the empty agent input to return to shell mode.
Create release-check.sh inside ~/warp-release-lab by running this command:

nano release-check.sh

What Does This Command Do?

The command opens a new release-check.sh file in Nano. This file becomes the executable release checker.

Paste this checker into release-check.sh:

#!/bin/sh

required_files="README.md CHANGELOG.md"
status=0

printf '%s\n' "Release readiness check"

for file in $required_files; do
  if [ -f "$file" ]; then
    printf 'PASS: %s exists\n' "$file"
  else
    printf 'FAIL: %s is missing\n' "$file"
    status=1
  fi
done

if [ "$status" -eq 0 ]; then
  printf '%s\n' "READY: required release files are present."
else
  printf '%s\n' "NOT READY: add the missing release files."
fi

exit "$status"

How Does the Checker Work?

The required_files variable defines the two files needed for a release.
The status variable begins at 0 to represent a passing check.
The file variable holds each required filename while the loop checks for it.
A missing file changes status to 1 so the script returns a nonzero result.
The final condition prints the readiness result that matches the accumulated status.

Press Ctrl+O to save release-check.sh.
Press Return to confirm the filename.

Nano confirms that it wrote release-check.sh to the workspace.

Press Ctrl+X to close Nano.

Your workspace now contains README.md and release-check.sh. The required CHANGELOG.md file remains absent.

✔️ Awesome, I've got everything!

Your two files are saved. Keep CHANGELOG.md absent for the planned check.

ⓧ I'd like to double check the full code

These are the complete files for comparison:

# Warp Release Lab

A safe sandbox for practicing approval-driven release checks with Warp Agent CLI.

Run the standard check:

```sh
./release-check.sh
```

#!/bin/sh

required_files="README.md CHANGELOG.md"
status=0

printf '%s\n' "Release readiness check"

for file in $required_files; do
  if [ -f "$file" ]; then
    printf 'PASS: %s exists\n' "$file"
  else
    printf 'FAIL: %s is missing\n' "$file"
    status=1
  fi
done

if [ "$status" -eq 0 ]; then
  printf '%s\n' "READY: required release files are present."
else
  printf '%s\n' "NOT READY: add the missing release files."
fi

exit "$status"

Run the planned failure

The checker needs executable permission before macOS can run it directly. Its output then provides visible evidence for every release requirement.

Type ! into the empty agent input to enter shell mode.
Make the checker executable by running this command:

chmod +x release-check.sh

What Does This Command Do?

The chmod +x command gives release-check.sh permission to run as a program. The script can now return its own readiness status.

Before you run the checker, which required file do you expect to pass?

Type ! into the empty agent input to return to shell mode.
Test the partial workspace by running this command:

./release-check.sh

This Failure Is the Goal

You'll see PASS: README.md exists. You'll also see FAIL: CHANGELOG.md is missing.

The checker ends with NOT READY: add the missing release files. and a nonzero exit status. The failure proves that an incomplete release cannot pass silently.

Seeing Different Output?

Confirm that your active folder is ~/warp-release-lab if the checker cannot be found.
Repeat the executable-permission command above if macOS blocks the script.
Compare both saved files with the full-code tab if the printed lines differ.

Ask for help with the checker output.

You got the intended failure. Next, the agent will diagnose this release blocker and propose the smallest approval-driven repair.

Diagnose and Repair the Release Blocker

The failed checker from the previous step exposes a real release blocker because CHANGELOG.md is absent. That deterministic result gives the agent a concrete failure to investigate.

Warp Agent CLI can now diagnose the missing file. You will keep auto-approve off while you inspect the smallest proposed repair.

In this step, get ready to:

Ask the agent to diagnose the failed release check.
Review the proposed changelog under explicit approval.
Confirm the repaired checker passes independently.

Ask the agent to diagnose the failure

The previous shell command returned Warp's input to Agent Mode. A precise prompt asks the agent to reproduce the failure before it proposes a repair.

Before you submit the prompt, do you expect the unchanged checker to pass or to report the same blocker?

Ask the agent to investigate by submitting this exact prompt:

Run ./release-check.sh. Explain why it fails, then propose the smallest fix. Do not edit until I approve. The fix must create CHANGELOG.md with # Changelog, ## Unreleased, and - Initial release-readiness workflow.

What Does This Prompt Control?

The opening instruction makes the agent reproduce the failure with the deterministic checker.
The approval instruction separates the diagnosis from the file edit.
The final instruction defines the exact contents required in CHANGELOG.md.

You should see the agent pause on a command permission card for ./release-check.sh.

Agent Started Editing Immediately?

Reject the file edit so the workspace remains unchanged.
Confirm auto-approve is off for this conversation.

Ask for targeted help with help me restore approval-driven behavior in Warp.

Review and approve the smallest repair

Approving an agent action can feel risky. Warp's permission cards keep the exact command or diff visible before your decision.

Keep auto-approve off for this conversation.
Inspect the proposed command permission card.
Confirm the card runs only ./release-check.sh.

Before you approve the command, do you expect the checker to find a different problem or the same missing file?

Approve the checker command.

You'll see PASS: README.md exists followed by FAIL: CHANGELOG.md is missing. The run ends with NOT READY: add the missing release files..

The agent should trace the failure to the absent changelog. Its next permission card should propose one file addition.

Read the diagnosis to confirm it identifies the missing CHANGELOG.md file.
Inspect the proposed file-edit diff.
Confirm the diff creates only CHANGELOG.md.
Confirm the file starts with # Changelog.
Confirm the next heading is ## Unreleased.
Confirm the entry is - Initial release-readiness workflow..
Approve only the CHANGELOG.md addition.

Strong work. You approved only the new CHANGELOG.md file.

The existing README.md remains unchanged. The existing release-check.sh remains unchanged.

Diff Changes Another File?

Reject any diff that modifies README.md.
Reject any diff that modifies release-check.sh.
Submit the original prompt again to request the smallest repair.

Ask for help reviewing the proposal with help me verify this Warp file diff.

✔️ Awesome, I've got everything!

Your approved CHANGELOG.md addition is in place. The existing project files remain unchanged.

ⓧ I'd like to double check the full code

Compare the files in ~/warp-release-lab with the references below.

# Warp Release Lab

A safe sandbox for practicing approval-driven release checks with Warp Agent CLI.

Run the standard check:

```sh
./release-check.sh
```

Why Does the Readme Stay Unchanged?

The readme already documents the standard checker command. The missing changelog does not require a readme edit.

# Changelog

## Unreleased

- Initial release-readiness workflow.

What Did the Agent Add?

This new file satisfies the missing release requirement. Its unreleased section records the workflow as the pending change.

#!/bin/sh

required_files="README.md CHANGELOG.md"
status=0

printf '%s\n' "Release readiness check"

for file in $required_files; do
  if [ -f "$file" ]; then
    printf 'PASS: %s exists\n' "$file"
  else
    printf 'FAIL: %s is missing\n' "$file"
    status=1
  fi
done

if [ "$status" -eq 0 ]; then
  printf '%s\n' "READY: required release files are present."
else
  printf '%s\n' "NOT READY: add the missing release files."
fi

exit "$status"

Why Does the Checker Stay Unchanged?

The required_files value still names the readme and changelog.
The file value still holds each filename during the loop.
The status value still determines the final readiness result.

Verify the repair independently

The approved changelog now satisfies the missing requirement. The agent can rerun the same checker without changing another file.

Inspect the agent's next command permission card.
Confirm the card runs only ./release-check.sh.
Approve the checker rerun.

The agent's rerun shows PASS: README.md exists followed by PASS: CHANGELOG.md exists. It ends with READY: required release files are present..

The agent has proved its repair against the checker. A manual run in shell mode confirms the same result directly from your workspace.

Enter shell mode by typing ! at the start of empty input.

Before you run the checker yourself, which final status do you expect now that both required files exist?

Run the checker yourself by entering this command:

./release-check.sh

What Does This Manual Run Prove?

The command executes the local checker without relying on the agent's summary. Its result comes from the files currently present in ~/warp-release-lab.

You'll see PASS: README.md exists followed by PASS: CHANGELOG.md exists. The run ends with READY: required release files are present..

Still Seeing NOT READY?

Confirm Warp is still working in ~/warp-release-lab.
Confirm the approved filename is uppercase CHANGELOG.md.
Confirm CHANGELOG.md sits beside release-check.sh.

Get targeted help with help me diagnose why the checker still reports a missing changelog.

Your release blocker is fixed through a reviewed change. Next, you will make this approval-driven policy persist across fresh conversations.

Give the Agent Persistent Project Rules

Your release checker now passes with both required files in place. The next goal is to make its safety policy survive beyond the current conversation.

A one-off prompt can disappear with conversation history. An uppercase AGENTS.md file gives Warp Agent CLI persistent instructions for every conversation in this project.

In this step, get ready to:

Add the release policy to uppercase AGENTS.md.
Start a fresh conversation in ~/warp-release-lab.
Verify that Warp applies the project rules automatically.

Create the project rules file

Warp automatically applies uppercase AGENTS.md when it finds the file in the current project. These rules turn your approval-driven workflow into repository policy.

Ask Warp to explain its planned file addition before requesting permission to create uppercase AGENTS.md inside ~/warp-release-lab with the exact content below:

# Project Rules

- Run `./release-check.sh` before declaring a release ready.
- Never delete or overwrite existing release notes.
- Make only the smallest change required to satisfy a failed release check.
- Explain the proposed change before editing files.

What do these rules protect?

The uppercase AGENTS.md filename lets Warp discover the project policy automatically.
The ./release-check.sh rule creates a deterministic gate before release.
The release-note rule protects the existing project history.
The minimal-change rule limits the scope of every repair.
The explanation rule preserves your review point before any edit.

Inspect the proposed file-edit permission card.
Confirm that the diff adds only AGENTS.md with the four project rules.
Approve the AGENTS.md addition.

You have turned the release policy into a project file that future conversations can discover.

No file-edit permission card?

Confirm that your request requires approval before Warp creates AGENTS.md.
Verify that auto-approve remains off from the earlier step.

Ask for help with the missing approval card.

✔️ Awesome, I've got everything!

Great. Your uppercase AGENTS.md file now contains the persistent release policy.

ⓧ I'd like to double check the full code

Compare your complete AGENTS.md file with this reference:

# Project Rules

- Run `./release-check.sh` before declaring a release ready.
- Never delete or overwrite existing release notes.
- Make only the smallest change required to satisfy a failed release check.
- Explain the proposed change before editing files.

Start a fresh conversation

Conversation history can hide whether persistent guidance works. A fresh conversation isolates the test while keeping Warp inside ~/warp-release-lab.

Start a fresh Warp conversation by entering:

/new

What does this command prove?

The /new command starts a conversation without the earlier chat history. Warp remains in ~/warp-release-lab where it can discover AGENTS.md.

Any release policy mentioned next must come from the project rules file.

You will see a fresh conversation in the same active CLI session.

Did the command run as shell input?

Enter /new in the agent input area.
Confirm that the prompt has returned from shell mode before trying again.

Ask for help starting a fresh Warp conversation.

Verify the rules in fresh context

The new conversation has no memory of your earlier approval instructions. Its answer now reveals whether Warp loaded AGENTS.md from the project.

Before you ask, which release command should a rule-aware fresh conversation name?

Test project-rule discovery by sending this question:

What project rules apply here, and which command must run before release?

What should you see?

This question asks Warp to identify policy without access to the previous conversation. A matching answer proves that AGENTS.md supplied the context.

The response names ./release-check.sh as the required pre-release command.
The response protects existing release notes.
The response limits repairs to the smallest required change.
The response requires an explanation before file edits.

That confirms your project policy now survives a fresh conversation.

Are any project rules missing?

Confirm that the fresh conversation started while Warp remained in ~/warp-release-lab.
Check that the filename is uppercase AGENTS.md.
Compare the file against the full-code reference above.

Ask for help diagnosing project-rule discovery.

Your release policy now follows every conversation in this project. Next, you will package the complete check into a reusable slash command.

Turn the Workflow into a Reusable Skill

Your uppercase AGENTS.md now carries an approval-driven release policy into every fresh Warp Agent CLI conversation.

The next goal is a repeatable release command. A project-scoped skill packages the full procedure into a workflow the agent can discover.

Persistent rules leave the complete release procedure undefined. The skill fills that gap with one discoverable slash command.

In this step, get ready to:

Create the project-scoped release-readiness skill.
Refresh Warp's skill discovery.
Invoke the skill without changing the passing workspace.

Create the project skill

Each project skill lives in its own directory beneath .agents/skills/. Its SKILL.md file combines YAML frontmatter with Markdown instructions.

In the active Warp Agent CLI conversation, ask the agent to create .agents/skills/release-readiness/SKILL.md with the content below:

---
name: release-readiness
description: Check whether this project has the required release files and propose the smallest approved fix when it does not.
---

# Release Readiness

## Instructions

1. Read `AGENTS.md` and summarize the release rules that apply.
2. Run `./release-check.sh` from the project root.
3. If the check fails, explain each missing requirement and ask for approval before editing any file.
4. After an approved fix, run `./release-check.sh` again.
5. Report the final READY or NOT READY result and list any files changed.

## Constraints

- Do not enable auto-approve.
- Do not delete or overwrite existing release notes.
- Do not change files when the check already passes.

What does this skill define?

The name field creates the discoverable release-readiness command name.
The description field tells the agent when this workflow is relevant.
The instructions make AGENTS.md the policy source before the checker runs.
The constraints protect existing release notes when the project already passes.

Review the proposed edit in the file permission card.
Confirm the diff adds only .agents/skills/release-readiness/SKILL.md.
Approve the file addition.
Read the agent's confirmation that the skill file was created.

Don't see a file permission card?

Keep auto-approve off. Ask the agent to explain the proposed file addition before it edits the workspace.

If the agent proposes another path, restate the exact destination as .agents/skills/release-readiness/SKILL.md.

Ask for help to create the project skill safely.

✔️ Awesome, I've got everything!

Great. Confirm the agent saved .agents/skills/release-readiness/SKILL.md before refreshing skill discovery.

ⓧ I'd like to double check the full code

Compare your complete .agents/skills/release-readiness/SKILL.md file with this version:

---
name: release-readiness
description: Check whether this project has the required release files and propose the smallest approved fix when it does not.
---

# Release Readiness

## Instructions

1. Read `AGENTS.md` and summarize the release rules that apply.
2. Run `./release-check.sh` from the project root.
3. If the check fails, explain each missing requirement and ask for approval before editing any file.
4. After an approved fix, run `./release-check.sh` again.
5. Report the final READY or NOT READY result and list any files changed.

## Constraints

- Do not enable auto-approve.
- Do not delete or overwrite existing release notes.
- Do not change files when the check already passes.

Refresh skill discovery

Warp discovers project skills when a conversation starts in the relevant project directory. A fresh conversation loads the new skill without carrying over the earlier chat.

Type /new in the existing Warp Agent CLI input.
Type / in the fresh conversation to open the slash command menu.
Locate release-readiness in the menu.

You should see release-readiness listed as a project-scoped slash command. Its presence proves Warp discovered the skill from your workspace.

Skill missing from the menu?

Check that the file path is exactly .agents/skills/release-readiness/SKILL.md.
Confirm the frontmatter contains both name and description.
Run /new again after correcting the file.

Ask for help to debug project skill discovery.

Run the release-readiness skill

The skill now has everything it needs to read the persistent rules. It can run the deterministic checker before deciding whether a file change is necessary.

Before you invoke it, predict whether the skill should edit any file when the checker already passes.

Invoke the skill by selecting /release-readiness from the slash command menu.
Review the ./release-check.sh command permission card if Warp presents one.
Approve only the checker command.

You should see PASS: README.md exists followed by PASS: CHANGELOG.md exists. The run ends with READY: required release files are present.

Warp should report that no files changed. The passing result proves the skill follows the minimal-change policy from AGENTS.md.

Why does the skill leave files unchanged?

The checker already finds every required release file. The skill's constraints preserve that passing state.

This gives you a repeatable release check with deterministic evidence. The agent only proposes a repair when the checker identifies a real gap.

Skill tries to edit a passing project?

Reject the proposed edit. Confirm that the final constraint in SKILL.md says not to change files when the check already passes.

Keep auto-approve off so every proposed action remains reviewable. Start another fresh conversation after saving any correction.

Ask for help to stop an unnecessary skill edit.

Your /release-readiness skill now runs the approval-driven checker from a fresh conversation without touching a passing workspace. That repeatable workflow is ready whenever release time arrives.

Secret mission

Add a Strict Release Mode

Extend your release workflow with a parameterized strict mode for higher-risk releases. The strict path adds a security policy requirement while preserving the standard check.

Clean Up Your Resources

This lab has no ongoing cloud cost while Google billing remains disabled and Warp credit fallback stays off. Choose whether to keep the project available, pause the active Warp Agent CLI session, or remove its local files and credentials.

Resources you used:

The local ~/warp-release-lab folder containing your checker, release files, project rules, security policy, and project-scoped skill.
A Google provider key stored by Warp Agent CLI on this device.
A Gemini API key managed through Google AI Studio.
An authenticated Warp Agent CLI session.

Keep everything running

No action needed. Choose this if you want to keep testing standard and strict release checks.

Keep the ~/warp-release-lab folder so the checker, rules, and skill remain available.
Leave the Google provider key stored in Warp Agent CLI.
Leave the Gemini API key active in Google AI Studio.
Stay signed in to Warp so you can resume from the same account.
Keep Google billing disabled and Warp credit fallback off to preserve the zero-dollar setup.

Pause - I'll come back to this later

Close the active CLI session while keeping the project files and credentials available for later.

Exit Warp Agent CLI by entering this command:

/exit

What does this command do?

This closes the active CLI session. Your ~/warp-release-lab folder, Google provider key, Gemini API key, and Warp account remain available.

Delete - I don't want to use this again

Removing the stored credentials and local folder stops this workflow from being reused on this device. Your Warp and Google AI Studio accounts remain available.

Open provider-key management in Warp Agent CLI by entering this command:

/api-keys

What does this command do?

This opens the provider-key management panel. You can remove the Google key stored in secure device storage from this panel.

Highlight Google in the provider list.
Press Ctrl+X to clear the highlighted provider key.
Confirm the Google provider no longer shows a connected key.
Return to the Google AI Studio API Keys page.
Delete the Gemini API key you created for this lab.
Confirm the key no longer appears on the API Keys page.
Switch back to the Warp Agent CLI session in macOS Terminal.
Sign out of Warp by entering this command:

/logout

What does this command do?

This signs the CLI out of your Warp account. It does not delete the account itself.

Switch to Finder.
Navigate to your home folder.
Move warp-release-lab to Trash.
Confirm warp-release-lab no longer appears in your home folder.

Nice Work!

You made it! You built an approval-driven release workflow with Warp Agent CLI that routes Gemini 3.8 Flash through your personal Google API key. Your deterministic checker now enforces project rules through a reusable skill in standard and strict modes.

You've learned how to:

Configure BYOK model routing for Gemini 3.8 Flash while keeping Warp credit fallback disabled. Keep auto-approve off to preserve explicit approval controls.
Build a deterministic release checker that exposes missing release files through NOT READY output. Review the agent's smallest proposed repair before confirming the final READY result.
Turn project policy into persistent AGENTS.md guidance. Package the workflow as a reusable /release-readiness skill.
Secret Mission: Parameterize the checker plus skill with standard and strict modes. Require SECURITY.md only for strict release checks.

Ready to quiz yourself?