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.

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:

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

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:

• 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:

• 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.

Tests to generate

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

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:

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