Build projects faster with a scaffolder that asks what you’re actually building

Developers spend too much time copy-pasting boilerplate, rewriting the same folders, and deleting placeholder content after every create-x-app run. A project scaffolder that asks what you are building — like project-cli, the MIT-licensed npm package by Supun Kalhara Jayasinghe — breaks that loop by mapping the scaffold to your actual intent instead of just your tech stack. This is not just a UX flourish; it delivers a starter codebase tailored to the project, not just the framework banner. For anyone shipping marketing sites, dashboards, or chat apps, that distinction is the difference between a long cleanup treadmill and getting to real code fast. Here is how intent-driven scaffolding works, how to use it, and what it enables for serious projects.

A sourcing note first: the original version of this article cited a Medium piece by the tool's author that has since been deleted (the URL now returns 410). Every product claim below has been re-grounded in live sources — the npm registry entry for @supunkalharajayasinghe/project-cli, currently at version 1.3.2, and its GitHub repository. Time-saving figures are illustrative, not measured benchmarks.

What a scaffolder that asks what you are building is

Traditional project scaffolders, from the original create-react-app to create-next-app, start by asking what framework or stack you want. Answer the stack question and you get a generic starter — same folders, same welcome page, same junk you spend the next stretch deleting or rewriting.

A scaffolder that asks what you are building flips that script. The first question is not "React, Vue, or Svelte?" — it is "are you building a marketing site, a SaaS dashboard, or a chat app?" That one bit of intent powers the entire downstream scaffold: routes, folder structure, starter content, dependencies, and sensible defaults tailored to the actual outcome, not just the framework. Intent first, framework second.

This makes project-cli more than a create-x-app alternative. It is a scaffolder for different project types — "what are you actually building?" comes first, producing a codebase that fits the project from the start. The registry entry confirms the package reality behind the claim: published under the author's scope, exposing both project-cli and my-cli binaries, with its source and issue tracker on GitHub. That is a real, installable tool — not a concept post.

Why traditional boilerplate setup slows development

Every developer who has shipped more than one project knows the pattern. You run create-x-app, you get a fresh repo with placeholder copy and demo pages — then the real work begins. Delete the starter page, set up the folders you always need, add routine dependencies, write your .env.example, and remove the welcome screen that was never meant to ship.

For illustration, picture roughly 40 minutes of that per project before a single line of meaningful code is written — deleting, rewiring, installing, rewriting. Multiply across team members or frequent prototyping and it becomes a material productivity drag, which is exactly the pain the intent-first approach targets. (That figure is an illustration of the pain shape, not a measured benchmark.)

The pain points are consistent:

• Deleting placeholder pages and assets
• Redoing folder structure to fit the real project domain
• Reinstalling or adding common dependencies (linting, UI kits, analytics, CI/CD)
• Setting up .env files and reconfiguring build scripts for each use case
• Rewriting generic content that was only ever meant as a template

Boilerplate automation misses the mark when it never asks the higher-level question about what you are building. If all you pick is a framework, you get a shell — not a starter for your actual workflow.

How project-cli tailors starters to your needs

project-cli attacks the root cause by starting from user intent. Instead of immediately asking for a framework, it launches with the question that determines everything downstream: what blueprint are you building?

You run (binary name verified against the published package):

npx --package=@supunkalharajayasinghe/project-cli project-cli create

The prompts walk through your intent, not your stack:

Project name: my-app
Choose a project blueprint: Website -- landing page, portfolio, business site, documentation
What type of website? One-page landing page
Which sections do you want? Hero, Features, Contact
Add SEO starter files? Yes
Add contact form placeholder? Yes
Add Docker files? No
Add GitHub Actions CI? Yes
Install dependencies after generation? No

The impact: a Next.js project on disk, but shaped around the actual answers you gave — with only the sections you plan to ship, out-of-the-box SEO and contact form wiring, and real starter content that fits. Not a generic welcome app.

It is not just cosmetic. The tool supports three high-level blueprints:

• Website: landing pages, portfolios, documentation. Pick single or multi-page, exactly which sections you need (Hero, Features, About, Pricing, FAQ, Contact). SEO files and contact logic set up by default.
• Full-stack product: SaaS, dashboards; ships with product-focused sections, persistent navigation, auth, and sensible production and development builds.
• Chat app: pre-wired layouts and state, ready for real-time features or bot integrations.

The scaffolded result is closer to a first commit on a real repo than a demo shell. You shape the output by declarative intent, getting automation that fits the way you actually work.

How to use project-cli today: step-by-step guide

Turning this into a first build is direct. Here is the minimum reproducible workflow.

1. Install and run project-cli.

No global install. Use npx for the latest version:

npx --package=@supunkalharajayasinghe/project-cli project-cli create

2. Answer prompts about your project intent.

The CLI session guides you through project name (for example my-new-site), project blueprint (Website, Full-stack Product, Chat App), website type and specific sections for the Website path, and whether to include scaffolds for SEO, contact forms, CI/CD via GitHub Actions, and Docker files. Example session:

Project name: saas-landing
Choose a project blueprint: Website
What type of website? One-page landing page
Which sections do you want? Hero, Pricing, Contact
Add SEO starter files? Yes
Add contact form placeholder? Yes
Add Docker files? No
Add GitHub Actions CI? Yes
Install dependencies after generation? No

3. Review and customize the generated project.

On disk, you now have a folder matching your answers: only the sections you selected, starter SEO and environment setup tailored to those sections, optional CI/CD and Docker assets pre-wired — or not, based on your choices. The difference is minimal dead code. Almost no delete-before-launch busywork. You jump straight into features, design, and logic.

4. Iterate or extend.

The generated project uses modern Next.js conventions. Modify page content, scaffold additional features, or wire up APIs — but the foundation is intent-fit, with no framework-scaffolding cleanup standing between you and real work.

For the package source, issue tracker, and version history, start at the npm page and the GitHub repo.

Why intent-driven scaffolding beats traditional starters

Intent-driven scaffolders short-circuit the classic pain cycle:

• Time saved: setup collapses from the clean-rewire-install-rewrite treadmill to a guided config that writes what you need. No placeholder deletion, less wasted editing.
• Project-fit structure: you choose sections and starter content up front. The folder tree and files reflect your blueprint, not a generic demo app meant for deletion.
• Fewer errors and less fatigue: less manual editing means lower breakage risk — stray files and unused code do not pile up in source control.
• Faster feature work: teams get a repo ready for the first feature, not the first cleanup commit. Iteration starts in real context.
• Modern workflows out of the gate: optional CI/CD, SEO, and common tooling included at scaffold time where relevant — no post-hoc surgery.

For developers prototyping frequently — internal tools, SaaS products, landing pages — that process advantage compounds with every new project. And the principle extends past scaffolding CLIs: the fastest starters are the ones whose defaults already encode production reality. OTF kits apply the same intent-first idea at the template level — full-stack starters shaped around what you are shipping, not bare framework shells. Browse kits by what you are building.

The future of scaffolding and boilerplate automation

Project scaffolding is trending toward higher-level automation and intelligence. Tools like project-cli point to a future where intent, not just stack, drives setup. Contextual project creation — "what am I trying to ship?" — becomes the new baseline, not just "what language am I writing?"

The next wave: more granular blueprints, built-in support for common architectures (multi-tenant SaaS, content sites, AI agent backends), and likely AI-driven customization for even finer project fit. The through-line is the same — push project knowledge earlier into the pipeline so less of it gets reconstructed by hand afterward.

project-cli is a real example of this evolution: intent-driven, editable, and closer to production code than old-school demo shells. And its provenance story carries its own lesson — when the launch announcement lives only on a rented platform, link rot eats your citations. Grounding this retrofit in the package registry and the code repo instead of the deleted post is what keeps it verifiable.

Related reading on agent-ready project setup: Cursor rules for Next.js, Cursor prompts for agent sessions, Agent-readable repository structure.

Sources

• @supunkalharajayasinghe/project-cli on npm — version 1.3.2, MIT license, author, published binaries.
• ts-cli-tool on GitHub — source repository, homepage and issue tracker per the registry entry.
• The author's original Medium announcement has been deleted (HTTP 410); no claims in this article depend on it.

Originally published at otf-kit.dev — full-stack kits your AI coding agent can actually ship to production. See the kits →