Static Site Generator Vibe Coding Prompt
Personal Knowledge
My old jazz professor used to say, "you don't like what you don't know."
He was talking about music. I use it in the broader world. Recognizing the initial distaste for something is often because it's unfamiliar. That's leads me to try things to see what they're like. That leads me to Vibe Coding.
Vibe Check
"Vibe Coding" is the process of feeding prompts to an AI/LLM service to have it generate code for an app. The idea is not appealing to me. I like figuring things out myself. But, I've never tried the approach.
I know the basics of how AI/LLMs work. I've used them a few times for what amounts to an alternative to a search engine. Never more than that. I'm wary of doing more, but it's time to give it a shot. Time to go from secondhand anecdotes to personal experience.
The test will be creating a new static site generator. I've made enough of them that I have a very clear idea of what I want. I don't have to explore. I don't need the AI/LLM to provide direction. It just has to output what I tell it.
The Prompt
Here's the initial prompt I'll be using to get things started. It's a bare bones static site generator. I originally started to write the spec for one with all the features I want. But, that's not how I build projects. I get the basics in place then work from there. I'll do the same here.
Prompt Text
Create a static site generate in Rust that uses
MiniJinja for the template engine with the
following requirements:
- The site generator is a command line tool called
"buildsite".
- The tool builds a site in whatever directory it's
run in. This is the project directory for the site.
- The project directory contains the two subdirectories:
"content" and "docs".
- All source files go in the "content" directory.
- The site is output to the "docs" directory.
- Any executable files in the "pre-build" directory are run
before each generation of the site.
- Any executable files in the "post-build" directory are run
after each generation of the site.
- change the working directory for the "pre-build" and "post-build"
executables so they are run from their own directory.
- The "image-workshop" directory is for storing source assets.
The tools does not need to do anything with it.
- The "images" directory holds images that will be used on the site.
- The "logs" directory collects logging output from the tool.
There is one log file per day with the output from the tool.
- Logging is done with the "tracing" and "tracing-subscriber"
crates.
- Log messages have the standard levels: TRACE, DEBUG,
INFO, WARN, ERROR.
- INFO log messages are sent when:
- The process initializes.
- Output from a "pre-build" or "post-build" executable
is generated.
- A new generation of the site starts.
- A generation of the site is complete.
- An image is converted
- ERROR log messages are sent whenever any
error occurs.
- If a MiniJinja error occurs the resulting message
is seralized in the log message.
- The tool uses the axum create to provide a preview
of the site by service the "docs" directory on
a localhost port.
- The localhost port is chosen automatcially by
finding an open port between 5444 and 5499.
- The port number is disaplyed in the log messages
when the process starts and when a browser reload
is triggered.
- The "tower_livereload" create is used to reload
the preview site in the browser after each generation
of the site.
- The "notify" create is used to detect file changes
in the "content" and "images" directories. When
a change occurs the site it rebuilt and the
browser reloaded.
## Build Process
Every time the site is generated the following build
process is followed:
- [] Load all ".json" files into a "data" MiniJinja
variable that's available during content generation.
- [] Load metadata for all markdown (i.e. ".md") files
into a "files" MiniJinja variable that's
available during content generation.
- [] Run files though MiniJinja to generate output.
- [] Output files.
## Config File
- The tool looks for a "config.json" at the root of
the project directory (i.e. a sibling of the "content",
"docs", etc... direcotires).
- The format of the config file is
TKTKTKWhat's Not There
The above list is the baseline for the site builder. It the first thing I'd build if I was doing this by hand. Other things that will go into a future version are:
- HTML Template Tags - These are stand-ins for the standard MiniJinja tokens. They get replaced with the action tokens before the templates are run.
- bitty integration - basically rolling up bit javascripts into a single file to pull everything via a single network request.
- neopolitan formatting - my markdown replacement format that provides easier access to more complex output.
- paginated pages
- collection pages (e.g. tags)
- HTML file frontmatter metadata.
- Image Handling - The ability to call images with only their filename regardless of their actual path.
- Running "pre-build" and "post-build" scripts
- Plugin capabilities
- Preview server with hot reloading