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]>
46 lines
2.3 KiB
Markdown
46 lines
2.3 KiB
Markdown
---
|
|
name: small-focused-commits
|
|
description: Every commit does one thing, is understandable in isolation, and passes tests on its own. Bisectable-by-default policy.
|
|
when_to_use: Before every `git commit` — check that the commit is a single reviewable unit.
|
|
tags: [foundation, git, review]
|
|
---
|
|
|
|
# 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
|
|
|
|
1. **Can you describe the change in one sentence with no `and`?** If not, split.
|
|
2. **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).
|
|
3. **Would `git bisect` on this commit be meaningful?** If the commit combines a bug fix + a refactor, bisect can't isolate the bug — split.
|
|
4. **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 feature` in 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).
|