Share your best AI workflow. We could show it to 2M+ people.

I built a reusable AI skill that turns any topic and source material into a self-paced course. It follows the same assembly line every time: modules with learning goals, real lesson text, working YouTube videos, quizzes with explanations for wrong answers, and a simple local web course packaged in a folder-based library. Each new course gets its own folder. It works across subjects, but I still review high-stakes content myself. I also treat video quality as more than whether a link works. Step-by-step: 1. I provide a topic and source material. 2. The skill splits the topic into modules and defines learning goals for each one. 3. It writes the lesson text. 4. It finds real YouTube videos and verifies that they work. 5. It builds quizzes that explain incorrect answers. 6. It packages everything as a simple local web course. 7. It adds the new course to the folder-based library in its own folder. 8. I review high-stakes content and assess video quality beyond whether the links work.

I come across a public social video—a Reel, TikTok, or short clip—with an idea, process, or tool worth keeping. Rather than saving it and forgetting it, I drop the link into my capture workflow. I also use the workflow for clips I have permission to upload or process. The workflow extracts useful information from the video. It creates a transcript of the spoken content and captures key frames when useful information appears on screen. AI then turns that raw material into a structured research note covering the main idea, any reusable framework or step-by-step process, tools or prompts mentioned, constraints, and whether the item should become a project, opportunity, reference, watchlist item, or be ignored. I save the finished note in Obsidian with the original source link so I can search for it later and trace where the idea came from. Each note ends with one recommended next action, turning the video into something I can act on rather than another forgotten save. I only process public content or content I have permission to use, and I label rough transcripts as rough rather than treating them as perfect. Step-by-step: 1. I find a public Reel, TikTok, or short video containing an idea, process, or tool worth keeping. 2. I add the video link to my capture workflow, or upload a clip I have permission to process. 3. I create a transcript of the spoken content and capture key frames that contain useful information. 4. I use AI to turn the transcript and frames into a structured research note covering the main idea, reusable frameworks or processes, tools or prompts, constraints, and the appropriate category. 5. I save the note in Obsidian with the original source link and label any rough transcript accordingly. 6. I end the note with one recommended next action so I can act on the idea.

Everyone I know who runs a second brain uses Obsidian. The app is free, but sync is a subscription, and most AI integrations quietly assume you have it. I went another way: Joplin, which is free and open source, with an agent that reads my notebook through Joplin’s REST API, files my INBOX every morning while I sleep, and answers questions strictly from notes I actually wrote. It costs nothing beyond a VPS I already run, and the notebook still opens like a notebook. I use Hermes Agent on the VPS, Dropbox to sync notes between my devices, and Python scripts to connect the notebook and the agent. Every capture goes through `joplin_capture.py` and lands in a single INBOX folder with a source and timestamp attached. Captures can come from a Discord link, a thought from my phone, or a page from the web clipper. The process takes under ten seconds and requires no filing decisions at capture time, because filing at capture time is where second brains die. Joplin already ships with a REST API. I enable it with one setting and one token; the notebook then exposes HTTP on localhost:41184 with token authentication on every call. The same server powers the official web clipper, so this enables infrastructure I use anyway. There is no plugin, cloud service, or subscription. `joplin_filer.py` runs daily at 07:00 and uses a deterministic classifier to score each INBOX note against my existing folders. It uses token coverage rather than Jaccard, which dilutes single-token folders. Confident matches above 0.5 are moved into place: a hosting page goes to the hosting folder, while a security note goes to the security folder. Low-confidence notes stay in INBOX with the `needs-review` tag. Every move is logged to a FILER LOG note in the `__SYSTEM` folder, making the process auditable. The filer never deletes anything. I ran it in dry-run mode for a week before letting it touch a single note, and I recommend doing the same. When I want to know what I have learned, `joplin_ask.py` searches the corpus, reads the top notes in full, and answers with the note titles attached. It answers strictly from retrieved content. If the top hits are irrelevant, I refine the query before concluding there is nothing. It never invents a source, which matters when you write about security for a living. After each working session, `joplin_agent_log.py` prepends a digest to an AGENT LOG note in `__SYSTEM`. The log is newest first, append only, and syncs to my devices like everything else. The agent’s memory records what we did, decided, and deferred in the same place as the notes. The whole build is on GitHub: github.com/ciberjohn/mysecondBrain. It includes five Python scripts and the `joplin-brain` skill, which is the operating manual in a format another agent can load and follow. Step-by-step: 1. I enabled Joplin’s built-in REST API with one setting and one token. It serves HTTP on localhost:41184 with token authentication on every call and also supports the official web clipper. 2. I pointed Hermes Agent on my existing VPS at the Joplin REST API. 3. I routed every capture through `joplin_capture.py` into a single INBOX folder, attaching the source and a timestamp. Captures can come from Discord, my phone, or the web clipper. 4. I configured `joplin_filer.py` to run daily at 07:00 and score INBOX notes against my existing folders using token coverage rather than Jaccard. 5. I moved matches with scores above 0.5 into their folders, while leaving low-confidence notes in INBOX with the `needs-review` tag. 6. I logged every move in a FILER LOG note in the `__SYSTEM` folder and ensured that the filer never deletes anything. 7. I ran the filer in dry-run mode for a week before allowing it to move a note. 8. I used `joplin_ask.py` to search the corpus, read the top notes in full, and answer questions with the source note titles attached. When results were irrelevant, I refined the query. 9. After each working session, I used `joplin_agent_log.py` to prepend a digest to the newest-first, append-only AGENT LOG note in `__SYSTEM`. 10. I used Dropbox to sync notes between my devices and the REST API to move notes between Joplin and the agent—two separate pipes carrying the same notes in different directions.

I built a digital Second Brain after trying several approaches, including OpenBrain and LLM Wiki. OpenBrain and LLM Wiki are useful frameworks for building a digital brain. The theory is solid: flat Markdown files, AI-first conventions, and an ingestion pipeline that turns raw inputs into searchable knowledge. But when applied in practice, the process can be bumpy and may require adjustments—or an entirely different approach. I adapted the ideas to fit how I actually think and work. I kept what worked, discarded what didn’t, and built my own digital brain. The result is documented in a single file containing everything an AI needs to understand, maintain, or rebuild the system from scratch. Step-by-step: 1. I tried several digital-brain frameworks, including OpenBrain and LLM Wiki. 2. I evaluated their approaches, including flat Markdown files, AI-first conventions, and an ingestion pipeline for turning raw inputs into searchable knowledge. 3. I identified where the frameworks were difficult to apply in practice and adjusted my approach. 4. I kept the ideas that worked for me, discarded what didn’t, and built a digital brain suited to how I think and work. 5. I documented the system in a single file so an AI can understand, maintain, or rebuild it from scratch.

I record a meeting on my phone and send the audio file to my Telegram chat with Hermes, my local AI agent. That is the only trigger—there is no app, upload page, or extra step. Hermes runs on my PC through WSL and handles the rest locally, except for the LLM analysis. Step-by-step: 1. Send the audio via Telegram. I drop the meeting recording into my Telegram chat with Hermes. 2. Create the meeting record. When Hermes receives the audio message, it calls a FastAPI endpoint at `localhost:8200`. The endpoint creates a meeting record and uploads the file. It is a thin Python server backed by SQLite, using async SQLAlchemy. 3. Transcribe the meeting locally. The backend runs faster-whisper on my PC, so there is no cloud transcription API or transcription cost. It handles large files and produces the full text with timestamped segments. 4. Identify the speakers. A diarization pass determines who spoke when. I can optionally upload a 10-second voice sample for each person; the system stores MFCC features and can automatically label speakers such as “Steve” and “Andrew” in future meetings. Diarization is best-effort, so transcription still works if it fails. 5. Analyze the transcript with an LLM. The transcript and timestamped segments are sent to DeepSeek through the OpenRouter API. A single structured prompt extracts: - A TL;DR - Thematic topic groups - Decisions made - Open questions - Risks flagged - A participant list - Tags - Proposed action items, each with an owner, priority, due date, confidence score, source timestamp, and the exact transcript quote it came from 6. Send action items to the todo app. Each proposed task has a Create in Todo button. With one click, I send it to my separate local `agent-native-todo` service on port `8100`, along with the meeting title, evidence quote, and timestamp as context. The todo app runs independently; the meeting app only calls its REST API. 7. Review everything in the web miniapp. The results appear in a React SPA at `/miniapp/`, which includes a meeting list, FTS5 full-text search, transcripts with clickable timestamps that jump to the corresponding point in the audio, color-coded tasks, speaker name editing, and audio playback with seek. The stack is: - Backend: Python FastAPI, async SQLAlchemy, and SQLite - Transcription: faster-whisper, installed with `pip install faster-whisper` - Diarization: pyannote.audio or a similar tool; optional because transcription works without it - LLM: OpenRouter API with DeepSeek, using one structured prompt and JSON mode - Frontend: React, Vite, and plain CSS without a framework - Agent glue: Hermes Agent receives Telegram messages and orchestrates the API calls - Todo integration: Any task app with a REST API; the meeting app only needs to POST to it The only part that costs money is the LLM analysis step, which costs about $0.01 per meeting through DeepSeek. Everything else runs on my PC.

I enjoy researching football accumulators, but I did not want a workflow that simply asks AI for “the best bets.” I wanted a repeatable process that starts with evidence, makes uncertainty visible, and is allowed to say “pass.” I started building it on 4 August 2026. The result is a private Football Lab covering the Premier League, Championship, and League One. It is for personal research and entertainment only—not a public tips service, income claim, or automated betting system. The workflow pulls public football data into a private, traceable store, then cleans, reconciles, and blends it before analysis: - football-data.co.uk: 7,420 normal-context matches from 2021–22 to 2025–26, including results, basic statistics, referees, and historical odds. I excluded COVID-affected 2020–21. - Fixture Download: An initial 2026–27 schedule snapshot containing 1,484 fixtures across the three divisions. - Premier League public match feed: A five-season layer covering referees, cards, event timing, added time, and 469 penalty kicks split into scored, saved, and missed. - Official Premier League Transfer Watch and BBC Sport: A source ledger for squad movement. - Official EFL appointment pages: Timestamped Championship and League One weekend checks. Schedules, appointments, and transfers retain their source and capture time instead of becoming untraceable web snippets. Step-by-step: 1. I validate fixture identity, duplicates, dates, missing fields, and team-name mismatches before modelling. I then reconcile the sources into a common club and fixture record. A tidy report built on a broken fixture list is still wrong. 2. I build separate Elo and Poisson baselines that turn historical team performance and home advantage into expected goals and home/draw/away probabilities. The divisions remain separate, so Championship form is not quietly treated as Premier League form. Each fixture is predicted before its result updates the model, preventing hindsight from creeping in. I backtested the baseline against 1,484 completed 2025–26 fixtures to establish an honest benchmark rather than claim a magic model. 3. I add context that the baseline cannot see alone. When an official referee appointment is confirmed, I timestamp it and match it to the fixture. The Lab can then show competition-specific cards, dismissals, and—where Premier League evidence exists—penalty-kick and added-time patterns. The question is not whether a referee picks a winner, but whether the match environment looks more volatile or the sample is too thin to support a useful conclusion. Unknown or changed appointments remain neutral. 4. I maintain a private append-only ledger of source-backed squad movement and label every club as established, promoted, relegated, or limited history. A signing does not automatically improve a probability, and an old-division record is not treated as identical new-division form. Until those effects earn a tested role in the model, they widen uncertainty or rule out a fragile fixture. 5. I begin with the complete fixture board rather than a short list of favourites. For every game, I combine baseline probabilities, expected goals, team context, confirmed squad changes, referee environment where evidence exists, and unresolved live checks. I write a plain-English match story explaining what the baseline sees, what could make the fixture fragile, and whether the sensible outcome is candidate, watch, or pass. 6. I preserve the full board in a private Weekend Sheet, along with the model read and reason, uncertainty flags, and the small number of research candidates that survive the checks. There can be up to seven candidates, but seven is never a quota: three strong games means three, and none means pass. 7. Before results, I record each run’s data cutoff, model version, and referee-status snapshot. After the round, a separate debrief compares the original probabilities and swerves with what happened, checks whether the flags caught fragile fixtures, and identifies one bounded improvement. The Lab remains in private paper-run mode while a recurring live results source, appointment capture, and market checks earn their own evidence gates. AI helps turn public-source data into an inspectable research workflow. It makes uncertainty visible and treats “pass” as just as valid as a confident call.

I often lose track of movies and TV shows I want to watch, especially when they are announced months before release. To solve this, I use a free API from watchmode.com. I asked Hermes Agent—although ChatGPT Work could probably do the same—to create a scheduled task that checks the API once a week and notifies me when a title becomes available to stream. I also gave it a simple instruction: whenever I send an IMDb link for a movie, TV show, or specific season, it should automatically add it to my watchlist. Since I prefer to binge-watch, it only notifies me when an entire season is available. The next step is to make it automatically start tracking the following season once the current one has been fully released. Step-by-step: 1. I use the free API from watchmode.com to check streaming availability. 2. I asked Hermes Agent to create a scheduled task that checks the API once a week. 3. I configured the task to notify me when a movie or TV show becomes available to stream. 4. I instructed it to add a movie, TV show, or specific season to my watchlist whenever I send an IMDb link. 5. I configured notifications for TV shows to wait until the entire season is available. 6. My next step is to have it automatically start tracking the following season after the current one has been fully released.

The Rundown Workflow Hub asks members to “share your best AI workflow” and features the community’s top-voted workflows in its daily newsletter. Most posts rightly celebrate workflows that work and produce something useful. This one is about why “no” can also be a successful workflow outcome. A good AI workflow does not turn every idea into a project. It gives an idea the right amount of effort, then produces a clear answer—including a fast, well-documented no. In my first Workflow Hub post, I showed the capture workflow I call ReelForge: turning a useful public Reel, TikTok, or short video into a source-linked research note rather than another forgotten save. This is what happened to one of those notes. A Reel pitched an “AI operating system” for solo consultants: pull together client context, prepare the human before a call, then turn the transcript into follow-up drafts. At first glance, it sounded promising. The mechanism was clear, the problem was real, and the demo had exactly the kind of glossy “one person runs everything” energy that makes it tempting to jump straight to a build. We did not. ReelForge captured the source and separated the useful mechanism from the creator’s bigger claims. From there, a primary routing workflow ran a defined first pass: did the signal merit direct resolution, deeper specialist work, human review, or a reasoned stop? It earned deeper work. Hermes sent the pack into a specialist workflow, where assigned agents collaborated to enrich the evidence, check the market claims, and produce something concrete: a pre-call brief and a post-call follow-up pack. That made the opportunity inspectable rather than another confident paragraph about what an agent *could* do. The enriched pack then went to Jon T for formal review. The review surfaced the problem: Teams and Granola already cover a large part of the obvious transcript, summary, and meeting-preparation wedge. The idea had a workable mechanism, but not a sharp enough reason to become a new product. So the final route was a deliberate no. No unnecessary build. No “let’s just test it” theatre. No orphaned Notion page waiting to become somebody’s future problem. The first visual shows that five-step pass: Step-by-step: 1. Capture the signal. 2. Add evidence and context. 3. Choose the effort. 4. Hand off to human authority when needed. 5. Record the finish. The second visual shows the decision underneath it. A signal can earn direct resolution, a specialist pipeline, or a reasoned stop. Human review is a conditional handoff, not a fourth outcome. That is the rule I care about: the output is not agent text. It is the right next end state. ReelForge was the capture layer in the first post. This is the routing layer that stops captured signals from becoming a very organised pile of work nobody should do. Read my first Workflow Hub post here: https://app.therundown.ai/community/posts/eb787b9d-f7a0-4fe4-8e1d-166bb5c29cb7?ref=db29b880a9904700 Future posts can show the builds that survived this test. This one shows why the test matters first.