TBD by igalklebanov · Pull Request #93 · prisma/prisma-next

igalklebanov · 2026-01-05T23:33:43Z

Hey 👋

This PR consolidates per-package TypeScript configuration into a single tsconfig.json that handles declaration and decleration map generation AND IDE DX. Tests get a separate nested tsconfig.json.

package.json scripts for build and typecheck are now simpler since they don't require passing custom config paths - the default behavior of each CLI is equivalent now.

coderabbitai · 2026-01-05T23:33:52Z

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

... ...

Slice 9 of the build phase. Atomic-tier augmentations layered onto existing skills rather than new skills. - drive-create-project: add a project-DoR check after directory scaffolding. Walks the canonical DoR items (purpose statement; scope boundary sketch; operator availability; external dependencies known; Linear Project). Refuses handoff to drive-project-specify if any DoR item fails — gaps surface to operator. Also adds a "bootstrap project- context surfaces" step that invokes drive-bootstrap-context (PR #93) to seed any missing drive/<category>/README.md files. Adds a promote-ceremony specifics section for mid-flight slice→project invocations (migrate in-flight slice content into projects/<project>/ spec.md as the starting point). Handoff updated to reference the new split skills (drive-project-specify / drive-project-plan) rather than the deprecated drive-create-spec / drive-create-plan. - drive-pr-description: add direct-change mode. The full mode (the existing body — overview / changes / why) stays the default. Direct- change mode is a new section for PRs routed by drive-start-workflow as direct change (~30-second-verifiable diffs). Direct-change template: intent statement / Linear link / scope statement / verification note. Includes a sanity-check step (if the diff isn't direct-change-shaped, escalate back to drive-triage-work for re-routing — direct-change is a scope claim and the diff is the test). Anti-patterns documented (multi-paragraph Why, tests that need explaining, > 3 files, feature flags) — each implies a slice not a direct change. (drive-discussion was augmented in slice 3 and isn't touched here despite the slice 9 description mentioning it; keeping this commit focused on the two atomic augmentations remaining.) Refs: TML-2549

…scope DoD previously lumped CI gates and intent-validation under a single "validation gates" category, leaving manual QA implicit. Per PR #93 (prisma/ignite), drive-qa-plan and drive-qa-run are the canonical manual-QA discipline; the gate they enforce closes a class of gaps neither CI nor intent-validation can reach (diagnostic clarity, end-to-end developer journey, original-bug re-enactment, gate-of-gate sanity, exploratory probing). Add a "Three gates" framing section, slice-DoD + project-DoD items requiring a drive-qa-plan script + drive-qa-run report whenever the change touches user-observable surface (or explicit N/A for pure-refactor slices), updated templates, broadened anti-pattern #2 from "validation-gates only" to "CI-gates only", and reference drive-qa-plan / drive-qa-run / drive/qa/README.md in the Related principles section. Assumes PR #93 as base.

…e PR #93 Previous version opened with an "Option A scope" jargon callout and buried the restructure under per-skill verdicts the reader had to assemble in their head. Reviewers told us it was impossible to read. Rewrite to lead with the workflow-to-skill map: for every Drive workflow activity, name the skill that drives it, its scope, and its status under the restructure (one of stays / augmented / split / new / from PR #93). Drop "Option A" framing entirely (the per-PR skill-body drafting is just normal canonical-side work; it doesn't need a label). Add a Base Assumption section that makes the PR #93 dependency explicit (project-context convention + drive-qa-plan / drive-qa-run + the meta-skills) and folds those skills into the workflow map. Recap the naming convention from prisma/ignite skills/README.md honestly: there is no rigid <noun>-<verb> rule, just consistency with two dominant shapes. Update README.md to link the now-landed principle docs (no more "(upcoming)"), note PR #93 as the assumed-landed base, and add the stack-on-PR-#93 bullet to the restructure summary.

…trate docs Workflow.md gains two rows (drive-qa-plan + drive-qa-run as slice-review-phase activities) and a "reading the map" point naming manual QA as the judgement layer. Model.md persistence-shape table gains rows for manual-QA script, manual-QA run report, and the per-consumer-repo drive/<category>/README.md context convention introduced by PR #93. Calibration/prisma-next.md grows a new section 9 ("Manual-QA context") that authors the prisma-next-side content for drive/qa/README.md (consumer audiences, substrate locations, known coverage-gate gaps, script/report locations, when N/A is honest); slice + project DoD overlays gain matching QA checklist items.

… DoD gate) D21 codifies the choice to treat prisma/ignite#93 (the drive-context-convention work + drive-qa-plan / drive-qa-run + the meta-skills) as the assumed-landed base for every canonical-side PR proposed in skill-restructure.md, so DoR / DoD / model / workflow docs can reference its surface as already-existing rather than reinventing it. D22 codifies the split of validation gates into three categories (CI gates, intent-validation, manual QA) and the slice-DoD + project-DoD requirement that manual QA fires whenever a slice touches user-observable surface (or is explicitly marked N/A with rationale).

…ject-context separation; drop remaining "pickable" uses PR #93 introduces a structural separation between portable methodology (canonical drive-* skill bodies in prisma/ignite) and team-specific protocol (drive/<category>/README.md in each consumer repo, read by drive-* skills as workflow step 1). The principle docs talked about the general/calibration split in the abstract (D10) but did not reflect that the project-calibration layer now has a concrete on-disk home with strong memory properties, nor that drive-reconcile-skills + drive-update-skills make the loop between the two homes operational. Rewrite protocol-as-memory.md around the two homes and the reconciliation loop, and slot drive/<category>/README.md into the memory-strength tier table as a strong surface (loaded by the matching skill at workflow step 1, every invocation). Restructure retro.md mandatory-output around canonical / project- context / ADR, name the home-selection heuristic, and land the worked example in drive/plan/README.md instead of a generic calibration doc. Update DoR + DoD "How calibration overlays the protocol" sections to name the destination drive/<category>/README.md for every overlay class. Have brief-discipline name drive/plan/README.md as the canonical home for the failure-mode catalogue + grep library + reference tasks + model-tier routing (the assets brief assembly threads). Open the calibration worked-example with a section-by- section mapping table to destination READMEs. Record D23 codifying the commitment. While here, finish dropping "pickable" — the awkward Agile coinage the user flagged: remove its synonym treatment from definition-of-ready.md, replace the protocol-as-memory.md occurrence with "ready to start", and rename the "Pickable-looking-but-not" failure mode in DoR to "Ready-looking-but-not".

Captures the two failure modes (fuzzy units + unbounded agent dispatches) with evidence (prisma-next Linear-sync rejection; target-extensible-ir dispatch drift), states the proposed design in plain language, and names the canonical-side skill restructure. Self-contained so it can be shared without preloading the spec or the conversation history. References PR #93 as the assumed-landed base.

Strip the duplicated motivation/relationship-with-existing-skills content that belonged in spec.md and problem-statement.md. New shape: - At a glance: one paragraph stating what we are pinning + threading, with a pointer to problem-statement.md for external sharing. - Status. - Where to start: a six-row table that routes each reader (canonical maintainer / design validator / vocabulary lookup / skill restructurer / new-repo adopter / decision archaeologist) to the right doc with one-line why. - Base assumption (PR #93) named explicitly with what it ships. - Repository layout (ASCII tree). - Out of scope (top three). Drops 50+ lines that were spec-duplication.

Slice 9 of the build phase. Atomic-tier augmentations layered onto existing skills rather than new skills. - drive-create-project: add a project-DoR check after directory scaffolding. Walks the canonical DoR items (purpose statement; scope boundary sketch; operator availability; external dependencies known; Linear Project). Refuses handoff to drive-project-specify if any DoR item fails — gaps surface to operator. Also adds a "bootstrap project- context surfaces" step that invokes drive-bootstrap-context (PR #93) to seed any missing drive/<category>/README.md files. Adds a promote-ceremony specifics section for mid-flight slice→project invocations (migrate in-flight slice content into projects/<project>/ spec.md as the starting point). Handoff updated to reference the new split skills (drive-project-specify / drive-project-plan) rather than the deprecated drive-create-spec / drive-create-plan. - drive-pr-description: add direct-change mode. The full mode (the existing body — overview / changes / why) stays the default. Direct- change mode is a new section for PRs routed by drive-start-workflow as direct change (~30-second-verifiable diffs). Direct-change template: intent statement / Linear link / scope statement / verification note. Includes a sanity-check step (if the diff isn't direct-change-shaped, escalate back to drive-triage-work for re-routing — direct-change is a scope claim and the diff is the test). Anti-patterns documented (multi-paragraph Why, tests that need explaining, > 3 files, feature flags) — each implies a slice not a direct change. (drive-discussion was augmented in slice 3 and isn't touched here despite the slice 9 description mentioning it; keeping this commit focused on the two atomic augmentations remaining.) Refs: TML-2549

…scope DoD previously lumped CI gates and intent-validation under a single "validation gates" category, leaving manual QA implicit. Per PR #93 (prisma/ignite), drive-qa-plan and drive-qa-run are the canonical manual-QA discipline; the gate they enforce closes a class of gaps neither CI nor intent-validation can reach (diagnostic clarity, end-to-end developer journey, original-bug re-enactment, gate-of-gate sanity, exploratory probing). Add a "Three gates" framing section, slice-DoD + project-DoD items requiring a drive-qa-plan script + drive-qa-run report whenever the change touches user-observable surface (or explicit N/A for pure-refactor slices), updated templates, broadened anti-pattern #2 from "validation-gates only" to "CI-gates only", and reference drive-qa-plan / drive-qa-run / drive/qa/README.md in the Related principles section. Assumes PR #93 as base. Signed-off-by: Will Madden <madden@prisma.io>

…e PR #93 Previous version opened with an "Option A scope" jargon callout and buried the restructure under per-skill verdicts the reader had to assemble in their head. Reviewers told us it was impossible to read. Rewrite to lead with the workflow-to-skill map: for every Drive workflow activity, name the skill that drives it, its scope, and its status under the restructure (one of stays / augmented / split / new / from PR #93). Drop "Option A" framing entirely (the per-PR skill-body drafting is just normal canonical-side work; it doesn't need a label). Add a Base Assumption section that makes the PR #93 dependency explicit (project-context convention + drive-qa-plan / drive-qa-run + the meta-skills) and folds those skills into the workflow map. Recap the naming convention from prisma/ignite skills/README.md honestly: there is no rigid <noun>-<verb> rule, just consistency with two dominant shapes. Update README.md to link the now-landed principle docs (no more "(upcoming)"), note PR #93 as the assumed-landed base, and add the stack-on-PR-#93 bullet to the restructure summary. Signed-off-by: Will Madden <madden@prisma.io>

…trate docs Workflow.md gains two rows (drive-qa-plan + drive-qa-run as slice-review-phase activities) and a "reading the map" point naming manual QA as the judgement layer. Model.md persistence-shape table gains rows for manual-QA script, manual-QA run report, and the per-consumer-repo drive/<category>/README.md context convention introduced by PR #93. Calibration/prisma-next.md grows a new section 9 ("Manual-QA context") that authors the prisma-next-side content for drive/qa/README.md (consumer audiences, substrate locations, known coverage-gate gaps, script/report locations, when N/A is honest); slice + project DoD overlays gain matching QA checklist items. Signed-off-by: Will Madden <madden@prisma.io>

… DoD gate) D21 codifies the choice to treat prisma/ignite#93 (the drive-context-convention work + drive-qa-plan / drive-qa-run + the meta-skills) as the assumed-landed base for every canonical-side PR proposed in skill-restructure.md, so DoR / DoD / model / workflow docs can reference its surface as already-existing rather than reinventing it. D22 codifies the split of validation gates into three categories (CI gates, intent-validation, manual QA) and the slice-DoD + project-DoD requirement that manual QA fires whenever a slice touches user-observable surface (or is explicitly marked N/A with rationale). Signed-off-by: Will Madden <madden@prisma.io>

…ject-context separation; drop remaining "pickable" uses PR #93 introduces a structural separation between portable methodology (canonical drive-* skill bodies in prisma/ignite) and team-specific protocol (drive/<category>/README.md in each consumer repo, read by drive-* skills as workflow step 1). The principle docs talked about the general/calibration split in the abstract (D10) but did not reflect that the project-calibration layer now has a concrete on-disk home with strong memory properties, nor that drive-reconcile-skills + drive-update-skills make the loop between the two homes operational. Rewrite protocol-as-memory.md around the two homes and the reconciliation loop, and slot drive/<category>/README.md into the memory-strength tier table as a strong surface (loaded by the matching skill at workflow step 1, every invocation). Restructure retro.md mandatory-output around canonical / project- context / ADR, name the home-selection heuristic, and land the worked example in drive/plan/README.md instead of a generic calibration doc. Update DoR + DoD "How calibration overlays the protocol" sections to name the destination drive/<category>/README.md for every overlay class. Have brief-discipline name drive/plan/README.md as the canonical home for the failure-mode catalogue + grep library + reference tasks + model-tier routing (the assets brief assembly threads). Open the calibration worked-example with a section-by- section mapping table to destination READMEs. Record D23 codifying the commitment. While here, finish dropping "pickable" — the awkward Agile coinage the user flagged: remove its synonym treatment from definition-of-ready.md, replace the protocol-as-memory.md occurrence with "ready to start", and rename the "Pickable-looking-but-not" failure mode in DoR to "Ready-looking-but-not". Signed-off-by: Will Madden <madden@prisma.io>

Captures the two failure modes (fuzzy units + unbounded agent dispatches) with evidence (prisma-next Linear-sync rejection; target-extensible-ir dispatch drift), states the proposed design in plain language, and names the canonical-side skill restructure. Self-contained so it can be shared without preloading the spec or the conversation history. References PR #93 as the assumed-landed base. Signed-off-by: Will Madden <madden@prisma.io>

Strip the duplicated motivation/relationship-with-existing-skills content that belonged in spec.md and problem-statement.md. New shape: - At a glance: one paragraph stating what we are pinning + threading, with a pointer to problem-statement.md for external sharing. - Status. - Where to start: a six-row table that routes each reader (canonical maintainer / design validator / vocabulary lookup / skill restructurer / new-repo adopter / decision archaeologist) to the right doc with one-line why. - Base assumption (PR #93) named explicitly with what it ships. - Repository layout (ASCII tree). - Out of scope (top three). Drops 50+ lines that were spec-duplication. Signed-off-by: Will Madden <madden@prisma.io>

Slice 9 of the build phase. Atomic-tier augmentations layered onto existing skills rather than new skills. - drive-create-project: add a project-DoR check after directory scaffolding. Walks the canonical DoR items (purpose statement; scope boundary sketch; operator availability; external dependencies known; Linear Project). Refuses handoff to drive-project-specify if any DoR item fails — gaps surface to operator. Also adds a "bootstrap project- context surfaces" step that invokes drive-bootstrap-context (PR #93) to seed any missing drive/<category>/README.md files. Adds a promote-ceremony specifics section for mid-flight slice→project invocations (migrate in-flight slice content into projects/<project>/ spec.md as the starting point). Handoff updated to reference the new split skills (drive-project-specify / drive-project-plan) rather than the deprecated drive-create-spec / drive-create-plan. - drive-pr-description: add direct-change mode. The full mode (the existing body — overview / changes / why) stays the default. Direct- change mode is a new section for PRs routed by drive-start-workflow as direct change (~30-second-verifiable diffs). Direct-change template: intent statement / Linear link / scope statement / verification note. Includes a sanity-check step (if the diff isn't direct-change-shaped, escalate back to drive-triage-work for re-routing — direct-change is a scope claim and the diff is the test). Anti-patterns documented (multi-paragraph Why, tests that need explaining, > 3 files, feature flags) — each implies a slice not a direct change. (drive-discussion was augmented in slice 3 and isn't touched here despite the slice 9 description mentioning it; keeping this commit focused on the two atomic augmentations remaining.) Refs: TML-2549 Signed-off-by: Will Madden <madden@prisma.io>

…-update-skills from ignite #93 Brings in the three mechanism skills that operationalise the drive/ context convention. Aligned to our skill conventions (frontmatter format with multi-line description + metadata.version; cross-reference paths; naming per D28). The substantive divergence from ignite is the new "Canonical-source resolution" section in each skill, which makes the trial-period story explicit: - During the prisma-next trial period (until first upstream PR to ignite), no external canonical exists. reconcile + update refuse with a pointer at the resolution table; bootstrap operates as normal (reads templates from this skill's local sibling). - Post-upstream, canonical = ignite (consumers fetch via npx skills). - Consumer projects that pull from prisma-next get a third "canonical = prisma-next/skills-contrib" entry. Templates ship with the bootstrap skill: 8 from ignite + 3 added for categories we seeded that ignite hasn't (triage, retro, health). The new templates mirror the structure of the existing seeded READMEs as placeholder skeletons. Signed-off-by: Will Madden <madden@prisma.io>

…oice Slice B applies the rewrite-at-migration and soften-at-migration dispositions from drive-close-project step 4.5 to the docs/drive/ files that survived Slice A. Each file kept its methodology core and lost its project-execution framing. workflow.md -- rewrite-at-migration: - Drops the "Bold = new (this project adds it); plain = exists today; italic = augmented" legend from the lifecycle table header. Bold treatment removed from every row; reads as steady-state methodology. - Skill-surface section rewritten: was a "what changed" inventory organised as new / split / augmented / promoted; now an organised-by-purpose list of the canonical drive-* skill set. Both tiers (workflow + atomic) covered without the change-tracking framing. - Reading guide drops the "what is new versus existing" link. - "Status: living document; updates here are load-bearing for every other doc in this project" footer dropped. model.md -- rewrite-at-migration + soften-at-migration: - "Implications for existing canonical Drive" + "Atomic skills that split / stay / new" subsections (project-restructure framing) rewritten as a single "Skill set" section: Workflow skills table + Atomic skills table organised by purpose. No "new vs existing," no "splits into," no "renamed from." - "Open questions" block dropped (it was a closed-questions trail from project shaping -- OQ1/OQ5/OQ6/OQ10 -- with no methodology role going forward; the questions are resolved by the model itself). - "Linear sync" section generalised to "Tracker sync" using generic tracker vocabulary (tracker project / tracker issue / etc.) with Linear / Jira / GitHub Issues listed as worked examples in the bounded-contexts diagram. MCP tool names (save_project, update_issue) replaced with generic verbs ("create a tracker project", "move the ticket"). Tracker-specific concretes belong in project context (drive/project/, drive/triage/, drive/pr/). - At-a-glance summary + bounded-contexts diagram + Triage section + Aggregate-roots section + Triage decision tree all updated to say "tracker" rather than "Linear" where the reference is to the abstract concept; Linear remains as a named worked example. - Persistence-shape table drops the inline PR #93 attributions on Manual-QA + project-context rows (the skill is now first-class; its own SKILL.md is the source). principles/brief-discipline.md, definition-of-ready.md, definition-of-done.md -- soften-at-migration: - Replaces StorageTable / flat-shape / packages/2-sql / 2026-05-17 anchors with generic "legacy-shape" + "data-shape migration" + "<date>" placeholders. The example shape (three-round migration, spike-then-implement, programmatic-grep-route-around catch) is preserved; the project-specific names are not. principles/decomposition-and-cost.md -- soften-at-migration: - Two t-shirt-sizing table rows had StorageTable / ForeignKeyReference as worked examples; generalised to "substrate type that affects every IR consumer" / "two adjacent substrate types" without losing the sizing intuition. principles/retro.md -- soften-at-migration: - The "retro that actually happened" example is preserved in shape (dispatch-failure retro, intent-validation catch, programmatic-grep route-around, output lands in drive/plan/README.md) but the specific date, the StorageTable name, the Object.fromEntries constructor, and the "prisma-next-specific" attribution are generalised away. Reads as a representative retro a fresh team can follow. principles/protocol-as-memory.md, retro.md, spikes.md -- non-portable-conventions cleanup: - References to the wip/ convention replaced with "operator scratch (untracked working notes, draft files outside the tracked tree)". The concept (no-memory surface for transient scratch) is preserved; the prisma-next-specific wip/ path is not. skills-contrib/drive-start-workflow/SKILL.md -- mechanical: - Two section references that pointed at model.md § Linear sync re-pointed at model.md § Tracker sync to match the rename. Linked issue: TML-2549. Linked finding: drive/project/findings.md 2026-05-19. Signed-off-by: Will Madden <madden@prisma.io>