Skip to content
AI & Agents
Skill

/qa-execution

Run requested dogfooding through public product interfaces. Use existing QA journeys or qa-report to plan them; excludes routine code edits and CI-only verification.

BOOST
From plugin
pedronauck-skills
63787 skills1 command
Install
$ npx -y skills add pedronauck/skills --skill qa-execution --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/qa-execution

Context preview

The summary Claude sees to decide when to auto-load this skill.

Run requested dogfooding through public product interfaces. Use existing QA journeys or qa-report to plan them; excludes routine code edits and CI-only verification.

SKILL.md

qa-execution.SKILL.md
name: qa-execution
description: "Run requested dogfooding through public product interfaces. Use existing QA journeys or qa-report to plan them; excludes routine code edits and CI-only verification."
disable-model-invocation: true
argument-hint: "[qa-docs-path]"
metadata:
  author: Pedro Nauck
  github: https://github.com/pedronauck
  repository: https://github.com/pedronauck/skills

Real-User QA Execution

QA the product the way a real person meets it: a **persona** walks a journey through the product's public interfaces, feels the friction, hits the edges, and reports what happened. This is **dogfooding**, not a scripted test pass — the session is the work, and the living QA docs tree remembers it.

Three non-negotiables hold every session:

1. **In persona.** Every interaction and every verification goes through a surface a real user can reach — no dev-tools shortcut, no code-reading to decide what should happen, no patching over a stall. 2. **Proof, not optimism.** A `Pass` is the expected observable seen, confirmed through an independent read path, surviving a refresh, with evidence captured. Optimistic UI is not confirmation. 3. **Write back or it didn't happen.** Every session updates the tree — scenario-file verdicts, bug registry, and the dated report carrying the session debrief.

Input

  • **qa-docs-path** (optional): root of the living QA docs tree; defaults to `docs/qa/`. The tree is this skill's memory and its only output location — never a temp dir. If it doesn't exist, run `qa-report` first; it owns the tree and its bootstrap.

Steps

Choose the planned smoke/targeted/full scope. Read only the relevant procedure/schema sections and reuse current evidence for unchanged behavior. A small changed journey does not require all tours, edge categories, or a second full walk.

**Step 1 — Resolve the tree, scope, and preconditions**

  • Read, in order: `<qa-docs-path>/README.md` (entry points, dev-server command, area codes), the in-scope `scenarios/` files, related open `bugs/`, and this cycle's charters. The tree is the memory; running without reading it recreates the duplication this design kills.
  • Scope: a **branch/PR run** covers the journeys its user-visible diff touches plus an adjacent canary when shared behavior could regress — no user-visible change, report that and stop. A **release/full run** covers the journeys the cycle plan marked in scope.
  • Preconditions: the applicable preconditions and existing required checks are satisfied (reuse current evidence; unrelated suites need not finish before a focused probe) and the product is reachable in a production-parity build (real dev server, real auth, no mocks). Not reachable → name the exact gap and stop.
  • **Done when:** scope is fixed and every precondition is met or its gap is surfaced.

**Step 2 — Build the matrix and create the report now**

  • Read `references/status-and-reporting.md` — it owns the six-value status enum and the report lifecycle.
  • Assemble the session matrix from the planned charters: persona × journey × tour × time-box, ordered by risk. A charter missing for an in-scope journey is drafted per `../qa-report/references/session-charters.md` before running — never walk unplanned.
  • Create `<qa-docs-path>/reports/<YYYY-MM-DD>-<scope>.md` from the report template (project copy at `<qa-docs-path>/templates/report.md`, else `assets/report-template.md`) **before the first session**, with every matrix row `Pending`. This on-disk report is the source of truth for resume — update it after every session and every fix, never only at the end.
  • **Done when:** the report exists on disk carrying the full matrix, every row `Pending`.

**Step 3 — Walk each journey in persona**

  • Read `references/session-protocol.md` (the enter→act→verify→capture loop and the evidence standard) and `references/persona-fidelity.md` (the public-interface guardrails and stall-is-a-finding).
  • For each charter, in matrix order: adopt the persona (device, network, locale), enter through its real entry point, and walk the journey verb by verb to its **true end state** — verifying each step against the evidence standard.
  • Hunt **paper cuts** throughout: persona-felt friction no functional check fails; sharp ones become findings.
  • A leg only a human can complete (real payment, external email/SMS, real OAuth) is marked `Blocked (needs human verify)` with exact instructions — never faked.
  • **Done when:** every charter is walked to a recorded verdict, evidence captured at checkpoints and divergences, the debrief written to the report's Session Debriefs section, and the matrix row updated.

**Step 4 — Run each tour and edge probe**

  • Read `references/tours.md` (the 10-tour catalog and surface-to-tour matrix) and `references/edge-cases.md` (the non-technical user edge cases).
  • Run each charter's single **tour** against its surface, in persona, inside the box, asking at each action: *"would this matter for this tour's theme?"*
  • Choose distinct edge cases supported by the changed contract and risk; there is no minimum count. Attempted-and-clean is evidence too.
  • **Done when:** every charter's tour is run and its chosen edge cases are attempted and recorded.

**Step 5 — Experiential lens pass**

  • Read `references/lenses.md` — the six lenses and their severity defaults.
  • For a requested usability/full review or an unresolved experience risk, apply the relevant lenses to the affected journey. Reuse observations from the first walk and re-walk only the missing evidence.
  • **Done when:** the applicable experience risks have evidence, or this optional pass is not needed for the targeted scope.

**Step 6 — File findings into the registry**

  • Read `../qa-report/references/bug-registry.md` — it owns ids, dedup, and the impact rubric.
  • Dedup first: search `bugs/` and the affected scenarios' `bug_ids`. Re-found → append `## Re-found`; regressed → reopen with `## Regressed`; only a genuinely new symptom mints a new `BUG-<YYYYMMDD>-<slug>` id.
Read more
Ships withpedronauck-skills

A curated collection of 87 agent skills for Claude Code and compatible AI coding assistants — 40 original (⭐️), 34 hand-picked (💎), and 13 marketing & business (📣).

Get the whole plugin
Stats
637
Stars
89
Forks
Maintained
Maintenance
Python
Language
1mo ago
Last commit
7mo ago
Created
4h ago
Added

Repo: pedronauck/skills

Other skills on pedronauck-skills.