# Sw Use Case Coder

> Use when user wants to generate code for a use case or user story, says "code UC-01", "implement US-03", "generate all MVP", "scaffold UC-05 UC-07", or wants production-ready files from use-cases.md and tech-stack.yaml written directly into the project root.

- Skill: `chfle/sw-use-case-coder` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds@latest add chfle/sw-use-case-coder`
- Raw SKILL.md: https://api.skillmd.com/api/skills/chfle/sw-use-case-coder/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: chfle (https://skillmd.com/u/chfle)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/chfle/sw-use-case-coder

---


# SW Use Case Coder

## Overview

Reads `requirements/tech-stack.yaml` and `requirements/use-cases.md`, then writes or updates production-ready code **directly into the workspace root** using real project paths. Works for any language and framework. Iterative – calling it again for the same ID refines and improves existing code. Completely silent except for the three final lines.

**Language detection:** Read the user's input language and respond entirely in that language. Default to German if undetectable.

---

## Safety: Working Directory

Before creating or editing any file, verify the current working directory is the workspace **root** (the directory containing `package.json`, `pom.xml`, `src/`, `app/`, etc.).

If the working directory is inside `requirements/` or any subdirectory, immediately navigate to the workspace root before proceeding. Never write files relative to `requirements/`.

---

## Required Input – Check in Order

### 0. Boilerplate check (first, always)

Check the workspace root for at least one of:
`package.json`, `pom.xml`, `build.gradle`, `build.gradle.kts`, `Makefile`, `pyproject.toml`, `Cargo.toml`, `go.mod`, `composer.json`

If NONE exist → stop immediately, output exactly:

```
❌ No project boilerplate found in root.
Please run /sw-boilerplate first to create the full project structure.
Then try this command again.
```

### 1. Requirements check

- `requirements/tech-stack.yaml` missing → stop:
  > `requirements/tech-stack.yaml` not found. Run `/sw-tech-stack-planner` first.

- `requirements/use-cases.md` missing → stop:
  > `requirements/use-cases.md` not found. Run `/sw-use-case-creator` first.

- Also read `requirements/user-stories.md` as optional context if it exists.

---

## Use Case Selection

Accept **any ID exactly as the user typed it** – never normalize, pad, or change it.

| Input example | Meaning |
|---------------|---------|
| `UC-01`, `UC-1`, `UC-001` | Single use case by exact ID |
| `US-03`, `US-11` | Single user story by exact ID |
| `UC-01 UC-04`, `US-01 US-03` | Multiple items, space-separated |
| `all MVP` | Every item tagged MVP or `[MVP]` |
| `all Nice-to-have` | Every item tagged Nice-to-have |
| `all` | Every item in the source files |
| *(no argument)* | Ask: "Which items should I implement? (e.g. UC-01, US-03, all MVP, all)" |

Look up each ID in both `requirements/use-cases.md` and `requirements/user-stories.md`.

---

## Code Generation Rules

Read `requirements/tech-stack.yaml` fully. Adapt every file to the detected language, framework, ORM, and test tooling. Never generate files for frameworks not in the stack.

### Monorepo vs Single-App Paths

Before generating any file path, read `project.structure` from `requirements/tech-stack.yaml`:

| Value | Path prefix rule |
|-------|-----------------|
| `single-app` (or field absent) | Use paths as-is from the table below |
| `monorepo` | Prefix frontend files with `apps/web/`, backend files with `apps/api/` |

Example — Next.js in monorepo: `app/devices/page.tsx` → `apps/web/app/devices/page.tsx`
Example — NestJS in monorepo: `src/devices/devices.service.ts` → `apps/api/src/devices/devices.service.ts`

### Generic path conventions

| Stack | Real paths to write |
|-------|---------------------|
| Next.js App Router | `app/(feature)/page.tsx`, `app/(feature)/<Feature>Form.tsx`, `app/(feature)/actions.ts`, `lib/types/<feature>.ts`, `components/<Feature>.tsx` |
| Next.js Pages Router | `pages/<feature>/index.tsx`, `components/<Feature>Form.tsx`, `lib/<feature>.ts` |
| NestJS | `src/<feature>/<feature>.controller.ts`, `src/<feature>/<feature>.service.ts`, `src/<feature>/<feature>.module.ts`, `src/<feature>/dto/create-<feature>.dto.ts` |
| Spring Boot | `src/main/java/<pkg>/<feature>/<Feature>Controller.java`, `<Feature>Service.java`, `<Feature>Repository.java`, `<Feature>Dto.java` |
| FastAPI | `routers/<feature>.py`, `schemas/<feature>.py`, `services/<feature>.py` |
| Go | `internal/handler/<feature>.go`, `internal/service/<feature>.go`, `internal/repository/<feature>.go` |
| Rust (Axum) | `src/handlers/<feature>.rs`, `src/models/<feature>.rs`, `src/routes.rs` (update) |
| Prisma | Append model to `prisma/schema.prisma` |
| Flyway | `src/main/resources/db/migration/V<n>__add_<feature>.sql` |
| SQLAlchemy | `models/<feature>.py`, `alembic/versions/<n>_add_<feature>.py` |
| GORM | `internal/models/<feature>.go` |

### Quality rules

- Use exact language from `frontend.language` / `backend.language` in tech-stack.yaml
- Use `ui_library` value (shadcn/ui, Tailwind, MUI) for component styling
- Add `'use client'` in Next.js only when component uses state, effects, or event handlers
- DTOs and schemas contain the exact fields from the use case main flow
- **No hardcoded secrets** — use the environment variable pattern for the detected language:

| Language | Pattern |
|----------|---------|
| TypeScript / JS | `process.env.VAR_NAME` |
| Python | `os.environ["VAR_NAME"]` or `os.getenv("VAR_NAME")` |
| Java (Spring) | `@Value("${VAR_NAME}")` |
| Go | `os.Getenv("VAR_NAME")` |
| Rust | `std::env::var("VAR_NAME").expect("VAR_NAME not set")` |
| PHP | `$_ENV["VAR_NAME"]` |

- **Import conventions per framework**: `@/` alias for Next.js; relative imports within module for NestJS; absolute package path from `go.mod` for Go; standard Java package imports for Spring; absolute from project root for FastAPI

- **ORM model table naming** — use the convention for the detected ORM:

| ORM | Table mapping |
|-----|--------------|
| Prisma | `@@map("table_name")` + all required `@relation` fields |
| SQLAlchemy | `__tablename__ = "table_name"` |
| GORM | Model name auto-maps to snake_case plural; use `gorm:"column:col_name"` for custom field names |
| Spring JPA / Hibernate | `@Table(name = "table_name")` on entity class |
| TypeORM | `@Entity("table_name")` on entity class |
| Eloquent (Laravel) | `protected $table = "table_name"` |

- **Acceptance criteria** from use-cases.md become TODO comments in E2E test files using the language-appropriate comment syntax (`// TODO: AC-X:` for C-family languages, `# TODO: AC-X:` for Python/Ruby/Shell); for unit/integration tests use them to guide mock setup and assertions — do not repeat them as literal comments
- **Iterative**: if a file already exists, edit and improve it — add or enhance functions rather than replacing the entire file. For test files, always regenerate with all acceptance criteria covered. Never delete existing working logic.
- **Migrations are additive** — each use case appends only new migration files; never modify or delete existing ones. If a conflict is detected, stop and report it.

| ORM | New migration pattern | Post-write command to show user |
|-----|----------------------|---------------------------------|
| Prisma | Append model to `prisma/schema.prisma` | `npx prisma migrate dev --name add_<feature>` |
| Flyway | New `V<n+1>__add_<feature>.sql` in `src/main/resources/db/migration/` | Applied automatically on startup |
| Alembic | New `alembic/versions/<n>_add_<feature>.py` | `alembic upgrade head` |
| GORM | Add struct to `internal/models/`; register in AutoMigrate call | `db.AutoMigrate(&Feature{})` |
| TypeORM | Generate via `typeorm migration:generate` | `typeorm migration:run` |
| Liquibase | New changeset in `db/changelog/` | Applied automatically on startup |

### Tests to generate

| Type | Condition | Generate when |
|------|-----------|---------------|
| Unit | Always | For every use case |
| Integration (Testcontainers) | `testcontainers: true` in tech-stack.yaml | DB-level integration tests |
| E2E | `e2e` key present | Full flow from UI to DB |
| API / Contract | `api` key present | HTTP endpoint tests |

**Test path by language** — use the convention for the detected backend/frontend language:

| Language / Framework | Unit test | Integration test | E2E test |
|----------------------|-----------|-----------------|---------|
| TypeScript (Jest/Vitest) | `src/<f>/<f>.service.spec.ts` | `src/<f>/<f>.integration.spec.ts` | `e2e/<f>.spec.ts` |
| Python (pytest) | `tests/unit/test_<f>.py` | `tests/integration/test_<f>.py` | `tests/e2e/test_<f>.py` |
| Java (JUnit 5) | `src/test/java/<pkg>/<F>Test.java` | `src/test/java/<pkg>/<F>IT.java` | `src/test/java/<pkg>/<F>E2ETest.java` |
| Go (testing) | `internal/<f>/<f>_test.go` (same package) | `tests/<f>_integration_test.go` | `tests/<f>_e2e_test.go` |
| Rust (cargo test) | Inline `#[cfg(test)]` in `src/<f>.rs` | `tests/<f>_integration.rs` | `tests/<f>_e2e.rs` |
| PHP (PHPUnit) | `tests/Unit/<F>Test.php` | `tests/Feature/<F>Test.php` | `tests/Feature/<F>E2ETest.php` |

Apply the same monorepo prefix to all test paths: `apps/api/src/<feature>/...` for backend tests, `apps/web/...` for frontend tests.

---

## Output Rules (absolute)

- **Never output any code, file content, directory tree, file list, or folder names in the chat.**
- No explanations, no brainstorming, no "I created folder X", no Markdown code blocks.
- Do not create any use-case-specific staging folder (`requirements/code/`, `uc-01-.../`, `generated-/`, etc.).
- All changes go directly into the existing project structure.
- If an error occurs, output only the error message – no partial code.

---

## Final Output

After all files are written, print **exactly three lines** – nothing else.

Single item:
```
✅ [exact user input] implemented in root (X files updated/created)
To test: <dynamic command>
💡 Tip: Run git add . && git commit -m "feat: implement [exact user input]" to allow easy reset on mistakes.
```

Multiple items:
```
✅ [exact user input 1] implemented in root (X files)
✅ [exact user input 2] implemented in root (X files)
To test: <dynamic command>
💡 Tip: Run git add . && git commit -m "feat: implement [exact user input 1] [exact user input 2]" to allow easy reset on mistakes.
```

Batch (`all MVP`, `all`, etc.):
```
✅ all MVP implemented in root (X files updated/created)
To test: <dynamic command>
💡 Tip: Run git add . && git commit -m "feat: implement all MVP" to allow easy reset on mistakes.
```

Dynamic command from tech-stack.yaml:

| Stack / package manager | Command |
|------------------------|---------|
| Next.js + pnpm | `pnpm install && pnpm dev` |
| Next.js + npm | `npm install && npm run dev` |
| Next.js + yarn | `yarn && yarn dev` |
| NestJS + pnpm | `pnpm install && pnpm start:dev` |
| NestJS + npm | `npm install && npm run start:dev` |
| Spring Boot + Maven | `./mvnw spring-boot:run` |
| Spring Boot + Gradle | `./gradlew bootRun` |
| FastAPI | `uvicorn main:app --reload` |
| Go | `go run ./cmd/...` |
| Rust | `cargo run` |
| Docker-first (docker.services non-empty) | `docker compose up` |

When `docker.services` is non-empty, always prefer `docker compose up`.

---

## Example Usage

```
User: /sw-use-case-coder US-01

Skill: (silent)
  → reads requirements/tech-stack.yaml  (Next.js + Prisma + pnpm)
  → reads requirements/user-stories.md  (US-01: Register Device)
  → writes app/devices/new/page.tsx
  → writes app/devices/new/RegisterDeviceForm.tsx
  → writes app/devices/actions.ts
  → appends model Device to prisma/schema.prisma
  → writes src/devices/devices.service.spec.ts
  → writes lib/types/device.ts
  → writes e2e/register-device.spec.ts

Final output:
✅ US-01 implemented in root (7 files updated/created)
To test: pnpm install && pnpm dev
💡 Tip: Run git add . && git commit -m "feat: implement US-01" to allow easy reset on mistakes.
```

---

## Next Skill

After code generation, test and commit your work:

> ▶ **Next steps:**
> - Commit: `git add . && git commit -m "feat: implement [use-case IDs]"`
> - Run the test suite to verify: `pnpm test` / `./mvnw test` / `pytest` (based on your stack)
> - Run `/sw-use-case-coder` again with the next use case to continue building out the application