tab-name-normalization

Implements shared trim-based normalization and duplicate rejection for tab name add and edit operations.

Updated Jul 21, 2026
One-click install
npx skills add https://github.com/masakinihirota/2026src-ni --skill tab-name-normalization-masakinihirota
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: tab-name-normalization
Source: https://github.com/masakinihirota/2026src-ni/tree/main/.agents/skills/tab-name-normalization
Command: npx skills add https://github.com/masakinihirota/2026src-ni --skill tab-name-normalization-masakinihirota

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When multiple screens manage tab names independently, inconsistent validation rules cause duplicate names, empty labels, and divergent behavior between add and edit flows. This Skill centralizes the naming rules so every tab-management screen behaves identically. ## Core Features & Use Cases - Unified Normalization Logic: Enforces trim-based canonicalization, empty-string rejection, and duplicate rejection through one shared function used by both add and edit paths. - Layered Architecture Guidance: Keeps validation decisions in the logic layer while the UI layer handles only error display and control flow. - Minimal Test Coverage: Defines a focused test set covering initial names, add-time duplicates, edit-time duplicates, and empty-string edit preservation. - Use Case: When renaming tabs across /work, /values, and /skills screens, apply this Skill to guarantee that a name rejected on one screen is rejected everywhere, then verify with the direct tests and a production build. ## Quick Start Ask the AI to apply the tab name normalization rules when adding or renaming a tab so trimming, empty-string rejection, and duplicate checks stay consistent across all screens.

Frequently Asked Questions about tab-name-normalization

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

FAQPage Schema
How do I prevent duplicate tab names in a web app?▼

Prevent duplicate tab names by routing both add and edit operations through one shared validation function that trims the input and rejects names already in use. Keeping the check in the logic layer ensures every screen enforces the same rule.

How to normalize user input for tab or label names?▼

Normalize tab names by applying trim() and treating the trimmed value as the canonical string for storage and comparison. Reject the result if it becomes an empty string, and on edit operations keep the original name instead.

Should tab name validation live in the UI or logic layer?▼

Tab name validation belongs in the logic layer, with the UI layer responsible only for error display and control flow. This separation prevents divergent rules when multiple screens manage the same tab data.

What tests are needed for tab rename validation?▼

A minimal test set covers initial default names, duplicate rejection on add, duplicate rejection on edit, and empty-string edits preserving the original name. After changes, run the direct tests and a full build to confirm completion.

When should I not use a shared tab naming rule?▼

A shared naming rule is unnecessary when tabs are scoped per user or per workspace where duplicates across contexts are acceptable. In those cases, scope the duplicate check to the relevant collection rather than a global list.