@salesforce/afv-skills 1.25.0 → 1.26.0

package/skills/configuring-test-provider/SKILL.md

@@ -1,113 +0,0 @@
----
-name: configuring-test-provider
-description: "Configures an available test provider (e.g. Apex Unit Tests, Code Analyzer, Flow Tests, Provar) on a DevOps Center pipeline via the Connect API, after explicit user confirmation, so the provider's test suites become available for assignment to pipeline stages. Takes a pipelineId and a testProviderId. Use this skill when a provider is available on the pipeline but not yet configured and the user wants to enable it. TRIGGER when: the user wants to configure, enable, set up, or add a test provider on a pipeline, or wants a not-yet-configured provider's suites to become available. DO NOT TRIGGER when: re-syncing an already-configured provider to pick up new suites (use syncing-test-providers), or assigning existing suites to a stage (use managing-suite-assignments)."
-metadata:
-  version: "1.0"
-  minApiVersion: "67.0"
----
-
-# Configuring a Test Provider
-
-Configures an available test provider on a DevOps Center pipeline, making its test suites available for assignment to pipeline stages.
-
-**Confirmation required:** Yes — explicit confirmation before the provider is configured.
-
-## Prerequisites
-
-Load `checking-devops-prerequisites` first — Prerequisites 1–4 (org login, Agentforce DX plugin, DevOps Center org auth, pipeline identified). Prerequisite 5 (stage) is **not** required: providers are configured at the pipeline level, not the stage level.
-
-| Variable | Source |
-|---|---|
-| `doce-org-alias` | Established in Prerequisite 1 |
-| `pipelineId` | Identified in Prerequisite 4 (pipeline selection) |
-| `testProviderId` | Resolved by fetching the pipeline's test providers (below) |
-
----
-
-## Step 1 — Fetch test providers to resolve the provider ID
-
-Get all test providers for the pipeline so you can resolve the `testProviderId` and confirm which providers are still available to configure:
-
-```bash
-sf api request rest \
-  "/services/data/v67.0/connect/devopstesting/pipeline/<pipelineId>/testProviders?status=all" \
-  --target-org <doce-org-alias>
-```
-
-Each provider entry includes `testProviderId`, `testProviderName`, and a status (Configured vs. Available). Present a short summary grouped by status:
-
-```text
-Test providers for <pipelineName>:
-
-✓ Configured:
-- Code Analyzer (63 suites)
-- Apex Unit Tests (5 suites)
-
-Available (not yet configured):
-- Flow Tests
-```
-
-- **Only an Available provider can be configured.** If the pipeline has no available providers, report that and stop — do NOT fabricate a provider or ID.
-
-### If the named provider is already Configured
-
-Do **not** present the confirmation gate and do **not** POST to the configure endpoint (Steps 2–3) — that would create a duplicate `DevopsPipelineTestProvider`. Instead:
-
-1. State plainly that the provider is already configured, including its synced suite count and last-sync time if returned (e.g. *"Flow Tests is already configured on `<pipelineName>` with 3 suites synced (last sync 2026-06-23)."*).
-2. Diagnose the user's actual goal and redirect **by name**:
-   - If the user says the provider's **suites don't appear when assigning tests to a stage**, this is a **stage-assignment gap, not a provider-configuration gap** — the suites already exist at the pipeline level; they just need to be linked to the stage. Redirect to **`managing-suite-assignments`**.
-   - If the user expects **newly created suites** that aren't yet synced, redirect to **`syncing-test-providers`** (re-sync via `POST /connect/devops/sync`) to pull them in.
-3. Do not loop back to configuring — finish cleanly after the explanation and redirect.
-
-## Step 2 — Confirmation gate
-
-**Required — do not call the API before the user confirms.**
-
-> "I'll configure `<testProviderName>` on the `<pipelineName>` pipeline. This will make its suites available for assignment to stages. Confirm?"
-
-Do not proceed until the user gives an affirmative response.
-
-## Step 3 — Configure the provider
-
-On confirmation, call the configure endpoint with the provider ID:
-
-```bash
-sf api request rest \
-  "/services/data/v67.0/connect/devops/pipeline/<pipelineId>/testProvider" \
-  --method POST \
-  --body '{"testProviderId": "<testProviderId>"}' \
-  --target-org <doce-org-alias>
-```
-
-## On success
-
-> "Provider `<testProviderName>` is now configured on the `<pipelineName>` pipeline. Its suites are available for assignment to stages."
-
-Newly configured suites can then be assigned to stages with `managing-suite-assignments`.
-
----
-
-## Critical gotcha
-
-This `POST .../pipeline/<pipelineId>/testProvider` endpoint **creates a new provider configuration record** (`DevopsPipelineTestProvider`). Use it ONLY to configure a provider for the first time. To re-sync an already-configured provider for new suites, use `syncing-test-providers` (`POST /connect/devops/sync`) — calling this configure endpoint on an already-configured provider produces **duplicate** `DevopsPipelineTestProvider` records.
-
-## Error Handling
-
-Never expose raw API error messages, stack traces, or JSON payloads to the user. Map response status codes to plain-language messages:
-
-| Status | User-facing message |
-|---|---|
-| 400 | "The request was invalid. Check that the provider ID and pipeline ID are correct." |
-| 403 | "You don't have permission to configure test providers on this pipeline." |
-| 404 | "The pipeline or test provider was not found." |
-| 409 | "That provider appears to already be configured on this pipeline. To pick up new suites, re-sync it instead." |
-| 500 | "A server error occurred. Try again in a few minutes." |
-
----
-
-## Related skills
-
-- **`checking-devops-prerequisites`** — loaded first to establish org and pipeline context.
-- **`syncing-test-providers`** — once a provider is configured, use this to re-sync it later and pull in newly added suites.
-- **`managing-suite-assignments`** — after configuring a provider, use this to assign or map its suites to a pipeline stage.
-- **`recommending-devops-tests`** — to recommend which of the newly available suites to run.

package/skills/managing-suite-assignments/SKILL.md

@@ -1,161 +0,0 @@
----
-name: managing-suite-assignments
-description: "Manages all forms of test suite assignment for DevOps Center pipeline stages via the Connect API testSuiteStages endpoint. Covers three modes: (A) attaching a single suite to a stage as a one-off add, (B) bulk-mapping multiple suites to a stage as a testing strategy with a mandatory impact-preview table before any changes, and (C) adding or removing individual test classes within a suite assignment with governance rules that exclude rejected tests and re-present the final list before committing. TRIGGER when: a suite is found unlinked from a pipeline stage and the user wants to assign it; the user wants to configure suite-to-stage mappings across a pipeline or assign multiple suites to stages as part of a testing strategy; the user wants to add or remove tests in a suite, sync reviewed tests into a suite, or promote tests to a suite. DO NOT TRIGGER when: authoring new test classes (use platform-apex-test-generate) or running tests directly (use platform-apex-test-run)."
-metadata:
-  version: "1.0"
-  minApiVersion: "67.0"
----
-
-# Managing Suite Assignments
-
-## Prerequisites
-
-Load `checking-devops-prerequisites` first — Prerequisites 1–4 AND Prerequisite 5 (stage). You need `doce-org-alias`, `pipelineId`, and `stageId` before proceeding in any mode.
-
-| Variable | Description |
-|---|---|
-| `doce-org-alias` | Established in Prerequisite 1 |
-| `pipelineId` | Identified in Prerequisite 4 (pipeline selection) |
-| `stageId` | Identified in Prerequisite 5 (stage selection) |
-| `event` | `Pre-Promote`, `Post-Promote`, or `Review` |
-
----
-
-## Mode A — Assign a single suite to a stage
-
-Use this mode when a relevant test suite already exists but is not yet linked to a pipeline stage and the user wants to add it as a single one-off assignment.
-
-**Additional inputs required:**
-
-| Variable | Description |
-|---|---|
-| `testSuiteId` | ID of the suite to assign |
-| `testSuiteName` | Name of the suite (for display in confirmation) |
-
-**Confirmation gate**
-
-**Confirmation required before any API call is made.**
-
-Present the following prompt to the user and wait for an affirmative response:
-
-> "The suite `<testSuiteName>` is not currently assigned to the `<stageName>` stage (`<event>`). Would you like me to assign it now?"
-
-Do not proceed until the user confirms.
-
-**On success**
-
-Report to the user:
-
-> "Suite `<testSuiteName>` has been assigned to the `<stageName>` stage (`<event>`)."
-
----
-
-## Mode B — Map multiple suites to a stage
-
-Use this mode when configuring suite-to-stage mappings across a pipeline or assigning multiple suites to stages as part of a testing strategy.
-
-**Additional inputs required:**
-
-| Input | Description |
-|---|---|
-| `testSuiteOperations` | List of `{testSuiteId, action: "add"\|"remove"}` |
-
-**MANDATORY IMPACT PREVIEW — Required Before Any Changes**
-
-**Do not call the API until the user has confirmed the preview below.**
-
-Present the full mapping summary and wait for explicit confirmation:
-
-> "Here's the suite mapping I'll apply:
->
-> | Suite | Stage | Event | Action |
-> |---|---|---|---|
-> | `<suiteName>` | `<stageName>` | `<event>` | Add |
-> | `<suiteName2>` | `<stageName>` | `<event>` | Remove |
->
-> Confirm to apply all changes?"
-
-Only proceed after the user explicitly confirms.
-
-**On success**
-
-> "Suite mapping applied. `<N>` suite(s) updated for the `<stageName>` stage."
-
----
-
-## Mode C — Add/remove test classes in a suite
-
-Use this mode when the user wants to add or remove individual test classes within an existing suite assignment, sync reviewed tests into a suite, or promote tests to a suite.
-
-**Additional inputs required:**
-
-| Input | Source |
-|---|---|
-| `testSuiteOperations` | List of `{testSuiteId, action: "add"\|"remove"}` |
-
-**Governance rules**
-
-- **Never call this without explicit approval.** AI-reviewed or modified tests must be re-presented to the user before this call is made.
-- Rejected tests must be EXCLUDED from the payload — do not include them even if they were previously in the suite.
-- If tests were modified during review, re-present the final list of tests before requesting confirmation.
-
-**Confirmation gate**
-
-**REQUIRED — do not skip.** Show the user the full list of changes before calling:
-
-> "I'm about to sync the following changes to the test suite:
-> - **Add:** `<testSuiteName1>`, `<testSuiteName2>`
-> - **Remove:** `<testSuiteName3>`
-> - Stage: `<stageName>` | Event: `<event>`
->
-> Confirm?"
-
-Only proceed after receiving explicit confirmation.
-
-**On success**
-
-Confirm to the user:
-> "Test suite updated successfully for the `<stageName>` stage."
-
----
-
-## The system call
-
-All three modes use the same endpoint. Substitute all `<placeholder>` values before executing.
-
-```bash
-sf api request rest "/services/data/v67.0/connect/devopstesting/pipeline/<pipelineId>/testSuiteStages" --method POST --body '{"pipelineStageId":"<stageId>","event":"<event>","assignments":[{"testSuiteId":"<id>","action":"add|remove"}]}' --target-org <doce-org-alias>
-```
-
-Full payload schema:
-
-```json
-{
-  "pipelineStageId": "<stageId>",
-  "event": "<event>",
-  "assignments": [
-    {"testSuiteId": "<suiteId1>", "action": "add"},
-    {"testSuiteId": "<suiteId2>", "action": "remove"}
-  ]
-}
-```
-
-**Error handling**
-
-Never expose raw API error messages to the user. Map response status codes to the following user-facing messages:
-
-| Status | User-facing message |
-|---|---|
-| 400 | "The request was invalid. Check that all suite and stage IDs are correct and the event type is valid." |
-| 403 | "You don't have permission to modify suite assignments on this pipeline." |
-| 404 | "The pipeline or stage was not found." |
-| 500 | "A server error occurred. Try again in a few minutes." |
-
----
-
-## Related skills
-
-- **`syncing-test-providers`** — use when the suite you want to assign doesn't appear yet; re-syncing the provider pulls in newly added suites.
-- **`recommending-devops-tests`** — use when a suite has not yet been identified and you need a recommendation for which suite to assign.
-- **`configuring-quality-gate`** — use to configure a quality gate on the stage after mapping suites.
-- **`analyzing-test-failures`** — use for failure analysis and suggested improvements to the tests within a suite.

package/skills/polling-test-results/SKILL.md

@@ -1,72 +0,0 @@
----
-name: polling-test-results
-description: "Polls a DevOps Center async test execution by runId until it completes, fails, or times out — using read-only SOQL on the execution record at provider-specific intervals (Apex 15s/5m, Code Analyzer 10s/3m, Provar UI 60s/20m, Flow 20s/8m) — then surfaces results. Use this skill when a test suite run is in progress and the user is waiting on results, or immediately after running a suite. TRIGGER when: a test suite run is in progress and the user is waiting on results, or immediately after running a suite and a runId is available. DO NOT TRIGGER when: there is no active runId."
-metadata:
-  version: "1.0"
-  minApiVersion: "67.0"
----
-
-# polling-test-results
-
-**Confirmation required:** No — polling is automatic and read-only. No user confirmation gate is needed.
-
-**What it does:** Polls the DevOps Center org for the status of an async test execution until it completes, times out, or fails.
-
----
-
-## Prerequisites
-
-You need an active `runId` (returned by the `running-devops-test-suite` skill) and the confirmed `doce-org-alias`. If org context is not yet established, load `checking-devops-prerequisites` first (Prerequisites 1–3).
-
----
-
-## Inputs required
-
-| Input | Source |
-|---|---|
-| `runId` | Returned by the `running-devops-test-suite` skill |
-| `testType` | Derived from the suite's test provider (Apex, Code Analyzer, UI/Provar, Flow) |
-| `doce-org-alias` | Established via `checking-devops-prerequisites` |
-
-## Polling configuration
-
-| Test type | Poll interval | Max wait | Timeout action |
-|---|---|---|---|
-| Apex unit tests | 15 seconds | 5 minutes | Surface runId, offer retry |
-| Code Analyzer | 10 seconds | 3 minutes | Surface runId, offer retry |
-| UI tests (Provar) | 60 seconds | 20 minutes | Surface runId, mark as pending |
-| Flow tests | 20 seconds | 8 minutes | Surface runId, offer retry |
-
-## Poll query
-
-Query the execution record by `runId` on each interval:
-
-```bash
-sf data query \
-  --query "SELECT Id, Status, TestsRan, TestsPassed, TestsFailed, CoveragePercentage FROM DevopsTestExecution WHERE Id = '<runId>' LIMIT 1" \
-  --target-org <doce-org-alias> \
-  --json
-```
-
-Check the `Status` field on each poll:
-- `Queued` / `Running` → wait and poll again
-- `Completed` → proceed to result analysis
-- `Failed` → surface error and offer retry or skip
-
-## On timeout
-
-Surface the `runId` to the user:
-> "The test run is taking longer than expected. Your run ID is `<runId>`. You can check the status manually in DevOps Center, or I can keep waiting — what would you prefer?"
-
-Do not automatically retry after timeout. Wait for user instruction.
-
-## On completion
-
-Pass the full result payload to the `analyzing-test-failures` skill for reasoning. Surface `Coverage`, `SuccessCount`, `FailureCount`, and `QualityGateStatus` inline. Do not surface raw JSON to the user.
-
----
-
-## Related skills
-
-- Runs are started by `running-devops-test-suite` (including its retrigger mode)
-- Failure analysis is handled by `analyzing-test-failures`

package/skills/running-devops-test-suite/SKILL.md

@@ -1,144 +0,0 @@
----
-name: running-devops-test-suite
-description: "Triggers async execution of one or more DevOps Center test suites on a pipeline stage (Pre-Promote, Post-Promote, or Review event) via the Connect API, after an explicit user confirmation gate, then hands off to result polling via the `polling-test-results` skill. Also re-runs (retriggers) a quality gate after fixes — but only once validation confirms the coverage threshold is now met. TRIGGER when: the user wants to run, kick off, or launch test suites on a pipeline stage; execute tests before or after a promotion; trigger a Pre-Promote, Post-Promote, or Review-event run; re-run a quality gate after fixing failures; retry a failed gate once coverage is met; or unblock a blocked promotion after adding tests. DO NOT TRIGGER when: running sf apex run test directly (use platform-apex-test-run); or configuring a NEW gate or threshold (use configuring-quality-gate)."
-metadata:
-  version: "1.0"
-  minApiVersion: "67.0"
----
-
-# Running a DevOps Center Test Suite
-
-## Prerequisites
-
-Load and follow `checking-devops-prerequisites` first — run Prerequisites 1–4 AND Prerequisite 5 (pipeline stage), since this skill operates on a specific stage. You need the confirmed `doce-org-alias`, `pipelineId`, and `stageId` before proceeding.
-
-## Inputs required before calling this skill
-
-| Input | How to obtain |
-|---|---|
-| `pipelineId` | From Prerequisite 4 (pipeline selection) |
-| `stageId` | From Prerequisite 5 (pipeline stage confirmation) |
-| `event` | Confirm with user: `Pre-Promote` or `Post-Promote` (or `Review` if the context is a review environment) |
-| `testSuiteIds` | Confirmed suite IDs from the suite selection or recommendation step |
-| `doce-org-alias` | Established in Prerequisite 1 |
-
-## Confirmation gate
-
-**This call mutates org state — do not proceed without explicit user confirmation.**
-
-Before calling the API, show the user:
-
-> "I'm about to run tests with the following configuration:
-> - Pipeline: `<pipelineName>`
-> - Stage: `<stageName>`
-> - Event: `<event>`
-> - Suite(s): `<suiteName(s)>`
-> - Org: `<doce-org-alias>`
->
-> Shall I proceed?"
-
-Do not make the API call until the user confirms.
-
-## API call
-
-```bash
-sf api request rest \
-  "/services/data/v67.0/connect/devopstesting/pipeline/<pipelineId>/stage/execute" \
-  --method POST \
-  --body '{
-    "stageId": "<stageId>",
-    "event": "<event>",
-    "testSuiteIds": ["<suiteId1>", "<suiteId2>"]
-  }' \
-  --target-org <doce-org-alias>
-```
-
-### Body schema
-
-| Field | Type | Description |
-|---|---|---|
-| `stageId` | string | The ID of the pipeline stage to execute tests on |
-| `event` | string | `Pre-Promote`, `Post-Promote`, or `Review` |
-| `testSuiteIds` | string[] | One or more test suite IDs to execute |
-
-## On success
-
-Extract the `runId` (or execution ID) from the response. Inform the user:
-
-> "Tests are running in `<doce-org-alias>`. I'll update you when results are ready."
-
-Immediately hand off the `runId` to the `polling-test-results` skill to begin the polling loop.
-
-## On error
-
-| Status | Message to user |
-|---|---|
-| 400 | "The test execution request was invalid. Check that the stage and suite IDs are correct." |
-| 403 | "You don't have permission to run tests on this pipeline. Check your DevOps Testing API access." |
-| 404 | "The pipeline or stage was not found. It may have been deleted." |
-| 500 | "The DevOps Center org returned a server error. Try again in a few minutes." |
-
-Never expose raw API errors to the user.
-
----
-
-## Retrigger mode (re-running a quality gate)
-
-Use this mode when a promotion was blocked by a quality gate failure and the coverage gap has since been addressed.
-
-### Extra preconditions — all must be true before proceeding
-
-1. The `Coverage` field on the latest `DevopsTestSuiteExecution` meets or exceeds the threshold defined in the `DevopsQualityGateRule`
-2. The user has explicitly asked to retrigger the gate
-3. The same `pipelineId`, `stageId`, and `event` from the blocked promotion are known
-
-If coverage is still below threshold, do **not** retrigger. Instead, respond:
-
-> "Coverage is still at `<X>%`, below the `<threshold>%` gate. The gate cannot be retriggered until the threshold is met. Here are the remaining uncovered methods: `<list>`."
-
-Do not retry. Explain what must be resolved first and stop.
-
-### Inputs required for retrigger
-
-| Input | Source |
-|---|---|
-| `pipelineId` | From the blocked promotion context |
-| `stageId` | From the blocked promotion context |
-| `event` | Same event type that originally blocked (`Pre-Promote` or `Post-Promote`) |
-| `suiteIds` | Same suites that were originally run |
-| `doce-org-alias` | Established in Prerequisite 1 |
-
-### Confirmation gate (retrigger)
-
-Before executing the API call, present this confirmation prompt and wait for explicit user approval:
-
-> "Coverage is confirmed at `<X>%`, which meets the `<threshold>%` gate. I'll retrigger the quality gate check for the `<stageName>` stage (`<event>`). Confirm?"
-
-Only proceed after the user confirms. If the user declines, stop without making any API call.
-
-### API call (retrigger)
-
-Uses the same Connect API stage/execute endpoint:
-
-```bash
-sf api request rest "/services/data/v67.0/connect/devopstesting/pipeline/<pipelineId>/stage/execute" --method POST --body '{"stageId":"<stageId>","event":"<event>","testSuiteIds":["<suiteId1>"]}' --target-org <doce-org-alias>
-```
-
-After the call returns a `runId`, hand off to the `polling-test-results` skill with the new `runId` to monitor the execution result.
-
-### Error handling (retrigger)
-
-If the API returns an error indicating the gate cannot be retriggered, respond with:
-
-> "The quality gate cannot be retriggered right now. Reason: `<plain-language summary>`. Here's what needs to be resolved first: `<list>`."
-
-Never expose raw API error details to the user.
-
----
-
-## Related skills
-
-- **`polling-test-results`** — poll for async run results after receiving the `runId`
-- **`recommending-devops-tests`** — recommend which suites to run first before triggering execution
-- **`managing-suite-assignments`** — assign or map a suite to a pipeline stage if it isn't linked yet
-- **`configuring-quality-gate`** — configure a new gate or threshold

package/skills/syncing-test-providers/SKILL.md

@@ -1,108 +0,0 @@
----
-name: syncing-test-providers
-description: "Re-syncs a configured DevOps Center test provider on a pipeline to pick up new test suites, via the Connect API sync endpoint, after explicit user confirmation. Takes a pipelineId and one or more testProviderIds and triggers an asynchronous re-sync so newly added suites become available for assignment. Use this skill when a test provider (e.g. Apex Unit Tests, Code Analyzer, Flow Tests, Provar) has had suites added since it was last configured and the user wants those suites to show up in DevOps Center. TRIGGER when: the user wants to re-sync a test provider, pull in new suites from a provider, refresh a provider's suite list, or says assigned suites are missing/out of date for a configured provider. DO NOT TRIGGER when: configuring a provider for the first time (that creates a new DevopsPipelineTestProvider configuration), or assigning/mapping existing suites to a stage (use managing-suite-assignments)."
-metadata:
-  version: "1.0"
-  minApiVersion: "67.0"
----
-
-# Syncing Test Providers
-
-Re-syncs a configured test provider on a DevOps Center pipeline so that suites added to the provider since it was last configured become available for assignment to stages.
-
-**Confirmation required:** Yes — explicit confirmation before the sync is triggered.
-
-## Prerequisites
-
-Load `checking-devops-prerequisites` first — Prerequisites 1–4 (org login, Agentforce DX plugin, DevOps Center org auth, pipeline identified). Prerequisite 5 (stage) is **not** required: providers are synced at the pipeline level, not the stage level.
-
-| Variable | Source |
-|---|---|
-| `doce-org-alias` | Established in Prerequisite 1 |
-| `pipelineId` | Identified in Prerequisite 4 (pipeline selection) |
-| `testProviderId` | Resolved by fetching the pipeline's test providers (below) |
-
----
-
-## Step 1 — Fetch test providers to resolve the provider ID
-
-Get all test providers configured on the pipeline so you can resolve the `testProviderId` and confirm the provider name with the user:
-
-```bash
-sf api request rest \
-  "/services/data/v67.0/connect/devopstesting/pipeline/<pipelineId>/testProviders?status=all" \
-  --target-org <doce-org-alias>
-```
-
-Each provider entry includes `testProviderId`, `testProviderName`, and a status (Configured vs. Available). Present a short summary grouped by status:
-
-```text
-Test providers for <pipelineName>:
-
-✓ Configured:
-- Code Analyzer (63 suites)
-- Apex Unit Tests (5 suites)
-
-Available (not yet configured):
-- Flow Tests
-```
-
-- **Only a Configured provider can be synced.** If the user names an *Available* (not-yet-configured) provider, explain it must be configured first — this skill does not configure providers.
-- If the pipeline has no configured providers, report that and stop — do NOT fabricate a provider or ID.
-
-## Step 2 — Confirmation gate
-
-**Required — do not call the API before the user confirms.**
-
-> "I'll re-sync `<testProviderName>` on the `<pipelineName>` pipeline to pick up any new suites. Confirm?"
-
-Do not proceed until the user gives an affirmative response.
-
-## Step 3 — Trigger the sync
-
-On confirmation, call the sync endpoint with the provider ID(s) and pipeline ID:
-
-```bash
-sf api request rest \
-  "/services/data/v67.0/connect/devops/sync" \
-  --method POST \
-  --body '{
-    "testProviderIds": ["<testProviderId>"],
-    "pipelineId": "<pipelineId>"
-  }' \
-  --target-org <doce-org-alias>
-```
-
-`testProviderIds` is a list — multiple configured providers can be synced in one call.
-
-## On success
-
-> "Provider `<testProviderName>` sync started. The operation is running asynchronously — new suites will be available shortly."
-
-The sync runs asynchronously; newly synced suites can then be assigned to stages with `managing-suite-assignments`.
-
----
-
-## Critical gotcha
-
-**Do NOT use** `POST /connect/devops/pipeline/<pipelineId>/testProvider` to sync — that endpoint **creates a new provider configuration** and will result in duplicate `DevopsPipelineTestProvider` records. Sync only via `POST /connect/devops/sync`.
-
-## Error Handling
-
-Never expose raw API error messages, stack traces, or JSON payloads to the user. Map response status codes to plain-language messages:
-
-| Status | User-facing message |
-|---|---|
-| 400 | "The sync request was invalid. Check that the provider ID and pipeline ID are correct." |
-| 403 | "You don't have permission to sync test providers on this pipeline." |
-| 404 | "The pipeline or test provider was not found." |
-| 500 | "A server error occurred. Try again in a few minutes." |
-
----
-
-## Related skills
-
-- **`checking-devops-prerequisites`** — loaded first to establish org and pipeline context.
-- **`configuring-test-provider`** — use to configure an available provider for the first time; this skill only re-syncs already-configured providers.
-- **`managing-suite-assignments`** — after a sync surfaces new suites, use this to assign or map them to a pipeline stage.
-- **`recommending-devops-tests`** — to recommend which of the newly synced suites to run.