tribunal-kit 2.4.6 → 3.0.0

package/.agent/skills/playwright-best-practices/SKILL.md

@@ -1,81 +1,162 @@
 ---
 name: playwright-best-practices
-description: End-to-end testing expert specializing in Playwright. Focuses on robust selectors, auto-waiting, parallelization, and reducing flaky tests.
+description: Playwright End-to-End (E2E) testing mastery. Resilient selectors, auto-waiting mechanisms, parallel test execution, mocking network requests, fixture management, and cross-browser CI configurations. Use when configuring, deploying, or writing E2E web tests.
 allowed-tools: Read, Write, Edit, Glob, Grep
-version: 1.0.0
-last-updated: 2026-03-30
-applies-to-model: claude-3-7-sonnet, gemini-2.5-pro
+version: 2.0.0
+last-updated: 2026-04-02
+applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
 ---
 
-# Playwright Best Practices
-
-You are an expert in End-to-End (E2E) testing utilizing Playwright. Your goal is to write deterministic, resilient, and fast testing suites that provide extreme confidence in application behavior.
-
-## Core Directives
-
-1. **Locator Strategy:**
-   - Always prefer user-facing locators: `getByRole`, `getByText`, `getByLabel`.
-   - Never use XPath or highly coupled CSS selectors (e.g., `.container > div > span`) unless absolutely necessary.
-   - For components needing strict test-binding, use `data-testid` via `getByTestId`.
-
-2. **Auto-Waiting & Assertions:**
-   - Playwright automatically waits for elements to be actionable. Never insert explicit `page.waitForTimeout(5000)` unless debugging.
-   - Use web-first assertions: `await expect(locator).toBeVisible()`, `await expect(locator).toHaveText()`. Do not use standard Node.js assertions `assert(true)` for DOM state.
-
-3. **Authentication & Setup:**
-   - Utilize global setup (`globalSetup` or `test.beforeAll`) for authentication.
-   - Save the authentication state (cookies/local storage) into a reusable state file (e.g., `playwright/.auth/user.json`) to skip login UI flows during testing.
-
-4. **Parallelization & Structure:**
-   - Group related tests logically using `test.describe`.
-   - Keep tests independent. Tests should not rely on state mutated by previous tests.
-   - Clean up data after tests using `test.afterEach` or isolated contexts.
-
-## Output Format
-
-When creating or modifying tests:
-1. Explain the User Journey being tested.
-2. Outline the steps and assertions.
-3. Provide the full test code incorporating the best practices above.
-
-
----
-
-## 🤖 LLM-Specific Traps
-
-AI coding assistants often fall into specific bad habits when dealing with this domain. These are strictly forbidden:
-
-1. **Over-engineering:** Proposing complex abstractions or distributed systems when a simpler approach suffices.
-2. **Hallucinated Libraries/Methods:** Using non-existent methods or packages. Always `// VERIFY` or check `package.json` / `requirements.txt`.
-3. **Skipping Edge Cases:** Writing the "happy path" and ignoring error handling, timeouts, or data validation.
-4. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
-5. **Silent Degradation:** Catching and suppressing errors without logging or re-raising.
-
----
-
-## 🏛️ Tribunal Integration (Anti-Hallucination)
-
-**Slash command: `/review` or `/tribunal-full`**
-**Active reviewers: `logic-reviewer` · `security-auditor`**
-
-### ❌ Forbidden AI Tropes
-
-1. **Blind Assumptions:** Never make an assumption without documenting it clearly with `// VERIFY: [reason]`.
-2. **Silent Degradation:** Catching and suppressing errors without logging or handling.
-3. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
-
-### ✅ Pre-Flight Self-Audit
-
-Review these questions before confirming output:
-```
-✅ Did I rely ONLY on real, verified tools and methods?
-✅ Is this solution appropriately scoped to the user's constraints?
-✅ Did I handle potential failure modes and edge cases?
-✅ Have I avoided generic boilerplate that doesn't add value?
-```
-
-### 🛑 Verification-Before-Completion (VBC) Protocol
-
-**CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
-- ❌ **Forbidden:** Declaring a task complete because the output "looks correct."
-- ✅ **Required:** You are explicitly forbidden from finalizing any task without providing **concrete evidence** (terminal output, passing tests, compile success, or equivalent proof) that your output works as intended.
+# Playwright E2E — Bulletproof Testing Mastery
+
+> E2E tests prove the system works. Flaky tests prove nothing.
+> Never test implementation details. Test what the user experiences.
+
+---
+
+## 1. Resilience & Auto-Waiting
+
+Playwright automatically waits for elements to be actionable (visible, stable, not obscured).
+
+```typescript
+// ❌ FLAKY: Hardcoded sleeps. Fails on slow CI, wastes time on fast local rings.
+await page.waitForTimeout(3000); 
+
+// ❌ FLAKY: CSS selectors tied to layout/styling changes
+await page.locator('.btn-primary > span').click();
+
+// ✅ ROBUST: Playwright auto-waits for actionability based on user-centric selectors
+await page.getByRole('button', { name: "Submit Checkout" }).click();
+
+// ✅ ROBUST: Testing for expected states 
+await expect(page.getByText('Order confirmed')).toBeVisible();
+```
+
+### The Selector Hierarchy (Best to Worst)
+1. `page.getByRole()` — Checks accessibility simultaneously.
+2. `page.getByText()` — Finds elements by raw text values.
+3. `page.getByTestId()` — Resilient to text/translation updates (`data-testid`).
+4. `page.locator('css')` — Brittle, bound to DOM structures. Use only as last resort.
+
+---
+
+## 2. Test Isolation & Fixtures
+
+Do not cascade tests (where Test B requires Test A to pass first). Playwright gives every test a blank browser context isolated from the rest.
+
+```typescript
+import { test, expect } from '@playwright/test';
+
+// ❌ BAD: Cascading state
+test.describe('Dashboard', () => {
+  test('Login', async ({ page }) => {
+    await login(page); // Next test assumes this succeeded
+  });
+  test('Action', async ({ page }) => {
+    await page.getByRole('button', { name: 'Save' }).click(); 
+  });
+});
+
+// ✅ GOOD: Isolated tests via beforeEach or Custom Fixtures
+test.beforeEach(async ({ page }) => {
+  // Login directly via API to bypass slow UI login, seeding cookies
+  await performFastApiLogin(page);
+  await page.goto('/dashboard');
+});
+
+test('Should save settings', async ({ page }) => {
+  await page.getByRole('button', { name: 'Save' }).click();
+  await expect(page.getByRole('alert')).toHaveText('Saved successfully');
+});
+```
+
+---
+
+## 3. Network Mocking
+
+E2E tests that rely on external 3rd party APIs (Stripe, SendGrid) will fail randomly due to network latency outside your control.
+
+```typescript
+test('Should block invalid credit cards', async ({ page }) => {
+  // Intercept the outgoing request to the payment processor
+  await page.route('**/api/v1/charge*', async route => {
+    // Return a mocked failure response immediately
+    const json = { status: 'declined', message: 'Insufficient funds' };
+    await route.fulfill({ status: 400, json });
+  });
+
+  await page.getByRole('button', { name: 'Purchase' }).click();
+  await expect(page.getByText('Insufficient funds')).toBeVisible();
+});
+```
+
+---
+
+## 4. Configuration for CI/CD
+
+```typescript
+// playwright.config.ts
+import { defineConfig, devices } from '@playwright/test';
+
+export default defineConfig({
+  testDir: './tests/e2e',
+  fullyParallel: true,   // Run tests concurrently
+  forbidOnly: !!process.env.CI, // Fail build if `.only` was left in code
+  retries: process.env.CI ? 2 : 0, // Retry flakes on CI only
+  workers: process.env.CI ? 1 : undefined, // Reduce CI overload
+  reporter: 'html',
+
+  use: {
+    trace: 'on-first-retry', // Record trace viewer ONLY on failure to save space
+    video: 'retain-on-failure',
+    baseURL: 'http://localhost:3000',
+  },
+
+  projects: [
+    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
+    { name: 'webkit', use: { ...devices['Desktop Safari'] } },
+    // Mobile Viewport Example
+    { name: 'Mobile Safari', use: { ...devices['iPhone 13'] } },
+  ],
+
+  // Spin up local server before running tests
+  webServer: {
+    command: 'npm run build && npm run start',
+    url: 'http://localhost:3000',
+    reuseExistingServer: !process.env.CI,
+  },
+});
+```
+
+---
+
+## 🤖 LLM-Specific Traps (Playwright)
+
+1. **WaitTime Hallucinations:** AI constantly suggests `await page.waitForTimeout()` to "fix" failing tests. This is a severe anti-pattern. Rely on Playwright's default auto-waiting, or use `waitForURL / waitForResponse`.
+2. **CSS Selector Blindness:** Relying on `.main > div:nth-child(3)` instead of `getByRole`. Tests will break on the next UI update.
+3. **Cypress Confusions:** Writing Cypress syntax (`cy.get`) in Playwright files. They are fundamentally different frameworks.
+4. **Ignoring Promises:** Playwright actions are async. The AI forgets the `await` keyword, causing the test to complete and close the browser instantly before the assertion happens.
+5. **Slow UI Logins:** Executing full UI visual typing of username/password on *every* test. In an E2E suite of 100 tests, this adds 15 minutes. Use API logins to set browser cookies in `beforeEach` (or `globalSetup`).
+6. **`.only` Commit Pollution:** Leaving `test.only()` in the code. Enable `forbidOnly` in `playwright.config.ts` so the CI catches it immediately.
+7. **Trace Recording Overload:** Using `trace: 'on'` inside the CI. Tracking traces for passes consumes massive disk space. Use `trace: 'on-first-retry'`.
+8. **Soft Assertions Abuse:** AI uses `expect.soft()` to suppress failures. If an assertion is critical, allow it to fail the test entirely.
+9. **Clicking Hidden Elements:** Trying to `click()` elements that are functionally obscured by modals. If Playwright refuses to click, it's a real bug. Bypassing it via `click({ force: true })` ruins the purpose of E2E testing.
+10. **State Leakage:** Failing to realize that tests run completely independently. AI trying to pass variables between `test()` blocks. Variables reset on every definition.
+
+---
+
+## 🏛️ Tribunal Integration
+
+### ✅ Pre-Flight Self-Audit
+```
+✅ Did I completely eliminate `waitForTimeout` (hard sleep) sleep commands?
+✅ Are selectors relying on semantic meaning (`getByRole`, `getByText`) instead of raw CSS?
+✅ Have I properly awaited all locator actions and expectations (`await expect...`)?
+✅ Are tests completely isolated (no cascading state dependence)?
+✅ Is the test executing an API-level authentication bypass if testing underlying features?
+✅ Are external 3rd-party SaaS integrations defensively mocked via `page.route`?
+✅ Have I respected Playwright's auto-actionability checks (avoiding `{ force: true }`)?
+✅ Did I define multiple targeted viewports/browsers inside the `playwright.config.ts`?
+✅ Is `forbidOnly` enabled for CI pipelines?
+✅ Did I assert user-facing impacts rather than deep implementation variables?
+```

package/.agent/skills/powershell-windows/SKILL.md

@@ -1,230 +1,146 @@
----
-name: powershell-windows
-description: PowerShell Windows patterns. Critical pitfalls, operator syntax, error handling.
-allowed-tools: Read, Write, Edit, Glob, Grep
-version: 1.0.0
-last-updated: 2026-03-12
-applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
----
-
-# PowerShell on Windows
-
-> PowerShell is not bash with a Windows accent.
-> It is object-based, not text-based. That changes everything.
-
----
-
-## Core Difference: Objects, Not Text
-
-Every PowerShell command returns objects, not strings. This is the foundational difference from bash.
-
-```powershell
-# bash: 'ls' returns text you parse
-ls -la | awk '{print $9}'
-
-# PowerShell: Get-ChildItem returns objects you access directly
-Get-ChildItem | Select-Object Name, Length
-(Get-ChildItem ".\src").Count   # count files directly
-```
-
-This means string parsing (grep, awk, cut) is often unnecessary in PowerShell.
-
----
-
-## Critical Operator Pitfalls
-
-PowerShell comparison operators use letters, not symbols:
-
-| Operation | PowerShell | NOT This |
-|---|---|---|
-| Equal | `-eq` | `==` |
-| Not equal | `-ne` | `!=` |
-| Greater than | `-gt` | `>` |
-| Less than | `-lt` | `<` |
-| Like (wildcard) | `-like "*.ts"` | — |
-| Match (regex) | `-match "pattern"` | — |
-| Contains | `-contains "val"` | — |
-
-```powershell
-# ❌ This doesn't compare — it redirects output
-if ($count == 5) { ... }
-
-# ✅ Correct PowerShell comparison
-if ($count -eq 5) { ... }
-```
-
----
-
-## Path Handling
-
-Windows paths have backslashes but PowerShell handles both:
-
-```powershell
-# Both work in PowerShell
-$path = "C:\Users\username\project"
-$path = "C:/Users/username/project"
-
-# Use Join-Path for safe cross-platform joins
-$full = Join-Path $env:USERPROFILE "Desktop\project"
-
-# Resolve to absolute path
-$abs = Resolve-Path ".\relative\path"
-
-# Test existence before using
-if (Test-Path $path) { ... }
-if (Test-Path $path -PathType Container) { ... }  # is it a directory?
-if (Test-Path $path -PathType Leaf) { ... }        # is it a file?
-```
-
----
-
-## Error Handling
-
-PowerShell has two error types: terminating and non-terminating.
-
-```powershell
-# Stop on any error (like bash set -e)
-$ErrorActionPreference = 'Stop'
-
-# Try/Catch only catches terminating errors
-try {
-  Remove-Item "nonexistent.txt" -ErrorAction Stop
-} catch {
-  Write-Host "Error: $_" -ForegroundColor Red
-  exit 1
-}
-
-# Handle non-terminating errors
-$result = Get-Item "maybe.txt" -ErrorAction SilentlyContinue
-if (-not $result) {
-  Write-Host "File not found"
-}
-```
-
----
-
-## String Handling
-
-```powershell
-# Single quotes = literal (no variable expansion)
-$name = 'world'
-Write-Host 'Hello $name'   # outputs: Hello $name
-
-# Double quotes = interpolation
-Write-Host "Hello $name"   # outputs: Hello world
-
-# Here-string for multiline
-$block = @"
-Line 1
-Line 2
-Value: $name
-"@
-
-# String operations
-$str.ToLower()
-$str.Replace("old", "new")
-$str.Split(",")
-$str.Trim()
-$str -like "*.ts"       # wildcard match
-$str -match "^\d{4}$"   # regex match
-```
-
----
-
-## Useful Patterns
-
-```powershell
-# Get script directory (equivalent of bash's $SCRIPT_DIR)
-$ScriptDir = Split-Path -Parent $MyInvocation.MyCommand.Path
-
-# Run command and capture output WITH error handling
-$output = & git status 2>&1
-if ($LASTEXITCODE -ne 0) {
-  Write-Error "git failed: $output"
-  exit 1
-}
-
-# Iterate files matching pattern
-Get-ChildItem ".\src" -Recurse -Filter "*.ts" | ForEach-Object {
-    Write-Host $_.FullName
-}
-
-# Create directory if not exists
-New-Item -ItemType Directory -Force ".\output" | Out-Null
-
-# Read/write files
-$content = Get-Content ".\file.txt" -Raw
-Set-Content ".\output.txt" "new content"
-Add-Content ".\log.txt" "append this line"
-
-# Environment variables
-$env:MY_VAR = "value"         # set
-[System.Environment]::GetEnvironmentVariable("PATH")   # read system-level
-```
-
----
-
-## Execution Policy
-
-Scripts may be blocked by execution policy:
-
-```powershell
-# Check current policy
-Get-ExecutionPolicy
-
-# Allow local scripts (most permissive safe setting)
-Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
-
-# Run a specific script bypassing policy (one-time)
-powershell -ExecutionPolicy Bypass -File script.ps1
-```
-
----
-
-## Output Format
-
-When this skill produces or reviews code, structure your output as follows:
-
-```
-━━━ Powershell Windows Report ━━━━━━━━━━━━━━━━━━━━━━━━
-Skill:       Powershell Windows
-Language:    [detected language / framework]
-Scope:       [N files · N functions]
-─────────────────────────────────────────────────
-✅ Passed:   [checks that passed, or "All clean"]
-⚠️  Warnings: [non-blocking issues, or "None"]
-❌ Blocked:  [blocking issues requiring fix, or "None"]
-─────────────────────────────────────────────────
-VBC status:  PENDING → VERIFIED
-Evidence:    [test output / lint pass / compile success]
-```
-
-**VBC (Verification-Before-Completion) is mandatory.**
-Do not mark status as VERIFIED until concrete terminal evidence is provided.
-
-
----
-
-## 🏛️ Tribunal Integration (Anti-Hallucination)
-
-**Slash command: `/audit` or `/review`**
-**Active reviewers: `logic` · `security` · `devops`**
-
-### ❌ Forbidden AI Tropes in PowerShell
-
-1. **Using Bash Operators** — writing `==` or `!=` instead of `-eq` or `-ne`.
-2. **Text Parsing Over Objects** — extracting properties with regex instead of just accessing `$obj.Property`.
-3. **Ignoring Execution Policies** — writing scripts without considering that they might be blocked on the user's machine.
-4. **Silent Failures** — relying on generic `catch` blocks without understanding terminating vs non-terminating errors.
-5. **Path Separator Errors** — failing to wrap path operations in safe cmdlets like `Join-Path` or `Test-Path`.
-
-### ✅ Pre-Flight Self-Audit
-
-Review these questions before generating PowerShell commands:
-```
-✅ Did I use the correct comparison operators (e.g., `-gt`, `-like`)?
-✅ Did I leverage PowerShell's object pipeline instead of parsing text?
-✅ Are paths safely manipulated (e.g., `Join-Path`) to handle Windows backslashes correctly?
-✅ Are potential non-terminating errors handled explicitly?
-✅ Will this script require an execution policy bypass, and did I note that for the user?
-```
+---
+name: powershell-windows
+description: PowerShell and Windows environment mastery. Object-oriented piping, strict error handling (ErrorActionPreference), PSProviders, active directory querying, credential management, and execution policies. Use when automating Azure, Windows environments, or writing .ps1 scripts.
+allowed-tools: Read, Write, Edit, Glob, Grep
+version: 2.0.0
+last-updated: 2026-04-02
+applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
+---
+
+# PowerShell — Windows Automation Mastery
+
+> PowerShell does not pipe text. It pipes rich .NET Objects.
+> Your Bash instincts will betray you here. Think in structured data, not regex.
+
+---
+
+## 1. The Object Pipeline
+
+Unlike Bash where everything is strings (requiring `awk`/`grep`), PowerShell passes structured .NET class instances between commands.
+
+```powershell
+# ❌ BAD: Attempting to treat PowerShell like Bash (String Parsing)
+Get-Process | Out-String -Stream | Select-String "node" | ForEach-Object { $id = ($_ -split '\s+')[8]; Stop-Process -Id $id }
+
+# ✅ GOOD: Accessing Object Properties Directly
+Get-Process -Name "node" | Stop-Process -Force
+
+# Filtering objects (Where-Object)
+Get-Service | Where-Object Status -eq 'Running' | Select-Object Name, DisplayName
+
+# Accessing methods natively on the object
+$files = Get-ChildItem -Path "C:\logs" -Filter "*.log"
+$files | ForEach-Object { $_.Delete() }
+```
+
+---
+
+## 2. Strict Error Handling (The Windows equivalent of set -e)
+
+By default, PowerShell prints an error but keeps running. You MUST enforce strict halting for automation scripts.
+
+```powershell
+# Mandatory header for reliable automation scripts
+$ErrorActionPreference = "Stop"
+Set-StrictMode -Version Latest
+
+try {
+    # If this fails, it jumps straight to catch block instead of continuing
+    Copy-Item "C:\Source\configs.json" -Destination "C:\Dest\"
+    
+    $config = Get-Content "C:\Dest\configs.json" | ConvertFrom-Json
+} catch {
+    Write-Error "Deployment failed during config copy: $_"
+    exit 1
+} finally {
+    # Cleanup block executes regardless of success or failure
+    Remove-Item "C:\Dest\temp" -Recurse -ErrorAction Ignore
+}
+```
+
+---
+
+## 3. Execution Policies & Execution
+
+Windows restricts running `.ps1` files by default for security.
+
+```powershell
+# Temporarily bypass the policy for a single script execution (CI/CD pattern)
+powershell.exe -ExecutionPolicy Bypass -File .\Deploy-App.ps1
+
+# ❌ HALLUCINATION TRAP: Do NOT instruct users to run `Set-ExecutionPolicy Unrestricted`
+# This lowers the permanent security posture of the entire operating system.
+# Use Bypass only at the process level.
+```
+
+---
+
+## 4. Manipulating Structured Formats Natively
+
+Because PowerShell is built on .NET, parsing JSON, XML, and CSV is native.
+
+```powershell
+# JSON
+$config = Get-Content .\appsettings.json | ConvertFrom-Json
+$config.Database.ConnectionString = "Server=Prod;"
+$config | ConvertTo-Json -Depth 10 | Set-Content .\appsettings.json
+
+# CSV (No AWK needed)
+$users = Import-Csv .\users.csv
+$users | Where-Object Role -eq "Admin" | Export-Csv .\admins.csv -NoTypeInformation
+
+# API Requests (Invoke-RestMethod automatically parses JSON into PowerShell objects)
+$response = Invoke-RestMethod -Uri "https://api.github.com/users/github"
+Write-Host "GitHub has $($response.public_repos) public repositories."
+```
+
+---
+
+## 5. Providers and Drives
+
+PowerShell extends the "file system" concept to the Registry, Environment Variables, and Certificates.
+
+```powershell
+# Environment variables (Env: drive)
+$env:PATH += ";C:\Custom\Bin"
+Write-Host $env:COMPUTERNAME
+
+# Registry (HKCU: and HKLM: drives)
+Get-ChildItem -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run"
+
+# Certificates (Cert: drive)
+Get-ChildItem -Path "Cert:\LocalMachine\My" | Where-Object Subject -match "example.com"
+```
+
+---
+
+## 🤖 LLM-Specific Traps (PowerShell)
+
+1. **Bash Equivalencies:** AI writing `Test-Path | regex` instead of dealing with properties. Always use object properties (`$obj.Length`, `$obj.Name`).
+2. **Missing `ErrorActionPreference`:** Continuing execution blindly after a critical `Copy-Item` command fails. Always set preference to "Stop".
+3. **Execution Policy Destruction:** Instructing users to permanently change global machine policy to run a script. Always use `-ExecutionPolicy Bypass` natively.
+4. **JSON Conversion Depth limits:** `ConvertTo-Json` defaults to a depth of only 2. It will ruthlessly truncate your nested API payloads silently unless you append `-Depth 10`.
+5. **Return Types in Functions:** PowerShell returns EVERYTHING that hits the pipeline inside a function, not just the `return` statement. Explicitly cast silent operations to `$null` or pipe to `Out-Null`. (e.g., `$list.Add("item") | Out-Null`).
+6. **Comparison Operators:** AI uses `>` or `==`. PowerShell requires `-gt`, `-eq`, `-ne`, `-lt`.
+7. **Backtick Continuation:** Using the backtick `` ` `` as a line continuation character randomly. It is notoriously hard to read and breaks if there's a trailing space. Use proper pipeline formatting or array declarations.
+8. **Paths with Spaces:** Similar to bash, failing to wrap paths in string quotes when executing. `& "C:\Program Files\Node\npm.cmd" install`.
+9. **`Out-File` vs `Set-Content` Encryption:** AI writing configs using `Out-File` defaults to UTF-16 on older PowerShell versions, breaking Linux/Docker containers. Standardize on `Set-Content` or explicitly declare `-Encoding UTF8`.
+10. **`Write-Host` vs `Write-Output`:** AI uses `Write-Host` to return data from functions. `Write-Host` goes straight to the console display buffer. Always use `Write-Output` if you want another variable or pipe to catch the return data.
+
+---
+
+## 🏛️ Tribunal Integration
+
+### ✅ Pre-Flight Self-Audit
+```
+✅ Have I forced strict error catching via `$ErrorActionPreference = "Stop"`?
+✅ Am I manipulating objects (e.g., `Where-Object`) rather than string parsing?
+✅ If I invoked `ConvertTo-Json`, did I set `-Depth 10` (or higher)?
+✅ Are my comparison operators using PowerShell syntax (`-eq`, `-gt`) instead of (`==`, `>`)?
+✅ Did I use `-ExecutionPolicy Bypass` rather than recommending global registry changes?
+✅ Is text encoded correctly to UTF8 via `Set-Content` instead of `Out-File`?
+✅ Did I return data from my functions via `Write-Output` instead of `Write-Host`?
+✅ Are array modifications piped to `Out-Null` to prevent pipeline pollution?
+✅ Is `Invoke-RestMethod` leveraged for APIs instead of the heavier `Invoke-WebRequest`?
+✅ Are commands with spaces invoked using the call operator `& "Path\To\File"`?
+```