envoydev Project Build From Scratch - Greenfield Design, Scaffold, Build
Use this skill to build a new application or a major new module from scratch, before code exists. The design happens here, in-session - there is no dispatched greenfield seat: with no code to read, a design pass reasons from the spec that is already in this conversation, and its options come back to the user anyway. The frontmatter pins the invoking turn to opus/xhigh, so DESIGN runs on the architect's budget regardless of the session model (the pin lasts the turn - after the user's pick, orchestration resumes on the session model, which is fine: scaffold and build are dispatch mechanics).
Steps
1. DESIGN - in-session, on the pinned turn
Turn the spec into 2-3 reasoned architecture options - stack, architecture style, folder/module shape, state and persistence approach - each with its tradeoffs, using the brainstorming discipline plus the stack's architecture skills (the per-stack table below names them). Ground every option in the house skills, not recall. A spec gap that blocks the design is a question to the user (the superpowers brainstorming + AskUserQuestion path), never a guess. Multi-stack designs name the seam and its producer/consumer direction up front - the build step will run it producer-first per project-solve-cross-task.
2. THE PICK - hard gate
Present the options, then put the pick through AskUserQuestion - one option per architecture, its stack and one-line tradeoff as the description, a custom direction always available via Other (plain-text options where the harness lacks the tool). Greenfield tech choices are the user's, never silently picked - nothing is scaffolded before this gate.
3. SCAFFOLD
Run the named new-project command (dotnet new <template>; ng new; ionic start for Ionic), establish the structure from the chosen architecture skill, and wire the baseline - DI, config, a test project, formatter/analyzer config - via the stack's setup skills (dotnet-project-setup + dotnet-code-quality on .NET).
4. BUILD - slice by slice
When dispatch is available, ask ONE question before the first slice, via AskUserQuestion - build in the current session, or dispatch the stack seats? - then hold the answer for the run (an invocation that already names the mode is the answer); no dispatch (Cursor) or a scaffold too small to fan out is INLINE without asking. DELEGATED: for each vertical slice, dispatch that slice's stack seats directly from the main session - its designer, then implementer(s), then verifier (the domain-trio vertical - this skill's own references/domain-trio-protocol.md); before the first implementer fans out, write the approval gate file <docs-path>/flow/APPROVAL, first line APPROVED <plan id> - "<the user's words, verbatim>" on their explicit approval, or AUTO - "<their words, verbatim>" only on a literal no-stops ask (the dispatch hook blocks an unstamped implementer; delete it when the run completes). Write the stamp at the ABSOLUTE path $CLAUDE_PROJECT_DIR/<docs-path>/flow/APPROVAL with the Write tool - .claude/ is a protected path, so the first write in a session prompts; take the prompt's 'allow Claude to edit its own settings for this session' option and the rest of the run is free (no settings key can pre-approve it: permissions.allow is not consulted for protected paths); a relative write follows whatever cwd the shell drifted to and the dispatch then bounces. The stamp belongs to the session that dispatches - written when its own decision lands, deleted at its own close; an earlier session's leftover stamp is not consent. If BOTH the Write tool and an absolute-path Bash write are refused by the harness's classifier, stop and put the choice through AskUserQuestion (retry the stamp, or run this stage inline) rather than retrying blind or dispatching around the gate. Reds route to the matching resolver. A multi-stack slice runs producer-first with the recorded interface, per project-solve-cross-task. Loop until the spec's first milestone is met. INLINE (chosen or forced): do the slices in-session with writing-plans + the architecture skills instead of dispatching.
5. HANDOFF
First milestone green: suggest the captures - /project-architecture-analyzer and /project-code-style-analyzer - so the new repo gets its map, style doc, and generated awareness rules; from here on the standing flow machinery owns the project.
Per-stack scaffolding
Availability - each row's skills exist only where that stack was installed; match them from your skill list by what each covers, and a skill absent because the project is greenfield (an evidence-gated specialist arrives only once code shows the need) is designed around from the stack's hub skill and the vendor docs, never guessed by name.
| Stack | new-project command | Architecture + convention skills |
|---|---|---|
| Angular web | ng new | angular-conventions + angular-styling |
| Ionic/Capacitor mobile | ionic start + cap add | ionic + mobile |
| ASP.NET Core backend | dotnet new webapi/web | dotnet-architecture + dotnet-web-backend / dotnet-minimal-api |
| WPF desktop | dotnet new wpf | dotnet-wpf (strict MVVM) |
| SQL / data | first schema | database-conventions + dotnet-migrate |
Example
Brief: 'Start a new Angular admin dashboard.'
- DESIGN in-session: three options - standalone + signals with feature folders; NgRx-backed modular; minimal-shell MVP - each with routing, state tier, folder shape, and the tradeoff that decides it.
- THE PICK: the user chooses option one.
- SCAFFOLD:
ng new admin, structure perangular-conventions, wire lint/format config, a test setup, the core routing shell. - BUILD: first slice (the auth shell) - dispatch web-angular-solution-designer, then the angular implementer(s), then web-angular-verifier; loop the punch-list. Repeat per slice to the first milestone.
- HANDOFF: suggest the captures so the repo gets its map and style artifacts.
Rules
- Greenfield architecture and tech choices are the user's - present options, get the pick, never scaffold before it.
- Design from the house architecture skills, not recall - this skill routes to them, it does not re-derive structure. Version-sensitive choices check the library-docs MCP (context7 where the project kept it) or the vendor doc, never memory - an option resting on a claim no doc backs says
unverified. - The main session is the only orchestrator - never instruct a subagent to dispatch another; the domain seats this skill fans out carry no Agent tool.
- An honest NEEDS_CONTEXT beats a guessed design: a blocking spec question goes to the user before options are locked.