ironmind-data-layer

Enforce a three-layer Pages-Controllers-Services-Firebase data architecture in the IRONMIND app.

Updated Aug 27, 2026
One-click install
npx skills add https://github.com/MorganDevInSA/ironmind --skill ironmind-data-layer
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ironmind-data-layer
Source: https://github.com/MorganDevInSA/ironmind/tree/main/.cursor/skills/ironmind-data-layer
Command: npx skills add https://github.com/MorganDevInSA/ironmind --skill ironmind-data-layer

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

The IRONMIND data architecture enforces a strict three-layer separation (Pages → Controllers → Services → Firebase) to prevent wiring gaps, dead services, and incomplete features in data-driven UI.

Core Features & Use Cases

  • Hard-layer separation: Pages call controllers, controllers call services, services use Firebase helpers.
  • Deterministic data flow: Clear boundaries reduce regressions when adding features or pages and mutations.
  • Onboarding guidance: Quick-start templates and recommended patterns for new domains.

Quick Start

Create a new domain feature by wiring a page to a controller, a controller to a service, and a Firebase helper integration, following the templates provided.

Frequently Asked Questions about ironmind-data-layer

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

FAQPage Schema
How do I enforce a three-layer data architecture in a TypeScript app?

A clean data architecture separates data access from UI by ensuring pages call controllers, controllers call services, and services handle Firebase interactions. This strict boundary prevents wiring gaps and dead services in data-driven UI.

How do I prevent direct Firebase calls in my UI pages and controllers?

Prevent direct Firebase calls by using centralized converters and Firebase helpers within services. Pages and controllers must interact with services rather than accessing raw Firebase data, ensuring disciplined data flow boundaries.

What's the best way to structure new features and mutations in a data-driven app?

The best way to structure features and mutations is wiring a page to a controller, a controller to a service, and a Firebase helper integration. Following these templates ensures deterministic data flow and reduces regressions when adding pages.

Does this three-layer architecture approach work for Firebase and TypeScript projects?

Yes, this three-layer architecture is designed for Firebase and TypeScript projects. It requires pages to call controllers, controllers to call services, and services to call Firebase wrappers, using centralized converters to manage data boundaries.

Why does my data-driven UI have wiring gaps and dead services?

Data-driven UI develops wiring gaps and dead services when strict three-layer separation is missing. Enforcing boundaries where pages call controllers and controllers call services prevents incomplete features and regressions during development.