跳到正文
cccskills
免费在 GitHub 公开中文介绍

scope-creep-detector

将 Git 差异与修改目的对照,找出可能无关的文件、新增依赖等范围扩张信号,给出保留、拆分或说明必要性的判断,并整理拆分方案。

原文查看原文说明

Analyzes git diffs against a stated intent to detect scope creep, unrelated files, broad pull requests, changes that grew beyond a fix, dependency additions, public API renames, config or CI edits, oversized hunks, and formatting-only files. Use when the user asks whether a change grew beyond the fix, a PR is too broad, or what unrelated stuff they touched, and wants keep, split, or justify guidance. Operates locally and offline.

AI 评分90分/ 100查看安装方法

适用场景

  • 创建拉取请求前检查修改范围
  • 发现混入缺陷修复的额外修改
  • 检查暂存修改是否范围过大
  • 规划混合修改的拆分方式

中文介绍

功能

scope-creep-detector 将 Git 差异与修改目的对照,检查工作范围是否扩大。它会找出与目的关联较弱的文件、新增依赖、公共 API 重命名、配置或 CI 编辑、过大的修改区块,以及仅涉及格式调整的文件。根据这些信号,整理出保留、拆成独立修改或说明必要性的判断。

适用场景

适合原本的小修复涉及了许多文件,或提交拉取请求前需要核对范围时使用。可以检查工作区修改、已暂存修改、相对于基准分支的差异,也可以分析已保存的差异文件。若多种修改混在一起,可获得标明相关文件或修改区块的拆分方案。

使用示例

  • “请检查这份差异是否超出了修复解析器缺陷的目的。”
  • “请从已暂存修改中列出适合拆成另一个拉取请求的候选项。”
  • “请为评审整理为什么需要包含这项配置修改。”

注意事项

使用 Python 3 脚本在本地运行,不进行网络通信,也不修改工作区。检测会参考文件名与目的描述中的词语是否匹配,因此不能仅凭结果断定某项修改无关。不评估修改的正确性、安全性或测试质量。

本介绍由 AI(OpenAI Codex)根据公开的 SKILL.md 撰写。准确的规格请查看下方原文。

客观评估

AI 仅根据 SKILL.md 的内容,从 4 个方面进行了评估。星标数和热度不计入评估。

指令清晰度能否看出何时使用、做什么
A良好明确比较差异与修改目的,并给出保留、拆分或说明必要性的判断。
步骤具体性步骤、输入输出和示例是否具体
A良好提供 scope_creep.py 命令示例、JSON 字段定义和六部分报告格式。
安全性发送数据、删除文件、执行命令等是否有说明
A良好明确不联网或修改工作区,并要求拆分、还原、暂存或提交前确认。
安装难易度所需工具和 API 密钥是否少且有说明
B部分不足示例使用 python3 和 Git,但没有安装步骤。

总分按每项 A=25 分、B=15 分、C=5 分相加。 由 AI(OpenAI Codex)于 2026年10月20日 评估。仅供参考,安装前请同时查看原文。

如果您认为评估有误,请申请复核

请写明哪一项有误以及原因。无需登录。我们会对照 SKILL.md 重新评估,并在此处更新结果。

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

包含的文件(4)

  • SKILL.md5.0 KB
  • README.md1.2 KB
  • references/scope-signals.md3.2 KB
  • scripts/scope_creep.py18.2 KB

SKILL.md(原文)

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

Scope Creep Detector

A one-line fix should not require a reviewer to reverse-engineer fourteen files across three subsystems. This skill compares a git diff with its stated intent, surfaces scope signals, and turns them into keep, split, or justify decisions.

Everything runs locally. The script makes no network calls and does not change the working tree, index, commits, or branches.

When to use

  • Before opening a pull request whose diff may have grown beyond its intent
  • When a bug fix touches unexpected files or subsystems
  • When the user asks whether staged changes are too broad
  • When a diff includes dependency, public API, config, CI, or build changes
  • When the user wants a concrete split plan for a mixed change

When not to use

  • Formatting code, running a linter, or writing a commit message
  • Reviewing correctness, security, or test quality inside an agreed scope
  • Measuring historical project growth across many commits
  • Editing or reverting files without the user's approval

Establish the intent

Use the user's one-line intent when available. Keep it concrete, such as fix null dereference in parser or add retry limit to webhook delivery.

If no intent was given, the script falls back to the current branch name. If that name is generic, detached, or unrelated to the work, ask for one line of intent before treating relatedness as meaningful.

Run the classifier

Run from this skill directory and point --repo at the target repository.

Working tree diff:

python3 scripts/scope_creep.py --repo /path/to/repo \
  --intent "fix null dereference in parser" --json

Staged diff:

python3 scripts/scope_creep.py --repo /path/to/repo --staged \
  --intent "fix null dereference in parser" --json

Branch diff against a merge base:

python3 scripts/scope_creep.py --repo /path/to/repo --base main \
  --intent "fix null dereference in parser" --json

Saved diff or stdin:

python3 scripts/scope_creep.py --diff change.diff --intent "parser fix" --json
git diff --staged | python3 scripts/scope_creep.py --diff - \
  --intent "parser fix" --json

Use --hunk-threshold only when the repository has a documented reason to change the default churn threshold. Do not tune the threshold merely to make a warning disappear.

Interpret the JSON

Read references/scope-signals.md before making a recommendation. Treat the classifier as triage evidence, not proof of authorial intent.

  • in_scope: file paths with at least one intent/path keyword overlap
  • likely_creep: paths without overlap, with the reason and detected signals
  • new_deps: dependencies introduced in supported manifest formats
  • api_renames: nearby removed and added public function or class declarations
  • config_edits: CI, container, build, YAML, and TOML changes
  • stats: churn, subsystem counts, oversized hunks, and formatting-only files

Empty arrays are evidence too. Say that no signal was detected, not that the diff is guaranteed to be in scope.

Recommend keep, split, or justify

Give every item in likely_creep one disposition:

  1. Keep when the path is necessary for the stated intent and the connection is direct. Explain the connection in one sentence.
  2. Split when it can land independently, belongs to another subsystem, or introduces a dependency, API rename, config edit, or large hunk that is not required for the intent. Name the files or hunks for the follow-up change.
  3. Justify when a cross-cutting edit cannot be separated safely. State the invariant or build constraint that requires it and call out reviewer risk.

Prefer split when evidence is ambiguous. Never claim that a zero overlap score proves a file is unrelated. Path vocabulary is a cheap, deterministic proxy.

Write the scope report

Use this compact structure:

  1. Intent and diff source
  2. Files and subsystems touched, with total additions and deletions
  3. In-scope changes
  4. Likely creep with signal evidence
  5. Keep, split, or justify table
  6. Proposed follow-up grouping, if any

Name file paths and hunk headers. For an oversized mixed hunk, explain that the script cannot split it automatically and describe the smallest coherent edit. Ask before applying any split, revert, staging, or commit operation.

Files

  • scripts/scope_creep.py: deterministic unified-diff parser and classifier
  • references/scope-signals.md: signal definitions, thresholds, and limits

评价

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

评论

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

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

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

0 / 1000 字

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

同一仓库的技能

advisor-orchestrator-worker

免费有简介AI 评分 80分

将大型调研或生成任务分配给多个AI模型,完成计划评审、并行执行、成果验证与整合,并记录各负责角色的进度和重试情况。

  • 并行调研多个竞争对手
  • 分担大型内容生成任务
  • 让顾问评审计划或草稿
Shubhamsaboo/awesome-llm-apps14.3万2026年10月23日 更新

chatgpt-app-builder

免费有简介AI 评分 70分

指导开发可在ChatGPT内操作的应用,涵盖功能规划、React组件及状态共享的实现。该技能已弃用,并指引用户转向后续技能。

  • 梳理ChatGPT应用功能
  • 实现与服务器联动的界面
  • 与ChatGPT共享界面状态
Shubhamsaboo/awesome-llm-apps14.3万2026年10月23日 更新

commit-archaeologist

免费有简介AI 评分 100分

通过本地Git历史调查代码的引入背景与修改意图,追溯最初提交及反复同时修改的文件,整理改动前需要检查的事项。

  • 了解陌生函数存在的原因
  • 改动前检查历史约束
  • 调查临时变通方案为何仍被保留
Shubhamsaboo/awesome-llm-apps14.3万2026年10月23日 更新

dependency-doctor

免费有简介AI 评分 100分

检查Python和JavaScript依赖文件中的版本约束缺失、重复条目、固定版本冲突及过时兼容包,用易懂的语言说明影响并提出便于核对的修改建议。

  • 安装失败深入排查前的初步检查
  • 检查过时的Python兼容包
  • 检查重复条目和固定版本冲突
Shubhamsaboo/awesome-llm-apps14.3万2026年10月23日 更新

first-reader

免费有简介AI 评分 100分

从目标读者的角度试读发布前的文稿,检查是否愿意打开、在哪里失去兴趣,以及读后记住什么。它报告模拟读者的反应,不改写文章。

  • 检查帖子是否会被读完
  • 找出读者停止阅读的位置
  • 比较修改前后的读者反应
Shubhamsaboo/awesome-llm-apps14.3万2026年10月23日 更新

mcp-apps-builder

免费有简介AI 评分 70分

使用mcp-use设计和实现MCP服务器,让AI调用外部操作与数据。指南涵盖认证、交互界面、错误处理及部署,并引导查阅各功能的配套资料。

  • 新建MCP服务器
  • 添加操作、数据及可复用提示词
  • 构建浏览与选择数据的React界面
Shubhamsaboo/awesome-llm-apps14.3万2026年10月23日 更新

查看 Shubhamsaboo 的全部技能

报告此技能的问题