/audit-layer-boundaries
Analyze layer boundary definitions in Rust codebases, identifying mixed responsibilities and violations
$ npx -y skills add qdhenry/Claude-Command-Suite --agent claude-codeHow it fires
How this command gets triggered: by you, by Claude, or both.
- Fires itselfClaude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/audit-layer-boundaries
Context preview
What this command does when you run it.
Analyze layer boundary definitions in Rust codebases, identifying mixed responsibilities and violations
Command definition
audit-layer-boundaries.mdname: rust:audit-layer-boundaries
description: Analyze layer boundary definitions in Rust codebases, identifying mixed responsibilities and violations
allowed-tools: Read, Grep, Glob, Bash
author: Quintin Henry (https://github.com/qdhenry/)
Audit Layer Boundaries
Analyze how well-defined the architectural layer boundaries are in a Rust codebase, identifying mixed responsibilities, unclear separation, and boundary violations.
Instructions
Audit layer boundaries in the codebase: **$ARGUMENTS**
> **Note:** `$ARGUMENTS` can specify a path or focus area. > Examples: > - `/rust:audit-layer-boundaries` - Full boundary audit > - `/rust:audit-layer-boundaries src/core/` - Focus on specific path
---
Layer Responsibility Reference
| Layer | Responsibility | Should NOT Contain | |-------|---------------|-------------------| | **Domain** | Entities, value objects, domain services, business rules | Serialization, HTTP, DB queries, config | | **Application** | Use cases, orchestration, port definitions, app errors | HTTP handlers, DB implementations, framework types | | **Adapters** | HTTP handlers, DB repositories, external API clients, serialization | Business logic, configuration setup | | **Infrastructure** | App startup, config loading, DB pools, dependency wiring | Business logic, HTTP handling |
---
Phase 1: Identify Layer Structure
1.1 Discover Project Organization
# List top-level source structure
ls -la src/
# Find all modules
find src -name "mod.rs" -o -name "lib.rs" | head -20
# Check for layer-like directories
for pattern in domain application adapters infrastructure core lib api handlers services controllers repositories; do
found=$(find src -type d -name "$pattern" 2>/dev/null)
[ -n "$found" ] && echo "Layer candidate: $found"
done
1.2 Document Layer Mapping
## Current Layer Structure
| Identified Directory | Mapped Layer | Confidence |
|---------------------|--------------|------------|
| `src/???` | Domain | High/Medium/Low |
| `src/???` | Application | High/Medium/Low |
| `src/???` | Adapters | High/Medium/Low |
| `src/???` | Infrastructure | High/Medium/Low |
| `src/???` | UNCLEAR | - |
---
Phase 2: Domain Layer Boundary Audit
2.1 Domain Purity Check
The domain should contain ONLY business logic.
# Find all files in domain layer
find src/domain -name "*.rs" 2>/dev/null
# Check each file for boundary violations
for file in $(find src/domain -name "*.rs" 2>/dev/null); do
echo "=== $file ==="
# Check for HTTP concerns
grep -n "HttpResponse\|StatusCode\|axum::\|actix::\|Request\|Response" "$file"
# Check for DB concerns
grep -n "sqlx::\|diesel::\|query!\|execute\|Pool\|Connection" "$file"
# Check for serialization in struct definitions
grep -n "Serialize\|Deserialize\|Json<" "$file"
done
2.2 Domain Should Contain
// GOOD: Domain content
pub struct User { ... } // Entities
pub struct Email(String); // Value objects
pub fn validate_email(s: &str) -> bool { ... } // Domain rules
pub trait DomainService { ... } // Domain services
pub enum DomainError { ... } // Domain errors2.3 Domain Should NOT Contain
// BAD: HTTP in domain
#[derive(Deserialize)] // Serialization concern
pub struct CreateUserRequest { ... }
// BAD: DB in domain
#[derive(sqlx::FromRow)] // Persistence concern
pub struct User { ... }
// BAD: Framework types in domain
pub fn handler(req: HttpRequest) { ... }---
Phase 3: Application Layer Boundary Audit
3.1 Application Layer Content Check
# Find application layer files
find src/application -name "*.rs" 2>/dev/null
# Check for misplaced responsibilities
for file in $(find src/application -name "*.rs" 2>/dev/null); do
echo "=== $file ==="
# HTTP concerns (should be in adapters)
grep -n "HttpResponse\|StatusCode\|Json<\|Path<\|Query<" "$file"
# Direct DB queries (should use repository trait)
grep -n "sqlx::query\|diesel::\|\.execute(\|\.fetch" "$file"
# Framework routing
grep -n "Router\|route\|get\|post\|put\|delete" "$file"
done
3.2 Application Should Contain
// GOOD: Application content
pub struct RegisterUser { ... } // Use cases
pub trait UserRepository { ... } // Port traits
pub enum AppError { ... } // Application errors
pub async fn execute(&self) { ... } // Use case execution3.3 Application Should NOT Contain
// BAD: HTTP handlers in application
pub async fn register_handler(Json(body): Json<...>) -> impl IntoResponse { ... }
// BAD: Direct DB access
let user = sqlx::query!("SELECT * FROM users").fetch_one(&pool).await?;
// BAD: Concrete adapter types
pub struct RegisterUser {
db: PgPool, // Should be trait object
}---
Phase 4: Adapters Layer Boundary Audit
4.1 Adapter Content Check
# Find adapter layer files
find src/adapters -name "*.rs" 2>/dev/null
# Check for business logic leakage
for file in $(find src/adapters -name "*.rs" 2>/dev/null); do
echo "=== $file ==="
# Complex business logic (should be in application/domain)
grep -n "if.*&&.*&&\|match.*=>" "$file" | head -5
# Business validation (should be in domain)
grep -n "validate\|is_valid\|check_" "$file"
done
4.2 Adapters Should Contain
// GOOD: Adapter content
impl UserRepository for PostgresUserRepository { ... } // Port implementations
pub async fn register_handler(...) -> impl IntoResponse { ... } // HTTP handlers
pub fn app_error_to_response(e: AppError) -> Response { ... } // Error conversion
pub struct CreateUserDto { ... } // DTOs with serialization4.3 Adapters Should NOT Contain
// BAD: Business logic in adapter
pub async fn register_handler(...) {
// Business rules should be in use case
if password.len() < 8 { return Err(...) }
if !email.contains('@') { return Err(...) }
// ...
}
// BAD: MuRead more
name: rust:audit-layer-boundaries description: Analyze layer boundary definitions in Rust codebases, identifying mixed responsibilities and violations allowed-tools: Read, Grep, Glob, Bash author: Quintin Henry (https://github.com/qdhenry/)
Audit Layer Boundaries
Analyze how well-defined the architectural layer boundaries are in a Rust codebase, identifying mixed responsibilities, unclear separation, and boundary violations.
Instructions
Audit layer boundaries in the codebase: **$ARGUMENTS**
> **Note:** `$ARGUMENTS` can specify a path or focus area. > Examples: > - `/rust:audit-layer-boundaries` - Full boundary audit > - `/rust:audit-layer-boundaries src/core/` - Focus on specific path
---
Layer Responsibility Reference
| Layer | Responsibility | Should NOT Contain | |-------|---------------|-------------------| | **Domain** | Entities, value objects, domain services, business rules | Serialization, HTTP, DB queries, config | | **Application** | Use cases, orchestration, port definitions, app errors | HTTP handlers, DB implementations, framework types | | **Adapters** | HTTP handlers, DB repositories, external API clients, serialization | Business logic, configuration setup | | **Infrastructure** | App startup, config loading, DB pools, dependency wiring | Business logic, HTTP handling |
---
Phase 1: Identify Layer Structure
1.1 Discover Project Organization
# List top-level source structure ls -la src/ # Find all modules find src -name "mod.rs" -o -name "lib.rs" | head -20 # Check for layer-like directories for pattern in domain application adapters infrastructure core lib api handlers services controllers repositories; do found=$(find src -type d -name "$pattern" 2>/dev/null) [ -n "$found" ] && echo "Layer candidate: $found" done
1.2 Document Layer Mapping
## Current Layer Structure | Identified Directory | Mapped Layer | Confidence | |---------------------|--------------|------------| | `src/???` | Domain | High/Medium/Low | | `src/???` | Application | High/Medium/Low | | `src/???` | Adapters | High/Medium/Low | | `src/???` | Infrastructure | High/Medium/Low | | `src/???` | UNCLEAR | - |
---
Phase 2: Domain Layer Boundary Audit
2.1 Domain Purity Check
The domain should contain ONLY business logic.
# Find all files in domain layer find src/domain -name "*.rs" 2>/dev/null # Check each file for boundary violations for file in $(find src/domain -name "*.rs" 2>/dev/null); do echo "=== $file ===" # Check for HTTP concerns grep -n "HttpResponse\|StatusCode\|axum::\|actix::\|Request\|Response" "$file" # Check for DB concerns grep -n "sqlx::\|diesel::\|query!\|execute\|Pool\|Connection" "$file" # Check for serialization in struct definitions grep -n "Serialize\|Deserialize\|Json<" "$file" done
2.2 Domain Should Contain
// GOOD: Domain content
pub struct User { ... } // Entities
pub struct Email(String); // Value objects
pub fn validate_email(s: &str) -> bool { ... } // Domain rules
pub trait DomainService { ... } // Domain services
pub enum DomainError { ... } // Domain errors2.3 Domain Should NOT Contain
// BAD: HTTP in domain
#[derive(Deserialize)] // Serialization concern
pub struct CreateUserRequest { ... }
// BAD: DB in domain
#[derive(sqlx::FromRow)] // Persistence concern
pub struct User { ... }
// BAD: Framework types in domain
pub fn handler(req: HttpRequest) { ... }---
Phase 3: Application Layer Boundary Audit
3.1 Application Layer Content Check
# Find application layer files find src/application -name "*.rs" 2>/dev/null # Check for misplaced responsibilities for file in $(find src/application -name "*.rs" 2>/dev/null); do echo "=== $file ===" # HTTP concerns (should be in adapters) grep -n "HttpResponse\|StatusCode\|Json<\|Path<\|Query<" "$file" # Direct DB queries (should use repository trait) grep -n "sqlx::query\|diesel::\|\.execute(\|\.fetch" "$file" # Framework routing grep -n "Router\|route\|get\|post\|put\|delete" "$file" done
3.2 Application Should Contain
// GOOD: Application content
pub struct RegisterUser { ... } // Use cases
pub trait UserRepository { ... } // Port traits
pub enum AppError { ... } // Application errors
pub async fn execute(&self) { ... } // Use case execution3.3 Application Should NOT Contain
// BAD: HTTP handlers in application
pub async fn register_handler(Json(body): Json<...>) -> impl IntoResponse { ... }
// BAD: Direct DB access
let user = sqlx::query!("SELECT * FROM users").fetch_one(&pool).await?;
// BAD: Concrete adapter types
pub struct RegisterUser {
db: PgPool, // Should be trait object
}---
Phase 4: Adapters Layer Boundary Audit
4.1 Adapter Content Check
# Find adapter layer files find src/adapters -name "*.rs" 2>/dev/null # Check for business logic leakage for file in $(find src/adapters -name "*.rs" 2>/dev/null); do echo "=== $file ===" # Complex business logic (should be in application/domain) grep -n "if.*&&.*&&\|match.*=>" "$file" | head -5 # Business validation (should be in domain) grep -n "validate\|is_valid\|check_" "$file" done
4.2 Adapters Should Contain
// GOOD: Adapter content
impl UserRepository for PostgresUserRepository { ... } // Port implementations
pub async fn register_handler(...) -> impl IntoResponse { ... } // HTTP handlers
pub fn app_error_to_response(e: AppError) -> Response { ... } // Error conversion
pub struct CreateUserDto { ... } // DTOs with serialization4.3 Adapters Should NOT Contain
// BAD: Business logic in adapter
pub async fn register_handler(...) {
// Business rules should be in use case
if password.len() < 8 { return Err(...) }
if !email.contains('@') { return Err(...) }
// ...
}
// BAD: MuA comprehensive development toolkit designed following Anthropic's Claude Code Best Practices for AI-assisted software development.
Repo: qdhenry/Claude-Command-Suite
Other commands on claude-command-suite.
- /boundary-bbcr-fallback
Execute automatic BBCR (Collapse-Rebirth Correction) when knowledge boundaries are exceeded or reasoning fails.
Open command - /boundary-detect
Analyze semantic position relative to knowledge boundaries to prevent hallucination and identify uncertainty zones.
Open command - /boundary-heatmap
Generate a visual heatmap of knowledge boundaries showing safe zones, risk areas, and semantic coverage.
Open command - /boundary-risk-assess
Evaluate the current risk level and provide detailed analysis of potential hallucination or reasoning failure.
Open command - /boundary-safe-bridge
Find and construct semantic bridges to safely navigate from current position to target concept without crossing dangerous boundaries.
Open command - /optimize-prompt
Takes an input prompt and returns ONLY a token-optimized version that preserves meaning while minimizing token count. Based on LLM tokenization principles: common words tokenize more efficiently, unusual words break into more tokens, and conciseness reduces cost.
Open command

