Progen

Step 3 — Derive config from the user's description

Read the user's description and map it onto the fields above:

• App/artifact identity: look for an explicit name, company/org (→ GroupID), or repo-style slug (→ ArtifactID, AppName). If genuinely absent, this is mandatory — ask (see Step 4).
• Kind of app: "API", "backend", "microservice" → RestApi. "website", "server-rendered pages", "HTMX" → WebApp (and set HTMXSupport if HTMX is mentioned). "Angular", "SPA", "single page app" → SpringBootAngularFullStack.
• Build tool: "Maven"/"Gradle" mentioned explicitly → use it; otherwise default Maven.
• Persistence: "JPA"/"Hibernate" → SpringDataJPA; "JdbcClient"/"plain JDBC"/"no ORM" → SpringJdbcClient; "jOOQ" → SpringJOOQ.
• Database: "Postgres" → PostgreSQL; "MySQL" → MySQL; "MariaDB" → MariaDB.
• Migrations: "Flyway" or unspecified → Flyway; "Liquibase" → Liquibase.
• Feature keywords → booleans:
  • AWS/S3/SQS/Cloud → SpringCloudAWSSupport;
  • email/SMTP/notifications → EmailSupport;
  • RabbitMQ/messaging/queue → RabbitMQSupport;
  • caching/Redis → RedisCachingSupport;
  • tracing/observability/OpenTelemetry → OpenTelemetrySupport;
  • Kubernetes/k8s/Helm-adjacent manifests → K8sSupport.
• Anything not mentioned: leave at its default rather than asking — only the identity fields in Step 4 are worth interrupting the user for.

Step 4 — Ask about missing mandatory info

Only pause to ask when AppName, GroupID, or ArtifactID cannot be reasonably derived from the description (progen's own prompt flow treats these three as required; everything else has a sane default). Ask concisely, e.g.:

What should the app/artifact be called, and what's the group id (e.g. com.acme)?

Don't ask about AppType, BuildTool, PersistenceType, DbType, DbMigrationTool, or the feature booleans — apply the Step 3 mapping and fall back to defaults silently.

Step 5 — Generate the project

Write the derived config to a .progen.json file, then run progen non-interactively:

cat > .progen.json <<'EOF'
{
 "AppType": "REST API",
 "AppName": "orders-service",
 "GroupID": "com.acme",
 "ArtifactID": "orders-service",
 "AppVersion": "1.0.0",
 "BasePackage": "com.acme.ordersservice",
 "BuildTool": "Maven",
 "PersistenceType": "Spring Data JPA",
 "DbType": "PostgreSQL",
 "DbMigrationTool": "Flyway",
 "SpringCloudAWSSupport": false,
 "ThymeleafSupport": false,
 "HTMXSupport": false,
 "EmailSupport": false,
 "RabbitMQSupport": false,
 "RedisCachingSupport": false,
 "OpenTelemetrySupport": false,
 "K8sSupport": false
}
EOF
progen -c .progen.json

This creates a new directory named after AppName containing the generated project (and drops a copy of the resolved config as <AppName>/.progen.json). Any invalid enum value is replaced with its default and a WARNING: is printed — check the command output for these.

Step 6 — Features progen doesn't support

progen only knows the fields in Step 2's table. If the user asked for something outside that list (e.g. GraphQL, a specific cloud provider integration beyond Spring Cloud AWS, a particular auth provider, gRPC, a non-listed database, CI platform other than GitHub Actions):

1. Generate the base project first using the closest matching config from Steps 3–5.
2. Then add the extra feature by hand-editing the generated project — treat it as a normal Spring Boot codebase from that point on (respect its existing conventions: package layout under BasePackage, the chosen persistence/build tool, existing test setup, etc.).

Don't block project generation waiting on unsupported-feature design decisions — scaffold first, layer the custom feature on top second.