NAME

{{$name}} - Add the module abstract here

```

Don't be concern yourself with the funny-looking curly brackes now–more on templates later.

Lastly, we are going to add the `dist_ini.txt` file to your blueprint, the file mentioned in the `[DistINI]` section of your `profile.ini` configuration file. Create the `dist_ini.txt` file and add the following lines to it, which should look familiar to you:

```

[@Starter] [ReadmeAnyFromPod] type = markdown filename = README.md location = root

```

If you guessed that the contents of `dist_ini.txt` will end up inside your `dist.ini` file, you guessed right.

You should now have three files in the `default` directory. Together, they comprise your first factory blueprint. Let's see if you cut and paste everything correctly. Do a `cd ~/dzil_projects` and try creating a new work area:

`dzil new Super::Greetings`

If you see a new `Super-Greetings` directory and `Dist::Zilla` didn't throw any errors at you, congratulations, you've successfully ~~minted~~ drafted and processed your first ~~profile~~ blueprint. If something went wrong, go back and inspect your three blueprint files for errors and try again.

## Exploring Your New Factory

Look inside your new work area and you'll see that your `dist.ini` has all the plugins and parameters you supplied in your `plugins.ini` file. The global configuration parameters at the top of of the `dist.ini` file were added for you as well. You might also notice something missing, though. More on that in a bit.

Now open the `lib` directory where your module lives. Inside of that directory is the `Super` directory and inside of that directory is a `Greetings` directory and inside of that directory we finally see your `Greetings.pm` module file. `Dist::Zilla` created this nested directory structure from the name of your module, `Super::Greetings`. Sweet.

Everything seems to be in place. See if you can build a distribution with the blueprint:

`dzil build`

Oops, Zilla monster not happy:

```

[DZ] beginning to build Super-Greetings [DZ] no version was ever set [DZ] no version was ever set at inline delegation in Dist::Zilla for logger->log_fatal (attribute declared in /usr/local/share/perl/5.20.2/Dist/Zilla.pm at line 768) line 18.

```

## Fixing Your Blueprint

It looks like your blueprint has a fatal flaw, thanks to our bad advice. What went wrong, exactly?

Remember back when you added the `# ABSTRACT` comment to your module in the very first tutorial? We added that to give the installer software an esssential bit of information it needs in order to work. But instead of adding an `# ABSTRACT` comment into the module, your new blueprint kept the installer happy by supplying the `NAME` section in your documentation that `Dist::Zilla` used to generate the `ABSTRACT` our installer required. This way, your blueprint killed two birds with one stone by giving your module some documenation and keeping the installer happy.

Though your installer now has an abstract, it is now demanding that we feed it a version. What's the best way to do that? One way is to edit the module and add a version number there, similar to the way we added the `# ABSTRACT` comment. But since we're using `Dist::Zilla`, we'll add in `version = 0.001` directly to the `dist.ini` because it's easy.

However, this doesn't fix the real source of the problem, your flawed blueprint. So the next time we create a new module, we are going to run into the same issue. So let's also be sure to fix the blueprint, too. Open the `dist_ini.txt` file in the default profile and add the following line to the top of it:

`version = 0.001`

Once you've fixed up both files, try to build the distribution again. If you did everything right, Zilla monster will please you with a new distribution. Super duper!

OK, let's plow forward with our exploration of blueprints in the next section of the tutorial.