phyllisstein

Functionality for this workflow has been folded into "Open in Sublime." Just enter the keyword "subl" to be given the option of opening the frontmost Finder window's items in Sublime or opening a recent project. The keyword "sub*" allows you to search all your files for a particular one to send to Sublime, and the "Open in Sublime" file action does precisely what you'd expect. The version of ST that you're using is automatically detected, with preference given to ST3 (way of the future and all).
 
Download Here

Oh, I also forgot that there's another trick I read about. Try adding shopt -s expand_aliases at the beginning of your script. I can't remember whether Pedro's Googling or mine turned it up, but that was necessary to get a background-command workflow to source the user's .bash_profile correctly for some reason.

Note from Andrew: While this is a convenient method for updating workflows, I cannot endorse the use of it unless you are fully aware of the security implications of blanket updating all of your workflows. I'm currently working on a built in workflow auto-updater, for a future Alfred 2 release, that performs the standard verification checks that Alfred currently does on manual import, along with migrating your hotkey/keyword settings on upgrading. I'll also be adding 3rd party workflow developer signatures to keep you safe.
 
Hey all,
I've just completed a workflow designed to make it easier for workflow developers to push updates to their work. (And to their flows.) It's called Alleyoop, it's based very heavily on the concept behind David's old extension updater, and it works a little something like this:
When you enter the query oop, it searches through the workflow folders for files named update.json. update.json indicates what version of the workflow is currently installed and where to check for an update. (The format is below.) Alleyoop downloads a remote json file, indicated in update.json, and if that file indicates a higher version, it downloads the workflow at the address given by the remote file. The user finds the workflow in his or her ~/Downloads directory and opens it. There is no step 4. Workflow developers can start implementing this workflow immediately. All you need is a static place to host a json file and an alfredworkflow file—so Github will do, failing all else, but Droplr won't. Place an update.json file in your workflow, with the following keys defined:
 
{ "version": 1.0, "remote_json": "http://alfred.daniel.sh/Updates/Things.json" }  
version should be a float, meaning that 1.0 and 1.1 and 3.14159 are all valid, but 3.1.4 is not, and remote_json should point to a json file on a remote server that's defined like this:
{ "version": 1.5, "download_url": "http://alfred.daniel.sh/Workflows/Things.alfredworkflow", "description": "Brief description of the update." }  
If the version on the remote server is greater than the version on the user's computer, s/he'll see something like this:

 
Selecting a workflow from the list will download it. No fuss, no muss.
 
And that's it! Enjoy implementing this, until we get a good package manager running again, and let me know if you run into any difficulties.
 
Download Here

Good news, everyone! I've just pushed a new version of the workflow that has Unicode working without a hitch. You can get it through Alleyoop or at http://alfred.daniel.sh/Workflows/Downer.alfredworkflow . Share and enjoy!

The previously released menu search workflow has been universally panned due to the poor performance of the AppleScript that dumps menu contents. The caching of results worked very poorly as a stop-gap. So, I've re-written the menu extraction in Objective-C. It's much faster. The source is here: https://github.com/ctwise/alfred-workflows
 
You can download the workflow directly from http://tedwi.se/u/db
 
To recap, this workflow lets you trigger an application's menu's from Alfred. For example, if you're in iTerm and trigger Alfred, you can type 'm view' to get a list of all menu items with 'view' in the name or that belong to the 'view' menu. Selecting one of the entries triggers the corresponding menu entry in iTerm. In one sense it gives you a command-line to control your applications.
 
The workflow has the beginnings of shortcut key display as well but it's currently disabled due to numerous bugs.
 
Update: 
 
v1.3 - Provide error message when assistive devices isn't checked.
v1.2 - Skip the Safari History and Bookmarks menus. They take too long.
v1.1 - I fixed the bug with Alfred not remembering selections and added AlleyOop support. Download from the same link.
 
Requires OS/X 10.7+.
 
---
 
You need to turn on OS/X assistive device support to allow this workflow to operate. You can find the checkbox in Settings. The settings page looks very different in recent versions of OS/X but the wording for providing access for assistive devices is very similar no matter what OS/X version you're using. Here's an image of the settings from the latest version of Mountain Lion.
 

I often cut/copy a bunch of text, then switch to BBEdit, then create a new document, then paste the text.
 
I realized today that this is stupid and inefficient, when all I really need to do it
 
pbpaste | bbedit
 
so I created an Alfred workflow that does just that.
 
http://share.luo.ma/alfred/bbpaste.alfredworkflow
 
Note:
 
To use this you'll need BBEdit installed, obviously, but also the bbedit command line tool. If you purchased BBEdit from the Mac App Store, you will have to download and install them from here:
 
http://www.barebones.com/support/bbedit/cmd-line-tools.html

Note from Andrew: While this is a convenient method for updating workflows, I cannot endorse the use of it unless you are fully aware of the security implications of blanket updating all of your workflows. I'm currently working on a built in workflow auto-updater, for a future Alfred 2 release, that performs the standard verification checks that Alfred currently does on manual import, along with migrating your hotkey/keyword settings on upgrading. I'll also be adding 3rd party workflow developer signatures to keep you safe.
 
Hey all,
I've just completed a workflow designed to make it easier for workflow developers to push updates to their work. (And to their flows.) It's called Alleyoop, it's based very heavily on the concept behind David's old extension updater, and it works a little something like this:
When you enter the query oop, it searches through the workflow folders for files named update.json. update.json indicates what version of the workflow is currently installed and where to check for an update. (The format is below.) Alleyoop downloads a remote json file, indicated in update.json, and if that file indicates a higher version, it downloads the workflow at the address given by the remote file. The user finds the workflow in his or her ~/Downloads directory and opens it. There is no step 4. Workflow developers can start implementing this workflow immediately. All you need is a static place to host a json file and an alfredworkflow file—so Github will do, failing all else, but Droplr won't. Place an update.json file in your workflow, with the following keys defined:
 
{ "version": 1.0, "remote_json": "http://alfred.daniel.sh/Updates/Things.json" }  
version should be a float, meaning that 1.0 and 1.1 and 3.14159 are all valid, but 3.1.4 is not, and remote_json should point to a json file on a remote server that's defined like this:
{ "version": 1.5, "download_url": "http://alfred.daniel.sh/Workflows/Things.alfredworkflow", "description": "Brief description of the update." }  
If the version on the remote server is greater than the version on the user's computer, s/he'll see something like this:

 
Selecting a workflow from the list will download it. No fuss, no muss.
 
And that's it! Enjoy implementing this, until we get a good package manager running again, and let me know if you run into any difficulties.
 
Download Here

Hah, sorry about that—I switched hosts and kept having to reconfigure from scratch. As God is my witness, never another custom mail server again ever. Should be consistently back up now.
 
 
 
 
I thought about that, but I think there may be a fine line between killing an afternoon avoiding finals and totally rewriting Hazel.

Note from Andrew: While this is a convenient method for updating workflows, I cannot endorse the use of it unless you are fully aware of the security implications of blanket updating all of your workflows. I'm currently working on a built in workflow auto-updater, for a future Alfred 2 release, that performs the standard verification checks that Alfred currently does on manual import, along with migrating your hotkey/keyword settings on upgrading. I'll also be adding 3rd party workflow developer signatures to keep you safe.
 
Hey all,
I've just completed a workflow designed to make it easier for workflow developers to push updates to their work. (And to their flows.) It's called Alleyoop, it's based very heavily on the concept behind David's old extension updater, and it works a little something like this:
When you enter the query oop, it searches through the workflow folders for files named update.json. update.json indicates what version of the workflow is currently installed and where to check for an update. (The format is below.) Alleyoop downloads a remote json file, indicated in update.json, and if that file indicates a higher version, it downloads the workflow at the address given by the remote file. The user finds the workflow in his or her ~/Downloads directory and opens it. There is no step 4. Workflow developers can start implementing this workflow immediately. All you need is a static place to host a json file and an alfredworkflow file—so Github will do, failing all else, but Droplr won't. Place an update.json file in your workflow, with the following keys defined:
 
{ "version": 1.0, "remote_json": "http://alfred.daniel.sh/Updates/Things.json" }  
version should be a float, meaning that 1.0 and 1.1 and 3.14159 are all valid, but 3.1.4 is not, and remote_json should point to a json file on a remote server that's defined like this:
{ "version": 1.5, "download_url": "http://alfred.daniel.sh/Workflows/Things.alfredworkflow", "description": "Brief description of the update." }  
If the version on the remote server is greater than the version on the user's computer, s/he'll see something like this:

 
Selecting a workflow from the list will download it. No fuss, no muss.
 
And that's it! Enjoy implementing this, until we get a good package manager running again, and let me know if you run into any difficulties.
 
Download Here

DEVONthink Document Search
 
This workflow helps you to find your DEVONthink documents from within Alfred. It supports DEVONthink Personal as well as DEVONthink Pro (with multiple databases).
 
Installation
 
Download from GitHub and import into Alfred 2.
 
Usage
 
Keywords
Search in all databases devon [your search string]
 
Search in specific database devondb [your search string]

 
 
 
Refresh DEVONthink datanase list

The association between database names and uuids can only be obtained via AppleScript. This is done automatically if you run the "devondb" command for the first time. The information is then cached for better performance. If you add a new DEVONthink database later on, you'll have to run the "devondb!" command to refresh the database list. devondb!

Alright, I've just uploaded a new version to http://alfred.daniel.sh/Workflows/OpenMetaTags.alfredworkflow that will hopefully correct the problem. If not, let me know.

Hello, fellow workers of flow! I've just thrown together a new workflow that searches and sets OpenMeta tags and opens files that have already been tagged. You can download it here! Just install it, then enter "tags" to display—after about a second—a list of all the tags currently set on your system. Select a tag and press Return to add it to the Finder selection's current tags, or keep typing. In which case the workflow will search through the tags on your system for tags containing and related to your query. (Note that "related to" really means "related to": if a document is tagged "alice" and "bob," searching for "bob" will turn up "alice" as related.) It'll also list documents tagged with your query. Select a tag and hit Return to tag the Finder selection (again), or choose a document and hit Return to open it. Hitting Tab while a tag is selected will autocomplete to that tag, making it a cinch to search for tagged documents.
 
In the updated version, also at the link above, holding down Ctrl while pressing Return will remove the chosen tag from the Finder selection or, if a file is highlighted in Alfred, clear all tags from that file. The updated version is also a bit greedier with the metadata attributes it sets, so that stale data won't be left behind for other apps to potentially use by mistake.
 
So, have fun, tag away, and enjoy using OpenMeta without paying $29 for Tags.app!
 

Nice work! You might want to rename it to reflect the fact that it's adding comments, not tags, though; OpenMeta tags are a different animal than Spotlight comments, as you can see from my tagging workflow.

I think that I've spotted the issue that was causing @parekh problems. I've updated the workflow, but it may have to be manually downloaded from this link, as I suspect that its self-update mechanism was affected by the bug.

Very fancy! Nicely done.

Mailtags Workflow 2.5

Workflow to tag, tickle and set Project to emails using MailTags 3.

The workflow was suggested by rdpozo.

Usage
Select email(s) from Apple Mail app Bring Alfred and type the keyword mtag (for tagging) or mproj (for Project) or mtic (for Tickle) Select a tag or Project or Tickle from the list or type a new one. You can also type multiple tags separating them by comma e.g. tag1,tag2,tag3 Hit return key You can set a new email Tickle by typing the date (e.g. 4/5/13 or 4-5-2013 or 4.5.13) or by telling how many days from now on (e.g. 5 days or 10 days).
 
To delete all tags or tickle hold control key (requires MailTags 3.2.2).
 
Type the keyword inbox to access your emails and set tags (return key), a tickle (control key) or a project (option key). This feature is still in progress. It will be slow if you have several messages in your inbox. Any feedback will be appreciated.




You can also use a hotkey to bring Alfred or a second hotkey to tag with the text inside the hotkey configuration (see screenshot below from version 1.0). The same with Project.



What’s new
 
 
Version 2.5
Remove all tags from selected messages (hold control key in keyword mtag) Remove tickle from selected messages (hold control key in keyword mtic) Keyword inbox to access your inbox messages and tag (return key), set tickle (control key) or a project (option key) MailTags version 3.2.2 or greater is required  
Version 2.1
Fixed Tickle bug (thanks to Scott) Version 2.0
Multiple tags: separate them by comma e.g. tag1,tag2,tag3 Projects from Things, OmniFocus and The Hit List will also be listed Version 1.5
Tags and projects read from MailTags database (thanks to Scott) Version 1.2
tickle support Version 1.1
support for Projects list of tags (preferred and from the selected email) Download

Version 2.5
Release date: 19 May 2013
Requires: Apple Mail app and MailTags 3 version 3.2.2 or greater
Supports Alleyoop 2
Download Now

Functionality for this workflow has been folded into "Open in Sublime." Just enter the keyword "subl" to be given the option of opening the frontmost Finder window's items in Sublime or opening a recent project. The keyword "sub*" allows you to search all your files for a particular one to send to Sublime, and the "Open in Sublime" file action does precisely what you'd expect. The version of ST that you're using is automatically detected, with preference given to ST3 (way of the future and all).
 
Download Here

Note from Andrew: While this is a convenient method for updating workflows, I cannot endorse the use of it unless you are fully aware of the security implications of blanket updating all of your workflows. I'm currently working on a built in workflow auto-updater, for a future Alfred 2 release, that performs the standard verification checks that Alfred currently does on manual import, along with migrating your hotkey/keyword settings on upgrading. I'll also be adding 3rd party workflow developer signatures to keep you safe.
 
Hey all,
I've just completed a workflow designed to make it easier for workflow developers to push updates to their work. (And to their flows.) It's called Alleyoop, it's based very heavily on the concept behind David's old extension updater, and it works a little something like this:
When you enter the query oop, it searches through the workflow folders for files named update.json. update.json indicates what version of the workflow is currently installed and where to check for an update. (The format is below.) Alleyoop downloads a remote json file, indicated in update.json, and if that file indicates a higher version, it downloads the workflow at the address given by the remote file. The user finds the workflow in his or her ~/Downloads directory and opens it. There is no step 4. Workflow developers can start implementing this workflow immediately. All you need is a static place to host a json file and an alfredworkflow file—so Github will do, failing all else, but Droplr won't. Place an update.json file in your workflow, with the following keys defined:
 
{ "version": 1.0, "remote_json": "http://alfred.daniel.sh/Updates/Things.json" }  
version should be a float, meaning that 1.0 and 1.1 and 3.14159 are all valid, but 3.1.4 is not, and remote_json should point to a json file on a remote server that's defined like this:
{ "version": 1.5, "download_url": "http://alfred.daniel.sh/Workflows/Things.alfredworkflow", "description": "Brief description of the update." }  
If the version on the remote server is greater than the version on the user's computer, s/he'll see something like this:

 
Selecting a workflow from the list will download it. No fuss, no muss.
 
And that's it! Enjoy implementing this, until we get a good package manager running again, and let me know if you run into any difficulties.
 
Download Here

Thanks, Carlos. I believe that is indeed the problem: Droplr doesn't automatically redirect you to the file you're trying to download, so the workflow is downloading the raw webpage data and trying to call it an alfredworkflow file. You should try to link directly to "YourWorkflow.alfredworkflow" whenever possible, or to a URL that reliably redirects to "YourWorkflow.alfredworkflow" (like a bit.ly link).
 
The workflows are stored by name in ~/Downloads because that datum can be extracted from their Info.plist files, whereas the original filenames can't. And I can't reliably grab the workflow filename from the web address, for fear of breaking it for people who use redirect services. As for auto-opening the file after it's downloaded, I'd prefer to leave that to the user, who should be able to eyeball the file for potential maliciousness at some point in the process.

Note from Andrew: While this is a convenient method for updating workflows, I cannot endorse the use of it unless you are fully aware of the security implications of blanket updating all of your workflows. I'm currently working on a built in workflow auto-updater, for a future Alfred 2 release, that performs the standard verification checks that Alfred currently does on manual import, along with migrating your hotkey/keyword settings on upgrading. I'll also be adding 3rd party workflow developer signatures to keep you safe.
 
Hey all,
I've just completed a workflow designed to make it easier for workflow developers to push updates to their work. (And to their flows.) It's called Alleyoop, it's based very heavily on the concept behind David's old extension updater, and it works a little something like this:
When you enter the query oop, it searches through the workflow folders for files named update.json. update.json indicates what version of the workflow is currently installed and where to check for an update. (The format is below.) Alleyoop downloads a remote json file, indicated in update.json, and if that file indicates a higher version, it downloads the workflow at the address given by the remote file. The user finds the workflow in his or her ~/Downloads directory and opens it. There is no step 4. Workflow developers can start implementing this workflow immediately. All you need is a static place to host a json file and an alfredworkflow file—so Github will do, failing all else, but Droplr won't. Place an update.json file in your workflow, with the following keys defined:
 
{ "version": 1.0, "remote_json": "http://alfred.daniel.sh/Updates/Things.json" }  
version should be a float, meaning that 1.0 and 1.1 and 3.14159 are all valid, but 3.1.4 is not, and remote_json should point to a json file on a remote server that's defined like this:
{ "version": 1.5, "download_url": "http://alfred.daniel.sh/Workflows/Things.alfredworkflow", "description": "Brief description of the update." }  
If the version on the remote server is greater than the version on the user's computer, s/he'll see something like this:

 
Selecting a workflow from the list will download it. No fuss, no muss.
 
And that's it! Enjoy implementing this, until we get a good package manager running again, and let me know if you run into any difficulties.
 
Download Here

Note from Andrew: While this is a convenient method for updating workflows, I cannot endorse the use of it unless you are fully aware of the security implications of blanket updating all of your workflows. I'm currently working on a built in workflow auto-updater, for a future Alfred 2 release, that performs the standard verification checks that Alfred currently does on manual import, along with migrating your hotkey/keyword settings on upgrading. I'll also be adding 3rd party workflow developer signatures to keep you safe.
 
Hey all,
I've just completed a workflow designed to make it easier for workflow developers to push updates to their work. (And to their flows.) It's called Alleyoop, it's based very heavily on the concept behind David's old extension updater, and it works a little something like this:
When you enter the query oop, it searches through the workflow folders for files named update.json. update.json indicates what version of the workflow is currently installed and where to check for an update. (The format is below.) Alleyoop downloads a remote json file, indicated in update.json, and if that file indicates a higher version, it downloads the workflow at the address given by the remote file. The user finds the workflow in his or her ~/Downloads directory and opens it. There is no step 4. Workflow developers can start implementing this workflow immediately. All you need is a static place to host a json file and an alfredworkflow file—so Github will do, failing all else, but Droplr won't. Place an update.json file in your workflow, with the following keys defined:
 
{ "version": 1.0, "remote_json": "http://alfred.daniel.sh/Updates/Things.json" }  
version should be a float, meaning that 1.0 and 1.1 and 3.14159 are all valid, but 3.1.4 is not, and remote_json should point to a json file on a remote server that's defined like this:
{ "version": 1.5, "download_url": "http://alfred.daniel.sh/Workflows/Things.alfredworkflow", "description": "Brief description of the update." }  
If the version on the remote server is greater than the version on the user's computer, s/he'll see something like this:

 
Selecting a workflow from the list will download it. No fuss, no muss.
 
And that's it! Enjoy implementing this, until we get a good package manager running again, and let me know if you run into any difficulties.
 
Download Here

Note from Andrew: While this is a convenient method for updating workflows, I cannot endorse the use of it unless you are fully aware of the security implications of blanket updating all of your workflows. I'm currently working on a built in workflow auto-updater, for a future Alfred 2 release, that performs the standard verification checks that Alfred currently does on manual import, along with migrating your hotkey/keyword settings on upgrading. I'll also be adding 3rd party workflow developer signatures to keep you safe.
 
Hey all,
I've just completed a workflow designed to make it easier for workflow developers to push updates to their work. (And to their flows.) It's called Alleyoop, it's based very heavily on the concept behind David's old extension updater, and it works a little something like this:
When you enter the query oop, it searches through the workflow folders for files named update.json. update.json indicates what version of the workflow is currently installed and where to check for an update. (The format is below.) Alleyoop downloads a remote json file, indicated in update.json, and if that file indicates a higher version, it downloads the workflow at the address given by the remote file. The user finds the workflow in his or her ~/Downloads directory and opens it. There is no step 4. Workflow developers can start implementing this workflow immediately. All you need is a static place to host a json file and an alfredworkflow file—so Github will do, failing all else, but Droplr won't. Place an update.json file in your workflow, with the following keys defined:
 
{ "version": 1.0, "remote_json": "http://alfred.daniel.sh/Updates/Things.json" }  
version should be a float, meaning that 1.0 and 1.1 and 3.14159 are all valid, but 3.1.4 is not, and remote_json should point to a json file on a remote server that's defined like this:
{ "version": 1.5, "download_url": "http://alfred.daniel.sh/Workflows/Things.alfredworkflow", "description": "Brief description of the update." }  
If the version on the remote server is greater than the version on the user's computer, s/he'll see something like this:

 
Selecting a workflow from the list will download it. No fuss, no muss.
 
And that's it! Enjoy implementing this, until we get a good package manager running again, and let me know if you run into any difficulties.
 
Download Here

Functionality for this workflow has been folded into "Open in Sublime." Just enter the keyword "subl" to be given the option of opening the frontmost Finder window's items in Sublime or opening a recent project. The keyword "sub*" allows you to search all your files for a particular one to send to Sublime, and the "Open in Sublime" file action does precisely what you'd expect. The version of ST that you're using is automatically detected, with preference given to ST3 (way of the future and all).
 
Download Here

Note from Andrew: While this is a convenient method for updating workflows, I cannot endorse the use of it unless you are fully aware of the security implications of blanket updating all of your workflows. I'm currently working on a built in workflow auto-updater, for a future Alfred 2 release, that performs the standard verification checks that Alfred currently does on manual import, along with migrating your hotkey/keyword settings on upgrading. I'll also be adding 3rd party workflow developer signatures to keep you safe.
 
Hey all,
I've just completed a workflow designed to make it easier for workflow developers to push updates to their work. (And to their flows.) It's called Alleyoop, it's based very heavily on the concept behind David's old extension updater, and it works a little something like this:
When you enter the query oop, it searches through the workflow folders for files named update.json. update.json indicates what version of the workflow is currently installed and where to check for an update. (The format is below.) Alleyoop downloads a remote json file, indicated in update.json, and if that file indicates a higher version, it downloads the workflow at the address given by the remote file. The user finds the workflow in his or her ~/Downloads directory and opens it. There is no step 4. Workflow developers can start implementing this workflow immediately. All you need is a static place to host a json file and an alfredworkflow file—so Github will do, failing all else, but Droplr won't. Place an update.json file in your workflow, with the following keys defined:
 
{ "version": 1.0, "remote_json": "http://alfred.daniel.sh/Updates/Things.json" }  
version should be a float, meaning that 1.0 and 1.1 and 3.14159 are all valid, but 3.1.4 is not, and remote_json should point to a json file on a remote server that's defined like this:
{ "version": 1.5, "download_url": "http://alfred.daniel.sh/Workflows/Things.alfredworkflow", "description": "Brief description of the update." }  
If the version on the remote server is greater than the version on the user's computer, s/he'll see something like this:

 
Selecting a workflow from the list will download it. No fuss, no muss.
 
And that's it! Enjoy implementing this, until we get a good package manager running again, and let me know if you run into any difficulties.
 
Download Here

(--- update: currently on version 1.05 -- download links all the same)
 
So, I have a workflow problem in that I like to install them. Quite a few of them, and I can easily lose track of the commands for each of them. Hence, I present to you a tool that I needed for me: Alfred2 Workflows Help.
 
Basically, this is a python script that will cycle through your workflows folder, process the info.plist files, and grab the hotkeys and commands from each of them. Then it will compile all of them into a Markdown file, and then show that file in a Quicklook window. Yes! Screenshot is below.
 
Github Repository here: https://github.com/shawnrice/alfred2-workflow-help
Download here: https://github.com/shawnrice/alfred2-workflow-help/raw/master/Command%20Help.alfredworkflow
 
Currently, there is just one command: help.
 
The file can take a few seconds to generate, and it is generated every time. This will change in a later version.
 
---
 
Some notes: The main script (help.py) is written in python, and it's really my first venture into python, so the code might be laughable. I welcome collaboration and commits. I can give you access to the repo if you private message me. I do think that this workflow has a lot of potential.
 
This is version 1.0, and there are many improvements to be made. It has Alleyoop support, so updating should be easy.
 
Quirks and files included:
This workflow displays the file generated through a debug mode of Quicklook (so that the focus doesn't need to switch to finder), so there will always be a "[debug]" message on the window. I've included a Quicklook Markdown generator in the workflow to make sure that it always displays correctly. There are some images that are included that are not currently used (these are in the "images" folder). They will be used to show the hotkeys later. ALP is included. Right now, only part of the library is used, so I might strip it down to make the workflow smaller. So, the size of the workflow is larger because of these things in there.
 
---
 
Roadmap:
Clean up the help.py code. Cache the generated file and update it only when the workflow folder changes. Make the display of the file nicer. Add in more images to the file. Display individual workflow helps (show the data for that workflow as well as the readme.md file). Have a better precedent to show either text or subtext for the command help. Try to figure out a way to describe arguments taken for different commands / hotkeys. Make it understand file actions better. Clean up the file/folder structure. Maybe some more... any ideas?  
Dependencies and Testing:
Built on 10.8.3, but this should be compatible for all systems as the only dependencies are included in the workflow.
 
Screenshot: