scope-rule-architect-angular

Enforce Angular 20+ architecture with standalone components and the Scope Rule.

2|Updated Jul 29, 2025
One-click install
npx skills add https://github.com/kurojs/EnderDots --skill scope-rule-architect-angular-kurojs
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: scope-rule-architect-angular
Source: https://github.com/kurojs/EnderDots/tree/main/.config/opencode/skills/angular
Command: npx skills add https://github.com/kurojs/EnderDots --skill scope-rule-architect-angular-kurojs

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents Angular projects from becoming unmaintainable by enforcing consistent, shared-vs-local code placement and modern Angular 20+ architecture patterns.

Core Features & Use Cases

  • Standalone-first Angular 20+ architecture: Requires standalone components, signal-driven state management, OnPush change detection, and modern template syntax (e.g., @if/@for/@switch, @defer).
  • Unbreakable Scope Rule: Forces a strict decision boundary so code used by 2+ features goes in shared/global directories, while code used by only 1 feature stays local with no exceptions.
  • Screaming Architecture: Structures folders so feature names describe business functionality, with main components matching feature names for instant readability.
  • Practical re-structure guidance: Uses a decision framework to count feature usage, validate against Angular best practices, and document placement decisions.

Quick Start

Apply the scope rule when you add a new component or service by counting exactly how many features consume it, then place it in shared/global only when it is used by 2+ features and keep it local otherwise.

Frequently Asked Questions about scope-rule-architect-angular

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

FAQPage Schema
How do I enforce the Scope Rule in Angular to manage shared vs local components?

The Scope Rule in Angular enforces a strict decision boundary: code used by 2+ features goes in shared/global directories, while code used by only 1 feature stays local. This prevents unmaintainable projects by ensuring consistent code placement with no exceptions.

How do I structure Angular folders using Screaming Architecture for better readability?

Screaming Architecture structures Angular folders so feature names describe business functionality, with main components matching feature names for instant readability. This directs component, service, template, and folder placement based on feature usage.

Does this Angular architecture approach support standalone components and signals?

Yes, this architecture approach requires standalone components, signal-driven state management, inject() usage, and modern template control flow like @if/@for/@switch. It targets Angular 20+ with OnPush change detection and typed reactive forms without legacy NgModules.

What is the best way to decide where to place a new Angular service or component?

The best way to place a new Angular service or component is counting exactly how many features consume it. Apply the scope rule during refactoring or ongoing development: validate against Angular best practices, document placement decisions, and use shared directories only for 2+ feature usage.

Can I apply the Scope Rule when refactoring an existing Angular application?

Yes, you can apply the Scope Rule when refactoring existing Angular applications that use standalone components and signals. It provides practical re-structure guidance using a decision framework to count feature usage, validate against best practices, and document placement decisions.

Why does my Angular project become unmaintainable without strict feature boundaries?

Angular projects become unmaintainable without strict feature boundaries because shared and local code placement becomes inconsistent. Enforcing the Scope Rule and Screaming Architecture naming prevents this by directing component, service, template, and folder placement based on exact feature usage.