architecture-guardrails

Enforce repository architecture guardrails across backend services, routers, analytics, frontend, and MCP surfaces.

Updated May 17, 2026
One-click install
npx skills add https://github.com/cheetah-alo/NegritaOS --skill architecture-guardrails
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: architecture-guardrails
Source: https://github.com/cheetah-alo/NegritaOS/tree/main/.codex/skills/architecture-guardrails
Command: npx skills add https://github.com/cheetah-alo/NegritaOS --skill architecture-guardrails

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

architecture-guardrails prevents chaotic growth of a modular system by enforcing clear ownership, stable boundaries, and deterministic source-of-truth rules whenever changes affect how moneyflowlist components interact.

Core Features & Use Cases

  • Boundary discipline across layers: Routes HTTP/REST transport into routers, while domain behavior stays in Python services to avoid tight coupling.
  • Single source of truth for rules and contracts: Keeps governance, prompts, and skill/workflow rules under .codex/, and declarative rule assets and definitions under backend/app/rules/ and backend/app/configs/.
  • Cross-surface consistency checks: Ensures the same concept behaves identically across backend APIs, analytics outputs, and MCP surfaces when a boundary is touched.

Quick Start

Use architecture-guardrails when you are about to add or move a subsystem and want to confirm the correct folder boundaries, ownership, and traceability rules before you implement.

Frequently Asked Questions about architecture-guardrails

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

FAQPage Schema
How do I enforce architecture boundaries when refactoring backend services and API routers?

Architecture boundaries are enforced by routing HTTP transport into thin routers while keeping domain logic in Python services, ensuring loose coupling and clean ownership across moneyflowlist components during refactors.

What is the single source of truth for declarative rules and governance assets?

Declarative rules and governance assets require a single source of truth, placing governance under the .codex directory while keeping rule definitions and configurations organized under backend/app/rules/ and backend/app/configs/.

How do I keep behavior consistent across backend APIs, analytics, and MCP surfaces?

Cross-surface consistency is maintained by validating that identical concepts behave uniformly across backend APIs, analytics outputs, and MCP surfaces whenever system boundaries or ownership are modified.

When do I need to validate traceability and ownership before moving a subsystem?

Traceability and ownership validation is needed before adding or moving a subsystem to confirm correct folder boundaries, state flow rules, and cross-package responsibilities prior to implementation.

Can I reuse domain service logic across frontend and MCP surfaces without tight coupling?

Domain service logic is reused across frontend and MCP surfaces by requiring thin transport layers for routing, which prevents tight coupling and maintains auditability across different transport protocols.