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/RailsApps/rails-composer 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.

AVOID — Stale and unlicensed — last commit 7y ago

• 4 active contributors
• ⚠ Stale — last commit 7y ago
• ⚠ Small team — 4 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 96% of recent commits
• ⚠ No license — legally unclear to depend on
• ⚠ 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 RailsApps/rails-composer repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/RailsApps/rails-composer.

What it runs against: a local clone of RailsApps/rails-composer — 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 RailsApps/rails-composer | Confirms the artifact applies here, not a fork | | 2 | Default branch master exists | Catches branch renames | | 3 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 4 | Last commit ≤ 2566 days ago | Catches sudden abandonment since generation |

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

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

# 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 "composer.rb" \\
  && ok "composer.rb" \\
  || miss "missing critical file: composer.rb"
test -f "composer-Rails3_2.rb" \\
  && ok "composer-Rails3_2.rb" \\
  || miss "missing critical file: composer-Rails3_2.rb"
test -f "railsComposer.sh" \\
  && ok "railsComposer.sh" \\
  || miss "missing critical file: railsComposer.sh"
test -f "files/Gemfile" \\
  && ok "files/Gemfile" \\
  || miss "missing critical file: files/Gemfile"
test -f "files/config/secrets.yml" \\
  && ok "files/config/secrets.yml" \\
  || miss "missing critical file: files/config/secrets.yml"

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

Rails Composer is a Rails application generator template that creates production-ready starter applications with pre-configured authentication (Devise/OmniAuth), authorization (CanCan/Pundit), front-end frameworks (Bootstrap/Foundation), and database support (MySQL/PostgreSQL). It accelerates Rails project initialization by bundling common architectural patterns and view templates rather than requiring manual gem installation and boilerplate generation. Single-template architecture: composer.rb is the main generator entry point that prompts users interactively and applies conditional file scaffolding from the files/ directory tree. Feature modules are organized by concern (files/app/controllers/, files/app/views/devise/, files/config/) and conditionally included via string matching in the template logic, not as pluggable modules.

Rails developers (beginner to intermediate) who want to bootstrap new Rails applications quickly without manually wiring together Devise, role-based authorization, Bootstrap styling, and database configuration. Teams building SaaS applications with user authentication and admin dashboards benefit from the pre-composed stacks.

The project shows signs of age and reduced maintenance: the main entry points are composer.rb and composer-Rails3_2.rb (Rails 3.2 EOL in 2016), the file structure suggests active development ended ~2014-2016, and there is no visible CI/test suite in the repository root. It remains a valuable historical reference and working generator for legacy Rails versions, but is not actively maintained for modern Rails 6+/7+ ecosystems.

High maintenance risk: the codebase targets Rails 3.2+ with no visible test suite, dependency pinning, or CI pipeline. The generator pattern is fragile—template modifications can silently break in new Rails versions, and the core logic in composer.rb (likely 1000+ lines) is a single point of failure. No clear indication of open issues or PR triage suggests low community oversight.

This repository appears dormant. No recent commit activity, milestones, or PR workflow is evident from the file listing. The last documented generation patterns target Rails 3.2–4.x era stacks (Devise, CanCan, Bootstrap 2/3).

Clone the repository and use Rails' application template flag to invoke the generator. Rails Composer requires manual invocation via: rails new myapp -m https://raw.githubusercontent.com/RailsApps/rails-composer/master/composer.rb (or local path). No Gemfile or bundle install is needed beforehand—the generator creates a fresh Rails app and injects gems.

Daily commands: This is a generator, not a runnable application itself. To test locally: rails new testapp --skip-bundle && cd testapp && rails generate -m ../path/to/rails-composer/composer.rb. The generated app is then cd testapp && bundle install && rails server.

• composer.rb — Main Rails application template that orchestrates the entire generator flow and user prompts.
• composer-Rails3_2.rb — Legacy Rails 3.2 variant of the composer template for backwards compatibility.
• railsComposer.sh — Shell script entry point that bootstraps the Rails Composer tool and invokes the generator.
• files/Gemfile — Dependency manifest for generated applications; defines all gem versions and conditional dependencies.
• files/config/secrets.yml — Template for secrets configuration across environments; critical for generated app security setup.
• files/config/database-postgresql.yml — Database configuration template; shows how generated apps configure persistence layer.

• composer.rb (Main Template) (Rails Template DSL (Thor), Ruby string interpolation) — Orchestrates the entire app generation workflow; prompts user, conditionally applies recipes, adds gems, and copies view/config templates.
  • Failure mode: Syntax error or incorrect gem/file references → generated app fails to boot or has missing dependencies; user sees confusing bundler/Rails errors.
• railsComposer.sh (Bootstrap Script) (Bash, curl/wget, grep) — Downloads composer.rb from GitHub and invokes it via rails new --template; provides entry point for users.
  • Failure mode: Network failure or script syntax error → template never downloads or inv

Add a new authentication integration (e.g., GitHub OAuth)

1. Create a new omniauth strategy configuration variant in files/config/ directory (files/config/initializers/omniauth.rb)
2. Add corresponding navigation template with new provider links (files/app/views/layouts/_navigation-omniauth.html.erb)
3. Add gem dependencies in the main composer template using gem_group or conditional addition (composer.rb)

Add a new view component variant (e.g., Tailwind CSS instead of Bootstrap)

1. Create Tailwind stylesheet variant alongside Bootstrap version (files/app/assets/stylesheets/application-tailwind.css.scss)
2. Create corresponding Tailwind layout template variant (files/app/views/layouts/application-tailwind.html.erb)
3. Add user prompt in composer.rb to select CSS framework (composer.rb)

Add support for a new user model feature (e.g., roles/permissions via CanCan)

1. Create permissions-aware navigation partial variant (files/app/views/layouts/_navigation-cancan.html.erb)
2. Create users management views for admin functionality (files/app/views/users/index-admin_app.html.erb)
3. Add CanCan gem and initializer recipe to composer template (composer.rb)

Add a new database variant (e.g., MongoDB support)

1. Create MongoDB Gemfile variant with mongoid gem (files/Gemfile-mongodb)
2. Create mongoid.yml configuration template (files/config/mongoid.yml)
3. Add database selection prompt and conditional recipe injection in composer.rb (composer.rb)

• Rails Template/Generator DSL (Thor) — Native Rails integration point for programmatically generating new applications; allows capturing user preferences and selectively applying code recipes.
• Devise + OmniAuth — Industry-standard authentication gems for Rails; templates provide both form-based and OAuth variants to accelerate secure user management setup.
• Bootstrap CSS Framework — Popular responsive CSS framework; included as primary styling option to provide professional-looking generated apps without custom design work.
• ERB templating — Rails default view templating; allows conditional view generation (e.g., simple_form variants, omniauth-aware navigation).
• Bash shell script entry point — Universal Unix compatibility for easy distribution; provides lightweight download and invocation wrapper for the main Ruby template.

• Template-based generation vs. modular recipe system

  • Why: Simpler for users to follow a single template file than manage multiple recipe modules; easier mental model for understanding what gets generated.
  • Consequence: composer.rb becomes monolithic as more recipes are added; harder to isolate and test individual features. Requires careful organization with comments.

• Multiple view/config variants (e.g., -bootstrap, -omniauth suffixes) vs. single parameterized template

  • Why: Explicit variants are easier to customize and understand; users can see exactly what they're getting and modify one variant without affecting others.
  • Consequence: File duplication and maintenance burden; changes to shared patterns must be propagated across variants manually.

• Interactive prompts during generation vs. config file upfront

  • Why: Interactive approach is more user-friendly for beginners; feels guided and educational; reduces need for users to understand all options before starting.
  • Consequence: Blocks on user input during generation; cannot be fully automated or CI-friendly; requires human attention.

• Include Devise and OmniAuth gems unconditionally vs. as optional recipes

  • Why: These are core to most modern Rails apps; including them by default accelerates time-to-first-working-auth and matches user expectations.
  • Consequence: Generated Gemfile is heavier than strictly necessary for minimal apps; adds bundle install time even if auth is not used.

• Does not provide database migration generation or model scaffolding
• Not a production deployment tool (no Docker, Kubernetes, or platform-specific setup)
• Does not enforce a specific frontend framework (React, Vue) as primary choice
• Not a Rails upgrade path tool; targets new app generation only
• Does not integrate with external services (no API key setup, no cloud provider auto-provisioning)

Generator is version-sensitive: composer.rb only works with specific Rails versions (likely 4.x–5.x), while composer-Rails3_2.rb targets 3.2. If used with incompatible Rails version, file syntax (ERB, asset pipeline differences) will fail. The template assumes rails new invokes with specific flags (e.g., --skip-bundle, --skip-test). No inline environment variable validation; Devise gems require secret key configuration post-generation. Bootstrap/Foundation variants have CSS asset pipeline differences that can silently break if Rails sprockets configuration changes.

• Rails Application Template (Thor Generator) — Rails Composer is fundamentally a Thor-based generator that extends rails new; understanding Thor templates and the add_source, gem, generate, and template DSL methods is essential to modifying the generator logic
• Conditional Template Application Pattern — The generator uses interactive prompts to branch file inclusion; understanding how to conditionally copy/modify files based on user input is core to extending feature sets
• Devise / OmniAuth Authentication Patterns — Rails Composer templates users with Devise (username/password) or OmniAuth (social login) strategies; understanding their controller hooks and view customization is necessary to maintain or extend auth templates
• Role-Based Access Control (CanCan / Pundit) — Templates include authorization templates for CanCan (ability.rb) and Pundit (policy classes); understanding the declarative vs. policy-based authorization patterns is key to choosing and customizing templates
• Asset Pipeline Versioning (Sprockets 2 vs. 3 vs. Webpacker) — Rails Composer templates include CSS/JS assets for Bootstrap/Foundation that differ between Rails 3.2 (Sprockets 2) and modern Rails (Webpacker); template generation must account for asset pipeline differences or assets fail to load
• SimpleForm Custom Input Builders — The generator includes files/app/helpers/application_helper-simple_form.rb showing custom form markup; understanding SimpleForm configuration is necessary to maintain Devise/OmniAuth form templates
• Database Adapter Configuration (MySQL vs. PostgreSQL) — Templates branch database.yml and Gemfile entries based on user choice; understanding Rails database adapter gems and YAML interpolation is required to support multiple databases correctly

• thoughtbot/suspenders — Similar Rails application template emphasizing best practices and company-standard tooling; active maintenance and modern Rails versions (alternative approach to application bootstrapping)
• lewagon/rails-templates — Modern Rails template generator with Devise, Tailwind CSS, and Stimulus; more recently maintained and supports Rails 6+/7+
• RailsApps/learn-rails — Companion tutorial and starter app generated by Rails Composer; demonstrates expected output and learning progression
• RailsApps/rails-devise — Specific example app generated by Rails Composer targeting Devise authentication; shows production-ready output for a single stack variant
• rails/rails — Core Rails framework; Rails Composer depends on Rails generators and template hooks; understanding Rails generator API is essential to contributing

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 RuboCop configuration enforcement and linting tests for template files

The repo includes files/.rubocop.yml but there's no CI workflow to validate that generated template files comply with it. New contributors should add a GitHub Action that runs RuboCop against the files/ directory to catch style violations early. This ensures generated Rails apps maintain consistent code quality standards.

• [ ] Create .github/workflows/rubocop.yml to run rubocop files/ on PRs
• [ ] Add RuboCop configuration exceptions for template-specific patterns in files/.rubocop.yml
• [ ] Document the linting requirements in CONTRIBUTING.md
• [ ] Test against key template files like files/app/controllers/ and files/app/views/

Create integration tests for composer.rb template generation across Rails versions

The repo has composer.rb and composer-Rails3_2.rb but no test suite validating that template generation works correctly. A new contributor should build RSpec tests that verify the composer generators properly scaffold apps with different gem combinations (devise, omniauth, cancan, bootstrap, etc.). This prevents regressions when updating dependencies.

• [ ] Create spec/composer_spec.rb with tests for basic app generation
• [ ] Add tests for key template files: files/config/secrets.yml, files/config/database-*.yml
• [ ] Test gem combination variations (devise+omniauth, cancan+devise, etc.)
• [ ] Verify layout partials are correctly selected (_navigation-devise.html.erb vs _navigation-cancan.html.erb)

Add documentation for template variant naming conventions and create missing variant files

The codebase uses inconsistent naming patterns for template variants (e.g., 'application-bootstrap.css.scss', '_navigation-devise.html.erb', 'edit-simple_form.html.erb'). A new contributor should document this convention in a TEMPLATE_VARIANTS.md file and identify/create missing variant combinations that users likely expect (e.g., application-simple_form.css.scss, _messages-devise.html.erb).

• [ ] Create docs/TEMPLATE_VARIANTS.md documenting the {filename}-{feature}.{ext} naming pattern
• [ ] Audit files/app/views/layouts/ and files/app/views/devise/ for missing logical combinations
• [ ] Create missing _messages variant files for devise/omniauth/bootstrap combinations
• [ ] Add a matrix table showing which view partials exist for each feature combination

• Add RSpec test templates to files/spec/ and wire bundle install hook in composer.rb to generate spec files for models/controllers created by the template—currently no testing scaffold is applied
• Create a Rails 6+ variant of composer.rb by updating the Devise/Pundit/SimpleForm gem versions and webpacker asset paths; the existing template fails on modern Rails due to yarn/webpacker and gem API changes
• Document the interactive prompt flow with inline comments in composer.rb and add a flow diagram to README.textile—currently new contributors cannot understand which files are conditionally included based on which prompt responses

This Rails Composer starter template has moderate security concerns primarily centered on configuration management and credential handling. The most critical issues are: (1) Hardcoded secrets.yml tracked in version control, (2) Database configuration files with potential credentials included in the repository, and (3) Lack of visible security header configuration. The template

• High · Potential Hardcoded Secrets in Configuration Files — files/config/secrets.yml. The presence of 'files/config/secrets.yml' in the repository indicates that sensitive configuration files may be tracked in version control. Rails secret files should never be committed to git as they may contain database passwords, API keys, and other sensitive credentials. Fix: Remove secrets.yml from version control, add it to .gitignore, and use environment variables or Rails credentials (encrypted credentials.yml.enc) to manage sensitive data. Ensure the file is listed in .gitignore.
• High · Multiple Database Configuration Files in Repository — files/config/database-mysql.yml, files/config/database-postgresql.yml. Database configuration files (database-mysql.yml, database-postgresql.yml) are included in the repository. These files may contain sensitive database connection information including hostnames, usernames, and passwords that should not be version controlled. Fix: Store database credentials in environment variables or use Rails encrypted credentials. Use example configuration files (database.yml.example) instead and add actual configuration files to .gitignore.
• Medium · No Visible Input Validation in View Templates — files/app/views/devise/*, files/app/views/users/_user*.html.erb. Several view files (particularly in devise views, user views, and form partials) are present but cannot be fully analyzed. The file structure suggests user input handling in forms (_user-simple_form.html.erb, edit forms). Without visible sanitization, there is XSS risk if user input is not properly escaped. Fix: Ensure all user-provided data is properly escaped using Rails helpers (<%= %> with automatic escaping enabled). Use strong_parameters in controllers to whitelist permitted parameters. Implement Content Security Policy (CSP) headers.
• Medium · Authentication Framework Usage Without Security Analysis — files/app/controllers/application_controller-omniauth.rb, files/app/controllers/registrations_controller-devise.rb, files/app/views/devise/*. Multiple authentication-related files are present (devise, omniauth, cancan) but actual implementation cannot be verified. If not properly configured, these can introduce authentication bypass or authorization vulnerabilities. Fix: Ensure Devise is updated to the latest secure version. Implement CSRF protection on all state-changing requests. Verify OmniAuth callback handling validates state parameter. Use CanCan properly with load_and_authorize_resource to prevent unauthorized access.
• Medium · Missing Security Headers Configuration — Application configuration (likely config/application.rb or config/initializers/). No visible security headers configuration (HSTS, X-Frame-Options, X-Content-Type-Options, CSP) in the provided file structure. Rails applications should define these headers to prevent common attacks. Fix: Configure security headers in config/application.rb or use the secure_headers gem. Set: X-Frame-Options: DENY, X-Content-Type-Options: nosniff, X-XSS-Protection: 1; mode=block, Strict-Transport-Security for HTTPS.
• Low · RVM Configuration File in Repository — files/.rvmrc. The .rvmrc file (or .ruby-version) in the files directory may leak Ruby version information. While not a direct vulnerability, version disclosure can aid attackers in identifying known vulnerabilities. Fix: Use .ruby-version instead of .rvmrc for better compatibility. These files are typically not security risks but should not contain additional environment-specific secrets.
• Low · Missing or Incomplete .gitignore Rules — .gitignore, files/gitignore.txt. The presence of configuration files in the repository structure suggests potential .gitignore gaps. Critical files like secrets.yml and database.yml should be ignored. Fix: Ensure .gitignore includes: config/secrets.yml, config/database.yml, config/credentials.yml.enc (if using old format), .env, .env.local, and any other files containing sensitive data.

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.