Repository Guidelines

Project Structure & Module Organization

Jekyll source lives in _pages (published pages), _layouts (HTML skeletons), _includes (shared fragments), and _drafts (unpublished work). Legacy content is under _legacypages.
Assets such as CSS, JS, images, and fonts live in assets/. Avoid editing _site/ because it is the generated output.
Automation and utilities are under _scripts/ (mir helpers, prompts) with tests mirrored in spec/mir/ and friends. Rake tasks are defined in Rakefile.
Site-wide configuration is in _config.yml; keep page front matter minimal and consistent.

Install deps once: bundle install.
Build static site: bundle exec jekyll build (or rake build) outputs to _site/.
Run locally with livereload: bundle exec jekyll serve --livereload.
Run all tests: bundle exec rspec (or rake test); runs RSpec + Capybara/HTMLProofer checks.
Optional sanity: bundle exec rubocop for Ruby/Rake/Liquid linting and rake build_and_test to chain build + tests.

Ruby, Rake, and specs use 2-space indentation and RuboCop defaults (including rubocop-rspec). Prefer descriptive method names and snake_case files.
Jekyll pages: use kebab-case filenames in _pages/ and include YAML front matter for layout, title, and canonical URLs. Keep inline scripts/styles in assets when possible.
Prefer includes for repeated snippets and keep layout changes in _layouts/ to avoid copy/paste drift.

Add or update specs in spec/pages/, spec/layouts/, etc. Mirror the page or helper name for clarity (e.g., spec/pages/404_spec.rb).
Feature tests should build the site first; when writing Capybara specs, point to _site/ output (as configured in spec_helper).
For HTML/SEO regressions, add HTMLProofer expectations; for helpers, add unit-level expectations.
Run bundle exec rspec before submitting; rerun bundle exec jekyll build if you touched layouts or includes to ensure Liquid compiles.

Follow the existing history: short, imperative commits with optional Conventional Commit prefixes (feat:, fix:, test:). Commit related changes together (content, tests, and assets).
PRs should include: a concise summary of the change, linked issue/ticket if applicable, screenshots for visual changes, and notes on test coverage or manual verification.
Keep diffs focused; avoid committing _site/ artifacts or local caches. Mention any config changes (_config.yml, Gemfile) explicitly in the PR description.

Do not place secrets or API keys in front matter, includes, or _config.yml; prefer environment variables and documented placeholders.
When updating gems, run bundle update selectively and verify Gemfile.lock diffs; note any security-related upgrades in the PR.