liftera-architecture

Enforce Liftera monorepo architecture rules for code placement and dependency scoping.

Updated Jan 15, 2026
One-click install
npx skills add https://github.com/estebandrg/liftera --skill liftera-architecture
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: liftera-architecture
Source: https://github.com/estebandrg/liftera/tree/main/skills/liftera-architecture
Command: npx skills add https://github.com/estebandrg/liftera --skill liftera-architecture

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Liftera monorepo architecture patterns and best practices that ensure code lives in the correct locations, preventing ad-hoc imports and tangled dependencies.

Core Features & Use Cases

  • ALWAYS keep application code inside apps/*.
  • ALWAYS keep reusable code inside packages/*.
  • NEVER import app code from another app; extract shared logic into a package.
  • ALWAYS design packages to be platform-agnostic and expose stable entrypoints.
  • NEVER duplicate UI or utilities across apps; centralize in packages/ui.
  • ALWAYS enforce dependency discipline at the package level to minimize root-level changes.

Quick Start

Review the Liftera architecture guidelines when planning a new change, ensuring new code resides under apps/ or packages/ with clear ownership and entrypoints.

Frequently Asked Questions about liftera-architecture

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

FAQPage Schema
How do I enforce monorepo architecture rules for apps and packages?▼

To enforce monorepo architecture rules, keep application code inside apps/* and reusable code inside packages/*. This prevents ad-hoc imports and tangled dependencies by ensuring code lives in correct locations with clear ownership.

Why does importing app code from another app break monorepo architecture?▼

Importing app code from another app breaks monorepo architecture because it creates tangled dependencies. You should never import across apps; instead, extract shared logic into a package to maintain proper cross-app collaboration boundaries.

What is the best way to organize reusable code in a monorepo?▼

The best way to organize reusable code in a monorepo is to centralize it inside packages/*. You should never duplicate UI or utilities across apps; instead, design platform-agnostic packages with stable entrypoints to ensure dependency discipline.

When do I need to extract shared logic into a package in a monorepo?▼

You need to extract shared logic into a package when multiple apps require the same functionality. This enforces dependency discipline at the package level and ensures reusable code remains platform-agnostic with stable entrypoints, minimizing root-level changes.

Can I duplicate UI components across different apps in a monorepo?▼

No, you should never duplicate UI or utilities across apps in a monorepo. Instead, centralize shared UI inside packages/ui to maintain dependency discipline and ensure code lives in the correct locations with clear ownership.

Does this monorepo architecture guidance apply to new packages and apps?▼

Yes, this monorepo architecture guidance applies to repository changes, new packages, and new apps. It ensures code lives in the correct locations and dependencies stay well-scoped when planning any structural addition to the monorepo.