Initial commit

2025-11-30 09:08:09 +08:00
commit 931528dc65
6 changed files with 1613 additions and 0 deletions
--- a/commands/yeet.md
+++ b/commands/yeet.md
@@ -0,0 +1,248 @@
+---
+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