Architecture decisions

Skill Xopoko/plug-n-skills/plugins/architecture-intelligence/skills/architecture-decisions

Ready-to-install skills and plugins for Codex, Claude Code, and AI coding agents: practical workflows for app delivery, architecture, research, design, and agent tooling.

Install

npx -y skills add Xopoko/plug-n-skills --skill architecture-decisions

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when structural code choices need durable rationale: ADRs, tradeoffs, consequences, reversibility, ownership, review triggers, and validation plans.

SKILL.md

2.1 KB, as published. Nobody here has run it

Architecture Decisions

Use when making, documenting, reviewing, or revising an architecture decision.

ADR Threshold

Create or review an ADR when a choice:

shapes module boundaries, ownership, data ownership, runtime topology, or integration style;
changes reliability, scalability, security, performance, operability, testability, or cost;
introduces hard-to-reverse dependency, platform, data model, framework, or protocol;
affects multiple teams, services, packages, apps, release trains, CODEOWNERS/OWNERS coverage, or cross-owned dependencies;
needs a revisit trigger because evidence may change.

Skip ceremony for small local implementation choices unless asked.

Contract

Capture status, context/forces, options, decision/rationale, consequences, affected components, migration plan, fitness functions, owner/review path, ownership exception path, expiry/revisit trigger.

Use architecture_intelligence.decision.v1 for durable output.

Review Questions

What source/runtime evidence supports the decision?
Which quality attribute improves and which gets worse?
What is the smallest reversible step?
What would make this decision wrong?
How will drift be detected?
Who owns implementation and later review?
Which owners must review cross-owned dependency/runtime changes?
Which tests, metrics, or operational signals prove it worked?
What rationale would be lost if this stayed only in chat or PR comments?

Verdict

accept: evidence and validation are sufficient.
sharpen: promising but missing constraints, options, owner, or validation.
block: high-risk or unsupported.

Before accepted, require explicit alternatives, named tradeoffs, evidence stronger than preference/trend, ownership/revisit trigger, and drift-detection fitness functions.

Do not accept decisions backed only by preference, trend, or unsupported scale claims. Mark needs-validation until evidence and fitness functions are credible.