Explain a Ticket

Understand the work before you write code. Explain a Ticket reads a Jira or GitHub issue against the code it touches and describes the components involved, how they behave today, and the code around them.

From ticket to the code it touches.

Explain a Jira or GitHub issue using the code it touches. Describes the relevant components, their current behavior, and surrounding code so you can understand the work before implementing it.

Claude Code/cloudaeye:explain jira PROJ-123

PROJ-123

Make the payment retry cap configurableStory

Operators need to change how many times a failed payment is retried, without a deploy.

  • Read the retry cap from configuration.
  • Default to 3 when the setting is missing.
  • Reject values below 1.

Explanation

payments-apiRepository analyzed

Relevant components

payments/retry.ts runs the retry loop. payments/config.ts loads payment settings.

Current behavior

The loop retries three times with a fixed two-second delay. The count is a constant in retry.ts.

Related patterns

config.ts already reads TIMEOUT_MS from the environment with a default and validation. Follow the same pattern.

Read the ticket.
Understand the code.

A ticket says what to build, not where or how the code works today. Explain a Ticket connects the requirements to the components they touch, so the first commit goes in the right place.

Start with context, not guesswork.

CloudAEye finds the components behind the issue with the repository's code graph and vector-based context, and explains how they work today.

  • Issue contextSummarized
  • ComponentsFound in the code graph
  • Current behaviorExplained
See an example

Jira or GitHub issues.

Run it from your coding agent with a Jira key or GitHub issue number, or comment on the ticket itself.

  • Jirajira PROJ-123
  • GitHubgithub 42
  • On the ticket@cloudaeye /explain
See the commands

Follow the patterns that exist.

The explanation points to existing implementations, configuration, and dependencies, so new code fits the codebase instead of reinventing it.

  • PatternsExisting implementations
  • ConfigurationSettings that matter
  • DependenciesSurrounding code
Read the docs

Then check the work.

Explain the ticket, plan and implement the change, then confirm it with Check Task and a bug review before merging.

  • Before codingExplain a Ticket
  • Before commitCheck Task
  • Before mergeBug Review
Explore Check Task

Commands

Claude Code
/cloudaeye:explain jira PROJ-123
Codex
$cloudaeye:explain github 42
Jira · GitHub issue
@cloudaeye /explain

On a Jira ticket, the explanation is also left as a comment on the ticket.