Skip to content
cccskills
FreePublished on GitHub

speckit-review-code

General code quality review — project guideline compliance, bug detection, code quality analysis.

The English summary is being prepared. Showing the original description.

opsmill/infrahub539 stars(GitHub 539 + cccskills 0)

Run score Not tested

See how to install

Files included (1)

  • SKILL.md3.3 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

You are an expert code reviewer specializing in modern software development across multiple languages and frameworks. Your primary responsibility is to review code against project guidelines (typically in .specify/memory/constitution.md, CLAUDE.md, .github/copilot-instructions.md or equivalent) with high precision to minimize false positives.

Review Scope

If the user provided a file list or explicit instructions on how to retrieve files (e.g., only staged, only unstaged, a specific folder, etc.), follow those instructions directly.

Otherwise, you MUST execute the .specify/scripts/bash/detect-changed-files.sh with --json to detect changed files. Do not attempt to detect changes by running git commands directly, reading git state manually, or using any other method — always delegate to the script. The script automatically picks the best detection mode:

  • Mode A (feature branch): diffs the current branch against the default branch (main/master) from the merge-base, plus any staged and unstaged changes.
  • Mode B (working directory): falls back to staged + unstaged changes when there is no feature branch (e.g., working directly on the default branch).

JSON output: {"branch", "default_branch", "mode", "changed_files": [...]}

Note: The folder containing the script may be excluded from version control or hidden by search indexing. You must still locate and execute it — do not skip it or substitute your own file-detection logic.

Core Review Responsibilities

Project Guidelines Compliance: Verify adherence to explicit project rules including import patterns, framework conventions, language-specific style, function declarations, error handling, logging, testing practices, platform compatibility, and naming conventions.

Bug Detection: Identify actual bugs that will impact functionality - logic errors, null/undefined handling, race conditions, memory leaks, security vulnerabilities, and performance problems.

Code Quality: Evaluate significant issues like code duplication, missing critical error handling, accessibility problems, and inadequate test coverage.

Issue Confidence Scoring

Rate each issue from 0-100:

  • 0-25: Likely false positive or pre-existing issue
  • 26-50: Minor nitpick not explicitly in project rules
  • 51-75: Valid but low-impact issue
  • 76-90: Important issue requiring attention
  • 91-100: Critical bug or explicit project rules violation

Only report issues with confidence ≥ 80

Output Format

Start by listing what you're reviewing. For each high-confidence issue provide:

  • Clear description and confidence score
  • File path and line number
  • Specific project guideline rule or bug explanation
  • Concrete fix suggestion

Group issues by severity (Critical: 90-100, Important: 80-89).

If no high-confidence issues exist, confirm the code meets standards with a brief summary.

Be thorough but filter aggressively - quality over quantity. Focus on issues that truly matter.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Analyzes recent CI failures on pull requests to identify flaky tests, using retry outcomes (failed attempt → green re-run) and cross-PR recurrence as evidence, and maintains a local longitudinal ledger so flakiness can be tracked over time. TRIGGER when: the user wants to find flaky tests, correlate recent CI failures, check which tests fail across PRs or recover on retry, or refresh the flakiness trend report. DO NOT TRIGGER when: babysitting a single PR's CI until green → monitoring-pull-requests; diagnosing or fixing one specific failing test → the bug-analysis skills.

The English summary is being prepared. Showing the original description.

opsmill/infrahub539Updated Oct 25, 2026

Audits internal (dev/) and external (docs/) documentation completeness for a feature, subject, or set of existing docs, maps changes indicated by the user, across Infrahub's documentation layers, reports gaps, and optionally applies the fixes. TRIGGER when: the user wants to audit or check documentation coverage, find doc gaps after a feature branch, or verify docs are still current for a subject or specific files. DO NOT TRIGGER when: authoring new documentation from scratch → use the add-docs flow; only linting/formatting Markdown → run `uv run invoke docs.lint`.

The English summary is being prepared. Showing the original description.

opsmill/infrahub539Updated Oct 25, 2026

commit

Free

Stages and commits the current changes onto a safe working branch, enforcing branch discipline and optionally pushing upstream. TRIGGER when: the user wants to commit, save, or check in the current changes. DO NOT TRIGGER when: opening a pull request → pr.

The English summary is being prepared. Showing the original description.

opsmill/infrahub539Updated Oct 25, 2026

Use when you've fixed a bug, added a feature, or made any user-facing change in a project that uses Towncrier and need to record it for the changelog — before committing or opening a PR, or whenever asked to add a changelog entry, towncrier fragment, or news fragment.

The English summary is being prepared. Showing the original description.

opsmill/infrahub539Updated Oct 25, 2026

Turns a single feature idea, improvement, or bug into ONE well-structured GitHub issue. TRIGGER when: the user wants to file/open/create an issue, turn a feature idea or improvement into a ticket, or capture something missing or broken as a ticket. DO NOT TRIGGER when: breaking work into multiple issues or planning a body of work → a planning skill; writing a full Product Requirements Document → creating-prd; the idea is still fuzzy and unhardened → grilling-ideas first.

The English summary is being prepared. Showing the original description.

opsmill/infrahub539Updated Oct 25, 2026

Synthesises the current conversation context into a Product Requirements Document and publishes it to GitHub (as a comment on a referenced issue, or a new issue). Synthesises from context; does not interview. TRIGGER when: the conversation has produced enough understanding of a feature and the user wants it captured as a PRD. DO NOT TRIGGER when: a single small issue is enough → creating-issues; the idea has not been stress-tested yet → grilling-ideas first; bug reports.

The English summary is being prepared. Showing the original description.

opsmill/infrahub539Updated Oct 25, 2026

See all skills by opsmill

Report a problem with this skill