openlark-naming

Enforce consistent public API naming across the OpenLark Rust SDK.

103|27|Updated Apr 9, 2024
One-click install
npx skills add https://github.com/foxzool/open-lark --skill openlark-naming
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: openlark-naming
Source: https://github.com/foxzool/open-lark/tree/main/.agents/skills/openlark-naming
Command: npx skills add https://github.com/foxzool/open-lark --skill openlark-naming

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

OpenLark naming conventions provide a standardized approach for public API types (Client/Service/Resource/Request/Builder) to improve readability, maintainability, and onboarding when designing or refactoring APIs. It helps manage meta call chains and module exports/preludes to avoid semantic clashes like DocsService in related crates.

Core Features & Use Cases

  • Establishes explicit naming rules for Client, Service, Resource, Request, and Builder types to improve readability and maintainability.
  • Guides versioned naming to avoid collisions and clarifies meta call chains (e.g., client.xxx.v1.yyy) to maintain a clean API surface.
  • Helps detect and resolve naming conflicts across modules and prelude exports, improving API discoverability and consistency across the SDK.

Quick Start

Review a target module and propose naming changes that align with the OpenLark naming conventions.

Frequently Asked Questions about openlark-naming

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

FAQPage Schema
How do I enforce consistent API naming across an OpenLark Rust SDK?

To enforce consistent API naming across an OpenLark Rust SDK, apply standardized conventions to Client, Service, Resource, Request, and Builder types, ensuring clear export paths and prelude organization.

Why do naming collisions happen in versioned Rust modules and how do I prevent them?

Naming collisions in versioned Rust modules happen when semantic clashes occur across related crates, such as overlapping DocsService types. You prevent them by guiding versioned naming and clarifying meta call chains.

What is the best way to organize a Rust SDK prelude to avoid API name collisions?

The best way to organize a Rust SDK prelude to avoid API name collisions is to establish explicit naming rules for Service and Resource types, detecting and resolving conflicts across module exports.

Can I use naming conventions to clarify meta call chains like client.xxx.v1.yyy in Rust?

Yes, you can use naming conventions to clarify meta call chains like client.xxx.v1.yyy in Rust by applying versioned naming rules that prevent collisions and maintain a clean API surface.

How do I review a Rust module and propose API naming changes for better readability?

To review a Rust module and propose API naming changes for better readability, identify target types and align their Client, Service, Resource, Request, and Builder names with OpenLark conventions.

Does standardizing public API types improve onboarding when refactoring a Rust SDK?

Standardizing public API types does improve onboarding when refactoring a Rust SDK by providing a standardized approach for Client, Service, and Builder types, which enhances overall maintainability and readability.