Add direct skill browser to interactive shell

Author: KSemenenko

AGENTS.md

@@ -107,6 +107,7 @@ Treat explicit frustration, swearing, sarcasm, repeated rejection, or "don't do
 - In the interactive shell, when a newer `dotnet-skills` tool version is available, keep that status visible on the main control-center screen instead of relying on a one-time notice that disappears before the home UI renders.
 - In the interactive shell, outdated-skill refresh must expose a direct `Update all skills` action wherever outdated installed skills are detected. Review-style multi-select update flows may remain as secondary actions, but bulk update cannot be hidden behind them.
 - In the interactive shell home screen, keep `Update all skills` visible as a first-class action even when no outdated skills are currently detected. In the zero-outdated case, keep the action callable and return a clear no-op status instead of hiding the entry.
+- In the interactive shell, expose a first-class direct `Skills` browse/install surface for people who want to inspect or pick individual skills without going through `Collections` or `Bundles` first. Collection- and bundle-first flows may stay primary for taxonomy and grouped installs, but direct individual-skill browsing cannot be missing.
 - When replacing the interactive shell home or entry UX, remove the superseded legacy menu flow from the published tool instead of leaving a parallel flat prompt path behind the new control center.
 - In the interactive shell, escape Spectre markup syntax in every prompt choice label and prompt-only caption before rendering selection or multi-selection pickers. Keep a regression test that covers labels containing brackets and `.NET` text from bundle or collection surfaces.
 - Interactive collection, analysis, bundle, installed, and agent pages must not ship as giant spreadsheet-style matrices. Each page needs an intentional dominant pane plus supporting card-style summaries; use a large table only when it is clearly the best representation for that page instead of the default.

README.md

@@ -58,7 +58,7 @@ agents install router --auto                # same agent install flow without th
 
 | Command | Description |
 |---------|-------------|
-| `dotnet skills` | Open the interactive control center with collection browsing, analysis, and install preview |
+| `dotnet skills` | Open the interactive control center with direct skill browsing, collections, analysis, bundles, and install preview |
 | `dotnet skills version` | Show the current installed tool version and check whether NuGet has a newer release |
 | `dotnet skills list` | Show the current inventory, compare project/global scope when relevant, and keep the remaining catalog as a compact collection summary |
 | `dotnet skills bundle list` | Show the focused bundles that expand into related skills by collection or workflow |
@@ -88,7 +88,7 @@ Use `--agent` to target a specific agent platform, `--scope` to choose global or
 
 `dotnet-skills` remains the skill-first CLI and still supports `dotnet skills agent ...` for compatibility. The dedicated agent-only surface is published in both forms: `dotnet-agents` for `dotnet agents ...` and `agents` for `agents ...`. Both top-level `list`, `install`, `remove`, and `where` commands target orchestration agents directly.
 
-The interactive shell behind bare `dotnet skills` is the main control center: it exposes `Collection -> Lane -> Skill` browsing, package-signal analysis, token hotspots, a full tree view, and install preview before files are written.
+The interactive shell behind bare `dotnet skills` is the main control center: it exposes a direct individual-skill picker, `Collection -> Lane -> Skill` browsing, package-signal analysis, token hotspots, a full tree view, and install preview before files are written.
 
 The public site mirrors the same surface now: `Packages`, `Bundles`, `Collections`, `Skills`, `Agents`, and `About`. The published GitHub Pages output uses the same collection taxonomy as the CLI instead of the old manifest-category grouping.