feature-structure

Reorganize modules into four-layer feature boundaries with strict import rules.

3|2|Updated Mar 15, 2026
One-click install
npx skills add https://github.com/beeman/skills --skill feature-structure-beeman
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: feature-structure
Source: https://github.com/beeman/skills/tree/main/feature-structure
Command: npx skills add https://github.com/beeman/skills --skill feature-structure-beeman

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Use when reorganizing code around feature boundaries, splitting monolithic screen components or state hooks, deciding whether logic belongs in data-access, feature, ui, or child features, or moving orchestration out of prop-heavy UI files.

Core Features & Use Cases

  • Enforces a four-layer architecture: data-access, feature or feature-<app>, ui or ui-<app>, and optional util, with clear import boundaries.
  • Guides parent-child feature decomposition to manage gating, prerequisites, and workflow orchestration.
  • Preserves repository naming conventions and minimizes disruption by reusing existing wiring and layout where possible.

Quick Start

Refactor the repository's feature code into a parent feature with child features and separate UI leaves following the four-layer boundaries.

Frequently Asked Questions about feature-structure

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

FAQPage Schema
How do I split monolithic screen components into distinct child features?

Split monolithic screen components by applying a four-layer architecture with strict import boundaries, reorganizing them into parent features, child features, and separate leaf UI components. This decomposition moves orchestration logic out of prop-heavy UI files into explicit parent-child feature contracts.

What is the four-layer pattern for structuring feature boundaries?

The four-layer pattern organizes code into data-access, feature or feature-<app>, ui or ui-<app>, and optional util layers. It enforces strict import boundaries between these layers to clearly separate data fetching, business orchestration, and presentation concerns.

How do I decide if logic belongs in data-access, feature, or ui layers?

Logic placement follows strict four-layer import boundaries: data-access handles data fetching, feature manages workflow orchestration and gating, and ui handles presentation. This separation prevents prop-heavy UI files and keeps modules aligned with feature boundaries.

What's the best way to refactor code around feature boundaries without disrupting existing wiring?

Refactor around feature boundaries by reusing existing wiring and layout where possible, moving monolithic screens into parent and child features while preserving repository naming conventions. This approach minimizes disruption while establishing strict parent-child feature contracts.

When do I need to reorganize modules by feature boundaries?

Reorganize modules by feature boundaries when splitting monolithic screen components or state hooks, deciding where logic belongs across data-access and UI layers, or moving orchestration out of prop-heavy UI files into explicit parent-child feature contracts.