{"id":16387,"plugin_id":"plugin_asdk_app_6ab4ed5292d48191bc192893c8c83045","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:13:18.883Z","digest":"122e382d3011ec090e6bba250c3fd0509f8d5cd34784912e14ab85fe9a41d3f1","against":null,"payload":{"description":"Build and deploy applications when the user selects or invokes the Prisma plugin, including requests like \"Build a simple Todo app and deploy it\" that do not name a stack. Use Prisma Composer for new apps and Prisma Compute for deployment. Also use for explicit Composer/Compute requests, deployment diagnostics, and recovering Composer deployments. Does not cover unrelated ORM or database administration.","included_files":[{"relative_path":"references/toolchain.md","size_in_bytes":14513}],"name":"prisma-build-and-deploy","skill_md_contents":"---\nname: prisma-build-and-deploy\ndescription: >-\n  Build and deploy applications when the user selects or invokes the Prisma\n  plugin, including requests like \"Build a simple Todo app and deploy it\" that\n  do not name a stack. Use Prisma Composer for new apps and Prisma Compute for\n  deployment. Also use for explicit Composer/Compute requests, deployment\n  diagnostics, and recovering Composer deployments. Does not cover unrelated ORM\n  or database administration.\n---\n\n# Build and deploy with Prisma\n\nGuide the requested application from working code to a verified deployment.\nSelecting Prisma for this task supplies the default: Composer for a new app and\nCompute for deployment. The user need not name either product or separately ask\nfor local and live verification. State that choice briefly and follow this\nworkflow. Respect explicit stack/hosting choices and local-only requests;\ninstallation alone is not a provider choice.\n\nThis journey requires ChatGPT's desktop app with local execution. Check the\nactual execution environment: a cloud task launched from desktop is still out of\nscope. In web/cloud execution, explain that the user must continue in a desktop\ntask running locally; do not offer manual credentials as a workaround.\n\nDo not process protected health information (PHI) or payment card data regulated\nby PCI DSS through files, CLI commands, database operations, MCP tools, logs, or\napplication verification. If the request or available context indicates such\ndata may be present, stop before accessing affected resources; clarify without\nrequesting real data samples and offer an isolated environment with synthetic\ndata only. If encountered unexpectedly, stop further access and do not reproduce\nthe data in responses or artifacts. Never retrieve it merely to redact it later\nor switch tools to bypass this restriction. Ordinary Todo requests need no extra\nquestionnaire; healthcare or payment prototypes using synthetic data are supported.\n\nFor Composer declarations, wiring, builds, and database concepts, read the bundled\n[Composer core concepts](../prisma-composer-core-concepts/SKILL.md). Reuse its\nguidance rather than re-deriving the API. For CLI installation and authentication,\nread [the version-specific toolchain reference](references/toolchain.md): the\nbundled core reference describes the standalone CLI, while this workflow defaults\nto the unified Prisma CLI for new interactive projects.\n\n## Establish the project and toolchain\n\n- Inspect the app, package manifest, lockfile, existing Composer configuration,\n  and scripts. Preserve the framework, package manager, and database strategy of\n  an existing app. If it is not Composer-ready, explain the concrete adaptation\n  needed before undertaking a substantial rewrite.\n- Resolve Node and the package-manager executable together, plus Bun when used.\n  Check paths and versions against package requirements and project pins. Preserve\n  the selected executables across install, build, dev, and deploy; recheck them\n  when commands switch execution contexts. Use available host capabilities to\n  supply supported tooling and install project-local dependencies yourself.\n  Explain progress or genuine blockers in plain language; the user should not\n  need to open a terminal, run commands, or configure credentials.\n- For a new project, use the dependency set in the toolchain reference, including\n  required peers, and prefer its verified Node/npm pair when available. For an\n  existing project, inspect its installed versions and\n  their matching skill/documentation; do not downgrade it to the bundled version.\n- Choose a simple implementation suited to the request. Do not turn a small Todo\n  request into a design interview. Make the schema and persistence approach\n  explicit; do not accidentally mix raw SQL initialization with ORM migrations.\n\n## Resolve authentication and the deployment target\n\nWhen deployment is requested, start this after project inspection while local\nwork continues. Combine outstanding workspace and region questions when possible.\n\n1. Check the existing connection early and verify remote workspace access. Reuse\n   a valid session. If login is needed, explain: \"To put your app online, connect\n   Prisma. If you don't have an account, you can create one during sign-in. Return\n   here when you're finished; I'll handle the setup.\" Describe only providers\n   offered by the actual page. Start one managed login using the reference's\n   supported command and keep it alive. If the browser does not open, share\n   the actual authorization link emitted by that attempt. Leave signup and\n   consent to the user; never request passwords, tokens, or callback URLs in chat.\n2. After login, require successful process completion, authenticated identity,\n   and a successful remote workspace read from the deployment environment before\n   saying \"You're connected to Prisma.\" An empty project list is valid; browser\n   signup or \"I'm done\" alone is not proof. Reuse the workspace authorized during\n   login unless another was explicitly requested. Honor explicit choices and\n   validate access without asking again. If a target still cannot be resolved,\n   use authoritative membership when available (sole workspace automatically,\n   multiple by asking); otherwise ask once with known sessions as suggestions,\n   allowing another name. Stored sessions are not an account-wide inventory and\n   failed discovery does not establish a workspace count.\n3. Preserve an existing project's region; clarify an explicitly conflicting\n   region before provisioning. For a new project, honor the chosen region or ask,\n   \"Select the region closest to your users.\" Show the complete supported choices\n   with geographic labels and IDs from the reference's region link; do not infer\n   a recommendation from the developer's location.\n4. Resolve any ambiguous application/project identity. Preserve the requested\n   stage; a new demo defaults to `demo`. State the resolved target as a progress\n   update, not another approval request. Provision only after target selection and\n   local verification are complete. Omitting the stage targets production.\n\nCheck quota information only through an available supported read-only capability.\nOtherwise note briefly that deployment may still fail after creating resources;\ndo not invent a quota endpoint or promise a comprehensive preflight.\n\nFor cancelled, expired, or failed login, explain the outcome and offer a fresh\nattempt after the old process has ended. Preserve app progress; distinguish\nauthentication failure from network, permission, and quota problems. Continue\nindependent local work while login or answers are pending, then resume deployment\nautomatically once connection, target, and local verification are ready.\n\n## Build and verify locally\n\nFollow install → typecheck → build → local dev → verification. The app owns its\nbuild; Composer's dev and deploy operations consume that output.\n\nFor a Todo app, exercise adding, listing, completing, and deleting a todo. Verify\ndata survives an actual service restart without resetting its database; exiting\nthe dev CLI alone is not proof that its service stopped. Check the actual UI in a\nbrowser and inspect failures in the running service. For a different app, test\nthe equivalent core user action and persistence when relevant.\n\nLocal Composer development does not need cloud credentials. Keep building and\ntesting locally when cloud login or target selection is still pending. Report\nany unperformed verification explicitly.\n\n## Deploy, verify, and recover\n\nBuild before deploying. Use the same resolved project and stage throughout the\nattempt. Capture a structured deploy report if the installed CLI supports it;\notherwise retain the relevant command output and inspect the platform read-only.\n\nSuccess requires a live service version, a reachable URL, a working core user\naction backed by the database when applicable, and a browser check. Use the\nproject's supported service inspection commands to distinguish an allocated\nservice from a live version. A zero exit code or created project is not enough.\nFor Todo, check CRUD against the deployed application as well as locally.\n\nUse the optional [MCP diagnostics](references/toolchain.md#optional-mcp-diagnostics)\nonly to investigate a failure or an explicit diagnostic request. Match the MCP\nworkspace and application to the CLI target before inspecting state or logs.\nKeep Composer/CLI responsible for changes and deployment; unavailable MCP access\nmust not block their normal path. MCP authentication does not authenticate the CLI.\n\nOn failure:\n\n- Record the failed step, reported error, resolved target, and available resource\n  IDs. Check whether an existing version is still serving traffic, whether a new\n  version is live, or whether nothing is serving. Do not infer this from the\n  failure alone.\n- Preserve the app configuration, deployment identity, and recorded deploy state.\n  Explain what exists and what remains incomplete. Fix the reported cause before\n  retrying the same target so Composer can converge existing resources. If state\n  cannot be verified, stop and investigate instead of creating a renamed app.\n- A quota or entitlement refusal needs resolution, not a retry loop. Do not\n  guess the quota amount or limit from a generic `quota-exceeded` error.\n- Treat cleanup as a separate action requiring the user's intent. Do not delete\n  resources or deployment state as an automatic recovery step.\n\nFinish with the local/deployed URLs, what was actually verified, any remaining\nblocker, and material demo limitations (for example, cookie-only ownership or\nlack of cross-device access). If Console deployment history was unavailable,\nreport it separately from the live result; do not create Git commits to suppress\nthat warning. Keep unverified work clearly separate from success.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}