--- name: record-gotchas-6914debb613c description: Capture surprises, workarounds, and rough edges hit while *consuming* the public surface of Prisma Next, Prisma Compute, or Prisma Postgres — anything a real user of these products would experience. Fires whenever an operator (or agent) writes a workaround, hits a surprising failure mode, or finds undocumented behaviour while using one of these three products from the outside (extension authoring, example apps, integration tests, customer reproductions, internal demos, manual repros). Does NOT fire on bugs in code the operator's own team maintains — those are normal product-backlog bugs. In product-team repos (e.g. `prisma-next-ws`), surfaces the gotcha and offers the operator three paths (capture-as-gotcha, file a normal bug, or note-and-move-on). Outside product-team repos (pet projects, hackathon entries, customer codebases), silent-captures into the project's gotchas log AND a Triage-state Linear ticket in the matching gotchas project — no operator escalation. Do not skip the recording step. --- # Record a gotcha A **gotcha** is friction that a *consumer* of Prisma Next, Prisma Compute, or Prisma Postgres would feel — something an external user of those products would also experience: a surprising failure mode, an undocumented behaviour, a workaround you wrote, a mental model mismatch with the CLI / runtime / docs. The signal is the consumer's perspective, not the project context — you can hit a gotcha while writing an extension, working in an example app, reproducing a customer report, running an integration test against the public surface, or building anything that consumes the product from the outside. A gotcha is **not** a bug in code your team maintains. If you own the surface and you can fix it, that's a normal product bug, filed in the regular product backlog — not a gotcha. This skill is the canonical workflow for capturing gotchas. When the trigger fires: 1. Determine whether you're in a product-team repo or somewhere else — the escalation mode depends on it (see § Escalation mode). 2. Write a short entry to the matching gotchas log (`gotchas.md` or a per-product file). 3. File a Triage-state ticket in the matching `*-gotchas` Linear project. 4. Cross-link the two so future readers can navigate either way. When in doubt about whether something is gotcha-worthy, capture it. The cost of a near-duplicate entry is trivial; the cost of losing the learning is permanent. > **This skill is not optional for qualifying gotchas.** If you wrote a workaround, consulted source code, or hit a behaviour that didn't match the docs while consuming the product, run this skill before the conversation ends. --- ## Consuming vs. maintaining — the boundary The trigger depends on the *role* the operator is wearing in the moment, not on the repo they're sitting in. | You're doing… | Role | Trigger fires? | |---|---|---| | Writing a new extension that uses PN's authoring API | Consuming | Yes | | Working in an example app under `examples/` and hitting a CLI / runtime rough edge | Consuming | Yes | | Reproducing a customer's bug report against the public surface | Consuming | Yes | | Running an integration test that exercises the public CLI / runtime | Consuming | Yes | | Building an internal demo with PN / Compute / PPg | Consuming | Yes | | Fixing a bug in PN core | Maintaining | No — file a normal bug | | Adding a feature to PN's runtime | Maintaining | No | | Refactoring an internal package | Maintaining | No | **Worked example.** You change `schema.prisma`, run `prisma-next migration plan`, and the CLI reports *"No changes detected"* — because the contract was stale and you hadn't run `contract emit`. The CLI's mental model didn't match yours; a real user would hit this. That's a gotcha, even though you're sitting in `prisma-next-ws` and could fix it: you were *consuming* the migration workflow, not maintaining it. **Ambiguous cases default to capture.** If you can't tell which role you were in, capture the gotcha. The team filters at triage. --- ## Hard prerequisite: Linear MCP This skill **requires** the Linear MCP plugin to be installed and authenticated. Without it, ticket filing is impossible and the workflow is incomplete. **If the Linear MCP plugin is not available or not authenticated, halt and tell the operator** something like: > I just hit a gotcha I'd like to record, but the Linear MCP plugin isn't available. Please install and authenticate `plugin-linear-linear` (the [Linear plugin for Cursor](https://cursor.com/plugins/linear)), then re-run the request. The skill needs to file a Triage-state ticket in the matching Prisma gotchas project. Do not proceed. Do not write the file entry without the ticket. The two halves are intentionally coupled — the file is the local record; the ticket is the team's signal. Both must exist for the pipeline to work. --- ## The three products and their Linear projects Each product has a single Linear project for *all* tickets — both gotchas and normal bugs. Gotchas and normal bugs are distinguished by **status / labels**, not by which project they're filed in. | Product | Linear project | |---------|----------------| | **Prisma Next** ORM (`@prisma-next/*`, schema, generated client, migration tooling) | [`pn-gotchas`](https://linear.app/prisma-company/project/pn-gotchas-a6f6f5157a5c/overview) | | **Prisma Compute** (`@prisma/compute-cli`, deploy, runtime, env management) | [`compute-gotchas`](https://linear.app/prisma-company/project/compute-gotchas-dd3ac34b5ad4/overview) | | **Prisma Postgres** (PPg, `@prisma/dev`, dialect behaviour) | [`ppg-gotchas`](https://linear.app/prisma-company/project/ppg-gotchas-afe77336f696/overview) | **Filing convention.** - **Gotcha:** status `Triage`, no priority, no labels — the project itself is the dogfood filter. - **Normal bug:** filed in the same project, but follow the product team's regular conventions (status, priority, labels). Used when the operator's team owns the issue and wants it in the regular triage flow rather than the dogfood lens. The project names retain the `-gotchas` suffix for historical reasons; treat them as the canonical Linear project for each product regardless. If a gotcha straddles two products, pick the surface where you were when it bit, file there once, and mention the second product in the body. If you find yourself wanting to file a gotcha for a fourth product (Eclipse, Slack, Bun, Next.js, etc.), **stop**. This skill is scoped to the three Prisma products. Other tools' bugs go in those tools' own issue trackers. Exception: if a third-party bug only surfaces *because of* how a Prisma product is structured, record it on the Prisma side and link the third-party tracker. **Where to record locally**, in priority order: 1. If `docs/prisma-next-gotchas.md`, `docs/compute-gotchas.md`, or `docs/ppg-gotchas.md` exist — append to the matching one. 2. Otherwise, append to `gotchas.md` at the repo root. Create it (using the bootstrap template below) if missing. --- ## Escalation mode (product-team repo vs. elsewhere) How the agent behaves when the trigger fires depends on **which repo it's in**: - **Product-team repo** (e.g. `prisma-next-ws`, the Compute workspace, the PPg workspace) → **surface the gotcha and offer three paths.** The operator is likely on the affected product's team and is in a position to decide whether this is gotcha-worthy, a regular bug, or already known. Don't capture silently — ask. - **Any other repo** (customer pet projects, hackathon entries, internal demos, sandbox repos) → **silent capture.** Run the gotcha workflow without escalating. The operator is consuming the product as an outsider; the dogfood signal is exactly the friction they would otherwise not formalize. If you can't tell which kind of repo you're in, treat it as "other" — silent capture is the safer default for a dogfood pipeline. ### The three paths (product-team repos only) Surface the gotcha to the operator in one short message — symptom, hypothesis on cause, the workaround you used or are about to use — then offer: 1. **Capture as gotcha** — run the full gotcha workflow below (file entry + ticket filed in `Triage` status, no priority, no labels). The default when the operator wants the team to see this through a dogfood lens. 2. **File a normal bug** — the agent files a regular ticket in the same product Linear project on the operator's behalf, but following the team's normal-bug conventions rather than the gotcha filing convention. Used when the operator's team owns the issue and wants it in the regular triage flow. 3. **Note-and-move-on** — do nothing further. Used when the operator already knows about the issue or it's not worth recording. The agent acknowledges and drops it. The operator picks. Default to capture-as-gotcha if the operator doesn't choose. --- ## When NOT to use Skip this skill for: - **Bugs in code the operator's own team maintains.** This is the consuming-vs-maintaining boundary. File a normal bug in the product's Linear project (using the team's normal-bug filing convention, not the gotcha-Triage one) instead. - **Subjective preferences** ("I'd prefer the CLI used `--service` instead of positional"). File feature requests in Linear directly, not as gotchas. - **Bugs in third-party tools** (Bun, Next.js, `pg`, Slack, etc.) — those go in the relevant tool's tracker. Exception: if the third-party bug only surfaces *because of* how a Prisma product is structured, record it on the Prisma side and link the third-party tracker. - **Misunderstandings on your end that the docs already cover.** Re-read the docs first. Honest self-test: if the answer is in the docs and you missed it, that's not a gotcha. --- ## Workflow Numbered, in order. Don't skip steps; the value comes from doing all of them. ### 1. Verify Linear MCP is available If the `plugin-linear-linear` MCP isn't installed or isn't authenticated, halt per § Hard prerequisite. ### 2. Identify the product Use the table in § The three products. If the gotcha straddles two, pick the surface you were on when it bit and mention the second in the body. ### 3. Resolve the escalation mode Determine whether you're in a product-team repo (see § Escalation mode). If yes, surface the gotcha to the operator and offer the three paths; resume the workflow only if they pick "capture as gotcha." If they pick "file a normal bug," skip to § Filing a normal bug below; if they pick "note-and-move-on," exit the skill. If you're not in a product-team repo, proceed with silent capture. ### 4. Search the matching Linear project for duplicates Before filing, search the matching `*-gotchas` project for an open ticket with similar symptoms. Use the symptom keyword(s) — error message text, API name, CLI flag, package version, etc. - If you find a match (read the top 1–3 results to be sure): **do not file a duplicate.** Link to the existing ticket from your gotcha file entry instead. Optionally, add a comment to the existing ticket with new repro evidence if your environment differs from the original report. - If no match: continue to step 5. ### 5. Decide where to record locally Per § The three products. Use the existing per-product file if present; otherwise create `gotchas.md` at repo root with the bootstrap template below. ### 6. Draft the entry Use the file-entry template below verbatim. Keep entries 10–25 lines. If you need more, you're either explaining a generic concept (write a runbook instead) or describing two gotchas (split them). ### 7. File the Linear ticket In the matching `*-gotchas` project: - **Status:** `Triage`. Do not set priority — let the team triage. - **Title:** the file entry's heading, verbatim. - **Description:** see the Linear-ticket template below. Mirror the file entry's body and link back to the file (commit SHA + path + line range once committed; if you haven't committed yet, link to the file path in the working tree and update after). Capture the Linear ticket id (e.g. `TML-1234`) and URL — you'll need both for the file entry's `**Filed upstream:**` line. ### 8. Append the entry to the file - Insert in the file's existing order; don't reorder existing entries (treat the file as append-mostly). - Add the entry's title to the `## Contents` list at the top, with a working anchor link. - Replace the placeholder `**Filed upstream:**` line with the real Linear ticket id and URL from step 7. ### 9. Commit One commit per gotcha (or per closely-related group). Conventional shape: ```text docs(gotcha): record <2–4 line summary: what was surprising, workaround in one sentence, ticket id.> Filed as in . ``` The commit lands alongside the workaround in the same PR. Don't gate the operator's primary work on this — record inline as you finish the workaround. If you cited a `working tree` path in the Linear ticket because you hadn't committed yet, update the ticket description after the commit lands (replace with a permalink to the committed line range). --- ## Filing a normal bug (path 2 in product-team repos) When the operator picks "file a normal bug" instead of capturing as a gotcha: 1. **Search the product's Linear project for duplicates.** Use the same symptom keywords. If a match exists, link the operator to it and ask whether to add a comment with the new repro evidence or drop it. 2. **File the ticket on the operator's behalf** in the matching product project (per § The three products table). - **Title:** symptom-led, same shape as a gotcha entry heading. - **Description:** symptom / cause / workaround / repro from the conversation, formatted like the Linear-ticket template below but minus the `Source:` line (there's no local gotcha file). - **Status / priority / labels:** follow the team's normal-bug conventions, not the `Triage` / no-labels gotcha convention. Ask the operator if you don't know the team's defaults. 3. **Confirm with the operator** by pasting the ticket URL into the conversation. No local file entry, no commit — the ticket is the record. If the operator wants to file the ticket themselves rather than have the agent do it, draft the body and hand off — they paste. --- ## Templates ### File entry Used in `gotchas.md` (or the matching per-product file). ```markdown ## **Filed upstream:** [TML-XXXX](https://linear.app/prisma-company/issue/TML-XXXX) — *""* **Product:** Prisma Next | Prisma Compute | Prisma Postgres **Version:** **First hit:** **Cost:** **Symptom.** **Cause.** **Workaround.** **Reproduction.** 1. 2. ... **References.** - Upstream: [TML-XXXX](https://linear.app/prisma-company/issue/TML-XXXX) - Workaround source: [`path/to/file.ts`](path/to/file.ts) (link to where the fix actually lives) - Related: ``` **Naming the heading.** Lead with the symptom (`OG image URLs fall back to localhost:8080`) or the constraint (`pg/timestamptz codec types output as string | Date`), not the solution (`Set metadataBase`). Future-you searches by what they saw, not what they did about it. ### Linear ticket (gotchas project) - **Project:** the matching gotchas project (PN / Compute / PPg). - **Status:** `Triage`. No priority, no labels — the project itself is the dogfood filter. - **Title:** the file-entry heading, verbatim. - **Description (Markdown):** ```markdown **Source:** **Product:** Prisma Next | Prisma Compute | Prisma Postgres **Version:** ## Symptom ## Cause ## Workaround ## Reproduction 1. 2. ... ## Notes ``` After the gotcha-recording commit lands, update the ticket's `**Source:**` line to point at the permalink for the committed line range (Linear MCP supports issue editing). ### `gotchas.md` (bootstrap, for fresh repos) Use this when creating `gotchas.md` for the first time in a repo that has no per-product files: ```markdown # Gotchas A running log of surprises, workarounds, and undocumented behaviour hit while *consuming* **Prisma Next**, **Prisma Compute**, or **Prisma Postgres** in this project. Each entry captures friction a real user of these products would also experience. Each entry is also filed as a Triage-state Linear ticket in the matching gotchas project so the team can pick them up: - Prisma Next → [`pn-gotchas`](https://linear.app/prisma-company/project/pn-gotchas-a6f6f5157a5c/overview) - Prisma Compute → [`compute-gotchas`](https://linear.app/prisma-company/project/compute-gotchas-dd3ac34b5ad4/overview) - Prisma Postgres → [`ppg-gotchas`](https://linear.app/prisma-company/project/ppg-gotchas-afe77336f696/overview) The capture workflow is documented in [`.agents/skills/record-gotcha/SKILL.md`](.agents/skills/record-gotcha/SKILL.md). --- ## Contents --- ``` --- ## Examples ### Good entry — shape to copy > ## `migration plan` reports "No changes detected" when contract is stale > > **Filed upstream:** [TML-XXXX](https://linear.app/prisma-company/issue/TML-XXXX) > **Product:** Prisma Next > **Version:** `@prisma-next/cli@` > **First hit:** `examples/prisma-next-demo`, changing the schema while iterating on a demo > **Cost:** ~15 minutes > > **Symptom.** Edited `schema.prisma`, ran `pnpm prisma-next migration plan`, got `✔ No changes detected` with `from` and `to` hashes equal. No warning, no indication that the contract was out of date. > > **Cause.** `migration plan` compares the *emitted* contract hash (`src/prisma/contract.json`) against the last applied migration's hash. Editing `schema.prisma` doesn't update the contract — `contract emit` does. The CLI doesn't detect the staleness or warn about it. > > **Workaround.** Run `pnpm prisma-next contract emit` before `migration plan` whenever the schema has changed. Or wire `emit` into your dev script. > > **Reproduction.** Edit `schema.prisma` in `examples/prisma-next-demo`, run `pnpm prisma-next migration plan` without re-emitting. Observe the spurious "No changes detected". Why it's good: symptom-led title, version captured, cost surfaced, cause cites the underlying mechanism, workaround is concrete, repro steps are minimal. ### Bad entry — don't do this > ## Migrations don't work > > **Symptom.** I ran a migration and it failed. > > **Workaround.** I figured it out after a while. Why it's bad: title doesn't tell future-you what to search for; no version, no cause, no concrete workaround, no upstream link. The team can't act on this and the next operator won't recognise it as relevant when they hit the same issue. --- ## Resolved gotchas When a Prisma release fixes a gotcha, **do not delete the entry.** Append a `**Resolved**` line at the bottom of the entry, citing the release that closed it. The history of what we knew when matters; deleting it loses signal about how long the issue lived. ```markdown **Resolved in `@prisma-next/orm@0.5.1`** — see [release notes](...). Workaround removed in [commit abc123](...). ``` If the entry was wrong (rather than fixed), mark it `**Superseded — see **` and add a corrected entry below. Don't edit the original body. --- ## Anti-patterns - **Filing a gotcha about code your team maintains.** That's a bug. File it in the same product Linear project, but with the team's normal-bug conventions (not `Triage` / no-labels). The gotcha filing convention exists to surface the *consumer perspective*; tagging maintenance-side bugs as gotchas dilutes the signal. - **Skipping the Linear ticket** because "I'll file it later." You won't. File now or not at all; "not at all" only if you decided it's not gotcha-worthy. - **Filing without searching for duplicates first.** The gotchas projects fill up fast; duplicate tickets dilute the signal. - **Recording your own misunderstanding as a product gotcha.** If the docs already cover it, skip. (Honest self-test: would you file a public ticket about this? If no, don't write a gotcha either.) - **Burying the workaround in a deeply-nested code comment** instead of the gotcha file. Code comments are for readers of that file. The gotcha file is for the next operator who hits the same trap from a different code path. - **Silent-capturing in a product-team repo.** In `prisma-next-ws` (and the Compute / PPg equivalents), surface the gotcha and let the operator pick the path. They may be about to file it as a normal bug or fix it directly. - **Editing existing entries to "improve" them.** Append-mostly. If an entry is wrong, mark it `**Superseded**` and add a new entry; don't rewrite the original. - **Filing in the wrong project.** PN bugs go to PN, Compute bugs to Compute, PPg bugs to PPg. If straddling, pick one and mention the second in the body — don't file in two. - **Skipping the version field.** The team uses `Version` to know which release to test against when triaging. Without it, the ticket sits. - **Setting priority on the ticket yourself.** That's the team's call during triage. Leave it alone. --- ## Optional: promote operational lessons into skills If your repo has operational skills that prescribe how to use one of the three products (e.g. `compute-deploy-nextjs`, `prisma-next-nextjs-app`, or anything similar), and your gotcha changes how someone *should* do the underlying task, also fold the prescriptive lesson into the matching skill — the gotcha is the *forensic* record (what bit us); the skill is the *prescriptive* record (how to avoid it). In product-team repos like `prisma-next-ws`, prescriptive skills for the team's own product often live elsewhere (developer docs, contributing guides, IDE rules). The principle is the same: where there's a durable prescriptive home for the lesson, cross-link from it back to the gotcha entry. --- Source attribution: prisma Original project: https://github.com/prisma/prisma-next/blob/55458c441d2cf452028c22eed21370447720840a/skills-contrib/record-gotcha/SKILL.md License: Apache-2.0 License information: https://www.apache.org/licenses/LICENSE-2.0 Original upstream instructions; downloaded from Mega AI Hub. ## Upstream license notice Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. "Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License. "Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. "Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. "Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution." "Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. END OF TERMS AND CONDITIONS APPENDIX: How to apply the Apache License to your work. To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets "[]" replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same "printed page" as the copyright notice for easier identification within third-party archives. Copyright [2026] [Prisma Data, Inc] Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. # Mega AI Hub resource metadata Creator / publisher: prisma Original project: https://github.com/prisma/prisma-next/blob/55458c441d2cf452028c22eed21370447720840a/skills-contrib/record-gotcha/SKILL.md Attribution basis: Source repository record Fields of work: Data & Analytics, Development & Engineering, Product Management Roles: Backend Developer, Data Analyst, Growth Product Manager, Product Manager, QA / Test Engineer Specialties: API, Database, DevOps, Word Documents, Frontend, React, Testing Tools: Linear, Gotchas Log Country applicability: Country not specified Classification basis: Source catalog labels Instruction SHA-256: 70eec734f782f963a7d55700e74fed7fb8de204f17361c01c3195218de44dc2c