---
title: "Using Playstack with Megamono"
description: "Let Megamono shape the repository while Playstack installs capability closures, checks database compatibility, and materializes package artifacts."
tags: ["getting-started","megamono","cli","nx","composition","database"]
---

Megamono and Playstack meet at an explicit boundary: Megamono knows where applications and infrastructure projects belong; Playstack knows which packages and artifacts make a product capability complete.

<Callout title="New to Megamono?">

[Visit megamono.com](https://megamono.com) to learn what it is and explore its tools and documentation.

</Callout>

| Concern                                                                                                                                        | Owner            |
| ---------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- |
| Workspace, Nx graph, app paths, database-project placement, and generic CI                                                                     | Megamono         |
| Capability recipes, prerequisites, framework bindings, database compatibility, artifact manifests, integration contracts, and wiring templates | Playstack        |
| Discovery, placement, planning, and materialization of reviewed application wiring                                                             | Megamono         |
| Final controllers, routes, composition roots, provider credentials, migrations, and product policy                                             | Your application |

Neither side needs to duplicate the other. Playstack does not import Megamono, inspect an Nx graph, read `megamono.json`, or assume `apps/web` and `apps/api` unless those paths are passed explicitly.

## Start with repository shape

Use Megamono's guided initialization when adopting an existing repository or shaping a new monorepo:

```sh
megamono init
```

Create or register the application-owned database target before adding a persistence-bearing capability:

```sh
megamono add database primary --adapter=prisma
```

Database names are user-defined lowercase slugs. Megamono owns the database project and records the matching named Playstack target; it does not hide the selected ORM or run Playstack package migrations.

## Add a Playstack capability

Preview the exact package and surface selection first:

```sh
playstack info auth --web --api
playstack add auth \
  --web=apps/web \
  --api=apps/api \
  --database=primary \
  --dry-run
```

For automation, add `--json`. The versioned plan includes the entire package closure plus active routes, environment variables, module imports, framework configuration, health checks, required tests, application decisions, and integrity-checked ejectable templates.

Apply the same plan non-interactively after review:

```sh
playstack add auth \
  --web=apps/web \
  --api=apps/api \
  --database=primary \
  --yes
playstack init
```

Megamono may invoke this operation for a concise capability selection such as `auth`, `accounts`, `billing`, or `content`. It must pass the app paths and database name it already knows. The same Playstack commands remain independently executable in a plain Node repository.

Fully qualified `@playstack/*` package names are Megamono's direct-install escape hatch when you want a package rather than a capability recipe. Use `playstack info <capability>` when you want prerequisites and compatible web, API, and persistence surfaces selected together.

## Check storage, then materialize artifacts

For an existing Prisma schema, run the read-only compatibility report before writing:

```sh
playstack database compatibility --database=primary
playstack database sync --database=primary --dry-run
playstack database sync --database=primary
```

Then use the application's ORM tooling explicitly:

```sh
prisma migrate dev
```

The sequence is intentionally visible:

```text
megamono add database
  -> playstack add
  -> playstack database compatibility
  -> playstack database sync
  -> application migration tooling
```

Playstack never connects to the database, generates a migration history, runs schema push, or applies a migration. If an existing schema is semantically equivalent but not physically compatible, implement the package persistence interface in the application rather than declaring the managed artifact satisfied. See [Existing schema adoption](/docs/cli/existing-schema-adoption).

## Generate and compose the application boundary

Package installation is not application wiring. Integration-facing packages publish `playstack.integration.json`; Playstack filters each contract for the selected surface and adapters, then exposes it in `add --dry-run --json`. Megamono can place and materialize those templates because it knows the Nx project graph. The resulting files are ejectable and application-owned.

The current manifest-backed surfaces include rate limiting, cache and Next caching, queues, auth, accounts, billing, storage, webhooks, and AT Protocol. Requirements can describe module imports, provider tokens, environment variables, endpoint contracts, raw-body handling, framework configuration, health checks, required tests, and unresolved product decisions.

After Playstack and Megamono produce the reviewed plan:

1. construct the portable service with application-owned persistence, events, clocks, IDs, and provider clients;
2. register the optional NestJS or Next.js binding at the relevant app edge;
3. review or complete generated controllers, routes, providers, workers, health checks, and tests around the exported service; and
4. run the repository's ordinary tests, builds, migrations, and deployment checks.

This preserves a useful division of labor: Playstack authors the authoritative integration contract, Megamono places and materializes it, and the application keeps the generated code plus its product and runtime decisions.

## Verify the handoff

```sh
playstack doctor --check
```

Megamono can schedule this read-only command in repository health checks. Playstack remains the single owner of managed-artifact, lint, Skills, and ejected-upstream drift logic; Megamono does not reimplement those checks.

`playstack init --survey --json` uses the same Nx-aware inventory shape for direct adoption: nested Next and Nest applications, Pages or App Router, workers, Redis and BullMQ usage, datasource-bearing Prisma contexts, and generated schema derivatives are reported without human output or writes.