Menu
Rules for writing commit messages in the deep-cuts repository — subject line format, body content, scope naming, and what to omit
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Experimental protocol for Deep Cuts research, prototypes, model evaluations, threshold tuning, ablations, metric comparisons, and claims about accuracy or quality. Use before running or interpreting experiments so bots preserve train/validation/test boundaries, avoid leakage, compare against baselines, and report results honestly.
Guidelines for creating, updating, reorganizing, and reviewing Deep Cuts documentation in the project wiki, including page taxonomy, lifecycle status, protected pages, proposal handling, and link verification.
Pattern for multi-agent collaboration sessions in the deep-cuts fam — forge-first coordination over the botfam substrate (Gitea issues/PRs as the coordination plane, the unified `botfam wait` wake loop, bare-actor worktrees), with IRC opt-in for design sprints, plus session-log conventions
Draft, structure, and finalize a Deep Cuts blog-series post so it conforms to the post template, house voice, and cross-post link rules. Use when writing, drafting, assembling, or editing a "Deep Cuts" blog post (the rlupi.com series), preparing a post for publishing, or adding front matter to one. Covers the template, front matter schema, voice, agent crediting, and the link linter.
Checklist and guide for adding a new analysis pass to the trait-based modular pipeline
Safe pattern for adding SQLite schema migrations in the deep-cuts Rust/rusqlite_migration stack
| name | git-commits |
| description | Rules for writing commit messages in the deep-cuts repository — subject line format, body content, scope naming, and what to omit |
Every commit message is permanent project history. Write it for the person (or agent) reading git log six months from now, not for the person who just reviewed the diff.
Format: type(scope): imperative verb phrase
fix(ipc): route all Tauri imports through $lib/ipc
feat(analysis): add sleep prevention during pipeline run
docs(feedback): archive C1, F1a, F1b completed items
test(analysis): add pass invariant tests
Type signals the category of change:
| Type | When to use |
|---|---|
feat | New user-visible capability |
fix | Corrects a bug or wrong behavior |
refactor | Internal restructuring, no behavior change |
test | Adding or fixing tests only |
docs | Documentation only |
perf | Performance improvement |
tooling | Dev tools, scripts, lint |
chore | Deps, config, build — nothing a user sees |
Scope is the subsystem or domain: ipc, analysis, scanner, frontend, stores, db, css, skills, feedback, design. Keep it to one word. If you can't name the scope, the commit may contain multiple logical changes.
Verb is imperative, present tense: add, fix, replace, remove, extract, not added, fixes, replacing.
Length: subject under 72 characters. If you can't fit it, the commit is probably too large.
Include a body when the why is not obvious from the subject and diff. The diff already shows what changed — the body explains the decision, the problem, or the constraint.
fix(rust): replace silent filter_map(ok) with visible error handling
filter_map(|r| r.ok()) was swallowing SQLite row-mapping errors across
multiple query paths, making schema drift invisible at runtime. Each
call site now logs the error and the query continues — no behavior
change for callers, but failures are now observable in logs.
Good reasons to add a body:
Bad reasons to add a body:
When a commit implements a tracked item from the operations backlog, reference the item ID in the subject or body:
feat(ipc): add typed CommandMap with 86 commands (F1b)
fix(stores): make library.init() idempotent and add dispose() (F3)
This creates a navigable link between git log and doc/operations/.
The subject line is a forcing function. If you cannot write a single clear subject, the commit contains multiple logical changes and should be split.
A commit that touches the same concern in multiple files is fine (e.g. "fix(css): replace hardcoded colors with --sg-* tokens in 18 components"). A commit that touches two unrelated concerns in the same session should be two commits.
feat(analysis): add HDBSCAN structure clustering pass
fix(download): structured error events, spawn_blocking, group key validation
refactor(backend): modularize commands, extract repositories, decouple coordinators
test(analysis): add pass invariant tests for lifecycle, order, and reset
docs(architecture): add data flow and IPC domain map (D5)
tooling(skills): auto-inject skill table into agent instruction files
chore: add tools/ export scripts and models/ directory scaffold