| name | fallback-discipline |
| description | Control error handling, defaults, retries, compatibility paths, and fallback behavior. Use before adding catch blocks, defaults, shims, optional values, retries, or graceful degradation. |
Fallback Discipline
Use this skill whenever the implementation may hide, soften, retry, or default
around a failure.
Read templates/fallback-discipline.md before writing fallback code.
Workflow
- Identify the failure or unknown state.
- Decide whether continuing is required by the requested behavior or existing
product contract.
- If continuing is not required, surface the failure explicitly.
- If a fallback is required, make it narrow and observable.
- Add or update a test for the fallback path.
- Report how the failure is surfaced to callers, logs, UI, metrics, or tests.
Forbidden By Default
- Empty catches.
- Catch-all exception handling around unrelated work.
- Returning empty values or success to hide failure.
- Silent retries.
- Unknown states treated as valid.
- Fake backward compatibility for callers that do not exist.
- Optional or broad types that erase invariants.
Output
Fallback Decision
- failure handled:
- continue or fail:
- surfacing:
- test:
- review needed:
