# Production Full Stack

> Design, scaffold, implement, review, and verify production-grade full-stack applications and substantial backend or frontend features. Use when creating an app, API, backend, frontend, dashboard, service, worker, queue, database-backed feature, or production deployment. Enforce scalable API/worker architecture, bounded concurrency, queues, caching, pagination, audit logging, rate limits, Docker a…

- **Type:** Skill
- **Install:** `agentstack add skill-notwld-engineering-baseline-production-full-stack`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [notwld](https://agentstack.voostack.com/s/notwld)
- **Installs:** 0
- **Category:** [Databases](https://agentstack.voostack.com/c/databases)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [notwld](https://github.com/notwld)
- **Source:** https://github.com/notwld/engineering-baseline/tree/master/skills/production-full-stack

## Install

```sh
agentstack add skill-notwld-engineering-baseline-production-full-stack
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Production Full-Stack

Produce a deployable, observable, secure system—not a demo. Ponytail governs
scope, not production quality: prefer a modular monolith until measured needs
justify services, but never omit a required control to save code.

If this is an existing application and adoption is pending, stop and invoke
Adopt Existing Project. Do not scaffold over, move or refactor existing code
until its read-only assessment and user approval gate are complete.

## 1. Research and decisions

Before selecting a framework, queue, cache, database library, validation library,
UI system, or observability package:

1. Search current official documentation, release notes, package registries,
   security advisories, maintenance policy, compatibility, and license.
2. Prefer stable, actively maintained, production-proven libraries with minimal
   dependency and operational cost. Do not select from memory alone.
3. Record considered options, versions, evidence links, tradeoffs, and the final
   decision in `docs/architecture/dependencies.md`.
4. Pin direct dependencies and commit the ecosystem lockfile.

Read [references/architecture.md](references/architecture.md), then use
Superpowers brainstorming and planning before implementation.

## 2. Scaffold the production contract

Create a stack-appropriate equivalent of:

```text
apps/web        frontend
apps/api        HTTP/API process
apps/worker     background worker process
packages        shared contracts, UI, validation, config, observability
database        schema, migrations, seeds
infra           Docker and deployment configuration
tests           unit, integration, contract, E2E, load and security tests
docs            architecture, API, operations and security evidence
```

Also create and maintain:

- `Dockerfile` for each runnable service, `compose.yaml` for local development,
  and `compose.prod.yaml` as a hardened single-host production baseline.
- `.env.example` with documented names and safe placeholders.
- `.env.local` with cryptographically generated development secrets; never use
  `secret`, `changeme`, framework defaults, or copied production values.
- `.gitignore` covering `.env.local`, other environment files except examples,
  keys, certificates, logs, dumps, caches, coverage, builds and editor files.
- `.production-baseline.json` containing implementation and test evidence.
- `README.md`, `DESIGN.md`, API documentation, threat model, ASVS matrix,
  operational runbook and risk register.

Run Security Review and state STRIDE mitigations before implementation.

## 3. Mandatory architecture outcomes

- Keep API processes stateless and horizontally scalable.
- Include a queue/broker and a separately scalable worker service.
- Move slow, bursty, retryable, scheduled, CPU-heavy, file-processing, email,
  webhook, import/export and third-party work out of request handlers.
- Use a bounded configurable worker pool with concurrency greater than one.
  Select threads, async tasks, processes, or runtime workers according to the
  language and workload; never create an unbounded thread per request.
- Make queued jobs idempotent, traceable and tenant-aware. Use acknowledgements,
  bounded exponential-backoff retries with jitter, timeouts, a dead-letter path,
  cancellation where feasible, and observable queue depth/age/failure metrics.
- Use transactional outbox or equivalent when database state and message
  publication must succeed together.
- Provision and use a shared cache for rate limits, safe reusable reads, job
  status or other justified cross-instance state. Every cached value needs an
  owner, key namespace, tenant boundary, TTL, invalidation rule, stampede
  protection and sensitive-data decision.
- Use server-side pagination for every unbounded collection. Prefer cursor
  pagination for changing or high-volume data; allow page/offset pagination for
  stable administrative datasets where random access is required.
- Apply endpoint-specific rate limits and quotas by IP, identity, tenant and/or
  operation cost. Return `429`, retry guidance and the standard API envelope.
- Emit structured operational logs, metrics and traces with correlation IDs.
- Emit append-oriented audit events for security-relevant actions, including the
  client IP derived only through a configured trusted-proxy chain.

Read [references/concurrency-data.md](references/concurrency-data.md) and
[references/operations.md](references/operations.md).

## 4. Backend contract

Use one documented response envelope for success and failure. Keep HTTP status
semantics authoritative while including `status_code` for client consistency.
Use stable machine-readable error codes and safe, specific messages a user can
act on. Never expose stack traces, SQL, secrets, internal hosts or raw exceptions.

Validate at the boundary, authorize every resource/action server-side, use
transactions and constraints for invariants, and generate an OpenAPI or equivalent
contract from or alongside the implementation. Read
[references/api-contract.md](references/api-contract.md).

## 5. Frontend contract

Invoke Impeccable for UI work. Research current layouts appropriate to the
specific product and workflow using reputable design-system documentation and
real products; record the rationale and sources in `DESIGN.md` without copying.

- Use shared shells, layouts, navigation, forms, tables, pagination, loading,
  empty, error and permission states instead of page-specific duplication.
- Use a consistent spacing scale. Default component and table-cell padding to
  the `space-3` token (`0.75rem`; Tailwind `p-3`) while adapting compact/touch
  variants deliberately.
- Avoid generic AI aesthetics, decorative gradients, glass cards, excessive
  shadows, nested cards and random radii.
- Display backend field errors inline and action/system outcomes through an
  accessible shared toast system. Preserve the backend request ID for support.
- Implement keyboard behavior, focus management, semantic HTML, contrast,
  responsive layout and reduced-motion support.

Read [references/frontend.md](references/frontend.md).

## 6. Completion gate

For every feature or behavior change:

1. Update `README.md` and affected API, architecture, operations, environment,
   security and design documentation in the same change.
2. Update `.env.example`, `.env.local`, `.gitignore`, Compose files and the
   production manifest when the change affects them. Never print secret values.
3. Run unit, integration, contract, E2E, negative/security and relevant load or
   concurrency tests.
4. Review the complete diff using Superpowers code review and Security Review.
5. Check for leaked tasks, threads, listeners, subscriptions, timers, streams,
   files, sockets, DB connections, response bodies and unbounded caches/queues.
6. Profile or soak-test long-running paths when memory/resource leakage is
   plausible; compare resource usage before and after repeated work.
7. Run `scripts/validate_project.py --project ` from this skill.
8. Do not claim production-ready while evidence is missing, checks fail, or
   residual critical/high risk lacks explicit acceptance.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [notwld](https://github.com/notwld)
- **Source:** [notwld/engineering-baseline](https://github.com/notwld/engineering-baseline)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** yes
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-notwld-engineering-baseline-production-full-stack
- Seller: https://agentstack.voostack.com/s/notwld
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.