Agent skill · github
system-commandline-cli
Use this skill when adding, modifying, or reviewing CLI commands in a .NET project built with System.CommandLine. Triggers include: creating a new CLI command, adding options or arguments, wiring command handlers, registering subcommands, building command groups, or any architecture decision about CLI command structure. Also use when the user mentions 'System.CommandLine', 'CommandBase', 'SetAction', 'ParseResult', 'RootCommand', 'subcommand', or asks to add a verb to the CLI. Do NOT use for general C# coding, web APIs, UI work, or non-CLI projects.
What it needs
About 5k tokens when loaded.
What this skill does
System.CommandLine CLI Developer Skill You are working on a .NET CLI application built with System.CommandLine v2.x.x, targeting .NET 8 or later or any .NET Standard 2.0 implementation, including .NET Framework 4.6.1 or later and .NET Core 2.0 or later. Follow these rules and patterns strictly when creating or modifying CLI commands. --- Architecture Overview --- RULE 1 — Prefer a Project-Specific Command Base Class Prefer defining a project-specific abstract CommandBase that inherits from System.CommandLine.Command. Concrete commands should inherit from this base class so shared behavior and conventions remain centralized. When the project already has a command base class, preserve its established conventions. Otherwise, introduce one when commands need shared behavior; simple applications may inherit from Command directly when a base class adds no meaningful value. --- RULE 2 — Options and Arguments Defining Options Defining Arguments (positional) Reading Values in Handlers --- RULE 3 — Command Handler Pattern Handlers are async methods wired via SetAction: --- RULE 4 — Command Group (Parent with Subcommands) A group command registers children but does not call SetAction: A command may define both an action and subcommands when the direct invocation has meaningful behavior. --- RULE 5 — Registration Top-level commands → register in RootCommand.cs: Subcommands → register inside the parent command's constructor: --- RULE 6 — User Confirmation for Destructive Operations --- RULE 7 — Command Logic The logic of each command should be in one or more service classes that implement interfaces. The command receives interfaces through dependency injection (DI), not concrete implementations. The command handler should not contain business logic. The command handler should be thin, responsible only for: 1. Parsing input 2. Validating configuration 3. Calling the service method 4. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills github/system-commandline-cli