go-microservice-architecture

Go Microservice Architecture

Use this for new product/server architecture work. It distills proven backend patterns but must not assume any existing repository, service identifier, package path, database, or legacy service layout.

Skill Routing

• Use this skill for architecture decisions, service decomposition, API/RPC contract shape, storage ownership, async workflow design, observability, reliability, and launch readiness.
• Use product-rd-workflow first when the request spans product shaping, architecture, implementation, review, release, and learning loops rather than architecture alone.
• Use go-microservice-dev when the user asks to implement, modify, debug, test, scaffold, or generate code. A localized refactor (某文件/某类) also belongs to go-microservice-dev; only service-wide layering/boundary redesign stays here, and a multi-stage / cross-module refactor delivery must re-enter product-rd-workflow. An unqualified whole-service "Go 服务重构" enters here by default, mirroring the Python pair — do not let the unqualified form fall to the implementation skill.
• Use python-service-architecture for Python services. Do not load Python rules for Go work unless the task is explicitly cross-language contract design.
• Use platform-observability for logs/metrics/traces/log-id propagation/dashboards/alerts/SLI-SLO design. This skill owns only the service-side observability surface (Kitex/Hertz middleware that emits structured logs, OTel SDK use, baseline labels attached by metrics client, health endpoints); the cross-cutting evidence stack belongs there.
• Use platform-service-connectivity for service mesh, service discovery (Nacos/Consul/equivalent), mTLS, multi-environment lane routing, retry/timeout/circuit-breaker policy, and the canonical RPC base struct shape. This skill defines what the service exposes (framework default options usage, request-metadata propagation conformance via the platform's chosen carrier — in-message base or transport metadata, scenario-driven per the connectivity Carrier decision — graceful shutdown); mesh policy and routing rules live there.
• Use platform-release-engineering for environment/lane matrix, canary/blue-green, promotion gates, rollback playbook, secret distribution, dynamic-config (config-center) vs static-config split, image build pipeline. This skill owns the service-side contracts (config schema, secret consumption interface, registration metadata); release flow lives there.
• Use codebase-specific skills only when the task is explicitly about an existing legacy/workspace repository.
• Architecture references should define decision criteria, invariants, ownership boundaries, and acceptance checks. Put concrete code patterns, helper APIs, and test mechanics in go-microservice-dev.
• When changing an architecture rule that implementation must obey, name the downstream execution owner before landing: go-microservice-dev for code mechanics, testing-strategy for proof layer, platform skills for runtime contracts, and product-rd-workflow for cross-stage gates. If the rule also applies outside Go, route through skill-extraction-workflow and mirror or explicitly skip sibling architecture/dev skills.
• For money, billing, quota, permission, tenant/user data isolation, privacy, high-impact AI, repeated writes, async finality, or incident-explanation risk, start from product-rd-workflow and its high-risk resilience gate before choosing service boundaries or fallback behavior.