If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/plusjade/jekyll-bootstrap shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 1y ago

• 27+ active contributors
• Distributed ownership (top contributor 28% of recent commits)
• MIT licensed
• ⚠ Stale — last commit 1y ago
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live plusjade/jekyll-bootstrap repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/plusjade/jekyll-bootstrap.

What it runs against: a local clone of plusjade/jekyll-bootstrap — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in plusjade/jekyll-bootstrap | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 555 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of plusjade/jekyll-bootstrap. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/plusjade/jekyll-bootstrap.git
#   cd jekyll-bootstrap
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of plusjade/jekyll-bootstrap and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "plusjade/jekyll-bootstrap(\\.git)?\\b" \\
  && ok "origin remote is plusjade/jekyll-bootstrap" \\
  || miss "origin remote is not plusjade/jekyll-bootstrap (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "_config.yml" \\
  && ok "_config.yml" \\
  || miss "missing critical file: _config.yml"
test -f "_layouts/default.html" \\
  && ok "_layouts/default.html" \\
  || miss "missing critical file: _layouts/default.html"
test -f "_includes/JB/setup" \\
  && ok "_includes/JB/setup" \\
  || miss "missing critical file: _includes/JB/setup"
test -f "index.md" \\
  && ok "index.md" \\
  || miss "missing critical file: index.md"
test -f "_includes/themes/bootstrap-3/default.html" \\
  && ok "_includes/themes/bootstrap-3/default.html" \\
  || miss "missing critical file: _includes/themes/bootstrap-3/default.html"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 555 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~525d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/plusjade/jekyll-bootstrap"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Jekyll-Bootstrap is a quickstart scaffolding framework for Jekyll static site generators that bundles reusable Liquid templates, modular comment/analytics provider integration, and Bootstrap/Twitter theme layouts. It lets developers spin up a GitHub Pages-ready blog with pluggable analytics (Google, Mixpanel, Piwik), comments (Disqus, Facebook, Intensedebate), and social sharing—without writing boilerplate Liquid or YAML config. Monolithic Jekyll scaffold: _config.yml drives global config; _includes/JB/ contains 30+ reusable Liquid modules (analytics, comments, helpers like file_exists, posts_collate, sort_collection); _includes/themes/ holds two complete theme implementations (bootstrap-3, twitter) each with default.html, page.html, post.html layouts; _layouts/ provides Jekyll layout hierarchy; _plugins/ holds Ruby custom Liquid filters.

Developers and technical bloggers who want to launch a Jekyll blog on GitHub Pages quickly without wrestling with Liquid templating, analytics/comment integrations, or theme scaffolding. The target user knows Git and wants a documented, modular baseline rather than a blank Jekyll install.

Archived and unmaintained. The repo is stable at v0.3.0 (semantic versioning) but the maintainer explicitly states the project is no longer maintained and the jekyllbootstrap.com domain was abandoned. It demonstrates viable Jekyll patterns and Liquid techniques but receives no active development, security updates, or dependency management.

High risk for production use. No CI/CD pipeline visible, no test suite despite Ruby/Liquid code in _plugins/debug.rb, single-maintainer project with no successor indicated. The Gemfile lacks version pinning details visible here, and the archived status means dependency drift over time. Open issue #144 (BASE_PATH with FQDN) remains unfixed, indicating incomplete API coverage.

Project is dormant. README explicitly states maintenance stopped. Planned v0.4.0 milestone targeted ETA 03/29/2015 with goals to close PRs, fix bugs (#86 Facebook Comments, #113 ASSET_PATH resolved; #144 BASE_PATH unresolved), and add features (#98 Gist integration, #244 file_exists helper marked done). No commits, PRs, or issues are active.

git clone https://github.com/plusjade/jekyll-bootstrap.git
cd jekyll-bootstrap
bundle install
bundle exec jekyll serve

Then edit _config.yml to configure site title, analytics provider, comments provider, and theme selection (bootstrap-3 or twitter).

Daily commands:

bundle exec jekyll serve --watch

Jekyll watches _posts/, _drafts/, _includes/, _layouts/ for changes and regenerates at http://localhost:4000. Configuration via _config.yml (site title, theme, analytics/comment providers, BASE_PATH, JB settings).

• _config.yml — Central Jekyll configuration file that controls site metadata, theme selection, and plugin behavior—all other files depend on settings here
• _layouts/default.html — Root layout template that wraps all pages; defines the HTML structure and theme integration point for every page on the site
• _includes/JB/setup — Core Jekyll-Bootstrap setup include that initializes theme variables and feature flags used throughout all layout and content files
• index.md — Homepage entry point that introduces the Jekyll-Bootstrap framework and sets the first impression for users
• _includes/themes/bootstrap-3/default.html — Default theme layout for Bootstrap 3; responsible for rendering the primary visual structure used by most pages
• Rakefile — Rake task automation for common blog operations (creating posts, managing drafts); primary developer workflow interface
• _plugins/debug.rb — Custom Jekyll plugin providing debugging and utility liquid filters used throughout template files

Add a new blog post

1. Run Rake task to generate new post file with frontmatter template (Rakefile)
2. Create post markdown file in _posts/ directory following YYYY-MM-DD-slug.md naming convention (_posts/core-samples/2011-12-29-jekyll-introduction.md)
3. Add YAML frontmatter with title, author, date, tags, and categories (_posts/core-samples/2011-12-29-jekyll-introduction.md)
4. Post automatically renders using _layouts/post.html which includes comments and sharing via JB includes (_layouts/post.html)

Switch or customize the theme

1. Edit _config.yml and set the JB.theme variable to 'bootstrap-3' or 'twitter' (or create new theme directory) (_config.yml)
2. Create new theme directory under _includes/themes/THEME_NAME/ with default.html, page.html, post.html, and settings.yml (_includes/themes/bootstrap-3/default.html)
3. Add corresponding CSS and JavaScript assets under assets/themes/THEME_NAME/ (assets/themes/bootstrap/css/style.css)
4. All layouts reference the active theme via _includes/JB/setup which provides theme-specific variables (_includes/JB/setup)

Enable a third-party feature (analytics, comments, or sharing)

1. Edit _config.yml and configure provider settings under comments, analytics, or sharing sections (_config.yml)
2. Place provider-specific template in _includes/JB/comments-providers/PROVIDER/ or analytics-providers/PROVIDER/ (_includes/JB/comments-providers/disqus)
3. Include the feature router in your layout template (e.g., {% include JB/comments %}) which dynamically loads the configured provider (_layouts/post.html)
4. Provider template is now rendered on all posts/pages that include the feature (_includes/JB/analytics)

Add a new collection page (category, tag, or archive listing)

1. Create HTML file at root level (e.g., categories.html, tags.html, archive.html) with layout frontmatter (categories.html)
2. Use JB collection includes (categories_list, tags_list, posts_collate) in the page content to render grouped items (archive.html)
3. These includes read post frontmatter and dynamically group content—no manual updates needed (_includes/JB/posts_collate)
4. Page renders through _layouts/page.html using the active theme's page template (_layouts/page.html)

• Jekyll (static site generator) — Converts Markdown + Liquid templates to static HTML; natively supported by GitHub Pages with zero deployment infrastructure
• Liquid templating — GitHub Pages' built-in template language; enables dynamic content generation at build time without server-side rendering
• Bootstrap CSS framework — Provides responsive design and UI components out-of-the-box; reduces custom CSS burden for blog styling
• Ruby (Rakefile, plugins) — Jekyll's native extension language; enables command-line automation for post/draft management and custom Liquid filters

• Static site generation instead of server-side CMS

  • Why: Enables free GitHub Pages hosting, excellent performance, no database, and version control for all content
  • Consequence: No real-time dynamic features; rebuild required for any content change; no user submissions or admin dashboard

• Theme system via file structure instead of unified theme engine

  • Why: Simplicity and compatibility with GitHub Pages' restrictive environment; easy to understand and customize
  • Consequence: No package manager for themes; manual directory structure required; theme switching requires file reorganization

• Provider-based third-party integrations (Disqus, Google Analytics, etc.)

  • Why: Offloads compute to external services; keeps static build lightweight; allows user choice of providers
  • Consequence: External service dependencies; potential privacy/tracking concerns; broken third-party services affect site functionality

• Markdown-first content with YAML frontmatter

  • Why: Human-readable, version-control friendly, minimal syntax overhead; ideal for technical audiences
  • Consequence: Learning curve for metadata structure; limited to Markdown

• No explicit test suite: despite Ruby in _plugins/debug.rb and Liquid templating, no spec/, test/, or CI config visible; high risk of regression when modifying helpers or filters.
• JB/setup must be included first: layouts must invoke {% include JB/setup %} before using {{ JB.asset_path }} or {{ JB.base_path }}; omitting this breaks relative URL resolution.
• Theme settings are per-theme: _includes/themes/bootstrap-3/settings.yml and _includes/themes/twitter/settings.yml are separate; switching themes requires checking if config keys match.
• ASSET_PATH complexity: issue #113 indicates ASSET_PATH behaves differently in pages vs posts; verify relative paths when moving content types.
• No version-pinned Gemfile details visible here: Gemfile exists but specific Jekyll/dependency versions not shown; old pins likely cause conflicts with modern Ruby environments.
• GitHub Pages compatibility assumed but not tested: marked "100% compatible" but no CI validating against GitHub Pages build environment.
• BASE_PATH with FQDN broken: issue #144 unfixed; using a full domain (not relative path) in _config.yml may cause asset/link failures.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add Ruby unit tests for _plugins/debug.rb

The repo contains a debug plugin (_plugins/debug.rb) but there are no test files in the repository. Jekyll plugins benefit from having tested Liquid filters and tags. Adding RSpec or Minitest tests would help ensure the debug plugin works correctly and prevent regressions when Jekyll versions update. This is especially valuable for an archived educational repo that serves as a reference for Jekyll patterns.

• [ ] Create a test directory structure (e.g., spec/ or test/)
• [ ] Add test dependency to Gemfile (RSpec or Minitest)
• [ ] Write tests for _plugins/debug.rb covering all Liquid filters/tags it exposes
• [ ] Add test execution task to Rakefile
• [ ] Document how to run tests in README.md

Create comprehensive theme documentation for _includes/themes/bootstrap-3 and _includes/themes/twitter

The repo ships with two themes (bootstrap-3 and twitter) but provides no documentation on theme structure, how to customize them, or how to create new themes. The _includes/themes directory contains layout partials (default.html, page.html, post.html, settings.yml) that new contributors would struggle to understand. Adding a THEMES.md file with specific examples would make this repo more valuable as an educational resource.

• [ ] Create THEMES.md documenting the theme directory structure and purpose of each file
• [ ] Document what settings.yml contains and how theme authors should define theme-specific variables
• [ ] Provide example: explain differences between _includes/themes/bootstrap-3/post.html and _includes/themes/twitter/post.html
• [ ] Add instructions on how to create a custom theme by duplicating and modifying an existing theme
• [ ] Reference this documentation from README.md

Add GitHub Actions workflow to validate Jekyll builds and liquid syntax

The repo is archived but still used as an educational reference. Currently there's no CI validation that the Jekyll site actually builds or that Liquid templates are syntactically correct. Adding a simple GitHub Actions workflow that runs jekyll build on push/PR would catch broken includes, invalid Liquid syntax, or missing dependencies—making it safer for people learning from this codebase.

• [ ] Create .github/workflows/jekyll.yml workflow file
• [ ] Configure workflow to run on push and pull requests
• [ ] Add step to install Ruby dependencies from Gemfile
• [ ] Add step to run jekyll build to validate site builds without errors
• [ ] Add step to validate no broken Liquid includes using Jekyll's built-in error reporting
• [ ] Document in README.md that the build is validated

Check the issue tracker.

This is an archived, unmaintained Jekyll theme from ~2015 with significant security concerns. The primary risks are: (1) completely outdated dependencies with accumulated CVEs, (2) Liquid template XSS vulnerabilities in user-facing components, (3) unverified third-party integrations for analytics/comments, and (4) missing modern security configurations. This codebase should NOT be used in production. If forked, comprehensive security auditing, dependency updates, and hardening are required. The repository is suitable only as a reference for Jekyll patterns and liquid techniques, not as a basis for a production blog.

• High · Archived and Unmaintained Repository — README.md, Repository Status. The repository is explicitly marked as archived and no longer maintained. This means security vulnerabilities will not be patched, and dependencies will become increasingly outdated. The maintainer also noted that the associated domain (jekyllbootstrap.com) has been abused. Fix: Do not use this codebase in production environments. Consider forking and maintaining your own version, or switching to actively maintained Jekyll themes and frameworks.
• High · Outdated Dependencies with Known Vulnerabilities — Gemfile (content not provided). No Gemfile content was provided, but given the repository was last actively maintained around 2015, all Ruby gem dependencies are likely several years outdated and contain known security vulnerabilities. This includes Jekyll itself and any third-party gems used. Fix: Run 'bundle audit' to identify vulnerable dependencies. Update all gems to their latest versions. Regularly monitor for security updates if this is forked for use.
• Medium · Potential XSS Vulnerability in Template Processing — _includes/JB/ directory, _layouts/ directory. The codebase uses Liquid templating extensively with custom includes (_includes/JB/). Liquid templates can be vulnerable to XSS if user-controlled content is rendered without proper escaping. The presence of analytics, comments, and sharing includes suggest external content integration points. Fix: Audit all Liquid templates to ensure user-generated content is properly escaped. Use Liquid's {{ variable | escape }} filter for any dynamic content. Never use unescaped content from untrusted sources.
• Medium · Third-Party Script Integration Without Verification — _includes/JB/comments-providers/, _includes/JB/analytics-providers/. The codebase integrates multiple third-party services (Disqus, Duoshuo, Google Analytics, Facebook, etc.) through includes. These external dependencies may have security issues or track users without proper consent, and their integrity is not verified. Fix: Verify and audit all third-party services integrated into the theme. Implement Subresource Integrity (SRI) checks for external scripts. Consider user privacy and consent (GDPR compliance) when enabling analytics and comment providers.
• Low · Missing Security Headers Configuration — _config.yml, Jekyll configuration. No evidence of security headers configuration (Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, etc.) in the provided file structure. GitHub Pages may provide some defaults, but explicit configuration is missing. Fix: Add security headers configuration to _config.yml if supported by your hosting, or implement them through a CDN/reverse proxy. At minimum, set CSP, X-Frame-Options: DENY, and X-Content-Type-Options: nosniff.
• Low · Missing HTTPS Enforcement — _config.yml, Jekyll configuration. No evidence of HTTPS enforcement or redirect configuration in the codebase. GitHub Pages supports HTTPS, but explicit enforcement is not visible. Fix: Enable HTTPS enforcement in GitHub Pages settings. Add url configuration in _config.yml pointing to https://yourdomain.com. Implement HSTS headers if possible.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.