de-architecture-decision

Generate Data Engineering Architecture Decision Records with weighted trade-off scoring.

14|1|Updated May 5, 2026
One-click install
npx skills add https://github.com/ivanshamaev/de-agent-skills --skill de-architecture-decision
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: de-architecture-decision
Source: https://github.com/ivanshamaev/de-agent-skills/tree/main/skills/de_adr
Command: npx skills add https://github.com/ivanshamaev/de-agent-skills --skill de-architecture-decision

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps you capture, justify, and standardize Data Engineering architecture decisions so your team can communicate trade-offs clearly and keep decision history consistent over time.

Core Features & Use Cases

  • ADRs with a consistent template: Provides an ADR-NNN structure including context, decision, rationale, alternatives, consequences, and follow-up actions.
  • Trade-off evaluation framework: Includes a weighted scoring matrix, scoring rubric, and reversibility spectrum to make comparisons systematic and repeatable.
  • Reusable, pre-filled examples: Offers concrete ADR examples for common DE choices like orchestrator selection, lakehouse storage formats, and CDC/data quality strategies.
  • Use cases: Selecting tools/approaches, designing high-level platform components, evaluating competing options, documenting past choices, and managing ADR lifecycle events (supersede/deprecate/link).

Quick Start

Use the de_adr skill when you need to decide between A and B for an architecture change and produce an ADR that records the context, decision, alternatives, trade-offs, and next actions.

Frequently Asked Questions about de-architecture-decision

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

FAQPage Schema
How do I write an Architecture Decision Record for data engineering?▼

An ADR for data engineering requires a structured template documenting context, decision, rationale, alternatives, consequences, and follow-up actions to capture and justify architecture choices consistently.

What is the best way to document trade-offs when evaluating data engineering platforms?▼

The best way to document trade-offs for data engineering platforms is using a weighted scoring matrix with a 1-5 rubric and a reversibility assessment to make technology evaluation systematic, repeatable, and clear for stakeholders.

How do I manage the lifecycle of an Architecture Decision Record?▼

Managing the lifecycle of an Architecture Decision Record involves documenting past choices and handling events like superseding, deprecating, or linking prior ADRs to maintain a consistent and durable decision history over time.

When do I need an ADR for technology evaluation?▼

You need an ADR for technology evaluation when selecting tools or designing high-level platform components, ensuring that competing options are compared via a weighted trade-off scoring approach and decision reversibility assessment.

How does stakeholder communication factor into architecture decisions?▼

Stakeholder communication in architecture decisions is guided by a decision reversibility assessment and structured ADR documentation, ensuring trade-offs, consequences, and follow-up actions are clearly conveyed to all relevant parties.

Does this ADR template work for common data engineering choices like lakehouse storage formats?▼

Yes, this ADR template works for common data engineering choices by providing reusable, pre-filled examples for decisions like orchestrator selection, lakehouse storage formats, and CDC or data quality strategies.