hai-razor

Audit requirements and architectures for unnecessary complexity using structured verdicts.

278|15|Updated Mar 25, 2026
One-click install
npx skills add https://github.com/hylarucoder/hai-stack --skill hai-razor
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: hai-razor
Source: https://github.com/hylarucoder/hai-stack/tree/main/skills/hai-razor
Command: npx skills add https://github.com/hylarucoder/hai-stack --skill hai-razor

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill helps teams identify and remove unnecessary requirements, abstractions, workflow steps, and architectural complexity by testing whether each concept truly deserves to exist.

Core Features & Use Cases

  • Concept Necessity Auditing: Evaluates requirements, fields, states, modules, layers, abstractions, and rules using Keep/Merge/Defer/Delete/Replace/Prove-first verdicts.
  • Evidence-Based Simplification: Separates real constraints from assumptions, finds hidden ownership, and protects complexity that preserves correctness, safety, or important boundaries.
  • Use Case: Review a growing product specification or architecture proposal to find fake requirements, premature abstractions, and over-engineered designs before implementation.

Quick Start

Ask the AI to use hai-razor to audit this PRD and identify which requirements should be kept, merged, deferred, deleted, or proven first.

Frequently Asked Questions about hai-razor

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

FAQPage Schema
How do I identify and remove unnecessary complexity in a product requirements document?

To identify and remove unnecessary complexity in a product requirements document, you can apply evidence-driven audits that classify concepts using Keep, Merge, Defer, Delete, Replace, or Prove-first evaluations to test whether each requirement truly deserves to exist.

What is the best way to audit a software architecture proposal for premature abstractions?

Auditing a software architecture proposal for premature abstractions requires applying deletion tests and hidden ownership analysis to separate real constraints from assumptions, protecting complexity that preserves correctness and safety while eliminating over-engineered designs.

How do I simplify a workflow and determine which steps to delete or merge?

To simplify a workflow and determine which steps to delete or merge, conduct an evidence-led classification of each step, applying a structured Keep/Merge/Defer/Delete/Replace/Prove-first evaluation to find and remove unnecessary workflow complexity.

Does this complexity reduction approach work for reviewing data models and state designs?

Yes, this complexity reduction approach works for reviewing data models and state designs by determining which fields, states, modules, and abstractions truly deserve to exist through a structured necessity audit and deletion test.

When should I avoid using an evidence-driven simplification audit on my requirements?

You should avoid using an evidence-driven simplification audit when your requirements or architecture strictly demand preserving complexity that maintains important boundaries, correctness, or safety constraints that cannot be proven unnecessary through deletion tests.