About fortify
fortify is an agent skill for adding failure handling to workflows that call external services. It outlines validation, retries, fallbacks, circuit breakers, timeouts, and an audit checklist.
Key features
- 01Input validation and size limits
- 02Retries with exponential backoff
- 03Fallback responses and escalation
- 04Circuit breakers and timeouts
- 05Fortification audit checklist
Use cases
- 01Harden workflows that call external APIs
- 02Define behavior after transient failures
- 03Review error handling across workflow components
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ sharpdeveye/ maestro --skill fortifyAfter installing, type/fortifyin Claude Code to confirm it loaded.
Details
From the project READMEMANDATORY PREPARATION
Invoke /agent-workflow — it contains workflow principles, anti-patterns, and the Context Gathering Protocol. Follow the protocol before proceeding — if no workflow context exists yet, you MUST run /teach-maestro first. Consult the guardrails-safety reference in the agent-workflow skill for defense-in-depth patterns and error boundary design.
Make the workflow resilient. Every external call will fail eventually — model APIs, tools, databases, third-party services. Fortify ensures the workflow handles failure gracefully.
Fortification Layers
Layer 1: Input Validation
- Validate all inputs before processing
- Return clear error messages for invalid input
- Set size limits on all input fields
Layer 2: Retry with Backoff For transient failures (network errors, rate limits, timeouts):
Retry strategy:
max_retries: 3
initial_delay: 1s
backoff_multiplier: 2
max_delay: 30s
retryable_errors: [429, 500, 502, 503, 504, TIMEOUT, CONNECTION_ERROR]
non_retryable_errors: [400, 401, 403, 404]
Layer 3: Fallback Responses When retries are exhausted:
- Use a cached previous response (if applicable)
- Use a simpler/cheaper model as fallback
- Return a graceful degradation response
- Escalate to human review
Layer 4: Circuit Breakers When a service is consistently failing:
Circuit breaker:
failure_threshold: 5 consecutive failures
state: CLOSED → OPEN (after threshold) → HALF_OPEN (after cooldown)
cooldown: 60 seconds
half_open_max_requests: 1
Layer 5: Timeout Controls Every external call needs a timeout:
- Model API calls: 30-120s depending on task
- Tool executions: 10-60s depending on tool
- Database queries: 5-15s
- Third-party APIs: 10-30s
Fortification Audit
For each component, verify:
- Input validation present
- Retry logic for transient failures
- Fallback for when retries fail
- Timeout set
- Error logged with context
- User gets a meaningful error (not a stack trace)
Recommended Next Step
After fortification, run /evaluate to verify error handling works under realistic failure scenarios.
NEVER:
- Retry non-retryable errors (authentication failures, validation errors)
- Retry without backoff (you'll make the problem worse)
- Swallow errors silently (log and handle, don't ignore)
- Set infinite timeouts (they'll hang forever)
- Skip the fallback (retries exhausted with no fallback = user sees an error)