feat(skills): add style review workflow

src/skills/style/RULE-FORMAT.md

@@ -0,0 +1,17 @@
+# Rule format
+
+Use this structure for each rule:
+
+```md
+## Rule title
+
+### Rule
+
+State enforceable instructions.
+
+### Rationale
+
+Explain why the rule exists.
+```
+
+Add `### Examples` only when examples clarify the rule.

src/skills/style/STYLE.md

@@ -0,0 +1,21 @@
+# Style skill instructions
+
+Use this document for skills that own repository style conventions.
+
+## Load rules
+
+Read every Markdown file directly under `rules/` before applying the skill.
+Resolve `rules/` relative to the skill's `SKILL.md`.
+
+Finish when all discovered rule files have been read.
+
+## Apply rules
+
+Apply the loaded rules when editing or reviewing files covered by the skill.
+When loaded rules conflict, follow the most specific rule.
+
+
+## Maintain rules
+
+When adding or changing files under `rules/`, read `src/skills/style/RULE-FORMAT.md` first.
+Finish when the changed rule files follow that format.

src/skills/style/nix/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: nix-style
+description: Use when creating, editing, or reviewing Nix files in this repository.
+---
+
+# nix-style
+
+Use this skill as the source of truth for repository Nix conventions.
+Follow the shared style skill instructions in `src/skills/style/STYLE.md`.
+
+After editing Nix files, run:
+
+```bash
+nix run .#fix
+```
+
+Finish when `nix run .#fix` succeeds and the Nix change follows the loaded rules.
+If the command fails, report the failure.

src/skills/style/nix/rules/flake.md

@@ -0,0 +1,13 @@
+# Flake rules
+
+## Keep `flake.nix` as flake wiring
+
+### Rule
+
+Add flake inputs in `flake.nix`.
+Put new flake output implementation in `src/dotfiles/default.nix`.
+Use `flake.nix` to pass inputs into that implementation.
+
+### Rationale
+
+This keeps dependency declarations separate from output logic.

src/skills/style/nix/rules/let.md

@@ -0,0 +1,17 @@
+# Let rules
+
+## Prefer explicit dependencies over shared convenience bindings
+
+### Rule
+
+Do not add a `let` binding only to let sibling values share one expression.
+Apply this rule only when one sibling value clearly owns the concept.
+When one sibling value owns the concept, reference that sibling value directly.
+When a flake output owns the public value, reference that output through `self`.
+Do not make an output attrset recursive only to reference sibling outputs.
+Do not apply this rule when a binding names a local constant used to keep sibling assignments in sync.
+
+### Rationale
+
+Shared convenience bindings hide dependency direction.
+Explicit references show which value owns a concept and which value consumes it.

src/skills/style/rust/SKILL.md

@@ -0,0 +1,9 @@
+---
+name: rust-style
+description: Use when creating, editing, or reviewing Rust files in this repository.
+---
+
+# rust-style
+
+Use this skill as the source of truth for repository Rust conventions.
+Follow the shared style skill instructions in `src/skills/style/STYLE.md`.

src/skills/style/rust/rules/build.md

@@ -0,0 +1,39 @@
+# Build rules
+
+## Use workspace dependency versions
+
+### Rule
+
+Declare Rust dependency versions in the repository root `Cargo.toml` under `[workspace.dependencies]`.
+Reference workspace dependencies from package `Cargo.toml` files with `workspace = true`.
+Do not declare dependency versions in package `Cargo.toml` files unless the operator explicitly requests a package-local version.
+Add package-local dependency features only when the feature set is specific to that package.
+
+### Rationale
+
+The repository has one Cargo workspace and one `Cargo.lock`.
+Centralized dependency versions keep package manifests consistent with the workspace lockfile.
+
+## Declare Rust tests in Bazel
+
+### Rule
+
+Declare Rust test files in the nearest Bazel `BUILD` file with `rust_test`.
+Do not add `[[test]]` entries to `Cargo.toml` unless the operator explicitly requests Cargo test declarations.
+
+### Rationale
+
+Bazel is the source of truth for Rust test targets in this repository.
+Keeping test declarations in Bazel avoids duplicate test target lists.
+
+## Use one source input style per `rust_test`
+
+### Rule
+
+Do not set both `crate` and `srcs` on a `rust_test` target.
+Use exactly one input style for each Rust test target.
+
+### Rationale
+
+`rules_rust` rejects `rust_test` targets that set both `crate` and `srcs`.
+Keeping one input style per target makes the test declaration valid and unambiguous.

src/skills/style/rust/rules/files.md

@@ -0,0 +1,28 @@
+# File rules
+
+## Avoid generic Rust file names
+
+### Rule
+
+Do not name Rust source files `lib.rs` or `main.rs`.
+Name library crate root files after the crate they define.
+Name binary crate root files after the binary they define, or use a `_main.rs` suffix.
+Set explicit Cargo paths and Bazel `srcs` when needed.
+
+### Rationale
+
+Generic root names make file search results and review context less clear.
+Descriptive file names show which crate or binary owns the code.
+
+## Keep Rust tests in separate files
+
+### Rule
+
+Put Rust tests in separate `*_test.rs` files.
+Name each test file after the Rust source file or crate root that it tests.
+Do not use generic test file names such as `lib_test.rs` or `main_test.rs`.
+Do not add inline `#[cfg(test)]` modules.
+
+### Rationale
+
+Separate test files keep production modules focused and match the repository's Bazel test layout.