gh-yeetrun-claude-code-plugins-yeet/commands/yeet.md

---
description: Build and deploy your project to the internet effortlessly
argument-hint: Optional service name
---

# Yeet - Effortless Internet Deployment

You are helping deploy a project to the internet using the yeet platform. Yeet makes deployment effortless by handling VMs, resources, and infrastructure automatically.

## Deployment Strategies

Yeet supports two deployment methods:

1. **Binary deployment** (`yeet run <payload>`):
   - For compiled languages: Go, Rust, C/C++, Zig
   - Also: Bun/Deno if they compile to standalone binaries
   - Fastest deployment, smallest footprint

2. **Docker deployment** (`yeet docker run <image>`):
   - For interpreted languages: Node.js, Python, Ruby, PHP
   - For projects with complex dependencies
   - For projects with existing Dockerfiles
   - Flexible, supports any runtime

## Core Process

### Phase 1: Understanding & Verification

**Goal**: Understand what needs to be deployed and verify yeet is available

**Actions**:

1. Create comprehensive todo list tracking all phases
2. Determine project location (current directory or $ARGUMENTS path)
3. Verify yeet CLI installation:
   - Check if `yeet` is available in PATH (`which yeet`)
   - If not found, inform user to install from yeet.net
4. Quick project type detection:
   - Look for go.mod, Cargo.toml, Makefile, etc.
   - Determine if project can be compiled to binary
   - If not binary-compatible, inform user early that deployment is not yet supported

### Phase 2: Requirements Gathering

**Goal**: Collect all necessary deployment configuration

**CRITICAL**: Ask specific, concrete questions. Never assume values.

**Required information**:

1. **Service name**:
   - If provided in $ARGUMENTS, use it
   - Otherwise, ask user or suggest based on project directory name
   - Explain: "This will be used in your deployment URL"

2. **HTTP port**:
   - Check code/config files for hints (listen addresses, PORT env vars)
   - Always confirm with user: "What HTTP port does your application listen on?"
   - Explain: "This is the port your application will listen on inside the container"

3. **Build configuration**:
   - For multi-binary projects (Rust workspace, Go with multiple mains): Ask which binary to deploy
   - For projects with build scripts: Ask if any special build flags are needed
   - For interpreted languages: Check for existing Dockerfile, offer to create one if missing
   - Confirm build strategy before proceeding (binary vs Docker)

4. **Optional settings**:
   - Ask if service should require login (`--require-login` flag)

**Present summary** before proceeding:
```
Ready to deploy:
- Project: [type and path]
- Service name: [name]
- HTTP port: [port]
- Build command: [what will be run]

Shall I proceed with building and deploying?
```

Wait for explicit user confirmation.

### Phase 3: Build

**Goal**: Build the project into a deployable artifact (binary or Docker image)

**CRITICAL**: Always rebuild. Never skip the build phase, even if a binary or Docker image already exists. Existing artifacts may be outdated - we must build fresh to deploy the latest code.

**Actions**:

1. Launch yeet-builder agent with all collected information
2. **Agent prompt template**:
   ```
   Build the [PROJECT_TYPE] project at [PATH] for deployment.

   Configuration:
   - Service name: [NAME]
   - HTTP port: [PORT]
   - Build strategy: [binary/docker]
   - Build target: [SPECIFIC_BINARY if applicable]

   For binary projects: Compile and return binary path
   For Docker projects: Build Docker image and return image tag

   Analyze the project, determine the correct build approach, execute the build,
   and return the artifact details (path/tag), size, and build status.

   List 3-5 key files you examined in your report.
   ```

3. Wait for builder agent to complete
4. Parse builder output:
   - Artifact type (binary or Docker image)
   - Artifact path/tag
   - Build success/failure
   - Any warnings or notes
5. If build failed, help user fix issues based on builder's report

### Phase 4: Deploy

**Goal**: Deploy the built artifact using yeet CLI

**DO NOT START WITHOUT USER APPROVAL**

**Actions**:

1. Verify artifact exists (binary file or Docker image)
2. Show final deployment preview:
   ```
   Ready to deploy:
   - Artifact: [binary path or docker image] ([size]MB)
   - Type: [binary/docker]
   - Service: [name]
   - Port: [port]
   - Command: [yeet run ... OR yeet docker run ...]

   Proceed with deployment?
   ```

3. Wait for explicit approval
4. Launch yeet-deployer agent with deployment configuration
5. **Agent prompt template**:
   ```
   Deploy the [binary/Docker image] using yeet CLI.

   Configuration:
   - Artifact type: [binary/docker]
   - Artifact: [binary path or image tag]
   - Service name: [NAME]
   - HTTP port: [PORT]
   - Require login: [yes/no]

   Use `yeet status` to check for existing services first.

   For binary: Use `yeet run <binary> --service=... --http-port=...`
   For Docker: Use `yeet docker run <image> --service=... --http-port=...`

   Use `yeet docker --help-llm` and `yeet docker run --help-llm` for Docker options.

   Extract and return the deployment URL and status.
   ```

6. Monitor deployment progress
7. Handle deployment errors by helping user resolve issues

### Phase 5: Completion

**Goal**: Provide user with deployment results and next steps

**Actions**:

1. Mark all todos complete
2. Present deployment summary:
   ```
   Deployment successful!

   Service: [name]
   URL: [deployment URL from yeet output]
   Status: Running

   Management commands:
   - View logs: yeet logs [name]
   - Restart: yeet restart [name]
   - Stop: yeet stop [name]
   - Status: yeet status [name]
   - Remove: yeet remove [name]

   To update: Run /yeet again with the same service name
   ```

3. Suggest next steps:
   - Test the deployment URL
   - View logs to ensure app is running correctly
   - Set up any needed environment variables via `yeet edit`

## Error Handling

### Yeet CLI Not Found
```
The yeet CLI is not installed. Please install it from yeet.net to deploy your project.

Once installed, run /yeet again to deploy.
```

### Docker Build Needed
```
This appears to be a [Node.js/Python/Ruby] project. I'll use Docker for deployment.

[Check for existing Dockerfile]
- If Dockerfile exists: I'll use it to build the image
- If no Dockerfile: I'll create one optimized for [language/framework]

What port does your application listen on?
```

### Build Failure
```
Build failed: [error message]

Suggested fixes:
- [specific suggestions from builder agent]

Would you like me to try again with different build settings?
```

### Deployment Failure
```
Deployment failed: [error message]

[Parse error and provide specific guidance based on deployer agent output]

Common issues:
- Authentication: Run `yeet` alone to authenticate
- Port conflicts: Try a different port
- Service name conflict: [suggest alternatives]
```

## Important Guidelines

1. **Never assume** - Always ask for service name and port
2. **Always rebuild** - Never skip the build phase, even if artifacts exist. Always run the builder agent to create fresh builds
3. **Check first** - Always run `yeet status` before deploying to detect existing services
4. **Confirm updates** - If service exists, confirm user wants to update it
5. **Be explicit** - Tell user exactly what you're about to do
6. **Use TodoWrite** - Track progress throughout entire workflow
7. **Support both strategies** - Binary for compiled languages, Docker for interpreted
8. **Sequential agents** - Launch builder first, then deployer (never parallel)
9. **Parse carefully** - Extract deployment URLs and errors from yeet output