Telegram docs check
Skill ballisarium/aiogram-bot-skills/skills/telegram-docs-check
focused workflows for building and maintaining aiogram bots
npx -y skills add ballisarium/aiogram-bot-skills --skill telegram-docs-checkAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 25 days oldThe repository was created 25 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
use when current or version-specific telegram, aiogram, or related library documentation materially affects a change; документация, limits, signatures, webhooks, payments, Mini Apps, versions.
SKILL.md
1.9 KB, as published. Nobody here has run it
telegram docs check
verify only the external fact that affects implementation. skip this skill for behavior-preserving local refactors or tests of established local logic.
source order
- project dependency files, lockfiles, imports, code patterns, and tests
- official documentation for the installed version
- official changelogs, release notes, repositories, and tagged source
- Context7 when available for library signatures
- primary-source web search when the earlier sources are incomplete
workflow
- state the exact load-bearing fact, such as a method signature, filter form, payload limit, webhook field, payment requirement, exception class, or migration note.
- prove the installed or pinned version before consulting current docs. prefer documentation for that version.
- verify only the fact needed for the change. do not turn a narrow implementation question into broad research.
- apply the finding while preserving the project's pinned version and conventions. never rewrite older code merely to match the latest documentation.
- mention the check in the final response only when it changed or confirmed a material implementation decision, using one short line:
docs checked: <fact> — <source and result>.
completion requires an authoritative source matched to the relevant version when versioning exists, a finding applied to the implementation or reported as the requested answer, and no unsupported current-behavior claim.
guardrails
do not rely on random tutorials, cite documentation without applying it, force a Context7 section when it added nothing, or claim certainty when official sources do not establish the fact.