/test-coverage

UiPath Skills Test Coverage Report

Analyze what a skill teaches vs what its tests verify. Produce a gap analysis with prioritized recommendations.

**Input:** `$ARGUMENTS`

• Skill name or path (e.g., `uipath-maestro-flow`) — single skill.
• Empty or `all` — every skill under `skills/`.

**Output:** Markdown report(s) in `tests/reports/<skill-name>.md` (e.g., `tests/reports/uipath-maestro-flow.md`), unless the user specifies a different path. Overwrite existing reports at the same path.

**Feed-forward contract.** This report is the primary input to `/generate-task <description>`. `/generate-task` takes a free-form description and infers the target skill from it — write gap titles as self-contained descriptions that name the skill or its CLI surface, so the reader can paste a gap straight into `/generate-task` (e.g. "Brown-field editing of existing uipath-maestro-flow projects" → `/generate-task Brown-field editing of existing uipath-maestro-flow projects`).

---

Phase 1 — Discovery

1. Resolve target skill(s):

• Single name → `skills/<name>/`. If `skills/<name>/` does NOT exist but `<name>` is in the **Planned Skills Registry** below, treat it as a planned skill (use the planned-skill template in Phase 5). If `<name>` is in the **Cross-Cutting Capability Registry** below, treat it as a cross-cutting capability (see that section).
• Empty/all → union of (a) glob `skills/uipath-*/`, (b) every entry in the **Planned Skills Registry** whose folder does not yet exist, and (c) every entry in the **Cross-Cutting Capability Registry**. Planned-but-missing skills MUST appear in the per-skill report set and roll-up at 0% until they ship; cross-cutting capabilities MUST appear as their own report + roll-up row (flagged cross-cutting, see §4f and §5).

2. For a normal skill, check for `tests/tasks/<skill-name>/`. For a cross-cutting capability, there is **no dedicated dir** — discover its tests by **tag** (step 3). 3. Find `*.yaml` test files. Normal skill: recursively under `tests/tasks/<skill-name>/`, exclude `_shared/`. Cross-cutting capability: `grep -rl '<tag>' tests/tasks --include='*.yaml' | grep -v _shared` across the **whole** `tests/tasks/` tree (its tasks live inside other skills' dirs). 4. Find `check_*.py` scripts recursively. Exclude `_shared/test_*.py` (unit tests for shared helpers).

For multi-skill runs, use parallel Explore agents — one per skill — to read skill + test content simultaneously. Skip Phase 2 entirely for planned-but-missing skills (no SKILL.md to read).

Cross-Cutting Capability Registry

Some capabilities are taught and tested across **multiple** skills with no folder of their own, yet are first-class products on the org scorecard (e.g. ECS / Context Grounding). Analyze each as its own unit: a dedicated `references/` doc is the capability inventory source, and its tests are selected by **tag** (they physically live inside other skills' `tests/tasks/` dirs). Because those tasks are **also** counted under their host skills, a cross-cutting unit is an **additive overlay, not a partition** — flag it and **exclude it from the repo-wide Totals sums** (Phase 5) so tasks/components are not double-counted.

| Capability (report key) | Tag | Inventory source(s) | Host skills | Scorecard row | |---|---|---|---|---| | `uipath-context-grounding` | `context-grounding` | `skills/uipath-agents/references/context-grounding-patterns.md` (decision logic) + `skills/uipath-agents/references/coded/capabilities/context-grounding.md` + `.../lowcode/capabilities/context/context.md` + the BatchTransform/DeepRAG `planning.md` files those link to | `uipath-agents`, `uipath-maestro-flow` | ECS (uip context-grounding) |

Add a row when a capability (a) is documented in a shared `references/` doc, (b) is exercised by tasks tagged with a single stable tag that span ≥2 skill dirs, and (c) maps to a standalone scorecard product row. Remove it only if the capability gets its own `skills/uipath-<name>/` folder (then it becomes a normal skill).

Planned Skills Registry

These skills are expected to ship but have no folder under `skills/` yet. Treat them as 0% coverage and surface them in every `all`-mode run so the gap stays visible. When a folder appears under `skills/<name>/`, normal Phase 2 extraction takes over automatically — do not remove entries from this list when that happens; the existence check in step 1 handles the transition. Remove an entry only when the skill is intentionally cancelled.

| Planned skill | Domain (one-line hint for the stub report) | |---|---| | `uipath-automation-suite` | On-prem Automation Suite platform operations | | `uipath-communications-mining` | Communications Mining (email/text intent + sentiment) | | `uipath-document-understanding` | Document Understanding (extraction, classification, validation) | | `uipath-governance` | Tenant governance, policies, audit (umbrella over `uipath-gov-*`) | | `uipath-insights` | Insights dashboards, KPIs, scheduled reports | | `uipath-marketplace` | UiPath Marketplace component publish/consume | | `uipath-process-mining` | Process Mining (event logs, conformance, dashboards) | | `uipath-task-mining` | Task Mining (recordings, task analysis) | | `uipath-agenthub` | Agent Hub (build, publish, and manage UiPath agents) |

Phase 2 — Extract the skill's capability inventory

Read the skill's **SKILL.md and every file in `references/` and `assets/`**. Skills vary widely in structure — adapt extraction to what you find.

2a. Identify components

Components are the specific, testable units the skill teaches. What counts as a "component" depends on the skill's domain:

| Skill domain | Component examples | |---|---| | Flow orchestration (`uipath-maestro-flow`) | Node types: `core.action.script`, `core.logic.decision`, `uipath.connector.*`, etc. Find these in SKILL.md Plugin Index tables and `references/plugins/*/planning.md` files. | | RPA workflows (`uipath-rpa`) | Workflow modes (Coded C#, XAML), activity types