mirror-of-self

Compare two technical implementations through structured introspective questioning.

6|Updated Jan 14, 2026
One-click install
npx skills add https://github.com/markacianfrani/armor --skill mirror-of-self
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: mirror-of-self
Source: https://github.com/markacianfrani/armor/tree/main/skills/mirror-of-self
Command: npx skills add https://github.com/markacianfrani/armor --skill mirror-of-self

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill resolves decision paralysis when choosing between two technically sound, competing implementations by shifting the focus from abstract elegance to long-term maintainability and personal comfort.

Core Features & Use Cases

  • Pairwise Comparison: Provides a structured framework to evaluate two options side-by-side.
  • Engineer-Centric Evaluation: Prioritizes the experience of the engineer who will actually maintain the code over theoretical perfection.
  • Use Case: When you are stuck between two different API designs or module structures that both pass all tests, use this skill to determine which one you would rather inhabit during a 3am production incident.

Quick Start

Ask the mirror-of-self skill to help you choose between the two proposed refactoring approaches for the authentication module.

Frequently Asked Questions about mirror-of-self

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

FAQPage Schema
How do I choose between two equivalent software design or API architecture options?

To choose between equivalent software design or API architecture options, apply structured introspective questioning that prioritizes long-term maintainability and engineer comfort over abstract theoretical perfection, focusing on the reality of maintaining the code during production incidents.

What is the best way to resolve decision paralysis during code refactoring?

Resolving decision paralysis during code refactoring involves using a pairwise comparison framework to evaluate two technically sound implementations side-by-side, prioritizing the maintaining engineer's experience over theoretical elegance.

When do I need structured decision-making for software engineering ties?

You need structured decision-making for software engineering ties when objective metrics fail to distinguish between two distinct, functional alternatives in scenarios like API architecture, module structures, or refactoring approaches.

Does this pairwise comparison approach work for refactoring a specific module?

Yes, this approach works for refactoring specific modules by requiring you to provide two distinct, functional alternatives for comparative analysis, such as evaluating two proposed approaches for an authentication module.

Why should I prioritize engineer comfort over theoretical perfection in architecture decisions?

Prioritizing engineer comfort over theoretical perfection in architecture decisions ensures long-term maintainability by evaluating which implementation you would rather inhabit during a 3am production incident rather than relying on abstract elegance.