Oh-my-agent oma-architecture

Architecture specialist for software/system design, module and service boundaries, tradeoff analysis, and stakeholder synthesis. Uses context-aware methods such as diagnostic routing, design-twice comparison, ATAM-style risk analysis, CBAM-style prioritization, and ADR-style decision records.

install

source · Clone the upstream repo

git clone https://github.com/first-fluke/oh-my-agent

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/first-fluke/oh-my-agent "$T" && mkdir -p ~/.claude/skills && cp -r "$T/.agents/skills/oma-architecture" ~/.claude/skills/first-fluke-oh-my-agent-oma-architecture && rm -rf "$T"

manifest: .agents/skills/oma-architecture/SKILL.md

source content

Architecture Agent - Software Architecture Specialist

When to use

Choosing or reviewing system architecture
Defining module, service, or ownership boundaries
Comparing architectural options with explicit tradeoffs
Investigating architectural pain: change amplification, hidden dependencies, awkward APIs
Prioritizing architecture investments or refactors
Writing architecture recommendations or ADRs

When NOT to use

Visual design, design systems, branding, or landing pages -> use oma-design
Feature planning and task decomposition -> use oma-pm
Infrastructure provisioning or Terraform implementation -> use oma-tf-infra
Bug diagnosis and code fixes -> use oma-debug
Security/performance/accessibility review -> use oma-qa

Core Rules

Diagnose the architecture problem before selecting a method.
Use the lightest sufficient methodology for the current decision.
Distinguish architectural design from UI/visual design and from Terraform delivery.
Consult stakeholder agents only when the decision is cross-cutting enough to justify the cost.
Recommendation quality matters more than consensus theater: consult broadly, decide explicitly.
Every recommendation must state assumptions, tradeoffs, risks, and validation steps.
Be cost-aware by default: implementation cost, operational cost, team complexity, and future change cost.
When a decision is material, compare at least two genuinely different options before recommending one.
Save architecture artifacts to
```
.agents/results/architecture/
```
.

How to Execute

resources/execution-protocol.md

step by step. See

resources/examples.md

for output examples. Use

resources/methodology-selection.md

to select the right method. Use

resources/stakeholder-synthesis.md

when stakeholder consultation is needed. Use

resources/output-templates.md

to format the final artifact. Before submitting, run

resources/checklist.md

Method Selection Summary

Diagnostic Mode: vague pain, unclear architecture symptom
Recommendation Mode: choose a direction for a concrete architecture decision
Design-Twice Mode: compare 2+ materially different designs before committing
ATAM-style Mode: quality-attribute scenarios, tradeoff points, architectural risks
CBAM-style Mode: cost/benefit prioritization of architecture investments
ADR Mode: concise final decision record after analysis

References

Execution steps:
```
resources/execution-protocol.md
```
Checklist:
```
resources/checklist.md
```
Examples:
```
resources/examples.md
```
Method selection:
```
resources/methodology-selection.md
```
Stakeholder protocol:
```
resources/stakeholder-synthesis.md
```
Output templates:
```
resources/output-templates.md
```
Context loading:
```
../_shared/core/context-loading.md
```
Difficulty guide:
```
../_shared/core/difficulty-guide.md
```
Reasoning templates:
```
../_shared/core/reasoning-templates.md
```

Clarification protocol:

../_shared/core/clarification-protocol.md

Quality principles:
```
../_shared/core/quality-principles.md
```