opencode-skills-collection 3.1.12 → 3.1.13

package/bundled-skills/azure-servicebus-rust/SKILL.md

@@ -0,0 +1,182 @@
+---
+name: azure-servicebus-rust
+description: 'Azure Service Bus library for Rust. Send and receive messages using queues, topics, and subscriptions. Triggers: "service bus rust", "ServiceBusClient rust", "send message servicebus rust", "receive message servicebus rust", "queue rust messaging", "topic subscription rust".'
+risk: unknown
+source: https://github.com/microsoft/skills/tree/main/.github/plugins/azure-sdk-rust/skills/azure-servicebus-rust
+source_repo: microsoft/skills
+source_type: official
+date_added: 2026-07-01
+license: MIT
+license_source: https://github.com/microsoft/skills/blob/main/LICENSE
+---
+
+# Azure Service Bus library for Rust
+## When to Use
+
+Use this skill when you need azure Service Bus library for Rust. Send and receive messages using queues, topics, and subscriptions. Triggers: "service bus rust", "ServiceBusClient rust", "send message servicebus rust", "receive message servicebus rust", "queue rust messaging", "topic subscription rust".
+
+
+Client library for Azure Service Bus — enterprise message broker with queues and publish-subscribe topics.
+
+> **⚠️ WARNING:** This crate is in early development and **SHOULD NOT** be used in production. APIs may change without notice.
+
+Use this skill when:
+
+- An app needs to send or receive messages via Azure Service Bus from Rust
+- You need queue-based messaging with competing consumers
+- You need publish-subscribe messaging with topics and subscriptions
+- You need reliable message delivery with completion semantics
+
+> **IMPORTANT:** Only use the official `azure_messaging_servicebus` crate published by the [azure-sdk](https://crates.io/users/azure-sdk) crates.io user. Do NOT use unofficial or community crates. Official crates use underscores in names and none have version 0.21.0.
+
+## Installation
+
+```sh
+cargo add azure_messaging_servicebus azure_identity tokio
+```
+
+> If your code uses `azure_core` types directly, add `azure_core` to `Cargo.toml`. If you only use `azure_messaging_servicebus` re-exports, direct `azure_core` dependency is optional.
+
+## Environment Variables
+
+```bash
+SERVICEBUS_NAMESPACE=<namespace>.servicebus.windows.net # Required — fully qualified namespace
+```
+
+## Key Concepts
+
+| Concept          | Description                                                     |
+| ---------------- | --------------------------------------------------------------- |
+| **Namespace**    | Container for all messaging components                          |
+| **Queue**        | Point-to-point messaging with competing consumers               |
+| **Topic**        | Publish-subscribe messaging — one sender, many subscribers      |
+| **Subscription** | Receives messages from a topic                                  |
+| **Message**      | Package of data and metadata, with completion/abandon semantics |
+
+## Authentication
+
+```rust
+use azure_identity::DeveloperToolsCredential;
+use azure_messaging_servicebus::ServiceBusClient;
+
+#[tokio::main]
+async fn main() -> Result<(), Box<dyn std::error::Error>> {
+    // Local dev: DeveloperToolsCredential. Production: use ManagedIdentityCredential.
+    let credential = DeveloperToolsCredential::new(None)?;
+    let client = ServiceBusClient::builder()
+        .open("your_namespace.servicebus.windows.net", credential.clone())
+        .await?;
+    Ok(())
+}
+```
+
+## Core Workflow
+
+### Send a Message to a Queue
+
+```rust
+use azure_identity::DeveloperToolsCredential;
+use azure_messaging_servicebus::{ServiceBusClient, Message};
+
+#[tokio::main]
+async fn main() -> Result<(), Box<dyn std::error::Error>> {
+    let credential = DeveloperToolsCredential::new(None)?;
+    let client = ServiceBusClient::builder()
+        .open("your_namespace.servicebus.windows.net", credential.clone())
+        .await?;
+    let sender = client.create_sender("my_queue", None).await?;
+
+    let message = Message::from("Hello, Service Bus!");
+    sender.send_message(message, None).await?;
+    Ok(())
+}
+```
+
+### Receive Messages from a Queue
+
+```rust
+use azure_identity::DeveloperToolsCredential;
+use azure_messaging_servicebus::ServiceBusClient;
+
+#[tokio::main]
+async fn main() -> Result<(), Box<dyn std::error::Error>> {
+    let credential = DeveloperToolsCredential::new(None)?;
+    let client = ServiceBusClient::builder()
+        .open("your_namespace.servicebus.windows.net", credential.clone())
+        .await?;
+    let receiver = client.create_receiver("my_queue", None).await?;
+
+    let messages = receiver.receive_messages(5, None).await?;
+    for message in messages {
+        println!("Received: {}", message.body_as_string()?);
+        receiver.complete_message(&message, None).await?;
+    }
+    Ok(())
+}
+```
+
+### Send a Message to a Topic
+
+```rust
+let sender = client.create_sender("my_topic", None).await?;
+let message = Message::from("Hello, Topic subscribers!");
+sender.send_message(message, None).await?;
+```
+
+### Receive Messages from a Subscription
+
+```rust
+let receiver = client
+    .create_receiver_for_subscription("my_topic", "my_subscription", None)
+    .await?;
+
+let messages = receiver.receive_messages(5, None).await?;
+for message in messages {
+    println!("Received: {}", message.body_as_string()?);
+    receiver.complete_message(&message, None).await?;
+}
+```
+
+## Message Settlement
+
+| Action     | Purpose                                            |
+| ---------- | -------------------------------------------------- |
+| `complete` | Remove message from queue — processing succeeded   |
+| `abandon`  | Release lock — message becomes available for retry |
+
+Always complete messages after successful processing to prevent redelivery.
+
+## RBAC Roles
+
+For Entra ID auth, assign one of these roles:
+
+| Role                              | Access           |
+| --------------------------------- | ---------------- |
+| `Azure Service Bus Data Sender`   | Send messages    |
+| `Azure Service Bus Data Receiver` | Receive messages |
+| `Azure Service Bus Data Owner`    | Full access      |
+
+## Best Practices
+
+1. **Use `cargo add` to manage dependencies, never edit `Cargo.toml` directly.** Add and remove Rust SDK dependencies with cargo commands instead of manual manifest edits.
+2. **Add `azure_core` only when importing `azure_core` types directly.** If your code imports `azure_core::http::Url`, `azure_core::http::RequestContent`, or `azure_core::error::ErrorKind`, include `azure_core`; otherwise a direct dependency is optional.
+3. **Use `DeveloperToolsCredential`** for local dev, **`ManagedIdentityCredential`** for production — Rust does not provide a single `DefaultAzureCredential` type
+4. **Never hardcode credentials** — use environment variables or managed identity
+5. **Assign RBAC roles** — ensure the identity has appropriate Service Bus data roles
+6. **Always complete messages** — call `complete_message` after processing to remove from queue
+7. **Use topics for fan-out** — when multiple consumers need the same messages, use topics with subscriptions
+8. **This crate is pre-production** — APIs may change; pin your dependency version with cargo commands in your dependency workflow
+
+## Reference Links
+
+| Resource      | Link                                                                                            |
+| ------------- | ----------------------------------------------------------------------------------------------- |
+| API Reference | https://docs.rs/azure_messaging_servicebus/latest/azure_messaging_servicebus                    |
+| crates.io     | https://crates.io/crates/azure_messaging_servicebus                                             |
+| Source Code   | https://github.com/Azure/azure-sdk-for-rust/tree/main/sdk/servicebus/azure_messaging_servicebus |
+
+## Limitations
+
+- Use this skill only when the task clearly matches its upstream source and local project context.
+- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
+- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.

package/bundled-skills/azure-storage-queue-rust/SKILL.md

@@ -0,0 +1,178 @@
+---
+name: azure-storage-queue-rust
+description: 'Azure Queue Storage library for Rust. Send, receive, and manage queue messages. Triggers: "queue storage rust", "QueueClient rust", "send message rust", "receive messages rust", "QueueServiceClient rust", "queue rust".'
+risk: unknown
+source: https://github.com/microsoft/skills/tree/main/.github/plugins/azure-sdk-rust/skills/azure-storage-queue-rust
+source_repo: microsoft/skills
+source_type: official
+date_added: 2026-07-01
+license: MIT
+license_source: https://github.com/microsoft/skills/blob/main/LICENSE
+---
+
+# Azure Queue Storage library for Rust
+## When to Use
+
+Use this skill when you need azure Queue Storage library for Rust. Send, receive, and manage queue messages. Triggers: "queue storage rust", "QueueClient rust", "send message rust", "receive messages rust", "QueueServiceClient rust", "queue rust".
+
+
+Client library for Azure Queue Storage — send, receive, and manage queue messages.
+
+Use this skill when:
+
+- An app needs to send or receive messages from Azure Queue Storage in Rust
+- You need to create or manage queues
+- You need to peek, receive, or delete queue messages
+- You need RBAC-based auth for queue operations
+
+> **IMPORTANT:** Only use the official `azure_storage_queue` crate published by the [azure-sdk](https://crates.io/users/azure-sdk) crates.io user. Do NOT use unofficial or community crates. Official crates use underscores in names and none have version 0.21.0.
+
+## Installation
+
+```sh
+cargo add azure_storage_queue azure_identity azure_core tokio
+```
+
+> If your code uses `azure_core` types directly, add `azure_core` to `Cargo.toml`. If you only use `azure_storage_queue` re-exports, direct `azure_core` dependency is optional.
+
+## Environment Variables
+
+```bash
+AZURE_STORAGE_QUEUE_ENDPOINT=https://<account>.queue.core.windows.net/ # Required for all operations
+```
+
+## Authentication
+
+```rust
+use azure_core::http::Url;
+use azure_identity::DeveloperToolsCredential;
+use azure_storage_queue::QueueServiceClient;
+
+#[tokio::main]
+async fn main() -> Result<(), Box<dyn std::error::Error>> {
+    // Local dev: DeveloperToolsCredential. Production: use ManagedIdentityCredential.
+    let credential = DeveloperToolsCredential::new(None)?;
+    let service_url = Url::parse("https://<storage_account_name>.queue.core.windows.net/")?;
+    let service_client = QueueServiceClient::new(service_url, Some(credential), None)?;
+
+    // Derive a queue client by name.
+    let queue_client = service_client.queue_client("<queue_name>")?;
+    Ok(())
+}
+```
+
+## Client Types
+
+| Client               | Purpose                               | Access                                   |
+| -------------------- | ------------------------------------- | ---------------------------------------- |
+| `QueueServiceClient` | Account-level operations, list queues | `QueueServiceClient::new()`              |
+| `QueueClient`        | Queue operations, send/receive/delete | `service_client.queue_client("<name>")?` |
+
+## Core Workflow
+
+### Send a Message
+
+```rust
+use azure_core::http::Url;
+use azure_identity::DeveloperToolsCredential;
+use azure_storage_queue::{models::QueueMessage, QueueServiceClient};
+
+#[tokio::main]
+async fn main() -> Result<(), Box<dyn std::error::Error>> {
+    let credential = DeveloperToolsCredential::new(None)?;
+    let service_url = Url::parse("https://<storage_account_name>.queue.core.windows.net/")?;
+    let service_client = QueueServiceClient::new(service_url, Some(credential), None)?;
+    let queue_client = service_client.queue_client("<queue_name>")?;
+
+    let message = QueueMessage {
+        message_text: Some("hello world".to_string()),
+    };
+    queue_client.send_message(message.try_into()?, None).await?;
+    Ok(())
+}
+```
+
+### Receive Messages
+
+```rust
+use azure_core::http::Url;
+use azure_identity::DeveloperToolsCredential;
+use azure_storage_queue::QueueServiceClient;
+
+#[tokio::main]
+async fn main() -> Result<(), Box<dyn std::error::Error>> {
+    let credential = DeveloperToolsCredential::new(None)?;
+    let service_url = Url::parse("https://<storage_account_name>.queue.core.windows.net/")?;
+    let service_client = QueueServiceClient::new(service_url, Some(credential), None)?;
+    let queue_client = service_client.queue_client("<queue_name>")?;
+
+    let response = queue_client.receive_messages(None).await?;
+    let messages = response.into_model()?;
+    for msg in messages.items.unwrap_or_default() {
+        println!("{}", msg.message_text.as_deref().unwrap_or("<empty>"));
+    }
+    Ok(())
+}
+```
+
+### Delete a Message
+
+After receiving a message, delete it using the message ID and pop receipt:
+
+```rust
+let response = queue_client.receive_messages(None).await?;
+let messages = response.into_model()?;
+for msg in messages.items.unwrap_or_default() {
+    if let (Some(id), Some(pop_receipt)) = (&msg.message_id, &msg.pop_receipt) {
+        queue_client.delete_message(id, pop_receipt, None).await?;
+    }
+}
+```
+
+### Peek Messages
+
+Peek at messages without removing them from the queue:
+
+```rust
+let response = queue_client.peek_messages(None).await?;
+let messages = response.into_model()?;
+for msg in messages.items.unwrap_or_default() {
+    println!("Peeked: {}", msg.message_text.as_deref().unwrap_or("<empty>"));
+}
+```
+
+## RBAC Roles
+
+For Entra ID auth, assign one of these roles to the identity:
+
+| Role                                   | Access                 |
+| -------------------------------------- | ---------------------- |
+| `Storage Queue Data Reader`            | Read and peek messages |
+| `Storage Queue Data Contributor`       | Read/write messages    |
+| `Storage Queue Data Message Sender`    | Send messages only     |
+| `Storage Queue Data Message Processor` | Receive and delete     |
+
+## Best Practices
+
+1. **Use `cargo add` to manage dependencies, never edit `Cargo.toml` directly.** Add and remove Rust SDK dependencies with cargo commands instead of manual manifest edits.
+2. **Add `azure_core` only when importing `azure_core` types directly.** If your code imports `azure_core::http::Url`, `azure_core::http::RequestContent`, or `azure_core::error::ErrorKind`, include `azure_core`; otherwise a direct dependency is optional.
+3. **Use `DeveloperToolsCredential`** for local dev, **`ManagedIdentityCredential`** for production — Rust does not provide a single `DefaultAzureCredential` type
+4. **Never hardcode credentials** — use environment variables or managed identity
+5. **Assign RBAC roles** — ensure appropriate queue data roles for the identity
+6. **Use `QueueServiceClient` as the entry point** and derive `QueueClient` from it via `queue_client()`
+7. **Delete messages after processing** — use the message ID and pop receipt from `receive_messages`
+8. **Reuse clients** — clients are thread-safe; create once, share across tasks
+
+## Reference Links
+
+| Resource      | Link                                                                                  |
+| ------------- | ------------------------------------------------------------------------------------- |
+| API Reference | https://docs.rs/crate/azure_storage_queue/latest                                      |
+| crates.io     | https://crates.io/crates/azure_storage_queue                                          |
+| Source Code   | https://github.com/Azure/azure-sdk-for-rust/tree/main/sdk/storage/azure_storage_queue |
+
+## Limitations
+
+- Use this skill only when the task clearly matches its upstream source and local project context.
+- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
+- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.

package/bundled-skills/baseline-ui/SKILL.md

@@ -1,18 +1,22 @@
 ---
 name: baseline-ui
-description: Validates animation durations, enforces typography scale, checks component accessibility, and prevents layout anti-patterns in Tailwind CSS projects. Use when building UI components, reviewing CSS utilities, styling React views, or enforcing design consistency.
+description: Quickly deslop UI code by fixing spacing, hierarchy, typography, and small layout issues. Use when the interface needs a fast cleanup or polish pass.
 risk: unknown
-source: community
+source: https://github.com/ibelick/ui-skills/tree/main/skills/baseline-ui
+source_repo: ibelick/ui-skills
+source_type: community
+date_added: 2026-07-01
+license: MIT
+license_source: https://github.com/ibelick/ui-skills/blob/main/LICENSE
 ---
 
 # Baseline UI
+## When to Use
 
-Enforces an opinionated UI baseline to prevent AI-generated interface slop.
+Use this skill when you need quickly deslop UI code by fixing spacing, hierarchy, typography, and small layout issues. Use when the interface needs a fast cleanup or polish pass.
 
-## When to Use
-- You are building or reviewing Tailwind-based UI and want a strict baseline for accessibility, motion, typography, and layout.
-- The task is to prevent generic or sloppy AI-generated interface decisions before they spread through the codebase.
-- You need concrete UI constraints to apply to a file review or an ongoing frontend implementation.
+
+Enforces an opinionated UI baseline to prevent AI-generated interface slop.
 
 ## How to use
 
@@ -92,6 +96,7 @@ Enforces an opinionated UI baseline to prevent AI-generated interface slop.
 - SHOULD use existing theme or Tailwind CSS color tokens before introducing new ones
 
 ## Limitations
-- Use this skill only when the task clearly matches the scope described above.
-- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
-- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
+
+- Use this skill only when the task clearly matches its upstream source and local project context.
+- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
+- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.

package/bundled-skills/brooks-audit/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: brooks-audit
+description: "Architecture audit that maps module dependencies, checks layering integrity, and flags structural decay across a codebase, drawing on twelve classic engineering books. Triggers when: user asks to audit architecture, review folder/module structure, check for circular imports, understand..."
+risk: unknown
+source: https://github.com/hyhmrright/brooks-lint/tree/main/skills/brooks-audit
+source_repo: hyhmrright/brooks-lint
+source_type: community
+date_added: 2026-07-01
+license: MIT
+license_source: https://github.com/hyhmrright/brooks-lint/blob/main/LICENSE
+---
+
+# Brooks-Lint — Architecture Audit
+## When to Use
+
+Use this skill when you need architecture audit that maps module dependencies, checks layering integrity, and flags structural decay across a codebase, drawing on twelve classic engineering books. Triggers when: user asks to audit architecture, review folder/module structure, check for circular imports, understand...
+
+
+## Setup
+
+1. Read `../_shared/common.md` for the Iron Law, Project Config, Report Template, and Health Score rules
+2. Read `../_shared/source-coverage.md` for book-level coverage, exceptions, and tradeoffs
+3. Read `../_shared/decay-risks.md` for symptom definitions and source attributions
+4. Read `architecture-guide.md` in this directory for the audit framework
+
+## Process
+
+**Onboarding mode:** If the user asks for an onboarding report, codebase tour, or
+"explain this codebase to a new developer", read `onboarding-guide.md` from this
+directory and follow it instead of `architecture-guide.md`. This mode explains rather
+than diagnoses — no Health Score, no Iron Law findings.
+
+**If the user has not specified files or a directory to audit:** apply Auto Scope
+Detection from `../_shared/common.md` to determine the audit scope before proceeding.
+
+1. Gather codebase context and draw the module dependency graph as Mermaid (Steps 0–1 of the guide)
+2. Scan for each decay risk in the order specified (Steps 2–4 of the guide)
+3. Assign node colors in the Mermaid diagram based on findings (red/yellow/green) — after Step 4
+4. Run the Testability Seam Assessment (Step 5 of the guide)
+5. Run the Conway's Law check (Step 6 of the guide)
+6. Output using the Report Template from common.md — Mermaid graph FIRST, then Findings
+
+**Mode line in report:** `Architecture Audit`
+
+## Limitations
+
+- Use this skill only when the task clearly matches its upstream source and local project context.
+- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
+- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.

package/bundled-skills/brooks-audit/architecture-guide.md

@@ -0,0 +1,195 @@
+# Architecture Audit Guide — Mode 2
+
+**Purpose:** Analyze the module and dependency structure of a system for decay risks that
+operate at the architectural level. Every finding must follow the Iron Law:
+Symptom → Source → Consequence → Remedy.
+
+**Monorepo note:** Treat each deployable service or library as a top-level module. Draw
+dependencies between services, not between their internal packages. Apply the Conway's Law
+check at the service ownership level. Within a single service, apply standard module-level analysis.
+
+---
+
+## Analysis Process
+
+Work through these six steps in order.
+
+### Step 0: Gather Codebase Context
+
+Before drawing anything, establish what you can see.
+
+**If the user provided a full directory tree or pasted relevant file contents:** skip the
+proactive reading below and proceed to Step 1.
+
+**Otherwise, proactively read the project using these tools:**
+
+1. **Top-level structure** — glob top two levels to identify module boundaries:
+   ```
+   Glob: **/*(depth 2, directories only)
+   ```
+2. **Entry points** — read the package manifest or main config file (e.g., `package.json`,
+   `go.mod`, `pom.xml`, `Cargo.toml`, `pyproject.toml`) to confirm language, framework,
+   and declared dependencies.
+3. **Dependency edges** — grep import statements to discover inter-module calls. Run once
+   per language present; limit to the first 200 matches to avoid token overrun:
+   ```
+   Grep: "^\s*(import|from|require\(|use )" across *.ts|*.py|*.go|*.rs|*.java
+   ```
+4. **Large modules** — for any top-level directory with > 10 files, read the file matching
+   `index.*`, `main.*`, or `__init__.*` to understand its stated responsibility.
+
+**Stop when you can answer all three:**
+- What are the top-level modules (names and count)?
+- Which modules import from which other modules?
+- Which module has the highest fan-in or fan-out?
+
+If the project has > 100 top-level files or > 4 levels of nesting, note which areas were
+sampled vs. inferred, and flag this in the report scope line.
+
+### Step 1: Draw the Module Dependency Graph (Mermaid)
+
+Before evaluating any risk, map the dependencies as a Mermaid diagram. Use this format:
+
+````mermaid
+graph TD
+  subgraph UI
+    WebApp
+    MobileApp
+  end
+
+  subgraph Domain
+    AuthService
+    OrderService
+    PaymentService
+  end
+
+  subgraph Infrastructure
+    Database
+    MessageQueue
+  end
+
+  WebApp --> AuthService
+  WebApp --> OrderService
+  MobileApp --> AuthService
+  MobileApp --> OrderService
+  OrderService --> PaymentService
+  OrderService --> Database
+  OrderService --> MessageQueue
+  PaymentService --> Database
+  AuthService -.->|circular| OrderService
+
+  classDef critical fill:#ff6b6b,stroke:#c92a2a,color:#fff
+  classDef warning fill:#ffd43b,stroke:#e67700
+  classDef clean fill:#51cf66,stroke:#2b8a3e,color:#fff
+
+  class PaymentService critical
+  class OrderService warning
+  class Database,MessageQueue,AuthService,WebApp,MobileApp clean
+````
+
+Draw the graph structure first — nodes, subgraphs, and edges — without any `classDef` or
+`class` lines. You cannot assign colors until you have completed the risk scan in Steps 2–4.
+
+**After completing Step 4**, return to this graph and add the `classDef` and `class` lines
+based on findings. The example above shows the final colored output.
+
+Rules:
+1. **Nodes** — Use top-level directories or services as nodes, not individual files
+2. **Grouping** — One `subgraph` per architectural layer or top-level directory (e.g., UI, Domain, Infrastructure)
+3. **Edges** — Solid arrows (`-->`) point FROM the depending module TO the dependency; use dotted arrows with label (`-.->|circular|`) for circular dependencies. If no circular dependencies exist, use only solid arrows
+4. **Node limit** — Keep the graph to ~50 nodes maximum; collapse low-risk leaf modules into their parent if needed
+5. **Fan-out** — For any node with fan-out > 5, use a descriptive label: `HighFanOutModule["ModuleName (fan-out: 7)"]`
+6. **Colors** — Apply `classDef` colors AFTER completing Steps 2-4: `critical` (red `#ff6b6b`) for nodes with Critical findings, `warning` (yellow `#ffd43b`) for Warning findings, `clean` (green `#51cf66`) for nodes with no findings or only Suggestions. If no findings at all, classify all nodes as `clean`
+7. **Direction** — Default to `graph TD` (top-down); use `graph LR` only if the architecture is clearly a left-to-right pipeline
+
+### Step 2: Scan for Dependency Disorder
+
+*The most architecturally consequential risk — scan this first.*
+
+Look for:
+- Circular dependencies (any `-.->|circular|` edge in the map above)
+- Arrows flowing upward (high-level domain depending on low-level infrastructure)
+- Stable, widely-depended-on modules that import from frequently-changing modules
+- Modules with fan-out > 5
+- Absence of a clear layering rule (no consistent answer to "what depends on what?")
+
+### Step 3: Scan for Domain Model Distortion
+
+Look for:
+- Do module names match the business domain vocabulary?
+- Is there a layer called "services" that contains all the business logic while domain objects
+  are pure data structures?
+- Are there modules that cross bounded context boundaries (e.g., billing logic in the user module)?
+- Is there an anti-corruption layer where external systems interface with the domain?
+
+### Step 4: Scan for Remaining Four Risks
+
+Check each in turn:
+
+**Knowledge Duplication:**
+- Are there multiple modules implementing the same concept independently?
+- Does the same domain concept appear under different names in different modules?
+
+**Accidental Complexity:**
+- Are there entire layers in the architecture that do not add value?
+- Are there modules whose responsibility cannot be stated in one sentence?
+
+**Change Propagation:**
+- Which modules are "blast radius hotspots"? (A change here requires changes in many other modules)
+- Does the dependency map reveal why certain features are slow to develop?
+
+**Cognitive Overload:**
+- Can the module responsibility of each module be stated in one sentence from its name alone?
+- Would a new developer know which module to add a new feature to?
+
+### Step 5: Testability Seam Assessment
+
+A *seam* is a place in the architecture where behavior can be altered without editing source
+code — typically an interface, a configuration point, or a dependency injection boundary.
+Seam density is a proxy for testability and evolvability.
+
+Scan for:
+- **No seam at the infrastructure boundary**: can you replace a real database, file system,
+  or HTTP client with a test double without editing the module under test? If not, the
+  architecture forces integration tests where unit tests would suffice.
+- **Seam collapse**: a module that was once testable in isolation has had its seams removed
+  (e.g., direct constructor instantiation replaced a dependency injection point, or a global
+  singleton replaced an injected collaborator).
+- **Missing seam in legacy areas**: modules without an obvious injection point or interface
+  boundary — any change requires touching the entire call stack to substitute behavior.
+
+If all modules have clear seams at their infrastructure boundaries → no finding.
+
+If seams are absent or collapsed: flag as 🟡 Warning with a Remedy pointing to the specific
+module and the injection point that needs to be restored or introduced.
+
+Source: Feathers — Working Effectively with Legacy Code, Ch. 4: The Seam Model
+
+### Step 6: Conway's Law Check
+
+After the six-risk scan, assess the relationship between architecture and team structure:
+
+- Does the module/service structure reflect the team structure?
+  (Conway's Law: "Organizations design systems that mirror their communication structure")
+- If yes: is this intentional design or accidental coupling?
+- A mismatch that causes cross-team coordination overhead for every feature is 🔴 Critical.
+- A mismatch that is theoretical but not yet causing pain is 🟡 Warning.
+- If team structure is unknown, note this as context missing and skip the check.
+
+**Calibration examples:**
+- 🔴 Critical: the Payments module is owned by Team A but contains auth logic owned by Team B —
+  every Payments change requires a sync meeting with Team B
+- 🟡 Warning: two separate teams own the `utils/` and `helpers/` directories which do the same
+  things — theoretically painful but not yet causing release coordination issues
+- Not a finding: a single team owns a monorepo with multiple logical modules — Conway's Law
+  misalignment requires *separate teams* to be meaningful
+
+---
+
+## Output
+
+Use the standard Report Template from `../_shared/common.md`. Mode: Architecture Audit.
+
+Place the Mermaid dependency graph FIRST under "Module Dependency Graph". Reference
+relevant node names in findings. Add `classDef` color assignments LAST, after all
+findings are identified.