milanhorvatovic/local-ci-code-review
.agents/skills/local-ci-code-review/SKILL.md
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.
$ install --global
skillsauthnpx skillsauth add milanhorvatovic/skill-system-foundry local-ci-code-reviewInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 17, 2026, 3:36 AM30.8s1 file scanned
SKILL.md
- name:
- local-ci-code-review
- description:
- >
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}
<details> <summary>Reasoning</summary> {reasoning — what was observed, why it is a problem, concrete impact} </details>{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.
Related Skills
milanhorvatovic/hello-router
tools
VerifiedTrustedCommunity
Greets a recipient through one of two registered tones — formal or casual — by dispatching to a dedicated capability. Activates when the conversation asks for a tone-specific welcome or a switch between formal and casual greetings; use when comparing the two styles. Demonstrates the router pattern in the Skill System Foundry — a thin SKILL.md entry point routing to capability files, with allowed-tools declared in frontmatter so capability shell fences pass validation.
1SKILL.mdUpdated Apr 29, 2026
milanhorvatovic/hello-greeter
testing
VerifiedTrustedCommunity
Greets a single recipient with a friendly welcome message rendered in a formal or casual tone. Activates when the conversation asks to say hello or welcome someone; use when a minimal standalone skill is needed. Demonstrates the smallest valid standalone skill in the Skill System Foundry — required name and description frontmatter plus an optional metadata block — and how its layout passes validation.
1SKILL.mdUpdated Apr 29, 2026
milanhorvatovic/skill-system-foundry
testing
VerifiedTrustedCommunity
Designs and evolves AI-agnostic skill systems. Triggers on skill/capability creation, role definition, or router migration; use when auditing consistency or improving token efficiency.
1SKILL.mdUpdated Apr 17, 2026
milanhorvatovic/yaml-config
development
VerifiedTrustedCommunity
Governs the configuration.yaml file that serves as the single source of truth for all validation rules in the Skill System Foundry. Triggers when adding, modifying, or reviewing validation rules, limits, patterns, or reserved words. Also triggers when working with constants.py, yaml_parser.py, or any code that reads from configuration.yaml. Use this skill when asked to add a new validation check, change a limit or threshold, update reserved word lists, add SPDX license identifiers, modify regex patterns, or troubleshoot why a validation rule is not working as expected. Activates on mentions of configuration, validation rules, constants, thresholds, or pattern definitions.
1SKILL.mdUpdated Apr 17, 2026