uipreliga

fix(ci): scope the skills.sh drift check to drift the PR introduces (#3043) * fix(ci): scope the skills.sh drift check to drift the PR introduces `Validate skills.sh.json against skills/` failed 68 times in the last three months — a 6.1% failure rate, the highest of any deterministic gate in the repo. 65 of those 68 failures were one incident. #2252 landed `skills/uipath-process-mining/` on 2026-08-04 without a `skills.sh.json` entry. The checker reads the whole tree, so from 15:52 that day until 17:13 on 2026-08-06 every PR touching any `skills/*/SKILL.md` went red for drift it did not cause — ~20 unrelated branches, 65 failed runs. The entry was finally added by an unrelated PR (#2498, a solution zip-filename fix) that happened to trip over it. The remaining 3 failures were skill-adding PRs failing legitimately. So 96% of this check's failures were false positives, which is also why it merged red 5 times: a check that cries wolf gets clicked through, and that is how the drift reached main in the first place. Fix: `--baseline-ref` compares findings against the base commit. Findings that also reproduce at the baseline print as `::warning::` and do not fail the run; only findings the change introduces exit 1. Whole-tree visibility is kept — the blast radius is not. An unreadable baseline (shallow clone, missing base) falls back to strict whole-tree behaviour, so the failure mode is the old behaviour rather than a silent pass. Replayed against the real incident: #2252 (adds process-mining) new=[uipath-process-mining] exit 1 ✓ still blocks #2436 (unrelated, maestro-case) pre-existing exit 0 ✓ no longer blocks #2498 (adds the entry) clean exit 0 ✓ Docs: `skills.sh.json` is not derived from disk, so a rename or removal leaves it stale with no symptom other than this check. CONTRIBUTING.md covered adding a skill, but it is not loaded into agent context — CLAUDE.md and `.claude/rules/` are, and neither mentioned the file. Added the add/rename/remove contract to CLAUDE.md (rule 5 + File Conventions), `.claude/rules/skill-structure.md` (new § skills.sh Grouping), `.claude/rules/pr-review.md` (both checklists), and a rename/removal subsection in CONTRIBUTING.md. Tests: `tests/scripts/test_check_skills_sh.py` (15 cases) pins the contract — pre-existing drift warns, introduced drift fails, a dirty baseline is no shield for fresh drift, renames fail on both halves, an unreadable baseline stays strict. Registered as a Test Helpers job. This also makes the check safe to add to the required set. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(ci): address review — stable finding identity, no paths filter, HEAD^1 baseline Review from @bai-uipath. All three findings reproduced and fixed. 1. Finding identity keyed on the formatted error string, which embeds grouping titles and list indices, so unrelated edits re-attributed pre-existing drift as new. Reproduced against the previous commit: retitle a grouping (duplicate drift already present) -> exit 1 insert a grouping at the top (schema drift present) -> exit 1 Findings now carry an explicit `kind` and a `subject`, and identity is `(kind, subject)`. `key`/`error` stay display-only, so output is unchanged. Coverage findings key on the skill name alone — retitling a grouping or moving a bad entry between groupings is not new drift. Schema findings key on the grouping title when it is valid, never the index. Both scenarios now exit 0, and five tests pin it. 2. Dropped the `paths:` filter. The reviewer is right that blast radius was not the only failure mode: the check never ran on #2252 at all — 19 checks reported on that head, and this was not among them — even though the workflow had existed since 2026-07-31 and the filter listed `skills/*/SKILL.md`. The guard was silent on the one PR it existed to catch. validate-version-sync.yml and smoke-rpa-skills.yml already document the required-check rationale verbatim; this workflow now matches. ~20s job, so it just always runs. A manual dispatch gets no baseline and validates the whole tree strictly. 3. Removed `fetch-depth: 0` from the new test job. Every test resolves HEAD or a deliberately missing ref, both fine on the default shallow clone. Also took both optional suggestions: - Baseline is now `HEAD^1`, the base parent of the merge commit actually under test, rather than the event payload's `base.sha`, which can lag the merge ref GitHub recomputed. Let the validate job's fetch-depth drop from 0 to 2. - CLAUDE.md rule 5 now points at the skill-structure rule for the full change→edit table instead of restating the `--fix` limits, per .claude/rules/token-optimization.md § 3 (one full statement + pointers). And the Claude review bot's finding: test_cli_json_output_carries_the_ preexisting_flag passed by vacuous truth — a clean tree emits no JSON, so the loop body never ran. Replaced with a fixture that produces one pre-existing and one introduced finding, asserting both `preexisting` values actually emit, plus a separate test that a clean tree stays silent. 21 tests, all passing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

chore(preview): re-sync Maestro SDK skills to flow-builder-sdk@4db8e12 (#2878) 🤖 Generated with Claude Code Co-Authored-By: [Claude](mailto:noreply@anthropic.com) Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

chore(preview): re-sync Maestro SDK skills to flow-builder-sdk@49520ad (#2722) 🤖 Generated with Claude Code Co-Authored-By: [Claude](mailto:noreply@anthropic.com) Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

fix(ci): harden catalog refresh — branch cleanup, token split, subtree-loss guard (#2398) * fix(ci): stop stranding refresh branches, split feed-read from repo-write PAT The nightly catalog refresh failed every day from 2026-06-30 to 2026-07-30. `GH_PAT` was rotated on 06-25 to a token that reads the GitHub Packages feed but cannot write labels, so `gh label create` returned `HTTP 404 .../labels` (GitHub 404s instead of 403 when a token lacks a permission). Three consequences, all fixed here: - The step died after `git push`, stranding one branch per run. 34 `auto/refresh-uip-catalog-*` branches accumulated with no open PRs. A trap now deletes the pushed branch unless a PR ended up owning it. This also removes a latent deadlock: the branch name is version + UTC date, so a same-day retry at an unchanged CLI version collided with its own orphan and died on a non-fast-forward push, masking the real error. - `gh label create` was fatal under `bash -e` despite the `automated` label already existing on this repo. It is now non-fatal; `gh pr create --label` is the call that actually needs to succeed, and it still fails loudly. - One secret served two very different jobs. `smoke-skills.yml` and `smoke-rpa-skills.yml` are `pull_request`-triggered required checks on a public repo, so anyone who can push a branch here could read a credential that also carried repo write. Feed-read consumers now take `GH_PACKAGES_TOKEN`; `GH_PAT` is referenced only by the two `schedule`/`check_suite` workflows that need write. The `GH_PACKAGES_TOKEN || GH_PAT` fallback keeps every workflow green until the new secret exists — drop it once it does. Also corrects two comments claiming this PAT is shared with activation-gate.yml, which does not reference it. That claim sent the original Slack triage toward "expired PAT" when the token was valid and merely under-scoped. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(catalog): refuse to ship a catalog that lost a whole command group The 2026-07-30 21:39 UTC build dropped the entire `rpa debug` subtree (16 verbs) plus `rpa analyzer-rules list` and `rpa files diff`, and opened a PR that would have auto-merged. Cause was not a CLI change: `uip <group> --help` failed for those three groups, and collect_group marks a group unwalkable and returns no children when that happens. The group node itself survives, so the subtree disappears silently — 18 verbs is 1.3% of a 1384-verb catalog, well inside --max-drop-frac 0.2. The same three groups walked fine 16 hours earlier, and five *other* rpa groups failed in that earlier build instead, so the failures are transient rather than structural. Two changes: - collect_group retries a failed `--help` (3 attempts, linear backoff) before marking a group unwalkable. Only failing groups pay the cost. - New always-on guard: refuse to write when a group that was walked in the committed snapshot is unwalkable in this build. Verified against the two real snapshots — it reports exactly the 3 regressed groups / 18 lost verbs that --max-drop-frac passed. `--allow-unwalkable-regression` is the escape hatch for a genuine permanent loss, or for recovering when the committed snapshot is itself the flaky build. The guard stays quiet on the cases that are not regressions: leaf commands (no children in the previous snapshot), groups already unwalkable, groups genuinely deleted from the CLI (never enter the walk), and new groups. 10 unit tests cover those plus both retry paths. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs(ci): clarify why each workflow gets the read-only feed token Reviewer nits on #2398, both comment-only: - smoke-rpa-skills.yml: the token-split note ran into the `@dev` pinning paragraph mid-sentence. Split into its own paragraph and spell out the reason the `pull_request` trigger matters (a branch pusher on a public repo can read the secret), matching the wording in smoke-skills.yml. - run-coder-eval.yml: this workflow is `workflow_dispatch`-only, so the fork-PR argument does not apply to it. Say so, and name the actual reason for the narrower token here: least privilege. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

feat(discovery): add skills.sh.json, a zero-install trial path, and a drift guard (#2390) * feat(discovery): add skills.sh.json and a zero-install trial path We are already indexed on skills.sh (37 entries, 529 installs) and `npx skills add UiPath/skills` already works — but the page is an ungrouped flat list and the README never mentions either fact. - skills.sh.json groups all 24 skills using the README's existing four catalog sections. Display-only: it does not affect how the skills CLI installs anything. `notGrouped: bottom` pushes the 13 retired entries still indexed on our page (uipath-flow, uipath-rpa-workflows, uipath-case-management, ...) below the live sections — the only lever available without a support request to prune them. - README: skills.sh badge, plus an evaluation path via `npx skills use` that needs neither the UiPath CLI nor a project change. `uip skills install` stays the recommended path and the note says why (it auto-detects agents and auto-updates; npx does not). TODO before merge — confirm the grouping of seven skills that appear only in the README's generated status table, never in its descriptive catalog tables, so their placement here was inferred from the skill name alone: uipath-automation-discovery -> Solution & Planning uipath-connector-builder -> Authoring uipath-functions -> Authoring uipath-governance -> Platform & Operations uipath-insights -> Platform & Operations uipath-mcp-servers -> Platform & Operations uipath-tasks -> Platform & Operations The same taxonomy should then close the README catalog gap so there is one grouping rather than two. Not included (needs a request via skills.sh/contact): pruning the 13 retired entries, and asking whether install history can carry across the renames uipath-flow -> uipath-maestro-flow and uipath-case-management -> uipath-maestro-case (~40 installs of real signal). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(ci): guard skills.sh.json against drift skills.sh.json is presentation-only — it never changes what the skills CLI installs — which is exactly why it rots unnoticed. A skill added, renamed, or removed under skills/ produces no error anywhere and the public page keeps showing the old grouping. This is the failure mode already visible on our live page: 13 renamed or retired skills still listed. scripts/check-skills-sh.py checks four things: 1. Parses — valid JSON, expected top-level shape. 2. Schema — the published skills.sh constraints, enforced locally so CI needs no network (groupings 1-50, title required and 1-120 chars, skills non-empty and <=500, description <=500, notGrouped in {top,bottom}, no unknown top-level keys, canonical $schema URL). 3. No duplicates — a skill appears in at most one grouping. 4. Bijection — every skills/<name>/ is grouped, every grouped name exists on disk. --fix is deliberately asymmetric: it removes grouped names that no longer exist (unambiguous) plus any grouping left empty, and refuses to place newly added skills, because which section a skill belongs to is an editorial call. It exits 1 while anything remains ungrouped so it can never be mistaken for "the manifest is now correct". When `groupings` is missing or malformed the coverage check is skipped, so the one finding that matters isn't buried under every skill on disk. Follows the scripts/check-skill-status.py pattern: findings-per-line text output, --json for tooling, and a paths-scoped workflow mirroring validate-skill-status.yml. The workflow uses no ${{ }} interpolation, triggers on pull_request rather than pull_request_target, and requests only contents:read. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs(contributing): document the skills.sh grouping step Without this, the first contributor to add a skill gets a red `Validate skills.sh.json against skills/` and no documentation saying why. Step 4 exists for exactly this reason for the status manifest; this mirrors it — what to add, which section, how to validate, and what CI enforces — plus the matching Quality Checklist line. Also states the thing that is easy to assume wrong: the grouping affects only the skills.sh page, never what `uip skills install` or the skills CLI installs. Renumbers the two optional steps that follow (5-6 -> 6-7). No internal anchors referenced them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs: point skills.sh links at the canonical host `https://skills.sh/...` 308-redirects to `www.skills.sh`, and the page path 307s again to a lowercased owner — so the badge and page links each cost one or two hops. `https://www.skills.sh/uipath/skills` and `.../b/uipath/skills` both return 200 directly, with an identical badge. Left alone deliberately: the `$schema` value in skills.sh.json (and the matching constant in scripts/check-skills-sh.py) keeps the apex form `https://skills.sh/schemas/skills.sh.schema.json`. That is a service-defined identifier, spelled exactly as skills.sh documents it and as every other vendor repo shipping this file uses it — matching the spec matters more there than saving a redirect an editor follows anyway. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

chore(preview): re-sync Maestro SDK skills to flow-builder-sdk@efd27ce (#2789) 🤖 Generated with Claude Code Co-Authored-By: [Claude](mailto:noreply@anthropic.com) Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

chore(preview): re-sync Maestro SDK skills to flow-builder-sdk@3d5a94e (#2916) 🤖 Generated with Claude Code Co-Authored-By: [Claude](mailto:noreply@anthropic.com) Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

docs(commands): cross-cutting capability analysis (context grounding) + scorecard wiring (#1434) test-coverage: - Add a Cross-Cutting Capability Registry: capabilities with no skills/<name>/ folder that are taught in a shared reference and tested by a single tag across multiple skill dirs. First entry: context-grounding, sourced from uipath-agents/references/context-grounding-patterns.md (+ capability refs), tag-selected across uipath-agents + uipath-maestro-flow, mapped to the ECS row. - Tag-based test discovery (grep the tag across tests/tasks), components from the modes x surfaces matrix, rules from the invariants; Comp 70% / Rules 30% shape. - coverage.json gains cross_cutting / tag / host_skills fields; cross-cutting entries are additive overlays EXCLUDED from repo-wide Totals (counted in hosts). - Roll-up reconciliation step + SUMMARY row/Totals handling. generate-confluence-scorecard (consumer side): - Read cross_cutting coverage.json entries and map them to their product row (uipath-context-grounding -> ECS): Skill Coverage from overall_pct, pass/fail non-additive (footnote 7). - Reproduce BOTH org product tables incl. the Product Capability Enumeration table (Skills Smoke / Integration+E2E split). - Always resolve the newest dated org scorecard as parent (not just on 404). - Publish ergonomics: includeBody:false on update, large-create-response handling. Also consolidates the operate/diagnose archetype lens + mode-balanced/floor scoring from PR #1364 into test-coverage.md (same file). Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

chore(preview): re-sync Maestro SDK skills to flow-builder-sdk@c0cf591 (#2754) 🤖 Generated with Claude Code Co-Authored-By: [Claude](mailto:noreply@anthropic.com) Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

chore(preview): re-sync Maestro SDK skills to flow-builder-sdk@b384859 (#2759) 🤖 Generated with Claude Code Co-Authored-By: [Claude](mailto:noreply@anthropic.com) Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>