x-tdlib

Align TDLib adapter boundaries and test/authorization contracts for Telegram repos.

2|Updated Apr 12, 2026
One-click install
npx skills add https://github.com/pure-golang/level85 --skill x-tdlib
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: x-tdlib
Source: https://github.com/pure-golang/level85/tree/main/.agents/skills/x-tdlib
Command: npx skills add https://github.com/pure-golang/level85 --skill x-tdlib

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill removes ambiguity and implementation drift when building or modifying the TDLib adapter layer and its interaction/test strategy, ensuring a consistent contract between raw TDLib surfaces and the project’s consumer-side interfaces.

Core Features & Use Cases

  • TDLib adapter ownership: defines the canonical place for TDLib-facing wrapping (clientAdapter) and what must stay in repo/telegram package internals.
  • Consumer-side telegramRepo contract: specifies how handlers and other consumers should depend on a partially-applied telegramRepo interface using raw TDLib types plus repo-provided composites.
  • Test strategy for reliability: distinguishes TDLib-independent unit tests (mocking telegramRepo), from BDD tests running against a real TDLib with test data center, and explicitly discourages long-term fake TDLib implementations.
  • Authorization lifecycle control: clarifies that the auth flow (WaitPhone → WaitCode → WaitPassword → Ready) belongs to repo.go and is expressed via domain AuthState* events.

Quick Start

Use the x-tdlib skill when you change a method in internal/repo/telegram/ and need to update the adapter boundary, consumer-side telegramRepo interface, and the corresponding unit/BDD test expectations accordingly.

Frequently Asked Questions about x-tdlib

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

FAQPage Schema
How do I structure a TDLib adapter boundary in a Telegram repository?▼

To structure a TDLib adapter boundary, wrap TDLib-facing calls in a clientAdapter and keep composite, lifecycle, and authorization logic in repo.go. Consumers should depend on a telegramRepo interface using raw *client.* TDLib types.

Where should the Telegram authorization flow logic reside when using TDLib?▼

The Telegram authorization flow logic (WaitPhone, WaitCode, WaitPassword, Ready) belongs in repo.go, where it is managed internally and expressed externally via domain AuthState* events.

What is the best way to test TDLib adapter methods without a real Telegram connection?▼

The best way to test TDLib adapter methods without a real connection is mocking the consumer-side telegramRepo interface for unit tests. Long-term fake TDLib implementations are explicitly discouraged.

Can I use abstracted types instead of raw TDLib types in my telegramRepo consumer contract?▼

No, you must use raw *client.* TDLib types in the consumer contract. The telegramRepo interface depends on these raw types alongside repo-provided composites to prevent implementation drift.

Why does my TDLib adapter implementation drift when updating telegramRepo methods?▼

TDLib adapter implementation drifts when adapter boundaries and test contracts are misaligned. You must update the clientAdapter wrapper, the telegramRepo interface, and test expectations simultaneously to maintain a consistent contract.