I have my emacs set up so that every time I create a new file with ".perl" at the end of the file name, it automatically inserts the following into the editing buffer:

#!/usr/bin/perl

=head1 NAME

=head1 SYNOPSIS

=head1 DESCRIPTION

=cut

use strict;

my $Usage = "$0 ";
[download]

The very next thing that happens, after I open this new perl file, is I fill in the blanks. Then I start to write perl code -- and if it is a command-line tool that I'm writing (almost always the case), the first code that I write is "die $Usage if ..." (or "unless...") with suitable conditions checking the command line args. (Naturally, Getopts::Long or Getopts::Std is usually involved in that part.)

I make a habit of never using "-?" as an actual command line option flag, so whenever I need to see the usage message, I run the script with "-?" as the sole option, which always causes the script to die and print $Usage. If that and the name of the script are not enough to remind me what the script is supposed to do (or what I'm supposed to do with it), the "$0" in the usage message always prints the full path to the script, and I can then paste that as an arg to "perldoc", to see the pod.

Apart from that, a perl-tk pod browser is definitely a good idea -- I have one that I adapted from sample code that came with the Perl/Tk bundle, to show all the docs for the core distribution and for all installed modules. It just does a system() call to run "xterm -e perldoc chosen-page &" (which uses "less" as the pager), so I can have as many scrollable man pages as I want on the screen at once. I just now posted that here (Code->GUI Programming->PerlMan). (Heh, since I adapted that from someone else's code, my normal emacs init didn't happen there -- but it's a GUI, it doesn't have command line args, so who cares...)

You could easily adapt that to all the perl programs in your arsenal, if these are all kept in places that are marked in your PATH environment variable, and if they all have a consistent file name pattern (e.g. *.pl or *.perl). Adding widgets for running command lines might be fun (or scary, depending on the roles you fill at your job).