tinygrad
Skill28 starsChanged 8 months agoMITView on GitHub
Deep learning framework development with tinygrad - a minimal tensor library with autograd, JIT compilation, and multi-device support. Use when writing neural networks, training models, implementing tensor operations, working with UOps/PatternMatcher for graph transformations, or contributing to tinygrad internals. Triggers on tinygrad imports, Tensor operations, nn modules, optimizer usage, schedule/codegen work, or device backends.
In this repository25 other files it gives its agents.
- agent-integration-testingSkill
- annealSkill
- article-factorySkill
- autoresearchSkill
- boost-modulesSkill
- bugbashSkill
- bughuntSkill
- catalog-deslopSkill
- disciplineSkill
- factual-communicationSkill
- ideateSkill
- improve-skillSkill
- make-videoSkill
- mosaic-writingSkill
- preact-buildless-frontendSkill
- pull-llamacpp-modelSkill
- run-llmsSkill
- sandcastleSkill
- superclaudeSkill
- timeboxed-iteratingSkill
- timeframe-researchSkill
- turso-dbSkill
- use-coding-agentsSkill
- workgraphSkill
- workmachineSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 158
Prefer readability over cleverness
- Distinctive: line 159
Never mix functionality changes with whitespace changes
- Distinctive: line 160
All functionality changes must be tested
- Very specific: line 161
Run pre-commit run --all-files before commits
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
tinygrad
A minimal deep learning framework focused on beauty and minimalism. Every line must earn its keep.
Quick Reference
from tinygrad import Tensor, TinyJit, nn, dtypes, Device, GlobalCounters
# Tensor creation
x = Tensor([1, 2, 3])
x = Tensor.rand(2, 3)
x = Tensor.kaiming_uniform(128, 784)
# Operations are lazy until realized
y = (x + 1).relu().sum()
y.realize() # or y.numpy()
# Training context
with Tensor.train():
loss = model(x).sparse_categorical_crossentropy(labels).backward()
optim.step()Architecture Pipeline
- Tensor (
tinygrad/tensor.py) - User API, creates UOp graph - UOp (
tinygrad/uop/ops.py) - Unified IR for all operations - Schedule (
tinygrad/engine/schedule.py) - Converts tensor UOps to kernel UOps - Codegen (
tinygrad/codegen/) - Converts kernel UOps to device code - Runtime (
tinygrad/runtime/) - Device-specific execution
Training Loop Pattern
from tinygrad import Tensor, TinyJit, nn
from tinygrad.nn.datasets import mnist
X_train, Y_train, X_test, Y_test = mnist()
model = Model()
optim = nn.optim.Adam(nn.state.get_parameters(model))
@TinyJit
@Tensor.train()
def train_step():
optim.zero_grad()
samples = Tensor.randint(512, high=X_train.shape[0])
loss = model(X_train[samples]).sparse_categorical_crossentropy(Y_train[samples]).backward()
return loss.realize(*optim.schedule_step())
for i in range(100):
loss = train_step()Model Definition
Models are plain Python classes with __call__. No base class required.
class Model:
def __init__(self):
self.l1 = nn.Linear(784, 128)
self.l2 = nn.Linear(128, 10)
def __call__(self, x):
return self.l1(x).relu().sequential([self.l2])Available nn modules: Linear, Conv2d, BatchNorm, LayerNorm, RMSNorm, Embedding, GroupNorm, LSTMCell
Optimizers: SGD, Adam, AdamW, LARS, LAMB, Muon
State Dict / Weights
from tinygrad.nn.state import safe_save, safe_load, get_state_dict, load_state_dict, get_parameters
# Save/load safetensors
safe_save(get_state_dict(model), "model.safetensors")
load_state_dict(model, safe_load("model.safetensors"))
# Get all trainable params
params = get_parameters(model)JIT Compilation
TinyJit captures and replays kernel graphs. Input shapes must be fixed.
@TinyJit
def forward(x):
return model(x).realize()
# First call captures, subsequent calls replay
out = forward(batch)Device Management
from tinygrad import Device
print(Device.DEFAULT) # Auto-detected: METAL, CUDA, AMD, CPU, etc.
# Force device
x = Tensor.rand(10, device="CPU")
x = x.to("CUDA")Environment Variables
| Variable | Values | Description |
DEBUG | 1-7 | Increasing verbosity (4=code, 7=asm) |
VIZ | 1 | Graph visualization |
BEAM | # | Kernel beam search width |
NOOPT | 1 | Disable optimizations |
SPEC | 1-2 | UOp spec verification |
Debugging
# Visualize computation graph
VIZ=1 python -c "from tinygrad import Tensor; Tensor.ones(10).sum().realize()"
# Show generated code
DEBUG=4 python script.py
# Run tests
python -m pytest test/test_tensor.py -xvsUOp and PatternMatcher (Internals)
UOps are immutable, cached graph nodes. Use PatternMatcher for transformations:
from tinygrad.uop.ops import UOp, Ops
from tinygrad.uop.upat import UPat, PatternMatcher, graph_rewrite
pm = PatternMatcher([
(UPat(Ops.ADD, src=(UPat.cvar("x"), UPat.cvar("x"))), lambda x: x * 2),
])
result = graph_rewrite(uop, pm)Key UOp properties: op, dtype, src, arg, tag
Define PatternMatchers at module level - they're slow to construct.
Style Guide
- 2-space indentation, 150 char line limit
- Prefer readability over cleverness
- Never mix functionality changes with whitespace changes
- All functionality changes must be tested
- Run
pre-commit run --all-filesbefore commits
Testing
python -m pytest test/test_tensor.py -xvs
python -m pytest test/unit/test_schedule_cache.py -x --timeout=60
SPEC=2 python -m pytest test/test_something.py # With spec verificationDoes it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

