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

시작하기

architecture-review

스타0

포크0

업데이트2026년 5월 14일 19:49

Use when reviewing architecture decisions. C4 model, dependency inversion, hexagonal boundaries.

설치

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

Manus에서 실행

출처

MonsieurBarti

MonsieurBarti/tff-mono

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

다운로드

Manus에서 실행

Architecture Review

When to Use

∀ plan reviews (standard, complex). ∀ PRs that touch module boundaries.

Checklist

DEPENDENCY DIRECTION: ∀ import: does it follow domain <- app <- infra <- presentation?
BOUNDARY CHECK: ∀ new module: is responsibility single and clear?
PORT/ADAPTER: ∀ external dependency: accessed through port? adapter exists?
COUPLING: ∀ cross-module call: through interface or direct import?
ADR: Architecture decision worth recording? -> create ADR

Review Template

Aspect	Status	Finding
Layer dependency	pass/fail	...
Module boundaries	pass/fail	...
Port coverage	pass/fail	...
Cross-cutting concerns	pass/fail	...

Anti-Patterns

Reviewing code style (that's code-reviewer's job)
Proposing rewrites for working code (YAGNI)
¬reading the spec before reviewing architecture
Designing for hypothetical future requirements

Rules

Scope: architecture only, ¬code quality, ¬spec compliance
∀ finding: cite specific file + line
Severity: Critical (blocks) | Important (should fix) | Suggestion (optional)
∀ deviation from patterns: justification required

Domain-Vocabulary Heuristics

Apply these structural tests during every architecture review:

Deletion Test

Ask: "If I remove this module, does complexity scatter across the system or consolidate elsewhere?"

Scatter → the module was hiding distributed complexity. Refactor to make dependencies explicit.
Consolidate → the module was a genuine abstraction. Keep it.

Thin Implementations

Identify modules with large surface area and low behavioral leverage. These are candidates for deepening — merging, hiding behind a narrower interface, or replacing with a library.

Entangled Units

Locate seams where two modules cannot change independently. One adapter = hypothetical seam. Two adapters = real seam. Entangled units without a seam violate the boundary rule.

Difficult-to-Test Areas

Flag modules that require heavy mocking or complex setup. "The interface is the test surface." Difficult testing often signals a shallow module or a missing port.

Document findings using domain terminology from CONTEXT.md or DOMAIN.md, not generic handler or service names.

이 저장소의 다른 Skills

같은 저장소

grill-with-docs

MonsieurBarti/tff-mono

Use during discuss-slice and plan-slice to stress-test a spec or plan against domain vocabulary before approval.

2026-05-140

prototype

MonsieurBarti/tff-mono

Use during research-slice to build disposable experiments that answer technical uncertainty.

2026-05-140

setup-project-skills

MonsieurBarti/tff-mono

Use during project:init to scaffold repo-level agent configuration (CLAUDE.md, AGENTS.md, tracker labels).

2026-05-140

systematic-debugging

MonsieurBarti/tff-mono

Use when debugging. 4-phase investigation, root cause, minimal fix.

2026-05-140

test-driven-development

MonsieurBarti/tff-mono

Use when implementing features/fixes. Iron law: ¬∃ production code without failing test.

2026-05-140

to-prd

MonsieurBarti/tff-mono

Use during discuss-slice to synthesize conversation context into a formal PRD with user stories, implementation decisions, testing decisions, and exclusions.

2026-05-140

name	architecture-review
description	Use when reviewing architecture decisions. C4 model, dependency inversion, hexagonal boundaries.
version	1.0.0
tags	["architecture","review"]

Architecture Review

When to Use

∀ plan reviews (standard, complex). ∀ PRs that touch module boundaries.

Checklist

DEPENDENCY DIRECTION: ∀ import: does it follow domain <- app <- infra <- presentation?
BOUNDARY CHECK: ∀ new module: is responsibility single and clear?
PORT/ADAPTER: ∀ external dependency: accessed through port? adapter exists?
COUPLING: ∀ cross-module call: through interface or direct import?
ADR: Architecture decision worth recording? -> create ADR

Review Template

Aspect	Status	Finding
Layer dependency	pass/fail	...
Module boundaries	pass/fail	...
Port coverage	pass/fail	...
Cross-cutting concerns	pass/fail	...

Anti-Patterns

Reviewing code style (that's code-reviewer's job)
Proposing rewrites for working code (YAGNI)
¬reading the spec before reviewing architecture
Designing for hypothetical future requirements

Rules

Scope: architecture only, ¬code quality, ¬spec compliance
∀ finding: cite specific file + line
Severity: Critical (blocks) | Important (should fix) | Suggestion (optional)
∀ deviation from patterns: justification required

Domain-Vocabulary Heuristics

Apply these structural tests during every architecture review:

Deletion Test

Ask: "If I remove this module, does complexity scatter across the system or consolidate elsewhere?"

Scatter → the module was hiding distributed complexity. Refactor to make dependencies explicit.
Consolidate → the module was a genuine abstraction. Keep it.

Thin Implementations

Identify modules with large surface area and low behavioral leverage. These are candidates for deepening — merging, hiding behind a narrower interface, or replacing with a library.

Entangled Units

Locate seams where two modules cannot change independently. One adapter = hypothetical seam. Two adapters = real seam. Entangled units without a seam violate the boundary rule.

Difficult-to-Test Areas

Flag modules that require heavy mocking or complex setup. "The interface is the test surface." Difficult testing often signals a shallow module or a missing port.

Document findings using domain terminology from CONTEXT.md or DOMAIN.md, not generic handler or service names.