architecture

Enforce downward-only imports across app, features, shared, and platform boundaries.

Updated Mar 1, 2026
One-click install
npx skills add https://github.com/murphyjoseph/dojo-kit --skill architecture-murphyjoseph
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: architecture
Source: https://github.com/murphyjoseph/dojo-kit/tree/main/skills/architecture
Command: npx skills add https://github.com/murphyjoseph/dojo-kit --skill architecture-murphyjoseph

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Boundary-first architecture helps teams place code and manage imports so responsibilities are clear, reducing cross-feature coupling and making app boundaries obvious.

Core Features & Use Cases

  • Enforce downward-only imports: app/ → features/ → shared/ → platform/
  • Promote shared utilities only after proven need; duplicate otherwise
  • Define layer boundaries for routes, features, shared, and platform; support cross-cutting services like logging/analytics
  • Ensure portable, framework-agnostic feature boundaries to enable feature portability

Quick Start

Place a new file or component in the correct boundary (app/, features/, shared/, or platform/) using downward imports and minimal cross-boundary dependencies.

Frequently Asked Questions about architecture

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

FAQPage Schema
How do I enforce import boundaries and control file placement in a frontend project structure?▼

Boundary-first architecture enforces import boundaries by restricting import flow downwards: app/ to features/ to shared/ to platform/. This controls file placement and makes code ownership clear across the frontend project structure.

What is the best way to organize shared utilities and feature directories to prevent cross-feature coupling?▼

Organize shared utilities by duplicating code initially, then promoting to shared/ only after proven need at 2-3 instances. This prevents premature abstraction and keeps feature directories decoupled.

When do I need boundary-first architecture for my codebase?▼

You need boundary-first architecture when cross-feature coupling becomes complex and code ownership is unclear. It codifies layer boundaries for routes, features, shared, and platform to make app boundaries obvious.

Does this boundary-first architecture approach work with cross-cutting concerns like logging and analytics?▼

Yes, boundary-first architecture supports cross-cutting services like logging, analytics, and feature flags. These concerns are handled without breaking the downward import flow or portable feature boundaries.

Why should I duplicate code instead of creating premature abstractions in shared directories?▼

Duplicating code avoids premature abstractions that create unwanted dependencies across features. You promote a utility to shared/ only after 2-3 proven instances, ensuring the abstraction is genuinely needed.

Can I use this project structure approach to scaffold initial app directories and components?▼

Yes, apply these boundary rules during initial project scaffolding. It guides where new files, directories, components, hooks, and utilities should live within app/, features/, shared/, or platform/ from the start.