architecture

Create and evaluate Architecture Decision Records in markdown structure.

Updated Apr 23, 2026
One-click install
npx skills add https://github.com/ngochuy13/intern-dev --skill architecture-ngochuy13
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: architecture
Source: https://github.com/ngochuy13/intern-dev/tree/main/skills/architecture
Command: npx skills add https://github.com/ngochuy13/intern-dev --skill architecture-ngochuy13

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps teams document and decide architecture choices in a consistent way, reducing confusion and rework when selecting technologies or reviewing system designs.

Core Features & Use Cases

  • Create an ADR from a decision: Capture the context, options, trade-offs, and consequences when choosing between approaches like Kafka vs SQS.
  • Evaluate a proposed design: Provide structured feedback for a microservices or component proposal based on requirements and constraints.
  • Design a new component from requirements: Turn a system-design prompt into an organized decision record that explains why an approach is appropriate.

Quick Start

Use the architecture skill to produce a complete ADR by giving it your decision prompt, such as "Should we use Kafka or SQS for our event bus and why?"

Frequently Asked Questions about architecture

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

FAQPage Schema
How do I document architecture decisions for technology selection?

Architecture decision records (ADRs) document technology selection by capturing context, options, trade-offs, and consequences in a structured markdown format with status, deciders, and action items. They ensure consistent design decisions across teams.

What is an ADR and when do I need one for system design?

An ADR (Architecture Decision Record) is a markdown document capturing context, options, trade-offs, and consequences for technical design choices. You need one when selecting technologies, reviewing microservices, or designing components to prevent rework and confusion.

How do I create an ADR to compare microservices design options?

Create an ADR by providing a design decision prompt, such as choosing between Kafka or SQS. The system evaluates the proposed microservices design against requirements and outputs structured option comparisons, trade-off analysis, and consequences.

Does this approach work for evaluating component design from requirements?

Yes, evaluating component design from requirements works by turning system-design prompts into organized decision records. It explains why an approach is appropriate by mapping requirements and constraints to structured trade-off analysis and action items.

What are the limitations of using ADRs for trade-off analysis?

ADRs for trade-off analysis are limited to documenting and structuring design decisions rather than automatically implementing them. They provide organized markdown records of options and consequences but require manual execution of the resulting action items.