backend-logic

Enforce 5-layer Dart/Flutter architecture rules for backend development tasks.

Updated Mar 4, 2026
One-click install
npx skills add https://github.com/MHD-Nour-KJ/Intertwined --skill backend-logic
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: backend-logic
Source: https://github.com/MHD-Nour-KJ/Intertwined/tree/main/.agent/skills/backend-logic
Command: npx skills add https://github.com/MHD-Nour-KJ/Intertwined --skill backend-logic

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill eliminates the risk of implementing new backend features, refactors, or services for the Beautifully Done app that violate core architectural rules, repeat past mistakes, or introduce untestable, unmaintainable code by providing the full rationale behind every backend design decision.

Core Features & Use Cases

  • Full Architectural Rationale: Documents the "why" behind the 5-layer architecture, dependency injection setup, data model design choices, and database migration conventions.
  • Critical Guardrails & Rules: Explicitly calls out high-risk gotchas like private constructors breaking DI, incorrect DB clear order, and un-cancelled timer stream subscriptions that cause production bugs.
  • Use Case: For example, if you are adding a new feature that modifies task completion status and cascades changes to phases, this skill tells you to place the cascade logic in the Orchestrator layer (not the DAO or Provider) to maintain testability and avoid god classes.

Quick Start

Use the backend-logic skill to review the architectural rationale before implementing any new feature, refactor, or service for the Beautifully Done backend to avoid critical design mistakes.

Frequently Asked Questions about backend-logic

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

FAQPage Schema
How do I structure dependency injection in a Flutter offline-first app to maintain strict layer isolation?

To structure dependency injection in a Flutter offline-first app, use get_it to enforce strict 5-layer isolation. This prevents private constructors from breaking DI and ensures backend architecture remains testable and free of god classes.

What is the correct way to handle SQLite database migrations in an offline-first Dart architecture?

Correct SQLite database migrations in Dart require following specific database migration conventions and proper DB clear order. This prevents data corruption and ensures architectural consistency across application updates.

Why does my Flutter backend logic cause cascading changes to leak into the DAO or Provider layer?

Cascading changes leak into DAO or Provider layers because logic is misplaced. You must place cascade logic in the stateless Orchestrator layer to maintain testability, enforce strict layer isolation, and avoid creating god classes.

How do I handle errors in Dart backend architecture without breaking the orchestrator pattern?

Handle errors in Dart backend architecture by implementing Result<T> error handling patterns within the stateless orchestrator layer. This maintains testable strict layer isolation and prevents untestable code from spreading across your architecture.

What are the common gotchas when refactoring a 5-layer Flutter backend architecture?

Common gotchas when refactoring a 5-layer Flutter backend include using private constructors that break DI, incorrect DB clear order during SQLite migrations, and un-cancelled timer stream subscriptions that cause production bugs.

Can I use get_it for dependency injection across all 5 layers of a Dart backend?

Yes, you can use get_it for dependency injection across all 5 layers of a Dart backend. It enforces strict layer isolation, ensures correct DI setup, and prevents architectural mistakes like private constructors breaking dependency injection.