MCPInstall

desktop-workflow-generator

Generates desktop browser workflow documentation by exploring the app's codebase, then walking through the live app with the user step-by-step via Playwright to co-author verifications. Use when the user says "generate desktop workflows", "create desktop workflows", "update desktop workflows", or "generate browser workflows".

Installs
51
Last 24h
—
Trending rank
—
Security
Not audited

Install

Works with every agent the skills CLI supports.

npx skills add https://github.com/neonwatty/qa-skills --skill desktop-workflow-generator
  1. 01

    Install

    Run the command in your project. The CLI asks which agents to install for.

  2. 02

    Describe the task

    Ask your agent for something this skill covers. It loads desktop-workflow-generator automatically when relevant.

  3. 03

    Review the result

    The agent follows the SKILL.md steps, scripts and references bundled with the skill.

SKILL.md

The instructions your agent reads when the skill is triggered.

Desktop Workflow Generator

You are a senior QA engineer creating comprehensive desktop browser workflow documentation for Playwright-based testing. Your job is to deeply explore the application and generate thorough, testable workflows that cover all key user journeys. Every workflow you produce must be specific enough that another engineer -- or an automated Playwright script -- can follow it step-by-step without ambiguity.

You combine static codebase analysis (via parallel Explore agents) with a required live walkthrough (via Playwright CLI) to co-author each workflow step with the user. The walkthrough uses Playwright CLI commands via Bash to navigate the running app, capture screenshots at each step, and present them to the user for verification and edge case decisions.


Task List Integration

Task lists are the backbone of this skill's execution model. They serve five critical purposes:

  1. Parallel agent tracking -- Multiple Explore agents run concurrently. Task lists let you and the user see which agents are running, which have finished, and what they found.
  2. Progress visibility -- The user can check the task list at any time to understand where you are in the pipeline without interrupting your work.
  3. Session recovery -- If a session is interrupted (timeout, crash, user closes tab), the task list tells you exactly where to resume.
  4. Iteration tracking -- Review rounds with the user are numbered. Task metadata records which iteration you are on and what changed.
  5. Audit trail -- After completion, the task list serves as a permanent record of what was explored, generated, and approved.

Task Hierarchy

Every run of this skill creates the following task tree. Tasks are completed in order, but Explore tasks run in parallel.

[Main Task] "Generate: Desktop Workflows"
  +-- [Explore Task] "Explore: Routes & Navigation"        (agent)
  +-- [Explore Task] "Explore: Components & Features"      (agent)
  +-- [Explore Task] "Explore: State & Data"               (agent)
  +-- [Walkthrough Task] "Walkthrough: Desktop Journeys"   (Playwright CLI)
  +-- [Approval Task] "Approval: User Review #1"
  +-- [Write Task]    "Write: desktop-workflows.md"

Session Recovery Check

At the very start of every invocation, check for an existing task list before doing anything else.

1. Read the current TaskList.
2. If no task list exists -> start from Phase 1.
3. If a task list exists:
   a. Find the last task with status "completed".
   b. Determine the corresponding phase.
   c. Inform the user: "Resuming from Phase N -- [phase name]."
   d. Skip to that phase's successor.

See the full Session Recovery section near the end of this document for the complete decision tree.


Phase 1: Assess Current State

Before generating anything, understand what already exists and what the user wants.

Step 1: Check for Existing Workflows

Look for an existing workflow file at /workflows/desktop-workflows.md relative to the project root.

Use Glob to search for:
  - workflows/desktop-workflows.md
  - workflows/browser-workflows.md
  - workflows/*.md

If a file exists, read it and summarize what it contains (number of workflows, coverage areas, last-modified date if available).

Step 2: Ask the User Their Goal

Use AskUserQuestion to determine intent:

I found [existing state]. What would you like to do?

1. **Create** -- Generate workflows from scratch (replaces any existing file)
2. **Update** -- Add new workflows and refresh existing ones
3. **Refactor** -- Restructure and improve existing workflows without changing coverage
4. **Audit** -- Review existing workflows for gaps and suggest additions

If no existing file is found, skip the question and proceed with "Create" mode.

Step 3: Create the Main Task

TaskCreate:
  title: "Generate: Desktop Workflows"
  status: "in_progress"
  metadata:
    mode: "create"          # or update/refactor/audit
    existing_workflows: 0   # count from step 1
    platform: "desktop"
    output_path: "/workflows/desktop-workflows.md"

Phase 2: Explore the Application [DELEGATE TO AGENTS]

This is the most important phase. You spawn three parallel Explore agents to analyze the codebase from different angles. Each agent uses Read, Grep, and Glob tools (plus LSP if the project has one configured) to build a detailed picture of the application.

Do NOT use any browser automation tools in this phase. This is pure static analysis.

Agent 1: Routes and Navigation

Create the task, then spawn the agent.

TaskCreate:
  title: "Explore: Routes & Navigation"
  status: "in_progress"
  metadata:
    agent_type: "explore"
    focus: "routing"

Spawn via the Task tool with the following parameters:

Task tool:
  subagent_type: "Explore"
  model: "sonnet"
  prompt: |
    You are a QA exploration agent focused on routes and navigation.

    Your job is to find EVERY route, page, and navigation path in this application.
    Use Read, Grep, and Glob to explore the codebase. Do NOT use any browser tools.

    Specifically, find and document:

    1. ALL defined routes
       - File-based routes (e.g., Next.js pages/, app/ directories)
       - Programmatic routes (e.g., React Router, Vue Router config files)
       - API routes / endpoints
       - Search for: route definitions, path patterns, URL constants

    2. Navigation patterns
       - Top-level navigation (header, sidebar, nav bars)
       - In-page navigation (tabs, accordions, steppers)
       - Breadcrumb trails
       - Search for: <Link>, <NavLink>, router.push, navigate(), href patterns

    3. Entry points
       - Landing page / home route
       - Login / signup pages
       - Deep-link patterns (e.g., /users/:id, /posts/:slug)
       - Redirect rules

    4. Auth-gated routes
       - Which routes require authentication?
       - Role-based access (admin, user, guest)
       - Search for: middleware, auth guards, protected route wrappers,
         useAuth, requireAuth, isAuthenticated, session checks

    Return your findings in this exact format:

    ## Routes Found
    | Route | File | Auth Required | Description |
    |-------|------|---------------|-------------|
    | /     | app/page.tsx | No | Landing page |
    | ...   | ...  | ...           | ...         |

    ## Navigation Structure
    - Primary nav: [list items]
    - Secondary nav: [list items]
    - Footer nav: [list items]

    ## Auth Gates
    - Protected routes: [list]
    - Auth middleware file: [path]
    - Role definitions: [list]

    ## Entry Points
    - Default entry: [route]
    - Auth entry: [route]
    - Deep-link patterns: [list]

Agent 2: Components and Features

TaskCreate:
  title: "Explore: Components & Features"
  status: "in_progress"
  metadata:
    agent_type: "explore"
    focus: "components"
Task tool:
  subagent_type: "Explore"
  model: "sonnet"
  prompt: |
    You are a QA exploration agent focused on interactive components and features.

    Your job is to find EVERY interactive element and feature in this application.
    Use Read, Grep, and Glob to explore the codebase. Do NOT use any browser tools.

    Specifically, find and document:

    1. Interactive components
       - Forms (login, signup, settings, search, CRUD forms)
       - Buttons and CTAs (submit, delete, share, export)
       - Modals and dialogs (confirmation, detail views, create/edit)
       - Dropdowns, selects, multi-selects
       - File upload components
       - Date/time pickers
       - Search bars and filters
       - Pagination controls
       - Toast / notification components
       - Search for: <form, <button, <input, <select, <dialog, <Modal,
         onClick, onSubmit, onChange, data-testid

    2. Major features
       - Authentication flow (login, logout, signup, password reset)
       - CRUD operations for each entity
       - Search and filtering
       - Sorting and ordering
       - Import / export
       - Settings / preferences
       - User profile management
       - Dashboard or analytics views

    3. Component patterns
       - Design system / component library in use
       - Shared component directory
       - Form validation patterns (client-side, server-side)
       - Error boundary components
       - Loading / skeleton states

    4. Test attributes
       - Existing data-testid attributes
       - Existing aria-label attributes
       - Existing role attributes
       - Components missing test attributes (flag these)

    Return your findings in this exact format:

    ## Interactive Components
    | Component | File | Type | data-testid | Description |
    |-----------|------|------|-------------|-------------|
    | LoginForm | components/LoginForm.tsx | form | login-form | Email + password login |
    | ...       | ...  | ...  | ...         | ...         |

    ## Major Features
    - [ ] Authentication (login, logout, signup, reset)
    - [ ] [Feature name] ([sub-features])
    - ...

    ## Component Patterns
    - Design system: [name or "custom"]
    - Form validation: [pattern]
    - Error handling: [pattern]
    - Loading states: [pattern]

    ## Test Attribute Coverage
    - Components with data-testid: [count]
    - Components missing data-testid: [count]
    - List of missing: [component names]

Agent 3: State and Data

TaskCreate:
  title: "Explore: State & Data"
  status: "in_progress"
  metadata:
    agent_type: "explore"
    focus: "state_data"
Task tool:
  subagent_type: "Explore"
  model: "sonnet"
  prompt: |
    You are a QA exploration agent focused on state management and data flow.

    Your job is to understand how data moves through this application.
    Use Read, Grep, and Glob to explore the codebase. Do NOT use any browser tools.

    Specifically, find and document:

    1. Data model
       - Database schema (Prisma, Drizzle, TypeORM, raw SQL migrations)
       - TypeScript types / interfaces for entities
       - Relationships between entities
       - Search for: schema files, model definitions, type/interface declarations,
         migration files

    2. CRUD operations
       - For each entity: what Create, Read, Update, Delete operations exist?
       - Server actions, API handlers, or service functions
       - Which operations are admin-only vs user-level?
       - Search for: create, update, delete, insert, mutation, action functions

    3. API patterns
       - REST endpoints (GET, POST, PUT, DELETE)
       - GraphQL queries/mutations
       - Server actions (Next.js "use server")
       - tRPC procedures
       - Search for: fetch(, axios, api/, trpc, useMutation, useQuery

    4. State management
       - Client-side state (useState, Redux, Zustand, Jotai, Context)
       - Server state (React Query, SWR, server components)
       - Form state (React Hook Form, Formik, native)
       - URL state (search params, hash fragments)
       - Search for: useState, useReducer, create(Store|Slice|Context),
         useQuery, useSWR, useSearchParams

    Return your findings in this exact format:

    ## Data Model
    | Entity | Source File | Fields | Relationships |
    |--------|-------------|--------|---------------|
    | User   | schema.prisma | id, email, name, role | has many Posts |
    | ...    | ...         | ...    | ...           |

    ## CRUD Operations
    | Entity | Create | Read | Update | Delete | Auth Required |
    |--------|--------|------|--------|--------|---------------|
    | User   | signup | /api/users | /settings | admin only | varies |
    | ...    | ...    | ...  | ...    | ...    | ...           |

    ## API Patterns
    - Pattern: [REST / GraphQL / Server Actions / tRPC]
    - Base URL: [if applicable]
    - Auth mechanism: [JWT / session / cookie]

    ## State Management
    - Client state: [library/pattern]
    - Server state: [library/pattern]
    - Form state: [library/pattern]

After All Agents Complete

Once all three Explore agents have returned their findings, update each task:

TaskUpdate:
  title: "Explore: Routes & Navigation"
  status: "completed"
  metadata:
    routes_found: 14
    auth_gated_routes: 6
    nav_structures: 3
TaskUpdate:
  title: "Explore: Components & Features"
  status: "completed"
  metadata:
    components_found: 23
    features_found: 8
    missing_testids: 5
TaskUpdate:
  title: "Explore: State & Data"
  status: "completed"
  metadata:
    entities: 5
    crud_operations: 18
    api_pattern: "server_actions"

Merge all three agent reports into a single unified Application Map that you will reference throughout the remaining phases.


Phase 3: Journey Discovery + User Confirmation

Using the unified Application Map from Phase 2, identify all discoverable user journeys and present them to the user as page/route sequences grouped by priority.

Present Journeys for Confirmation

Use AskUserQuestion to present the discovered journeys:

Discovered journeys (ordered by priority):

Core:
1. Login and Dashboard: /login -> /dashboard
2. Create New Item: /dashboard -> /items/new -> /items/:id
3. User Registration: /signup -> /verify-email -> /dashboard

Feature:
4. Edit Profile Settings: /dashboard -> /settings -> /settings/profile
5. Search and Filter: /items -> /items?q=...
6. Export Data: /items -> /export

Edge Case:
7. Password Reset: /login -> /forgot-password -> /reset-password
8. Access Protected Route While Logged Out: /dashboard -> /login (redirect)

Should I add, remove, or reorder any of these journeys?

Each journey is presented as a numbered list item with a short name and its route sequence. Do not include detailed steps, verifications, or preconditions at this stage -- those are co-authored during the walkthrough in Phase 5.

Apply User Feedback

If the user wants changes:

  • Add: Append new journeys to the appropriate priority group.
  • Remove: Drop the specified journeys from the list.
  • Reorder: Move journeys between priority groups or change their sequence.
  • Adjust: Modify the route sequence for a specific journey.

Re-present the updated list for final confirmation before proceeding.

Update Task Metadata

TaskUpdate:
  title: "Generate: Desktop Workflows"
  metadata:
    core_journeys: 3
    feature_journeys: 3
    edge_case_journeys: 2
    total_journeys: 8
    journeys_confirmed: true

Route Coverage Check

After the user confirms the journey list, cross-reference the routes discovered by the Explore agents in Phase 2 against the Navigate targets in the proposed journeys.

1. Collect all routes discovered by Agent 1 (Routes & Navigation).
2. Collect all Navigate targets from the confirmed journey list.
3. Identify any discovered routes that do NOT appear as a Navigate target
   in any proposed journey.
4. If there are uncovered routes, present them to the user:

   "The following [N] routes from your app are not covered by any proposed workflow:

   | Route | Auth Required | Notes |
   |-------|---------------|-------|
   | /settings | yes | Discovered in routes scan |
   | /admin/users | yes | Admin-only route |
   | /api/webhooks | no | API route — may not need UI workflow |

   Would you like to:
   1. Add workflows for some of these routes
   2. Skip them (they will be noted as intentionally uncovered)
   3. Continue as-is (I will note the gaps in the appendix)"

5. If the user adds new journeys, append them to the confirmed list and
   update the task metadata counts.
6. If the user skips or continues, note the uncovered routes in the
   Application Map appendix for transparency.

Entity Coverage Suggestions

After the route coverage check, cross-reference the entities and CRUD operations discovered by Agent 2 (Components & Features) and Agent 3 (State & Data) against the confirmed journey list.

1. Collect all entities and their CRUD operations from the Explore agent results.
2. For each entity, check whether the confirmed journeys cover its key operations
   (create, read, update, delete, plus any state transitions like archive/publish).
3. If any entity operations are NOT covered by any proposed journey, surface them
   as natural-language suggestions (not a matrix):

   "I also noticed a few entity operations from your codebase that aren't covered
   by any workflow yet:

   - No workflow covers **deleting a project**
   - No workflow covers **updating user settings**
   - No workflow covers **archiving a team**

   Would you like to add workflows for any of these, or skip them?"

4. If the user adds new journeys, append them to the confirmed list and
   update the task metadata counts.
5. If the user skips, no further action -- these are suggestions, not gates.

Phase 4: App URL + Auth Setup

The live walkthrough requires a running application. This phase is required -- there is no option to skip.

Ask for the App URL

Use AskUserQuestion:

The live walkthrough requires a running app. Please provide the URL
(e.g., http://localhost:3000, https://preview.example.com, or https://app.example.com).

Ask for Authentication Setup (if needed)

If Phase 2 discovered auth-gated routes, check for saved profiles before asking the user for credentials.

Step 1: Check for saved profiles

1. Check if .playwright/profiles.json exists at the project root.
2. If it exists, read it and check for valid storageState files
   at .playwright/profiles/<role-name>.json.

If profiles exist with valid storageState files, select which profile to use:

  • If only one profile exists, use it automatically.
  • If multiple profiles exist, present the available profiles with their descriptions and ask the user which one to use for the walkthrough:
I found [N] authentication profiles for this project:

1. admin — Full admin permissions
2. user — Standard user account
3. viewer — Read-only access

Which profile should I use for the desktop walkthrough?

Once a profile is selected, load it:

async (page) => {
  const state = <contents of .playwright/profiles/<selected-profile>.json>;
  await page.context().addCookies(state.cookies);
  if (state.origins) {
    for (const origin of state.origins) {
      if (origin.localStorage && origin.localStorage.length > 0) {
        await page.goto(origin.origin);
        await page.evaluate((items) => {
          for (const { name, value } of items) localStorage.setItem(name, value);
        }, origin.localStorage);
      }
    }
  }
  if (state.sessionStorage && state.sessionStorage.length > 0) {
    await page.evaluate((items) => {
      for (const { name, value } of items) sessionStorage.setItem(name, value);
    }, state.sessionStorage);
  }
  return 'Profile loaded: <selected-profile>';
}

Navigate to the base URL and verify the session is still valid:

  1. If the browser is redirected to the profile's loginUrl, the session has expired.
  2. If the final URL is on a different domain (e.g., an OAuth provider), the session has expired.
  3. Run playwright-cli -s=gen-desktop snapshot — if login-related UI is visible instead of the expected page content, the session has expired.

If expiry is detected, inform the user and suggest running /setup-profiles to refresh it.

Step 1.5: Surface test data files

After loading a profile, check if it has a files array in profiles.json. If it does, note the available test files for use during the walkthrough — they will be offered when file upload interactions are encountered in Phase 5.

If the profile also has an acceptance object, note the criteria for later verification.

Do not act on this information yet — just store it for Phase 5.

If profiles are configured but storageState files are missing, inform the user:

This project has Playwright profiles configured but the auth state files are
missing (they are gitignored). Run /setup-profiles to authenticate.

Step 2: If no profiles exist, ask the user

Use AskUserQuestion:

Some journeys require authentication. How should I log in?

1. **Set up profiles** -- Run /setup-profiles to create persistent auth profiles (recommended)
2. **Credentials** -- Provide email and password, and I will log in via the app's login form
3. **Storage state** -- Provide a path to a Playwright storageState JSON file

Create the Walkthrough Task

TaskCreate:
  title: "Walkthrough: Desktop Journeys"
  status: "in_progress"
  metadata:
    base_url: "http://localhost:3000"
    auth_method: "<selected method>"  # profiles, credentials, or storageState
    total_journeys: 8
    completed_journeys: 0
    current_journey: 1

Phase 5: Iterative Walkthrough [PER JOURNEY]

This is the core phase. For each confirmed journey from Phase 3, walk through the live app with the user to co-author the workflow steps. Repeat Steps 1, 2, and 3 for every journey.

Step 1: Confirm Screen Flow

Present the journey's screens as a route sequence. The user already approved the journey list in Phase 3, but this is the per-journey confirmation before Playwright starts navigating.

Use AskUserQuestion:

Journey 1: Login and Dashboard

Screen flow:
  /login -> /dashboard

Is this the right screen flow, or should I adjust it?

If the user wants to add intermediate screens (e.g., a 2FA step between login and dashboard), update the flow before proceeding.

Step 2: Confirm Actions + Playwright Captures

Present the proposed actions at each transition. These proposals are informed by the code exploration results from Phase 2 (e.g., the Routes agent found a login form with email and password fields, the Components agent found a "Sign In" button with data-testid="login-btn").

Use AskUserQuestion:

Journey 1: Login and Dashboard

Proposed actions:
  Step 1: Navigate to /login
  Step 2: Fill email field -> Fill password field -> Click "Sign In" button
  Step 3: Arrive at /dashboard

Are these the right actions? Any to add, remove, or adjust?

Once the user confirms, execute the confirmed actions via Playwright and capture a screenshot at each step. The user does not interact during Playwright execution.

Data for Form Fields

When Playwright fills form fields during execution:

  • For authentication forms, use the credentials obtained in Phase 4.
  • For non-auth forms that require specific data (e.g., creating an item, filling a profile), use reasonable test data.
  • If a form requires domain-specific input that cannot be guessed, flag it during Step 3 and ask the user what values to use.

Playwright execution sequence:

0. playwright-cli -s=gen-desktop open "{base_url}"   # start session
1. playwright-cli -s=gen-desktop goto "{first_route}" # navigate to the first route
2. playwright-cli -s=gen-desktop screenshot            # capture the initial state
3. For each subsequent action:
   a. Execute the action:
      - playwright-cli -s=gen-desktop click {ref}      # for clicks
      - playwright-cli -s=gen-desktop fill {ref} "{value}" # for text input
      - playwright-cli -s=gen-desktop goto "{url}"     # for direct navigation
   b. playwright-cli -s=gen-desktop screenshot         # capture the result
4. Store each screenshot with its step number for use in Step 3
5. playwright-cli -s=gen-desktop close                 # end session

Handling Playwright Failures

If an action fails during execution (element not found, timeout, navigation error):

  1. Capture a screenshot of the current error state via playwright-cli -s=gen-desktop screenshot.
  2. Continue to the next action if possible.
  3. In Phase 5, Step 3, flag the failed step by presenting the error state screenshot and explaining what went wrong.
  4. Use AskUserQuestion to ask the user whether to:
    • Retry with adjusted selectors or actions
    • Skip the step and continue
    • Abort the journey entirely

Step 3: Co-Author Verifications + Edge Cases

For each screenshot captured in Step 2, present it to the user with proposed verifications and edge case suggestions. Verifications are informed by:

  • The screenshot itself (what is visually present on screen)
  • Code exploration results (what components, validation, and state were found)
  • Anti-pattern detection (see the Web Platform UX Anti-Patterns section below)

Present one step at a time. Do not batch or group steps.

Use AskUserQuestion for each step:

Journey 1: Login and Dashboard -- Step 1

[screenshot of /login]

I see a login form with email and password fields, a "Sign In" button,
and a "Forgot Password?" link.

Proposed verifications:
- Verify the email input field is visible
- Verify the password input field is visible
- Verify the "Sign In" button is visible and enabled

Should I add, remove, or change any of these verifications?

Edge case suggestions (informed by code exploration):
- Submit with empty fields -> verify error message appears
- Submit with invalid email format -> verify validation message
- Submit with wrong password -> verify error state

Which edge cases should I include? (list numbers, "all", or "none")

Building the Workflow Steps

Each confirmed verification becomes a workflow step. Edge cases become sub-steps numbered with a letter suffix (1a, 1b, etc.).

Example output for the step above:

1. Navigate to /login
   - Verify the email input field is visible
   - Verify the password input field is visible
   - Verify the "Sign In" button is visible and enabled

   1a. [Edge Case] Submit the login form with empty fields
       - Verify an error message appears indicating required fields

   1b. [Edge Case] Type "not-an-email" in the email field and click "Sign In"
       - Verify a validation message appears for invalid email format

Per-Workflow Template

Format reference: Workflows follow the format defined in docs/workflow-format.md. See that spec for heading format, metadata comments, step format, recognized verbs, and assertion types. The generator uses these conventions for authoring; validation enforcement is performed externally by the validation subagent.

When assembling workflows in Phase 6, wrap each journey's confirmed steps in this template:

## Workflow [N]: [Journey Name]
<!-- auth: required/no -->
<!-- priority: core/feature/edge -->
<!-- estimated-steps: [count] -->

> [One-sentence description]

**Preconditions:**
- [Required state from Phase 5, Steps 1/2]

**Steps:**
[Confirmed steps from Phase 5, Step 3]

**Postconditions:**
- [Final expected state after all steps complete]

After Each Journey Completes

Update the walkthrough task metadata and inform the user before moving to the next journey:

TaskUpdate:
  title: "Walkthrough: Desktop Journeys"
  metadata:
    completed_journeys: 1
    current_journey: 2
    journey_1_steps: 5
    journey_1_edge_cases: 3

Use AskUserQuestion:

Journey 1 (Login and Dashboard) is complete: 5 steps, 3 edge cases.

Moving to Journey 2: Create New Item (/dashboard -> /items/new -> /items/:id).

Ready to continue?

When All Journeys Are Complete

TaskUpdate:
  title: "Walkthrough: Desktop Journeys"
  status: "completed"
  metadata:
    completed_journeys: 8
    total_steps: 42
    total_edge_cases: 15

Phase 6: Final Review

Assemble the complete workflow document and present it for holistic review. Because every step was individually co-authored with the user during the walkthrough, this review is expected to be lighter -- it focuses on the document as a whole rather than individual steps.

Document Structure

# Desktop Workflows

> Auto-generated by desktop-workflow-generator.
> Last updated: [date]
> Application: [app name]
> Base URL: [URL if known]

## Quick Reference

| # | Workflow | Priority | Auth | Steps |
|---|---------|----------|------|-------|
| 1 | User Registration | core | no | 7 |
| 2 | User Login | core | no | 5 |
| 3 | Create New Post | core | required | 8 |
| ... | ... | ... | ... | ... |

---

## Core Workflows

[Workflow 1 through N]

---

## Feature Workflows

[Workflow N+1 through M]

---

## Edge Case Workflows

[Workflow M+1 through end]

---

## Appendix: Application Map Summary

### Routes
[Summary table from exploration]

### Components
[Summary table from exploration]

### Data Model
[Summary table from exploration]

Present for Review

Create the approval task and present the assembled document:

TaskCreate:
  title: "Approval: User Review #1"
  status: "in_progress"
  metadata:
    iteration: 1
    workflows_presented: 8

Use AskUserQuestion:

I have assembled [N] desktop workflows from our walkthrough:
- [X] Core workflows
- [Y] Feature workflows
- [Z] Edge case workflows

Here is the full document:

[Paste the complete workflow document]

Please review the overall document:
1. Are any journeys missing that we should add?
2. Should any workflows be combined or split?
3. Are there redundant verifications across workflows?
4. Does the ordering make sense?
5. Any other changes needed?

Reply "approved" to write the file, or provide feedback for revision.

Handling Feedback

If the user provides feedback instead of approving:

  1. Apply the requested changes to the workflow document.
  2. Update the approval task:
TaskUpdate:
  title: "Approval: User Review #1"
  status: "completed"
  metadata:
    iteration: 1
    result: "changes_requested"
    feedback_summary: "Add password reset workflow, combine login variants"
  1. Create a new approval task for the next round:
TaskCreate:
  title: "Approval: User Review #2"
  status: "in_progress"
  metadata:
    iteration: 2
    changes_made: ["added password reset workflow", "combined login variants"]
    workflows_presented: 9
  1. Present the revised document to the user again.

Repeat until the user replies with "approved" or equivalent affirmation.

On Approval

TaskUpdate:
  title: "Approval: User Review #[N]"
  status: "completed"
  metadata:
    iteration: N
    result: "approved"
    final_workflow_count: 8

Phase 7: Write File and Complete

Validation is external. Do not self-validate. After this file is written, validation is performed by the validation subagent (agents/validation-subagent.md), which runs independently of the generator. The subagent invokes scripts/validate-workflows.sh for mechanical checks and presents judgment observations to the user.

Write the File

Write the approved workflow document to /workflows/desktop-workflows.md relative to the project root.

1. Ensure the /workflows/ directory exists (create it if not).
2. Write the complete document to /workflows/desktop-workflows.md.
3. Verify the file was written correctly by reading it back.

Update the Write Task

TaskCreate:
  title: "Write: desktop-workflows.md"
  status: "completed"
  metadata:
    file_path: "/workflows/desktop-workflows.md"
    file_size_lines: 487
    workflows_written: 8

Complete the Main Task

TaskUpdate:
  title: "Generate: Desktop Workflows"
  status: "completed"
  metadata:
    mode: "create"
    total_workflows: 8
    core: 3
    feature: 3
    edge: 2
    output_path: "/workflows/desktop-workflows.md"
    exploration_agents: 3
    walkthrough_journeys: 8
    total_steps: 42
    total_edge_cases: 15
    review_iterations: 1

Final Summary

Present the user with a completion summary:

Desktop workflow generation complete.

File: /workflows/desktop-workflows.md

Summary:
- Total workflows: 8
- Core workflows: 3
- Feature workflows: 3
- Edge case workflows: 2
- Exploration agents used: 3
- Walkthrough journeys completed: 8
- Total steps: 42
- Total edge cases: 15
- Review iterations: 1

Next steps:
- Run "convert workflows to playwright" to generate E2E test files
- Run "run playwright tests" to execute the generated tests

Phase 8: Session Reflection

Read references/reflection-protocol.md and execute it before finishing.


Session Recovery

If the skill is invoked and an existing task list is found, use this decision tree to determine where to resume.

Decision Tree

Check TaskList for "Generate: Desktop Workflows"

CASE 1: No task list exists
  -> Start from Phase 1

CASE 2: Explore tasks are "in_progress"
  -> Some agents may have timed out
  -> Check which Explore tasks completed
  -> Re-spawn only the incomplete agents
  -> Resume from Phase 2 (partial)

CASE 3: All Explore tasks are completed, journeys_confirmed is NOT set
  -> Resume from Phase 3 (journey discovery)

CASE 4: All Explore tasks are completed, journeys_confirmed is set, no Walkthrough task
  -> Resume from Phase 4 (app URL + auth setup)

CASE 5: Walkthrough task is "in_progress"
  -> Some journeys were completed, others remain
  -> Read completed_journeys and current_journey from task metadata
  -> Inform user which journeys are done and which is next
  -> Resume from Phase 5 at the next incomplete journey

CASE 6: Walkthrough task is "completed", no Approval task
  -> All journeys walked through but document not yet reviewed
  -> Resume from Phase 6 (final review)

CASE 7: Approval task exists with result "changes_requested"
  -> User gave feedback but revisions were not completed
  -> Read the feedback from task metadata
  -> Apply changes and re-present for review
  -> Resume from Phase 6 (next iteration)

CASE 8: Approval task is "completed" with result "approved", no Write task
  -> Document was approved but file was not written
  -> Resume from Phase 7 (write file)

CASE 9: Write task is "completed"
  -> Everything is done
  -> Show the final summary and ask if the user wants to make changes

Always Inform the User When Resuming

I found an existing session for desktop workflow generation.

Current state: [describe where things left off]
Last completed phase: [phase name]

I will resume from [next phase]. If you would like to start over instead,
let me know and I will create a fresh session.

Workflow Writing Standards

Use these exact verb forms and patterns when writing workflow steps. Consistency makes workflows easier to read, review, and automate.

ActionFormatExample
NavigationNavigate to [URL/page]Navigate to the dashboard page
ClickClick the "[label]" [element type]Click the "Save" button
TypeType "[text]" in the [field name] fieldType "john@email.com" in the email field
SelectSelect "[option]" from the [dropdown name] dropdownSelect "Admin" from the role dropdown
CheckCheck the "[label]" checkboxCheck the "Remember me" checkbox
UncheckUncheck the "[label]" checkboxUncheck the "Send notifications" checkbox
ToggleToggle the "[label]" switch [on/off]Toggle the "Dark mode" switch on
ClearClear the [field name] fieldClear the search field
ScrollScroll [direction] to [target/distance]Scroll down to the comments section
HoverHover over the "[label]" [element]Hover over the "Settings" menu item
WaitWait for [condition]Wait for the loading spinner to disappear
VerifyVerify [expected state]Verify the success toast appears with message "Saved"
UploadUpload "[filename]" to the [upload area]Upload "avatar.png" to the profile picture dropzone
DragDrag "[source]" to "[target]"Drag "Task A" to the "Done" column
PressPress [key/shortcut]Press Escape to close the modal
RefreshRefresh the pageRefresh the page and verify data persists

Test Data File Selection at Upload Steps

When writing an Upload step during the Phase 5 walkthrough, check whether the loaded profile has files configured. If it does:

  1. Present the available test files to the user:

    This profile has test data files available:
    
    1. valid-deck.pptx — Clean deck, passes all checks
    2. corrupted.pptx — Error case, should reject
    
    Which file should we use for this upload step? (number, "skip" to use a different file, or "none" to write the step without a specific file)
    
  2. If the user selects a file:

    • For path entries: use the path relative to the project root in the Upload step (e.g., Upload "test-fixtures/valid-deck.pptx" to the file dropzone)
    • For url entries: note the URL in a comment above the Upload step (e.g., <!-- test file: https://storage.example.com/large.pptx -->) and write the Upload step with the filename only
  3. After the upload step completes in the live walkthrough, if acceptance criteria exist (profile-level merged with any file-level overrides via shallow merge), add Verify steps for each applicable criterion:

    CriterionGenerated Verify Step
    uploadAccepted: trueVerify no error message or validation error is displayed
    uploadAccepted: falseVerify an error message or validation error is displayed
    processingCompletes: trueVerify the processing indicator resolves to a terminal state
    resultDownloadable: trueVerify a download button or link is available
    errorExpected: trueVerify an error message is displayed and the app remains functional
    expectedStatus: "X"Verify the status shows "X"

    These Verify steps are added to the workflow output as part of the normal walkthrough. Confirm each with the user via snapshot inspection before recording.

  4. If the user selects "skip" or "none", write the Upload step as normal without test data integration.


Automation-Friendly Guidelines

Workflows are designed to be converted into Playwright E2E tests. Follow these guidelines to make conversion straightforward.

Locator Descriptions

When describing elements in workflow steps, prefer descriptions that map cleanly to Playwright's recommended locator strategies:

Locator StrategyWorkflow DescriptionPlaywright Equivalent
By role + nameClick the "Submit" buttonpage.getByRole('button', { name: 'Submit' })
By labelType "john@email.com" in the email fieldpage.getByLabel('Email')
By textClick the "Learn more" linkpage.getByText('Learn more')
By placeholderType "Search..." in the search boxpage.getByPlaceholder('Search...')
By test IDClick the delete button (data-testid="delete-btn")page.getByTestId('delete-btn')
By titleHover over the info icon (title="More information")page.getByTitle('More information')

Preferred Locator Order

When writing steps, prefer locator descriptions in this order (matching Playwright's recommendation):

  1. Role-based (buttons, links, headings, etc.)
  2. Label-based (form fields)
  3. Text-based (visible text content)
  4. Placeholder-based (input placeholders)
  5. Test ID-based (data-testid attributes)
  6. CSS/XPath-based (last resort, avoid when possible)

Non-Automatable Steps

Some steps cannot be automated with Playwright. Mark these with [MANUAL]:

4. [MANUAL] Verify the email arrives in the user's inbox
   - Check for subject line "Welcome to [App Name]"

7. [MANUAL] Complete the CAPTCHA challenge
   - Workflow continues after CAPTCHA is solved

Known Limitations

LimitationDescriptionWorkaround
Native file dialogsPlaywright cannot interact with OS-level file pickersUse page.setInputFiles() instead of clicking file inputs
Native print dialogsCannot automate browser print previewSkip or mock print functionality
Browser extensionsPlaywright does not support browser extensionsTest extension-dependent features manually
Multi-tab OAuthOAuth popups in new tabs require special handlingUse context.waitForEvent('page') pattern
Clipboard accessClipboard API requires permissionsGrant permissions in browser context setup
Download verificationCannot directly verify file contents after downloadUse download event listeners and file system checks
HTTP basic authBrowser-native auth dialogs are not automatable via pageUse httpCredentials in browser context
Geolocation promptsPermission prompts block automationSet geolocation in context options before navigation

Prerequisites for Automation

When a workflow requires specific setup, document it in the Preconditions block:

**Preconditions:**
- User is logged in as admin (`admin@example.com` / `password123`)
- At least 3 posts exist in the database
- The feature flag "new-editor" is enabled

This information is critical for the converter skill to generate proper beforeEach and beforeAll blocks.


Web Platform UX Anti-Patterns

When generating workflows, watch for these common UX anti-patterns. If you detect any during exploration, flag them in the workflow document and write specific test steps to verify the application handles them correctly.

Navigation Anti-Patterns

Anti-PatternWhy It MattersVerification Step
Gesture-only navigationDesktop users have no swipe gesturesVerify all navigation is accessible via click or keyboard
Breaking the back buttonUsers expect browser back to workNavigate forward, click back, verify previous page loads
No URL for stateful viewsUsers cannot bookmark or share specific statesVerify that filters, tabs, and modals have URL representations
Hash-only routingBreaks SSR and some crawlersCheck that routes use proper path segments
Redirect loopsLogin -> redirect -> login cyclesAttempt to access protected routes, verify single redirect

Interaction Anti-Patterns

Anti-PatternWhy It MattersVerification Step
Missing hover statesDesktop users expect visual hover feedbackHover over interactive elements, verify cursor and style change
No focus indicatorsKeyboard users cannot see where they areTab through the page, verify visible focus ring on each element
Click targets too smallPrecision issues on large screens with trackpadsVerify buttons and links have adequate click area (min 24x24px)
Pull-to-refresh patternsDesktop browsers do not support pull gesturesVerify refresh functionality is available via button or keyboard
Double-click requiredUnexpected interaction pattern for webVerify all actions respond to single click
Context menu overridingUsers expect native right-click behaviorRight-click on page, verify native context menu appears

Visual Anti-Patterns

Anti-PatternWhy It MattersVerification Step
Full-screen modals on desktopWastes screen space on large viewportsVerify modals are appropriately sized for desktop viewports
No responsive breakpointsContent may overflow or underflowTest at common breakpoints: 1024px, 1280px, 1440px, 1920px
Fixed mobile-width layoutsDesktop users expect fluid or max-width layoutsVerify layout adapts to viewport width
Tiny text on large screensReadability issues at desktop viewing distancesVerify body text is at least 16px
Horizontal scroll on contentUnexpected on desktop (except tables/code)Verify no horizontal scrollbar appears at 1280px+

Component Anti-Patterns

Anti-PatternWhy It MattersVerification Step
Native mobile pickersDate/time pickers designed for touch, not mouseVerify date/time inputs use desktop-friendly pickers
Action sheets instead of dropdownsMobile pattern that looks wrong on desktopVerify selection components use standard dropdown/select
iOS-style toggle switchesMay confuse desktop users expecting checkboxesVerify toggle behavior matches desktop conventions
Bottom sheetsMobile pattern that wastes desktop spaceVerify panels and drawers use side placement on wide viewports
Floating action buttons (FABs)Mobile Material Design pattern, unusual on desktopVerify primary actions are in standard toolbar/header positions

Accessibility Anti-Patterns

Anti-PatternWhy It MattersVerification Step
No keyboard navigationMany desktop users rely on keyboardTab through all interactive elements, verify logical order
Missing ARIA labelsScreen readers cannot identify elementsCheck interactive elements for aria-label or aria-labelledby
Color-only status indicatorsColorblind users cannot distinguish statesVerify status uses text/icons in addition to color
Auto-playing mediaUnexpected and disruptive for desktop usersVerify no media plays without user interaction
Focus traps in modalsTab key should cycle within open modalsOpen modal, tab through all elements, verify focus stays inside
Missing skip navigationKeyboard users must tab through entire navVerify "Skip to main content" link exists and works

UX Verification Steps Template

When anti-patterns are detected during exploration, add a dedicated UX verification workflow:

## Workflow [N]: UX Pattern Compliance
<!-- auth: no -->
<!-- priority: feature -->

> Verifies the application follows desktop web platform conventions and avoids
> common UX anti-patterns that harm usability.

**Steps:**

1. Navigate to the home page
   - Verify no horizontal scroll at 1280px viewport width

2. Tab through all interactive elements on the page
   - Verify each element has a visible focus indicator
   - Verify tab order follows logical reading order

3. Hover over all buttons and links
   - Verify cursor changes to pointer
   - Verify hover state is visually distinct from default state

4. Click the browser back button after navigating to a sub-page
   - Verify the previous page loads correctly
   - Verify no redirect loops occur

5. [Continue based on specific anti-patterns found...]

Handling Updates

When the user selects "Update" mode (modifying existing workflows), follow these rules to minimize disruption while ensuring coverage stays current.

Rules for Updating Existing Workflows

  1. Preserve working workflows -- If an existing workflow is still valid (routes exist, components match, steps are correct), keep it unchanged. Do not rewrite working workflows for style consistency.

  2. Mark deprecated workflows -- If a workflow references routes or components that no longer exist, do not delete it. Instead, add a deprecation marker:

## Workflow 7: Legacy Export Feature
<!-- auth: required -->
<!-- priority: feature -->
<!-- deprecated: true -->
<!-- deprecated-reason: Export feature removed in v2.3 -->
<!-- deprecated-date: 2025-01-15 -->

> **DEPRECATED** -- This workflow references the legacy export feature which
> has been removed. Keeping for reference until confirmed safe to delete.
  1. Add new workflows -- New workflows are appended to the appropriate section (Core, Feature, or Edge Case). Number them sequentially after the last existing workflow.

  2. Version notes -- Add a version history section at the top of the file:

## Version History

| Date | Action | Details |
|------|--------|---------|
| 2025-01-20 | Updated | Added workflows 26-28 for new dashboard features |
| 2025-01-15 | Updated | Deprecated workflow 7 (export feature removed) |
| 2025-01-01 | Created | Initial generation: 25 workflows |
  1. Re-validate existing workflows -- During exploration, cross-reference existing workflow steps against the current codebase. Flag any steps that reference elements or routes that have changed:
3. Click the "Export CSV" button
   - **[CHANGED]** Button label is now "Download CSV" (updated in v2.2)
   - Verify download begins within 3 seconds
  1. Preserve workflow numbers -- Never renumber existing workflows. If workflow 7 is deprecated and workflow 28 is added, the gap stays. This ensures external references to "Workflow 7" remain valid.

Update Summary

After an update operation, present a change summary:

Desktop workflow update complete.

Changes:
- Workflows preserved (unchanged): 20
- Workflows updated (steps modified): 3
- Workflows deprecated: 1
- Workflows added (new): 3
- Total workflows: 27 (1 deprecated)

Changed workflows:
- Workflow 4: Updated step 3 (button label changed)
- Workflow 12: Updated step 1 (route changed from /settings to /preferences)
- Workflow 19: Updated steps 5-7 (new confirmation dialog added)

Deprecated workflows:
- Workflow 7: Legacy Export Feature (export removed in v2.3)

New workflows:
- Workflow 26: Dashboard Widget Customization
- Workflow 27: Real-Time Notification Center
- Workflow 28: Bulk Action on List View

FAQ

What does the desktop-workflow-generator skill do?

Generates desktop browser workflow documentation by exploring the app's codebase, then walking through the live app with the user step-by-step via Playwright to co-author verifications. Use when the user says "generate desktop workflows", "create desktop workflows", "update desktop workflows", or "generate browser workflows".

How do I install desktop-workflow-generator?

Run npx skills add https://github.com/neonwatty/qa-skills --skill desktop-workflow-generator in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/desktop-workflow-generator/ (personal) or .claude/skills/desktop-workflow-generator/ (project).

Which AI agents can use desktop-workflow-generator?

Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.

Is desktop-workflow-generator safe to install?

No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.

Who maintains desktop-workflow-generator?

It is published by neonwatty in neonwatty/qa-skills. It has 51 recorded installs.

More from neonwatty/qa-skills

View all →

playwright-runner

neonwatty/qa-skills

Executes workflow markdown files interactively via Playwright CLI, stepping through each workflow action in a real browser. Use when the user says "run workflows", "run playwright", "test workflows", "execute workflows", or wants to interactively test their app against workflow documentation. Supports desktop, mobile, and multi-user workflows with authentication.

Testing & QA56 installs

adversarial-audit

neonwatty/qa-skills

Audits SaaS and usage-based web apps for adversarial usage patterns — accidental, opportunistic, and deliberate. Use this when the user says "adversarial audit", "abuse case audit", "idiot-proof this app", "find usage exploits", "business logic audit", or "how could users break this". Explores the codebase to map the economic surface area (pricing tiers, usage limits, free trials, costly resources), then generates abuse cases where user behavior — intentional or not — could break assumptions, bypass limits, amplify costs, or corrupt state. Produces a prioritized markdown report with findings, code locations, and fix recommendations, then optionally verifies findings interactively in a browser.

Security55 installs

resilience-audit

neonwatty/qa-skills

Audits web apps for resilience against unexpected user behavior — accidental, edge-case, and chaotic. Use this when the user says "resilience audit", "chaos audit", "what could go wrong", "edge case audit", "idiot-proof this", "break this app", "stress test the UX", or "find UX dead ends". Explores the codebase to map user flows, then systematically identifies ways the app can break, get stuck, or behave unexpectedly when users do things the developer didn't anticipate. Covers navigation dead ends, double-submits, interrupted operations, cross-device issues, input edge cases, timing bugs, error recovery gaps, and unintended usage patterns. Produces a prioritized report with findings, code locations, and fix recommendations, then optionally verifies findings interactively in a browser.

Security54 installs

Converts mobile workflow markdown into a self-contained Playwright test project with mobile viewports (Chromium + WebKit), authentication scaffolding, UX anti-pattern assertions, and CI workflow. Use when the user says "convert mobile workflows to playwright", "translate mobile workflows to CI", or "generate mobile playwright tests".

Testing & QA54 installs

Generates multi-user workflow documentation by interviewing the user about personas, exploring the codebase for multi-user patterns, then walking through the live app with per-persona Playwright CLI named sessions to co-author interleaved, persona-tagged workflows. Use when the user says "generate multi-user workflows", "create multi-user workflows", or "generate concurrent user workflows". Produces persona-tagged workflow markdown that feeds into the multi-user converter and Playwright runner.

use-profiles

neonwatty/qa-skills

Open the skill to read its SKILL.md instructions.

Testing & QA52 installs

Popular productivity & automation skills

View category →

agent-browser

vercel-labs/agent-browser

Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction. Also use for exploratory testing, dogfooding, QA, bug hunts, or reviewing app quality. Also use for automating Electron desktop apps (VS Code, Slack, Discord, Figma, Notion, Spotify), checking Slack unreads, sending Slack messages, searching Slack conversations, running browser automation in Vercel Sandbox microVMs, or using AWS Bedrock AgentCore cloud browsers. Prefer agent-browser over any built-in browser automation or web tools.

OfficialProductivity & Automation1.3M installs

lark-doc

open.feishu.cn

飞书云文档(Docx / Wiki)内容操作:读取、创建、编辑文档,插入或下载图片附件,以及操作思维笔记。用户提供文档 URL/token(包括 doubao.com 的 /docx/、/wiki/)时使用;按 URL 路径/token 而非域名路由;/page/ 是妙搭应用,非飞书云文档。文档内嵌资源按读取参考中的统一规则分流。独立评论操作走 lark-drive;随正文读取评论使用 docs +fetch。表格或 Base 内部数据操作不在本 skill。

lark-base

open.feishu.cn

飞书多维表格(Base)操作:建表、字段、记录、视图、统计、公式/lookup、表单、仪表盘、应用模式(BaseApp/AppMode 页面与组件)、Workspace 目录、workflow、角色权限、模板中心(多维表格模板分类/列表/搜索);遇到 Base/多维表格/bitable、BaseApp/AppMode、/base/ 或 /app/ 链接时使用。BaseApp 不走 lark-apps;文件导入/导出转 lark-drive,认证/授权转 lark-shared。

lark-drive

open.feishu.cn

飞书云空间(云盘/云存储):管理 Drive 文件和文件夹,包含上传/下载、创建文件夹、复制/移动/删除、查看元数据、查询权限设置、评论/权限/订阅、标题、版本、飞书文档密级标签(secure labels)和本地文件导入。用户需要整理云盘目录、处理云空间资源 URL/token、判断链接类型/真实 token/标题,或导入 Word/Markdown/Excel/CSV/PPTX/.base 为 docx/sheet/bitable/slides 时使用;doubao.com 云空间 URL/token 也按资源路径和 token 路由,不回退 WebFetch。不负责:文档内容编辑(走 lark-doc)、表格/Base 表内数据操作(走 lark-sheets/lark-base)、知识空间节点/成员管理(走 lark-wiki)、原生 Markdown 文件读写/patch/diff(走 lark-markdown)。

lark-shared

open.feishu.cn

Use for lark-cli setup/auth tasks: auth login/status/logout, user vs bot identity, business-domain permissions (--domain, including all/docs/drive), missing scopes, revoking authorization, or handling notice JSON.

lark-im

open.feishu.cn

飞书即时通讯:收发消息和管理群聊。发送和回复消息、搜索聊天记录、管理群聊成员、上传下载图片和文件、管理表情回复、发送应用内/短信/电话加急、发送和处理交互卡片(Interactive Card)、监听卡片按钮回调(card.action.trigger)。当用户需要发消息、查看或搜索聊天记录、下载聊天中的文件、查看群成员、搜索群、创建群聊或话题群、管理标记数据、管理 Feed 置顶(添加/移除/查询置顶会话)、管理标签数据、处理卡片回调时使用。