From mcs-lab-auditor
Open a PR on the active instance's lab repo (microsoft/mcs-labs by default) that adds a NEW lab built by mcs-lab-builder. Stages the assembled `labs/<slug>/README.md` + screenshots, applies the registration entry (root `lab-config.yml` + generator, or direct `_data/lab-config.yml` + `_labs/<slug>.md` writes — per the detected mechanism), commits everything in one commit on a run-unique branch off `origin/main`, and opens the PR. Invoked by mcs-lab-builder at B7 — NOT directly by the user. Do not use this for audit fixes (that is mcs-lab-fix-pr-filer, which patches an existing lab).
How this skill is triggered — by the user, by Claude, or both
Slash command
/mcs-lab-auditor:mcs-lab-new-lab-prThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Open the PR for a freshly-built lab. You are called by `mcs-lab-builder` at B7 with: `build_id`, `mcs_labs_repo` (resolved absolute path), `slug`, `registration_mode` (`generate` | `direct`), the lab metadata + `order` + `journeys`, the optional `events` list, the **`proposal_issue.number`** (the In-Progress `type: new-lab` issue opened at B3.5, if any), and the build workspace path `runtime/bu...
Open the PR for a freshly-built lab. You are called by mcs-lab-builder at B7 with: build_id, mcs_labs_repo (resolved absolute path), slug, registration_mode (generate | direct), the lab metadata + order + journeys, the optional events list, the proposal_issue.number (the In-Progress type: new-lab issue opened at B3.5, if any), and the build workspace path runtime/builds/<build-id>/. The audit gate has already passed (or the user accepted a draft PR with residual findings listed by the orchestrator).
Why a separate skill from mcs-lab-fix-pr-filer. That filer's contract is: patch an existing _labs/<slug>.md from suggested_correction diffs and replace images, with OPEN-PR-dedup keyed to a lab's audit history. A new lab has no existing markdown to patch and no findings diffs — it adds a whole folder, a registration entry, and (in generate mode) generated output. Keeping this separate preserves both skills' contracts.
Prepare the working tree.
cd <mcs_labs_repo>
git fetch origin main
Stash any unrelated in-flight changes with a labeled stash and restore them at the end — never clobber the user's uncommitted work. Record whether a stash was created.
Create the branch (run-unique, off fresh main).
branch = build.issues.new_lab_pr.pr_branch_pattern # default "{branch_prefix}/new-lab-{slug}-{build_id}"
git checkout -b "<branch>" origin/main
The {build_id} suffix makes the branch unique — re-running build for the same slug yields a fresh build_id and a fresh branch, so a merged/closed prior PR never collides. (No open-PR append path: a new lab is one-shot.)
Stage the lab content.
runtime/builds/<build_id>/draft/README.md → <mcs_labs_repo>/labs/<slug>/README.md.runtime/builds/<build_id>/draft/images/* → <mcs_labs_repo>/labs/<slug>/images/ (create the dir; same-name copy — the README references images/<file>).Apply registration (per skills/mcs-lab-builder/references/lab-registration-spec.md):
lab-config.yml (title, difficulty, duration, section, order, journeys, and events: [...] only if events is non-empty), then run the generator (pwsh -NoProfile -File <mcs_labs_repo>/scripts/Generate-Labs.ps1 -SkipPDFs or the path from config). Commit the generated _labs/<slug>.md + _data/lab-config.yml too._data/lab-config.yml (matching the existing lab_metadata / lab_journeys / lab_orders shape), and write _labs/<slug>.md directly — Jekyll frontmatter (layout: lab, title, order, duration, difficulty, section, journeys, description, plus any bootcamp_order/event keys only if attached) followed by the README body. If events is non-empty, add the slug to each event's lab_order in _data/lab-config.yml.Sanity check.
git status --porcelain
git diff --stat
If nothing changed, abort with pr_action: skipped_no_changes and restore the stash. (Should not happen for a real build.)
Commit (one commit, no AI attribution).
git add labs/<slug>/ _labs/<slug>.md _data/lab-config.yml lab-config.yml # whichever exist
git commit -m "<slug>: add new lab"
Commit body (plain, no Co-Authored-By / no AI mention): one line on what the lab teaches (from Summary of Targets), the use-case list, and Built and verified end-to-end by mcs-lab-builder (build <build_id>). Author = current gh/git user.
Push and open the PR.
git push -u origin <branch>
gh pr create --repo {repo} --base main --head <branch> \
--title "<slug>: add new lab" \
--body-file "runtime/builds/<build_id>/pr-body.md"
Render pr-body.md first: what the lab teaches, the UC list, the lab metadata (section/difficulty/duration/journeys, events if any), a "How it was verified" line (Built interactively and passed the mcs-lab-builder audit gate, build <build_id>), and — if the user accepted residual findings — a "Findings deferred to review" list. If a proposal_issue.number was passed, include Closes #<proposal_issue.number> in the body (per build.proposal_issue.link_pr_with; use Refs #<n> instead if configured to Refs) so merging the lab resolves the In-Progress proposal. Use gh pr create --draft when residual findings exist.
Restore + record.
git switch - then git stash pop if a stash was created.runtime/builds/<build_id>/pr-url.txt and return { pr_url, pr_action: created | created_draft | skipped_no_changes } to the orchestrator.origin/main, never the user's current branch (the mcs-labs clone is often on a feature branch).Co-Authored-By: Claude, no "Generated with…") — user preference.Provides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.
npx claudepluginhub microsoft/bootcamplabtestplugin --plugin mcs-lab-auditor