Local CI Code Review Skill
Runs a deep structured code review locally, applying the same methodology used by the codex-ai-code-review-action CI pipeline. Uses repository-specific guidance from .github/codex/review-reference.md and the review methodology defined below.
Step 1: Identify the Changes
Determine the diff to review:
# Changes on current branch vs main (default)
git diff main...HEAD
# Uncommitted changes (if no branch commits yet)
git diff HEAD
# Specific commit range (if provided)
git diff <base>..<head>
If no scope is specified, default to main...HEAD.
List the changed files and note their types — file types determine which checklists apply in Step 3.
Step 2: Load Review Context
Read the repository-specific reference material and file-type instruction rules:
.github/codex/review-reference.md — repository-specific review guidance (conventions, Python script rules, workflow rules).github/copilot-instructions.md — Agent Skills format compliance, repository constraints, automated validation coverage, review focus areas.github/instructions/markdown.instructions.md — documentation quality rules, description quality, progressive disclosure, file reference conventions.github/instructions/scripts.instructions.md — Python script conventions, stdlib-only constraint, type hints, error handling, code organization rules
The review reference file provides repository-specific conventions — apply them alongside the methodology defined in this skill. The instruction files provide supplementary file-type-specific rules: apply copilot-instructions.md to all files, markdown.instructions.md when the diff includes **/*.md, and scripts.instructions.md when it includes skill-system-foundry/scripts/**/*.py.
Step 3: Review the Diff
Apply the review methodology from the loaded context. For each changed file:
- Identify the file type and select the matching checklist from the reference material (Python, Shell, Markdown, Workflow YAML).
- Trace data flow — follow values from input through parsing, transformation, and use.
- Check execution order — verify validation happens before use.
- Verify edge cases — empty arrays, zero, negatives, boundaries, missing optional fields.
- Connect schema to runtime — check if documented contracts are enforced.
- Check error propagation — verify callers handle failures.
For each finding, write the reasoning first, then assign priority and confidence.
Priority levels
| Priority |
Scope |
Examples |
| P0 |
Critical bugs, security vulnerabilities |
Data loss, injection, auth bypass, crash in mainline path |
| P1 |
Correctness and robustness |
Off-by-one, unhandled error path, race condition |
| P2 |
Maintainability and style |
Misleading name, duplicated logic, missing type hint |
| P3 |
Minor improvements |
Whitespace, comment wording, optional simplification |
Confidence scoring
| Range |
Meaning |
| 0.9–1.0 |
Certain — code is demonstrably wrong or violates documented rule |
| 0.7–0.9 |
High — very likely based on context, depends on intent |
| 0.5–0.7 |
Moderate — plausible, could be intentional |
| 0.3–0.5 |
Low — possible concern, may be false positive |
| < 0.3 |
Speculative — flag only if severe impact |
Rules
- Flag only issues introduced by the diff. Do not flag pre-existing problems.
- Include findings at all priority levels — do not suppress low-priority findings.
- Do not flag known limitations listed in the reference material.
- Read the full source file when diff context is insufficient.
Step 4: Run the Self-Review Checklist
Before producing output, verify:
- Every changed file in the diff has been examined.
- The relevant file-type checklist was applied to each file.
- Data flow was traced for any new parsing, transformation, or validation logic.
- Edge cases were checked for new conditional branches or numeric conversions.
- If zero findings, each file's clean status can be explained.
Step 5: Report Findings
Produce a structured review matching the CI pipeline output format.
Output format
## Summary
[1-5 sentence description of what the changes do and why]
## Changes
- [Short bullet describing each logical change]
## Files
| File | Description |
|---|---|
| path/to/file | Short description of what changed |
## Findings
### P0 — Critical
[findings or "None"]
### P1 — Correctness
[findings or "None"]
### P2 — Maintainability
[findings or "None"]
### P3 — Minor
[findings or "None"]
## Verdict
**[patch is correct | patch is incorrect]** (confidence: X.XX)
[One-sentence rationale]
Finding format
For each finding:
[P{n}] {title} — {path}:{line} (confidence: {score})
{body}
{exact replacement code, or omit block if null}
Metadata
After the verdict, append:
---
Findings: {total} ({skipped} below confidence threshold)
Model: {self-reported model identifier}
Review scope: {diff range used}
Rules
- Empty findings is a valid outcome — a clean diff is not a failure to review.
- Do not manufacture findings to justify the review.
- Do not suggest alternative implementations unless the current one is clearly wrong.
- Do not comment on style preferences without a documented convention backing them.
1---2name: local-ci-code-review3description: Runs a deep structured code review locally, applying the same methodology used by the codex-ai-code-review-action CI pipeline — priority levels, confidence scoring, data flow tracing, and structured findings — without requiring GitHub Actions or an external API. Triggers when asked to run the CI review locally, do a deep code review, review like the pipeline would, or check what CI would flag. Also triggers on phrases like "run the CI review on this," "what would the pipeline review find," "deep review this branch," or "simulate the automated review." For running automated checks (tests, coverage, shellcheck), use the local-code-review skill instead. For human PR review process guidance, use the review skill instead.4---56# Local CI Code Review Skill78Runs a deep structured code review locally, applying the same methodology used by the `codex-ai-code-review-action` CI pipeline. Uses repository-specific guidance from `.github/codex/review-reference.md` and the review methodology defined below.910## Step 1: Identify the Changes1112Determine the diff to review:1314```bash15# Changes on current branch vs main (default)16git diff main...HEAD1718# Uncommitted changes (if no branch commits yet)19git diff HEAD2021# Specific commit range (if provided)22git diff <base>..<head>23```2425If no scope is specified, default to `main...HEAD`.2627List the changed files and note their types — file types determine which checklists apply in Step 3.2829## Step 2: Load Review Context3031Read the repository-specific reference material and file-type instruction rules:3233- `.github/codex/review-reference.md` — repository-specific review guidance (conventions, Python script rules, workflow rules)34- `.github/copilot-instructions.md` — Agent Skills format compliance, repository constraints, automated validation coverage, review focus areas35- `.github/instructions/markdown.instructions.md` — documentation quality rules, description quality, progressive disclosure, file reference conventions36- `.github/instructions/scripts.instructions.md` — Python script conventions, stdlib-only constraint, type hints, error handling, code organization rules3738The review reference file provides repository-specific conventions — apply them alongside the methodology defined in this skill. The instruction files provide supplementary file-type-specific rules: apply `copilot-instructions.md` to all files, `markdown.instructions.md` when the diff includes `**/*.md`, and `scripts.instructions.md` when it includes `skill-system-foundry/scripts/**/*.py`.3940## Step 3: Review the Diff4142Apply the review methodology from the loaded context. For each changed file:43441. **Identify the file type** and select the matching checklist from the reference material (Python, Shell, Markdown, Workflow YAML).452. **Trace data flow** — follow values from input through parsing, transformation, and use.463. **Check execution order** — verify validation happens before use.474. **Verify edge cases** — empty arrays, zero, negatives, boundaries, missing optional fields.485. **Connect schema to runtime** — check if documented contracts are enforced.496. **Check error propagation** — verify callers handle failures.5051For each finding, write the `reasoning` first, then assign priority and confidence.5253### Priority levels5455| Priority | Scope | Examples |56|---|---|---|57| P0 | Critical bugs, security vulnerabilities | Data loss, injection, auth bypass, crash in mainline path |58| P1 | Correctness and robustness | Off-by-one, unhandled error path, race condition |59| P2 | Maintainability and style | Misleading name, duplicated logic, missing type hint |60| P3 | Minor improvements | Whitespace, comment wording, optional simplification |6162### Confidence scoring6364| Range | Meaning |65|---|---|66| 0.9–1.0 | Certain — code is demonstrably wrong or violates documented rule |67| 0.7–0.9 | High — very likely based on context, depends on intent |68| 0.5–0.7 | Moderate — plausible, could be intentional |69| 0.3–0.5 | Low — possible concern, may be false positive |70| < 0.3 | Speculative — flag only if severe impact |7172### Rules7374- Flag only issues **introduced by the diff**. Do not flag pre-existing problems.75- Include findings at all priority levels — do not suppress low-priority findings.76- Do not flag known limitations listed in the reference material.77- Read the full source file when diff context is insufficient.7879## Step 4: Run the Self-Review Checklist8081Before producing output, verify:82831. Every changed file in the diff has been examined.842. The relevant file-type checklist was applied to each file.853. Data flow was traced for any new parsing, transformation, or validation logic.864. Edge cases were checked for new conditional branches or numeric conversions.875. If zero findings, each file's clean status can be explained.8889## Step 5: Report Findings9091Produce a structured review matching the CI pipeline output format.9293### Output format9495```96## Summary97[1-5 sentence description of what the changes do and why]9899## Changes100- [Short bullet describing each logical change]101102## Files103| File | Description |104|---|---|105| path/to/file | Short description of what changed |106107## Findings108109### P0 — Critical110[findings or "None"]111112### P1 — Correctness113[findings or "None"]114115### P2 — Maintainability116[findings or "None"]117118### P3 — Minor119[findings or "None"]120121## Verdict122**[patch is correct | patch is incorrect]** (confidence: X.XX)123[One-sentence rationale]124```125126### Finding format127128For each finding:129130> **[P{n}] {title}** — `{path}:{line}` (confidence: {score})131>132> {body}133>134> <details>135> <summary>Reasoning</summary>136> {reasoning — what was observed, why it is a problem, concrete impact}137> </details>138>139> ```suggestion140> {exact replacement code, or omit block if null}141> ```142143### Metadata144145After the verdict, append:146147```148---149Findings: {total} ({skipped} below confidence threshold)150Model: {self-reported model identifier}151Review scope: {diff range used}152```153154### Rules155156- Empty findings is a valid outcome — a clean diff is not a failure to review.157- Do not manufacture findings to justify the review.158- Do not suggest alternative implementations unless the current one is clearly wrong.159- Do not comment on style preferences without a documented convention backing them.
milanhorvatovic