playwright-pom-harness

Plugin playwright-pom-harness in MahmoudElSharkawy/Playwright-Harness. Commands read from the repo's manifest — 5 days ago.

Skills (24)

• action-methods

  Use when writing, refactoring, or reviewing an action method on a page or service class — naming a business operation, wrapping it in its Allure step, choosing what to interpolate into the step title, deciding parameters and return type, judging granularity (compose vs split), handling native dialog

• automate-test

  Automate test cases from a user story, an ADO suite or local scenarios into durable POM code through observed execution, independent review and two scoped green runs.

• bug-report

  Draft, refine, review and optionally file a bug from a selected story and the user's description or existing execution evidence. Supports editable bug details, project-specific required/custom fields, proportionate reproduction and verified attachments.

• context-qa

  Answer business questions from selected saved work items and documents, only when explicitly invoked. Continue explicitly invoked follow-ups with readable explanations and short citations. Ordinary messages do not activate this skill.

• context-update

  Refresh saved business context using its selected documents, exact work-item IDs or saved criteria. Discover newly matching items, update changed evidence and preserve history. Ordinary questions do not trigger refresh.

• element-locators

  Choose or repair Playwright POM locators, including selector priority, field naming, dynamic locators, strict-mode ambiguity, and locator review.

• execute-test

  Execute an ADO suite or story through live browser, API and database runtimes, without generating automation code. Produce verified reports and optionally file bugs or publish suite outcomes.

• framework-review

  Use to review framework changes against the skill-library conventions and produce a verdict — \"review this diff/MR against the conventions\", \"run framework review\", the exit gate of automate-test GENERATE, or any pre-commit conventions check. Runs the mechanical linter, classifies the diff by la

• harness-setup

  Use when installing, updating, repairing, configuring or rolling back the Playwright POM harness in a project — \"install the harness from <repository>\", \"update the harness and preserve my customizations\", \"here is my project information; configure the harness\", adding an environment, applicat

• impact-analysis

  Identify affected areas and recommend regression scope for selected story, bug-fix, requirement, application or framework changes. Use for impact-only analysis; failure diagnosis, automation repair and blocked-test recovery belong to maintain-test.

• maintain-test

  Diagnose failed, flaky, changed or blocked tests. Support diagnose only (findings and next actions) and diagnose and fix (supported automation repair, review and verification), with bounded experiments, existing workflows and preserved history and budgets.

• page-classes

  Use when creating, extending, refactoring, or reviewing a page class in pages/ — a new HTML page object, a skeleton-area class (header/footer/side menu), class member order and section banners, constructors, dynamic locator methods, or deciding whether a new page class is justified at all.

• plan-tracker

  Use to record automation progress for the ADO test plan or to (re)generate the plan-tracker HTML report — \"update the tracker\", \"regenerate the plan tracker\", \"record these cases as done/blocked\", \"sync the tracker with the pipeline\", \"where are we on the plan\", or after any automation wav

• pom-architecture

  Use when designing, structuring, extending, or reviewing anything in this Playwright/TypeScript test framework — folder layout, POM layering, naming conventions, business-vs-technical separation, Allure reporting strategy, updating existing ADO test-case content, or deciding where new code belongs.

• project-context

  Build, retrieve or update business context from explicitly selected work items and supplied documents. Accept exact IDs or reusable criteria; save the selection for later refresh. Use context-qa only for explicitly invoked questions against saved context.

• requirements-analysis

  Analyze supplied requirements or an ADO story, review an editable findings table in chat, preserve acceptance traceability, and optionally post the user's approved story comment with requested team-member mentions.

• service-classes

  Use when creating, extending, or reviewing an ApisDomain class in apis/ or a DbsDomain class in dbs/ — adding an API endpoint or SQL query for tests (source endpoints from the team collection library resources/apisCollections/ and SQL from the team query library resources/Queries/ first), declaring

• test-case-design

  Design, review, create or revise source-grounded test cases for a selected story or supplied requirements, reuse suitable existing cases, and optionally publish an approved proposal to Azure DevOps. Use for test-case design, not test execution, automation generation or direct edits to already select

• test-classes

  Use when creating, restructuring, or reviewing a spec file in tests/ — file naming, folder placement, imports, module-level state, the test.describe block, hook wiring (beforeAll/beforeEach/afterEach/afterAll), setup/teardown responsibilities, or fresh-context-per-test plumbing.

• test-data

  Use when creating or editing a test data JSON file, deciding where an input, expected value, environment setting, or secret should live, replacing a hardcoded value, generating unique per-case and per-run data (TC-id clusters + timestamp), or planning seed-and-cleanup so tests stay independent, para

• test-methods

  Use when writing, reviewing, or refactoring an individual test case inside a spec file — its title, Allure metadata (feature/tms/issue), tags, the flow of business-method calls in the body, validation coverage, test independence, or unique per-case/per-run data usage.

• test-planning

  Plan a testing cycle's objectives, scope, risk priorities, strategy, prerequisites, effort and measurable entry, exit, suspension and resumption criteria from selected sources. Use for planning decisions, not individual case design, progress tracking, execution or repairs.

• utility-classes

  Use when writing, extending, or reviewing anything in utils/ — a technical facade like ApiActions/DBActions, report logging, Allure attachments, secret redaction, connection/pool handling, retries — the root-level globalSetup/globalTeardown lifecycle scripts (honorary utils for run hygiene and repor

• validation-methods

  Use when writing, naming, reviewing, or refactoring a validation method on a page, API, or DB service class — verify* naming, choosing the validation layer (GUI vs API vs DB), the ///// Validations section, Allure step titles for checks, web-first assertions (toBeVisible/toHaveText/toHaveTitle/toHav