Architecture analysis

Skill ShangChienLiu/ai-dev-os/skills/architecture-analysis

Use before implementation when the ticket involves design decisions, multiple possible approaches, or affects multiple modules. Evaluates approaches with tradeoffs and creates ADRs.From its SKILL.md

Install

npx -y skills add ShangChienLiu/ai-dev-os --skill architecture-analysis

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.2 KB, as published. Nobody here has run it

Architecture Analysis

Think like a senior engineer before coding. Evaluate multiple approaches, recommend one, and document significant decisions as Architecture Decision Records in Obsidian.

Configuration

Read config.json from the ai-dev-os skill directory. If configured is false or the file is missing, STOP and tell the user:

"Please run /configure-ai-dev-os to set up your Obsidian vault path and Linear team."

Obsidian vault: Use the obsidian_vault_path value from config.
ADR folder: decision_logs/
ADR template: templates/decision_log.md

Input

Ticket context from ticket-intake
Context summary from context-aggregation

Skip Condition

If the ticket is a trivial bug fix or small isolated change (single file, obvious fix, no design decisions), skip this stage. Output:

Architecture analysis skipped: [reason — e.g., "trivial bug fix in single file, no design decisions needed"]

Procedure

Step 1: Define the problem

Restate the technical problem clearly, separating:

What must change
What must not change
What constraints exist (performance, compatibility, security, etc.)

Step 2: Generate approaches

Produce 2-3 distinct approaches. For each:

### Approach [A/B/C]: [Name]

**Description:** [1-2 sentences]

**Pros:**
- [pro 1]
- [pro 2]

**Cons:**
- [con 1]
- [con 2]

**Risk level:** [low / medium / high]
**Estimated complexity:** [simple / moderate / complex]

Step 3: Recommend

State the recommended approach with rationale:

### Recommendation

**Chosen approach:** [A/B/C]

**Rationale:**
[Why this approach is best given the constraints, risks, and tradeoffs]

**What to watch for:**
[Key risks or areas that need careful implementation]

Step 4: Create ADR (if significant)

If the decision involves:

A new architectural pattern
A significant technology choice
A change that affects multiple modules
A tradeoff that future developers need to understand

Then create an ADR in Obsidian:

Read the decision_log template: call mcp__obsidian__obsidian_read_note on templates/decision_log.md.
Populate the template with:
- Title: the decision
- Problem: from Step 1
- Options Considered: from Step 2
- Decision: from Step 3
- Tradeoffs: pros/cons summary
- Frontmatter: created = today (ISO 8601), ticket = ticket ID, area = affected area, related_concepts = concepts involved
Write the ADR: call mcp__obsidian__obsidian_update_note to create decision_logs/YYYY-MM-DD-<slug>.md where slug is a kebab-case summary of the decision.

If the decision is routine (using existing patterns, small scope), skip ADR creation.

Gotchas

Skip logic ("trivial bug fix") is a judgment call — Claude may skip when it shouldn't. If in doubt, run the analysis.
ADR creation requires Obsidian templates/decision_log.md to exist. If missing, the skill will fail at template read.

Output

The recommended approach and any ADR reference are passed downstream for use by brainstorming and planning stages.