over-justify

Audits abstractions and designs for justification beyond the concrete implementations they replace.

9|Updated Mar 4, 2026
One-click install
npx skills add https://github.com/timcsy/semorphe --skill over-justify-timcsy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: over-justify
Source: https://github.com/timcsy/semorphe/tree/main/knowledge/skills/over-justify
Command: npx skills add https://github.com/timcsy/semorphe --skill over-justify-timcsy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams and AI assistants routinely produce abstractions, layers, theories, and design patterns that look elegant but add no explanatory or predictive value over the concrete code they replace. This Skill provides a single decision rule to detect over-abstraction and over-engineering before they calcify into the codebase or knowledge base. ## Core Features & Use Cases - Justification Test: For each abstraction, identify the concrete thing it replaces, then check whether it explains more, predicts more, or compresses (fewer assumptions, same predictions). - Three-Way Verdict: Classify each audited item as keep (earns its place), cut (pure restatement or decoration), or downgrade to an explicitly labeled unverified bet locked as a draft. - Dual-Layer Application: The same rule applies to conceptual/theoretical abstractions and to code-level over-design, complementing code review and simplification passes. - Use Case: While reviewing a design document proposing a new architectural layer, run the audit and receive a per-item verdict such as "cut — restates the existing module in heavier vocabulary" with a one-line reason. ## Quick Start Ask the AI to run the over-justify audit on the abstraction or design draft you just proposed and return a keep, cut, or bet verdict with a one-line reason for each item.

Frequently Asked Questions about over-justify

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

FAQPage Schema
How do I detect over-engineering in a design proposal?

Apply a justification test to each proposed abstraction: name the concrete implementation it replaces, then state what it explains or predicts beyond that implementation. If it does neither and does not compress assumptions, classify it as decoration and cut it or mark it as an unverified bet.

What criteria justify keeping an abstraction in code or theory?

An abstraction earns its place in two ways: it explains or predicts more than the concrete thing it replaces, or it compresses by making fewer assumptions with equal predictive power. Translating the same idea into heavier vocabulary counts as anti-compression, not compression.

How is this different from code review or simplification passes?

Code review catches bugs and simplification cleans up implementation, while this audit operates upstream on value judgment: whether an abstraction or layer should exist at all. It is designed to run alongside those passes, not replace them.

Should future-oriented designs be deleted when they fail the test?

No. Designs targeting unimplemented futures are not cut but must be explicitly labeled as unverified bets with no current value and locked as drafts. The failure mode being prevented is presenting speculative blueprints as validated understanding.

When should I not use an abstraction justification audit?

Avoid expanding it into a heavyweight methodology, since that would make the audit itself an instance of over-design. It is also not a cost test: low implementation effort does not exempt an abstraction from the explain, predict, or compress requirement.