agentsclimarketplace
Sign in

Architect

Skill Brayanhenaor/ai-standards/skills/architect

Senior-architect lens for decisions that cross services, layers, or systems. Use when designing a feature that spans boundaries, choosing between architectural approaches, adding an external integration, or anything affecting scalability, availability, or operational complexity. Surfaces trade-offs and failure modes before code is written.From its SKILL.md

Install
npx -y skills add Brayanhenaor/ai-standards --skill architect

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

  • 1 stars1 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.

SKILL.md

2.4 KB, as published. Nobody here has run it

Architect lens

Apply when a decision reaches beyond a single class — across services, layers, data stores, or system boundaries. The job is to surface trade-offs and failure modes early, when they're cheap to change.

What to examine

  • Boundaries & coupling. Are responsibilities in the right place? Does this change couple things that should evolve independently, or leak one layer's concerns into another? Dependencies should point inward (toward stable policy), not outward toward detail.
  • Scalability. What happens at 10×/100× load or data? Where's the bottleneck — CPU, a shared DB, a single writer, a lock? Does the design scale horizontally, or does some shared state prevent it?
  • Availability & fault tolerance. What fails when a dependency is slow or down? Is failure contained (timeouts, circuit breakers, bulkheads, graceful degradation) or does it cascade? No single point of failure on a critical path.
  • Distributed-systems consistency. Crossing a process boundary trades a guarantee for a trade-off. Is strong consistency actually needed, or is eventual fine? How are partial failures, retries, and duplicate delivery handled (idempotency, outbox, sagas)?
  • Data ownership. One owner per piece of data. Are you reaching into another service's store? Is a shared database coupling services that should be independent?
  • Operational complexity. Every moving part is something to deploy, monitor, and debug at 3am. Is the added complexity justified by a real, present need — or is it architecture astronautics?

Discipline

  • Simplest architecture that meets real requirements. Don't add services, queues, caches, or layers for scale or flexibility nobody has asked for — that's over-engineering at the system level. A modular monolith often beats premature microservices.
  • Present options with trade-offs (complexity, scalability, availability, cost, operability) and a recommendation. Name the failure modes explicitly.
  • Flag anything worth an ADR. Hand the chosen approach to plan for step breakdown.

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.