project-scaffoldinglisted

# Project Scaffolding A scaffold invented from habit instead of from the ecosystem's actual convention costs the project every time a new contributor or tool (a linter, a build system, a package registry) expects the structure it's used to and doesn't find it. This skill scaffolds to the real convention, and states which one it's following. ## Step 1 — Identify the actual project type first The correct scaffold depends on more than the language: a library has different needs than an application; a single service is structured differently from a monorepo; a CLI tool differs from a long-running service. Get this right before creating a single directory — the "generic" scaffold that ignores this distinction is wrong for most of the specific cases it gets applied to. ## Step 2 — Follow the ecosystem's real convention, and say which one Use the layout the language/framework's own tooling and community actually expect (for example: a Python package's expected `src/` layout and packaging metadata file, a Node project's expected manifest and source/output separation, a Go module's expected command/internal package conventions, a framework's own CLI-generated structure where one exists). State explicitly which convention is being followed and why — presenting an idiosyncratic structure as if it's the standard one misleads anyone who later assumes it behaves like a familiar project of that type. ## Step 3 — Separate concerns clearly Source, tests, configuration, build output, an