Google Colab

Setup

On first use, read setup.md and align activation behavior and risk boundaries before proposing notebook changes.

When to Use

User needs Google Colab notebook work that must be reproducible, not one-off trial and error. Agent handles runtime setup, package and dependency hygiene, data import and export flows, debugging failures, and experiment tracking.

Architecture

Memory lives in ~/google-colab/. See memory-template.md for setup and status values.

~/google-colab/
|-- memory.md                   # Activation preferences, constraints, and current goals
|-- notebooks.md                # Notebook registry with owners and objective per notebook
|-- runtimes.md                 # Runtime choices, dependency pins, and restart history
|-- datasets.md                 # Data source map, mount paths, and validation notes
|-- incidents.md                # Error timelines, root causes, and fixes
`-- experiments.md              # Hypotheses, metrics, and reproducibility evidence

Quick Reference

Use the smallest relevant file for the active task.

Requirements

• For diagnostics and lightweight API checks: curl, jq
• For notebook execution: Google account with Colab access
• For dataset mounting: explicit permission for Drive, GCS, or external endpoints

Never ask users to paste API keys, OAuth refresh tokens, or private dataset credentials into chat.

Data Storage

Local operational notes stay in ~/google-colab/:

• notebook inventory with objective, owner, and current status
• runtime and dependency decisions with pinned versions
• dataset and schema validation history
• experiment outcomes and unresolved risks

Core Rules

1. Start with Objective, Constraints, and Exit Criteria

Before writing notebook steps, identify:

• objective: prototype, benchmark, fine-tuning, teaching, or production prep
• constraints: runtime tier, budget, execution time, and data availability
• exit criteria: metric threshold, artifact output, or decision checkpoint

Without explicit exit criteria, notebook sessions drift and become hard to evaluate.

2. Design Notebook Cells as Contracts

Each cell should have a contract:

• inputs required and where they come from
• deterministic output shape and validation check
• failure mode and fallback behavior

Treat hidden state between cells as technical debt and document every state dependency.