arch-engineering

Guides full-stack engineering practices covering API design, authentication, caching, and cloud-native infrastructure.

7.1k|1.1k|Updated Mar 5, 2026
One-click install
npx skills add https://github.com/openJiuwen-ai/jiuwenswarm --skill arch-engineering
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: arch-engineering
Source: https://github.com/openJiuwen-ai/jiuwenswarm/tree/main/jiuwenswarm/resources/agent/workspace/plugins/agent_templates/system-architect/skills/arch-engineering
Command: npx skills add https://github.com/openJiuwen-ai/jiuwenswarm --skill arch-engineering

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Full-stack projects often suffer from inconsistent layering, ad-hoc configuration, untyped errors, unstable API contracts, and weak authentication design. This Skill provides concrete engineering practices and decision frameworks so teams can implement project layering, configuration management, error handling, API governance, auth architecture, and cloud-native infrastructure consistently.

Core Features & Use Cases

  • Full-Stack Architecture Practices: Feature-first project structure, three-layer architecture (Controller/Service/Repository), dependency injection patterns in TypeScript/Python/Go, typed error systems, N+1 query prevention, caching patterns, and real-time communication selection (SSE/WebSocket).
  • API Design & Governance: Decision trees for REST/GraphQL/gRPC/tRPC, REST design conventions, versioning and backward-compatibility rules, API gateway and BFF patterns, and OpenAPI contract management.
  • Auth, Infrastructure & Observability: JWT vs Session decisions, RBAC four-layer permission checks, middleware ordering, OAuth2/OIDC flows, Kubernetes namespace and service mesh selection, multi-region deployment, IaC modularization, OpenTelemetry integration, RED/USE metrics, and event-driven patterns (Transactional Outbox, CDC, idempotent consumers).
  • Use Case: When designing a new order service, use this Skill to choose the API style, structure the codebase by feature, implement JWT authentication with RBAC, set up structured logging with trace IDs, and select a message broker with an outbox pattern.

Quick Start

Ask the agent to design the engineering architecture for a new full-stack service, including project layering, API style selection, JWT authentication flow, and observability setup.

Frequently Asked Questions about arch-engineering

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

FAQPage Schema
How do I choose between REST, GraphQL, gRPC, and tRPC for my API?

Choose based on the consumer: tRPC for same-team TypeScript full-stack, REST with OpenAPI for multi-language or external consumers, GraphQL when clients need flexible queries, and gRPC for high-performance internal service-to-service communication.

How do I structure a full-stack project with clean layering?

Organize code by feature rather than technical layer, and apply three-layer architecture: Controllers handle HTTP parsing and validation, Services contain business logic without HTTP types, and Repositories handle database access. Use dependency injection to wire components.

Should I use JWT or Session for authentication?

Use JWT when you need stateless authentication without shared session storage, pairing short-lived access tokens with server-stored refresh tokens. Use Session for traditional web apps where active invalidation matters, backed by Redis for multi-instance deployments.

How do I prevent N+1 query problems in database access?

Replace per-record queries with a single JOIN or eager-loading query, such as using include options in ORM calls. Also manage transactions around multi-write operations and size connection pools based on CPU cores and disk count.

When should I use the Transactional Outbox pattern?

Use it whenever database writes and message publishing must stay consistent. Write the business record and an outbox row in one transaction, then a separate process publishes pending events, avoiding lost messages if the broker call fails.

When is event sourcing not a good fit?

Avoid event sourcing for simple CRUD domains, teams unfamiliar with the pattern, or systems without audit-trail requirements. It also fits poorly when state changes are extremely frequent, since event storage grows quickly and requires snapshot optimization.