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
In this repository8 other files it gives its agents.
- architectureSkill
- create-prSkill
- debug-agentSkill
- fix-dependenciesSkill
- knowledge-syncSkill
- reviewSkill
- security-alertsSkill
- workitemSkill
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
- Very specific: line 29
If last sync was > 7 days ago or missing: run /knowledge-sync inline, then continue.
- Distinctive: line 45
If the version does not exist on nuget.org, stop and report — do not create a PR for a non-existent version.
- Very specific: line 79
Add a new entry under {{NextReleaseVersion}}: (do not remove the placeholder — it stays):
- Distinctive: line 86
If additional changes are in this update (new task, Node target bump, etc.), add bullet points below the pac CLI line.
- Very specific: line 92
Only do this if a <wrapper-version> argument was given OR if the cli-wrapper changelog explicitly requires the new pac CLI version:
- Very specific: line 99
If updating, bump "@microsoft/powerplatform-cli-wrapper" in package.json dependencies and run npm install.
- Distinctive: line 114
If restore fails (pac CLI version not found), the version does not exist — stop and report.
- Distinctive: line 127
Create the main-branch PR:
- Distinctive: line 171
Create the release PR:
- Very specific: line 234
Never update only one of the two nuget.json packages — both must match
- Distinctive: line 235
Never skip the release/stable PR — every CLI update needs both
- Distinctive: line 236
Never cherry-pick to release/stable without verifying the main PR CI passes first
- Very specific: line 238
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 …
≈ “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.
Files
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 -1If 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>&1If 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>&1Step 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 -1If 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>&1npm 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>&1Create 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>&1Cherry-pick the commit from Step 7:
git cherry-pick <commit-sha-from-step-7> 2>&1
git push -u origin HEAD 2>&1Create 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:
- PAC CLI: old version → new version
- cli-wrapper: old → new (or "not updated")
- Main PR: URL
- Release PR: URL
- Restore verified: yes / no (did
gulp restoredownload 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.jsonpackages — 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 inoverview.mdmust 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
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
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.

