feat: add example Vale package for zero-setup demos

Author: armstrongl

README.md

@@ -24,6 +24,15 @@ Generate a style guide site from a Vale package:
 rulebound build ./my-vale-package --output ./public/
 ```
 
+Try it with the included example package:
+
+```sh
+git clone https://github.com/armstrongl/rulebound.git
+cd rulebound
+go run . build examples/starter-package --output /tmp/my-style-guide
+open /tmp/my-style-guide/index.html
+```
+
 ## Requirements
 
 rulebound requires Hugo to build sites. Pagefind is optional and adds client-side search.

examples/starter-package/Contractions.yml

@@ -0,0 +1,20 @@
+extends: substitution
+message: "Use '%s' instead of '%s'."
+level: suggestion
+ignorecase: true
+swap:
+  are not: aren't
+  cannot: can't
+  could not: couldn't
+  did not: didn't
+  do not: don't
+  does not: doesn't
+  has not: hasn't
+  have not: haven't
+  is not: isn't
+  it is: it's
+  should not: shouldn't
+  that is: that's
+  was not: wasn't
+  will not: won't
+  would not: wouldn't

examples/starter-package/Headings.yml

@@ -0,0 +1,7 @@
+extends: capitalization
+message: "'%s' should use sentence case."
+level: error
+scope: heading
+match: $sentence
+indicators:
+  - ":"

examples/starter-package/Jargon.md

@@ -0,0 +1,5 @@
+Use plain language that every reader can understand. Replace jargon and unnecessarily complex phrasing with simpler alternatives.
+
+## Guiding principle
+
+If a shorter, plainer word means the same thing, use it. Documentation is not the place to demonstrate vocabulary. Write at a level that a new team member can follow without a glossary.

examples/starter-package/Jargon.yml

@@ -0,0 +1,15 @@
+extends: substitution
+message: "Prefer '%s' over '%s'."
+level: warning
+ignorecase: true
+swap:
+  leverage: use
+  utilize: use
+  functionality: feature
+  in order to: to
+  at this point in time: now
+  due to the fact that: because
+  prior to: before
+  subsequent to: after
+  in the event that: if
+  a large number of: many

examples/starter-package/PassiveVoice.md

@@ -0,0 +1,15 @@
+Active voice makes documentation clearer and more direct. When you write in active voice, the reader knows immediately who or what performs the action.
+
+## Why it matters
+
+Passive voice obscures the actor and adds unnecessary words. In technical documentation, readers need to know exactly what to do and what the system does.
+
+| Passive (avoid) | Active (prefer) |
+| --- | --- |
+| The file was created by the system. | The system creates the file. |
+| The setting is required by the application. | The application requires this setting. |
+| Errors were found during validation. | Validation found errors. |
+
+## Exceptions
+
+Passive voice is acceptable when the actor is unknown, unimportant, or when you intentionally want to emphasize the object rather than the actor. For example: "The package is installed automatically during setup."

examples/starter-package/PassiveVoice.yml

@@ -0,0 +1,18 @@
+extends: existence
+message: "'%s' looks like passive voice. Use active voice instead."
+level: warning
+tokens:
+  - was created
+  - was deleted
+  - was found
+  - was made
+  - was removed
+  - was set
+  - was updated
+  - were changed
+  - were found
+  - were removed
+  - is expected
+  - is required
+  - are expected
+  - are required

examples/starter-package/SentenceLength.yml

@@ -0,0 +1,6 @@
+extends: occurrence
+message: "This sentence has %s words. Try to keep sentences under 30 words."
+level: suggestion
+scope: sentence
+max: 30
+token: '[^\s]+'

examples/starter-package/Wordiness.yml

@@ -0,0 +1,17 @@
+extends: existence
+message: "'%s' is wordy. Consider a more concise alternative."
+level: suggestion
+ignorecase: true
+tokens:
+  - a number of
+  - as a matter of fact
+  - at the present time
+  - by means of
+  - for the purpose of
+  - has the ability to
+  - in the process of
+  - it is important to note that
+  - on a regular basis
+  - take into consideration
+  - with regard to
+  - with respect to

examples/starter-package/pages/_index.md

@@ -0,0 +1,8 @@
+---
+title: "TechDocs Style Guide"
+description: "Documentation standards for technical writing teams"
+---
+
+This style guide defines how we write technical documentation. It covers voice, tone, formatting, and the linting rules that enforce our standards automatically.
+
+Browse the sections below or use search to find a specific topic.