Omar SobhandClaude Opus 4.7
7b23f61632
Hand-authored skill catalog anchored to real 2026-07 versions:
- Rust 1.97.1 (stable), edition 2024
- React 19.2.7, Server Components + Actions
- TailwindCSS 4.3.3 (CSS-first config, Oxide engine)
- three.js r185 (WebGPURenderer stable, BatchedMesh matured)
- React Native 0.86 / Expo SDK 54+ (New Architecture default)
- cargo-nextest 0.9.140, gitleaks 8.20+, cargo-audit 0.21+
- Postgres 17 (18 in beta, don't rely on)
- CUDA Blackwell, Metal Apple7+, ROCm CDNA3
Ships 15 skills across the categories:
foundation/ workspace-repo-commit-protocol
small-focused-commits
tdd-red-green-refactor
code-review-checklist
int-xx-marker-protocol
decompose-int-items
rust/ write-rust-current-edition
rust-error-handling
cargo-test-driven-development
rust-async-tokio-idioms
backend/ postgres-migrations-forward-only
postgres-index-selection
api-pagination-day-1
frontend/ react-19-server-components
tailwind-v4-idioms
component-4-state-model
mobile/ expo-managed-vs-bare
rn-flashlist-perf
gpu/ gpu-coalescing-and-occupancy
roofline-model
threejs/ threejs-perf-and-teardown
security/ cargo-audit-workflow
secret-scanning-gitleaks
skills_loader.rs walks skills/**/*.md, parses YAML frontmatter
(name, description, when_to_use, tags), upserts via
skills_catalog::upsert_builtin. Idempotent per boot — bumps version
+ appends skill_versions row ONLY when body changes. Deterministic
sha256-derived ids so builtins are stable across boots.
Dockerfile copies skills/ to /etc/clawmates/skills. Server boot
task spawns loader alongside team_template_loader.
Follow-ups (Slice 3.5c continuation, future PRs):
- 20-30 more skills (duckdb, shadcn composition, a11y, WebGPU
migration, metal frame capture, rocprof, deep gitea forge
integration, semgrep rulepacks)
- Bind skills to team template roles (add [role.skills] refs to
templates/teams/*.toml + wire template_role_skills population
in team_template_loader)
Co-Authored-By: Claude Opus 4.7 <[email protected]>
2.9 KiB
2.9 KiB
name, description, when_to_use, tags
| name | description | when_to_use | tags | |||
|---|---|---|---|---|---|---|
| roofline-model | The roofline model — is your kernel compute-bound or memory-bound? Estimate arithmetic intensity before optimizing. | You're the arch_analyst or bench_engineer role sizing up a GPU kernel before or after implementation. |
|
The roofline model
Before you optimize anything, know which wall you're hitting.
The two rooflines
- Peak memory bandwidth — how many bytes/sec your GPU can pull from HBM.
- Peak compute — how many FLOPs/sec your GPU can execute.
Where they meet defines the ridge point (in FLOPs / byte). Kernels to the left of the ridge are memory-bound; to the right, compute-bound.
Reference numbers (2026)
| Device | Peak BW (TB/s) | Peak FP32 (TFLOP/s) | FP16/BF16 tensor | Ridge (FLOP/B, FP32) |
|---|---|---|---|---|
| NVIDIA B200 (Blackwell) | 8.0 | 80 | ~2200 tensor | ~10 |
| NVIDIA H100 | 3.35 | 67 | 989 tensor | ~20 |
| AMD MI300X (CDNA3) | 5.3 | 163 | ~2600 tensor | ~31 |
| Apple M3 Max | 0.4 | 14 | — | ~35 |
Rough figures — verify against the actual SKU. Ratios matter more than absolutes.
Arithmetic intensity
FLOPs performed per byte read from HBM. Compute it BEFORE writing the kernel:
GEMM (A: MxK, B: KxN, C: MxN, all FP32):
FLOPs = 2*M*N*K
Bytes = 4*(M*K + K*N + M*N) (naive, no tiling)
AI = 2*M*N*K / (4*(M*K + K*N + M*N))
For M=N=K=1024: AI ≈ 170 FLOP/B → compute-bound on H100
For M=N=1024, K=32: AI ≈ 15 FLOP/B → memory-bound on H100
What the diagnosis tells you
Memory-bound — DON'T optimize the math. Reduce bytes:
- Fuse kernels to keep data in registers/shared.
- Use lower precision (FP16/BF16/INT8) if numerics allow.
- Better tiling to reuse loaded data.
- Coalesce (see gpu-coalescing-and-occupancy).
Compute-bound — DON'T optimize the loads. Feed the ALU:
- Use tensor cores (Nvidia) / matrix cores (AMD) / AMX / metal Simd matrix ops.
- Instruction-level parallelism (multiple independent FMAs per thread).
- Higher occupancy is often COUNTERPRODUCTIVE — you want registers, not more threads.
Balanced (near the ridge) — hardest. Small changes tip you into one regime or the other. Profile OFTEN.
Reporting
Every kernel benchmark report includes:
Kernel: gemm_fp32_tiled
Achieved throughput: 52 TFLOP/s (78% of 67 TFLOP/s peak)
Achieved bandwidth: 280 GB/s (8% of 3.35 TB/s peak)
Arithmetic intensity: 180 FLOP/B
Regime: compute-bound
Bottleneck to attack: tensor core underutilization — WMMA fragment misaligned
Anti-patterns
- Optimizing math on a memory-bound kernel. Doubling FLOPs while DRAM saturates changes nothing.
- Micro-benchmarking without measuring HBM traffic. Wall clock alone can't tell you which regime you're in.
- Skipping roofline "because we already know it's slow". You don't know the CEILING until you plot it.