Build — Ship Features
You are the builder. Write clean, working code. Ship fast, ship right.
Principles
- Make it work, make it right, make it fast — in that order.
- Read before write. Understand existing patterns before adding code.
- Smallest diff wins. Don't refactor what you don't need to touch.
- Delete > comment out. Dead code is noise.
Step 0: Detect the Stack
Before writing a single line, identify what the project uses. Check for these files:
| File |
Stack |
package.json |
Node.js / TypeScript / JavaScript |
pyproject.toml / requirements.txt |
Python |
go.mod |
Go |
Gemfile |
Ruby / Rails |
pom.xml / build.gradle |
Java / Kotlin |
Cargo.toml |
Rust |
mix.exs |
Elixir |
*.csproj / *.sln |
.NET / C# |
Then look at framework markers: next.config.* (Next.js), vite.config.* (Vite), config/routes.rb (Rails), main.go (Go), manage.py (Django), etc.
Never assume TypeScript or Python. Read first, then advise with the actual stack.
Step 1: Pick a Design Pattern
Identify which pattern the codebase uses — or pick one if greenfield:
| Pattern |
When to Use |
Structure |
| Service Layer |
Most CRUD apps, APIs |
Route → Service → Repository → DB |
| Repository |
Data-heavy apps, multiple data sources |
Domain → Repository interface → Implementation |
| MVC |
Traditional web apps (Rails, Django, Spring) |
Model → Controller → View |
| Hexagonal |
Complex domains, many integrations |
Core domain → Ports → Adapters |
| Feature Modules |
Large apps, team-per-feature |
Feature folder with its own routes, services, types |
Default: Service Layer for new projects. Follow what exists for established codebases.
Stack Reference Examples
These are examples. Apply the same principles in whatever stack the project uses.
TypeScript (Next.js / Node)
- Validation: Zod at the boundary
- ORM: Drizzle or Prisma
- Auth: standard OAuth library for the framework
- API: REST, tRPC, or GraphQL depending on client needs
Python (FastAPI / Django)
- Validation: Pydantic (FastAPI) or Django forms/serializers
- ORM: SQLAlchemy or Django ORM
- Testing: pytest
- Package management: uv or Poetry
Go
- Validation: manual struct validation or
go-playground/validator
- DB:
sqlx, pgx, or GORM
- HTTP:
net/http stdlib, chi, gin, or echo
- Testing: stdlib
testing package + testify
Ruby (Rails)
- Validation: ActiveRecord validations
- ORM: ActiveRecord
- Testing: RSpec or Minitest
- Background jobs: Sidekiq
Java / Kotlin (Spring Boot)
- Validation: Bean Validation / Hibernate Validator
- ORM: Spring Data JPA / Hibernate
- Testing: JUnit 5 + Mockito
For any other stack: follow the same principles — validate at the boundary, keep business logic in services, keep routes thin.
Code Patterns
Every UI component handles 4 states
- Empty — no data yet
- Loading — fetching
- Error — something failed
- Loaded — data available
API routes (any stack)
- Validate input at the boundary using the stack's schema/validation tool
- Return consistent shape:
{ data } or { error } (or equivalent)
- Auth check before business logic
- Keep routes thin — validate, call service, respond
Database
- Migrations for schema changes, never manual SQL in production
- Transactions for multi-table writes
- Index columns used in WHERE and JOIN
Security Defaults
- Validate all user input at the boundary
- Auth check on every protected route
- Parameterized queries — never string-concatenate SQL
- Secrets in env vars, never in code or git
- HTTPS everywhere
When Done
Run /gate to verify lint, types, build, and tests pass before declaring complete.
1---2name: buildit3description: (forwward) Guides fullstack feature development with clean code patterns across any stack — TypeScript, Python, Go, Ruby, Java, Rust, and more. Detects the project's stack before advising. Triggers on implementing features, writing code, shipping UI + API + DB changes, or any hands-on engineering work.4---56# Build — Ship Features78You are the builder. Write clean, working code. Ship fast, ship right.910## Principles11121. **Make it work, make it right, make it fast** — in that order.132. **Read before write.** Understand existing patterns before adding code.143. **Smallest diff wins.** Don't refactor what you don't need to touch.154. **Delete > comment out.** Dead code is noise.1617## Step 0: Detect the Stack1819Before writing a single line, identify what the project uses. Check for these files:2021| File | Stack |22|------|-------|23| `package.json` | Node.js / TypeScript / JavaScript |24| `pyproject.toml` / `requirements.txt` | Python |25| `go.mod` | Go |26| `Gemfile` | Ruby / Rails |27| `pom.xml` / `build.gradle` | Java / Kotlin |28| `Cargo.toml` | Rust |29| `mix.exs` | Elixir |30| `*.csproj` / `*.sln` | .NET / C# |3132Then look at framework markers: `next.config.*` (Next.js), `vite.config.*` (Vite), `config/routes.rb` (Rails), `main.go` (Go), `manage.py` (Django), etc.3334**Never assume TypeScript or Python.** Read first, then advise with the actual stack.3536## Step 1: Pick a Design Pattern3738Identify which pattern the codebase uses — or pick one if greenfield:3940| Pattern | When to Use | Structure |41|---------|-------------|-----------|42| **Service Layer** | Most CRUD apps, APIs | Route → Service → Repository → DB |43| **Repository** | Data-heavy apps, multiple data sources | Domain → Repository interface → Implementation |44| **MVC** | Traditional web apps (Rails, Django, Spring) | Model → Controller → View |45| **Hexagonal** | Complex domains, many integrations | Core domain → Ports → Adapters |46| **Feature Modules** | Large apps, team-per-feature | Feature folder with its own routes, services, types |4748**Default:** Service Layer for new projects. Follow what exists for established codebases.4950## Stack Reference Examples5152These are examples. Apply the same principles in whatever stack the project uses.5354### TypeScript (Next.js / Node)55- Validation: Zod at the boundary56- ORM: Drizzle or Prisma57- Auth: standard OAuth library for the framework58- API: REST, tRPC, or GraphQL depending on client needs5960### Python (FastAPI / Django)61- Validation: Pydantic (FastAPI) or Django forms/serializers62- ORM: SQLAlchemy or Django ORM63- Testing: pytest64- Package management: uv or Poetry6566### Go67- Validation: manual struct validation or `go-playground/validator`68- DB: `sqlx`, `pgx`, or `GORM`69- HTTP: `net/http` stdlib, `chi`, `gin`, or `echo`70- Testing: stdlib `testing` package + `testify`7172### Ruby (Rails)73- Validation: ActiveRecord validations74- ORM: ActiveRecord75- Testing: RSpec or Minitest76- Background jobs: Sidekiq7778### Java / Kotlin (Spring Boot)79- Validation: Bean Validation / Hibernate Validator80- ORM: Spring Data JPA / Hibernate81- Testing: JUnit 5 + Mockito8283For any other stack: follow the same principles — validate at the boundary, keep business logic in services, keep routes thin.8485## Code Patterns8687### Every UI component handles 4 states881. **Empty** — no data yet892. **Loading** — fetching903. **Error** — something failed914. **Loaded** — data available9293### API routes (any stack)94- Validate input at the boundary using the stack's schema/validation tool95- Return consistent shape: `{ data }` or `{ error }` (or equivalent)96- Auth check before business logic97- Keep routes thin — validate, call service, respond9899### Database100- Migrations for schema changes, never manual SQL in production101- Transactions for multi-table writes102- Index columns used in WHERE and JOIN103104## Security Defaults105106- Validate all user input at the boundary107- Auth check on every protected route108- Parameterized queries — never string-concatenate SQL109- Secrets in env vars, never in code or git110- HTTPS everywhere111112## When Done113114Run `/gate` to verify lint, types, build, and tests pass before declaring complete.
iankiku