exploratory-charter-author
Authoring workflow that turns a feature spec, risk area, or bug cluster into a session-based exploratory testing charter per Jonathan and James Bach's SBTM - frames the one-sentence mission, scopes 3-7 areas, picks a 60 / 90 / 120 min time-box, suggests tours, and wires the PROOF debrief deliverables. Per Bach, exploratory testing is "performing tests while learning things that may influence the testing" - the charter sets the mission while leaving exact steps to the tester's judgment. Use when a feature has too many unknowns to script (new feature / refactor blast-radius / bug cluster) and a session-based exploration is the right approach. Authors the charter only: the ready-to-fill charter card, session vocabulary, debrief template, and session review live in the exploratory-testing skill this workflow composes with.
Install with skills.sh (any agent)
npx skills add testland/qa --skill exploratory-charter-authorexploratory-charter-author
Overview
A charter is the structured-but-open frame of an SBTM session: it tells the tester what to learn, not what to click. This skill is the authoring workflow - from a raw input (spec, diff, incident) to a filled charter card. The card format itself, the session vocabulary, and the time-box rationale are owned by exploratory-testing; the ready-to-fill card is its references/charter-template.md (opens in new window). This workflow fills that template - it does not redefine it.
Input: a feature spec / story, a diff / changeset, a bug cluster / incident postmortem, or a backlog item labeled "needs exploration." Output: a charter card the tester executes and reports against.
Step 1 - Frame the mission
The mission is the load-bearing field - one sentence telling the tester what to learn. Three patterns:
| Pattern | Example mission |
|---|---|
| New feature | "Explore the new promo-code apply flow at checkout to discover usability issues, edge cases, and integration risks." |
| Refactor / change risk | "Explore cart and checkout after the cart-state refactor to find regressions in state persistence." |
| Bug cluster / risk area | "Explore the Stripe webhook handler with focus on retry / out-of-order delivery after the webhook-replay incident." |
A mission is not "test the checkout page" (too vague) or "verify promo codes apply" (too narrow - that's a scripted test).
Step 2 - Scope areas, pick the time-box, suggest tours
Areas (3-7 per 90-min session) scope the exploration; they are what to look at, not what to assert. Derive them from the input: spec sections, diff blast-radius, or the bug cluster's common surface.
Time-box lengths (60 / 90 / 120 min) and their rationale: exploratory-testing.
Suggested tours, and how many to pick per session: references/tours.md (opens in new window). The charter suggests; the tester picks. For the Bad-data tour, point the tester at malicious-payload-bank.
Step 3 - Wire the deliverables (PROOF debrief)
Sessions deliver a structured PROOF debrief into the exploratory-testing debrief template (references/debrief.md (opens in new window)); the debrief fields and the session-sheet structure are owned by that skill. The charter's deliverables block names three things:
Step 4 - Fill the charter card
Assemble mission (Step 1), areas + time-box + suggested tours (Step 2), and deliverables (Step 3) into the card format from references/charter-template.md (opens in new window), adding the source artifact ("Created from: story / diff / incident"), the target build / SHA, and an explicit out-of-scope list (performance / load → k6-load-testing; a11y → qa-accessibility; cross-browser → qa-web-e2e).
Halt rules
Do not emit a charter that violates any of these:
Hand-off targets
References
Related skills
bug-bash-facilitator
Builds a structured bug-bash session - pre-bash kit (charter, test-data prep, environment setup, sign-up sheet), in-bash structure (role rotation across cohorts, shared backlog board, real-time triage), scoring rubric (severity weighting, novelty bonus), and a post-bash same-day wrap-up authored by the facilitator (not a standalone debrief: for post-session writeups without a live bash, use the PROOF debrief in exploratory-testing). Use when a team needs a coordinated multi-tester sweep before a release or after a major change - converts an ad-hoc "everyone test for an hour" into a recorded, comparable session with deliverables.
decision-table-test-design
Derives human-readable manual test cases from a business-rule spec via a decision table: identify conditions and actions, build the full 2^n-column matrix, collapse columns with irrelevant entries, strike infeasible combinations, then emit one test case per remaining column (each feasible column is one coverage item per ISTQB CTFL v4.0 section 4.2.3). A deep single-technique walkthrough rather than a broad multi-lens case matrix; the output is manual step/expected cases rather than parameterized test code, and it covers how cases are derived rather than how a case record is structured. Use when a spec's outcome depends on interacting conditions (pricing, eligibility, discounts, routing rules) rather than the boundaries of a single input.
exploratory-testing
Plans and runs time-boxed exploratory testing when tester hours are scarce before a release - one tester with two free 45-minute blocks before code freeze, a high-stakes window such as year-end payroll, or a device and environment the scripted suite never touches. Session-based per the Bachs' SBTM: charters (Explore X with Y to discover Z), 60-90 minute sessions, session sheets with TBS metrics, and the PROOF debrief. Bundles the exploration heuristics as references - Whittaker's seven tours, Kelly's FCC CUTS VIDS, Bach's SFDPOT. Broader than exploratory-charter-author, which writes one charter document: this owns the whole cycle from budgeting the available hours to debriefing what was found. Use when deciding what to explore with the time available, and how to run and record those sessions.
manual-test-script-author
Builds stakeholder-readable scripted manual test cases from a feature spec in four formats: a step-table (preconditions / steps / expected result / actual / pass-fail / notes) for spreadsheet review, a Gherkin Given/When/Then format for BDD-aware teams, a business-language UAT script with acceptance-criteria mapping and contractual sign-off (references/uat-format.md), and a one-line-per-item execution checklist for smoke / on-call / bug-bash / compliance sweeps (references/checklist-format.md). Each script is self-contained (no implicit team knowledge), single-scenario (one happy + N edge per script), and includes the data setup the tester needs without being a developer. Use when a feature can't be (or shouldn't be) fully automated and a human tester needs an executable script or checklist - UAT sign-off rounds, regression baselines, certification testing, deploy smoke checklists, exploratory follow-up scripts.
state-transition-test-design
Derives human-readable manual test cases from stateful behavior: identify states, events, transitions, and guard conditions, draw the state table including invalid (empty-cell) transitions, choose a coverage level (all states, valid transitions / 0-switch, transition pairs / 1-switch per Chow, all transitions including invalid ones), then derive one test case per coverage item as an event sequence with per-step expected states (ISTQB CTFL v4.0 section 4.2.4). A deep single-technique walkthrough rather than a broad multi-lens case matrix; the output is manual step/expected cases rather than parameterized test code, and it covers how cases are derived rather than how a case record is structured. Use for lifecycle entities (accounts, orders, subscriptions), workflows, and UI wizards where the response to an event depends on the current state.