ワンクリックでManusで任意のスキルを実行

$pwd:

adr

Name: Adr
Author: irahardianto

// Document significant architectural decisions using the ADR (Architecture Decision Record) format. Use during research phases when choosing between approaches, when introducing new dependencies or patterns, or when the user asks to document a technical decision.

Manusで実行

$ git log --oneline --stat

stars:2

forks:0

updated:2026年4月8日 13:13

SKILL.md

readonly

name	adr
description	Document significant architectural decisions using the ADR (Architecture Decision Record) format. Use during research phases when choosing between approaches, when introducing new dependencies or patterns, or when the user asks to document a technical 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 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 @.claude/rules/architectural-pattern.md
Core Design Principles @.claude/rules/core-design-principles.md
Project Structure @.claude/rules/project-structure.md

related-skills.json

同じリポジトリ

code-review.md

from "irahardianto/claude-superpowers"

Execute a structured code review protocol that inspects code quality against the full rule set. Use when auditing code written by yourself or another agent, during code audit workflows, or when the user asks for a code review. Produces a findings document with severity tags.

2026-04-142

research-methodology.md

from "irahardianto/claude-superpowers"

Structured research protocol for investigating technologies, patterns, and APIs before implementation. Use when exploring unfamiliar technologies, evaluating library options, or documenting technical findings. Covers multi-tool search strategy, research log conventions, and training data fallback honesty protocol.

2026-04-142

accessibility-principles.md

from "irahardianto/claude-superpowers"

Apply WCAG accessibility standards when building UI components, forms, interactive elements, or any user-facing interface. Covers semantic HTML, ARIA attributes, keyboard navigation, color contrast, and screen reader support.

2026-04-082

api-design-principles.md

from "irahardianto/claude-superpowers"

Apply REST/HTTP API design conventions when implementing endpoints, handlers, middleware, request validation, or response formatting. Covers resource naming, status codes, error formats, versioning, and pagination.

2026-04-082

ci-cd-gitops-kubernetes.md

from "irahardianto/claude-superpowers"

Apply Kubernetes deployment and GitOps patterns when configuring container orchestration, deployment strategies (rolling, blue-green, canary), ArgoCD/Flux manifests, or Kubernetes secrets management. Supplement to ci-cd-principles.

2026-04-082

ci-cd-principles.md

from "irahardianto/claude-superpowers"

Apply CI/CD pipeline design patterns when configuring build pipelines, deployment processes, release strategies, Dockerfiles, or GitHub Actions workflows. Covers pipeline stages, artifact management, environment promotion, and rollback strategies.

2026-04-082

package.json

"author": "irahardianto"

"repository": "irahardianto/claude-superpowers"

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 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 @.claude/rules/architectural-pattern.md

Core Design Principles @.claude/rules/core-design-principles.md

Project Structure @.claude/rules/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