reuse-first

Enforces reuse of existing Angular kit components before creating new UI primitives.

1|Updated Jan 14, 2024
One-click install
npx skills add https://github.com/Eyhenij/rt-tools --skill reuse-first-eyhenij
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: reuse-first
Source: https://github.com/Eyhenij/rt-tools/tree/main/.claude/skills/reuse-first
Command: npx skills add https://github.com/Eyhenij/rt-tools --skill reuse-first-eyhenij

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams repeatedly rebuild components, styles, and message handling that already exist in their shared UI kit, producing inconsistent screens and duplicated code that linters and builds never catch. ## Core Features & Use Cases - Reuse-First Workflow: Defines a decision flow for new screens, components, and fields — read the ready-made kit first, extend it where it lives, and only build custom primitives with explicit owner approval. - Bypass Detection Signs: Catalogs concrete signals of reinvention, such as native controls where the kit ships its own, hand-built overlays, inline template:/styles: in decorators, and layout declared in screen styles instead of shared BEM directives. - Configurable Sign Bundles: Loads per-package sign sets via reuse.bundles, tree-specific signs via reuse.signals, and kit directive exemptions via reuse.kitDirectives, so the guard and the full audit read the same declared sets. - Use Case: Before adding a new Angular form field or edit panel, load this rule to check @rt-tools/ui-kit / ui-kit-v2 components and base classes (RtFormControlBase, RtRouteAsideComponent), inherit the shared base, and route success/failure through the shared notification bus instead of custom markup. ## Quick Start Load the reuse-first rule before creating any new Angular screen, component, field, store, or service, and follow its flow to extend the existing kit rather than writing a parallel implementation.

Frequently Asked Questions about reuse-first

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

FAQPage Schema
How do I avoid duplicating existing Angular components when building new screens?

Start by reading the existing kit components and base classes before writing any file. If the ready-made fits, use it as is; if it almost fits, extend it in the kit or base class so other screens benefit. Only create a custom primitive after explicit owner approval.

What are the signs that a UI kit component was bypassed?

Signs include native controls where the kit ships its own, hand-built failure or loading markup, custom overlays with own backdrop styles, layout in a screen's styles file instead of shared BEM directives, inline `template:` or `styles:` in decorators, and reimplementing what a base class provides.

When is an inline error message allowed instead of the shared notification bus?

An inline message is lawful only where a record edit panel stays open after a failure, since the panel base holds it. Screens, lists, and public pages must report success and failure through the shared notification bus, not custom markup.

How do I mark a justified departure from the shared UI kit?

Place a `native-ok` marker comment on the line, but only after reading the kit's inventory. The explanation next to the marker must name the kit component and what it lacks; a marker without that justification acts as a silencer, not a recorded decision.

Why does the reuse guard stay silent on some edits?

A guard that received no declared sign bundles is indistinguishable from one with nothing to refuse. Check that the tree declares its sets via the `reuse.bundles` key and its own signs via `reuse.signals` before treating silence as a sign of order.

Should each Angular component use separate template and style files?

Yes, a component is declared in three files: `.ts`, `.html`, and `.scss`. Inline `template:` and `styles:` in the decorator, `style=` attributes, and `[ngStyle]` resizing bypass both the kit and stylelint, and count as reinvention signs.