technical-architecture-decision

Produces architecture decisions with alternatives, patterns, contracts, risks, and rollout plans.

Updated Jun 8, 2026
One-click install
npx skills add https://github.com/vovanostm-public/multica --skill technical-architecture-decision-vovanostm-public
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: technical-architecture-decision
Source: https://github.com/vovanostm-public/multica/tree/main/workflow-bundles/multica-specops-v5/codex_skills/.agents/skills/technical-architecture-decision
Command: npx skills add https://github.com/vovanostm-public/multica --skill technical-architecture-decision-vovanostm-public

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Engineering teams often make architecture choices ad hoc, leading to over-engineered patterns, undocumented tradeoffs, and unclear API contracts. This Skill structures the architecture decision process so every design includes explicit alternatives, pattern triggers, risks, and a rollout strategy. ## Core Features & Use Cases - Structured Decision Workflow: Maps existing architecture, lists viable options, and selects patterns only when a concrete trigger exists (Adapter, Strategy, FSM, Repository). - Decision Matrix & Quality Gates: Enforces checks against over-engineering, backend/frontend compatibility, and test seam identification. - Typed Evidence Outputs: Produces architecture.document, decision_matrix, patterns, risks, and api.contract_plan with evidence, assumptions, blockers, and confidence fields. - Use Case: When planning a new service module, run this Skill to compare a plain function approach versus introducing a Repository pattern, and record the decision matrix and migration plan. ## Quick Start Ask the agent to evaluate the architecture options for the new module and produce an architecture decision document with a decision matrix and rollout plan.

Frequently Asked Questions about technical-architecture-decision

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

FAQPage Schema
How do I document a software architecture decision?▼

Map the existing architecture, list viable options including the simplest direct implementation, then record a decision matrix with chosen patterns, contracts, risks, and rollout plan. Each output includes evidence, assumptions, blockers, and confidence fields.

When should I use design patterns like Adapter, Strategy, or Repository?▼

Apply a pattern only when a concrete trigger exists: Adapter for external boundaries, Strategy for multiple algorithm variants, FSM for state transitions, and Repository only when direct queries are insufficient. Plain functions are preferred otherwise.

How do I avoid over-engineering in system design?▼

Use a decision matrix that defaults to the simplest direct implementation and requires a named trigger before introducing any pattern. Quality gates explicitly check for over-engineering and require a test seam and compatibility review.

What should an architecture decision record include?▼

Include alternatives considered, selected patterns with triggers, API contract plans, risks, migration and rollout strategy, plus typed evidence fields for assumptions, blockers, confidence, and handoff.

Can this workflow handle new dependency evaluation?▼

Yes, the decision matrix routes any new dependency introduction to a separate dependency-decision process rather than approving it inline, keeping dependency tradeoffs explicit and auditable.