Generate staged project plans from design through deployment. Use when planning App Platform projects, breaking complex deployments into resumable stages, or tracking multi-step infrastructure setup.
Instrucciones de origen · Vista previa de solo lectura
name
planner
version
1.0.0
min_doctl_version
1.82.0
description
Generate staged project plans from design through deployment. Use when planning App Platform projects, breaking complex deployments into resumable stages, or tracking multi-step infrastructure setup.
related_skills
["designer","deployment","postgres","networking"]
deprecated
false
Planner Skill
Generate staged project plans that break complex projects into manageable, resumable steps - from initial design through coding, testing, to cloud deployment.
Tip: For a complete overview of all available skills, see the root SKILL.md.
Greenfield vs Brownfield Detection
Scenario
Detection
Behavior
Greenfield
No Dockerfiles, no
.do/app.yaml
Create artifacts from scratch
Brownfield
Dockerfiles and/or .do/app.yaml exist
Review, validate, enhance existing
The AI assistant automatically detects the project state. Don't recreate valid artifacts. The critical validation gate is doctl app dev build — if that passes, artifacts are correct.
Why Staged Deployment?
Complex App Platform deployments fail when executed monolithically:
Blind deployment fails - Deploying without infrastructure prep results in cryptic errors
Context is lost - Credentials, cluster IDs, and progress are forgotten between sessions
Debugging is harder - When everything deploys at once, it's unclear which component failed
Resumability is poor - Starting over wastes time; partial progress isn't tracked
Build Locally First
CRITICAL: Always validate builds locally before cloud deployment.
doctl app dev build # Build using local app spec
doctl app dev build --app <APP_ID> # Build using existing deployed app
doctl app dev build --env-file .env# Build with environment overrides
Does user mention Kafka, OpenSearch, workers, or "event-driven"?
YES → Tier 3 (Complex)
NO → Does user mention database (PostgreSQL, MySQL, MongoDB)?
YES → Tier 2 (Database-backed)
NO → Tier 1 (Simple)
Detection from app.yaml (Fallback)
If .do/app.yaml exists:
workers present → Tier 3
databases with KAFKA or OPENSEARCH → Tier 3
databases present → Tier 2
Neither → Tier 1
Tier Structures
Tier 1: Simple (5 stages)
Criteria: Static sites, single service, no database
