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

$pwd:

adr

Name: Adr
Author: irahardianto

// Architecture Decision Record skill for documenting significant architectural decisions with context, options, and consequences. Use during the Research phase when choosing between approaches, or whenever the user asks to document an architectural decision.

Manus에서 실행

$ git log --oneline --stat

stars:146

forks:47

updated:2026년 5월 25일 01:39

SKILL.md

readonly

name	adr
description	Architecture Decision Record skill for documenting significant architectural decisions with context, options, and consequences. Use during the Research phase when choosing between approaches, or whenever the user asks to document an architectural decision.

Architecture Decision Record (ADR) Skill

Purpose

Document significant architectural decisions so institutional knowledge persists across conversations and team members. ADRs capture the why, not just the what.

When to Invoke

During Research phase (phase-research.md) when a significant architecture decision is identified
When user explicitly asks to document a decision
When choosing between 2+ viable approaches
When introducing a new dependency or pattern
When changing existing architecture

ADR Storage

ADRs are stored in docs/decisions/ as numbered files:

docs/decisions/
├── 0001-use-postgresql-for-storage.md
├── 0002-adopt-feature-based-structure.md
├── 0003-use-testcontainers-for-integration.md
└── NNNN-short-title.md

ADR Template

Create the ADR file at docs/decisions/NNNN-short-title.md:

# NNNN. Short Title

**Date:** YYYY-MM-DD
**Status:** Proposed | Accepted | Deprecated | Superseded by NNNN

## Context
What is the issue that we're seeing that is motivating this decision?
Include technical constraints, business requirements, and relevant context.

## Options Considered

### Option A: {name}
- **Pros:** ...
- **Cons:** ...
- **Effort:** Low/Medium/High

### Option B: {name}
- **Pros:** ...
- **Cons:** ...
- **Effort:** Low/Medium/High

### Option C: {name} (if applicable)
- **Pros:** ...
- **Cons:** ...
- **Effort:** Low/Medium/High

## Decision
We chose **Option X** because...

## Consequences

### Positive
- What becomes easier or possible as a result

### Negative
- What becomes harder as a result
- Technical debt introduced (if any)

### Risks
- What could go wrong with this decision
- Mitigation strategies

## Related
- Links to relevant rules, previous ADRs, or external resources

Process Guidelines

Number sequentially — check existing ADRs in docs/decisions/ for the next number
Keep titles short — descriptive enough to identify the decision at a glance
Status lifecycle: Proposed → Accepted (after approval) → optionally Deprecated or Superseded
Never delete ADRs — if a decision is reversed, mark as Superseded by NNNN and create a new ADR
Use Sequential Thinking skill if the trade-off analysis is complex

Rule Compliance

ADRs should reference applicable rules:

Architectural Patterns @architectural-pattern.md
Core Design Principles @core-design-principles.md
Project Structure @project-structure.md

related-skills.json

같은 저장소

omni.md

from "irahardianto/awesome-agv"

Token-efficient communication protocol. Activate ONLY when: (1) user explicitly requests it (e.g., "use omni", "be concise", "compress output"), (2) dispatched as a sub-agent in /workflow-team pipelines where token budget matters, or (3) agent-to-agent communication via /omni headless modifier. Never activate by default in normal conversations — users expect natural language responses unless they opt in. Compresses prose form while preserving 100% technical accuracy. Code blocks, tool calls, file paths, and data are NEVER compressed.

2026-05-25146

code-review.md

from "irahardianto/awesome-agv"

Structured code review protocol for inspecting code quality against the full rule set. Use when auditing code written by yourself or another agent, during the /audit workflow, or when the user asks for a code review.

2026-05-25146

guardrails.md

from "irahardianto/awesome-agv"

Pre-flight checklist and post-implementation self-review protocol. Use before generating any code (pre-flight) and after writing code but before verification (self-review) to catch issues early.

2026-05-25146

debugging-protocol.md

from "irahardianto/awesome-agv"

Comprehensive protocol for validating root causes of software issues. Use when you need to systematically debug a complex bug, flaky test, or unknown system behavior by forming hypotheses and validating them with specific tasks.

2026-05-25146

perf-optimization.md

from "irahardianto/awesome-agv"

Profile-driven performance optimization protocol. Use when profiling data (CPU, heap, trace) is available or when the user requests performance analysis. Covers methodology, pattern catalog, safety invariants, and when-to-stop heuristics. Language-specific tooling is in languages/*.md.

2026-05-25146

api-documentation.md

from "irahardianto/awesome-agv"

OpenAPI 3.1 specification writing, request/response examples, error documentation, versioning, and interactive API portal patterns.

2026-05-25146

package.json

"author": "irahardianto"

"repository": "irahardianto/awesome-agv"

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

$ install --global

$ download --local

Manus에서 실행

$ useful --forSOC

소프트웨어 개발자컴퓨터 및 수학직15-1252L4

Architecture Decision Record (ADR) Skill

Purpose

Document significant architectural decisions so institutional knowledge persists across conversations and team members. ADRs capture the why, not just the what.

When to Invoke

During Research phase (phase-research.md) when a significant architecture decision is identified

When user explicitly asks to document a decision

When choosing between 2+ viable approaches

When introducing a new dependency or pattern

When changing existing architecture

ADR Storage

ADRs are stored in docs/decisions/ as numbered files:

docs/decisions/ ├── 0001-use-postgresql-for-storage.md ├── 0002-adopt-feature-based-structure.md ├── 0003-use-testcontainers-for-integration.md └── NNNN-short-title.md

ADR Template

Create the ADR file at docs/decisions/NNNN-short-title.md:

# NNNN. Short Title **Date:** YYYY-MM-DD **Status:** Proposed | Accepted | Deprecated | Superseded by NNNN ## Context What is the issue that we're seeing that is motivating this decision? Include technical constraints, business requirements, and relevant context. ## Options Considered ### Option A: {name} - **Pros:** ... - **Cons:** ... - **Effort:** Low/Medium/High ### Option B: {name} - **Pros:** ... - **Cons:** ... - **Effort:** Low/Medium/High ### Option C: {name} (if applicable) - **Pros:** ... - **Cons:** ... - **Effort:** Low/Medium/High ## Decision We chose **Option X** because... ## Consequences ### Positive - What becomes easier or possible as a result ### Negative - What becomes harder as a result - Technical debt introduced (if any) ### Risks - What could go wrong with this decision - Mitigation strategies ## Related - Links to relevant rules, previous ADRs, or external resources

Process Guidelines

Number sequentially — check existing ADRs in docs/decisions/ for the next number

Keep titles short — descriptive enough to identify the decision at a glance

Status lifecycle: Proposed → Accepted (after approval) → optionally Deprecated or Superseded

Never delete ADRs — if a decision is reversed, mark as Superseded by NNNN and create a new ADR

Use Sequential Thinking skill if the trade-off analysis is complex

Rule Compliance

ADRs should reference applicable rules:

Architectural Patterns @architectural-pattern.md

Core Design Principles @core-design-principles.md

Project Structure @project-structure.md

adr

Architecture Decision Record (ADR) Skill

Purpose

When to Invoke

ADR Storage

ADR Template

Process Guidelines

Rule Compliance

이 저장소의 다른 Skills

이 저장소의 다른 Skills

Architecture Decision Record (ADR) Skill

Purpose

When to Invoke

ADR Storage

ADR Template

Process Guidelines

Rule Compliance