Classify risk before launching Claude
Assess task risk before writing the prompt or starting Claude. This defines an acceptable working mode and the possible scale of an error.
Do not combine task description, verification plan, risk classification, and capability envelope. A task spec says what to do; an envelope says what Claude may do within that task.
| Level | Typical areas | Working mode |
|---|---|---|
| Low | Documentation or small local refactor with tests | Bounded editing in a defined area |
| Review required | Code, configuration, dependencies, and API contracts | Read-only analysis and plan, then controlled changes |
| High | Production, database, secrets, shared infrastructure, irreversible actions | Plan, checklist, and materials; a person executes |
Task capability envelope
- Risk level and escalation criteria.
- Allowed tools, files, directories, and commands.
- Required approvals and responsible people.
- Required checks: tests, lint, build, and contract checks.
- Forbidden areas and actions.
- Rollback plan and stop conditions.
Risk: review-required
Allowed: read support/**, edit one service, run focused tests
Ask before: files outside support/** or config changes
Deny: payments/**, migrations/**, .env*, force push
Required: regression test, diff review, rollback note
Stop: if public API or production access is involvedRisk changes with context
Text format does not mean low impact. Configuration can change access, checkout, or service compatibility. If work enters production, API, or database scope, reclassify the task and update the envelope.
| Task | Classification |
|---|---|
| Change a README start command | Low when practically verified |
| Fix refund-request sorting | Review level with regression evidence |
| Change a public refund API | Review level because the contract may break |
| Manual SQL in a production database | High risk |
| Rotate a production key | High risk; Claude prepares a plan only |
Working mode by risk level
- For low risk, limit the file or directory and require a diff.
- For review-level work, start with read-only discovery and a short plan.
- After human confirmation, perform one narrow step and its checks.
- For high risk, allow analysis, a checklist, dependencies, and rollback planning only.
- Get a separate human decision before an external or irreversible action.
Evidence before expanding capabilities
Broader access does not replace result verification. For each permission, state the need it covers, the evidence that justifies it, and how work can stop.
A practical baseline is read-only analysis, the smallest change, targeted verification, and review of the actual diff.
- Do not grant write access “just in case”.
- A successful prompt is not correctness evidence.
- Green tests do not authorize high-risk operations.
- Stop when task boundaries become wider than the envelope.
Canonical lesson source · JavaRush
Open JavaRush material