Greenfield Project Scaffolding

Greenfield Project Scaffolding

Choose the project root and its normal layout before the first write.

1. Confirm current-turn authorization and a complete enough request. Authorization is satisfied only when the current user turn itself explicitly asks to start, implement, build, scaffold, or go ahead with a new project now. Answers to prior questions, planning or decision turns, and reminders that work remains do not authorize this workflow without those implementation-now words in the same user turn. If authorization is absent, stop without project-shape work or a file write. If product behavior or delivery constraints are missing, visibly truncated, or materially ambiguous, ask one focused clarification question and stop until the answer resolves the gap. Do not invoke this workflow merely because the deliverable is an application or game.

2. Resolve explicit placement before treating it as unknown. here, this folder, the current folder, this directory, and the current directory count as targets only when permitted facts confirm that the current directory is a suitable intended project root. A home-like, general-purpose, or false-empty current directory is not made suitable by deictic wording. Preserve an explicit named path and an existing project root. Existing repositories, projects, or notebooks remain excluded.

3. Honor inspection limits. When the user forbids inspecting existing files, honor that restriction. Use only the request, pwd, and path semantics. Do not list or read nearby content. When an explicit no-peek constraint leaves placement unresolved, create a user-meaningful dedicated subdirectory from the request and path semantics. Skip all discovery steps below.

4. Otherwise reuse the permitted inspection that triggered this workflow. Use the request, pwd, and observed top-level entries and project markers. Do not repeat an already completed read solely for this workflow. Inspect only placement facts that remain missing and are allowed by the user. Determine whether the user named a target and whether the current directory is already the intended project root. Do not adopt an unrelated nearby repository merely because it exists.

5. Reject a risky root before project work. When permitted inspection proves that the current directory is home-like, general-purpose, or contradicts an empty/current-root premise, treat it as requiring a dedicated child. Treat a home-like, general-purpose, or false-empty current root as closed to project artifacts. The first project mutation must establish the dedicated child. Keep every scaffold path and scaffold command working directory beneath the chosen root.

   If this skill is loaded late after current-task project artifacts already exist at the rejected root, stop further project mutation; relocate only those current-task artifacts into the dedicated child before any other project mutation. Relocate rather than duplicate them. Do not copy, synchronize, or mirror them back to the rejected root. Continue exclusively in the dedicated child. Do not inspect, move, or delete unrelated content while repairing the task's paths.

   Choose exactly one root:

   • Preserve an explicit named path or existing project root.
   • Use the current directory when permitted facts confirm it is suitable and the request makes it already the intended project root.
   • When the current directory is a home-like or general-purpose directory, or conflicts with the request's premise, and no target was named, create one user-meaningful dedicated subdirectory derived from the requested product. Do not add another wrapper directory inside the chosen root.

6. Use the ecosystem-native layout inside that root. Keep entry points, package files, source, tests, and assets where that ecosystem normally puts them. Create a directory only when the ecosystem convention or concrete near-term contents need it; do not create a directory that would contain only one file as decoration. Avoid placeholder files and speculative layers. For a playable browser app or game using no-build vanilla HTML/JavaScript that was not explicitly requested as standalone or single-file, keep the entry HTML in the dedicated project root and put substantial behavior in at least one separate authored .js or .mjs source file. For a framework or typed stack, use the normal source modules for that stack; do not force a root HTML file or a token JavaScript file. When the request explicitly chooses a standalone, single-file, paste-ready, or offline artifact shape, preserve it and defer artifact and verification mechanics to bundled:browser-app-delivery.

7. Scaffold the smallest complete runnable shape the request needs, then use the applicable delivery or verification workflow. Report the chosen root clearly.

8. Before handoff, audit known paths and paths created or changed for this task. Keep its scaffold artifacts under exactly one chosen project root. Relocate or remove only current-task artifacts outside it; do not inspect, move, or delete unrelated content.