claude-skills 的 GraphQL Architect 技能：从 Schema 设计到 Apollo Federation 与订阅的完整架构实战

claude-skills 的 GraphQL Architect 技能从 Schema 设计到 Apollo Federation 与订阅的完整架构实战【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills导读GraphQL Architect 是 claude-skills 项目中负责 API 架构设计的专业级技能聚焦于 GraphQL Schema 设计、Apollo Federation 2.5 分布式图架构、实时订阅与性能优化四大领域。本文基于 skills/graphql-architect/SKILL.md 及其全套 references 文档完整还原该技能的六步核心工作流、全部代码范式与约束规则并结合仓库源码逐层拆解 Schema 类型系统、子图联邦、DataLoader 防 N1、安全防护与 REST 迁移方案。读完本文你将掌握一套可直接落地的 GraphQL 架构设计方法论以及一套可复用的 Schema、Resolver、订阅与安全实现模板。一、技能定位它在 claude-skills 生态中扮演什么角色从 SKILL.md 的 frontmatter 可以清晰看到该技能的定位metadata: version: 1.1.0 domain: api-architecture triggers: GraphQL, Apollo Federation, GraphQL schema, API graph, GraphQL subscriptions, Apollo Server, schema design, GraphQL resolvers, DataLoader role: architect scope: design output-format: schema related-skills: api-designer, microservices-architect, database-optimizer领域domainapi-architecture说明它专注于 API 架构层的设计决策而非单纯代码生成。角色role与范围scopearchitect / design强调该技能在动手实现前先完成架构设计与 Schema 建模。触发词triggers覆盖 GraphQL 全栈关键词——Schema 设计、Apollo Federation、订阅、Apollo Server、Resolver、DataLoader。关联技能related-skills与 api-designerAPI 设计规范、microservices-architect服务边界划分、database-optimizer数据层优化形成协作矩阵——GraphQL 的 Federation 子图边界通常需要微服务架构技能配合而 Schema 背后的查询性能又依赖数据库优化技能兜底。按照该仓库的「上下文感知激活」机制见 README.md当开发者提出「实现 JWT 认证的 NestJS API」这类请求时对应技能会自动加载 references 文档。GraphQL Architect 的激活路径则是遇到 GraphQL Schema 设计、Federation 或订阅相关请求时根据具体上下文按需加载 6 份参考文档。二、六步核心工作流从领域建模到性能调优SKILL.md 将 GraphQL 架构工作定义为一条严格的流水线领域建模Domain Modeling——把业务域映射到 GraphQL 类型系统这是 Schema 设计的起点。设计 SchemaDesign Schema——创建 types、interfaces、unions并带上 Federation 指令。校验 SchemaValidate Schema——运行 Schema composition 检查确认所有key实体都能正确解析。失败处置若组合失败重新审查实体的key指令检查各子图间缺失或错配的类型定义解决external字段不一致问题后重新运行组合。实现 ResolverImplement Resolvers——用 DataLoader 模式编写高效 resolver。安全加固Secure——添加查询复杂度限制、深度限制、字段级鉴权部署前必须验证复杂度阈值。阈值超标处置定位成本最高的字段加分页限制重构嵌套查询或在有文档依据的前提下提高阈值。性能优化Optimize——通过缓存、持久化查询persisted queries与监控做性能调优。这条工作流的关键在于每一步都有明确的校验点与失败回退路径组合失败检查key/external复杂度超标则逐层降成本。这正是架构级技能与普通代码生成的最大区别——先立 Schema再谈实现最后过安全关。三、Schema 设计类型系统的完整建模范式schema-first 是 GraphQL Architect 的第一铁律。参考 references/schema-design.md一个高质量的 Schema 需要覆盖七类建模要素。3.1 对象类型Object Types字段即契约对象类型是领域实体的载体。参考文档给出了 User/Profile/Post 的完整建模示例其要点包括每个字段都必须带描述...块注释与行内...双管齐下让 Schema 自身可被 GraphQL introspection 直接呈现为 API 文档关系字段天然携带分页参数如posts(first: Int 10, after: String): PostConnection!从 Schema 层就杜绝无限制返回全部关联数据可空性表达业务语义username: String可选昵称与profile: Profile未完成则 null是刻意设计的可空字段。3.2 接口与联合类型多态建模的两种工具接口Interfaces用于「共享字段」场景。参考文档中的Timestamped与Searchable接口被Article、Video同时实现Query.search(query: String!): [Searchable!]!允许一次查询命中不同实现类型——这对搜索、时间线等聚合场景极其关键。联合类型Unions用于「互斥多态」场景。union SearchResult Article | Video | Podcast和union Notification CommentNotification | LikeNotification | FollowNotification表示返回结果必然是其中一种具体类型且联合成员不共享任何强制字段。经验法则接口表达「都是什么」的共同点联合表达「是其中哪一个」的多样性。前者适合搜索后者适合通知流、结果集。3.3 枚举、输入类型与自定义 Scalar枚举PostStatusDRAFT/PUBLISHED/ARCHIVED/DELETED、UserRoleADMIN/MODERATOR/USER/GUEST、SortOrder把魔法字符串固化进 Schema配合orderBy: SortOrder DESC这类默认值约束查询行为。输入类型所有 Mutation 参数必须收敛到input对象。参考文档中的CreateUserInput、UpdatePostInput、PostFilterInput分别服务创建、更新与过滤三个场景其中PostFilterInput容纳status、authorId、tags、createdAfter/before等复杂筛选条件。自定义 ScalarDateTimeISO 8601、URL、Email、JSON、PositiveInt用于表达领域专属的语义约束而不是让客户端解析原始字符串。3.4 分页Relay 规范的游标连接参考文档完整给出了 Relay 规范的三件套——PostConnection含totalCount扩展、PostEdgenode cursor、PageInfohasNextPage/hasPreviousPage/startCursor/endCursor查询面同时支持first/after与last/before双向翻页。游标分页比 offset 分页在数据变化场景下更稳定是列表查询的默认推荐。3.5 可空性最佳实践精确表达数据边界这是最容易出错的建模环节参考文档用一组对照示例讲透了组合语义tags: [String]! # 非空列表元素可空——列表永远存在可为空列表元素可为 null roles: [UserRole!]! # 非空列表非空元素——最严格既保证列表存在又保证元素非空 posts: [Post!] # 可空列表非空元素——列表可能为 null但一旦存在则元素全非空对应到查询面users: [User!]!表示查询总能返回结果无数据时为空列表user(id: ID!): User表示查不到时返回 nullcurrentUser: User!表示要么返回结果要么抛错。原则字段默认可空只有「保证存在」才标记非空避免把可空错误升级为整个响应的失败。3.6 字段弃用与 Schema 文档化弃用deprecated(reason: Use username instead)必须在 reason 中给出迁移路径例如Migrating to UUID. Will be removed 2025-06-01——弃用不是删除而是可追踪的演进。文档化类型级...描述中直接内嵌示例查询如query GetUser让 GraphiQL 一打开就能看到可执行的用法示范。最后参考文档给出十条设计原则可空字段默认、列表用[Type!]!、全部类型字段带描述、字段 camelCase/类型 PascalCase、接口表达共享字段、联合表达多态返回、Mutation 专用输入类型、领域专属自定义 Scalar、弃用带迁移路径、文档内嵌示例查询。四、Apollo Federation 2.5跨子图的分布式图架构Federation 是 graphql-architect 的差异化能力参考 references/federation.md 完整覆盖了从子图搭建到网关编排的全链路。4.1 子图与实体键key是联邦的基石每个子图独立暴露 Schema并通过link引入 Federation 2.5 规范# users-subgraph/schema.graphql extend schema link(url: https://specs.apollo.dev/federation/v2.5, import: [key, shareable]) type User key(fields: id) { id: ID! email: String! username: String! createdAt: DateTime! }key声明「实体的全局身份」支持三种形态单键key(fields: id)最常见的标识方式复合键type Variant key(fields: productId sku)多字段联合定位实体多键key(fields: id) key(fields: productId authorId)允许通过不同字段组合引用同一实体。被key标记的实体需要通过__resolveReference让网关能按引用还原真实数据见下节 Resolver 部分。4.2 跨子图扩展类型external与__resolveReferenceposts 子图可以「扩充」users 子图拥有的User类型# posts-subgraph: extends User with posts extend type User key(fields: id) { id: ID! external posts: [Post!]! }external声明id由别的子图负责posts 子图只追加posts字段。对应的 resolver 必须实现两层逻辑——用__resolveReference返回实体桩再在字段级 resolver 中解析真实数据const resolvers { User: { __resolveReference: async (reference: { id: string }, context: Context) { return { id: reference.id }; // 返回实体桩 }, posts: async (user: { id: string }, args, context: Context) { return context.dataSources.posts.findByAuthor(user.id); // 字段级解析 }, }, Post: { author: (post: Post) ({ __typename: User, id: post.authorId }), // 返回实体引用 }, };4.3 指令全谱external/requires/provides/shareable/override/inaccessible/tag指令用途参考示例external声明字段由其他子图定义id: ID! externalrequires本子图计算依赖其他子图字段canPost: Boolean! requires(fields: email isVerified)provides优化提示本子图能直接提供某字段减少跨子图回源author: User! provides(fields: username)shareable字段可由多个子图解析强一致要求值相同sku: String! shareableoverride从旧子图接管字段支持渐进式迁移price: Float! override(from: legacy-subgraph)inaccessible对内可见、对 supergraph 隐藏internalId: String! inaccessibletag按环境/用途打标签组织 Schemaproducts: [Product!]! tag(name: public)4.4 网关配置与 Managed Federation网关通过IntrospectAndCompose聚合多个子图地址并轮询拉取 Schema 变更const gateway new ApolloGateway({ supergraphSdl: new IntrospectAndCompose({ subgraphs: [ { name: users, url: http://localhost:4001/graphql }, { name: posts, url: http://localhost:4002/graphql }, { name: products, url: http://localhost:4003/graphql }, ], pollIntervalInMs: 10000, // 10 秒轮询一次子图 Schema }), serviceHealthCheck: true, debug: process.env.NODE_ENV development, });而 Managed Federation 则把组合composition上移到 Apollo Studio网关不再感知子图 URL改由supergraphSdl({ update })从 Apollo Uplink 拉取已组合的 supergraph SDL子图侧通过ApolloServerPluginInlineTrace上报内联追踪——这是生产环境实现安全部署、灰度发布的推荐形态。4.5 值类型 vs 实体、interfaceObject与查询计划优化值类型Value Types无key的纯数据结构如Address完全由单个子图解析、不可被扩展实体Entities有key、可被其他子图扩展。判断标准就是「是否需要跨服务引用」。interfaceObject当 orders 子图只认识接口Account、不认识其实现User/AdminUser时用type Account key(fields: id) interfaceObject以接口身份引用实体从而在不复制实现细节的前提下完成关联。查询计划优化provides能让网关在部分场景下直接从 posts 子图满足 User 的某些字段避免回源 users 子图产生额外往返roundtrip这是分布式图性能调优的核心杠杆。4.6 联邦错误处理与十条最佳实践__resolveReference的错误处理遵循「软硬分层」实体不存在返回null软错误客户端仍能拿到其他字段真正失败则抛出带extensions.code与上下文如userId的GraphQLError硬错误。最佳实践清单包括需要被扩展的类型才用key、子图边界对齐团队/服务边界、shareable只用于真正共享的字段、用override渐进迁移、用provides优化查询计划、在 CI/CD 中测试 Schema 组合、用 Managed Federation 保证安全部署、监控查询计划与 resolver 性能、文档化实体归属与扩展模式。五、Resolver 实现Context、DataLoader 与错误处理参考 references/resolvers.mdResolver 是 Schema 的执行引擎其质量直接决定 API 的吞吐上限。5.1 Resolver 签名与 Context 设计标准签名(parent, args, context, info)中context是每次请求的「容器」参考文档建议打包四类东西user已认证用户、dataSources数据访问层、loadersDataLoader 实例、req与authToken。关键约束每个请求创建全新的 loaders绝不能跨请求复用——DataLoader 的缓存周期就是请求生命周期。5.2 DataLoader从根源消灭 N1N1 问题的本质是「N 个实体各触发 1 次子查询」。DataLoader 通过**批处理batching 缓存caching**把它变成 1 次查询const context ({ req }) ({ loaders: { user: new DataLoader(async (userIds) { const users await db.users.findMany({ where: { id: { in: userIds } } }); // 返回值必须与输入 key 顺序一致缺失补 null return userIds.map((id) users.find((u) u.id id) ?? null); }), }, }); const resolvers { Review: { author: (review, _args, { loaders }) loaders.user.load(review.authorId), }, };loaders.user.load(review.authorId)会把同一事件循环内的所有 authorId 聚合为一次IN查询。参考文档进一步给出了batchScheduleFn: (cb) setTimeout(cb, 10)10ms 窗口合并请求与maxBatchSize: 100等调优参数以及「一对多」场景的postsByAuthorLoader——批量查出所有帖子后按 authorId 分组回填。凡是外键关系一律走 DataLoader这是 MUST DO 约束中的硬性要求。5.3 接口与联合类型的__resolveType接口Searchable与联合SearchResult都必须实现__resolveType判别具体类型参考文档给出的判别顺序是content in obj → Article、duration in obj → Video、audioUrl in obj → Podcast未命中则throw new Error(Unknown Searchable type)。5.4 结构化错误处理参考文档的推荐是抛出带extensions的结构化GraphQLError未找到GraphQLError(User not found, { extensions: { code: USER_NOT_FOUND, http: { status: 404 }, userId: args.id } })未认证ApolloServerErrorCode.UNAUTHENTICATED 401越权ApolloServerErrorCode.FORBIDDEN 403更新失败code: UPDATE_FAILED并携带originalError便于排障。同时参考文档明确「在 resolver 中做鉴权、不要在 data source 中做」——数据层只负责数据权限判断属于 API 层职责。5.5 分页 Resolver 的完整实现Relay 游标分页的 resolver 核心技巧是「多取一条判断 hasNextPage」limit Math.min(args.first || 10, 100)硬性封顶同时first与last会被拒绝取limit 1条超过 limit 即hasNextPage true随后用encodeCursor/decodeCursor完成游标编解码。这是可无限滚动的fetchMore场景的标准后端配套。六、实时订阅WebSocket、Pub/Sub 与连接治理参考 references/subscriptions.md订阅是 GraphQL 区别于 REST 的核心能力之一。6.1 传输层搭建graphql-ws HTTP 双通道订阅通过 WebSocket 承载查询与变更仍走 HTTP。服务端典型结构是expresshttpServerWebSocketServer({ path: /graphql })useServer(...)其中useServer的context从connectionParams.authorization提取令牌并验证用户同时通过ApolloServerPluginDrainHttpServer与drainServer保证优雅关闭。6.2 Pub/Sub 两档方案开发环境内存版new PubSub()graphql-subscriptions生产环境RedisPubSub分离publisher与subscriber两个 Redis 连接并配置retryStrategy: (times) Math.min(times * 50, 2000)退避策略——Redis 是水平扩展时跨实例广播事件的必备通道。所有事件名收敛到常量对象EVENTS { POST_CREATED, POST_UPDATED, COMMENT_ADDED, USER_ONLINE } as const避免魔法字符串漂移。6.3withFilter服务端过滤与鉴权withFilter是订阅的过滤原语参考文档给出了从简单到复杂的三个层级按变量过滤payload.postUpdated.id variables.id只推送指定实体的更新连接期鉴权subscribe 回调内先检查context.user未认证直接 throw异步权限过滤filter 回调内查数据库判断post.isPublic || post.authorId context.user.id兼顾过滤与越权防护。6.4 连接与订阅生命周期治理useServer暴露完整的生命周期钩子onConnect校验令牌、拒绝无凭证连接、onDisconnect、onSubscribe订阅数限流——超过 10 个订阅直接拒绝、onComplete以及connectionInitWaitTimeout: 10000心跳兜底。此外还展示了四种订阅模式实体更新entityUpdated(id: ID!)、集合变更entityAdded/entityDeleted、事件流events(types: [EventType!])、轮询式 live query异步生成器async function*每 5 秒 yield 一次搜索结果。6.5 客户端接入与水平扩展客户端用split按操作类型分流getMainDefinition(query).operation subscription走GraphQLWsLinkWebSocket其余走HttpLinkWebSocket 连接通过connectionParams.authorization携带令牌。水平扩展的要点是多实例必须用RedisPubSub带publisherPrefix/subscriberPrefix通道隔离前缀并用粘性会话sticky sessions保证同一用户的连接状态绑定在同一实例。最佳实践清单还强调始终在onConnect与 filter 中做认证授权、限制每用户订阅数、断连时清理订阅、监控活跃连接与订阅数。七、安全加固GraphQL 特有的攻击面防护参考 references/security.mdGraphQL 的安全模型与 REST 截然不同——单一入口意味着攻击面高度集中因此必须叠加多层防护。7.1 深度限制拦截递归炸弹graphql-depth-limit将查询深度硬限制在 7 层并对 Federation 内部字段_service、_entities与 Relay 结构字段pageInfo、edges、node放行。参考文档用 8 层嵌套的user → posts → author → ...示例直观展示了拒绝机制——这是抵御深度递归 DoS 的第一道闸门。7.2 复杂度分析为每个字段定价深度限制挡不住「横向爆炸」必须引入复杂度complexity核算。参考文档展示了两套实现内置估算器标量字段计 1列表字段按first参数 × 子复杂度累乘超限即抛出带code: COMPLEXITY_LIMIT_EXCEEDED、cost、limit的结构化错误自定义cost指令在 Schema 中声明directive cost(complexity: Int!, multipliers: [String!]) on FIELD_DEFINITION为昂贵字段显式定价例如analytics: Analytics! cost(complexity: 50)、users(first: Int 10): [User!]! cost(complexity: 1, multipliers: [first])并配套给出了指令参数解析的完整实现代码。7.3 速率限制与认证授权速率限制IP 维度用express-rate-limitRedisStore15 分钟 100 次用户维度用rate-limiter-flexible的RateLimiterRedis1000 点/60 秒超限封禁 5 分钟失败时在extensions中返回retryAfter认证JWT 在 context 创建期完成验签verifyToken失败返回null而非抛错保证匿名请求也能进入公共字段授权提供三种范式——auth(requires: Role)指令化鉴权通过mapSchemagetDirective包装字段 resolver、resolver 内声明式检查requireAuth()、字段级脱敏仅作者或 ADMIN 可见authorEmail否则返回 null。7.4 持久化查询、Introspection 控制与输入校验持久化查询Allowlist客户端用 SHA-256 哈希代替完整 query 文本createPersistedQueryLinkuseGETForHashedQueries服务端persistedQueries.cache只认哈希生产环境可进一步用手动白名单allowedOperationsGetUser/GetPosts/CreatePost/UpdatePost未知 operationName 直接拒绝——这是最彻底的防滥用手段Introspection生产环境introspection: false并禁用 Landing Page或实现「仅 ADMIN 可 introspection」的条件放行输入校验Mutation 输入先用 Zod Schema如CreatePostSchematitle 3~200 字符、tags 最多 5 个safeParse失败返回code: BAD_USER_INPUT并携带逐字段校验错误CSRF 防护csurf中间件对 POST/graphql校验CSRF-Token头。安全最佳实践总计十二条深度限制、复杂度分析、速率限制、认证、授权、输入校验、查询白名单、Introspection 控制、错误脱敏、CORS 白名单、强制 HTTPS、敏感操作审计日志。八、REST 迁移到 GraphQL决策框架与四步落地参考 references/migration-from-rest.md该技能同时承担「是否该迁移」的决策顾问角色而非一味鼓励迁移。8.1 迁移决策框架该迁的信号复杂 UI 需要多次往返聚合数据、过度/不足取数严重、客户端类型多样移动/Web/桌面、团队边界需要联邦化 API、实时订阅是核心需求、跨客户端类型安全要求高、REST 版本化成本失控。不该迁的信号稳定客户端的简单 CRUD、以文件上传下载为主、强依赖 HTTP 缓存CDN/浏览器、团队无 GraphQL 经验与培训预算、现有 REST 已足够好、第三方集成强制 REST、查询复杂度会带来安全风险。小团队1~2 人、纯服务间通信、静态内容分发也是明确的警告信号。8.2 REST 概念映射表迁移的路线图REST 概念GraphQL 对应说明GET /usersQuery.users读操作GET /users/:idQuery.user(id: ID!)单实体获取POST /usersMutation.createUser创建PUT /users/:idMutation.updateUser更新DELETE /users/:idMutation.deleteUser删除PATCH /users/:idMutation.updateUserPartial部分更新查询参数?filter字段参数过滤/排序URL 路径段嵌套字段选择数据关系多个端点单个查询消灭往返Webhook 回调订阅实时更新HTTP 状态码errors数组 data部分成功模型API 版本号Schema 演进用弃用替代版本/users?includepostsusers { posts }客户端控制预取offset 分页游标连接Relay 规范OAuth/JWTcontext 认证认证模式相同8.3 四个迁移模式模式一GET → Query——把端点改造成 Query 与嵌套选择并用createUserByIdLoader/createPostsByUserIdLoader双 DataLoader 避免重蹈 REST 中的 N1 覆辙客户端示例展示MINIMAL_USER与DETAILED_USER两种取数粒度以及一次 Query 替代多次 REST 调用的仪表盘场景模式二POST/PUT/DELETE → Mutation——引入 Payload 模式CreateUserPayload { user, errors }将字段级校验错误fieldmessagecode返回给客户端在表单上逐项渲染取代 REST 的 4xx 状态码模式三分页迁移——把 REST offset 分页改造成 Relay 游标连接resolver 通过「多取一条」判断hasNextPage、base64 编解码游标客户端用fetchMore实现无限滚动模式四认证翻译——REST 中间件验签逻辑平移到 GraphQL context并额外提供requireAuth()助手统一抛出UNAUTHENTICATED错误字段级鉴权email仅本人或 ADMIN 可见是 REST 难以优雅实现的差异化能力。此外还给出了BFFBackend for Frontend架构针对移动端反范式化、少往返与 Web 端细粒度、易缓存分别构造 Schema通过x-client-type请求头路由到不同 Apollo Server。8.4 四阶段增量迁移策略Phase 1第 1~2 周GraphQL 包装层——resolver 内部fetch现有 REST 端点客户端立即接入而无需后端重写Phase 2第 3~6 周并行实现——resolver 直连数据库用GRAPHQL_ENABLED特性开关灰度切换流量Phase 3第 7~12 周客户端迁移——setContext注入x-graphql-migration: phase-3头做 A/B 对比监控性能与错误率Phase 4第 13 周起REST 下线——旧端点返回410 GonesunsetDate最终整体移除。8.5 五大陷阱与完成标准常见陷阱包括N1 查询未用 DataLoader、直接把数据库结构泄露进 Schemauser_id/created_at这类列名与原始类型、resolver 一个抛错拖垮整个响应应改为字段级 try/catch 的部分成功模型、忽略查询复杂度被昂贵查询打挂服务、过度范式化userName/userEmail/userPosts拆散为多个顶层字段。迁移完成的验收标准是关键路径全部走 GraphQL、REST 端点带日落日期弃用、客户端全部迁移、性能指标达到或超过 REST 基线。九、约束体系与交付物规范SKILL.md 用 MUST DO / MUST NOT DO 两栏固化了质量底线这是该技能输出的验收标尺。MUST DO必须schema-first 设计、正确的可空字段模式、用 DataLoader 做批处理与缓存、加查询复杂度分析、文档化全部类型与字段、遵循 camelCase 命名规范、正确使用 Federation 指令、为所有操作提供示例查询。MUST NOT DO禁止制造 N1 查询问题、跳过查询深度限制、暴露内部实现细节、在 GraphQL 中套用 REST 模式、给非空字段返回 null、resolver 不做错误处理、硬编码授权逻辑、忽略 Schema 校验。交付物规范Output Templates实施任何 GraphQL 功能时必须产出四件套——① Schema 定义含类型与指令的 SDL② Resolver 实现含 DataLoader 模式③ Query/Mutation/Subscription 示例④ 设计决策的简短说明。从知识面来看该技能覆盖 Apollo Server、Apollo Federation 2.5、GraphQL SDL、DataLoader、GraphQL Subscriptions、WebSocket、Redis pub/sub、Schema 组合、查询复杂度、持久化查询、Schema stitching、类型生成等完整技术栈是一套从设计、实现、安全到运维的闭环方法论。十、延伸阅读技能主文档skills/graphql-architect/SKILL.md参考文档Schema 设计 schema-design.md、Federation federation.md、Resolver resolvers.md、安全 security.md、订阅 subscriptions.md、REST 迁移 migration-from-rest.md协作技能api-designer、microservices-architect、database-optimizer技能总览SKILLS_GUIDE.md、项目入口 README.md说明本文所有代码与参数均来自上述仓库文件。Federation 指令导入地址、Apollo 生态依赖版本等以当前仓库写法为准实际接入时请对照你所使用的 Apollo Server / Gateway 版本验证 API 兼容性。【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考