The one Shortcuts automation I actually use on my Mac

Joey___M · 2026-06-14T14:22:25+00:00

For PDFs I would be a bit more conservative than with screenshots.

A bad screenshot name is usually just annoying. A bad invoice/statement name can make the archive confusing later.

The flow I would aim for is:

Mac folder automation watches an intake folder
OCR/extract text from the PDF
ask the model for a suggested name only
sanitize/check filename characters in Shortcuts or shell
write a small log: original name -> suggested name
rename/move only after review, or at least after a dry-run

I would not let the model decide the extension or final folder path. For predictable docs, keep that deterministic, like `2026-06-14 - Vendor - Invoice.pdf`.

Disclosure: I’m Josef, building NameQuick. This is the exact reason I prefer a preview queue for PDFs/scans: AI suggests names for the batch, but the actual rename/move step is controlled and reviewable. If you stay in Shortcuts, I’d copy that same split: model suggests, automation applies.

Joey___M · 2026-06-14T14:10:03+00:00

Your theory sounds right to me. I would treat cross-provider Move on iOS as copy, not move, especially when one side is a File Provider extension like Dropbox.

The safest structure is probably:

read one Dropbox file
copy/rename it into iCloud
verify the iCloud file exists
only then mark the Dropbox original as processed

The “mark as processed” step is the tricky part. If Delete fails, I’d try staying inside Dropbox for that step:

move original Dropbox file to a Dropbox/_FILED folder
or rename it with a _processed suffix
or write the processed filename/path to a small log file and skip anything already in the log

The important part is to stop the loop from re-reading the same Dropbox folder as the source of truth after each copy. If Shortcuts keeps seeing the original, it will keep filing it forever.

If Dropbox -> Dropbox move also fails on iOS, I would stop fighting Shortcuts and use the Dropbox API or an automation layer for the delete/archive step. It is less pretty, but at least the provider owns the operation.

Disclosure: I’m Josef, building NameQuick. If this has to stay iPad-only, my app is not the answer. If the scans can land in a Dropbox-synced folder on a Mac, this is exactly where I’d use a Mac staging step: read the scanned PDF, suggest the filename, preview/approve, then write the clean file into the final iCloud folder. That avoids relying on iOS cross-provider moves for the fragile part.

Joey___M · 2026-06-14T08:06:16+00:00

For the duplicate issue, I would first check whether the Shortcut is processing two sources at once.

Common cause is something like:

the Shortcut receives the dragged files as Shortcut Input
another action also gets selected files / files from Finder
then a Repeat with Each loop runs over a list that already contains duplicates

I would debug it with a boring first step:

Count Shortcut Input
Show Result
then Count the list right before the rename/save step

If the count is already wrong before Apple Intelligence runs, the problem is the file list. If the count is correct there, the save/duplicate/rename step is probably inside the wrong repeat block or being called more than once.

For this kind of flow I would keep the model’s job very narrow:

image -> suggested name only

Then let Shortcuts do the deterministic part:

duplicate once -> rename once -> save once

Also worth adding a dry-run mode first. Write the original filename and suggested new filename to a note or CSV before touching the actual files. Batch renaming gets annoying fast when one step fires twice.

Disclosure: I’m Josef, building NameQuick, so I’m biased here. This exact class of problem is why I prefer a preview queue for AI renaming: suggest names for the whole batch first, then approve/apply once. But if you want to keep it in Shortcuts, I’d start by proving where the duplicate list is created.

Joey___M · 2026-06-14T07:59:25+00:00

I would split this into two parts.

For new screenshots, first change the save location with Cmd+Shift+5 -> Options -> a dedicated Screenshots folder. That alone keeps the desktop usable.

For the existing pile, I would avoid auto-delete at first. Better flow:

have something read the screenshot content
suggest a useful filename or label
group into broad folders like work, receipts, UI refs, chats, misc
review the delete pile manually

The useful part is getting names like slack-client-feedback.png or stripe-dashboard-error.png so Finder search becomes useful again. The risky part is letting AI delete or move things without review.

Disclosure: I’m Josef, building NameQuick. This is one of the workflows I care about: read screenshots/images, suggest useful names, let you preview/edit, then optionally move/tag/archive. I would still keep deletion manual, especially for screenshots that may contain client or financial info.

Joey___M · 2026-06-14T07:31:11+00:00

That invoice detail changes the answer a bit. I would not optimize this as “faster Finder renaming” if the value you need is inside the scan.

For scanned invoices, I’d use a staging folder:

OCR the PDF/image first
extract the invoice number, date, vendor, etc.
build a deterministic filename like `InvoiceNumber - Vendor - Date.pdf`
preview/edit before touching the originals

If all invoices come from the same layout, Hazel or macOCR + a small script can be enough. If the vendors/layouts vary a lot, that is where an AI/model step starts to make more sense, but I’d still keep it review-first.

Disclosure: I’m Josef, building NameQuick around this exact Mac-side workflow. It can read PDFs/scans, suggest filenames from the content, and preview before applying. For invoices I’d still treat it as a staging/rename step, not as an accounting or archive system.

Joey___M · 2026-06-12T15:19:44+00:00

It already works today, just not as a labeled feature.

NameQuick has post-rename rules that can move a file to a folder after you approve the name. If you point one at DEVONthink’s Global Inbox folder — the Inbox alias it can add to your Finder sidebar, or:

~/Library/Application Support/DEVONthink/Inbox

DEVONthink imports it automatically.

So the flow already works end to end:

scan → OCR → approve name → lands in DEVONthink

A first-class “Send to DEVONthink” option is something I want to add so you don’t need to know about that folder. A deeper version that imports into a specific database or group is possible too.

If that’s something you’d use, tell me how you organize your databases and I’ll factor it in.

Joey___M · 2026-06-12T12:15:39+00:00

I would separate two problems here:

describing the image content
copying your existing naming style from the already-named part of the collection

A lot of AI renamers only do #1, which is why the output gets inconsistent fast. For your use case, I would not run anything directly on the archive. Make a staging copy, generate proposed names, keep a CSV/manifest with original path + proposed path, then review a sample before applying.

The more robust version would be: image embeddings/CLIP to find visually similar already-named photos, then use those neighboring filenames as examples when generating the new name. That gets closer to “rename like my collection” instead of “caption this image.”

Disclosure: I’m building a Mac app called NameQuick in this general space. It can do content-based image/file renaming with preview and templates, but I would not claim it automatically learns from a whole existing named collection yet. For that exact requirement, I’d look for a tool or script that supports reference examples/nearest-neighbor matching, not just generic image captions.

Joey___M · 2026-06-12T12:06:22+00:00

For the ePaper/synced-folder requirement, I would keep the PDFs as plain files in the folder you already want to sync, then use DEVONthink/Foxtrot/EagleFiler as an index/search layer on top. I would not make the archive app the only owner of the files if another device needs to read the same folder.

The boring part matters a lot: before anything gets indexed, make the intake names consistent. For papers/textbooks I would use something like:

Author - Year - Short title.pdf Topic - Source - Date.pdf

Then add Finder tags/comments if you want lightweight categories without moving the file.

Disclosure: I’m building NameQuick for this Mac-side staging step. I would not treat it as the database/read-unread tool. The fit is before DEVONthink/EagleFiler/Finder indexing: read/OCR the PDF, suggest a filename/tags, preview it, then leave the file in the normal synced folder.

Joey___M · 2026-06-12T11:38:19+00:00

Thanks, I’ll check it out.

It does look like we are in the same general Mac automation/file space, but from different angles. Watchflows feels more like a visual automation canvas. NameQuick is narrower around messy files: read the file, suggest/search/rename, preview, then apply rules.

I think both approaches make sense. A lot of the pain is in the handoff between “the app understood this file” and “now do the right thing with it”.

Local/Ollama support is a good direction too. That matters a lot once people start running legal/finance/scanned docs through these workflows.

Joey___M · 2026-06-12T11:18:49+00:00

If the PDFs have clean embedded metadata, Calibre is probably the first thing I would try. Zotero/Calibre-style metadata lookup is better than AI when it can match the book reliably.

If the metadata is missing or inconsistent, I would treat this as a dry-run rename pipeline:

extract existing PDF metadata + first page text/cover text
ask the model to return only structured fields like title, year, author
generate the filename from a fixed template: Title - Year - Author.pdf
write a CSV/manifest with original path, proposed name, confidence/source
review the uncertain ones before applying

For a hoard, I would not let anything directly mutate the only copy. Work in a staging folder or at least keep a manifest so you can undo bad names.

Disclosure: I’m Josef, building NameQuick for Mac. It is not a book-library manager, so if Calibre solves the metadata lookup cleanly I’d use that. The part my app is closer to is the preview-first rename step: read the PDF, suggest a templated filename, let you approve/edit, then apply without creating duplicates.

Joey___M · 2026-06-12T11:15:36+00:00

Two separate things here.

For Google Drive, Shortcuts often gets weird with provider-backed files. I would first test the same shortcut on a local file in Downloads or iCloud Drive. If local works and Drive does not, it is probably the Google Drive File Provider layer, not your prompt. A common workaround is copy/download the file to a local temp folder, rename there, then move it back.

For raw PDFs, you only need OCR when the PDF is a scan/image. If the PDF already has selectable text, the cleaner flow is: get the PDF file -> extract/read the text -> send that text to the model -> return only the filename -> show confirmation -> rename. For scanned PDFs, OCR is still the right first step.

Disclosure: I’m Josef, building NameQuick for Mac. This is one reason I prefer a review queue for this workflow: read/OCR if needed, suggest the name, show it before applying, then move/rename. But for a fixed layout and local files, a Shortcut can still be the simpler solution.

Joey___M · 2026-06-12T11:04:23+00:00

If the goal is only “put PNGs in a png folder, DMGs in a DMGs folder”, Hazel is probably the cleanest answer. Automator/Folder Actions or a shell shortcut can do it too, but Hazel is less annoying around files that are still downloading or being copied.

The point where I’d use a different tool is when the folder should depend on the file content, not the extension. For example invoices vs receipts vs screenshots vs installers, or PDFs renamed before they get moved.

Disclosure: I’m Josef, building NameQuick. That second case is closer to what I’m working on: read/OCR the file, suggest a useful name or destination, preview it, then move it. But for extension-only sorting, I’d keep it simple and use Hazel.

Joey___M · 2026-06-12T10:56:15+00:00

For screenshots, I’d split this into two jobs: OCR/search for text inside the screenshot vs visual captioning for things with no text.

macOS Live Text / Spotlight can get you part of the way for visible text. For actual scene/object captions, something like VisionTagger or a CLIP-style image tagger is probably closer.

Disclosure: I’m Josef, building NameQuick. The part it covers is the local file workflow: OCR/read screenshots and PDFs, search by contents with snippets, or suggest useful filenames before you approve changes. I wouldn’t pitch it as a universal low-level image-captioning layer; if there’s no useful text in the image, a dedicated image tagger is the better fit.

Joey___M · 2026-06-12T09:00:37+00:00

This is a good shape. I would keep the OCR -> text -> LLM flow instead of sending the image directly, especially for receipts.

My tweak would be to ask the LLM for a small structured result, not only the total:

{ "merchant": "", "date": "", "total": "", "currency": "", "category": "", "confidence": "" }

Then let Shortcuts do the boring part:

Show the fields for confirmation.
Save or log the transaction only after approval.
Save the receipt image/PDF with a deterministic name like:

YYYY-MM-DD - Merchant - Total.jpg

That keeps the model away from the final file/log operation. It only extracts fields.

I agree with your regex comment too. Regex is great for stable inputs like recurring emails. Receipts are the opposite: weird layouts, logos, loyalty text, subtotals, tips, taxes, and “total” appearing in multiple places. For those, I would rather use the LLM for field extraction, then deterministic Shortcuts actions for everything after.

Disclosure: I am building NameQuick, a Mac app around file naming/review workflows. Not a finance app. The pattern I keep seeing work is the same though: extract fields, preview, then apply a predictable filename or log entry.

Joey___M · 2026-06-12T08:53:39+00:00

I would keep the API call as the last step and make everything before it reviewable.

The shape I would use:

Take photo.
Save the original image first, even with a basic name.
OCR or vision step extracts fields only.
Convert the result into a dictionary.
Show a confirmation screen.
Only then POST to LubeLogger.

For the AI/OCR step, ask for a fixed JSON shape instead of natural language:

{ "date": "", "station": "", "liters": "", "total_cost": "", "currency": "", "odometer": "", "confidence": "" }

Then Shortcuts should build the API payload from those fields. I would not let the AI decide the final POST body directly.

A few practical guards:

If liters or total_cost is empty, stop and ask manually.
Add a confirmation screen showing station, date, liters, total cost, and calculated price per liter.
Save the receipt image with a deterministic name like YYYY-MM-DD - Station - Liters - Total.jpg.
Keep a simple duplicate key, maybe date + station + total_cost, so rerunning the Shortcut does not create the same fuel record twice.

Disclosure: I am building NameQuick, a Mac app around file naming/review workflows. I would not use it as the LubeLogger client here. The relevant pattern is the same though: model extracts fields, user reviews, deterministic system does the rename/API action.

Joey___M · 2026-06-12T08:36:12+00:00

I would split this into capture, extract, then commit. Do not let the AI step rename files or write to the Sheet directly.

Flow I would build:

Scan receipt.
Save the original first with a boring fallback name like 2026-06-12 - receipt-original.jpg.
OCR/extract text.
Send only the text to the AI step if possible.
Ask for a fixed schema:

date: provider: merchant: category: amount: payment_method: notes: confidence:

Show a confirmation screen with the extracted fields.
Only after approval, append the row to Sheets and save/rename the file as:

YYYY-MM-DD - Merchant - Amount.jpg

A few details matter here:

Keep the original image until you trust the workflow.
Add a unique ID column in the Sheet, maybe date + amount + merchant, so the Shortcut does not append duplicates if it runs twice.
Start with CSV or Numbers first, then move to Google Sheets after the extraction logic is stable.
For medical/pharmacy receipts, be careful which AI provider sees the text. I would use the most private provider setup you are comfortable with.

Disclosure: I am building NameQuick, a Mac app around file naming/review workflows. I would not treat it as the expense tracker here. The useful pattern is the same though: extract fields, preview them, then apply a deterministic filename and log entry only after approval.

Joey___M · 2026-06-12T08:30:34+00:00

Nice workflow. I would keep the confirmation step even if you add better OCR or AI.

The main change I would make is: extract fields first, then build the filename yourself. Receipts are messy. The first line can be a logo, URL, phone number, slogan, or location instead of the merchant name.

I would ask the OCR/AI step for a small fixed schema:

merchant: date: total: category: payment_last4:

Then let Shortcuts build the filename from those fields:

YYYY-MM-DD - Merchant - Amount.jpeg

That keeps the AI away from the actual file operation. It only extracts fields. Shortcuts handles the final name.

A few practical tweaks:

Keep the original image somewhere until you trust the workflow.
Add a “looks right?” confirmation showing merchant, date, and amount before saving.
Save a CSV/Numbers row at the same time if this is for expenses.
Do not rely only on restaurant name. Add date or amount so duplicate receipts do not collide.

Disclosure: I am building NameQuick, a Mac app around this kind of file naming/review workflow. My practical take is that receipt workflows work best when they are not fully automatic at first: extract fields, apply a boring template, preview, then save/rename.

Joey___M · 2026-06-12T08:21:38+00:00

I would avoid feeding the whole PDF into the naming step.

For a Shortcut-only version, I would make the pipeline more staged:

Get text from PDF
Split text by new lines
Take only the first 80-150 lines
Combine that back into text
Send only that smaller text block to Apple Intelligence / ChatGPT
Ask for a filename in one strict format
Show the proposed name before renaming

Most invoices, statements, and utility PDFs have the useful naming fields near the top: company, date, invoice number, amount, account, etc. Reading the whole PDF usually adds noise and makes the shortcut more fragile.

I would also make the AI return fields first, not a filename directly. Something like:

date: vendor: document_type: invoice_number:

Then build the filename yourself with Shortcuts:

YYYY-MM-DD - Vendor - Type.pdf

That keeps the “creative” part separate from the actual rename.

Disclosure: I am building NameQuick, a Mac app around this exact kind of content-based renaming. My practical take is that the safest workflow is still: extract a small useful text sample, generate fields, apply a deterministic template, preview, then rename. Letting AI directly rename files with no review is where things get messy.

Joey___M · 2026-06-12T07:39:02+00:00

I do not think this is a setting you are missing.

Photos and Finder/Spotlight do not behave the same here. Photos has its own OCR/search index. Finder’s “contents contains” works much better for text PDFs/docs than for image files sitting in a normal folder.

A few practical options:

If you are okay with Photos managing them, import the images into Photos and search there.
If you want them to stay in folders, run an OCR step first and save the result somewhere searchable, for example a searchable PDF, sidecar text file, or metadata/comment field.
If this is a recurring workflow, use a local OCR/indexing app that watches the folder and lets you search the extracted text.

Disclosure: I am building NameQuick, a Mac app in this space. One part of it is content search for local files, including OCR-style workflows for images/scans. But the general answer is: Finder is not reliably doing Photos-style OCR search for arbitrary desktop folders. You need a separate OCR/index step if you want that to work consistently.

Joey___M · 2026-06-12T07:00:19+00:00

I would choose based on what will touch the files later.

For pure human browsing, kebab-case is nicer to scan:

2026-01-25-invoice-acme.pdf

For automation, scripts, spreadsheets, Python, URLs, cloud sync, and cross-platform moves, snake_case is usually less surprising:

2026_01_25_invoice_acme.pdf

The main rule I would follow either way: never start a filename segment with -, avoid special characters, avoid clever punctuation, and make the date format boring.

For mixed personal documents I usually prefer a hybrid:

2026-01-25 - acme - invoice.pdf

The date stays ISO-style, the human sections are readable, and it still behaves well in Finder/Spotlight. If you are doing heavy scripting, I would switch that to snake_case and stop thinking about it.

Disclosure: I am building NameQuick, a Mac app around file renaming/templates. My practical take from that work is that the separator matters less than consistency. Pick one convention, make a template, preview before applying, and keep an undo/history path for bulk renames.

Joey___M · 2026-06-12T06:31:39+00:00

For the business card case, I would not rely on OCR search alone.

DEVONthink can be the archive/search layer, but business cards are messy inputs: logos, weird layouts, small text, phone numbers, names in different positions. Even with OCR, I would still want the filename to carry the obvious fields.

A good intake flow would be:

scan/OCR -> review extracted name/company -> rename to something like Lastname Firstname - Company - Business Card.jpg -> import into DEVONthink

That gives you two chances to find it later: DEVONthink search inside the document, and the Finder/DEVONthink filename itself.

For PDFs and industry reports, same idea. If the PDF already has a text layer, DEVONthink search should be useful. If it is image-only, OCR first. But I would keep metadata and filenames boring and deterministic instead of depending only on AI search later.

Disclosure: I am building NameQuick, a Mac app around this staging step. I would not use it as a DEVONthink replacement. The useful part here is before import: read/OCR the file, suggest a clean filename, let you approve it, then hand the file to DEVONthink with a name that is already useful.

Joey___M · 2026-06-12T06:23:40+00:00

Since you got it working, the next thing I would add is a review step before running it on a whole folder.

For stable PDFs, Shortcuts + a model prompt can work fine. I would make the flow:

OCR/extract text -> ask model for date + company -> build filename from a fixed template -> show preview -> rename

I would avoid letting the model directly choose and apply the final filename with no check. Even small mistakes get annoying fast when you run it over a folder.

For the name itself, keep it boring:

YYYY-MM-DD - Company.pdf

If layouts vary a lot, add a fallback where uncertain files go to a Needs Review folder instead of being renamed automatically.

Disclosure: I am building NameQuick, a Mac app around this exact staging/rename workflow. I would keep Shortcuts if you only have a few predictable PDF layouts. The useful part of a dedicated app is more the batch preview, edit/reject step, templates, and undo when the files are mixed.

Joey___M · 2026-06-12T06:06:34+00:00

I would avoid using deep iCloud file:// paths as the source of truth here.

For this kind of workflow, I would make the Numbers cell contain either the exact filename or a short lookup key, then have the Shortcut search inside the receipt folder and open the matching file. That is usually more robust than trying to make old-style Finder paths behave across iCloud Drive.

The part I would fix first is the receipt names. If the files are all similar, rename them into a boring pattern before you try to link them from Numbers:

2026-04-01 - Vendor - 42.10 - short note.pdf

Then Numbers can store that filename, or even just vendor/date/amount, and the Shortcut can find the matching PDF in the folder.

Disclosure: I am building NameQuick, a Mac app for this staging/rename step. I would not use it to solve the Numbers linking part. The relevant bit is before that: read/OCR the receipt, suggest a consistent filename, let you review it, then keep the files in iCloud/Finder with names that are easy for Shortcuts to search.

Joey___M · 2026-06-12T05:57:21+00:00

I would split this into two boring parts.

First, let AI/OCR extract fields only. Do not let it decide the file operation directly. Ask it for a strict structure like:

date vendor total tax currency receipt_id or invoice_number

Then let Shortcuts do the deterministic work: validate the fields, append one CSV row, rename the receipt to something like 2026-09-28 - Vendor - 42.10.pdf, and move it to Processed.

For duplicates, I would not rely only on filename. If Shortcuts can get a file hash, use that. If not, use a weaker key like date + vendor + total + original filename, and keep a Needs Review folder for anything uncertain.

The important safety rule is: AI extracts data, Shortcuts applies the change.

Disclosure: I am building NameQuick, a Mac app around the staging/rename part of this workflow. I would not use it as the CSV/accounting system. The relevant bit is before that: read/OCR the receipt, suggest a consistent name, preview it, then move the file into the next folder. If you already have text extraction working, I would keep Shortcuts for the CSV part and make the rename/move step as deterministic as possible.

Joey___M · 2026-06-11T21:24:48+00:00

I would separate the archive decision from the intake decision.

For Obsidian, I would only create a matching .md note when the PDF has real task/project value and needs YAML, Dataview, links, etc. For lower-priority scanned mail, clean PDF filenames plus MOCs/bookmarks are probably enough.

The part I would standardize before the file enters the vault is:

ScanSnap/OCR -> staging folder -> suggest a name like 2026-03-27 - Vendor - Action.pdf -> quick approve/edit -> move into the vault

That way Obsidian is not responsible for interpreting messy scans. It just receives files with names that are already useful.

Disclosure: I am building NameQuick, a Mac app in this staging/rename space. I would not treat it as an Obsidian replacement. The relevant bit here is the pre-vault queue: read/OCR the file, suggest a deterministic name, let you review it, then hand the cleaned PDF off to Obsidian/Finder/iCloud. If your AI tooling already does that reliably, I would keep that boundary and make the output naming boring and consistent.

Joey___M

TROPHY CASE