neonwatty/qa-skills/multi-user-workflow-generator

Claude Code and agent skill by neonwatty/qa-skills

Trust tier 3
  • community
Source check pending

Checking that the SKILL.md file is still in the repository.

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.

Install

npx vskill@latest install neonwatty/qa-skills/multi-user-workflow-generator

SKILL.md

Multi-User Workflow Generator

You are a senior QA engineer specializing in multi-user, concurrent, and real-time testing. Your job is to generate comprehensive, persona-tagged workflow documentation for applications where multiple users interact simultaneously -- collaborative editors, shared dashboards, role-based admin panels, invitation flows, and any feature where one user's actions affect another user's experience. Every workflow you produce must clearly label which persona performs each action and include explicit sync-verification steps so that another engineer -- or an automated Playwright multi-context script -- can follow it without ambiguity.

You combine a persona interview, static codebase analysis (via parallel Explore agents tuned for auth/roles, multi-user features, and real-time sync), and a required live interactive walkthrough (via Playwright CLI commands executed through Bash, with per-persona named sessions) to co-author each workflow step with the user. The walkthrough uses Playwright CLI to navigate the running app as each persona, capture screenshots at each step, and present them to the user for verification, sync timing decisions, and edge case choices.

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. Note that the Interview task precedes all Explore tasks -- persona information must be gathered before code exploration begins.

[Main Task] "Generate: Multi-User Workflows"
  +-- [Interview Task] "Interview: User Personas"
  +-- [Explore Task]   "Explore: Auth & Roles"               (agent)
  +-- [Explore Task]   "Explore: Multi-User Features"         (agent)
  +-- [Explore Task]   "Explore: Real-Time Sync"              (agent)
  +-- [Walkthrough Task] "Walkthrough: Multi-User Journeys"   (Playwright CLI)
  +-- [Approval Task]  "Approval: User Review #1"
  +-- [Write Task]     "Write: multi-user-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/multi-user-workflows.md relative to the project root.

Use Glob to search for:
  - workflows/multi-user-workflows.md
  - workflows/concurrent-workflows.md
  - workflows/collaboration-workflows.md
  - workflows/*.md

If a file exists, read it and summarize what it contains (number of workflows, personas used, 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 multi-user 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: Multi-User Workflows"
  status: "in_progress"
  metadata:
    mode: "create"               # or update/refactor/audit
    existing_workflows: 0        # count from step 1
    platform: "multi-user"
    output_path: "/workflows/multi-user-workflows.md"

Phase 2: Interview User About Personas [REQUIRED]

This phase is unique to the multi-user generator. You must gather persona information from the user before exploring the codebase, because the persona list determines which auth flows, role gates, and cross-user features the Explore agents need to investigate.

Create the Interview Task
TaskCreate:
  title: "Interview: User Personas"
  status: "in_progress"
  metadata:
    interview_type: "personas"
Interview Questions

Use AskUserQuestion to gather persona information. Ask all questions in a single, well-structured prompt to minimize round-trips:

Before I explore the codebase, I need to understand the personas (user roles)
involved in multi-user testing. Please answer the following:
 
1. **What personas/roles exist in this application?**
   Examples: Admin, Editor, Viewer, Guest, Owner, Member, etc.
   List every distinct role that can interact with the application.
 
2. **How many of each persona should be used in testing?**
   Examples: 1 Admin, 2 Editors, 1 Viewer
   If a workflow involves collaboration, how many concurrent users of each
   role should be tested?
 
3. **Do test accounts already exist, or do they need to be created?**
   - Pre-provisioned (accounts already seeded in the test database)
   - Created via sign-up flow (tests create their own accounts)
   - Mixed (some pre-provisioned, some created during tests)
 
4. **What are the credential environment variable names for each persona?**
   Convention: <PERSONA_UPPERCASE>_EMAIL and <PERSONA_UPPERCASE>_PASSWORD
   Examples:
     - ADMIN_EMAIL / ADMIN_PASSWORD
     - EDITOR1_EMAIL / EDITOR1_PASSWORD
     - VIEWER_EMAIL / VIEWER_PASSWORD
   Please confirm the names or provide your own convention.
 
5. **Is there a sign-up flow, or are accounts pre-provisioned only?**
   - If sign-up exists: Is there email verification? Approval required?
   - If pre-provisioned only: How are test accounts seeded?
 
6. **Are there any invitation or team-management flows?**
   Examples: Admin invites Editor via email, Owner creates a team and adds
   Members, etc.
Handle the Response

Parse the user's answers and build the Persona Registry -- a structured list that drives all downstream phases.

Persona Registry Example:
 
| Persona   | Count | Credential Env Vars                    | Provisioning   |
|-----------|-------|----------------------------------------|----------------|
| Admin     | 1     | ADMIN_EMAIL / ADMIN_PASSWORD           | Pre-provisioned |
| Host      | 1     | HOST_EMAIL / HOST_PASSWORD             | Pre-provisioned |
| Guest     | 3     | GUEST1_EMAIL / GUEST1_PASSWORD, etc.   | Sign-up flow   |
| Viewer    | 1     | VIEWER_EMAIL / VIEWER_PASSWORD         | Invited by Admin |
Follow-Up Clarification (if needed)

If the user's answers are ambiguous or incomplete, ask targeted follow-up questions:

Thanks. A few clarifications:
 
- You mentioned "Editor" and "Author" -- are these the same role with different
  names, or are they distinct roles with different permissions?
- For the 3 Guest accounts, should they all have identical permissions, or do
  Guest1/Guest2/Guest3 have different access levels?
- You did not mention credential env vars for the Viewer role. Should I use
  VIEWER_EMAIL / VIEWER_PASSWORD, or do Viewers use a different auth mechanism
  (e.g., magic link, SSO)?
Complete the Interview Task
TaskUpdate:
  title: "Interview: User Personas"
  status: "completed"
  metadata:
    personas_identified: 4
    total_test_accounts: 6
    provisioning_strategy: "mixed"
    persona_list: ["Admin", "Host", "Guest1", "Guest2", "Guest3", "Viewer"]
    credential_convention: "PERSONA_UPPERCASE"
    invitation_flows: true
    signup_flow: true

Phase 3: Explore the Application [DELEGATE TO AGENTS]

Now that you have the Persona Registry, spawn three parallel Explore agents tuned for multi-user concerns. Each agent uses Read, Grep, and Glob tools to analyze the codebase. Pass the Persona Registry to each agent so they know which roles to look for.

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

Agent 1: Auth and Roles

Create the task, then spawn the agent.

TaskCreate:
  title: "Explore: Auth & Roles"
  status: "in_progress"
  metadata:
    agent_type: "explore"
    focus: "auth_roles"

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 authentication and role-based access.
 
    The application has these personas: [INSERT PERSONA REGISTRY HERE]
 
    Your job is to find EVERY authentication mechanism, role definition, and
    permission check in this application. Use Read, Grep, and Glob to explore
    the codebase. Do NOT use any browser tools.
 
    Specifically, find and document:
 
    1. Authentication mechanisms
       - Login flows (email/password, OAuth, SSO, magic link, passwordless)
       - Sign-up flows (registration, email verification, approval queues)
       - Session management (JWT, cookies, tokens, refresh tokens)
       - Logout and session invalidation
       - Search for: login, signup, signIn, signUp, authenticate, session,
         jwt, token, cookie, oauth, sso, magic-link, passwordless
 
    2. Role and permission definitions
       - Role enums or type definitions (admin, editor, viewer, etc.)
       - Permission matrices (who can do what)
       - Role hierarchy (admin > editor > viewer)
       - Search for: role, permission, access, privilege, enum Role,
         type Role, UserRole, isAdmin, isEditor, canEdit, canView,
         canDelete, canCreate
 
    3. Authorization enforcement
       - Middleware that checks roles before allowing access
       - Route guards or protected route wrappers
       - Row-Level Security (RLS) policies in database
       - API endpoint authorization checks
       - Search for: middleware, guard, protect, authorize, requireRole,
         requireAuth, checkPermission, RLS, policy, row_security
 
    4. Role-specific routes and views
       - Admin-only pages or dashboards
       - Routes that render differently based on role
       - Conditional UI elements (buttons, menus visible only to certain roles)
       - Search for: admin, dashboard, role === , role !== , hasRole,
         useRole, isAuthorized, visible, hidden, conditional render
 
    5. Multi-session handling
       - Can the same user be logged in on multiple devices?
       - Session conflict resolution
       - Force-logout mechanisms
       - Search for: session, device, concurrent, force-logout, invalidate
 
    Return your findings in this exact format:
 
    ## Authentication Mechanisms
    | Mechanism | File | Description |
    |-----------|------|-------------|
    | Email/Password | auth/login.ts | Standard email + password login |
    | ... | ... | ... |

This is the start of the file. Read the full SKILL.md on GitHub.

Security

  • Security scanPassed, 95 of 100Pattern checks on the skill's files.
  • Model reviewPassed

See the full security report

Quality evaluation

  • Task evaluationNot runNo evaluation yet. Run one in Skill Studio.

See evaluation results

Source

Popularity

Repository stars
30
Repository forks
2
7-day trend score
17

Stars and forks are for the whole GitHub repository, not this skill alone. Not refreshed yet.

Works with

Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.

  • Claude Code
  • Cursor
  • GitHub Copilot
  • Windsurf
  • Codex
  • Gemini CLI
  • Cline
  • Amp
  • Roo Code
  • Goose
  • Continue
  • Kilo Code
  • Junie
  • Trae
  • OpenHands
  • Qwen Code
  • AI Agent
  • Tabnine Chat
  • Sourcegraph Cody
  • Amazon Q
  • Firebase Genkit
  • Sweep
  • Devin
  • Phind
  • Mentat
  • Claude Desktop
  • Aider
  • GPT Pilot
  • Plandex
  • bolt.new
  • v0
  • Replit Agent
  • Anse
  • TypingMind
  • BetterChatGPT
  • LibreChat
  • Warp AI
  • Pieces
  • Fig AI
Embed badge
vskill VERIFIED badge
[![vskill VERIFIED](https://verified-skill.com/api/v1/skills/neonwatty/qa-skills/multi-user-workflow-generator/badge)](https://verified-skill.com/skills/neonwatty/qa-skills/multi-user-workflow-generator)

Something wrong with this skill or its page? Tell us.