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.