architecture-review

Evaluate architecture changes and document decisions as Architecture Decision Records.

3|Updated Mar 1, 2026
One-click install
npx skills add https://github.com/YanCheng-go/danskprep --skill architecture-review-yancheng-go
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: architecture-review
Source: https://github.com/YanCheng-go/danskprep/tree/main/.claude/skills/architecture-review
Command: npx skills add https://github.com/YanCheng-go/danskprep --skill architecture-review-yancheng-go

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Architecture decisions are often implicit and hard to trace; this skill provides a disciplined ADR-based approach to capture rationale and trade-offs.

Core Features & Use Cases

  • Record Architecture Decisions as ADRs to preserve context and rationale.
  • Evaluate and document API contracts, module boundaries, and data-model implications during design reviews or PRs.
  • Align teams and future work by listing alternatives and consequences for major architectural choices.

Quick Start

Create an ADR for a design decision by running the ADR workflow on the current PR.

Frequently Asked Questions about architecture-review

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

FAQPage Schema
How do I document architecture decisions and trade-offs during a PR review?

Document architecture decisions during PR reviews by generating Architecture Decision Records that capture context, decision, consequences, and alternatives, outputting directly to docs/adr/NNN-title.md.

What is the best way to record system design changes when crossing module boundaries?

Recording system design changes across module boundaries is best handled by creating an ADR to evaluate new hooks, pages, or DB tables, ensuring all architectural trade-offs and rationale are explicitly documented.

Can I use ADRs to evaluate API contracts and data-model implications?

Yes, you can use the ADR process to evaluate and document API contracts, module boundaries, and data-model implications during design reviews, aligning teams by listing alternatives and consequences.

What sections are required when writing an Architecture Decision Record?

Writing an Architecture Decision Record requires sections for context, decision, consequences, and alternatives to properly preserve the rationale behind architectural choices and align future work.