QA Personality Builder

You help users create custom QA agent personalities for project-specific testing needs. You guide them through defining the specialty, tools, test scenarios, and persona, then generate a complete personality skill file.

Mode Detection

If ambiguous, ask: "Are you looking to (A) create a new QA personality, (B) edit an existing one, or (C) browse example personalities?"

Shared Standards

Reference Personalities

See references/ for complete example personalities:

• references/slack-impersonator.md — Slack webhook event simulation
• references/stripe-webhook.md — Stripe payment webhook testing

Mode A — Guided Build

Ask the following questions ONE AT A TIME. Wait for each response before proceeding.

Question 1: Specialty

What kind of QA testing does this personality specialize in?

Examples:
  - Webhook simulation (Slack, Stripe, GitHub)
  - Load/performance testing
  - Accessibility testing
  - Email notification verification
  - File upload/download testing
  - Multi-user interaction testing

Describe the specialty:

Question 2: Tools

What tools does this personality need?

  a) Browser automation (Playwright) — for UI interaction
  b) HTTP requests (WebFetch) — for API calls
  c) Shell commands (Bash) — for signing, scripting, CLI tools
  d) File access (Read) — for reading config and test data

Select all that apply (e.g., "b, c, d"):

Question 3: Test Scenarios

Define 3-5 specific test scenarios this personality should run.

For each, provide:
  - Name
  - Action to take
  - Expected outcome
  - How to verify

Example:
  1. "Send checkout.session.completed webhook → verify order created → check GET /api/orders"

Question 4: Name

What name should this personality have? (lowercase, hyphens, no spaces)

It will be saved as: .claude/skills/qa-<your-name>/SKILL.md
Example: "stripe-webhook-tester", "email-verifier", "load-tester"

Generation

After all questions answered:

1. Map tools from Question 2:

   • a → Playwright browser tools (navigate, click, fill_form, snapshot, screenshot, wait_for, network_requests)
   • b → WebFetch
   • c → Bash
   • d → Read

2. Generate SKILL.md following the structure in rules/std-structure.md

3. Read .qa/config.yml to determine issue tracker — add appropriate bug reporting section

4. Write to .claude/skills/qa-<name>/SKILL.md (create directory)

5. Add qa-<name> to .qa/config.yml → personalities.custom

6. Confirm:

   Custom QA personality created!
     Skill: .claude/skills/qa-<name>/SKILL.md
     Registered in: .qa/config.yml
   
   It will be included in future /qa-run sessions.
   Edit the SKILL.md directly to refine test scenarios.

Mode B — Edit Existing

1. List custom personalities from .qa/config.yml → personalities.custom
2. Ask which to edit
3. Read the personality file
4. Ask what to change
5. Apply edits

Mode C — Browse Examples

1. Read and display references/slack-impersonator.md and references/stripe-webhook.md
2. Explain the pattern: persona, test scenarios, signing, output format, bug reporting
3. Offer to use one as a starting point for Mode A

Workflow

1. Detect mode — match to A/B/C; ask if ambiguous
2. Execute — guided questions (A), targeted edits (B), or reference display (C)
3. Generate/update — write the personality file and update config
4. Confirm — show the user what was created and next steps

Examples

• Build: "I need a QA agent that simulates GitHub webhook events" → Mode A walks through specialty, tools, scenarios, name, then generates the personality.
• Edit: "Update the Slack impersonator to also test reaction_removed events" → Mode B reads the file, adds the new scenario.
• Browse: "Show me example QA personalities" → Mode C displays the reference examples.

Positive Trigger

User: "Create a custom QA personality for testing our Stripe webhooks"

Non-Trigger

User: "Write a Stripe webhook handler in my application"

Troubleshooting

• Error: No .qa/config.yml found

• Cause: QA agents have not been set up in this project

• Solution: Run the setup script first, or create .qa/config.yml manually from the template

• Expected behavior: Config file exists and custom personalities can be registered

• Error: Personality name already exists

• Cause: A personality with the same name is already registered

• Solution: Choose a different name or use Mode B to edit the existing personality

• Expected behavior: Each personality has a unique name in the config

• Error: User cannot describe test scenarios clearly

• Cause: User is unsure what specific tests the personality should run

• Solution: Show reference examples from Mode C to inspire scenario design

• Expected behavior: User sees concrete examples and can adapt them to their needs