Tworzenie Nowych Projektów z Terminala

Inicjalizacja projektu w Claude Code to pętla czterech ruchów: konkretny prompt opisujący stack, przebieg generujący katalogi, narzędzia i konfigurację, weryfikacja dowodząca, że szkielet naprawdę startuje, i jedna korekta kursu. Wygenerowany CLAUDE.md przenosi konwencje do każdej kolejnej sesji, a /init stosuje ten sam przepływ do bazy kodu, która już istnieje.

Poniedziałek rano, właśnie zapaliło się zielone światło. Product manager opisał usługę jednym zdaniem — “REST API do preferencji użytkownika, PostgreSQL, uwierzytelnianie, rate limiting, logi strukturalne” — a tradycyjna odpowiedź to cały dzień klejenia boilerplate’u, zanim powstanie pierwsza linia logiki biznesowej. Struktura projektu, konfiguracja lintera, połączenie z bazą, zmienne środowiskowe, pipeline CI: nic z tego nie jest produktem.

Claude Code ściska ten dzień do jednej sesji w terminalu. Sztuka nie polega na samym generowaniu — drzewo katalogów wypluje każde narzędzie. Sztuka polega na poprowadzeniu pierwszego promptu tak, żeby wyszedł szkielet produkcyjny, a nie generyczny szablon, i na utrzymaniu ciasnej pętli buduj-zweryfikuj-koryguj, która łapie luki, póki są jeszcze małe.

Co daje dziesięciominutowy bootstrap

Powtarzalną pętlę bootstrapowania dowolnego projektu z CLI: opisz, zbuduj szkielet, zweryfikuj, koryguj kurs
Zwięzły CLAUDE.md, który działa jak trwała pamięć projektu, zamiast zostać zignorowanym przy trzeciej sesji
Prompty copy-paste do Next.js, FastAPI, Phoenix i Express z Drizzle
Przepływ /init, który zamienia nieznaną, istniejącą bazę kodu w skonfigurowaną sesję
Fazową migrację na TypeScript, która nie psuje deployu, i tryb prototypowania na wypadek, gdy wąskim gardłem są pytania o uprawnienia

Od pustego katalogu do usługi, która działa

Bootstrap, który się sprawdza, to nie “wpisz jedno życzenie i odejdź od klawiatury”. To cztery ruchy: opisz konkretnie, pozwól Claude zbudować szkielet, każ mu udowodnić, że szkielet startuje, a potem popraw jedną realną lukę.

Stwórz katalog projektu i uruchom Claude Code
Okno terminala
```
mkdir my-saas-app && cd my-saas-app
git init
claude
```
Rozpoczęcie od git init ma znaczenie. Claude Code zna git i tworzy commity w logicznych punktach kontrolnych całego scaffoldingu. Bez repozytorium tracisz możliwość cofnięcia się, kiedy któryś krok pójdzie bokiem.

Opisz projekt na tyle szczegółowo, żeby uniknąć generycznego outputu

Mgliste “stwórz aplikację webową” daje generyczny szablon. Konkretny prompt daje coś, na czym da się budować. Podaj stack, główne funkcje i swoje konwencje.

Prompt copy-paste do scaffoldingu projektu full-stack:

Bootstrap a Next.js 16 app with the App Router, TypeScript strict mode,
Tailwind CSS, and Prisma with PostgreSQL. Set up:

- src/app directory structure with a landing page and auth routes
- Prisma schema with User and Session models
- Environment variables in .env.example (never .env)
- ESLint with the next/core-web-vitals config
- A docker-compose.yml for local PostgreSQL
- Basic middleware for auth route protection

Use server components by default. Client components only where needed.
No barrel exports. Prefer named exports over default exports.

Każ Claude udowodnić, że szkielet startuje, zanim na nim zbudujesz

To ten krok odróżnia prawdziwy przepływ pracy od folderu reklamowego, i to jego większość ludzi pomija. Nie ufaj wypisanemu drzewu katalogów — uruchom je.
```
Start Postgres with docker compose, run the migrations, then start the
dev server and confirm /health returns 200. Run the linter and the test
suite. Paste any errors and fix them until everything is green.
```
Claude jest najlepszy wtedy, gdy ma przed sobą prawdziwy błąd. Kiedy wersje zależności wchodzą w konflikt albo migracja się wywala, to właśnie faktyczny stderr pozwala mu poprawić kurs precyzyjnie, zamiast zgadywać.

Popraw jedną realną lukę

Wygenerowane szkielety prawie zawsze pomijają coś specyficznego dla twojego sposobu pracy. Nazwij to wprost, zamiast opisywać cały projekt od nowa:

The CRUD handlers call Prisma directly. Extract a preferences service
layer between the routes and the DB so business logic is testable in
isolation, and move the Zod schemas into src/schemas/.

Wygeneruj plik CLAUDE.md

Ten krok zwraca się przy każdej kolejnej sesji, bo to jego Claude czyta, zanim przeczyta cokolwiek innego.
```
/init
```
Komenda /init analizuje strukturę projektu, wykrywa frameworki i narzędzia i generuje startowy CLAUDE.md. Przejrzyj go i dopisz to, czego Claude nie wywnioskuje z samego kodu.

Po kilku minutach masz bazę kodu, którą faktycznie uruchomiłeś: warstwę serwisową, zwalidowane trasy, migracje, które przeszły, zielony zestaw testów i Dockera, którego widziałeś startującego — a nie drzewo katalogów, co do którego masz nadzieję, że się skompiluje.

Pisanie CLAUDE.md, którego Claude faktycznie słucha

/init daje dobry punkt startowy, ale najlepsze pliki CLAUDE.md są bezlitośnie przycinane i dopracowywane w czasie. Oto co uwzględnić, a co pominąć.

Co należy do CLAUDE.md

# Build and test commands
npm run dev              # Start dev server on port 3000
npm run build            # Production build
npm run test             # Run vitest
npm run lint             # ESLint check
npm run db:migrate       # Run Prisma migrations
npm run db:seed          # Seed development data

# Code conventions
- Use server components by default, client components only for interactivity
- Named exports only, no default exports except page.tsx and layout.tsx
- Colocate tests next to source files: Button.tsx / Button.test.tsx
- Use Zod for all runtime validation, never trust client input
- Service layer between routes and DB; routes stay thin

# Architecture decisions
- Auth: NextAuth.js with database sessions (not JWT)
- State: Server state via React Server Components, client state via Zustand only where needed
- API: Server Actions for mutations, Route Handlers only for webhooks

# Common gotchas
- Prisma client must be instantiated as singleton (see src/lib/db.ts)
- Middleware runs on Edge Runtime -- no Node.js APIs available
- Migrations are append-only; use the generator, never hand-edit
- IMPORTANT: Never commit .env files. Use .env.example for templates.

Czego nie wpisywać do CLAUDE.md

Nie wpisuj rzeczy, które Claude wyczyta z kodu: standardowych konwencji TypeScriptu, działania hooków Reacta ani tego, co robi npm install. Nie wpisuj dokumentacji, która często się zmienia — podlinkuj ją.

Prompty startowe do stacków, od których najczęściej zaczynasz

Każdy z nich ma ten sam kształt co prompt Next.js powyżej — stack, układ katalogów, konwencje i pierwszy zasób do zbudowania — tylko ze zmienionymi szczegółami.

Python FastAPI

Prompt copy-paste do projektu FastAPI:

Create a FastAPI project with Python 3.12 and these conventions:

- src/ layout with separate routers, models, schemas, and services directories
- SQLAlchemy 2.0 with async sessions and Alembic migrations
- Pydantic v2 for request/response schemas
- Poetry for dependency management with a pyproject.toml
- pytest with async fixtures and httpx for API tests
- A Dockerfile with multi-stage build (builder + runtime)
- Pre-commit hooks for ruff formatting and type checking with mypy

Start with a health check endpoint and a basic CRUD resource for "projects"
with GET list, GET detail, POST create, and PATCH update.

Phoenix LiveView

Prompt copy-paste do projektu Phoenix:

Initialize a Phoenix 1.8 project with LiveView, Tailwind CSS, and
PostgreSQL. Set up:

- mix phx.new with --live flag
- Ecto schemas for User and Organization with a many-to-many relationship
- LiveView for a dashboard page with real-time updates
- ExUnit tests for the context modules
- A .formatter.exs configured for the project
- Docker Compose for PostgreSQL

Use contexts for business logic (Accounts context for User/Org).
Keep LiveView modules thin -- delegate to contexts for data operations.

Express z TypeScriptem i Drizzle

To prompt do usługi preferencji użytkownika z początku artykułu. Idzie dalej niż wersja dla Next.js w dwóch miejscach: nazywa wprost middleware uwierzytelniania, rate limitingu i logowania oraz zamawia workflow CI w tym samym przebiegu, więc repozytorium przychodzi z zielonym pipeline’em zamiast z takim, który dokręcasz później.

Prompt copy-paste do produkcyjnego szkieletu API w Node:

Scaffold a Node.js Express API in TypeScript strict mode for user
preferences. Use:

- src/ with routes/, middleware/, services/, db/, and lib/ directories
- Drizzle ORM against PostgreSQL, with a migrations/ folder
- Zod for request validation middleware
- JWT auth middleware (access + refresh), reading secrets from env only
- express-rate-limit at 100 req/min per IP
- pino for structured JSON logging with request IDs
- Vitest with a separate test database config
- A multi-stage Dockerfile running as a non-root user
- docker-compose.yml for local PostgreSQL 17
- GitHub Actions CI that runs lint, type-check, and tests

Include a /health route and full CRUD for a "preferences" resource with
error-handling middleware. Async/await everywhere, no callbacks. Put env
templates in .env.example and never create a real .env.

Konfiguracja, która odmawia startu przy złej wartości

Szkielet, który wypluł pliki konfiguracyjne, nie jest gotowy. Chcesz konfiguracji, która krzyczy przy złej wartości — i chcesz zobaczyć, jak krzyczy. Poproś o konfigurację świadomą środowiska z walidacją przy starcie, a potem przetestuj tę walidację, podając jej coś zepsutego.

Prompt copy-paste do zwalidowanej konfiguracji świadomej środowiska:

Add environment-aware config (development/staging/production) loaded by
NODE_ENV, with a single typed config object. Validate it at startup with
Zod: PORT is a valid port, DATABASE_URL is a URL, JWT_SECRET is >= 32
chars. On a missing or invalid value, throw with the offending key named.

Then prove it: start the app with JWT_SECRET unset and show me that it
refuses to boot with a clear error, then set it and show a clean start.

Cała rzecz tkwi w drugiej połowie, w “then prove it”. Walidacja konfiguracji, której nigdy nie widziałeś w akcji, to walidacja, której w praktyce nie masz.

Uruchamianie `/init` w bazie kodu, do której właśnie dołączyłeś

Nie każdy projekt zaczyna się od zera. Kiedy dołączasz do istniejącej bazy kodu, /init staje się narzędziem onboardingu.

Wejdź do katalogu głównego projektu i uruchom Claude Code
Okno terminala
```
cd /path/to/existing-project
claude
```
Wygeneruj CLAUDE.md z istniejącej bazy kodu
```
/init
```
Claude czyta package.json (albo jego odpowiednik), ogląda strukturę katalogów, wykrywa frameworki testowe i generuje CLAUDE.md dopasowany do projektu.

Poproś Claude o uzupełnienie tego, co /init pominął

Read through the README, the CI configuration, and the last 20 commits.
Update CLAUDE.md with any conventions, gotchas, or workflow patterns
you can identify that aren't already captured.

Zweryfikuj pytaniem, na które odpowie tylko dobrze skonfigurowana sesja
```
How do I run just the unit tests for the auth module?
What is the deployment process?
```
Jeśli Claude odpowie poprawnie z samego CLAUDE.md, bez doczytywania kolejnych plików, konfiguracja działa.

Migracja starej aplikacji zamiast budowania nowej od zera

Czasem projekt, który inicjalizujesz, już istnieje, a prawdziwym zadaniem jest przeniesienie go na nowoczesny toolchain — stara aplikacja Express, która potrzebuje TypeScriptu bez ryzykownego przepisania na raz. Pętla jest ta sama, opisz-wygeneruj-zweryfikuj, tyle że stosowana po jednej fazie, żeby aplikacja pozostała wdrażalna na każdym etapie.

Poproś o plan fazowy, nie o diff

Analyze this Express app and propose a phased migration to TypeScript
strict that keeps the service deployable after each phase. Start with
tsconfig + build wiring and the leaf modules with no internal imports.

Wykonaj pierwszą fazę i potwierdź, że build nadal przechodzi

Implement phase 1: add the TypeScript config and convert the leaf
modules. Then run the build and the existing test suite and confirm
both pass before we touch anything else.

Iteruj, weryfikując każdą fazę

Tests pass. Convert the next layer (the route handlers), add types for
the external deps they use, and run the suite again. Stop if anything
breaks.

Dyscyplina siedzi w kroku weryfikacji między fazami. Pominięcie go to dokładnie ten sposób, w jaki “stopniowa” migracja po cichu zbiera sto błędów typów, które odkrywasz naraz.

Prototypowanie, gdy wąskim gardłem są pytania o uprawnienia

Hackathon rządzi się innymi prawami. Pomysł trzeba zwalidować w kilka godzin, a to prośba o zgodę przy każdym zapisie pliku cię spowalnia. W Claude Code nie ma żadnego “trybu YOLO” — prawdziwym mechanizmem jest flaga --dangerously-skip-permissions (albo tryb uprawnień bypassPermissions), która wyłącza pytania o zgodę na czas sesji.

claude --dangerously-skip-permissions

Potem podaj mu prompt z wyraźnie ograniczonym zakresem:

Prompt copy-paste do prototypu na wyrzucenie:

Build a minimal real-time collaborative whiteboard: Next.js 16 + Socket.io
+ the Canvas API, deployable to Vercel. In-memory state is fine, no auth,
no database. Core only: draw, see other cursors, clear board. Get it
running on the dev server and tell me the URL.

Hooki, które egzekwują to, co CLAUDE.md tylko sugeruje

Hooki to skrypty uruchamiane automatycznie w konkretnych punktach przepływu pracy Claude. Instrukcje z CLAUDE.md są doradcze, hooki wykonują się deterministycznie za każdym razem.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx eslint --fix"
          }
        ]
      }
    ]
  }
}

Ten hook uruchamia ESLint z auto-fixem po każdej edycji pliku przez Claude. Koniec z wyłapywaniem w review problemów stylistycznych, które powinny zniknąć automatycznie.

Kształt ma tu znaczenie. Wpis z matcherem opakowuje wewnętrzną tablicę hooks z obiektami { type: "command", command: ... } — nie ma czegoś takiego jak gołe pole command na najwyższym poziomie. Hooki nie dostają też zmiennej $FILE_PATH: Claude Code podaje zdarzenie jako JSON na stdin, więc ścieżkę edytowanego pliku wyciągasz przez jq -r '.tool_input.file_path' i przekazujesz dalej przez xargs. Pomiń jq, a ESLint dostanie pusty argument i po cichu nie zrobi nic.

Prompt copy-paste do konfiguracji hooków projektu:

Create hooks in .claude/settings.json that:
1. Run ESLint --fix after every file edit (PostToolUse on Edit/Write).
   Extract the edited file path from stdin with jq '.tool_input.file_path'
   and pass it to eslint -- there is no $FILE_PATH variable.
2. Run TypeScript type-check after editing .ts or .tsx files.
3. Block writes to the migrations/ directory (PreToolUse on Write)
   by having the script exit with code 2 and print a message saying
   "Use the migration generator instead".

Use the matcher -> hooks: [{ type: "command", command }] structure
throughout, not a bare top-level command key.

Rozszerzanie konfiguracji przez skille i serwery MCP

Dwa mechanizmy rozszerzeń realnie skracają setup i rozwiązują różne problemy: skill to przepis wielokrotnego użytku, serwer MCP to żywe połączenie z systemem.

Skill, który buduje funkcje po waszemu

Kiedy projekt już stoi, zakoduj zespołowy przepływ pracy jako skill, który każdy może wywołać.

---
name: new-feature
description: Scaffold a new feature with all required files
---
Create a new feature: $ARGUMENTS

1. Create a new branch named feature/$ARGUMENTS
2. Add route handler in src/app/api/$ARGUMENTS/route.ts
3. Add service in src/services/$ARGUMENTS.service.ts
4. Add Zod schemas in src/schemas/$ARGUMENTS.schema.ts
5. Add tests in src/services/$ARGUMENTS.service.test.ts
6. Update CLAUDE.md if new conventions are introduced

Wywołujesz go przez /new-feature user-preferences, a Claude buduje całą strukturę funkcji zgodnie z konwencjami zespołu. Po gotowe rzeczy, które napisał ktoś inny, zajrzyj na skills.sh i instaluj uniwersalnym CLI — npx skills add <owner/repo> — działającym w Claude Code, Cursorze i Codeksie.

Serwery MCP, które kończą zgadywanie

Po serwer MCP sięgaj wtedy, gdy chcesz żywego, stanowego połączenia z narzędziem, a nie jednorazowego przepisu.

Serwer MCP do Postgresa pozwala Claude odpytać żywy schemat, zamiast zgadywać nazwy kolumn przy pisaniu migracji i zapytań:
Okno terminala
```
claude mcp add --transport stdio postgres -- npx -y @modelcontextprotocol/server-postgres "$DATABASE_URL"
```
Serwer MCP do GitHuba (@modelcontextprotocol/server-github) pozwala tej samej sesji założyć repozytorium, wypchnąć szkielet i otworzyć pierwszy PR bez wychodzenia z terminala.

Gdy scaffolding projektu zawodzi

Claude generuje generyczny szablon zamiast tego, co opisałeś. Prompt był zbyt ogólny. Dopisz konkretne wersje frameworków, dokładny układ katalogów i swoje konwencje. Szczegółowość, którą dokładasz na wejściu, to korekty kursu, których unikasz później.

Wygenerowany projekt ma konflikty zależności. Claude czasem wciąga niekompatybilne wersje pakietów. Właśnie dlatego krok weryfikacji jest nienegocjowalny — “uruchom serwer deweloperski i napraw błędy” stawia przed Claude prawdziwy stderr, a konflikty rozwiązuje dobrze, kiedy widzi faktyczną awarię.

Szkielet odpływa od promptu w długiej sesji. Gdy kontekst się zapełnia, Claude potrafi zapomnieć wczesną instrukcję w rodzaju “tylko named exports”. Przenieś regułę do CLAUDE.md, żeby przetrwała, zamiast powtarzać ją w czacie za każdym razem.

CLAUDE.md jest ignorowany w kolejnych sesjach. Plik jest za długi albo zbyt ogólnikowy. Zejdź poniżej mniej więcej 50 linii i spraw, żeby każda linia była konkretna i wykonalna. “Pisz czysty kod” nie zarabia na siebie; “Warstwa serwisowa między trasami a bazą, trasy zostają cienkie” — zarabia.

/init pomija konwencje projektu. Komenda analizuje strukturę kodu, ale nie przeczyta niepisanych zasad zespołu. Zawsze uzupełniaj jej wynik o rzeczy, które żyją wyłącznie w głowach: nazewnictwo gałęzi, proces PR, procedury wdrożeniowe. Potem zweryfikuj to pytaniem, na które odpowie tylko dobrze skonfigurowany CLAUDE.md.

Dokąd dalej, gdy projekt już działa

Projekt ma szkielet, CLAUDE.md jest skonfigurowany, hooki stoją, a serwer deweloperski widziałeś na własne oczy. Następny krok to poruszanie się po kodzie, którego nie napisałeś.

Analiza bazy kodu Użyj Claude Code do zrozumienia dużych, nieznanych baz kodu przez systematyczną eksplorację

Planowanie funkcji Zamień wymagania w szczegółowe plany wdrożenia dzięki Plan Mode i rozszerzonemu myśleniu

Rozwój API Buduj solidne API na gotowym szkielecie, z Claude Code prowadzącym endpointy i testy