跳到正文
cccskills
免费在 GitHub 公开

speckit-review-code

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

中文简介正在准备中。当前显示原文说明。

查看安装方法

包含的文件(1)

  • SKILL.md3.3 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

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.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

commit

免费

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.

中文简介正在准备中。当前显示原文说明。

opsmill/infrahub-ansible202026年10月16日 更新

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.

中文简介正在准备中。当前显示原文说明。

opsmill/infrahub-ansible202026年10月16日 更新

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.

中文简介正在准备中。当前显示原文说明。

opsmill/infrahub-ansible202026年10月16日 更新

Stress-tests a fuzzy or vague feature idea before any PRD, spec, or ticket is written. TRIGGER when: the user has a fuzzy feature idea — one or two paragraphs, vague on users / scope / success — and wants to harden it, or says "grill / stress-test / pressure-test this idea." DO NOT TRIGGER when: the idea is already turned into a spec or PRD; bug fixes or refactors; the idea is hardened and you are ready to write the PRD → creating-prd.

中文简介正在准备中。当前显示原文说明。

opsmill/infrahub-ansible202026年10月16日 更新

Watches an open pull request's CI until green and fixes failing checks. TRIGGER when: the user wants to watch a pull request's CI, babysit a PR until it goes green, or fix failing CI checks on an open PR. DO NOT TRIGGER when: opening the PR in the first place → pr; rebasing the branch onto its base → rebase.

中文简介正在准备中。当前显示原文说明。

opsmill/infrahub-ansible202026年10月16日 更新

pr

免费

Opens a pull request, publishing the current branch as a PR. TRIGGER when: the user wants to open a pull request, publish the current branch as a PR, or take the current work through to an open PR. DO NOT TRIGGER when: only committing changes → commit; babysitting CI after the PR is already open → monitoring-pull-requests.

中文简介正在准备中。当前显示原文说明。

opsmill/infrahub-ansible202026年10月16日 更新

查看 opsmill 的全部技能

报告此技能的问题