agentleFS
MicrosoftKnown publishermicrosoft/powerplatform-build-tools/.claude/skills/pac-cli-update/SKILL.md

pac-cli-update

Skill314 starsChanged 7 months agoMITView on GitHub

Bump PAC CLI binary version and/or cli-wrapper npm package. Always produces two PRs — main and release/stable.

  • Reads credentials
  • Installs packages
  • Commits and pushes

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. About 0 are common, 7 are distinctive, and 6 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 6

    Very specific

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

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

    If last sync was > 7 days ago or missing: run /knowledge-sync inline, then continue.

    line 29
  2. Distinctive:

    If the version does not exist on nuget.org, stop and report — do not create a PR for a non-existent version.

    line 45
  3. Very specific:

    Add a new entry under {{NextReleaseVersion}}: (do not remove the placeholder — it stays):

    line 79
  4. Distinctive:

    If additional changes are in this update (new task, Node target bump, etc.), add bullet points below the pac CLI line.

    line 86
  5. Very specific:

    Only do this if a <wrapper-version> argument was given OR if the cli-wrapper changelog explicitly requires the new pac CLI version:

    line 92
  6. Very specific:

    If updating, bump "@microsoft/powerplatform-cli-wrapper" in package.json dependencies and run npm install.

    line 99
  7. Distinctive:

    If restore fails (pac CLI version not found), the version does not exist — stop and report.

    line 114
  8. Distinctive:

    Create the main-branch PR:

    line 127
  9. Distinctive:

    Create the release PR:

    line 171
  10. Very specific:

    Never update only one of the two nuget.json packages — both must match

    line 234
  11. Distinctive:

    Never skip the release/stable PR — every CLI update needs both

    line 235
  12. Distinctive:

    Never cherry-pick to release/stable without verifying the main PR CI passes first

    line 236
  13. Very specific:

    If the Linux pac CLI package (Microsoft.PowerApps.CLI.Core.linux-x64) doesn't have the new version yet, wait — don't ship with mismatched …

    line 238

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 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

PAC CLI Update — PAC CLI and cli-wrapper version bump

Handles the most common update in this repo: bumping the PAC CLI binary version and/or the @microsoft/powerplatform-cli-wrapper npm package.

Invoke as:

  • /pac-cli-update <pac-version> — e.g. /pac-cli-update 1.53.2
  • /pac-cli-update <pac-version> <wrapper-version> — when cli-wrapper also has a new version

Always produces two PRs: one targeting main, one targeting release/stable. This is the standard release pattern for this repo — never merge a CLI update to only one branch.


Step 0 — Sync knowledge if stale

grep "## Last sync" memory/ado-knowledge.md 2>/dev/null | tail -1

If last sync was > 7 days ago or missing: run /knowledge-sync inline, then continue.


Step 1 — Verify the new PAC CLI version exists on nuget.org

# Confirm the version is published before touching any files
curl -s "https://api.nuget.org/v3-flatcontainer/microsoft.powerapps.cli/index.json" \
  | node -e "const d=JSON.parse(require('fs').readFileSync('/dev/stdin','utf8')); console.log(d.versions.slice(-5).join('\n'))" 2>&1

# Confirm the linux package also exists (both must be present)
curl -s "https://api.nuget.org/v3-flatcontainer/microsoft.powerapps.cli.core.linux-x64/index.json" \
  | node -e "const d=JSON.parse(require('fs').readFileSync('/dev/stdin','utf8')); console.log(d.versions.includes('<pac-version>') ? 'linux: found' : 'linux: NOT FOUND')" 2>&1

If the version does not exist on nuget.org, stop and report — do not create a PR for a non-existent version.


Step 2 — Sync with origin/main and create the main branch

git fetch origin 2>&1
git checkout main 2>&1
git merge origin/main --no-edit 2>&1
git checkout -b users/<alias>/cli-version-<pac-version> 2>&1

Step 3 — Update nuget.json

Edit both packages to the new version:

{
  "packages": [
    { "name": "Microsoft.PowerApps.CLI",              "version": "<pac-version>", ... },
    { "name": "Microsoft.PowerApps.CLI.Core.linux-x64", "version": "<pac-version>", ... }
  ]
}

Both packages must always use the same version. Never update only one.


Step 4 — Update extension/overview.md

Add a new entry under {{NextReleaseVersion}}: (do not remove the placeholder — it stays):

{{NextReleaseVersion}}:
- pac CLI <major.minor>, [Release Notes on nuget.org](https://www.nuget.org/packages/Microsoft.PowerApps.CLI/<pac-version>#releasenotes-body-tab)

If additional changes are in this update (new task, Node target bump, etc.), add bullet points below the pac CLI line.


Step 5 — Update cli-wrapper npm package (if applicable)

Only do this if a <wrapper-version> argument was given OR if the cli-wrapper changelog explicitly requires the new pac CLI version:

npm view @microsoft/powerplatform-cli-wrapper versions --json 2>&1 | tail -1

If updating, bump "@microsoft/powerplatform-cli-wrapper" in package.json dependencies and run npm install.


Step 6 — Verify

npm install 2>&1 | tail -5
npm run ci 2>&1

npm run ci runs: clean → compile → lint → restore (downloads the new pac CLI version) → unitTest → pack. Functional tests will fail locally (require live credentials) — expected, not a blocker.

If restore fails (pac CLI version not found), the version does not exist — stop and report.


Step 7 — Commit and push (main branch PR)

git add nuget.json extension/overview.md package.json package-lock.json
git status  # confirm only these files staged
git commit -m "chore: update pac CLI to <pac-version>"
git push -u origin HEAD 2>&1

Create the main-branch PR:

gh pr create \
  --base main \
  --title "Update pac CLI to <pac-version>" \
  --body "$(cat <<'EOF'
## Summary
- Bump PAC CLI from <old-version> to <pac-version>
- [Release Notes on nuget.org](https://www.nuget.org/packages/Microsoft.PowerApps.CLI/<pac-version>#releasenotes-body-tab)

## Changes
- `nuget.json`: both `Microsoft.PowerApps.CLI` and `Microsoft.PowerApps.CLI.Core.linux-x64` updated to `<pac-version>`
- `extension/overview.md`: release notes entry added

## Test plan
- [ ] `npm run ci` passes locally (restore downloads new pac CLI version successfully)
- [ ] Functional tests exempt (require live env credentials)

🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"

Step 8 — Create the release/stable branch PR

This is the production release. Create a second branch off release/stable:

git fetch origin 2>&1
git checkout release/stable 2>&1
git merge origin/release/stable --no-edit 2>&1
git checkout -b users/<alias>/cli-version-<pac-version>-release 2>&1

Cherry-pick the commit from Step 7:

git cherry-pick <commit-sha-from-step-7> 2>&1
git push -u origin HEAD 2>&1

Create the release PR:

gh pr create \
  --base release/stable \
  --title "[release] Update pac CLI to <pac-version>" \
  --body "$(cat <<'EOF'
## Summary
- Bump PAC CLI from <old-version> to <pac-version> on the release/stable branch
- Mirrors: <main-branch-pr-url>

## Changes
- `nuget.json`: both packages updated to `<pac-version>`
- `extension/overview.md`: release notes entry added

## Test plan
- [ ] Main-branch PR verified first
- [ ] Functional tests exempt

🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"

Step 9 — Final summary

Print:

  1. PAC CLI: old version → new version
  2. cli-wrapper: old → new (or "not updated")
  3. Main PR: URL
  4. Release PR: URL
  5. Restore verified: yes / no (did gulp restore download the new pac CLI successfully?)

Then tell the user what to do after both PRs merge:

Once both PRs merge, queue the official build to sign, publish to Marketplace, and create the GitHub Release:
  https://dev.azure.com/dynamicscrm/OneCRM/_build?definitionId=21491

Pipeline variables to set when queuing:
  - GITHUB_TOKEN            GitHub PAT (repo scope, SSO enabled for 'microsoft' org)
  - AZ_DevOps_Read_PAT      PAT to read from the AzDO DPX-Tools-Upstream feed
  - isEsrpEnabled           true
  - PUBLISH_TO_MARKETPLACE  true

On success, a published GitHub Release will appear automatically at:
  https://github.com/microsoft/powerplatform-build-tools/releases/tag/v<new-extension-version>

That release will include:
  - All 4 signed VSIXs (LIVE, BETA, DEV, EXPERIMENTAL) as assets
  - Release notes extracted from `extension/overview.md`'s `{{NextReleaseVersion}}:` block
  - Latest tag

If the release does not appear, check the "Create GitHub release with VSIX assets" task in the build log — usually GITHUB_TOKEN scope or SSO authorization is the issue.

Hard rules

  • Never update only one of the two nuget.json packages — both must match
  • Never skip the release/stable PR — every CLI update needs both
  • Never cherry-pick to release/stable without verifying the main PR CI passes first
  • The {{NextReleaseVersion}} placeholder in overview.md must stay — add below it, never replace it
  • If the Linux pac CLI package (Microsoft.PowerApps.CLI.Core.linux-x64) doesn't have the new version yet, wait — don't ship with mismatched versions

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.