Architecture Options Analysis

Architecture Options Analysis

Purpose

Prevent premature convergence on the first architecture idea.

This skill is for moments when a system change is large enough that choosing the wrong structure is expensive:

• architecture update
• new subsystem
• major refactor
• migration strategy
• interface redesign
• splitting or merging modules
• introducing new processing, storage, or orchestration patterns

The goal is not to generate many ideas. The goal is to compare a small number of realistic options and choose deliberately.

Use when

Use this skill when the user wants:

• architecture options
• design alternatives
• refactor strategy variants
• migration strategy comparison
• explicit trade-off analysis before implementation
• a recommendation grounded in constraints

Typical trigger phrases:

• "давай подумаем над архитектурой"
• "разложи варианты решения"
• "сравни архитектурные варианты"
• "какой вариант лучше"
• "какие есть правдоподобные варианты"
• "analyze architecture options"
• "compare design alternatives"
• "what architecture should we choose"

Do not use when

Do not use this skill for:

• generic brainstorming with no implementation target
• full implementation planning after the architecture is already chosen
• small local code changes
• bug fixing
• PR review
• product roadmap planning
• personal planning

If the user already chose the target architecture and wants staged execution, use an implementation-planning skill instead.

Inputs

Expected inputs:

• target change or problem
• current codebase or system context
• constraints
• existing interfaces, modules, flows, or deployment assumptions

Optional inputs:

• non-functional requirements
• scaling expectations
• operational constraints
• org or team constraints
• migration urgency
• backward compatibility requirements

Outputs

Always produce:

1. current state summary
2. constraints and decision criteria
3. 2-4 realistic architecture options
4. trade-off analysis for each
5. comparison table or structured comparison
6. recommended option
7. explicit rejection reasons for the non-selected options
8. optional next step if the recommendation should move into implementation planning

Core principles

• Do not invent options that are not realistic for the actual constraints.
• Do not analyze only one favored option.
• Do not silently add future-proofing that the current task does not justify.
• Compare options on engineering consequences, not on aesthetics.
• Keep the analysis anchored to migration and validation realities.

Constraints

• Start from the current state, not from abstract option generation.
• Limit the comparison to 2-4 plausible options.
• Every option must differ in a meaningful architectural dimension.
• Every non-selected option must have explicit rejection reasons.
• Do not turn the result into an execution plan.
• Do not recommend a migration-heavy option unless the benefit clearly pays for the migration cost under current constraints.

Procedure

1. Summarize the current state. First identify:

   • what exists now
   • what hurts now
   • what must remain stable
   • what interfaces or behaviors cannot be broken
   • what technical debt or coupling already exists

   The current state should be specific enough to explain why the architectural choice matters.

2. Extract real constraints. List only constraints that actually affect the decision, such as:

   • compatibility requirements
   • latency, throughput, or memory limits
   • data volume or request volume
   • deployment model
   • failure tolerance
   • observability requirements
   • team ownership or maintenance cost
   • migration constraints
   • time-to-delivery constraints

3. Define decision criteria. Make the evaluation dimensions explicit before comparing options. Common criteria:

   • implementation complexity
   • operational complexity
   • delivery cost
   • correctness risk
   • migration pain
   • testing surface
   • observability implications
   • scaling implications
   • maintainability or extensibility
   • rollback simplicity

4. Generate only 2-4 plausible options. Each option must be:

   • technically coherent
   • compatible with the real constraints
   • different in a meaningful architectural dimension
   • concrete enough to evaluate

   Do not generate fake variety by renaming the same structure.

5. For each option, describe:

   • the core architectural idea
   • the main components or boundaries
   • the data or control flow
   • what changes relative to the current state
   • where the complexity moves
   • what assumptions the option relies on

6. Analyze trade-offs for each option. For every option, explicitly cover:

   • strengths
   • weaknesses
   • complexity and cost
   • correctness risk
   • migration pain
   • testing implications
   • scaling implications
   • operational implications
   • likely failure modes
   • where this option is clearly better or worse than the others

7. Make migration pain concrete. Do not say "migration is harder" vaguely. Specify:

   • what must be rewritten
   • what interfaces change
   • whether dual-path support is needed
   • how incremental rollout could work
   • whether rollback is easy or painful

8. Make testing implications concrete. For each option, identify:

   • what new seams become testable
   • what becomes harder to validate
   • whether integration surface grows
   • whether mocking or stubbing becomes easier or worse
   • what lightweight validation would be needed during migration

9. Make scaling implications concrete. For each option, identify:

   • what bottlenecks move
   • how the option behaves under larger data, traffic, or concurrency
   • whether the option improves isolation or only hides coupling
   • whether horizontal growth, batching, partitioning, or caching become easier or harder

10. Recommend one option. The recommended option must be justified against the decision criteria, not personal taste. Explain:

    • why it is best under current constraints
    • what trade-offs are being consciously accepted
    • what assumptions must remain true for the recommendation to hold

11. Reject the other options explicitly. For every non-selected option, give concrete rejection reasons. Good rejection reasons:

    • too much migration pain for current benefit
    • adds operational burden without removing the main bottleneck
    • weak rollback story
    • increases coupling in the wrong place
    • testing surface becomes too fragile
    • only pays off at scale far beyond current needs

    Avoid weak rejection like "less ideal" or "not preferred".

Decision rules

Realism rule

Only compare options that a serious engineer could actually implement in this context.

Constraint rule

If an option violates an important constraint, say so directly instead of compensating with vague advantages.

Minimality rule

Prefer the option that solves the stated problem with the least additional architecture, unless a heavier option clearly pays for itself under current constraints.

Migration rule

Do not recommend an option with large migration pain unless the benefit is material and near-term.

Testing rule

If an option makes correctness much harder to validate, treat that as a major negative.

Scaling rule

Do not over-optimize for hypothetical scale. But do account for foreseeable scaling pain if the current architecture already points there.

Rejection rule

Every non-selected option must have explicit rejection reasons.

Optional subagent use

For large or cross-cutting systems, explicitly spawn bounded subagents before finalizing the comparison:

• one subagent to map current architecture, module boundaries, and interfaces
• one subagent to inspect migration and testing surface
• one subagent to inspect scaling or operational implications when those are central

Wait for their memos, then synthesize the final comparison. Do not spawn subagents for a small local design decision.

References

Use the supporting references when needed:

• references/options-analysis-template.md
• references/current-state-and-constraints-checklist.md
• references/rejection-reasons-checklist.md

Definition of done

• The current state and real constraints are explicit.
• The comparison covers 2-4 realistic options.
• Each option is evaluated on concrete engineering consequences.
• One option is recommended with explicit assumptions.
• All other options are explicitly rejected with concrete reasons.
• The result stops before implementation planning.

Final response format

Return the result in this structure:

• Current state
• Constraints
• Decision criteria
• Options:
  1. Option A
     • core idea
     • strengths
     • weaknesses
     • migration pain
     • testing implications
     • scaling implications
  2. Option B ...
  3. Option C ...
• Comparison summary
• Recommended option
• Rejected options and why
• What would invalidate this recommendation

Positive examples

Use this skill for:

• "разложи архитектурные варианты"
• "сравни варианты рефактора"
• "какую архитектуру выбрать"
• "дай 2-4 правдоподобных варианта решения"
• "compare design options for this subsystem"
• "analyze migration architecture choices"

Negative examples

Do not use this skill for:

• "сделай план реализации"
• "исправь баг"
• "сделай summary architecture"
• "напиши PR"
• "распланируй неделю"