Issue Context Review

Issue-Context Code Review

Enrich code reviews with business context by resolving linked issues/tickets before the review begins. Ensures code changes satisfy acceptance criteria and business requirements — not just code quality.

Prerequisites

Before executing this skill, ensure:

1. A code review is in progress with access to the PR/MR metadata (branch name, title, description)
2. The relevant issue tracker is accessible via the configured connection
3. The {{config.issue_tracker}} connection is available

Workflow

Step 1: Extract Issue References

Parse the branch name, PR/MR title, and PR/MR description to find issue references.

Branch name patterns:

PR/MR description patterns:

Extraction priority:

1. PR/MR description (most explicit signal)
2. PR/MR title
3. Branch name

If no issue reference is found from any source, skip this skill entirely and proceed with the standard code review. Do not fabricate or guess issue references.

Step 2: Fetch Issue Details

Based on {{config.issue_tracker}}, fetch the issue details:

GitLab:

source ./_skills/connections/gitlab/gitlab/scripts/gitlab_helpers.sh
ISSUE=$(gitlab_get_issue "{{config.project_key}}" $ISSUE_NUMBER)

GitHub:

source ./_skills/connections/github/github/scripts/github_helpers.sh
ISSUE=$(gh issue view $ISSUE_NUMBER --repo "{{config.project_key}}" --json title,body,labels,state,assignees)

Jira:

source ./_skills/connections/atlassian/jira/scripts/jira_helpers.sh
ISSUE=$(jira_get_issue "{{config.project_key}}-${ISSUE_NUMBER}")

Bitbucket:

source ./_skills/connections/bitbucket/bitbucket/scripts/bitbucket_helpers.sh
ISSUE=$(bitbucket_get_issue "{{config.project_key}}" $ISSUE_NUMBER)

Extract from the fetched issue:

Step 3: Build Business Context Summary

Compile a structured context block for the code review agent:

## Linked Issue Context

**Issue:** {tracker_prefix}{issue_number} — {issue_title}
**Tracker:** {{config.issue_tracker}}
**Status:** {issue_status}
**Type:** {issue_type}

### Requirements
{issue_description_or_body}

### Acceptance Criteria
{extracted_acceptance_criteria_as_checklist}

Step 4: Inject Context into Review

Provide the business context to the code review with these instructions:

1. Requirements coverage — Verify that the code changes address the requirements described in the linked issue
2. Acceptance criteria — Check each acceptance criterion against the diff. Flag any that appear unmet
3. Scope alignment — Flag changes that appear unrelated to the issue (scope creep) or requirements that are not addressed by any changed file
4. Edge cases from requirements — If the issue describes specific scenarios or constraints, verify the code handles them

Step 5: Append Findings to Review

Add a dedicated section to the review output:

### Business Logic Validation

**Linked Issue:** {tracker_prefix}{issue_number} — {issue_title}

#### Acceptance Criteria Coverage
- [x] {criterion_1} — Addressed in `{file}:{line}`
- [ ] {criterion_2} — **Not addressed in this PR/MR**
- [x] {criterion_3} — Addressed in `{file}:{line}`

#### Observations
- {any scope misalignment, missing requirements, or partial implementations}

Skip Conditions

Do NOT execute this skill when:

• No issue reference is found in the branch name, PR/MR title, or PR/MR description
• The referenced issue cannot be fetched (tracker unreachable, permission denied, issue not found)
• The issue is in a terminal state (Closed, Done, Cancelled) and appears stale

When skipping, silently proceed with standard code review. Do not post warnings about missing issue references.

Output

When this skill executes successfully, the code review output includes:

1. The linked issue reference and title
2. Acceptance criteria coverage checklist (met vs. unmet)
3. Scope alignment observations
4. Any business logic concerns found during review

Error Handling

Branch Name Parsing Rules

Apply patterns in this order (first match wins):

1. Jira-style key: /([A-Z][A-Z0-9_]+-\d+)/ → e.g., OPS-1234
2. Hash-prefixed number: /#(\d+)/ or /\b#(\d+)\b/ → e.g., #456
3. Bare number after slash: /\/(\d+)[-_]/ → e.g., /1234-fix-bug
4. Bare number in description: /(?:close[sd]?|fix(?:e[sd])?|resolve[sd]?)\s+#?(\d+)/i

Guidelines

• Never block a review because an issue reference is missing — this is an enrichment, not a gate
• Keep the business context section concise — summarize long issue descriptions
• Do not repeat the entire issue body verbatim; extract the actionable requirements
• When acceptance criteria are informal (prose instead of checklist), convert them to checkable items
• If the issue has subtasks or child tickets, only reference the directly linked issue

Counter-Rationalizations