From an empty folder · purpose → stack decisions → context files · no code written
+
no code written at any pointquestions come as multiple choiceevery stack choice is yours
1
Create the folder and run git init, then start Claude Code in it.
2
Invoke the skill, optionally with a one-line idea. Without one, Claude asks what the project does, who uses it, and how they interact with it.
3
Make the stack decisions. For each area, Claude offers 2–3 options with one-line trade-offs and its recommendation listed first. Pick one, or type your own answer.
4
Confirm the summary. Every decision appears in one block, with the reason and the alternatives you rejected.
5
Review the generated files, then commit them: chore: add SDD context files.
Invoke
/sdd-startup a CLI that syncs my markdown notes to S3
Decision areas, in order
1 Language and runtime
2 Framework
3 Data layer
4 Async work / queues (only if needed)
5 Hosting and deployment
6 Testing (and the test command)
7 Hard constraints (open question)
Why the test command matters here: every task in a feature spec names a check that proves it works, and most checks are the project's test command run against the new tests. Settling on it now means every later task has a check it can run.
N·02
What gets generated
Three steering docs, a short CLAUDE.md, STATE.md, and a .gitignore entry
+
P
.claude/steering/product.md: purpose, users, interaction model, what success looks like
T
.claude/steering/tech.md: each stack decision with its reason and the alternatives rejected, plus the build, test and run commands
S
.claude/steering/structure.md: the planned folder layout. It's updated as features land.
C
CLAUDE.md (written last): stack, commands, conventions, NEVER list, and pointers to the steering docs. Under 60 lines.
S
STATE.md: feature status. It gets its first commit hash after your first commit.
G
.gitignore gets .claude/worktrees/, used later when features are built in parallel.
CLAUDE.md← written last# StackTypeScript · Node 22 · Fastify · Postgres · Fly.io# Commands- Test: npm test- Run: npm run dev# Conventions- Validate input with Zod at the route- Log with Pino, never console.log# NEVER- In-memory state between requests- Libraries not listed in tech.md# Project context (read when relevant)- .claude/steering/product.md: purpose and users- .claude/steering/tech.md: stack decisions- .claude/steering/structure.md: where code lives- specs/<feature>/ · STATE.md
Why pointers instead of @ imports? An @path import loads the whole file into every session, so splitting files that way saves nothing. The SDD skills read the steering docs when they need them, and CLAUDE.md stays small, which keeps its rules from getting lost.
N·03
Next: your first feature
Commit the context files, clear the conversation, and spec the first feature
+
01
Commit the context files: chore: add SDD context files
02
Run /clear so the stack discussion doesn't crowd out the feature. CLAUDE.md loads again automatically.
03
Spec the feature with /sdd-feature. The Workflow page covers the rest: spec → implement → validate.
Starting the first feature
/sdd-feature sync-commandpush changed notes to the bucket