sivaprasadreddy/sivalabs-agent-skills/progen

progen: Spring Boot Project Generator

progen is an offline, single-binary Go CLI (https://github.com/sivaprasadreddy/progen) that scaffolds a complete, production-ready Spring Boot project: build files, Java source, tests, Docker Compose, GitHub Actions, DB migrations, security, and more.

This skill's job: turn a user's description of the app they want into a .progen.json config, fill gaps by asking the user, run progen to generate the project, and — if the user asked for anything progen can't do natively — layer that on afterward by editing the generated code.

Step 1 — Ensure progen is available

Check for a working binary:

progen --version

If not found (or version looks outdated and the user wants latest), download the right asset for the current OS/arch from the latest release:

# Example for macOS arm64 — adapt OS/ARCH from `uname -s` / `uname -m`
curl -L -o progen.tar.gz \
  "https://github.com/sivaprasadreddy/progen/releases/latest/download/progen_<os>_<arch>.tar.gz"
tar -xzf progen.tar.gz
chmod +x progen
sudo mv progen /usr/local/bin/   # or anywhere on PATH
progen --version

If the exact asset naming isn't obvious, fetch the releases page (https://github.com/sivaprasadreddy/progen/releases) to find the correct filename for the user's OS/architecture before downloading. If a Go toolchain is available, go install github.com/sivaprasadreddy/progen@latest also works and avoids the asset-naming problem entirely.

On macOS, downloaded binaries may trigger a Gatekeeper "cannot be opened because the developer cannot be verified" error — tell the user to right-click → Open once in Finder to approve it (or xattr -d com.apple.quarantine progen if working non-interactively is fine with them).

Step 2 — Config schema (.progen.json)

progen takes no scaffolding info via flags — everything goes through a JSON config file consumed as progen -c <file> (interactive prompts are the only other input path, and are not used by this skill). Field names below are exactly as marshaled to JSON (Go field names, capitalized).

Notes:

• Spring Modulith package structure, Docker Compose, Testcontainers, JUnit, Spotless, SDKMAN, GitHub Actions, Renovate, and .editorconfig/AI-assistant config files are always generated — there's no toggle for them.
• "Spring Boot + Angular Full Stack" additionally scaffolds an Angular + TailwindCSS frontend; HTMXSupport and ThymeleafSupport don't apply to it.
• Get a fresh copy of these defaults any time with progen init, which writes a .progen.json pre-filled with the defaults above into the current directory.

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.