@raishin/vanguard-frontier-agentic 2.0.0 → 2.1.0

package/skills/qa/plc-control-logic-safety-review/references/workflow-and-output.md

@@ -0,0 +1,231 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Collect inputs
+
+Ask the user to provide one or more of the following as sanitized exports (no live controller IP addresses, no plant-network hostnames, no historian credentials, no production asset tags that identify a specific facility or unit):
+- Exported program logic in text form: Structured Text (`.st`, `.txt`), L5X/L5K (Rockwell), exported XML (IEC 61131-3 PLCopen XML), or a pasted ladder rung / function block description.
+- The I/O list or hardware configuration (module types, I/O addresses, safety vs. standard I/O).
+- The safety requirements specification (SRS) or SIL/PL assessment for the relevant safety instrumented function (SIF), if available.
+- The process hazard analysis (PHA) or HAZOP summary for the unit, if available.
+- The watchdog and communication-loss behavior specification, if documented separately.
+
+If only a partial set is provided, note which inputs are absent and scope every finding accordingly. Logic without an I/O list leaves safety-rated channel identification as inference; say so explicitly.
+
+### Step 2 — Safety function and E-stop implementation audit
+
+Identify every E-stop, emergency trip, or safety instrumented function (SIF) referenced in the exported logic.
+
+**2a. Software-only E-stop — CRITICAL**
+
+A safety function implemented entirely in standard PLC software cannot achieve SIL 1 or higher under IEC 61508 without architectural redundancy and systematic capability claims that a standard PLC runtime does not provide. A scan fault, firmware defect, or communications outage can prevent the software path from executing.
+
+Correct implementation pattern:
+- Hardware E-stop loop through a safety relay or safety-rated PLC (e.g., Pilz PNOZ, Siemens SIRIUS, Allen-Bradley GuardLogix safety task with dual-channel input).
+- Standard PLC logic may signal or acknowledge the trip, but must never be the sole means of de-energizing the hazardous output.
+
+Flag any rung or ST block where an E-stop coil address is driven exclusively by software logic with no cross-reference to a hardware-forced safety output or a safety PLC output.
+
+**2b. Safety PLC vs. standard PLC**
+
+If the exported logic is from a safety-rated task (e.g., GuardLogix safety task, Siemens F-CPU, HIMA HIMax), confirm that safety I/O is referenced via the safety I/O map, not standard I/O. Mixing safety and standard I/O addresses for the same SIF is CRITICAL.
+
+### Step 3 — Output fail-safe and de-energization audit
+
+For every output coil or output block in the export:
+
+- Trace whether a fail-safe (de-energized) state is reachable when: (a) the PLC transitions to STOP or FAULT mode, (b) the remote I/O link drops, (c) the safety function trips.
+- Flag outputs where the only de-energization path is through software logic that may not execute during a PLC halt.
+
+**Example — CRITICAL: output holds last state on I/O dropout**
+
+```
+(* Structured Text — standard remote I/O, no watchdog output *)
+IF ConveyorRunCmd AND NOT EStop_SoftBit THEN
+    ConveyorMotor_Out := TRUE;
+END_IF;
+(* No else-branch; no watchdog; remote I/O module holds last state on link loss *)
+```
+
+Correct pattern — explicit safe state on every execution path:
+
+```
+(* Every path terminates in an explicit assignment *)
+IF ConveyorRunCmd AND NOT EStop_HW AND CommOK THEN
+    ConveyorMotor_Out := TRUE;
+ELSE
+    ConveyorMotor_Out := FALSE;  (* de-energize on any fault condition *)
+END_IF;
+```
+
+### Step 4 — Latch and SET/RESET integrity audit
+
+Scan every SET coil, SR function block, retentive output, and latch pattern in the export.
+
+Check for:
+- A SET with no cross-referenced RESET anywhere in the POU or program — HIGH (output permanently energized; requires a force to clear).
+- A RESET gated behind a condition that is logically unreachable (e.g., RESET of a latch that is itself the condition for the RESET) — HIGH.
+- SR blocks where the S1 (dominant set) input is tied to a non-safety-rated signal for a safety-rated latch — HIGH.
+
+```
+(* HIGH — SET has no reachable RESET in export *)
+IF FaultDetected THEN
+    FaultLatch (S := TRUE, R1 := FALSE);
+END_IF;
+(* FaultLatch.Q will remain TRUE forever — operator has no reset path *)
+```
+
+Correct pattern:
+
+```
+FaultLatch(
+    S  := FaultDetected,
+    R1 := OperatorReset AND NOT FaultDetected
+);
+```
+
+### Step 5 — Memory-write race audit
+
+Search for any output bit, memory flag (`%M`, `%MW`, internal variable), or output coil address that appears on the left-hand side (assignment target, coil address) in more than one rung, network, or POU within the same task scan.
+
+- Multiple writers to the same address — HIGH (last scan position wins; behavior changes silently when rungs are reordered or POUs are added).
+- Output written in both a periodic task and an event-driven interrupt task — HIGH (non-deterministic; interrupt preemption creates a race).
+
+Document the addresses, the rung or line numbers where the conflict occurs, and the task priority if available.
+
+### Step 6 — Forced I/O and commissioning override audit
+
+Scan the exported file for:
+- Force table entries, force lists, or any tag marked with a force flag in the export format (e.g., `Force="1"` in L5X, `%IX0.0 := TRUE (*FORCED*)` annotations).
+- Debug constants or literal-TRUE inputs substituted for field sensor addresses.
+- Comments containing `//FORCED`, `(* DEBUG *)`, `TODO: remove`, `commissioning`, or similar.
+
+Any force or commissioning override found in a production export — HIGH. Forces suppress the live field signal; the control loop no longer sees the physical process.
+
+### Step 7 — Interlock bypass and maintenance override audit
+
+Identify every maintenance mode, bypass, or inhibit bit that disables or overrides a protective interlock.
+
+For each bypass:
+- Confirm a time-limit timer (TON) in logic resets the bypass after a defined interval — if absent, HIGH.
+- Confirm gating by a supervisor key-switch input, a safety-rated hardware input, or a logged credential acknowledgment — if absent, HIGH.
+- Confirm the bypass state is annunciated to the operator and historian — if absent, MEDIUM.
+
+```
+(* HIGH — indefinite bypass with no time limit, no key gate, no annunciation *)
+IF MaintenanceBypassBit THEN
+    HighTempTrip := FALSE;
+END_IF;
+```
+
+Correct pattern:
+
+```
+(* Time-limited, key-gated bypass with annunciation *)
+MaintenanceTimer(IN := MaintenanceBypassBit AND KeySwitchIn, PT := T#15m);
+IF MaintenanceTimer.Q THEN
+    MaintenanceBypassBit := FALSE;  (* auto-expire *)
+END_IF;
+HighTempTrip_Active := HighTempTrip AND NOT (MaintenanceBypassBit AND KeySwitchIn);
+BypassAnnunciation := MaintenanceBypassBit;
+```
+
+### Step 8 — Timer determinism and watchdog audit
+
+**8a. Scan-count timers — HIGH**
+
+Flag any timer pattern that increments a counter every scan and compares to a literal count rather than using a real-time-based function block (IEC 61131-3 TON, TOF, TP with a PT operand in time literals).
+
+```
+(* HIGH — scan-count "timer"; breaks when scan time changes *)
+ScanCounter := ScanCounter + 1;
+IF ScanCounter >= 500 THEN  (* intended: 500 scans * assumed 10ms = 5s *)
+    ScanCounter := 0;
+    TimeoutAction();
+END_IF;
+```
+
+Correct pattern:
+
+```
+(* Real-time timer — deterministic regardless of scan load *)
+DelayTimer(IN := TriggerCondition, PT := T#5s);
+IF DelayTimer.Q THEN
+    TimeoutAction();
+END_IF;
+```
+
+**8b. Watchdog and communications-loss handling — HIGH if absent**
+
+Confirm the program drives a watchdog output (toggling bit or heartbeat write) and that a defined default output state is explicitly set in the comms-loss handler or in the I/O module configuration. If neither is present in the export, flag HIGH and note the inference basis.
+
+### Step 9 — Input validation audit
+
+Search for division (`/`, `MOD`), array indexing (`arr[idx]`), and explicit or implicit type conversions applied to process values or network-received values.
+
+- Division where the divisor can reach zero based on sensor range — MEDIUM (scan fault and PLC halt on most runtimes).
+- Array index derived from a process value with no range clamp before use — MEDIUM.
+- Type conversion (INT to UINT, REAL to INT truncation) on a value that can legitimately be negative or out-of-range — MEDIUM.
+
+```
+(* MEDIUM — divisor can be zero if flow transmitter fails low *)
+FlowVelocity := FlowVolume / PipeArea;
+
+(* CORRECT — guard the divisor *)
+IF PipeArea > 0.0 THEN
+    FlowVelocity := FlowVolume / PipeArea;
+ELSE
+    FlowVelocity := 0.0;
+    InputFaultBit := TRUE;
+END_IF;
+```
+
+### Step 10 — Produce the output
+
+Format findings using the Output section below.
+
+---
+
+## Output
+
+Return findings in this structure:
+
+```
+## Verdict
+<one sentence: pass / needs work / critical issues found>
+
+## Evidence level
+<exported logic provided | I/O list provided | SRS/SIL assessment provided | partial artifacts | documentation-based | inference>
+
+## Findings
+
+### CRITICAL
+- [C1] <finding title>: <description> — <remediation>
+
+### HIGH
+- [H1] <finding title>: <description> — <remediation>
+
+### MEDIUM
+- [M1] <finding title>: <description> — <remediation>
+
+### LOW
+- [L1] <finding title>: <description> — <remediation>
+
+## Safe next actions
+1. <action>
+2. <action>
+
+## Open questions
+- <question requiring user clarification>
+```
+
+---
+
+## Security notes
+
+- Never request or accept live controller IP addresses, plant-network hostnames, historian connection strings, OPC-UA endpoint URLs, or any identifier that maps a specific asset to a physical facility.
+- This is a static review: do not attempt to connect to a PLC, write to a controller, modify running logic, or advise on bypassing any safety interlock or E-stop circuit.
+- If a user requests a recommendation to disable, bypass, or weaken a safety interlock or SIF, refuse clearly and explain that doing so without a formal Management of Change (MOC) process and a SIL re-assessment is outside the scope of this review and is non-compliant with IEC 61508 and IEC 62443.
+- Do not store, log, or repeat back plant identifiers, tag names that encode asset location, or process values that could reconstruct production data.
+- Label every finding with its evidence basis so engineers can distinguish a confirmed defect in provided logic from an inference based on absent configuration.

package/skills/qa/rpa-workflow-resilience-review/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: rpa-workflow-resilience-review
+description: Use this skill when reviewing exported RPA workflow definitions for resilience and security defects that cause unattended bots to fail silently in production. Trigger when a user provides UiPath XAML files, Automation Anywhere bot exports, Power Automate Desktop flow definitions, Blue Prism process XML, or project dependency manifests, or asks why an unattended bot crashes silently, double-processes transactions, or times out under load. This skill reviews workflow definitions statically; it never connects to a live orchestrator, never runs a bot, and never requests runner credentials or orchestrator URLs.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-17"
+  category: resilience
+  lifecycle: experimental
+---
+
+# RPA Workflow Resilience Review
+
+## Purpose
+This skill reviews exported RPA workflow definitions — UiPath XAML, Automation Anywhere task bots, Power Automate Desktop flows, and Blue Prism processes — for the resilience and security defects that destroy unattended production runs: hardcoded credentials, brittle UI selectors, missing exception handling, non-idempotent transaction logic, hard sleeps, and invisible failures. A bot that silently fails at 2 AM, double-posts a financial transaction, or leaks an RDP session is a production incident. This review catches those defects from the exported artifact before they reach the orchestrator scheduler.
+
+## Lean operating rules
+- Treat any hardcoded credential, API key, connection string, or token present in a workflow variable, argument, activity property, or annotation as CRITICAL — these must be stored in the orchestrator credential vault or a secure asset; no exceptions.
+- Treat UI selectors built on volatile attributes — absolute screen coordinates, positional `idx` values, dynamic window titles, auto-generated IDs from frameworks like WinForms or SAP session GUIDs — as HIGH; they break on any application UI change or version bump; use stable anchors (semantic names, fixed automation IDs, accessible names).
+- Treat any application or UI interaction boundary with no enclosing exception handler (Try/Catch or platform equivalent) as HIGH — an unattended run dies silently with no diagnostics and no item-level status update.
+- Treat a workflow that is not idempotent — re-running it after a partial failure re-submits a form, re-sends an email, re-posts a transaction, or re-creates a record with no already-processed guard — as HIGH; every unattended workflow must be re-runnable without side-effect duplication.
+- Treat any use of a fixed Delay activity to wait for an application or UI element instead of an element-exists, on-element-appear, or application-ready condition as HIGH — this is the RPA equivalent of a hard sleep; it either races the application or pads every run unnecessarily.
+- Treat the absence of a retry or recovery scope around transient steps, OR the presence of an unbounded or infinite retry with no cap or circuit-breaker, as HIGH — transient failures (network blips, SAP logon timeouts) need bounded retry; infinite loops produce zombie runs.
+- Treat attended-only constructs — message boxes, input dialogs, manual user prompts, pop-up confirmations — inside a workflow marked or scheduled for unattended execution as HIGH; they block indefinitely and consume a robot license slot.
+- Treat any selector, screenshot artifact, annotation, test-data variable, or hardcoded string in the workflow that contains PII, real customer names, account numbers, or production data as HIGH — sanitize before sharing or storing in source control.
+- Treat the complete absence of logging and per-transaction-item status updates as MEDIUM — unattended failures become invisible until a downstream system breaks or an SLA is missed.
+- Treat mutation of a shared orchestrator queue item or shared asset without a lock or transaction boundary as MEDIUM — concurrent robot instances can corrupt processing state.
+- Treat missing cleanup logic on failure paths — browser sessions, SAP connections, RDP sessions, or file handles left open after an exception — as MEDIUM; leaked sessions exhaust connection pools and degrade the orchestrator environment.
+- Do not recommend disabling exception handling or removing logging to simplify a workflow — refuse and explain that both are load-bearing safety mechanisms for unattended operation.
+- Label every finding with its evidence basis: exported workflow provided, documentation-based, or inference from absent artifact.
+
+## References
+Load these only when needed:
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review or formatting the final answer.
+
+## Response minimum
+Return, at minimum:
+- Credential and secrets findings (hardcoded values, unprotected variables)
+- Selector resilience assessment (stable vs. volatile attribute strategy per workflow)
+- Exception handling coverage (which interaction boundaries are unguarded)
+- Idempotency and transaction-safety findings (re-run risk, queue locking)
+- Wait strategy findings (fixed delays vs. element-ready conditions)
+- Attended/unattended compatibility findings (blocking constructs in unattended flows)
+- Observability findings (logging, item status, alerting)
+- Severity-labelled finding list (critical / high / medium / low)
+- Safe next actions

package/skills/qa/rpa-workflow-resilience-review/metadata.json

@@ -0,0 +1,22 @@
+{
+  "id": "rpa-workflow-resilience-review",
+  "name": "RPA Workflow Resilience Review",
+  "type": "skill",
+  "provider": "generic",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review exported RPA workflow definitions (UiPath XAML, Automation Anywhere, Power Automate Desktop, Blue Prism) for resilience and security defects — hardcoded credentials, brittle selectors, missing exception handling, non-idempotent logic, fixed delays, and invisible failures — statically, without connecting to a live orchestrator.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.uipath.com/studio/standalone/latest/user-guide/about-workflow-analyzer",
+    "https://docs.uipath.com/studio/standalone/latest/user-guide/about-debugging",
+    "https://docs.uipath.com/orchestrator/standalone/latest/user-guide/about-assets",
+    "https://docs.automationanywhere.com/",
+    "https://learn.microsoft.com/en-us/power-automate/guidance/coding-guidelines/overview",
+    "https://learn.microsoft.com/en-us/power-automate/guidance/coding-guidelines/error-handling"
+  ],
+  "security_notes": "Static review only — reads exported workflow definitions, never connects to a live orchestrator, never executes a bot, and never requests runner credentials, orchestrator URLs, or production queue data. Never accept workflow exports containing live PII, real customer data, or production connection strings; ask for sanitized snippets.",
+  "last_verified": "2026-05-17",
+  "path": "skills/qa/rpa-workflow-resilience-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/qa/rpa-workflow-resilience-review/references/workflow-and-output.md

@@ -0,0 +1,210 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Collect inputs
+
+Ask the user to provide one or more of the following as sanitized exports (no orchestrator URLs, no runner credentials, no production queue data, no PII in test variables):
+- Exported workflow definitions: UiPath `.xaml` files, Automation Anywhere `.atmx` or task JSON, Power Automate Desktop `.zip` or flow JSON, Blue Prism process XML
+- Project dependency manifest or `project.json` (UiPath) / package descriptor
+- Orchestrator asset list (names and types only — no values, no credential content)
+- Optional: a recent orchestrator job log excerpt showing the failure (sanitized — no connection strings, no stack traces containing file paths with tenant IDs)
+
+If only a partial set is provided, note which inputs are absent and scope findings accordingly. A workflow without its project manifest leaves dependency and version blind spots. An asset list without the workflow leaves credential-usage patterns invisible — say so explicitly.
+
+### Step 2 — Credential and secrets audit
+
+Scan every workflow variable, argument, activity property, configuration file, and annotation for hardcoded secrets.
+
+**2a. Hardcoded credentials**
+
+```xml
+<!-- CRITICAL — password stored as a plain workflow argument default -->
+<x:Property Name="SAPPassword" Type="InArgument(x:String)" />
+<!-- Default value: "P@ssw0rd2024" -->
+```
+
+Credentials must live exclusively in the orchestrator credential vault (UiPath Orchestrator Assets of type Credential, AA Control Room credentials, Power Platform environment variables with secret type, or Blue Prism credential manager). The workflow retrieves them at runtime via a `Get Credential` / `Get Asset` activity and holds them in a `SecureString` variable scoped to the minimum lifetime needed.
+
+**2b. Connection strings and API tokens**
+
+```xml
+<!-- CRITICAL — API key baked into an Assign activity -->
+<Assign>
+  <Assign.To><OutArgument x:TypeArguments="x:String">apiKey</OutArgument></Assign.To>
+  <Assign.Value><InArgument x:TypeArguments="x:String">sk-live-abc123XYZ</InArgument></Assign.Value>
+</Assign>
+```
+
+Any string matching patterns for API keys (`sk-`, `Bearer `, `token=`, JDBC/ODBC DSNs with `Password=`) is CRITICAL regardless of whether it looks like a placeholder.
+
+### Step 3 — Selector resilience audit
+
+Review every UI activity's selector for volatile versus stable attributes.
+
+| Selector attribute | Verdict | Why |
+|---|---|---|
+| `automationid`, `name`, `controltype` from accessibility tree | preferred | stable across layout changes and minor version bumps |
+| Fixed `title` with exact window name (non-session-specific) | acceptable | stable if the application version is locked |
+| `idx` positional attribute | HIGH | breaks when the UI gains or loses elements above the target |
+| Absolute screen coordinates (`x`, `y` in click activity) | HIGH | breaks on any resolution, DPI, or window-size change |
+| Dynamic `title` containing session IDs, timestamps, or user names | HIGH | every robot instance generates a unique value |
+| Auto-generated IDs (WinForms `textBox1`, SAP session `wnd[0]/usr/txtRSYST-BNAME`) with session ordinals | HIGH | ordinal changes when multiple SAP sessions are open |
+| Partial match (`*` wildcard) on a stable prefix | acceptable | use sparingly; too broad a wildcard matches wrong elements |
+
+Flag each HIGH selector with the activity name, the volatile attribute, and the recommended stable replacement.
+
+**Example remediation for a SAP session-ordinal selector:**
+
+```xml
+<!-- HIGH — wnd[0] ordinal is relative to open SAP windows -->
+<uipath:TypeInto Selector="&lt;wnd app='saplogon.exe' title='SAP Easy Access' /&gt;&lt;wnd idx='1' /&gt;" />
+
+<!-- CORRECT — use the window's automation ID instead -->
+<uipath:TypeInto Selector="&lt;wnd app='saplogon.exe' automationid='MainWindow' /&gt;" />
+```
+
+### Step 4 — Exception handling coverage audit
+
+Verify that every application or UI interaction boundary is wrapped in an exception handler.
+
+Check for:
+- Any `Click`, `Type Into`, `Get Text`, `Attach Browser`, `Open Application`, `Send Hotkey`, or platform-equivalent activity outside a Try/Catch or Retry Scope → HIGH (silent failure on the happy path; unattended run terminates with no item status update)
+- A Try/Catch that catches `System.Exception` but only logs a generic message with no item-level failure status update to the orchestrator queue → MEDIUM (the exception is swallowed; the queue item stays In Progress forever)
+- A Retry Scope with `NumberOfRetries` set to 0 or left at default without justification → MEDIUM (equivalent to no retry on transient failures)
+- No Global Exception Handler configured at the project level → MEDIUM (any unhandled exception in an invoked workflow bypasses all local handlers)
+
+```xml
+<!-- HIGH — UI interaction with no surrounding exception handler -->
+<uipath:Click Selector="&lt;html app='chrome.exe' /&gt;&lt;webctrl id='submit-btn' /&gt;" />
+
+<!-- CORRECT — wrapped in Try/Catch with queue item failure status on catch -->
+<TryCatch>
+  <Try>
+    <uipath:Click Selector="..." />
+  </Try>
+  <Catches>
+    <Catch x:TypeArguments="s:Exception">
+      <uipath:SetTransactionStatus Status="Failed" ErrorMessage="[ExceptionMessage]" />
+      <Rethrow />
+    </Catch>
+  </Catches>
+</TryCatch>
+```
+
+### Step 5 — Idempotency and transaction safety audit
+
+Verify that every workflow is safe to re-run after a partial failure without duplicating side effects.
+
+- A workflow that submits a form, sends an email, posts a financial transaction, or creates a record with no "already processed" guard (a status field check, a queue item deduplication key, a database flag) → HIGH
+- A workflow that reads from an orchestrator queue but does not update the item status to `Successful` or `Failed` on every exit path → HIGH (items stuck In Progress block the queue and prevent retry)
+- Two robot instances that can claim the same queue item simultaneously with no server-side lock (i.e., not using orchestrator's built-in queue transaction model, instead reading from a shared spreadsheet with no advisory lock) → MEDIUM
+- No rollback or compensating transaction when a multi-step process fails partway through → MEDIUM
+
+```xml
+<!-- HIGH — no idempotency guard before submitting payment -->
+<uipath:Click Selector="'Submit Payment'" />
+
+<!-- CORRECT — check whether this transaction ID was already posted -->
+<uipath:GetQueueItemData ItemField="Reference" Result="[transactionRef]" />
+<If Condition="[alreadyPostedLookup(transactionRef)]">
+  <Then>
+    <uipath:SetTransactionStatus Status="Successful" />
+    <!-- skip re-submission -->
+  </Then>
+  <Else>
+    <uipath:Click Selector="'Submit Payment'" />
+    <uipath:SetTransactionStatus Status="Successful" />
+  </Else>
+</If>
+```
+
+### Step 6 — Wait strategy audit
+
+Scan every workflow for fixed Delay activities used as application synchronization.
+
+- Any `Delay` activity with a hardcoded duration (1 s, 3 s, 5 s) placed before a UI interaction → HIGH (races the application on fast machines; adds unnecessary latency on slow ones; the RPA equivalent of `Thread.Sleep`)
+- `WaitForReady` property left at `None` on a UI activity that targets a freshly loaded page or dialog → HIGH (the activity fires before the target element exists)
+- A pattern of `Delay` + `Element Exists` polling in a loop instead of `Wait Element Vanish` / `On Element Appear` / `Check App State` → MEDIUM
+
+```xml
+<!-- HIGH — hard sleep before clicking a dynamically loaded button -->
+<Delay Duration="[00:00:03]" />
+<uipath:Click Selector="'Confirm'" />
+
+<!-- CORRECT — wait for the element to become ready -->
+<uipath:WaitForElement Selector="'Confirm'" Timeout="[00:00:30]" />
+<uipath:Click Selector="'Confirm'" />
+```
+
+### Step 7 — Attended/unattended compatibility audit
+
+Identify attended-only constructs inside workflows scheduled or deployed for unattended execution.
+
+- Any `Message Box`, `Input Dialog`, `Prompt` activity, or platform-equivalent user interaction prompt inside a workflow that will run on an unattended robot or headless VM → HIGH (blocks indefinitely; consumes a licensed robot slot until manually killed)
+- A workflow that assumes a logged-in desktop session or a specific screen resolution without a session-setup or auto-login step → HIGH
+- A workflow that calls `Kill Process` or `Close Application` on a process that may not be running (no existence check first) → MEDIUM
+
+### Step 8 — Observability audit
+
+Verify that failures are visible before downstream systems surface them.
+
+- No `Log Message` activities at key decision points, transaction boundaries, or exception handlers → MEDIUM (failures are invisible until SLA breach)
+- No per-item status update (`Set Transaction Status` or equivalent) on every exit path, including exception branches → MEDIUM (queue backlog grows silently)
+- No alert or notification on repeated failure (three consecutive `Failed` items, orchestrator alert rule, or a monitoring webhook call) → MEDIUM
+
+### Step 9 — Cleanup and session hygiene audit
+
+Verify that failure paths close all acquired resources.
+
+- Browser sessions, SAP logons, application windows, or file handles acquired in the workflow with no corresponding close or kill activity on the exception path → MEDIUM (session leaks; connection pool exhaustion on the orchestrator VM)
+- A Finally block absent from Try/Catch sequences that open external connections → MEDIUM
+
+### Step 10 — Produce the output
+
+Format findings using the Output section below.
+
+---
+
+## Output
+
+Return findings in this structure:
+
+```
+## Verdict
+<one sentence: pass / needs work / critical issues found>
+
+## Evidence level
+<exported workflow provided | partial artifacts | documentation-based | inference>
+
+## Findings
+
+### CRITICAL
+- [C1] <finding title>: <description> — <remediation>
+
+### HIGH
+- [H1] <finding title>: <description> — <remediation>
+
+### MEDIUM
+- [M1] <finding title>: <description> — <remediation>
+
+### LOW
+- [L1] <finding title>: <description> — <remediation>
+
+## Safe next actions
+1. <action>
+2. <action>
+
+## Open questions
+- <question requiring user clarification>
+```
+
+---
+
+## Security notes
+
+- Never request or accept orchestrator URLs with embedded credentials, runner service-account passwords, production queue data, or PII in variable defaults. Ask for sanitized exports with placeholder values.
+- This is a static review: do not connect to a live orchestrator, execute a bot, or resolve orchestrator asset values. The review is based solely on the exported workflow artifact.
+- Do not recommend removing exception handling or disabling logging to simplify a workflow — both are load-bearing safety mechanisms. Refuse and explain.
+- Do not recommend hardcoding credentials even temporarily, even in a test workflow — credential exposure in source control is irreversible once committed.
+- If a workflow export contains apparent PII (real customer names, account numbers, national IDs in variable defaults or test-data annotations), flag it as HIGH, redact it from the review output, and instruct the user to sanitize before re-sharing.

package/skills/qa/test-coverage-quality-review/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: test-coverage-quality-review
+description: Use this skill when reviewing a test suite for assertion quality rather than coverage percentage — detecting coverage theater, where line/branch coverage is high but the tests would not catch a regression. Trigger when a user provides test files, a coverage report, or asks whether their tests are actually meaningful, why bugs ship despite high coverage, or how to set a coverage gate. This skill reviews test artifacts statically; it does not execute tests or run a coverage tool.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-17"
+  category: delivery
+  lifecycle: experimental
+---
+
+# Test Coverage Quality Review
+
+## Purpose
+This skill reviews a test suite for whether its tests would actually catch a regression — not whether a coverage tool reports a high percentage. High line coverage with weak assertions is *coverage theater*: code runs during the test, the number looks good in CI, and the test still passes when the behavior breaks. The review separates exercised code from verified behavior, surfaces assertion-free and tautological tests, finds mock over-specification that tests the test instead of the system, and recommends a coverage gate that measures meaning rather than line execution.
+
+## Lean operating rules
+- Treat a test with no assertion — it calls the code, no error is thrown, the test passes — as HIGH. Line coverage counts it; it verifies nothing.
+- Treat tautological assertions (`expect(true).toBe(true)`, `expect(result).toBe(result)`, snapshot tests auto-updated on every change without review) as HIGH — they cannot fail when behavior changes.
+- Treat assertions that only check shape, not value (`expect(result).toBeDefined()`, `expect(res.status).toBeTruthy()`, `expect(arr.length).toBeGreaterThan(0)`) where an exact value is knowable as MEDIUM — they pass for wrong values.
+- Treat tests that assert the mock was called but never assert the result computed from it as HIGH — they test the wiring, not the behavior.
+- Treat over-mocked unit tests where every collaborator is mocked and the assertions only restate the mock setup as HIGH — the test is a mirror of itself and proves nothing about integration.
+- Treat the absence of error-path, empty-input, and boundary tests for code that has those branches as HIGH — the happy path inflates the coverage number while real failure modes are untested.
+- Treat a coverage **percentage gate** as the sole quality signal as MEDIUM — a line-percentage threshold is easily satisfied by assertion-free tests; recommend pairing it with assertion-density and changed-line coverage.
+- Treat snapshot tests as the primary verification for logic-bearing output as MEDIUM — snapshots detect change, not correctness, and decay into rubber-stamped updates.
+- Treat coverage measured only as a global percentage with no per-changed-file or diff coverage as MEDIUM — new untested code hides behind a large tested codebase.
+- Treat 100% coverage as a target presented as a goal as MEDIUM — it incentivizes theater; the goal is meaningful assertions on behavior that matters.
+- Do not recommend raising the coverage threshold as a quality improvement — recommend assertion strength and diff coverage instead.
+- Label every finding with evidence basis: test source provided, coverage report provided, documentation-based, or inference.
+
+## References
+Load these only when needed:
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review or formatting the final answer.
+
+## Response minimum
+Return, at minimum:
+- Assertion quality findings (assertion-free, tautological, shape-only)
+- Mock usage findings (call-assertion-only, over-mocking)
+- Branch coverage gap assessment (error paths, boundaries, empty inputs)
+- Coverage gate assessment (percentage-only vs. diff/assertion-aware)
+- Snapshot test reliance assessment
+- Severity-labelled finding list (critical / high / medium / low)
+- Safe next actions

package/skills/qa/test-coverage-quality-review/metadata.json

@@ -0,0 +1,21 @@
+{
+  "id": "test-coverage-quality-review",
+  "name": "Test Coverage Quality Review",
+  "type": "skill",
+  "provider": "generic",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review a test suite for assertion quality over coverage percentage — detecting coverage theater, assertion-free and tautological tests, mock over-specification, and untested branches, and recommending a meaningful coverage gate. Static review only.",
+  "source_type": "original",
+  "official_docs": [
+    "https://martinfowler.com/bliki/TestCoverage.html",
+    "https://martinfowler.com/articles/mocksArentStubs.html",
+    "https://istanbul.js.org/docs/tutorials/coverage/",
+    "https://jestjs.io/docs/configuration",
+    "https://docs.pytest.org/en/stable/how-to/assert.html"
+  ],
+  "security_notes": "Static review only — reads test source and coverage reports, never executes tests or runs a coverage tool. Never request or accept credentials, fixtures containing real customer data, or production database snapshots; ask for sanitized test code.",
+  "last_verified": "2026-05-17",
+  "path": "skills/qa/test-coverage-quality-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}