with one click
assess
// Understand a Quay bug report from JIRA or GitHub. Fetches ticket details, checks for existing work, classifies as UI vs backend, and proposes an investigation plan. No code changes.
// Understand a Quay bug report from JIRA or GitHub. Fetches ticket details, checks for existing work, classifies as UI vs backend, and proposes an investigation plan. No code changes.
Orchestrates the Quay bug-fix workflow through 9 phases with confidence-based gating. Reads confidence from phase artifacts to advance automatically, post JIRA comments, or escalate to the user.
Root cause analysis for a Quay bug. Traces code paths through Quay subsystems, analyzes git history, forms and tests hypotheses, and enumerates complete state space.
Create comprehensive documentation for a Quay bug fix: JIRA ticket update, release notes, changelog entry, PR description, and team communication.
Systematically reproduce a Quay bug using project-specific tooling. Documents environment, reproduction steps, and observable behavior.
Critically evaluate a bug fix and its tests. Forms a verdict (inadequate / tests incomplete / solid) and recommends next steps.
Verify a bug fix with comprehensive testing using Quay's test infrastructure. Creates regression tests, runs the full suite, and documents results.
| name | assess |
| description | Understand a Quay bug report from JIRA or GitHub. Fetches ticket details, checks for existing work, classifies as UI vs backend, and proposes an investigation plan. No code changes. |
| allowed-tools | ["Bash(bash .claude/scripts/jira-ops.sh *)","Bash(gh issue view *)","Bash(gh pr list *)","Bash(gh search prs *)","Bash(gh repo clone *)","Bash(git log *)","Bash(ls *)","Read","Glob","Grep","AskUserQuestion"] |
Understand the bug before taking any action. This phase produces an assessment report — no code execution, no project code modifications (writing assessment artifacts and cloning repositories is allowed).
Read the bug report, present your understanding back to the user, identify gaps, and propose a plan. Let the user correct you before you invest effort in the wrong direction.
Accept either a JIRA ticket key, a GitHub issue URL, or a free-text description from the user.
For JIRA tickets:
bash .claude/scripts/jira-ops.sh view $TICKET
Extract: summary, description, type, component, priority, labels, comments, reporter, attachments.
For GitHub issues:
gh issue view NUMBER --repo ${DEFAULT_REPO:-quay/quay} --json title,body,labels,comments,state
For free-text descriptions: Use the conversation context directly.
ls /workspace/repos/ 2>/dev/null
If the project repo is present (e.g., /workspace/repos/quay/), note its
path. If not, clone it:
gh repo clone ${DEFAULT_REPO:-quay/quay} /workspace/repos/quay
Read referenced files or code paths to inform the assessment. This is read-only exploration.
Search for PRs or related issues that may already address this bug:
gh pr list --search "$TICKET" --state all --repo ${DEFAULT_REPO:-quay/quay} --json number,title,headRefName --jq '.[] | "\(.number)\t\(.title)"'
gh search prs "$TICKET" --repo ${DEFAULT_REPO:-quay/quay}
If an open PR appears to directly address this bug, stop and use
AskUserQuestion before continuing. Present options:
Do not continue until the user responds.
bash .claude/scripts/jira-ops.sh check-version $TICKET
If Target Version is set, note that backporting will be required after merge.
Determine whether this is a UI bug or Backend bug:
UI indicators: component is ui or web; keywords like rendering,
display, button, form, modal, PatternFly, React; screenshot attachments.
Backend indicators: component is api, data, auth, workers,
storage, buildman; keywords like endpoint, database, migration, worker,
ORM; log file or stack trace attachments.
Present to the user:
Based on your understanding, outline:
Save to artifacts/quay-bugfix/reports/assessment.md:
# Bug Assessment: <TICKET>
## Summary
<One-paragraph understanding of the bug>
## Classification
- **Type:** UI / Backend
- **Subsystem:** <from CLAUDE.md subsystem map>
- **Severity:** <from JIRA priority>
- **Component:** <JIRA component>
## Existing Work
<Any related PRs, issues, or prior fixes found — or "None found">
## Available Information
- <what the report provides>
## Gaps
- <what's missing or unclear>
## Assumptions
- <any assumptions being made>
## Proposed Investigation Plan
1. Reproduce: <specific steps>
2. Diagnose: <subsystems and code areas to investigate>
3. Fix approach: <initial hypothesis, if any>
## Backport Required
<Yes/No — based on Target Version field>
Include this section at the end of your assessment artifact:
## Confidence Assessment
- **Level**: high | medium | low
- **Score**: <0-100 integer>
- **Score rationale**: <1-2 sentences>
- **Open questions**: <bullet list, or "None">
Confidence signals for this phase:
artifacts/quay-bugfix/reports/assessment.mdReport your assessment: understanding, gaps, plan, and backport status.