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.