docs(dev/guide): de-duplicate import-granularity guidance

Now that `perfectionist::import_granularity` (`style = "module"`)
enforces import merging automatically, the prose that described how to
merge imports merely restated the rule. Apply the same treatment the
earlier `perfectionist` upgrade gave to derive ordering: drop the
redundant import bullet from the AI instruction quick reference, and
reframe the CONTRIBUTING.md section to lead with automatic enforcement,
keeping only the hand-applied convention for platform-gated import
blocks.

https://claude.ai/code/session_01CMrfXtuzxpSbchSJNuwboK

Author: claude

.github/copilot-instructions.md

@@ -7,7 +7,6 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c
 - Commit format: Conventional Commits. Pattern: `type(scope): lowercase description`. The scope is optional.
 - Version releases are the only exception. The commit message is just the version number, such as `0.21.1`.
 - Write documentation, comments, and other prose for ease of understanding first. Prefer a formal tone when it does not hurt clarity, and use complete sentences. Avoid mid-sentence breaks introduced by em dashes or long parenthetical clauses. Em dashes are a reliable symptom of loose phrasing; when one appears, restructure the surrounding sentence so each clause stands on its own rather than swapping the em dash for another punctuation mark.
-- Prefer imports merged per module. Combine items from the same module into a single `use` statement, but write a separate `use` statement for each module rather than collapsing every path from a crate into one nested-braces statement.
 - Use descriptive names for generics, such as `Size` and `Report`. Do not use single letters.
 - Use descriptive names for variables and closure parameters. Single letters are permitted only in these cases: (1) conventional names like `n` for count or `f` for formatter; (2) comparison closures like `|a, b|`; (3) trivial single-expression closures; (4) fold accumulators; and (5) index variables `i`/`j`/`k` in short closures or index-based loops. Single letters are never permitted in `let` bindings, including test fixtures, nor in multi-line functions or closures.
 - Use `pipe-trait` to chain through unary functions such as constructors, `Some`, `Ok`, and free functions. Use it to flatten nested calls and to continue method chains. Do not use it for simple standalone calls; prefer `foo(value)` over `value.pipe(foo)`.

AGENTS.md

@@ -7,7 +7,6 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c
 - Commit format: Conventional Commits. Pattern: `type(scope): lowercase description`. The scope is optional.
 - Version releases are the only exception. The commit message is just the version number, such as `0.21.1`.
 - Write documentation, comments, and other prose for ease of understanding first. Prefer a formal tone when it does not hurt clarity, and use complete sentences. Avoid mid-sentence breaks introduced by em dashes or long parenthetical clauses. Em dashes are a reliable symptom of loose phrasing; when one appears, restructure the surrounding sentence so each clause stands on its own rather than swapping the em dash for another punctuation mark.
-- Prefer imports merged per module. Combine items from the same module into a single `use` statement, but write a separate `use` statement for each module rather than collapsing every path from a crate into one nested-braces statement.
 - Use descriptive names for generics, such as `Size` and `Report`. Do not use single letters.
 - Use descriptive names for variables and closure parameters. Single letters are permitted only in these cases: (1) conventional names like `n` for count or `f` for formatter; (2) comparison closures like `|a, b|`; (3) trivial single-expression closures; (4) fold accumulators; and (5) index variables `i`/`j`/`k` in short closures or index-based loops. Single letters are never permitted in `let` bindings, including test fixtures, nor in multi-line functions or closures.
 - Use `pipe-trait` to chain through unary functions such as constructors, `Some`, `Ok`, and free functions. Use it to flatten nested calls and to continue method chains. Do not use it for simple standalone calls; prefer `foo(value)` over `value.pipe(foo)`.

CLAUDE.md

@@ -7,7 +7,6 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c
 - Commit format: Conventional Commits. Pattern: `type(scope): lowercase description`. The scope is optional.
 - Version releases are the only exception. The commit message is just the version number, such as `0.21.1`.
 - Write documentation, comments, and other prose for ease of understanding first. Prefer a formal tone when it does not hurt clarity, and use complete sentences. Avoid mid-sentence breaks introduced by em dashes or long parenthetical clauses. Em dashes are a reliable symptom of loose phrasing; when one appears, restructure the surrounding sentence so each clause stands on its own rather than swapping the em dash for another punctuation mark.
-- Prefer imports merged per module. Combine items from the same module into a single `use` statement, but write a separate `use` statement for each module rather than collapsing every path from a crate into one nested-braces statement.
 - Use descriptive names for generics, such as `Size` and `Report`. Do not use single letters.
 - Use descriptive names for variables and closure parameters. Single letters are permitted only in these cases: (1) conventional names like `n` for count or `f` for formatter; (2) comparison closures like `|a, b|`; (3) trivial single-expression closures; (4) fold accumulators; and (5) index variables `i`/`j`/`k` in short closures or index-based loops. Single letters are never permitted in `let` bindings, including test fixtures, nor in multi-line functions or closures.
 - Use `pipe-trait` to chain through unary functions such as constructors, `Some`, `Ok`, and free functions. Use it to flatten nested calls and to continue method chains. Do not use it for simple standalone calls; prefer `foo(value)` over `value.pipe(foo)`.

CONTRIBUTING.md

@@ -36,7 +36,9 @@ Automated tools enforce formatting (`cargo fmt`), linting (`cargo clippy`), and
 
 ### Import Organization
 
-Prefer **merged imports** at module granularity. Combine multiple items from the same module into a single `use` statement with braces, but write a separate `use` statement for each module rather than collapsing every path from a crate into one nested-braces statement. This granularity is enforced by the `perfectionist::import_granularity` dylint check (`style = "module"`). Import ordering is enforced by `cargo fmt`. Imports gated by a platform attribute such as `#[cfg(unix)]` go in a separate block after the main imports.
+Import granularity is enforced automatically by the `perfectionist::import_granularity` rule, configured for the `module` style. Items from the same module are merged into a single braced `use` statement, while each module keeps its own `use` statement rather than collapsing an entire crate into one nested-braces statement. Import ordering is enforced separately by `cargo fmt`.
+
+The remaining convention is not enforced and must be applied by hand. Imports gated by a platform attribute such as `#[cfg(unix)]` go in a separate block after the main imports.
 
 ```rust
 use crate::args::{Args, Quantity, Threads};

template/ai-instructions/shared.md

@@ -7,7 +7,6 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c
 - Commit format: Conventional Commits. Pattern: `type(scope): lowercase description`. The scope is optional.
 - Version releases are the only exception. The commit message is just the version number, such as `0.21.1`.
 - Write documentation, comments, and other prose for ease of understanding first. Prefer a formal tone when it does not hurt clarity, and use complete sentences. Avoid mid-sentence breaks introduced by em dashes or long parenthetical clauses. Em dashes are a reliable symptom of loose phrasing; when one appears, restructure the surrounding sentence so each clause stands on its own rather than swapping the em dash for another punctuation mark.
-- Prefer imports merged per module. Combine items from the same module into a single `use` statement, but write a separate `use` statement for each module rather than collapsing every path from a crate into one nested-braces statement.
 - Use descriptive names for generics, such as `Size` and `Report`. Do not use single letters.
 - Use descriptive names for variables and closure parameters. Single letters are permitted only in these cases: (1) conventional names like `n` for count or `f` for formatter; (2) comparison closures like `|a, b|`; (3) trivial single-expression closures; (4) fold accumulators; and (5) index variables `i`/`j`/`k` in short closures or index-based loops. Single letters are never permitted in `let` bindings, including test fixtures, nor in multi-line functions or closures.
 - Use `pipe-trait` to chain through unary functions such as constructors, `Some`, `Ok`, and free functions. Use it to flatten nested calls and to continue method chains. Do not use it for simple standalone calls; prefer `foo(value)` over `value.pipe(foo)`.