architect

Frame architecture decisions with alternatives and ripple-effect analysis.

3|Updated Mar 16, 2026
One-click install
npx skills add https://github.com/hcross/crewrig --skill architect-hcross
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: architect
Source: https://github.com/hcross/crewrig/tree/main/.gemini/skills/architect
Command: npx skills add https://github.com/hcross/crewrig --skill architect-hcross

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It helps teams make disciplined, reproducible architecture decisions when changes touch multiple modules, introduce a new abstraction, or modify a shared contract, ensuring alignment and traceability.

Core Features & Use Cases

  • Frame before proposing: Before proposing a solution, restate the goal, constraints, and the non-goal.
  • Surface ≥2 alternatives: For non-trivial decisions, present at least two viable options with a one-line trade-off each.
  • Ripple-effect analysis: Assess blast radius including affected files, contracts, downstream consumers, reversibility, and migration needs.
  • Grounding discipline: Cite external sources for architectural invariants and surface assumptions with verifiable evidence.

Quick Start

Use the architect skill to frame a design issue before proposing a solution, and surface two alternatives with trade-offs.

Frequently Asked Questions about architect

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

FAQPage Schema
How do I evaluate trade-offs for multi-component architecture decisions?▼

To evaluate trade-offs for multi-component architecture decisions, restate the goal and constraints, then surface at least two viable alternatives with a one-line trade-off each. This ensures a structured evaluation before implementation.

What is ripple-effect analysis for shared contract modifications?▼

Ripple-effect analysis for shared contract modifications assesses the blast radius of a change, including affected files, downstream consumers, reversibility, and migration needs. It ensures alignment and traceability across modules.

How do I frame architecture goals before proposing a new abstraction?▼

Framing architecture goals before proposing a new abstraction requires explicitly restating the goal, constraints, and non-goals. This disciplined approach prevents premature solutions and ensures reproducible decision-making.

When do I need to document architecture decisions for multi-module changes?▼

You need to document architecture decisions for multi-module changes when introducing a new abstraction, modifying a shared contract, or requiring design alternatives to ensure traceability and alignment across the affected components.

Does this approach require citing external sources for architectural invariants?▼

Yes, this approach enforces grounding discipline by requiring you to cite external sources for architectural invariants and surface assumptions with verifiable evidence to ensure disciplined, reproducible decisions.