arch-scaffold-service

Scaffolds a FastAPI web service with gateway, routers, service interfaces, health endpoints, and tests.

89|10|Updated Sep 15, 2026
One-click install
npx skills add https://github.com/baristaze/swe_guidelines --skill arch-scaffold-service-baristaze
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: arch-scaffold-service
Source: https://github.com/baristaze/swe_guidelines/tree/main/skills/arch-scaffold-service
Command: npx skills add https://github.com/baristaze/swe_guidelines --skill arch-scaffold-service-baristaze

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Setting up a new web service in a multi-tenant Python monorepo involves dozens of files—app factory, container, gateway, routers, wire types, settings, Dockerfile, Terraform modules, CI workflows—and each must follow strict architectural conventions. This Skill generates the entire service skeleton in the prescribed shape so nothing is missed. ## Core Features & Use Cases - Full service scaffolding: Creates the distribution, settings, app container, app factory with fixed middleware order, console entry point (serve, migrate, bootstrap, grant-operator, openapi), Docker image, and tests under services/<service-name>/. - Gateway and routing layer: Writes credential parsing, operator gate, error handlers, rate limiting, edge idempotency, request-id middleware, routers, wire types, and service interfaces with in-process impls—written once and shared via a root gateway/ distribution on later services. - Optional realtime and app-specific modes: --realtime adds the websocket channel (tickets, send buffer, typed envelopes, replay route); --app builds an app-specific service composing domain operations; --container adds the service to the full compose file. - Use Case: After scaffolding namespaces for a new product, run this Skill to create the first API process hosting every namespace, complete with health/readiness probes, OpenAPI emission via make openapi, Terraform service modules per environment, and deploy workflow entries. ## Quick Start Ask the AI to run the arch-scaffold-service skill with a service name such as "api" to scaffold the complete FastAPI service with gateway, routers, and tests.

Frequently Asked Questions about arch-scaffold-service

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I scaffold a new FastAPI microservice in a Python monorepo?▼

Run the skill with a service name, for example `api`, and it generates the distribution, settings, container, app factory, gateway, routers, service interfaces, Dockerfile, and tests under `services/<service-name>/`. It also updates the uv workspace, Makefile, dev script, and deploy workflows.

How to add a websocket realtime channel to a FastAPI service?▼

Pass the `--realtime` flag when scaffolding. The skill writes the realtime package with ticket redemption, the socket route, a bounded send buffer, typed frame envelopes, the events replay route, and a shared `realtime-timeouts.json` asserted by both service and client tests.

What is the difference between --namespaces and --app flags when creating a service?▼

`--namespaces` creates a domain service hosting only the named namespaces, while `--app` creates an app-specific service that composes domain operations for one app and rejects requests from other apps. With no flags, the service hosts every existing namespace.

Does the scaffolded service include authentication and rate limiting?▼

Yes. The gateway package includes credential parsing by prefix, an operator gate with TOTP second factor, error handlers, cache-backed rate limiting that fails open, edge idempotency on creating routes, and request-id middleware over HTTP and websocket scopes.

When should I not run this service scaffolding skill?▼

Do not run it for the first form of a service split: that is a deployment change where the existing API image mounts only named routers via its `namespaces` setting. Run this skill only when the new service needs code of its own.

Why does a second scaffolded service not get its own gateway package?▼

The gateway is written once. When a service already exists, the first service's `gateway/` package is moved into a root `<root>-gateway` distribution that both services import, so edge concerns like auth, rate limiting, and idempotency exist in a single shared place.