원클릭으로 Manus에서 모든 스킬 실행

document-decision

스타2

포크1

업데이트2026년 1월 19일 08:03

Create Architecture Decision Records (ADRs) documenting WHY decisions were made. Uses standard ADR format (Status/Context/Decision/Consequences).

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

a-scolan

a-scolan/c4-hands-on-demo

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Document Architecture Decision

Use this skill when recording system design decisions for LikeC4-modeled architectures.

Purpose

Create Architecture Decision Records (ADRs) that explain WHY architectural choices were made in the system diagrams, not HOW the diagrams are built or maintained.

Scope

✅ System design decisions (e.g., why Kong API Gateway vs HAProxy, why MongoDB vs PostgreSQL)
✅ Container-level technology choices (e.g., why RabbitMQ for queuing, why MinIO for storage)
✅ Component architecture patterns (e.g., why async processing, why microservices)
✅ Deployment infrastructure choices (e.g., why 3-node replication, why specific VM sizing)
❌ NOT repository structure, tooling, CI/CD setup, or LikeC4 modeling decisions

Format

Filename: ADR/NNNN-decision-title.md (manually increment NNNN)
Template: Use ADR/0000-template.md as reference
Sections: Status, Context, Decision, Consequences (Positive/Negative/Neutral)

Example

# ADR-0001: API Gateway Selection - Kong vs HAProxy

## Status
Accepted

## Context
Legacy system used HAProxy as a simple load balancer. Microservices architecture requires:
- API-aware routing based on paths, headers, JWT claims
- Built-in authentication (JWT validation, OAuth2)
- Rate limiting and circuit breakers
- Plugin ecosystem for extensibility

## Decision
Upgrade from HAProxy to Kong API Gateway

## Consequences

### Positive
- Routes to multiple backend services with path-based rules
- JWT validation out-of-the-box, reducing custom auth code
- Production-grade rate limiting without custom implementation
- Extensible via Lua plugins

### Negative
- More complex configuration than HAProxy
- Requires learning Kong admin API and declarative config
- Higher resource footprint (but acceptable for use case)

Integration with LikeC4

Reference elements from diagrams: "The decision affects mySystem.apiGateway (Container_ReverseProxy)"
Link to views: "See deployment view: deployment_api_tier"
Tag related decisions: Use frontmatter or Notes section to link ADRs

이 저장소의 다른 Skills

같은 저장소

design-view

a-scolan/c4-hands-on-demo

Design views with proper includes/excludes and basic layout. Use for include patterns, tag filtering, and simple rank hints. For advanced styling/navigation, use customize-view.

2026-01-232

model-deployment

a-scolan/c4-hands-on-demo

Model deployment infrastructure (environments, zones, VMs, apps) with proper hierarchy and instanceOf links. Organize zones into tiers (DMZ, App, Data, Processing) with rich descriptions including VLAN/network specifications.

2026-01-232

write-rich-descriptions

a-scolan/c4-hands-on-demo

Use metadata for system models (business/technical context) and markdown tables for deployment models (infrastructure specs). Makes models queryable and self-documenting.

2026-01-232

c4-modeling-process

a-scolan/c4-hands-on-demo

C4 modeling methodology - design system hierarchy top-to-bottom from Context to Components. Ensures consistent, stakeholder-focused architecture documentation.

2026-01-202

configure-project-includes

a-scolan/c4-hands-on-demo

Manage likec4.config.json includes and image aliases. Ensures relative paths and preserves existing configuration. Support multi-file organization (system-model + system-views + deployment + operations).

2026-01-202

create-element

a-scolan/c4-hands-on-demo

Create elements with proper naming (PascalCase kinds, camelCase vars), required metadata (technology, description), and correct hierarchy.

2026-01-202

Document Architecture Decision

Use this skill when recording system design decisions for LikeC4-modeled architectures.

Purpose

Create Architecture Decision Records (ADRs) that explain WHY architectural choices were made in the system diagrams, not HOW the diagrams are built or maintained.

Scope

✅ System design decisions (e.g., why Kong API Gateway vs HAProxy, why MongoDB vs PostgreSQL)

✅ Container-level technology choices (e.g., why RabbitMQ for queuing, why MinIO for storage)

✅ Component architecture patterns (e.g., why async processing, why microservices)

✅ Deployment infrastructure choices (e.g., why 3-node replication, why specific VM sizing)

❌ NOT repository structure, tooling, CI/CD setup, or LikeC4 modeling decisions

Format

Filename: ADR/NNNN-decision-title.md (manually increment NNNN)

Template: Use ADR/0000-template.md as reference

Sections: Status, Context, Decision, Consequences (Positive/Negative/Neutral)

Example

# ADR-0001: API Gateway Selection - Kong vs HAProxy ## Status Accepted ## Context Legacy system used HAProxy as a simple load balancer. Microservices architecture requires: - API-aware routing based on paths, headers, JWT claims - Built-in authentication (JWT validation, OAuth2) - Rate limiting and circuit breakers - Plugin ecosystem for extensibility ## Decision Upgrade from HAProxy to Kong API Gateway ## Consequences ### Positive - Routes to multiple backend services with path-based rules - JWT validation out-of-the-box, reducing custom auth code - Production-grade rate limiting without custom implementation - Extensible via Lua plugins ### Negative - More complex configuration than HAProxy - Requires learning Kong admin API and declarative config - Higher resource footprint (but acceptable for use case)

Integration with LikeC4

Reference elements from diagrams: "The decision affects mySystem.apiGateway (Container_ReverseProxy)"

Link to views: "See deployment view: deployment_api_tier"

Tag related decisions: Use frontmatter or Notes section to link ADRs

name	document-decision
description	Create Architecture Decision Records (ADRs) documenting WHY decisions were made. Uses standard ADR format (Status/Context/Decision/Consequences).