notebook-development

Stars0

Forks0

UpdatedJune 10, 2026 at 12:49

Write and organize production-grade notebooks across Fabric, Databricks, and Jupyter. Use for notebook cell structure, parameters, idempotency, platform utilities, validation cells, notebook-to-production conversion, and notebook hygiene.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

datacoolie

datacoolie/dekit

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	notebook-development
description	Write and organize production-grade notebooks across Fabric, Databricks, and Jupyter. Use for notebook cell structure, parameters, idempotency, platform utilities, validation cells, notebook-to-production conversion, and notebook hygiene.

Notebook Development

Use this skill when notebooks are the execution or exploration surface.

Structure

Title/purpose cell: what this notebook does and expected inputs/outputs.
Setup cell: imports, session config, helpers.
Parameters cell: environment, date/window, source/target names.
Load cells: read inputs with explicit schema/contract.
Transform cells: deterministic logic with no hidden UI state.
Validate cells: row counts, schema, quality checks, reconciliation.
Write cells: idempotent output behavior.

Rules

Notebook must run top-to-bottom after kernel restart.
Parameters must be injected, not edited inline for each run.
No credentials, secrets, or personal paths in cells.
Avoid global mutable state across cells.
Keep display/debug cells separate from production write path.
Extract reusable logic into modules when notebooks become production dependencies.

Platform Notes

Fabric/Databricks utilities are allowed at orchestration/I/O boundaries only.
Keep core transform logic portable where practical.
Use widgets/parameters for scheduled jobs.
Persist only intentional outputs; temporary views/tables need lifecycle cleanup.

Anti-Patterns

Out-of-order cell dependency.
Manual rerun instructions as operational process.
Hidden filters in exploratory cells reused for production.
Writing outputs before validation.
Notebook-only business logic used by multiple pipelines.

Verification

Before finishing notebook work:

Restart kernel/session and run all cells in order.
Verify parameters work for at least one representative run.
Confirm output idempotency.
Run validation cells and inspect failures.
Confirm scheduled/orchestrated execution path matches interactive path.

More from this repository

same repository

wiki

datacoolie/dekit

Build and maintain an internal technical LLM wiki when the user requests wiki work or a verified major or architectural change qualifies for automatic wiki review. Use for project memory, architecture notes, contracts, runbooks, decisions, glossary, incremental ingest, delta status, and wiki health. Do not use merely because a routine task or plan completed.

2026-07-180

brainstorm

datacoolie/dekit

Explore ambiguous ideas and solution directions before evidence-backed research or implementation planning. Use for ideation, framing, assumption checks, option generation, product or architecture trade-offs, and deciding whether research or a plan is needed.

2026-07-030

research

datacoolie/dekit

Research technical options with source-backed recommendations. Use for technology evaluation, architecture trade-offs, library/framework choices, best practices, scalability, security, maintainability, or when current external facts matter.

2026-07-030

plan

datacoolie/dekit

Create implementation plans, architecture decisions, and phased roadmaps. Use for Standard or Complex changes, new pipelines, schema changes, migrations, multi-file features, technology choices, or when acceptance criteria and verification strategy are unclear.

2026-06-170

code-review

datacoolie/dekit

Review code and data pipeline changes for correctness, security, performance, maintainability, contract breaks, and missing verification. Use before merge, after implementation, for PRs, commits, pending diffs, or codebase risk scans.

2026-06-100

data-ingestion

datacoolie/dekit

Design data ingestion into landing/bronze layers. Use for source onboarding, transfer pattern selection, full/incremental/CDC scope, change detection, landing zones, schema drift, idempotent file or batch processing, and ingestion quality gates.

2026-06-100

name	notebook-development
description	Write and organize production-grade notebooks across Fabric, Databricks, and Jupyter. Use for notebook cell structure, parameters, idempotency, platform utilities, validation cells, notebook-to-production conversion, and notebook hygiene.

Notebook Development

Use this skill when notebooks are the execution or exploration surface.

Structure

Title/purpose cell: what this notebook does and expected inputs/outputs.
Setup cell: imports, session config, helpers.
Parameters cell: environment, date/window, source/target names.
Load cells: read inputs with explicit schema/contract.
Transform cells: deterministic logic with no hidden UI state.
Validate cells: row counts, schema, quality checks, reconciliation.
Write cells: idempotent output behavior.

Rules

Notebook must run top-to-bottom after kernel restart.
Parameters must be injected, not edited inline for each run.
No credentials, secrets, or personal paths in cells.
Avoid global mutable state across cells.
Keep display/debug cells separate from production write path.
Extract reusable logic into modules when notebooks become production dependencies.

Platform Notes

Fabric/Databricks utilities are allowed at orchestration/I/O boundaries only.
Keep core transform logic portable where practical.
Use widgets/parameters for scheduled jobs.
Persist only intentional outputs; temporary views/tables need lifecycle cleanup.

Anti-Patterns

Out-of-order cell dependency.
Manual rerun instructions as operational process.
Hidden filters in exploratory cells reused for production.
Writing outputs before validation.
Notebook-only business logic used by multiple pipelines.

Verification

Before finishing notebook work:

Restart kernel/session and run all cells in order.
Verify parameters work for at least one representative run.
Confirm output idempotency.
Run validation cells and inspect failures.
Confirm scheduled/orchestrated execution path matches interactive path.