Back to Guide
BUILDING

Scaffold Backend

PRD-driven FastAPI scaffold into server/ with optional Supabase. One stub route per entry in PRD.md > Backend Routes. Skips automatically if Backend Needed? = No.

Slash Command

Type this directly in Cursor or Claude Code chat

/scaffold-backend

Install This Skill

Copy this prompt and paste it into Cursor (Ctrl+I) or Claude Code. The AI will handle the installation.

Install the Scaffold Backend skill from this GitHub repo: https://github.com/IdkwhatImD0ing/hackathonstarterkit

Run this command in the terminal:
npx skills add IdkwhatImD0ing/hackathonstarterkit --skill scaffold-backend

Then confirm the installation when prompted.

Skill Content

scaffold-backend/SKILL.md
Scaffold Backend

Scaffold Backend

Generate a minimal, working backend from the confirmed PRD. The backend should be callable immediately by the frontend, even if persistence is temporary.

Preflight

Check from the repo root:

test -f AGENTS.md && test -f PRD.md || { echo MISSING_DOCS; exit 1; }
test -d server && echo SERVER_EXISTS || true

Read `PRD.md > Backend Needed?`.

Stop without creating files if:

  • `AGENTS.md` or `PRD.md` is missing
  • `Backend Needed?` is missing, empty, or starts with `No`
  • `server/` already exists and is non-empty
  • `Backend Routes` is empty even though backend is needed

In each stop case, explain the specific missing prerequisite and the safest next step.

Read The Specs

Extract:

  • Backend routes, each as method, path, and purpose
  • Data model entities and fields
  • Auth, storage, file processing, email, and paid API requirements
  • Domain constraints that affect validation
  • Python version and backend conventions from `AGENTS.md`

If the PRD implies a database, ask whether to wire Supabase now, defer it, or use an in-memory placeholder. Do not silently choose paid or external services.

Before generating files, make a route inventory table with `Method`, `Path`, `Purpose`, `Route Module`, and `Handler`. This table is the contract for the scaffold. If two PRD bullets map to the same handler or an entity has no route module, resolve that before writing files.

Create `server/`

Generate:

server/
  app/
    __init__.py
    main.py
    config.py
    db.py
    models.py
    routes/
      __init__.py
      health.py
      <entity>.py
  tests/
    __init__.py
    test_health.py
  .env.example
  .gitignore
  requirements.txt
  README.md

Include:

  • FastAPI app with CORS for `http://localhost:3000`
  • `GET /health`
  • One route module per entity or route group in `Backend Routes`
  • Pydantic `Base`, `Create`, and response models for each entity
  • Type-safe placeholder data with UUIDs
  • Supabase client only if the user chose it

Avoid `NotImplementedError` stubs. The frontend should be able to call routes and receive realistic dummy responses.

Dependencies

Include:

fastapi>=0.115
uvicorn[standard]>=0.32
pydantic>=2.9
pydantic-settings>=2.6
python-dotenv>=1.0
pytest>=8.3
httpx>=0.27

Add `supabase>=2.9` only if Supabase is selected.

Route Generation Rules

For each PRD route:

  • Match the HTTP method and path exactly.
  • Use descriptive function names.
  • Return typed models or lists of typed models.
  • Raise `HTTPException(status_code=404)` for missing IDs.
  • Keep route behavior simple and predictable.
  • Add comments only where the placeholder store needs future replacement.

`GET /health` is allowed as a scaffold health check, but it does not count as satisfying a PRD route. In the final response, separate health routes from product routes so the user can see exactly what came from the PRD.

Verify

From `server/`:

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
pytest
uvicorn app.main:app --reload

Confirm:

  • Tests pass
  • `GET /health` returns `{"status": "ok"}`
  • Generated routes appear in `/docs`
  • No secrets are hardcoded

If verification fails, switch to the bugfix workflow and fix the generated scaffold before reporting success.

Final Response

Return:

  1. 1Files Created: every file under `server/`
  2. 2Routes Generated: each PRD route and generated handler
  3. 3Health Check: `GET /health` status, listed separately from PRD product routes
  4. 4Persistence: Supabase or in-memory placeholder, with reason
  5. 5Verification: commands and outcomes
  6. 6Next Steps: update frontend API URL and connect the first feature

Boundaries

  • Do not run without the required docs.
  • Do not create a backend when the PRD says no backend.
  • Do not overwrite existing backend files without approval.
  • Do not invent routes outside the PRD.
  • Do not hardcode secrets.

Raw SKILL.md

Copy the full contents below and save as SKILL.md in a folder named scaffold-backend/.

---
name: scaffold-backend
description: "Create a PRD-driven FastAPI backend in `server/` from repo-root `AGENTS.md` and `PRD.md`. Use this skill after frontend scaffolding only when `PRD.md` says `Backend Needed?` is Yes, especially for API routes, Pydantic models, health checks, optional Supabase wiring, and type-safe placeholder data."
---

# Scaffold Backend

Generate a minimal, working backend from the confirmed PRD. The backend should be callable immediately by the frontend, even if persistence is temporary.

## Preflight

Check from the repo root:

```bash
test -f AGENTS.md && test -f PRD.md || { echo MISSING_DOCS; exit 1; }
test -d server && echo SERVER_EXISTS || true
```

Read `PRD.md > Backend Needed?`.

Stop without creating files if:

- `AGENTS.md` or `PRD.md` is missing
- `Backend Needed?` is missing, empty, or starts with `No`
- `server/` already exists and is non-empty
- `Backend Routes` is empty even though backend is needed

In each stop case, explain the specific missing prerequisite and the safest next step.

## Read The Specs

Extract:

- Backend routes, each as method, path, and purpose
- Data model entities and fields
- Auth, storage, file processing, email, and paid API requirements
- Domain constraints that affect validation
- Python version and backend conventions from `AGENTS.md`

If the PRD implies a database, ask whether to wire Supabase now, defer it, or use an in-memory placeholder. Do not silently choose paid or external services.

Before generating files, make a route inventory table with `Method`, `Path`, `Purpose`, `Route Module`, and `Handler`. This table is the contract for the scaffold. If two PRD bullets map to the same handler or an entity has no route module, resolve that before writing files.

## Create `server/`

Generate:

```text
server/
  app/
    __init__.py
    main.py
    config.py
    db.py
    models.py
    routes/
      __init__.py
      health.py
      <entity>.py
  tests/
    __init__.py
    test_health.py
  .env.example
  .gitignore
  requirements.txt
  README.md
```

Include:

- FastAPI app with CORS for `http://localhost:3000`
- `GET /health`
- One route module per entity or route group in `Backend Routes`
- Pydantic `Base`, `Create`, and response models for each entity
- Type-safe placeholder data with UUIDs
- Supabase client only if the user chose it

Avoid `NotImplementedError` stubs. The frontend should be able to call routes and receive realistic dummy responses.

## Dependencies

Include:

```text
fastapi>=0.115
uvicorn[standard]>=0.32
pydantic>=2.9
pydantic-settings>=2.6
python-dotenv>=1.0
pytest>=8.3
httpx>=0.27
```

Add `supabase>=2.9` only if Supabase is selected.

## Route Generation Rules

For each PRD route:

- Match the HTTP method and path exactly.
- Use descriptive function names.
- Return typed models or lists of typed models.
- Raise `HTTPException(status_code=404)` for missing IDs.
- Keep route behavior simple and predictable.
- Add comments only where the placeholder store needs future replacement.

`GET /health` is allowed as a scaffold health check, but it does not count as satisfying a PRD route. In the final response, separate health routes from product routes so the user can see exactly what came from the PRD.

## Verify

From `server/`:

```bash
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
pytest
uvicorn app.main:app --reload
```

Confirm:

- Tests pass
- `GET /health` returns `{"status": "ok"}`
- Generated routes appear in `/docs`
- No secrets are hardcoded

If verification fails, switch to the bugfix workflow and fix the generated scaffold before reporting success.

## Final Response

Return:

1. **Files Created**: every file under `server/`
2. **Routes Generated**: each PRD route and generated handler
3. **Health Check**: `GET /health` status, listed separately from PRD product routes
4. **Persistence**: Supabase or in-memory placeholder, with reason
5. **Verification**: commands and outcomes
6. **Next Steps**: update frontend API URL and connect the first feature

## Boundaries

- Do not run without the required docs.
- Do not create a backend when the PRD says no backend.
- Do not overwrite existing backend files without approval.
- Do not invent routes outside the PRD.
- Do not hardcode secrets.