Merge New Sample PR

Merge New Sample PR (orchestrator)

This is a thin orchestrator over two existing skills — it doesn't duplicate their logic, it sequences them and adds the git/GitHub mechanics needed to actually get a fix committed onto someone else's PR branch and merged:

1. verify-new-sample-pr — build + manual test checklist
2. generate-sample-metadata — assets/sample.json

Four hard pause points, matching how impactful/reversible each step is — never skip these or combine them without the user's explicit go-ahead:

• After build+checklist: wait for the user to confirm manual deploy/test passed
• After generating sample.json: wait for the user to approve the content
• Before merging: wait for explicit "merge it" — this is the only step that isn't easily reversible
• Before posting the thank-you comment: wait for approval of the rendered text — it's a public, PR-visible comment

Procedure

1. Confirm PR type and permissions

gh pr view <PR_NUMBER> --repo pnp/sp-dev-fx-aces --json body --jq '.body'
gh pr view <PR_NUMBER> --repo pnp/sp-dev-fx-aces --json maintainerCanModify,author,headRefName,headRepositoryOwner,state --jq '.'

If it's not a new-sample PR, stop and suggest verify-sample-pr-build instead. If maintainerCanModify is false, stop — see the maintainer-edit-a-PR guidance in repo memory before proceeding (ask the contributor, don't force anything).

2. Run verify-new-sample-pr in full

Follow that skill's procedure exactly: checkout, build, locate .sppkg, check API permissions, extract the deployment/testing checklist, flag README gaps.

STOP and wait for the user to manually deploy/test and report back ("all ok" or a problem). Do not proceed past this point without that confirmation — this is the whole point of that skill.

3. Run generate-sample-metadata on the same checked-out branch

Only if assets/sample.json is missing or needs fixing (check first — some contributors include one). Follow that skill's procedure: gather facts, derive fields, check name uniqueness, write the file.

Show the generated file to the user and wait for approval before touching git — title/description/author wording needs a human look.

4. Stage, commit, and push — only the metadata file

Local npm install/build steps often leave incidental diffs (e.g. package-lock.json version bumps) and this repo may have other unrelated uncommitted files sitting in the working tree (e.g. skill files not yet committed to main). Stage only the new/changed assets/sample.json:

git add samples/<SampleName>/assets/sample.json
git status --short   # confirm nothing else is staged
git commit -m "Add sample.json metadata for <SampleName>"

Push to the contributor's branch to update the same PR (no separate PR):

git push <fork-remote-or-full-fork-url> <PR-branch-name>

Known auth quirks in this Codespace — try in this order if push fails:

1. Authentication error: ... push access — the default Codespaces GITHUB_TOKEN is scoped only to pnp/sp-dev-fx-aces, not third-party forks. Fix: have the user run unset GITHUB_TOKEN && gh auth login (interactive, needs a personal token with repo scope) — don't attempt this yourself, it needs their browser/device-code interaction.
2. Authentication error: ... verify locks (even after #1) — this is Git LFS lock verification, unrelated to normal push permissions (repo has no LFS-tracked files). Fix: add -c lfs.https://github.com/<owner>/<repo>.git/info/lfs.locksverify=false before push on the git invocation (global option, not a push flag).
3. If the named remote was removed in an earlier cleanup, push straight to the fork's full URL instead of re-adding a named remote.