ootbt-ticket-technical-ak-review

Reviews technical ticket acceptance criteria against frozen repository commits with multi-model evidence checks.

Updated Aug 20, 2026
One-click install
npx skills add https://github.com/nowrap/ootbt-skills --skill ootbt-ticket-technical-ak-review-nowrap
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ootbt-ticket-technical-ak-review
Source: https://github.com/nowrap/ootbt-skills/tree/main/skills/ootbt-ticket-technical-ak-review
Command: npx skills add https://github.com/nowrap/ootbt-skills --skill ootbt-ticket-technical-ak-review-nowrap

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Verifying whether a ticket's technical acceptance criteria are actually implemented is error-prone when done by a single model pass or by trusting commit messages and ticket IDs. This Skill freezes the ticket text and repository state at fixed commit SHAs, then checks each criterion against reproducible ground truth so that unmet, contradicted, or unverifiable requirements are surfaced explicitly instead of being smoothed over. ## Core Features & Use Cases - Criterion-by-criterion review: Decomposes bundled acceptance criteria into atomic subclaims, classifies them (factual, judgment, systemic, negative, runtime), and routes each to isolated primary reviewer processes. - Evidence-over-majority adjudication: Mechanically re-verifies every cited file, line range, and test execution at the frozen commit; negative claims require multiple probes or remain UNKNOWN, and no majority vote replaces evidence. - Tracker integration with opt-in publishing: Reads tickets from Jira (acli/REST), YouTrack (MCP/REST), or GitLab (glab), renders a structured review with per-criterion dispositions (KEEP, KEEP_UNMET, REFINE, SPLIT, and more), and publishes comments only after explicit approval and readback. - Use Case: Before a QA handoff, run the review against a Jira ticket and two pinned repository commits to learn which acceptance criteria are demonstrably implemented, which are only partially evidenced, and which need refinement or a product decision. ## Quick Start Review the technical acceptance criteria of Jira ticket PROJ-123 against the current main branch commits of this repository and produce a consolidated review without publishing anything.

Frequently Asked Questions about ootbt-ticket-technical-ak-review

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

FAQPage Schema
How do I review Jira ticket acceptance criteria against code?

Provide the tracker, ticket ID, repository roots, and fixed commit SHAs. The Skill reads the ticket via acli or the Jira REST API, freezes the acceptance criteria text, and checks each criterion against the pinned code state with isolated reviewer processes.

How does the review decide if an acceptance criterion is met?

Each criterion is decomposed into atomic subclaims checked against the frozen target tree. Positive evidence is mechanically re-verified at the exact commit and line range, negative claims need multiple probes, and undecidable cases are marked UNKNOWN rather than guessed.

Which ticket trackers are supported for acceptance criteria review?

Jira is supported via acli and the Jira REST API v3, YouTrack via MCP tools or its REST API, and GitLab issues via glab. Tool names and schemas are verified live, and publishing comments always requires explicit approval plus readback.

Can the review publish results back to the ticket automatically?

No, publishing is strictly opt-in. The workflow shows a preview, payload hash, and target, requires explicit user approval, writes the comment, and then reads it back to verify the marker or hash before claiming publication.

When should I not use this ticket review workflow?

It is not suited for non-technical product acceptance without technical ground truth, general plan or document challenges without a ticket, or full thesis-judge-evaluator procedures. QA-only criteria are excluded by default unless explicitly included.