athena-workflow-marketplace

Deeply explore a live app feature or a single mapped sub-feature and capture grounded evidence for downstream planning in `docs/qa/exploration-report.md` or a scoped file under `docs/qa/exploration/`. Use after the requested scope is already known, especially after `map-feature-scope` has identified bounded sub-features for a large feature. This skill owns observed product evidence and blockers for the scoped area; it does not perform feature decomposition, frame exploratory charters, prioritize risks, or write coverage plans.

Quickly map a broad product feature into concrete sub-features before deep exploration begins. Use when a requested feature may span multiple routes, tabs, overlays, roles, or primary interactive surfaces and the agent needs to identify bounded exploration units, shared state, and blockers before spawning parallel browser subagents. This skill owns `docs/qa/feature-map.md`; it does not produce the final deep exploration evidence, coverage plan, or test specs.

Define an exploratory testing charter: frame what to investigate, why it matters, and which risk hypotheses to test before or alongside the shared testing workflow. Triggers include "exploratory testing for...", "what should I investigate in this app", "help me think about what could go wrong", "risk hypotheses for...", "testing charter for...", "where should I probe deeper", or any request that needs structured thinking about test intent before coverage planning begins. This skill owns exploratory intent, risk framing, investigation order, and concrete follow-up asks for missing evidence; it does NOT own exploration evidence (capture-feature-evidence), final coverage prioritization (plan-test-coverage), or test case specs (generate-test-cases).

THE DEFAULT ENTRY POINT for the Playwright execution layer in the split testing suite. Use to add, create, or set up Playwright end-to-end tests for a feature, page, or application. It orchestrates the full Playwright workflow after shared exploration and planning: analyze the Playwright codebase, consume `docs/qa/feature-map.md`, `docs/qa/exploration-report.md`, `docs/qa/coverage-plan.md`, and `docs/qa/test-cases/*.md`, write production-grade test code, review it, and verify it with real execution. Delegates to `analyze-test-codebase`, `write-test-code`, `review-test-code`, and `fix-flaky-tests`, while relying on shared `map-feature-scope`, `capture-feature-evidence`, `plan-test-coverage`, `generate-test-cases`, and `review-test-cases`.

Scans and reports on an existing Playwright test codebase. This skill should be used to inspect the current Playwright setup before writing, reviewing, or fixing tests, and should be loaded early when working in a new project to understand existing patterns. Covers: Playwright config, page objects, fixtures, helpers, auth/globalSetup patterns, test conventions, and directory structure. Triggers: "understand", "check", "show me", "inspect", or "analyze" the current test setup, config, infrastructure, patterns, or conventions. In the full add-tests workflow, this skill serves as an early read-only analysis sub-step before planning detailed coverage or writing code. This skill examines existing files and outputs a structured report. It does NOT write or fix tests, install Playwright, or explore live websites — for live-site exploration, use `capture-feature-evidence` so evidence is captured in `docs/qa/exploration-report.md`.

Quality review of Playwright test code before final execution signoff. This skill should be used when implementation review of executable Playwright tests is needed, not for diagnosis of runtime flakiness. Triggers: "review test code", "review Playwright tests", "check test quality", "audit test implementation", "review my tests before merging", "check test code for issues", "review e2e tests", "code review Playwright", "are my tests stable", "check for brittle selectors", "review before running tests". Quality gate after write-test-code — catches brittle selectors, force:true misuse, networkidle overuse, Tailwind utility class selectors, exact numeric assertions, missing teardown, parallel-unsafe mutations, hardcoded data, missing assertions, test coupling, and convention divergence. Review-only — does NOT rewrite tests, does NOT run tests. Use fix-flaky-tests for fixing, write-test-code for rewriting.

This skill should be used when writing, refactoring, or modifying Playwright E2E test code. It covers creating test files from TC-ID specs, converting browser exploration results to executable tests, refactoring locators or fixtures, adding API mocking, test data setup/teardown, and parallel-safe isolation. Includes locator strategy hierarchy, auth setup patterns, fixture design, teardown strategies, and network interception recipes. Triggers: "write a test for", "add a test case", "refactor this locator", "add error path tests", "convert specs to code", "add API mocking", "set up auth for tests". NOT for: full pipeline from scratch (use add-playwright-tests), shared live-site exploration (use capture-feature-evidence), generating specs without code (use plan-test-coverage or generate-test-cases), diagnosing flaky tests (use fix-flaky-tests).

Use to define impact-based regression scope for a release, hotfix, changed area, or risky feature: decide what should be rerun beyond smoke, why it belongs in regression, and how deep each area should go. Triggers include "regression scope for...", "what should we rerun after this change", "what belongs in release regression", "impact-based rerun plan", "high-risk regression plan", "what's beyond smoke", or "pre-release regression checklist". This skill owns regression intent, included areas, and rerun depth; it does NOT own live exploration, shared coverage planning, detailed TC-ID specs, or framework-specific automation.

THE DEFAULT ENTRY POINT for the Robot Framework execution layer in the split testing suite. Use to add, create, or set up Robot Framework end-to-end tests for a feature, page, or application. It orchestrates the Robot-specific workflow after shared exploration and planning: analyze the `.robot` codebase, consume `docs/qa/feature-map.md`, `docs/qa/exploration-report.md`, `docs/qa/coverage-plan.md`, and `docs/qa/test-cases/*.md`, write production-grade `.robot` suites, review them, and verify them with real execution. Delegates to `analyze-test-codebase`, `write-robot-code`, `review-test-code`, and `fix-flaky-tests`, while relying on shared `map-feature-scope`, `capture-feature-evidence`, `plan-test-coverage`, `generate-test-cases`, and `review-test-cases`.

Use to inspect an existing Robot Framework + Browser library codebase before writing, reviewing, or fixing tests. Covers robot.toml or pyproject config, resource files, keyword libraries, listeners, auth keywords, suite init (`__init__.robot`), tag conventions, directory structure, and emits the typed `docs/qa/conventions.yaml` contract used by downstream skills. Triggers: "understand", "check", "show me", "inspect", or "analyze" the current Robot Framework test setup, config, infrastructure, patterns, or conventions. Does NOT write or fix tests, install Robot Framework, or explore live websites.

This skill should be used when a Robot Framework test (Browser library) is failing, flaky, timing out, or behaving inconsistently. It provides structured root cause analysis for: stabilizing intermittent tests, debugging timeouts, fixing race conditions, investigating local-vs-CI divergence, config drift, strict-mode ambiguity, and running repeated stability checks. IMPORTANT: If running tests with repeated runs, retries, or pabot loops to check stability, STOP and load this skill first — it has structured root cause analysis that prevents brute-force approaches. Triggers: "stabilize", "intermittent", "flaky", "keeps failing", "fails in CI", "timeout on", "race condition", "run N times to check stability", "verify Robot tests are stable". NOT for writing new tests (use write-robot-code) or analyzing setup (use analyze-test-codebase).

Use when reviewing Robot Framework and Python test automation code for best practices, maintainability, reliability, style, architecture, anti-patterns, or caveats. Trigger for `.robot`, `.resource`, Python custom libraries, Robot variable files, Browser/Selenium/API test suites, "Robot Framework best practices", "review automation quality", "what should be avoided", "common Robot issues", and "Python Robot library review". Review-only; does not rewrite tests or diagnose a specific flaky failure.

Quality review of Robot Framework test code before final execution signoff. This skill should be used when implementation review of executable `.robot` files is needed, not for diagnosis of runtime flakiness. Triggers: "review test code", "review Robot tests", "check test quality", "audit test implementation", "review my Robot tests before merging", "check .robot for issues", "review e2e tests", "code review Robot Framework", "are my tests stable", "check for brittle locators", "review before running tests". Quality gate after write-robot-code — catches wrong Browser-library dialect, brittle locators, post-action response waits, `force=True` misuse, `Sleep`, utility-class selectors, exact numeric assertions, missing teardown, parallel-unsafe mutations, hardcoded data, missing assertions, test coupling, and convention divergence. Review-only — does NOT rewrite tests, does NOT run tests. Use fix-flaky-tests for fixing, write-robot-code for rewriting.

Use when writing, refactoring, or modifying Robot Framework E2E test code with the Browser library. Covers creating `.robot` suites from TC-ID specs, converting browser exploration results to executable keywords, refactoring locators or resources, adding network mocking via `Route`, test data setup with RequestsLibrary, `docs/qa/conventions.yaml` adherence, smoke-first implementation, auth patterns, and parallel-safe isolation for `pabot`. Triggers: "write a Robot test for", "add a Robot test case", "refactor this locator", "add error path tests", "convert specs to .robot code", "add network mocking in Robot", "set up auth for Robot tests". NOT for: full pipeline from scratch (use add-robot-tests), shared live-site exploration (use capture-feature-evidence), generating specs without code (use plan-test-coverage or generate-test-cases), diagnosing flaky tests (use fix-flaky-tests).

Use to define the smallest high-signal confidence slice for a product, feature, or release. Triggers include "what should be in smoke", "define the minimum checks", "smoke scope for...", "critical-path confidence for...", or "what must never break before release". This skill owns smoke intent and prioritization; it does NOT own exploration evidence, shared coverage planning, detailed TC-ID specs, or framework-specific automation.

Use to write detailed TC-ID test case specifications for a web app feature, not executable code. This shared skill consumes `docs/qa/exploration-report.md`, `docs/qa/coverage-plan.md`, and existing coverage artifacts to write structured specs under `docs/qa/test-cases/`. Use it after coverage planning or when asked for test cases or TC-IDs. It does not write framework-specific test code.

Use before writing specs or executable tests to decide what coverage is needed first. This shared planning skill consumes exploration evidence, existing tests, and related artifacts to produce `docs/qa/coverage-plan.md` with prioritized P0/P1/P2 coverage and TC-IDs. When `docs/qa/exploratory-charter.md` exists (produced by `exploratory-test-writer`), use it as optional risk-framing context; do not require it and do not let it replace grounded exploration evidence. Use it for requests like "what tests do I need", "coverage gaps", or "what TC-IDs are missing". It plans; it does not perform the canonical exploration step and it does not write executable tests.

This skill should be used when a quality review of TC-ID test case specifications is needed before any framework-specific implementation begins. It reviews the spec artifact only; it does not implement or rewrite tests. Triggers: "review test cases", "check test specs", "review TC-IDs", "audit test coverage", "are my test cases good", "validate test specs", "review docs/qa/test-cases/*.md", "check for gaps in test cases", "review before writing tests", and "quality check test specs". Inserted as the shared quality gate between `generate-test-cases` and execution-layer authoring — catches gaps, duplication, weak assertions, missing error paths, and invented scenarios before they get encoded into framework-specific code.

Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into issues.

Turn the current conversation context into a PRD and publish it to the project issue tracker. Use when user wants to create a PRD from the current context.

Triage issues through a state machine driven by triage roles. Use when user wants to create an issue, triage issues, review incoming bugs or feature requests, prepare issues for an AFK agent, or manage issue workflow.

Package an in-flight fullstack-engineering task into a resumable relay note so the next agent continues at the exact phase and gate. Use at a clean slice/phase/gate boundary, or mid-task when the current agent is out of usable context (token window exhausted, context rot, "compact and continue"). Captures the Turn Protocol block, cleared gates, working branch + last pushed commit, durable-artifact pointers, the exact next action, and open blockers; saves to the OS temp dir like `handoff`. Triggers - "workflow handoff", "hand off this task", "relay to the next agent", "pass the baton", "continue in a fresh session", "running low on context", "context rot", "approaching the token limit", "I finished phase N, hand off", "resume from here", or any stop-and-handoff route into Phase 10. Unlike `handoff` (a generic conversation summary), this preserves binding workflow state for mid-flight resumption. It does NOT advance phases, waive gates, or duplicate the tracker/design/plan/commits - it references them.

Sets up the engineering workflow's per-repo context — an `## Agent skills` block in AGENTS.md/CLAUDE.md plus `docs/agents/` — capturing this repo's issue tracker (GitHub, GitLab, or local markdown), triage label vocabulary, and domain doc layout, and recording the full workflow skill map as a reference inventory. Run before first use of the engineering workflow or its skills (`to-issues`, `to-prd`, `triage`, `diagnose`, `tdd`, `improve-codebase-architecture`, `zoom-out`), or if those skills appear to be missing context about the issue tracker, triage labels, or domain docs.

MUST load BEFORE reading from or writing to ClickUp and BEFORE any mcp__plugin_clickup_clickup__ tool call. Use when the user asks to create, inspect, update, triage, plan, comment on, assign, or close ClickUp tasks, subtasks, lists, folders, spaces, docs, checklists, custom fields, statuses, sprints, goals, or time-tracking entries; when a workflow needs task-tracker context; when converting plans or PRDs into ClickUp work; when syncing delivery status back to ClickUp; or when the user says "ClickUp", "task", "subtask", "list", "folder", "space", "workspace", "doc", "checklist", "custom field", "status", "sprint", "goal", "time tracking", "due date", "assignee", or a ClickUp task ID such as 86abc1234 or a custom ID like GH-123. This skill teaches agent workflow discipline for ClickUp; it does not replace project-specific planning, code review, tests, or browser verification.

MUST load BEFORE reading from or writing to Linear and BEFORE any mcp__plugin_linear_linear__ tool call. Use when the user asks to create, inspect, update, triage, plan, comment on, or close Linear issues, projects, milestones, cycles, labels, teams, or backlog items; when a workflow needs issue-tracker context; when converting plans or PRDs into Linear work; when syncing delivery status back to Linear; or when the user says "Linear", "ticket", "issue", "project board", "backlog", "triage", "cycle", "roadmap", "blocked by", "branch from issue", or an issue key such as ABC-123. This skill teaches agent workflow discipline for Linear; it does not replace project-specific planning, code review, tests, or browser verification.

Scaffold, create, revise, or review complete Athena workflow packages, including workflow.md orchestration docs, workflow.json definitions, Plugin Pins, marketplace registration, and validation. Use when the user asks to create, scaffold, design, write, review, update, or package an Athena workflow, workflow.md, workflow.json, or end-to-end agent workflow definition.

MUST load BEFORE designing or implementing ANY user-visible UI — components, pages, layouts, flows, dashboards, marketing sites, settings screens, empty/error/loading states, or visual polish. Drives deliberate hierarchy, typography, spacing, color, motion, responsive behavior, and a11y so output isn't generic AI-default slop. Trigger on ANY of: 'build a page', 'design a screen', 'create a component', 'make a UI for', 'dashboard', 'landing page', 'marketing site', 'pricing page', 'sign-up flow', 'login screen', 'settings page', 'admin panel', 'data table', 'empty state', 'error state', 'loading skeleton', '404 page', 'redesign this', 'polish the UI', 'make it look better', 'hero section', 'navbar', 'sidebar', 'modal', 'responsive layout', 'dark mode', or any task whose output is HTML/JSX/TSX a human looks at. Use even when the user just says 'add a page for X'. Does NOT replace shadcn-ui (primitives) or tanstack-start-guide (routing); pair for the visual layer.

MUST load BEFORE writing, scaffolding, debugging, or migrating any TanStack Start / Router / React Start app, and BEFORE hand-rolling routing, loaders, server functions, server routes, middleware, SSR, or RSC. Trigger on ANY of: "TanStack Start/Router", "React Start", "@tanstack/start", "@tanstack/react-start", "@tanstack/react-router", "createFileRoute", "createRootRoute", "createServerFn", "createServerRoute", "start-basic", "file-based routes", "virtual file routes", "authenticated route", "route guard/loader", "deferred data", "useLoaderData/useSearch/useParams/useNavigate", "search params validation", "navigation blocking", "view transitions", "location masking", "tRPC/React Query with TanStack", "SSR/RSC in Start", "not-found route", "migrate Next.js to TanStack", "deploy TanStack Start". Also applies when the codebase has `app/routes/` with `createFileRoute` or `@tanstack/*` imports, even if "TanStack" isn't named. Does NOT cover generic React or visual design — pair with frontend-design / shadcn-ui.

MUST load BEFORE adding, composing, theming, or installing shadcn/ui components, and BEFORE any mcp__plugin_shadcn_shadcn__* tool call. Trigger on ANY of: "shadcn", "shadcn/ui", "components.json", "@shadcn", "@acme", "@tailark", "registry", "namespaced registry", "private registry", "add a button/dialog/card/form/sheet/sidebar", "build a login form", "build a dashboard", "build a settings page", "landing page with shadcn", "switch preset", "--preset", "OKLCH", "CSS variables theming", "dark mode tokens", "shadcn init/add/search/view/docs/diff/info/build", "registry.json", "publish a registry", "FieldGroup", "ToggleGroup", "radix base". Without this skill, output uses wrong base APIs, invents component names, skips registry resolution, ignores the project's aliases and icon library, and misuses theming tokens.

This skill should be used when a Playwright test is failing, flaky, timing out, or behaving inconsistently. It provides structured root cause analysis for: stabilizing intermittent tests, debugging timeouts ("Test timeout of 30000ms exceeded"), fixing race conditions, investigating local-vs-CI divergence, running repeated stability checks (--repeat-each). IMPORTANT: If running tests with --repeat-each, --retries, or multiple times to check stability, STOP and load this skill first — it has structured root cause analysis that prevents brute-force approaches. Triggers: "stabilize", "intermittent", "flaky", "keeps failing", "fails in CI", "timeout on", "race condition", "run N times to check stability", "verify tests are stable". NOT for writing new tests (use write-test-code) or analyzing setup (use analyze-test-codebase).

MUST load BEFORE any mcp__plugin_agent-web-interface_browser__* tool call (navigate, snapshot, click, type, find, get_element, get_form, press, select, scroll, list_pages, screenshot). Load the instant a task mentions a URL, a bare domain, or any live-site interaction — even a single click or "just open this page". Without it, browser work yields brittle selectors, prose instead of structured observations, stale eid reuse, and broken handoff to test-writing skills. Trigger on ANY of: "open", "go to", "visit", "navigate to", "browse to", "check the page", "walk through the flow", "click", "press", "tap", "fill in", "submit", "type into", "select dropdown", "log in", "sign up", "add to cart", "checkout", "search the site", "find the element", "inspect the form", "capture selectors", "explore the site", "screenshot", "reproduce on that url", or any mention of pages, forms, buttons, dropdowns, or dialogs on a live site. Also load on subagent dispatch with browser MCP access. If even a 1% chance applies, LOAD IT.

Export markdown file(s) to styled dark-theme PDF. Use for requests like "export to PDF", "convert markdown to PDF", "generate PDF", "make a PDF from markdown", or "export md".

Use when automating airbnb.com, searching for stays, browsing experiences, creating wishlists, completing bookings, or writing tests for Airbnb flows. Covers site structure, search and booking heuristics, and common Airbnb interaction patterns. Load live selectors from the browser; use the bundled reference only for flow guidance and modal caveats.

Use when automating amazon.com, searching for products, adding items to cart, browsing deals, navigating product pages, or writing tests for Amazon shopping flows. Covers site structure, search/buying heuristics, and common Amazon interaction patterns. Load live selectors from the browser; use the bundled reference only for flow guidance and site-specific caveats.

Use when automating apple.com, configuring iPhones or other Apple products, navigating the Apple Store, adding items to bag, or writing tests for Apple Store flows. Covers site structure, purchase flows, bag behavior, and Apple-specific interaction patterns. Load live selectors from the browser; use the bundled reference only for site heuristics and flow guidance.

Run the WebBench browser agent benchmark — main entry point and orchestrator. Triggers: "run benchmark", "run WebBench", "start benchmark", "benchmark browser agent", "web bench", "execute WebBench", "run web-bench". Parses the requested configuration (category filter, sample size, resume), delegates to load-dataset, execute-task, evaluate-task, and generate-report skills. This is the interactive orchestrator that ties the full benchmark pipeline together.

Evaluate whether a WebBench task was successfully completed using LLM-as-judge scoring. Triggers: "evaluate task", "score task", "judge result", "grade benchmark task". Examines the execution trace, final page state, and extracted data against the original task description. Produces a structured verdict (PASS/PARTIAL/FAIL) with reasoning. Does NOT execute browser actions — use execute-task for that.

Methodology for executing a single WebBench benchmark task via browser automation. Triggers: "execute task", "run task", "perform benchmark task", "browser task". Interprets the natural-language task description, defines the required browser actions, and specifies what final evidence to capture (for example screenshot + snapshot). Records an execution trace with actions taken and errors encountered. Does NOT evaluate success — use evaluate-task for that.

Aggregate WebBench benchmark results into a comprehensive evaluation report. Triggers: "generate report", "create benchmark report", "summarize results", "aggregate scores", "produce evaluation report". Reads web-bench-results.jsonl, computes statistics by category/website/failure mode, and writes web-bench-report.md with pass rates, timing, token usage, and analysis. Does NOT execute or evaluate tasks — only aggregates existing results.

Download and prepare the Halluminate/WebBench dataset from HuggingFace for benchmarking. Triggers: "load dataset", "download WebBench", "prepare benchmark data", "fetch tasks". Downloads the CSV dataset via curl, converts to JSONL with Node.js, applies optional filters (category, sample size, website allowlist/blocklist), and writes web-bench-tasks.jsonl to the working directory. Zero Python dependencies — uses only curl and Node.js. Does NOT execute tasks — use execute-task for that.