agentleFS
pnppnp/powershell/.agents/skills/cmdlet-scaffolder/SKILL.md

cmdlet-scaffolder

Skill906 starsChanged 2 months agoMITView on GitHub

Generate a new PnP PowerShell cmdlet modelled on an existing sibling - class with the right base class and permission attributes, the documentation page, and the changelog entry. Use when adding a cmdlet for a Graph or CSOM API. Output is a draft needing verification against a real tenant.

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 3 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Before writing anything, pin down: cmdlet name (Verb-PnPNoun, approved verb, singular noun), the API being wrapped, the parameters, and the …

    line 24
  2. Distinctive:

    Check the name is not already taken, including as an alias:

    line 28
  3. Very specific:

    Read the sibling's class *and* its documentation/*.md page in full.

    line 45
  4. Distinctive:

    Use the Microsoft Learn MCP server for the endpoint, its request/response shape and its least-privilege permissions, delegated and …

    line 50
  5. Distinctive:

    Do not describe the result as tested, working, or verified.

    line 116

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Playbook: cmdlet-scaffolder

Generate a new cmdlet — class, attributes, documentation page and changelog entry — modelled on an existing sibling.

The output is a draft. You cannot call the API or run the cmdlet. Everything about the request shape, the response fields and the permission scopes is inferred. Hand it over labelled as such, with the inferences listed. A plausible, well-formed, subtly wrong cmdlet is the specific failure mode this playbook exists to avoid.

Conventions live in new-cmdlet; language rules in dotnet-standards. This playbook is the procedure.

Never commit, push, or open a PR. Leave the work in the tree and hand it over — see Human in the loop.

1. Establish the request

Before writing anything, pin down: cmdlet name (Verb-PnPNoun, approved verb, singular noun), the API being wrapped, the parameters, and the output shape. If the verb or noun is unsettled, ask — renaming later requires an [Alias] and a changelog entry.

Check the name is not already taken, including as an alias:

grep -rn 'Cmdlet(Verbs[A-Za-z]*\.[A-Za-z]*, "PnPTheNoun")' src/Commands --include=*.cs
grep -rn '\[Alias(' src/Commands --include=*.cs

2. Choose the sibling

This is the most important step. Find the closest existing cmdlet: same folder, same base class, same API, same verb. Prefer a recently modified one — helper signatures have evolved and old call shapes survive in the tree.

git log --diff-filter=M --name-only -20 -- src/Commands/<Area>

Read the sibling's class and its documentation/*.md page in full. You are matching a house style, not producing generic C#. Say which sibling you used.

3. Resolve the API

Use the Microsoft Learn MCP server for the endpoint, its request/response shape and its least-privilege permissions, delegated and application. Do not answer from memory — this is where generated cmdlets go wrong, and it is exactly what the permission attributes encode.

Record the Learn URL for each claim; it goes in the handover.

4. Write the class

Per new-cmdlet: correct base class, [Cmdlet], [OutputType], permission attributes, PipeBind parameters with validation attributes, ExecuteCmdlet() override.

  • Reuse existing PipeBinds and models. Only add a new model if nothing fits, one type per file, enums under src/Commands/Enums/.
  • Graph collections: GetResultCollection, not Get.
  • CSOM: ExecuteQueryRetry().
  • Destructive or overwriting: SupportsShouldProcess plus an actual ShouldProcess call and -Force.
  • Error messages into Resources.resx, not string literals.

5. Write the documentation page

documentation/<Verb-PnPNoun>.md, structure copied from the sibling page:

  • Front matter — Module Name, title, schema: 2.0.0, applicable, external help file, online version slug matching the cmdlet name exactly
  • ## SYNOPSIS — a Required Permissions block stating the same scopes as the attributes with the same delegated/application split, then a one-line summary. Omit the block entirely if the cmdlet carries ApiPermissionsNotRequired; adding one there contradicts the attribute and the existing pages
  • ## SYNTAX — one ```powershell block per parameter set
  • ## DESCRIPTION
  • ## EXAMPLES — at least one, realistic, each followed by a sentence explaining it
  • ## PARAMETERS — alphabetical, one ```yaml block per parameter and nothing else fenced in this section, including the standard -Connection and -Verbose blocks copied verbatim from the sibling
  • ## RELATED LINKS

The YAML fields must agree with the attributes exactly — see docs-sync for the field mapping.

6. Changelog

One line under [Current nightly] → Added, cmdlet name in backticks, ending with a link to the PR or issue. Match the surrounding entries' tone: what it does and why someone would use it, not "added new cmdlet".

7. Build

dotnet build src/PnP.PowerShell.sln

Warning-clean. Do not touch src/Tests.

8. Hand over

Report:

  • Files created or changed
  • The sibling you modelled on
  • Inferred, not verified — every API shape, response field and permission scope, each with the Learn URL it came from
  • The invocation a maintainer should run against a tenant to verify, including which connection type (delegated and app-only both, where the cmdlet supports both)
  • Anything you could not resolve and what would settle it

Do not describe the result as tested, working, or verified. It has been compiled, and that is all.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.