CLI Design Patterns for Developer Tools

Research Summary

Survey of modern CLI tools (2024-2026) to inform SlopDrop's CLI design decisions.

Pattern 1: Zero-Config Start

Examples: Vercel CLI, Fly.io, Railway

The best CLIs work with zero configuration. vercel deploy just works — it detects the framework, infers settings, and deploys.

SlopDrop application: slop drop file.md should work without any init step. Project name inferred from directory, tenant from credentials.

Pattern 2: Progressive Disclosure

Examples: Git, Docker, Terraform

Simple commands for common tasks, flags for advanced use. git commit -m "msg" is the 80% case. git commit --amend --no-edit --signoff is the 5% case.

SlopDrop application:

L1: slop drop file.md (most common)
L2: slop drop file.md --project research (override project)
L3: slop watch --global --initial-sync (power user)

Pattern 3: Offline-First with Sync

Examples: Obsidian, Git, Syncthing

Local operations should never fail due to network issues. Queue changes, sync when connected.

SlopDrop application: The watch queue already does this — files queue locally and upload when the API is reachable. Exponential backoff on failures.

Pattern 4: Machine-Readable Output

Examples: GitHub CLI (gh), jq, kubectl

Every command should support --output json for scripting.

SlopDrop application: Already supports --output table|json|plain globally.

Pattern 5: Daemon vs One-Shot

Examples: Docker daemon, Syncthing, fswatch

Long-running processes need: health checks, graceful shutdown, log rotation, startup-on-boot.

SlopDrop application: slop watch --global is effectively a daemon. Currently started manually via nohup. Could benefit from proper daemon management (slop daemon start/stop/status).

Recommendations

Keep zero-config as the default path
Add slop daemon for proper lifecycle management
Add health endpoint for monitoring
Implement log rotation (current watch.log grows unbounded)
Consider slop doctor for diagnostics (config validation, connectivity check, credential status)