安装方式
手动下载安装
下载 ZIP 后解压到技能目录即可安装。若在桌面客户端 WebView中直接下载出现异常,本站会改为提示页 + 原始链接,请按页内说明操作。
下载 ZIP (shub-graphql-v1.0.1.zip)触发指令
/graphql
跨平台安装指引
该技能声明兼容以下 1 个平台,将 ZIP 解压到对应目录即可被识别。
unzip shub-graphql-v1.0.1.zip -d ~/.claude/skills/
mkdir -p 创建;启用 Skill 后请重启对应 Agent 让配置生效。
使用指南
GraphQL 开发
围绕 GraphQL 开发:Schema、Resolver、查询优化与 N+1 规避;订阅与上传等高级主题见 ZIP。 无需在每次任务前把零散英文说明手工拼进上下文,也 减少 与客户端默认行为脱节的试错;具体命令、钩子与 JSON 参数仍以 ZIP 包内 SKILL.md 为权威。下文结构与站内 MCP CLI 类专题稿相同:何时用、前置、流程、速查与故障。
何时使用
- Schema、Resolver、查询优化与 N+1 规避
- 订阅与上传等高级主题见 ZIP
- 已获取本技能 ZIP,并准备在 Claude Code / OpenClaw 中按 SKILL.md 挂载。
- 希望用中文专题稿快速判断「该不该启用」,再深入英文 SKILL 查参数与边界。
- 需要与团队对齐同一套触发方式、目录约定或回调格式时。
前置条件
- 通用:可运行 Claude Code 或文档要求的客户端;有可读写的项目工作区(或 SKILL.md 指定的沙箱目录)。
- 权威细节:API Key / OAuth、钩子路径、环境变量以 ZIP 内 SKILL.md 为准。
典型流程
- 从 ClawHub / 站内分发获取技能 ZIP,校验版本与校验和(若提供)。
- 阅读 SKILL.md 的安装段落:目录落点、客户端类型(Claude Code / OpenClaw / 脚本)。
- 用文档中的最小示例完成第一次调用(单文件修改、单次查询或单次委派)。
- 确认工作目录、权限边界与输出路径后,再处理多文件或长耗时任务。
- 需要回调 / Webhook / 通知时,按 SKILL.md 配置端点并在测试环境先验通。
与 ZIP / SKILL.md 的关系
站内专题稿与 MCP CLI 类 oss 稿同样:概括何时用、怎么接、怎么排错;命令模板、钩子名、JSON 字段、版本矩阵一律以 ZIP 内 SKILL.md 与 ClawHub 上游为准。
命令示例(摘自包内 SKILL.md)
以下为从上游 SKILL.md(或入库正文)自动抽取的终端/脚本片段;路径、环境变量与参数以当前 ZIP 与官方说明为准。
ClawHub slug:graphql(安装命令以 SKILL.md / claw CLI 为准)。
站内入库时的触发命令(完整语义见 ZIP):
# 使用本技能时可在对话中引用或执行上述指令;完整参数与示例见下载包内 SKILL.md。
/graphql
最佳实践
- 先 SKILL.md 再猜参数;站内专题稿不替代 schema 与必填字段说明。
- 委派任务时写清验收标准(命令、文件路径、测试命令),减少来回追问。
- 长任务用文档推荐的回调 / 日志落盘代替高频轮询,省 Token 也省机器负载。
- 多技能同时启用时,注意钩子加载顺序与重复工具调用(以 SKILL.md 冲突说明为准)。
调试与排错
- 打开 stderr 与客户端日志;PTY/tmux 场景同时看面板最后几十行输出。
- 参数错误时对照 SKILL.md 中的 JSON/CLI 示例(引号、转义、工作目录)。
- 网络类失败:查代理、防火墙、MCP 传输方式(stdio / HTTP / SSE)。
速查
| 动作 | 说明 |
|------|------|
| 获取技能包 | ClawHub / 站内 ZIP,核对版本 |
| 权威步骤 | 优先阅读 ZIP 内 SKILL.md |
| 首次试跑 | 使用 SKILL.md 最小示例 |
| 验收 | 对照路径、测试命令或回调负载 |
常见故障
- 无输出或立即退出 → 工作目录错误、依赖未装、或 Claude Code 未登录;按 SKILL.md 自检清单执行。
- 权限被拒绝 → 检查沙箱路径、
--permission-mode与工具白名单。 - 与简介不符 → 以英文 SKILL 与上游仓库为准,站内稿仅作结构化导读。
## Quick Reference
| Topic | File |
|-------|------|
| Schema design patterns | `schema.md` |
| Security and limits | `security.md` |
| Performance optimization | `performance.md` |
| Client-side patterns | `client.md` |
## N+1 Problem (Critical)
- Each resolver runs independently—fetching user for each of 100 posts = 100 queries
- DataLoader required: batches requests within single tick—100 posts = 1 user query
- DataLoader per-request: create new instance per request—prevents cross-request caching
- Even with DataLoader, watch for nested N+1—posts → comments → authors chains
## Schema Design
- Fields nullable by default—make non-null explicit: `name: String!`
- Input types separate from output—`CreateUserInput` vs `User`; allows different validation
- Connections for pagination: `users(first: 10, after: "cursor")` returns `edges` + `pageInfo`
- Avoid deeply nested types—flatten where possible; 5+ levels = resolver complexity
## Pagination
- Cursor-based (Relay style): `first/after`, `last/before`—stable across insertions
- Offset-based: `limit/offset`—simpler but skips or duplicates on concurrent writes
- Return `pageInfo { hasNextPage, endCursor }`—client knows when to stop
- `totalCount` expensive on large datasets—make optional or estimate
## Security Traps
- Query depth limiting—prevent `{ user { friends { friends { friends... } } } }`
- Query complexity scoring—count fields, multiply by list sizes; reject above threshold
- Disable introspection in production—or protect with auth; schema is attack surface
- Timeout per query—malicious queries can be slow without being deep
- Rate limit by complexity, not just requests—one complex query = many simple ones
## Error Handling
- Partial success normal—query returns data AND errors; check both
- Errors array with path—shows which field failed: `"path": ["user", "posts", 0]`
- Error extensions for codes—`"extensions": {"code": "FORBIDDEN"}`; don't parse message
- Throw in resolver = null + error—parent nullable = partial data; parent non-null = error propagates up
## Resolver Patterns
- Return object with ID, let sub-resolvers fetch details—avoids over-fetching at top level
- `__resolveType` for unions/interfaces—required to determine concrete type
- Context for auth, DataLoaders, DB connection—pass through resolver chain
- Field-level auth in resolvers—check permissions per field, not just per query
## Mutations
- Return modified object—client updates cache without re-fetch
- Input validation before DB—return user-friendly error, not DB constraint violation
- Idempotency for critical mutations—accept client-generated ID or idempotency key
- One mutation per operation typically—batch mutations exist but complicate error handling
## Performance
- Persisted queries: hash → query mapping—smaller payloads, prevents arbitrary queries
- `@defer` for slow fields—returns fast fields first, streams slow ones (if supported)
- Fragment colocation: components define data needs—reduces over-fetching
- Query allowlisting: only registered queries in production—blocks exploratory attacks
## Subscriptions
- WebSocket-based—`graphql-ws` protocol; separate from HTTP
- Scaling: pub/sub needed—Redis or similar for multi-server broadcast
- Filter at subscription level—don't push everything and filter client-side
- Unsubscribe on disconnect—clean up resources; connection tracking required
## Client-Side
- Normalized cache (Apollo, Relay)—deduplicate by ID; updates propagate automatically
- Optimistic UI: predict mutation result—rollback if server differs
- Error policies: decide per-query—ignore errors, return partial, or treat as failure
- Fragment reuse—define once, use in multiple queries; keeps fields in sync
## Common Mistakes
- No DataLoader—N+1 kills performance; one query becomes hundreds
- Exposing internal errors—stack traces leak implementation details
- No query limits—attackers craft expensive queries; DoS with single request
- Over-fetching in resolvers—fetching full object when query only needs ID + name
- Treating like REST—GraphQL is a graph; design for traversal, not resources