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.