architecture-patterns

Reviews module responsibilities and dependency direction in C, Go, Rust, and Zig codebases.

Updated Jul 4, 2023
One-click install
npx skills add https://github.com/kohdice/dotfiles --skill architecture-patterns-kohdice
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: architecture-patterns
Source: https://github.com/kohdice/dotfiles/tree/main/config/agents/skills/architecture-patterns
Command: npx skills add https://github.com/kohdice/dotfiles --skill architecture-patterns-kohdice

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It helps you judge whether code is placed in the right modules and whether dependencies point in allowed directions, so architecture reviews and new code placement follow citable conventions instead of personal taste. ## Core Features & Use Cases - Dependency Rule Enforcement: Detects core/domain code importing infrastructure, infrastructure types leaking into core signatures, dependency cycles, and layer skipping. - Responsibility Analysis: Flags god modules, utils/helpers dumping grounds, shotgun surgery, and units whose names no longer match their contents. - Language-Specific Catalogs: Provides sourced rules for Go (package naming, internal/, interface placement), Rust (lib/bin split, workspace DAGs, API guidelines), Zig (build.zig module declarations), and C (opaque pointers, include cycles). - Use Case: When adding a new feature to a Go service, use this Skill to verify the new package respects the project's declared layering and that no import edge points from domain logic toward HTTP or database infrastructure. ## Quick Start Ask the AI to review the dependency direction and module responsibilities of the changed packages in your repository using the architecture-patterns skill.

Frequently Asked Questions about architecture-patterns

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I check if my code violates clean architecture dependency rules?▼

Check the direction of every import edge: domain or core logic must not import infrastructure such as database drivers, HTTP frameworks, or CLI parsing. If core would gain an edge toward infrastructure, define the boundary type in core and adapt at the edge instead.

How to review Go package structure against official guidelines?▼

Judge against go.dev 'Organizing a Go module', the Google Go Style Guide, and Effective Go. Common violations include packages named util or common, packages that should live under internal/, interfaces defined at the producer instead of the consumer, and business logic inside cmd/ binaries.

Does this architecture review approach work for small CLI programs?▼

Small programs where formal layering would be over-engineering are explicitly accepted; absence of layers is not a defect unless the project claims them. However, existing wrong-direction dependency edges and cycles remain defects at any size.

What are common Rust architecture mistakes in workspace projects?▼

Common issues include binary crates holding all logic instead of a thin main.rs over lib.rs, workspace crates with mutual dependencies instead of a DAG, domain crates depending on framework crates like axum or sqlx, and public APIs leaking internals without re-exports.

When should a project's own declared architecture override general rules?▼

The project's declared architecture always wins. Discover it from README, ARCHITECTURE.md, ADRs, directory names, or doc comments assigning architectural roles, and judge against those rules first rather than imposing an architecture the project never adopted.

Why are unsourced architecture conventions not flagged in reviews?▼

A convention-based claim is only valid with a named source such as official language documentation or recognized pattern literature. Without a citable source the claim is personal opinion and must be omitted or explicitly marked as such.