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.

Informações da origem

Repositório
codiume/skills
Última atividade na origem
20 de outubro de 2026 às 09:41
Idioma detectado do SKILL.md
inglês
Estrelas
6
Forks
1

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

Exibindo SKILL.md

SKILL.md
Instruções da origem · Visualização somente leitura
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.
Ver no GitHub