oma-architecture

Analyze software architecture and document tradeoffs, risks, and stakeholder concerns.

1|Updated Mar 21, 2026

Search Tags:#architecture #system design #risk assessment #tradeoff analysis #stakeholder synthesis

Ready to run

npx skills add https://github.com/first-fluke/mapple --skill oma-architecture

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: oma-architecture
Source: https://github.com/first-fluke/mapple/tree/main/.agents/skills/oma-architecture
Command: npx skills add https://github.com/first-fluke/mapple --skill oma-architecture

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill assists in analyzing and documenting complex software architectures, helping teams make informed decisions about module boundaries, stakeholder concerns, and risk tradeoffs.

Core Features & Use Cases

Architecture Evaluation: Diagnose existing system structures and identify pain points.
Tradeoff & Risk Analysis: Compare architectural options using ATAM-style approaches and document potential tradeoffs.
Decision Documentation: Create ADRs and architecture recommendations to ensure clear, durable records for future reference.
Use Case: When redesigning a microservices system, generate a comprehensive architecture review highlighting risks, stakeholder concerns, and options for boundary adjustments.

Quick Start

Use the oma-architecture skill to analyze current system architecture and generate a risk and tradeoff report.

Frequently Asked Questions about oma-architecture

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

FAQPage Schema

How do I evaluate tradeoffs and risks in system design?▼

You can evaluate system design tradeoffs and risks using ATAM-style approaches to compare architectural options, identify pain points, and document potential stakeholder concerns across modules and services.

What is the best way to document software architecture decisions?▼

The best way to document software architecture decisions is by creating Architecture Decision Records (ADRs) that ensure clear, durable records of module boundaries, stakeholder concerns, and risk tradeoffs for future reference.

How do I analyze existing software architecture for pain points?▼

You can analyze existing software architecture by diagnosing current system structures to identify pain points, evaluate module boundaries, and generate a comprehensive risk and tradeoff report for redesigns.

Can I use this for microservices architecture redesign and boundary adjustments?▼

Yes, you can use it for microservices architecture redesign to generate a comprehensive review highlighting risks, stakeholder concerns, and options for adjusting module and service boundaries.

What methods are applied to produce architecture recommendations?▼

Methods like ATAM, ADR, and diagnostic routing are applied to produce architecture recommendations, ensuring thorough decision evaluation, stakeholder synthesis, and risk assessment across modules and services.

When do I need stakeholder synthesis in system architecture?▼

You need stakeholder synthesis in system architecture when comparing architectural options and documenting tradeoffs, ensuring that stakeholder concerns are integrated into the final architecture recommendations and decision records.