Post 2 walked through create.md exactly as it exists today: environment checks with m365 spfx doctor, a fully non-interactive scaffold command, dependency install discipline, and toolchain-aware packaging. It’s a solid, functional reference — and using it for a while surfaces a few places where it could grow.

To be clear up front: none of what follows is a criticism, and none of it is announced by the maintainers. These are our own proposals, each with a runnable command attached, that we plan to test against real SPFx projects before considering a pull request to SharePoint/spfx-dev-skills. Think of this post as the working notes before that PR, not the PR itself.

Proposal 1: Scaffold Commands for Library and Adaptive Card Extension

create.md shows full, copy-pasteable flag examples for exactly two of the four component types the skill pack’s own README lists: WebPart and Extension. Library and Adaptive Card Extension (ACE) get no example at all — which means an agent asked to scaffold either one has to improvise the flags from the WebPart/Extension pattern instead of following an explicit instruction.

Proposed addition — scaffolding a Library:

yo @microsoft/sharepoint --solution-name "<name>" --component-type library --component-name "<LibraryName>" --skip-install --no-insight

Proposed addition — scaffolding an Adaptive Card Extension:

yo @microsoft/sharepoint --solution-name "<name>" --component-type adaptiveCardExtension --component-name "<ACEName>" --framework react --skip-install --no-insight

Why this helps an agent specifically: the whole point of non-interactive flags is removing guesswork. An agent that has to infer --component-type library by analogy from the WebPart example is back to doing exactly the kind of pattern-matching that causes the invented-package-version problem from post 1. Explicit examples for all four types close that gap completely.

Proposal 2: Adding a Component to an Existing Solution

create.md as written only covers scaffolding a brand-new solution. In practice, a huge share of real SPFx work is adding a second (or fifth) component to a solution that already exists — and that workflow looks meaningfully different: you don’t pass --solution-name again, because you’re not creating a new solution.

Proposed addition:

cd <existing-solution-folder>
yo @microsoft/sharepoint --component-type webpart --component-name "<NewWebPartName>" --framework react --skip-install --no-insight

The generator detects the existing .yo-rc.json and scaffolds the new component into the existing solution structure rather than creating a new one.

Why this helps an agent specifically: without this documented, an agent following create.md literally would either try to create a whole new solution alongside the existing one, or pass --solution-name again and risk the generator prompting to overwrite files — reintroducing exactly the interactive-prompt problem the rest of the file works hard to eliminate.

Proposal 3: –sharepoint-version for On-Premises Targets

The Yeoman generator supports a --sharepoint-version flag (sp2016, sp2019, or spo) that isn’t mentioned anywhere in create.md. Left unspecified, the generator scaffolds for the newest supported target — which, for a team building against an on-premises SharePoint 2019 farm, produces a project that won’t deploy where they need it to.

Proposed addition:

yo @microsoft/sharepoint --solution-name "<name>" --framework react --component-type webpart --component-name "<WebPartName>" --sharepoint-version spo --skip-install --no-insight

And a one-line decision rule to go with it: before scaffolding, confirm the target environment (SPO, SP2019, or SP2016) rather than assuming SPO. If the user or project context doesn’t specify one, spo remains a reasonable default — but it should be a deliberate default, stated in the doc, not a silent one.

Why this helps an agent specifically: this is the kind of mismatch that doesn’t surface until deployment fails, often much later in a project than scaffolding — by which point the cost of having guessed wrong is far higher.

Proposal 4: Post-Scaffold Validation and Commit-Immediately

create.md ends at packaging. Nothing in it validates that the scaffold itself succeeded cleanly before an agent starts writing custom code on top of it, and nothing establishes a clean git baseline — which post 4 of this series shows is a hard precondition for upgrade.md later on.

Proposed addition — validate immediately after install:

npm run build

(or heft build directly, depending on toolchain — see post 2’s Heft/gulp table). Run this before touching a single line of custom code. A scaffold that fails to build on its own is much cheaper to diagnose than one that fails after three files of customization have been layered on top.

Proposed addition — commit immediately after a validated scaffold:

git init
git add -A
git commit -m "Initial SPFx scaffold"

Why this helps an agent specifically: this one is close to free. It costs two commands and gives every future operation — including upgrade.md‘s explicit clean-git-state requirement — a trivial, already-satisfied starting point instead of a separate ask later in the project’s life.

Testing Before Proposing

All four of these are proposals, not settled additions — the next step on our side is running each one against a handful of real SPFx projects (a fresh web part, an ACE, a multi-component solution, an on-prem target) before drafting anything for SharePoint/spfx-dev-skills‘s CONTRIBUTING.md process. That PR is a separate effort from this blog series, and we’ll link it here once it exists.

This series will keep the same pattern for the other three reference files: a pillar post covering what’s there today, immediately followed by its own roadmap post like this one. Next up: upgrade.md — how the skill governs version upgrades — and the roadmap post right behind it on rollbacks, incremental jumps, and CI-friendly output.

Source note: The baseline described in this post — what create.md currently covers — is drawn from SharePoint/spfx-dev-skills, specifically plugins/spfx/skills/spfx/references/create.md, and detailed in full in post 2. Every proposal in this post is our own, not sourced from the repo, and is marked as such throughout.