Skip to main content

preflight

Pre-production code review against a user-chosen healthy point. Use when asked to review a branch before merge, whether it's safe to ship, or what blocks a PR.

ソース情報

リポジトリ
codiume/skills
ソースの最終更新活動
2026年10月20日 09:41
検出された SKILL.md の言語
英語
スター
6
フォーク
1

インストール方法

デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。

ソースファイルを確認

インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。

SKILL.md を表示中

SKILL.md
ソースの指示 · 読み取り専用プレビュー
name
preflight
description
Pre-production code review against a user-chosen healthy point. Use when asked to review a branch before merge, whether it's safe to ship, or what blocks a PR.
disable-model-invocation
true
parameters
{"healthy_point":{"type":"string","required":false,"default":"main","description":"A Git commit SHA, branch, tag, or ref identifying a known healthy state of the application."}}
# Pre-production code review Find every reason this branch should NOT ship. No verdict until each one is resolved. ## Phase 1: Pin the healthy point The `healthy_point` parameter identifies the known healthy state to compare against. It can be a commit SHA, branch, tag, `main`, `HEAD~5`, or any other valid Git ref. Before going further: 1. Confirm it resolves: `git rev-parse {{healthy_point}}` 2. Write the diff command once and reuse it everywhere: `git diff {{healthy_point}}...HEAD` Three dots, so Git compares against the merge-base. 3. Confirm the diff is non-empty. A bad ref or empty diff should fail here, not mid-review. ## Phase 2: Read the diff and its context 1. Run the captured diff command for the full changeset. 2. For every changed file, read enough surrounding code to understand the original contract and what changed. 3. Check related code for auth, data models, API contracts, config, migrations, shared utilities, error handling, and logging. 4. Answer your own questions from the codebase. Ask the user only what the code can't tell you. ## Phase 3: Classify the risks Classify each change, ordered by severity: | Label | Meaning | | ------------- | ------------------------------------------------------- | | 🔴 Breaking | Changes observable behavior or an API contract | | 🟠 Conflict | Contradicts the system spec or codebase conventions | | 🟡 Incomplete | Happy path only, TODOs, unhandled errors, dead branches | | 🟢 Safe | No effect outside its module | Post the findings list before moving on: label, `file:line`, one-line reason. Summarize 🟢 changes as a count, not a list. ## Phase 4: Adversarial Interview For every non-🟢 finding and every implicit decision behind it: - Ask one question at a time, with your recommended answer. Wait for the reply. - Resolve dependent questions in order. - Continue until no implicit assumptions remain. A finding is resolved only when it is either: - **Fixed** — you re-read the code and confirmed the fix is on the branch, or - **Accepted** — the user explicitly confirmed it is intended, with a reason. ## Phase 5: Decide whether it ships (Go / No-Go) Only once every finding is resolved. - ✅ **SHIP** — every finding is 🟢, fixed, or accepted. List accepted risks in one line each. - 🚫 **DO NOT SHIP** — numbered list of each blocking action, with `file:line` and the relevant snippet.
GitHubで見る