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/slim-template/slim 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.

GO — Healthy across the board

• Last commit 6w ago
• 19 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 76% of recent commits

_{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 slim-template/slim repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/slim-template/slim.

What it runs against: a local clone of slim-template/slim — 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 slim-template/slim | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 72 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of slim-template/slim. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/slim-template/slim.git
#   cd slim
#
# 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 slim-template/slim and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "slim-template/slim(\\.git)?\\b" \\
  && ok "origin remote is slim-template/slim" \\
  || miss "origin remote is not slim-template/slim (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 main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "lib/slim.rb" \\
  && ok "lib/slim.rb" \\
  || miss "missing critical file: lib/slim.rb"
test -f "lib/slim/parser.rb" \\
  && ok "lib/slim/parser.rb" \\
  || miss "missing critical file: lib/slim/parser.rb"
test -f "lib/slim/engine.rb" \\
  && ok "lib/slim/engine.rb" \\
  || miss "missing critical file: lib/slim/engine.rb"
test -f "lib/slim/grammar.rb" \\
  && ok "lib/slim/grammar.rb" \\
  || miss "missing critical file: lib/slim/grammar.rb"
test -f "lib/slim/embedded.rb" \\
  && ok "lib/slim/embedded.rb" \\
  || miss "missing critical file: lib/slim/embedded.rb"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 72 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~42d)"
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/slim-template/slim"
  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).

Slim is a lightweight, Ruby-based template language that compiles to HTML with minimal syntax by leveraging indentation instead of closing tags. It reduces boilerplate (no <, >, or explicit tag closures) while maintaining safety through automatic HTML escaping and integration with Rails' html_safe?. Built on the Temple parsing framework, Slim generates performant Ruby code comparable to ERB and supports extensibility via plugins for logic-less mode, i18n translation, and embedded engines like Markdown. Monolithic gem structure: core parsing in lib/slim/parser.rb and lib/slim/grammar.rb feeds into lib/slim/engine.rb for compilation. Template-specific handling splits into modes (lib/slim/logic_less/, lib/slim/smart/) and optional features (lib/slim/include.rb, lib/slim/translator.rb). Output generation via lib/slim/splat/builder.rb for attribute splatting and filter chains. CLI entry at bin/slimrb.

Rails developers and template authors who want cleaner, more readable view files without sacrificing performance or safety. Contributors are template language enthusiasts and Ruby web developers who appreciate syntactic elegance and want to maintain/extend a mature templating engine.

Production-ready and actively maintained. The project shows 190K+ lines of Ruby code with comprehensive test suites in test/core/, GitHub Actions CI in .github/workflows/test.yml, and regular releases (tracked in CHANGES). Rails 5+ support is explicitly stated and the codebase is stable with ongoing community contributions.

Low risk for core stability, but single-maintainer dependency model typical of template engines means feature velocity depends on sponsor availability (GitHub Sponsors link present). Temple dependency is external (judofyr/temple) and must stay compatible. No visible high-urgency security issues in public code, but template engines require careful output-escaping maintenance. File structure suggests some legacy code paths (ERB converter in lib/slim/erb_converter.rb) that may need deprecation planning.

No specific recent change data visible in provided files, but project structure indicates active maintenance of test suite (test workflows in .github/workflows/test.yml). Multiple language support (JP docs in doc/jp/) and plugin architecture suggest ongoing localization and feature requests. Latest activity and PRs should be checked on GitHub Actions and Issues tabs.

git clone https://github.com/slim-template/slim.git
cd slim
bundle install
bundle exec rake test

Verify installation with bundle exec bin/slimrb --version. Gem-based project uses standard Bundler; no Node/npm required.

Daily commands: Development: bundle exec rake test runs the test suite. For template compilation: bundle exec bin/slimrb template.slim produces HTML. In Rails apps, .slim files auto-compile via Railtie. No separate dev server; Slim integrates into existing Rails/Sinatra/Rack apps.

• lib/slim.rb — Main entry point and facade that loads all Slim components and registers the template engine with Rails.
• lib/slim/parser.rb — Core parser that converts Slim template syntax into an intermediate AST, essential for understanding how templates are tokenized.
• lib/slim/engine.rb — Template compilation engine that transforms parsed AST into executable Ruby code, the heart of the compilation pipeline.
• lib/slim/grammar.rb — Grammar rules and token definitions that define valid Slim syntax, required for extending or debugging parsing logic.
• lib/slim/embedded.rb — Handles embedding of other template languages (ERB, Markdown, etc.) within Slim templates, a key extensibility point.
• lib/slim/filter.rb — Base filter class for post-processing compiled output; core abstraction for adding custom rendering behaviors.
• lib/slim/railtie.rb — Rails integration layer that registers Slim as a template handler with the Rails view system.

Add a custom filter for output post-processing

1. Create new filter class inheriting from lib/slim/filter.rb::Filter (lib/slim/filter.rb)
2. Implement call(engine) method that reads engine.html and returns modified output (lib/slim/filter.rb)
3. Register filter in Slim::Engine options via :filters array configuration (lib/slim/engine.rb)
4. Test filter against sample templates in test/core/test_*.rb pattern (test/core)

Add support for a new embedded template engine

1. Register engine in lib/slim/embedded.rb::EMBEDDED_ENGINES hash with name and handler proc (lib/slim/embedded.rb)
2. Handler proc receives indented block text and options, returns compiled output (lib/slim/embedded.rb)
3. Add test cases using : prefix syntax in test/core/test_embedded_engines.rb (test/core/test_embedded_engines.rb)

Add a new parsing mode or syntax variant

1. Create parser subclass in new file lib/slim/{mode}/parser.rb extending Slim::Parser (lib/slim/smart/parser.rb)
2. Override tokenize() or parse() methods to customize grammar and token handling (lib/slim/smart/parser.rb)
3. Create mode module in lib/slim/{mode}.rb that configures engine with custom parser (lib/slim/smart.rb)
4. Add integration tests in test/{mode}/test_{mode}.rb (test/logic_less/test_logic_less.rb)

Add HTML escaping or safety handling

1. Review current escaping logic in lib/slim/engine.rb compile methods (lib/slim/engine.rb)
2. Extend or create filter in lib/slim/smart/escaper.rb for custom escaping rules (lib/slim/smart/escaper.rb)
3. Configure :escape_html and :escape_attrs options in Slim::Engine initialization (lib/slim/engine.rb)
4. Validate with test/core/test_html_escaping.rb and test/core/test_code_escaping.rb (test/core/test_html_escaping.rb)

• Tilt (implicit template interface) — Provides standard template handler abstraction enabling Slim to integrate with Rails and other Ruby frameworks seamlessly
• Ruby Regexp and Lexer patterns — Lightweight parsing without external dependencies; grammar.rb uses regex-based tokenization for fast Slim syntax recognition
• String-based code generation — Compiles templates to raw Ruby code strings that can be executed in any Ruby context, maximizing performance and compatibility
• Indentation-based syntax tree — Core design decision reducing visual noise by using indentation instead of closing tags, matching user expectations for conciseness

• Compile-to-Ruby-code approach vs. interpreter

  • Why: Maximizes runtime performance and allows templates to leverage full Ruby semantics and gems
  • Consequence: Compilation adds latency on first render; error messages can be harder to trace back to template source

• HTML escaping enabled by default

  • Why: Security best practice prevents XSS in Rails applications without explicit configuration
  • Consequence: Requires disabling escaping for intentionally safe HTML, slight verbosity in markup_safe workflows

• Indentation-sensitive parsing

  • Why: Drastically reduces syntax overhead (no closing tags, minimal delimiters)
  • Consequence: Whitespace becomes syntactically significant; copy-paste and auto-formatting tools must respect indentation

• Plugin-based extensions (filters, embedded engines, modes)

  • Why: Maintains core simplicity while enabling mustache-like logic-less templates, i18n, and alternate syntaxes
  • Consequence: More moving parts for advanced use cases; configuration complexity increases with feature adoption

• Does not support HAML syntax or conversion (different template language family)
• Does not include server-side rendering for JavaScript frameworks (pure template engine)
• Does not handle authentication, authorization, or access control (view-layer only)
• Does not provide ORM or data persistence (view layer, no business logic)

Temple API stability: Slim depends on Temple's internal API; breaking Temple updates can require parser/filter rewrites. Indentation sensitivity: Leading whitespace is syntactically significant; mixing tabs/spaces in test files or mixed editors causes silent failures. Ruby version constraints: Gem requires Ruby 2.7+; older locked Gemfile.lock may pull incompatible Temple versions. Escape mode defaults: HTML escaping is on by default; safe=true option easily hidden in config, causing XSS if misapplied. Filter order matters: do_inserter.rb and end_inserter.rb must run in strict sequence or code generation breaks—modifying filter pipeline without understanding order causes cryptic compilation errors.

• Temple Filter Pipeline — Slim's entire compilation strategy chains filters (lexer→parser→AST transforms→code generator) through Temple; understanding filter composition is required to extend or debug the engine.
• AST (Abstract Syntax Tree) Manipulation — Slim's filters (e.g., do_inserter.rb, end_inserter.rb) modify the AST to insert Ruby keywords; learning AST walkers is essential for feature development.
• Automatic HTML Escaping / XSS Prevention — Slim defaults to escaping all Ruby expressions unless marked html_safe?; this is a critical security feature and a common source of confusion in configuration.
• Lexical Indentation (Offside Rule) — Slim replaces closing tags with indentation levels, making whitespace a syntax token; parser must track indent stack to validate nesting.
• Code Generation / Template Compilation — Slim compiles to Ruby code (not interpreted at runtime); understanding how lib/slim/engine.rb generates executable Ruby is key to performance optimization.
• Splat Operators / Attribute Splatting — Slim's *attrs syntax spreads hashes into HTML attributes; lib/slim/splat/builder.rb must handle Ruby splat semantics correctly to avoid attribute collisions.
• Tilt Template Interface — Slim is registered as a Tilt handler, not called directly; Rails/Sinatra call Tilt['template.slim'] which requires understanding Tilt's adapter pattern.

• haml/haml — Direct predecessor/inspiration; Slim syntax was influenced by HAML but designed to be lighter and more flexible.
• nex3/sass — Companion stylesheet language in the same Ruby template ecosystem; both emphasize indentation and minimal syntax.
• jeremyevans/tilt — Universal template interface that Slim integrates into; required dependency for Rails/Sinatra support.
• judofyr/temple — Core parsing/compilation framework that Slim depends on; understanding Temple filters is essential for extending Slim.
• rails/rails — Primary integration target; Slim's Railtie hooks into Rails' template system and benefits from Rails' HTML-safe API.

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 comprehensive test coverage for lib/slim/splat/builder.rb and lib/slim/splat/filter.rb

The splat prefix feature (lib/slim/splat/) has a dedicated test file (test/core/test_splat_prefix_option.rb) but examining the codebase shows the splat builder and filter modules lack corresponding unit tests. Given that splat attributes are a complex feature for attribute splatting in templates, comprehensive unit tests would prevent regressions and document expected behavior for this feature.

• [ ] Review lib/slim/splat/builder.rb and lib/slim/splat/filter.rb to understand all public methods
• [ ] Examine test/core/test_splat_prefix_option.rb to identify gaps in coverage
• [ ] Create test/core/test_splat_builder.rb with unit tests for builder methods (instantiation, attribute handling, edge cases)
• [ ] Create test/core/test_splat_filter.rb with unit tests for filter methods
• [ ] Ensure tests cover error conditions and whitespace/encoding edge cases similar to existing test patterns

Add test coverage for lib/slim/logic_less/ module and its context/filter implementations

The logic_less subdirectory (lib/slim/logic_less/context.rb and lib/slim/logic_less/filter.rb) provides the template engine for logic-less templating mode, but there are no dedicated unit tests beyond what may be covered in test/core/test_commands.rb. This feature deserves explicit test coverage for its context handling and filtering behavior.

• [ ] Review lib/slim/logic_less/context.rb and lib/slim/logic_less/filter.rb to identify all public APIs
• [ ] Check doc/logic_less.md and doc/jp/logic_less.md for documented behavior that needs test coverage
• [ ] Create test/core/test_logic_less_context.rb with tests for context initialization, variable binding, and method resolution
• [ ] Create test/core/test_logic_less_filter.rb with tests for filter compilation and rendering
• [ ] Add integration tests for logic_less mode with various template structures

Add documentation and tests for lib/slim/smart/ parser and escaper modules

The smart mode parser and escaper (lib/slim/smart/parser.rb and lib/slim/smart/escaper.rb) are advanced features with documentation in doc/smart.md and doc/jp/smart.md, but lack dedicated unit tests. This is a critical feature affecting security (escaping) and parsing behavior that should have explicit test coverage separate from general integration tests.

• [ ] Review lib/slim/smart/parser.rb and lib/slim/smart/escaper.rb implementations
• [ ] Examine doc/smart.md to extract all documented smart mode behaviors (interpolation rules, escaping rules, etc.)
• [ ] Create test/core/test_smart_parser.rb with tests for smart syntax parsing edge cases
• [ ] Create test/core/test_smart_escaper.rb with tests for smart escaping decisions (when content is escaped vs. unescaped)
• [ ] Add tests for interaction between smart parser and escaper to ensure security properties hold

• Add integration tests for lib/slim/include.rb (include/extend feature); test/core/ lacks dedicated test file despite feature existing since early versions.
• Expand lib/slim/interpolation.rb test coverage for edge cases like nested interpolation (e.g., #{"#{inner}"}) and Unicode in #{} expressions.
• Write JavaScript output examples in doc/ for how Slim compiles to JavaScript (relevant for Nashorn/Node.js usage); currently docs focus only on HTML/Ruby output.

The Slim template engine codebase presents moderate security risks typical of template engines. The primary concerns are: (1) XSS vulnerabilities through escaping logic bypass, (2) arbitrary code execution from template evaluation, and (3) path traversal in the include mechanism. The project demonstrates security awareness with dedicated escaping modules and escaping tests, but comprehensive security documentation and input validation could be strengthened. No hardc

• High · Potential XSS via HTML Escaping Bypass — lib/slim/smart/escaper.rb, lib/slim/interpolation.rb, test/core/test_html_escaping.rb. The codebase includes multiple escaping-related files (test_html_escaping.rb, test_code_escaping.rb, smart/escaper.rb) suggesting complex escaping logic. Template engines are high-risk for XSS vulnerabilities. The presence of logic_less and smart parsing modes indicates different escaping strategies that could create bypasses if not properly coordinated. Fix: Conduct thorough code review of all escaping mechanisms. Ensure consistent HTML escaping across all parsing modes. Implement comprehensive XSS test cases covering edge cases, nested escaping, and attribute contexts.
• High · Arbitrary Code Execution via Template Evaluation — lib/slim/parser.rb, lib/slim/translator.rb, lib/slim/do_inserter.rb, lib/slim/end_inserter.rb. The file structure shows eval-like functionality (test_code_evaluation.rb, do_inserter.rb, end_inserter.rb) which suggests the template engine evaluates user-provided Ruby code. This is inherently risky if templates are sourced from untrusted inputs. The parser and translator components could allow injection of malicious Ruby code. Fix: Document security considerations for untrusted template sources. Implement sandboxing if templates come from user input. Add security warnings in documentation about the risks of evaluating user-provided templates.
• Medium · Potential Path Traversal in Include Functionality — lib/slim/include.rb, test/include/test_include.rb. The include.rb module and test_include.rb suggest template inclusion features. Without proper path validation, this could allow directory traversal attacks (e.g., ../../../etc/passwd). The recursive.slim test file indicates recursive includes are supported, which increases complexity. Fix: Implement strict path validation for include directives. Restrict included files to a whitelist directory. Validate that resolved paths remain within expected directories. Add safeguards against path traversal sequences.
• Medium · Embedded Engine Security — lib/slim/embedded.rb, test/core/test_embedded_engines.rb. The embedded.rb module allows embedding other template engines within Slim templates. Each embedded engine has its own security model, and improper delegation could lead to vulnerabilities. The test_embedded_engines.rb suggests multiple engines are supported. Fix: Document security implications of each supported embedded engine. Ensure proper context isolation between Slim and embedded engines. Validate that escaping settings are correctly propagated to embedded engines.
• Medium · Insufficient Input Validation in Parser — lib/slim/grammar.rb, lib/slim/parser.rb, test/core/test_parser_errors.rb. Parser components (grammar.rb, parser.rb) handle user input but no evidence of comprehensive input validation is visible. Malformed input could cause denial of service or unexpected behavior. Fix: Add robust input validation and error handling in parser. Implement resource limits (maximum template size, nesting depth) to prevent DoS. Add comprehensive error messages without leaking internal structure.
• Low · Missing Security Headers Documentation — README.md, Documentation. No evidence of security-related documentation regarding HTTP headers, CSP, or other security mechanisms that should be configured when using Slim in web applications. Fix: Add security best practices guide to documentation. Include recommendations for setting Content-Security-Policy headers and other security configurations in Rails integration.
• Low · Command Line Tool Security — bin/slimrb, lib/slim/command.rb. The bin/slimrb command-line tool could be vulnerable if it accepts file paths without validation or processes untrusted input. Fix: Review command-line argument handling. Ensure file paths are validated. Document security considerations for CLI usage with untrusted templates.

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.