ticket-driven-testing

Verifies ticket and PR changes with Playwright evidence bundles, negative controls, and sentinel tests.

5|2|Updated May 19, 2026
One-click install
npx skills add https://github.com/civitas-cerebrum/achilles --skill ticket-driven-testing-civitas-cerebrum
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ticket-driven-testing
Source: https://github.com/civitas-cerebrum/achilles/tree/main/skills/ticket-driven-testing
Command: npx skills add https://github.com/civitas-cerebrum/achilles --skill ticket-driven-testing-civitas-cerebrum

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? QA work tied to a ticket or a just-finished code change often ends in unverified claims: tests written from the diff that bind to one implementation, green suites that never proved they would catch a regression, and verdicts posted with no evidence behind them. This Skill turns a ticket, branch, or developer request into verified evidence, durable regression tests, and sentinel tests for every defect found. ## Core Features & Use Cases - Structured 10-step QA sequence: ticket intake, PR review-state check, worktree isolation, diff review, environment access, interaction-driven understanding, durable test authoring, negative control, adversarial review, and reporting. - Negative control enforcement: runs the new suite against an environment without the fix (or the merge-base commit locally) to prove tests actually discriminate the change. - Adversarial review and evidence bundles: dispatches subagent reviewers to attack the tests, scores testing rigour, and produces per-ticket evidence bundles via companion-mode. - Use Case: A developer says "QA this ticket before I open the PR." The Skill derives acceptance criteria from the diff, confirms them with the developer, drives the app in a browser, writes one test per AC plus sentinels for defects, proves the suite fails on the merge-base, and reports a grounded verdict. ## Quick Start Ask the agent to QA a specific ticket or branch, for example: "QA ticket ABC-450 on its feature branch and verify the acceptance criteria with evidence before I open the PR."

Frequently Asked Questions about ticket-driven-testing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I QA a ticket or PR before merging?

Run the ticket-driven-testing sequence: read the ticket and its parent for acceptance criteria, check PR review state, worktree the branch, review the diff, then drive the app in a browser to build understanding before writing tests. Finish with a negative control run and an evidence bundle before reporting a verdict.

How do I test uncommitted changes a developer just finished?

Use the dev-triggered entry point: derive 3-6 candidate acceptance criteria from the diff and confirm them with the developer, then test in place since uncommitted work is not captured by a git worktree. Use the merge-base commit as the negative control to prove the new tests fail without the change.

What is a negative control in Playwright test suites?

A negative control runs the new test suite against an environment or commit without the fix, proving the tests fail there. Any test passing in both places is not testing the change; it is testing something already true and provides no regression cover for the feature.

Does this workflow work with Jira or Linear tickets?

Yes, the workflow is tracker-agnostic and maps six capabilities (read ticket, read parent, find branch, find PR, post report, attach evidence) onto whatever tracker is connected via MCP, CLI, or REST. If no tracker is reachable, paste the acceptance criteria and branch manually and the remaining phases run unchanged.

Why do tests written from a diff fail as regression cover?

Tests written from a diff bind to one branch's implementation details, such as class tokens or structural attributes, and break or mislead when the implementation changes. Deriving assertions from observed browser behaviour produces tests that survive implementation changes and assert outcomes users actually notice.

When should test.fail() be used in a Playwright suite?

Use test.fail() only for defect sentinels tied to a tracked ticket: assert the correct behaviour, mark it as a known defect, and let it flip loud when someone fixes the bug, signalling deletion. Outside this sentinel lifecycle, test.fail() is banned in the suite.