DEV Community: ImADev

Skill Forge: turn scattered notes into complete, reusable skills for AI agents

ImADev — Sat, 07 Nov 2026 10:09:37 +0000

The problem: your notes are not a skill yet

If you build with AI agents, you have probably hit this wall. You know how to do a task - the edge cases, the order of operations, the mistakes to avoid - but it lives in a pile of half-finished notes, exported PDFs and chat transcripts. An agent cannot use any of that.

A skill is different: it is an operational document. It says when to use it, what to do first, what to do next, which mistakes are common, and how to verify the result. Writing that by hand is slow and repetitive.

What Skill Forge does

Skill Forge takes whatever you have and produces that document for you.

You can start in two ways:

A. You already have material. Upload up to twenty files - transcripts, notes, exported PDFs, a rough draft of the skill. The model merges everything into one document, fills the gaps, and keeps every technical detail.

B. You start from an idea. Answer six questions about name, domain, goal, tone and constraints. The model writes the full procedure from scratch, with realistic examples and common mistakes.

Either way, the output has a fixed structure: when to use it, prerequisites, a numbered procedure, examples, common mistakes, and a verification checklist. You then download it, or publish it to the public marketplace.

The marketplace

Every published skill gets a page on the marketplace, so the good ones stop being throwaway prompts and become reusable building blocks. Skills are signed with your GitHub identity, so authorship is visible.

The tech

The front end and API run as a single Next.js app deployed to Cloudflare Workers with OpenNext. Data lives in Cloudflare D1 (SQLite at the edge) and rate limiting in KV. Sign-in is one click with GitHub - used only to read your profile and sign the skills you publish.

Privacy note

The material you upload stays only in the request. It is not archived on the server.

Try it

It is free: skill-forge.ciao22king.workers.dev

If you build agents, give it a shot and tell me what you think. What would you turn into a skill first?

A messenger with no server: how ShutChat gets a message from one phone to another

ImADev — Tue, 27 Oct 2026 19:10:07 +0000

Most messengers have a server in the middle. It is where your messages live, and it is also the single place where they can be read, subpoenaed, or quietly deleted when the company loses interest.

I wanted to see how far you can get without one. ShutChat is the result: an Android messenger where messages travel directly between devices. No server, no account, no sign-up screen.

This is a write-up of the parts that were interesting to build, and the parts that were genuinely hard.

The whole access model is one code

There is no address book, no user ID, no registration. A conversation starts with a 24-character invite code, and that code is the entire access model.

It is 15 bytes, rendered in Base32 with the Crockford alphabet, so 1/l/I and 0/O cannot be confused when you read it off someone else's screen:

Bytes	Contents
0	version and chat kind
1..2	expiry day, big endian, `0xFFFF` = never
3..4	CRC-16
5..14	80-bit rendezvous secret

Two details I would keep in any rewrite.

Expiry is stored as a day, not a timestamp. Every device in the room enforces the same UTC deadline, whatever its timezone. A timestamp would drift.

The CRC is computed with its own bytes zeroed. Obvious once it works, maddening before: a checksum cannot cover itself. This was a real bug in an early version, and it shipped.

Three transports, picked at runtime

The interesting constraint: two phones on different mobile networks have no addressable path to each other. Something has to be reachable. So there are three paths, chosen at runtime.

LAN — UDP multicast to find peers on the same network, TCP for the data.
Nearby Connections — Bluetooth and Wi-Fi Direct, for devices that are close but not on a shared network.
MQTT over TLS — for devices on different networks.

The room id is derived from the secret with HKDF and travels in the clear in every frame header. That looks wrong at first. It is deliberate: it lets a device forward a frame it cannot decrypt, which is what makes relaying possible. The message key and the file-transfer key are separate derivations, so a file chunk cannot be replayed as a message.

The relay is the only third party, and it sees neither the message nor who is talking. Frames are sealed, and the topic is derived from the invite secret, never from the room id. That last part matters: the room id travels in clear on every frame, so a topic derived from it would let a broker watcher correlate rooms.

The hard part: a message for someone who is offline

This is where a serverless design bites. With no server, a message can only arrive if something is awake to receive it.

The first version had a real bug. A message written for an offline peer went into the queue and was never retried. It sat in the chat with a clock icon, forever. Worse, "delivered" was inferred from "the bytes reached a socket", and the delivery receipt envelope was defined but never actually sent.

The fix was a retry queue with per-message backoff. It uses the message table as the queue, so a crash loses nothing the database had already saved. A message is retried until the recipient acknowledges it, and after 30 days, or when the room code expires, it is marked failed instead of pretending forever.

Two subtleties cost me real time.

The mesh deduplicates before the handler runs, so a re-sent message arrived and was silently dropped. The sender was retrying precisely because it never got the first receipt, so staying quiet kept it retrying for the whole window. A re-send now re-acknowledges.

Backoff must be per message, not a global counter: a message stays in the undelivered set after being handed to a transport, so a single counter would re-send every queued message on the same schedule.

A foreground service keeps the mesh listening when the app is closed, because with no push server, something must be awake to receive.

What it does

Direct and group chats from a single code; photos, audio and files transferred in chunks; replies, edits, deletes, reactions; read receipts and typing indicators; presence; search, pin, mute, archive, drafts; QR code sharing; automatic expiry and rotation of invite codes.

The honest limitations

The relay is on by default, because a messenger that only works on one network is not much of one. It can be switched off from settings.
Nearby Connections is Android-only. There is no iOS version, and a desktop version would be LAN plus relay, without the Bluetooth mesh.
I could not test the network paths end to end in my build environment: no KVM, so no emulator. The retry logic is covered by unit tests, but real two-phone behaviour is the thing to try first.

It is Apache-2.0, and the APK is on the releases page: https://github.com/ciao22king/ShutChat

EdgePassport

ImADev — Thu, 22 Oct 2026 17:22:51 +0000

Every time you open a website, you touch a physical city.

Not "the cloud" — a real building, somewhere on Earth.

Edge Passport shows you the one closest to you, as a passport card you can share.

Which city did you touch today
https://edge-passport.ciao22king.workers.dev

EdgePassport

ImADev — Tue, 20 Oct 2026 20:11:12 +0000

Edgepassport Remember were you were
with edgepassport you can see where you've been and where others have been, fun fuct on where you are and questions https://edge-passport.ciao22king.workers.dev I'm waiting for https://nic.eu.org as an extension (It Will be https://edgepassport.eu.org)

GoFetch

ImADev — Mon, 05 Oct 2026 20:27:50 +0000

use a simple cli for clone GitHub and gitlab repos https://github.com/ciao22king/GoFetch Built for Windows macOs and Linux in beta stage may not work the code was built by me with bug fix of the ai

OwnCode: Build Something

ImADev — Thu, 23 Jul 2026 20:17:32 +0000

Today I released my web app to the public and I'll explain what it does.

1° It is a project where privacy comes first. Your chats are sent to the Firebase Firestore server but no one will ever read them The API Keys will not be saved in the cloud but in local storage.

2° With this BYOK (Bring Your Own Key) project you will use your own gemini api but who knows maybe one day I will add more providers anyway we forced gemini to write real code🤣

3° This is an unfunded project, and I'm looking for testers, even if they don't get paid. I'd be very happy. Here is the link https://owncode.ai.studio/ and write In the comments if you want to be a tester or bug or feedback

OwnCode: Create amazing apps

ImADev — Wed, 22 Jul 2026 20:24:09 +0000

Today I finally uploaded OwnCode to the web and now I'll explain what it does.
It's a BYOK (bring your own api) project in this case by gemini. With our site you can force gemini to work 🤣!Anyway you give him a prompt and like any other AI he writes code in a built-in editor.
I need testers obviously this is an unfunded project so they won't be paid but I'd be very happy if someone would try it. Here is the link https://owncode.ai.studio/ and write in the comments if there is any bug etc.Your password will not be sent to any server.