Inspiration
I save useful links every day, but they often disappear across Telegram chats, browser tabs, and scattered notes. I wanted a small personal tool that would make saving a link as easy as sending a message, while keeping the archive readable and under my control.
That became AI Link Radar Bot: a Telegram bot backed by a local Markdown file.
What it does
When I send the bot a URL, it detects the source platform, checks whether the URL has already been saved, creates a structured Markdown card, and tries to fetch the page title. If normal title fetching fails, it has an optional Jina Reader fallback.
From Telegram, I can browse recent cards, search across the archive, filter by platform, add tags and notes, and mark items as processed or pending.
During OpenAI Build Week, I also added an optional /triage <id> workflow. It uses GPT-5.6 to turn saved card metadata into three structured fields:
- an assessment
- why the item matters
- one suggested next action
The triage feature uses only the selected card's saved metadata. It does not claim that GPT-5.6 has read the full webpage.
How I built it
The bot is written in Python with pyTelegramBotAPI. Saved items remain in a plain Markdown file, so the archive stays easy to inspect, edit, move, and reuse outside the bot.
The GPT-5.6 workflow uses the OpenAI Responses API with strict JSON Schema Structured Outputs. Card metadata is treated as untrusted data, model output is normalized and validated, and successful updates use a same-directory temporary file with atomic replacement.
The OpenAI API is mocked throughout the test suite, so tests do not spend API credits or alter a real personal archive.
How I used Codex and GPT-5.6
Codex supported repository inspection, focused implementation, test creation, documentation, and repeated review. I used it to work through small, auditable tasks rather than making one large uncontrolled change.
GPT-5.6 helped me design and review the metadata triage workflow. It helped identify edge cases involving structured output, prompt injection inside saved metadata, Markdown separator safety, handler ordering, refusal handling, and atomic file updates.
The final suite has 93 passing tests, two strict expected failures documenting known URL limitations, and zero failing tests.
Challenges
The biggest challenge was adding an AI feature without pretending the model knew more than it actually did. Because the first version does not fetch the full article body, I changed the feature from an article summary into an honest metadata triage workflow.
I also had to protect a simple Markdown archive from partial writes, duplicated fields, model-generated separators, and untrusted instructions embedded inside titles or notes.
Another challenge was preparing a public repository from a tool originally built for personal use. I removed private data, added safe sample files, documented external network behavior, and created privacy-aware issue templates.
What I learned
Small local tools still need clear trust boundaries once an AI model is added. Structured output controls the shape of a response, but local validation, untrusted-data instructions, safe file operations, and honest product language remain essential.
I also learned how useful Codex can be as an implementation and review partner when work is divided into narrow tasks with explicit constraints and verification steps.
What's next
Future work includes exact URL normalization, safer shared handling for all Markdown fields, full-page extraction followed by a separate /summarize command, Obsidian-oriented export, and an optional scheduled review digest.
Log in or sign up for Devpost to join the conversation.