graphql
>
Works with
---
name: graphql
description: >
license: MIT
---
# GraphQL Persona
## Agent Phases
### Phase 1: Domain Modeling
**Steps:**
1. Map each domain entity and action to a GraphQL type or mutation, assigning it to a single owning bounded context
2. Document entity relationships as GraphQL connections or nested types with explicit ownership
**Example Domain → Schema Mapping:**
| Domain Concept | GraphQL Construct | Owning Context |
|---|---|---|
| Order (entity) | `Types::OrderType` | Orders |
| Customer (entity) | `Types::CustomerType` | Accounts |
| PlaceOrder (command) | `Mutations::PlaceOrder` | Orders |
| Order.lineItems | `Types::LineItemType` (connection) | Orders |
**HARD GATE — Domain Language:**
- Core GraphQL types and their owning bounded contexts identified
- Entity relationships mapped to GraphQL connections or nested types
**If gate fails:** Return to domain discovery.
---
### Phase 2: Schema Design
**Steps:**
1. Use cursor-based or offset pagination for all list fields — never return unbounded arrays
2. Enforce field-level authorization via `authorized?` on sensitive types and fields (see Phase 4 for the full security checklist)
3. Wrap mutation responses in a result object with a structured `errors` field
4. Validate schema correctness before proceeding
**HARD GATE — Schema Validation:**
Verify schema validity using graphql-ruby's built-in tools:
```ruby
namespace :graphql do
task validate: :environment do
puts MySchema.to_definition
puts "Schema valid."
end
end
```
```bash
bundle exec rake graphql:validate
```
- No circular type references
- All types have proper fields and arguments
- Authorization rules defined for sensitive fields
**Example Type:**
```ruby
module Types
class OrderType < Types::BaseObject
field :id, ID, null: false
field :customer, Types::CustomerType, null: false
field :total, Float, null: false
field :status, String, null: false
def self.authorized?(object, context)
context[:current_user].can_read?(object)
end
end
end
```
---
### Phase 3: TDD Implementation
**For every resolver or mutation:**
1. Write a failing resolver spec, mutation spec, or integration spec targeting the specific graphql-ruby class under test
2. Propose implementation, wait for explicit user approval, then implement the resolver/mutation code
3. Run the full suite to confirm no regressions
**HARD GATE — Test Verification:**
- Test EXISTS and RUNS
- Test FAILS before implementation (correct reason)
- Test PASSES after implementation
- Full test suite PASSES (no regressions)
**Example Resolver Test:**
```ruby
RSpec.describe Resolvers::OrderResolver do
let(:user) { create(:user) }
let(:order) { create(:order, customer: user) }
it 'returns order for authorized user' do
result = described_class.new(object: nil, context: { current_user: user }).resolve(id: order.id)
expect(result).to eq(order)
end
it 'returns nil for unauthorized user' do
result = described_class.new(object: nil, context: { current_user: create(:user) }).resolve(id: order.id)
expect(result).to be_nil
end
end
```
---
### Phase 4: Security Review
This is the authoritative phase for all authorization and security requirements.
**Steps:**
1. Audit authorization at field level — every sensitive field must have an `authorized?` guard
2. Configure query depth and complexity limits on the schema class
3. Implement rate limiting at the application layer
4. Eliminate N+1 queries using `GraphQL::Batch` or `dataloader`
5. Ensure `rescue_from` on the schema class catches `StandardError` and returns a generic message
**HARD GATE — Security Check:**
- Authorization on all sensitive fields
- Query depth limit configured (recommended: ≤ 10)
- Query complexity limit configured
- Rate limiting implemented
- No N+1 queries in resolvers
- Error messages sanitized
**Example Security Configuration:**
```ruby
class MySchema < GraphQL::Schema
use GraphQL::Batch
query Types::QueryType
mutation Types::MutationType
max_depth 10
max_complexity 100
rescue_from(StandardError) do |err|
raise GraphQL::ExecutionError, "An error occurred"
end
end
```
---
## Error Recovery
| Problem | Remediation |
|---|---|
| Schema validation fails | Check circular references with `MySchema.to_definition`; verify all referenced types are defined |
| Authorization bypass detected | Add `authorized?` to the affected type, write a failing spec, re-run Phase 4 |
| N+1 queries | Identify with `bullet` gem; add `GraphQL::Batch` loader or `dataloader` for the association |
---
## Anti-Patterns
- **God schema:** Use `app/graphql/types/`, `app/graphql/mutations/`, `app/graphql/resolvers/` — not one file
- **Leaking internals:** Never expose ActiveRecord column names directly — map to domain-appropriate field names
- **Fat resolvers:** Extract business logic to service objects; resolvers should only coordinateMore API Design skills
lark-event
larksuite/cli
Lark/Feishu real-time event listening / subscribing / consuming: stream events as NDJSON via `lark-cli event consume <EventKey>` (covers IM messages/reactions/chat changes, Approval status changes, Task updates, VC meeting started/joined/ended, Minutes generated, Whiteboard updated, etc.). Use for Lark bots, real-time message processing, long-running subscribers, streaming webhook/push handlers. Supports `--max-events` / `--timeout` bounded runs and a stderr ready-marker contract — designed for AI agents running as subprocesses.
lark-contact
larksuite/cli
飞书 / Lark 通讯录:按姓名 / 邮箱解析成 open_id,或按 open_id 反查姓名 / 部门 / 邮箱 / 联系方式 / 个人状态 / 签名,以及按关键词搜索当前用户可见的机器人 / 智能体(agent)。当用户提到一个名字要下一步发消息 / 排日程,或拿到 open_id 想查具体信息时使用。不负责部门树遍历、按部门列员工、组织架构图,这类需求走原生 OpenAPI。
lark-openapi-explorer
larksuite/cli
飞书/Lark 原生 OpenAPI 探索:从官方文档库中挖掘未经 CLI 封装的原生 OpenAPI 接口。当用户的需求无法被现有 lark-* skill 或 lark-cli 已注册命令满足,需要查找并调用原生飞书 OpenAPI 时使用。

