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.3 KiB
2.3 KiB
name, description, when_to_use, tags
| name | description | when_to_use | tags | |||
|---|---|---|---|---|---|---|
| small-focused-commits | Every commit does one thing, is understandable in isolation, and passes tests on its own. Bisectable-by-default policy. | Before every `git commit` — check that the commit is a single reviewable unit. |
|
Small, focused commits
A commit's job is to make ONE change that a reviewer can hold in their head, that CI can green, and that git bisect can meaningfully cross.
Test yourself before you commit
- Can you describe the change in one sentence with no
and? If not, split. - Does the diff exceed ~300 lines net, excluding generated/mechanical? If yes, split unless every line is genuinely part of the same idea (renaming a symbol across a codebase counts).
- Would
git bisecton this commit be meaningful? If the commit combines a bug fix + a refactor, bisect can't isolate the bug — split. - Does the commit compile + tests pass on its own? If no, you're building a broken bisect landscape — reorder or squash so every commit is green.
Splitting patterns
- Mechanical then semantic — rename first, behavior second. Two commits, each trivially reviewable.
- Add then use — introduce the new abstraction as an unused module first, then wire callers in a follow-up. Reviewers can validate the shape before opining on integration.
- Refactor then feature — never
refactor + add featurein one commit. It hides what the feature actually cost. - Test then implementation — TDD writes the test first; commit the failing test, then the passing impl (see tdd-red-green-refactor).
What a good commit message looks like
<INT-NN> <imperative one-liner, ≤72 chars>
<paragraph explaining WHY the change is needed; what problem it solves;
what alternatives were considered and why they were rejected>
<optional: performance/security notes, migration guidance, follow-ups>
Refs: INT-NN
The subject is what shows up in git log --oneline. Make it stand alone.
Anti-patterns
wip/fix/update stuff— never merge these; if that's what you have locally, squash before push.- One commit per file — commits are about ideas, not filesystem layout.
- 40-line commit that touches 22 files — probably a rename that should be its own commit (see above).