.config/opencode/skills/workflow-review-code/SKILL.md
This skill should be used when reviewing code changes in a branch against main/master/develop. It analyzes commits, integrates JIRA ticket and MR context when available, and produces a structured code review using Conventional Comments format.
npx skillsauth add alexismanuel/dotfiles workflow-review-codeInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Review commits and changes in the current branch against main/master/develop. Analyze the diff, integrate available context (JIRA tickets, MR comments), and produce a structured code review.
Type: FLEXIBLE - Adapt review depth to the size and complexity of the changes.
Output: review.md with Conventional Comments format feedback.
Use this workflow when:
Announce at start: "I'm using the review-code workflow to analyze these changes."
When this workflow is invoked, gather context from multiple sources:
Extract from provided arguments:
[A-Z]+-[0-9]+ (e.g., "RD-1234")merge_requests/[0-9]+ (e.g., from GitLab URL)Use the jira-ticket-fetcher skill to retrieve:
Use the mr-tracker skill to retrieve:
# Working Directory Status
git status --short
# Current Branch
git rev-parse --abbrev-ref HEAD
# Branch Commits (not in main/master/develop)
git log --oneline --no-merges $(git merge-base HEAD $(git for-each-ref --format='%(refname:short)' refs/heads/ | grep -E '^(main|master|develop)$' | head -n1))..HEAD
# Commit Details
git log --no-merges --format="%H%n Author: %an <%ae>%n Date: %ad%n Message: %s%n Body: %b%n" --date=short $(git merge-base HEAD $(git for-each-ref --format='%(refname:short)' refs/heads/ | grep -E '^(main|master|develop)$' | head -n1))..HEAD
# Files Changed
git diff --name-status $(git merge-base HEAD $(git for-each-ref --format='%(refname:short)' refs/heads/ | grep -E '^(main|master|develop)$' | head -n1))..HEAD
# Full Diff
git diff $(git merge-base HEAD $(git for-each-ref --format='%(refname:short)' refs/heads/ | grep -E '^(main|master|develop)$' | head -n1))..HEAD
If JIRA Ticket Context is available:
If MR Context is available:
If neither is provided:
jira-ticket-fetcher or mr-tracker skills to fetch additional informationIMPORTANT: Review ONLY committed changes. Ignore any uncommitted modifications in the working directory.
git show HEAD:path/to/filereview.mdUse this format for all review comments:
<label>: <subject>
<discussion>
| Label | Description |
|-------|-------------|
| praise: | Highlight something positive |
| nitpick: | Trivial preference-based request |
| suggestion: | Propose an improvement |
| issue: | Highlight a problem that needs addressing |
| question: | Seek clarification or understanding |
| thought: | Share an idea without requiring action |
| chore: | Simple task that must be done |
Add decorators in parentheses after the label:
(blocking) - Must be resolved before approval(non-blocking) - Optional, nice to have(if-minor) - Only address if the fix is simple**issue (blocking):** SQL injection vulnerability
The query on line 45 concatenates user input directly. Use parameterized queries instead.
---
**suggestion (non-blocking):** Consider using a constant
This magic number `86400` appears multiple times. Consider extracting to a named constant like `SECONDS_PER_DAY`.
---
**praise:** Clean error handling
The retry logic with exponential backoff is well implemented and handles edge cases nicely.
When reviewing, consider:
Write the review to review.md:
# Code Review: [Branch Name]
**Reviewed:** [Date]
**Commits:** [N commits]
**Files Changed:** [N files]
**JIRA:** [Ticket ID or "N/A"]
## Summary
[2-3 sentence summary of the changes and overall assessment]
## Blocking Issues
[List any blocking issues that must be resolved]
## Suggestions
[List non-blocking suggestions for improvement]
## Praise
[Highlight what was done well]
## Questions
[Any clarifying questions]
## Requirement Validation
[If JIRA context available, validate against acceptance criteria]
development
Generate GitLab merge request descriptions from git commits with automatic categorization and Jira integration.
development
This skill should be used when validating that an implementation plan was correctly executed. It verifies success criteria, runs tests, identifies deviations, and presents structured completion options including MR creation or discard.
development
This skill should be used when conducting comprehensive codebase research to answer questions, understand architecture, or prepare context for implementation planning. It spawns parallel sub-agents and synthesizes findings into a structured research document.
testing
This skill should be used when executing an approved implementation plan with batch checkpoints. It implements tasks in batches of 3, stops for review after each batch, and handles mismatches or blockers by asking for guidance rather than guessing.