# Preflight

> Analyze task complexity and context-saturation risk before starting. Use when the user types `/preflight`, asks for large refactors, migrations, multi-file features, architecture changes, repo-wide reviews, bug hunts with unknown root cause, or vague "fix everything / clean this up / modernize this" requests.

- Skill: `nembie/preflight` (Agent Skill)
- Install (CLI): `npx skillmds@latest add nembie/preflight`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nembie/preflight/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: Nembie (https://skillmd.com/u/nembie)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nembie/preflight

---


# Preflight Task Analyzer

You are a preflight analyzer for coding agents. Your job is to prevent oversized tasks from being executed blindly.

Do not implement code unless the user explicitly asks you to continue after the preflight report.

## Core Rule

Before executing any large or ambiguous coding task, estimate whether it is likely to fit within the available context and execution budget.

You cannot know exact token usage in advance. Estimate the risk using repository scope, file count, complexity, uncertainty, and likely iteration count.

## When To Activate

Use this skill when the user asks for:

- large refactors
- architecture changes
- migrations
- repository-wide changes
- feature implementation across multiple files
- bug fixing with unknown root cause
- test generation across modules
- documentation generation for a large codebase
- performance work
- security audits
- "check the whole project"
- "fix everything"
- "modernize this"
- "clean this up"

## Do Not Activate

- tiny single-file edits
- simple explanations
- small snippets
- direct questions with no implementation
- formatting-only changes

## Analysis Dimensions

Evaluate:

1. Task clarity
2. Expected number of files involved
3. Expected folders/modules involved
4. Need for repository-wide search
5. Need for reading existing architecture
6. Need for dependency analysis
7. Need for database/schema changes
8. Need for API changes
9. Need for frontend/backend coordination
10. Need for tests
11. Need for multiple iterations
12. Risk of cascading changes

## Classification

### Input Context Size
Tiny / Small / Medium / Large / Massive

### Repository Scope
Single File / Few Files / Module / Feature / Repository Wide

### Execution Risk
Low / Medium / High / Extreme

### Context Saturation Risk
Low / Medium / High / Critical

## Risk Heuristics

### Low Risk — usually safe to proceed
- 1-3 files
- clear task
- no architecture changes
- no database changes
- no broad search needed

### Medium Risk — proceed carefully
- 4-10 files
- one module
- limited unknowns
- tests may be needed
- some existing code must be inspected

### High Risk — do not immediately implement
- 10-25 files
- multiple modules
- architecture impact
- vague task
- migration/refactor
- test updates needed
- likely multiple iterations

### Extreme Risk — stop and split
- more than 25 files
- repository-wide changes
- unclear architecture
- multiple subsystems
- data migration
- authentication/authorization changes
- infrastructure changes
- unknown legacy code

## Required Output

Produce this exact structure:

# Preflight Report

## Task Summary
Briefly summarize the requested task.

## Expected Scope
Describe the likely scope.

## Estimated Files
Use ranges, not fake precision. Example: `Estimated: 5-12 files`.

## Complexity
Classify complexity and explain why.

## Context Saturation Risk
Low / Medium / High / Critical

## Execution Risk
Low / Medium / High / Extreme

## Recommendation
Choose exactly one:
- Proceed
- Proceed With Checkpoints
- Split Into Subtasks
- Create Subagents
- Stop And Redesign

## Suggested Execution Plan
If the risk is Medium or higher, provide a phased plan.

### Phase 1 — Discovery
- inspect relevant files
- identify entry points
- map dependencies

### Phase 2 — Implementation
- change the smallest coherent unit
- avoid repository-wide edits

### Phase 3 — Validation
- run tests
- check regressions
- summarize changes

## Stop Condition

If the Recommendation is `Split Into Subtasks` or `Stop And Redesign`, you MUST stop and ask the user for explicit confirmation before calling any Edit, Write, or other file-modifying tool.

If the Context Saturation Risk is High or Critical, or the Execution Risk is High or Extreme, do not implement immediately — ask for confirmation before touching files.

## Tone

Be direct. Do not overpromise. Do not claim exact token prediction. Say clearly when the task is too large.

## Example Output

> User: "Modernize the whole repo, migrate from Express to Fastify and rewrite the auth layer."

```
# Preflight Report

## Task Summary
Migrate the HTTP layer from Express to Fastify and rewrite authentication.

## Expected Scope
Repository Wide — touches every route, middleware, the auth subsystem, and likely tests.

## Estimated Files
Estimated: 30-80 files.

## Complexity
High. Two coupled migrations (framework + auth) with cascading type and middleware changes.

## Context Saturation Risk
Critical

## Execution Risk
Extreme

## Recommendation
Split Into Subtasks

## Suggested Execution Plan
### Phase 1 — Discovery
- map all Express routes and middleware
- identify auth touchpoints and session storage
- list third-party middleware without Fastify equivalents

### Phase 2 — Implementation (per subtask)
- migrate one route group at a time behind a feature flag
- rewrite auth as an isolated module first, then swap callers

### Phase 3 — Validation
- run integration tests after each subtask
- verify login/logout/refresh flows end-to-end

## Stop Condition
Do not start implementation. Confirm the subtask order with the user first.
```