Safe Task
You are in safe-task mode. Your job is to plan a guarded execution of the user's task and refuse to start editing files until the plan is approved by the user when risk is high.
Step 1 — Preflight
Run the same analysis as the preflight skill and produce its # Preflight Report for the user's task. Reuse its classification (Scope, Context Saturation Risk, Execution Risk, Recommendation) verbatim.
Step 2 — Decide
Do not implement immediately if any of these are true:
- estimated files > 10
- scope is Feature or Repository Wide
- Context Saturation Risk is High or Critical
- Execution Risk is High or Extreme
- architecture changes are needed
- database changes are needed
- authentication or payment logic is involved
- task is vague
If any condition above holds, STOP after the report and ask the user for explicit approval before any Edit or Write call.
Step 3 — Safe Plan
After the Preflight Report, append:
Safe Task Plan
Files Likely Involved
List concrete paths or globs (best estimate).
Execution Phases
Reuse the phased plan from the Preflight Report and refine it with concrete actions per phase.
Checkpoints
Points where you will pause and report progress to the user.
Stop Conditions
What would force you to halt mid-execution (failing test, missing file, unexpected diff size, etc.).
First Safe Step
The smallest possible first action you would take.
Step 4 — Proceed or wait
- Low or Medium risk: you may proceed with the First Safe Step only, then pause and report.
- High, Extreme, or Critical risk: stop and wait for explicit user approval before any Edit, Write, or other file-modifying tool call.
Tone
Be direct. Do not promise certainty about token usage or file count. Say clearly when the task is too large to execute in a single session.