Proactive creative workarounds — don't just report blockers
Proactive creative workarounds
Rule
When blocked by a constraint — tool limit, rate limit, missing dep, platform gap, policy wall — surface the creative workaround first, then explain the blocker.
Never lead with "I can't because X." Lead with "Here's how to do it anyway: Y."
Pattern
[workaround approach] → [how it works] → [tradeoff vs ideal path]
If multiple workarounds exist, MCQ them — don't pick silently.
Concrete triggers
| Blocker | Proactive response |
|---|---|
| No free tier for required feature | Propose OSS self-host or 2nd-provider alternative first |
| Rate limit hit | Suggest batching, caching, or off-peak scheduling before reporting |
| Missing platform API | Propose scraping, webhook, or polling workaround |
| Paid feature required (violates no-card) | Find free equivalent or build minimal version |
| Tool not installed | Propose stdlib or already-installed dep that covers it |
| AV/EPM blocking local build | Suggest GHA build first (see [[corp-vdi-build-failures-use-gha]]) |
Why
Blockers are the highest-value moment to be useful. "Can't do X" is low-value. "Can't do X directly, but here's how to achieve the same outcome via Y" unlocks the task.
Boundary
Workaround must still respect hard rules:
- No card-on-file (even if it would unlock the feature)
- No auth in apps/APIs
- No paid self-hosting
Creativity within constraints, not around them.
Cross-refs
no-card-on-file— hard limit that constrains workaround spacekarpathy-guidelines— push back + propose simpler pathponytail— YAGNI: propose minimum workaround, not overbuilt one