check-scope

星标12

分支5

更新时间2026年4月29日 07:26

Verify a branch or PR stays inside PRD §3.1 v1.0 Committed Scope. Use when the user wants to check scope drift before opening a PR, when a contributor asks "is this in scope?", or before merging a non-trivial branch.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

来源

AndrewWayne

AndrewWayne/oh-my-warp

打开 GitHub 仓库查看创作者相关仓库

下载

Check Scope

Reports whether the current branch's changes stay inside the bright line drawn by PRD §3.1 v1.0 Committed Scope and the §13.x "Beyond v1" list.

Procedure

Determine the diff range. Default: main...HEAD. If the user passes $ARGUMENTS, treat it as the diff range (e.g. origin/main...HEAD, HEAD~5..HEAD).
Run git diff --name-only <range> and git diff --stat <range> to enumerate touched paths and rough magnitude.
Read PRD.md §3.1 and PRD.md §13.x to extract the committed-scope checklist and the deferred items.
For each touched path, classify as:
- In scope — maps to a §3.1 commitment (e.g. crates/omw-agent/ ↔ "CLI agent + tools + MCP + approval + audit + cost").
- Out of scope — maps to a §13.x Beyond-v1 item (e.g. anything in apps/native-shim/, crates/omw-tsnet-gateway/, Tier-2 provider crates).
- Infrastructural — .claude/, .github/, specs/, docs, CI config — always allowed.
- Unclear — flag for human review.
If any "Out of scope" or "Unclear" items exist, print a drift report with paths grouped by classification and a one-line rationale per group. If all "In scope" or "Infrastructural", print a clean confirmation.
Do NOT edit any files. This skill is read-only.

Output format

Scope check: <range>
  In scope (N files):       <one-liner>
  Out of scope (N files):   <list>  ← block / discuss
  Unclear (N files):        <list>  ← needs review
  Infrastructural (N files): <one-liner>

Verdict: PASS | DRIFT_DETECTED

Notes

A path counted as "Out of scope" is a scope-creep candidate, not necessarily wrong — the user may have made a deliberate Beyond v1 decision. Flag, don't reject.
If PRD.md §3.1 has changed since the branch diverged, surface that explicitly.

同仓库更多 Skills

同仓库

tech-debt-audit

AndrewWayne/oh-my-warp

Use when the user asks for a debt audit, codebase health check, architecture review, quality assessment of the entire omw repo, or a "what's rotten?" survey. Whole-repo scope, not diff-scoped (use /review for diffs, /simplify for tactical cleanup). Optional argument is a subtree (e.g. "crates/omw-server", "vendor/warp-stripped/app/src/ai_assistant"). User-invoked only — does not auto-trigger.

2026-05-0812

release-build-audit

AndrewWayne/oh-my-warp

Walk every Command::new() spawn site in omw_local code and cross-reference against the bundling steps in scripts/build-mac-dmg.sh (and the Windows equivalent). Use BEFORE running a release build script; this is the audit that would have caught the v0.0.3 keychain-helper and Node-on-PATH ship bugs. Argument is the target version.

2026-05-0712

byorc-protocol-check

AndrewWayne/oh-my-warp

Verify changes touching crates/omw-remote/ or specs/byorc-protocol.md against the BYORC protocol invariants. Use when reviewing a PR that modifies the remote daemon, the pairing flow, the signed-request validator, or the protocol spec itself. Read-only review aid.

2026-04-2912

refresh-cassette

AndrewWayne/oh-my-warp

Walk the provider cassette refresh ritual from specs/test-plan.md §4.4. Use when the user explicitly asks to refresh cassettes for a provider, or when CI flags cassette drift. Argument is the provider name (openai, anthropic, openai-compat, ollama). REFUSES to make real API calls unless OMW_CASSETTE_REFRESH=1.

2026-04-2912

release-checklist

AndrewWayne/oh-my-warp

Walk the pre-release checklist from specs/test-plan.md §7 for a target version. Use when the user is preparing a release (tagging v0.1, v0.2, ..., v1.0), wants to verify release readiness, or asks "are we ready to ship?". Argument is the target version.

2026-04-2912

spec-consistency

AndrewWayne/oh-my-warp

Cross-reference PRD ↔ TODO ↔ specs/*.md for drift, broken cross-links, and orphaned bullets. Use when the user asks to verify documentation consistency, after editing PRD or any spec, before publishing the repo, or when proof-reading.

2026-04-2912

name	check-scope
description	Verify a branch or PR stays inside PRD §3.1 v1.0 Committed Scope. Use when the user wants to check scope drift before opening a PR, when a contributor asks "is this in scope?", or before merging a non-trivial branch.
tools	Bash, Read, Grep

Check Scope

Reports whether the current branch's changes stay inside the bright line drawn by PRD §3.1 v1.0 Committed Scope and the §13.x "Beyond v1" list.

Procedure

Determine the diff range. Default: main...HEAD. If the user passes $ARGUMENTS, treat it as the diff range (e.g. origin/main...HEAD, HEAD~5..HEAD).
Run git diff --name-only <range> and git diff --stat <range> to enumerate touched paths and rough magnitude.
Read PRD.md §3.1 and PRD.md §13.x to extract the committed-scope checklist and the deferred items.
For each touched path, classify as:
- In scope — maps to a §3.1 commitment (e.g. crates/omw-agent/ ↔ "CLI agent + tools + MCP + approval + audit + cost").
- Out of scope — maps to a §13.x Beyond-v1 item (e.g. anything in apps/native-shim/, crates/omw-tsnet-gateway/, Tier-2 provider crates).
- Infrastructural — .claude/, .github/, specs/, docs, CI config — always allowed.
- Unclear — flag for human review.
If any "Out of scope" or "Unclear" items exist, print a drift report with paths grouped by classification and a one-line rationale per group. If all "In scope" or "Infrastructural", print a clean confirmation.
Do NOT edit any files. This skill is read-only.

Output format

Scope check: <range>
  In scope (N files):       <one-liner>
  Out of scope (N files):   <list>  ← block / discuss
  Unclear (N files):        <list>  ← needs review
  Infrastructural (N files): <one-liner>

Verdict: PASS | DRIFT_DETECTED

Notes

A path counted as "Out of scope" is a scope-creep candidate, not necessarily wrong — the user may have made a deliberate Beyond v1 decision. Flag, don't reject.
If PRD.md §3.1 has changed since the branch diverged, surface that explicitly.