Coding and Content Style Guide

To maintain consistency and readability across the project, we ask all contributors to follow these style guidelines.

Content Style

Tone: The tone should be authoritative yet accessible. We are explaining complex government rules to a general audience. Avoid overly technical jargon where possible, or link to the Glossary if a specific term is necessary.
Source of Truth: All information related to veteran's preference must be traceable back to the OPM Vet Guide for HR Professionals. When adding or changing logic, please be prepared to cite the relevant section of the guide.
Markdown Formatting:
- Use standard Markdown for all content pages.
- Use #, ##, and ### for headings to create a clear document structure.
- Use bulleted lists (*) for scannable information.
- Use bold (**text**) for emphasis on key terms or actions.

Jekyll/Liquid: Follow the existing patterns in the _layouts and advisor directories. Keep logic simple and add comments in the code for any complex Liquid tags.
HTML: Use semantic HTML5 tags (<header>, <nav>, <main>, <footer>, etc.) to ensure accessibility and a clean structure.
SCSS/CSS: Follow existing style patterns in the _sass directory. Changes should prioritize accessibility (e.g., color contrast, focus states).

To keep our Git history clean and easy to read, please follow this commit message format:

<type>: <subject>

<type> should be one of the following:
- feat: A new feature (e.g., feat: Add new case study for VEOA)
- fix: A bug fix (e.g., fix: Correct broken link in advisor start page)
- docs: Changes to documentation or content (e.g., docs: Update FAQ with new question)
- style: Formatting changes, no code logic change (e.g., style: Fix indentation in default layout)
- refactor: A code change that neither fixes a bug nor adds a feature.
- chore: Build process changes, dependency updates, etc.
<subject> should be a short, imperative-tense summary of the change.