radical-options

Compares current code abstractions against first-principles redesigns before editing.

4.8k|376|Updated Mar 16, 2023
One-click install
npx skills add https://github.com/EpicenterHQ/epicenter --skill radical-options
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: radical-options
Source: https://github.com/EpicenterHQ/epicenter/tree/main/.agents/skills/radical-options
Command: npx skills add https://github.com/EpicenterHQ/epicenter --skill radical-options

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

When a fix starts feeling like a band-aid, this Skill forces a structured comparison between the current abstraction and a clean-slate redesign, so you stop layering wrappers on a broken shape and decide deliberately whether to refactor locally or redesign the surface.

Core Features & Use Cases

  • Structured Decision Ritual: A six-part template (current path, friction, radical option, deletion prize, user loss, decision) that makes redesign trade-offs explicit before any code changes.
  • Mental Inlining Pass: Systematically evaluates whether helpers, wrappers, and adapters earn their existence by owning invariants, isolating unsafe input, or simplifying multiple callers.
  • Asymmetric Option Check: Identifies single refusals that delete entire code families such as adapters, flags, defensive checks, and migration branches.
  • Use Case: You are about to add a third boolean flag to track workspace teardown state. The Skill prompts you to go up one level, redesign teardown as a single owning transition, and delete all downstream readiness checks.

Quick Start

Before making this edit, run the radical options ritual to compare the current abstraction against a from-scratch design and tell me which to take.

Frequently Asked Questions about radical-options

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide between refactoring and redesigning a code abstraction?

Use a structured comparison: write out the current path, the friction it causes, the radical redesign option, what code it deletes, and what users lose. Choose the redesign when the abstraction is the main source of complexity and the product behavior survives intact.

How to tell if a wrapper or helper function should be inlined?

Mentally inline the helper into its callers and ask what it adds beyond its name. Keep it only if it owns a real invariant, isolates unsafe input, names non-obvious domain behavior, or simplifies multiple callers the same way; otherwise inline or redesign above it.

When should I keep the current design instead of taking the radical option?

Keep the current shape when the abstraction owns a real boundary, the weirdness comes from an external API or runtime constraint, the redesign deletes behavior users rely on, or migration cost exceeds the explanation win.

What is an asymmetric win in software design?

An asymmetric win is one refusal, such as dropping a legacy mode or fallback, that deletes an entire code family including adapters, unions, flags, tests, and defensive checks. Take it when the core product behavior survives and the deletion prize is large.

Why do local fixes keep growing in complexity?

Local fixes grow when the code compensates for a missing higher-level invariant, such as callers observing a half-torn-down workspace. Going up one level and making the lifecycle a single owning transition removes the downstream checks entirely.