admin-nav-item

Defines admin menu items and route addresses through a single navigation declaration.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Admin navigation often drifts into two sources of truth: menu items declared in one place and route gating declared in another, producing bugs like hidden items whose pages still open. This Skill encodes the navigation pattern that keeps one declaration as the source for both items and route gating. ## Core Features & Use Cases - Single declaration per item and route: Addresses, dictionary keys, rights, and section flags live in one container util, preventing drift between menu visibility and route access. - Items without screens: Declare placeholder items without rights or addresses, using aria-disabled with paired styles and hint wrappers instead of native disabled. - Address nesting and highlighting: Section addresses nest via route children, active-section highlighting comes from the router rather than computed state, and domain counters reach the header through an InjectionToken. - Use Case: When adding a new admin section with a panel, declare the item once, nest the screen under the section segment in app.routes.ts, and let the router drive highlighting without maintaining exception lists. ## Quick Start Ask the AI to add a new admin menu item with a section address following the navigation pattern, including rights, nesting, and highlight behavior.

Frequently Asked Questions about admin-nav-item

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

FAQPage Schema
How do I add a new admin menu item with a route?

Declare the item once in the container util with its address, dictionary keys, and rights, then nest the screen under the section segment in app.routes.ts using children. The same declaration drives both menu visibility and route gating.

How do I show a menu item before its screen exists?

Declare the item without rights and without an address so it stays visible to everyone. Use aria-disabled with a paired [aria-disabled='true'] style rule and a hint wrapper, never the native disabled attribute, so keyboard users can still reach the explanation.

Why should menu highlighting come from the router instead of computed state?

Computing the active item from router events creates a second source of truth that diverges on parameterized addresses or open panels. Letting the router highlight the item whose address is open keeps one answer, and panel outlets do not knock the highlight off.

Why does the navigation declaration forbid importing the shell?

Importing shell from the declaration closes the dependency graph into a cycle, which the layer check (npm run check:layers) rejects. The declaration must stay dependency-free so it can serve as the shared source for items and gating.

When should I not use this navigation pattern?

Do not use it for record edit panels; that case belongs to the entity-aside pattern instead. This pattern covers menu items, sections with panels, and screen addresses only.