Configure Rails for Conductor Parallel Agents

Conductor Setup configures an explicitly selected Rails development project to run inside Conductor workspaces. It describes a small set of project files that connect workspace setup and startup commands, provide controlled access to approved development secrets, and pass workspace-specific port and Redis settings into the application. The goal is to support parallel coding workspaces with verified resource separation.

The root conductor.json maps setup to bin/conductor-setup and run to script/server. The setup script requires a reviewed CONDUCTOR_ROOT_PATH, links an approved local .env and config/master.key only when the destinations are absent, and installs reviewed dependencies. Existing files and dangling symlinks are preserved. The npm path uses a lockfile and npm ci with lifecycle scripts disabled; a package.json without the reviewed lockfile causes the documented setup to stop instead of silently choosing npm install.

Use the skill when a Rails repository needs the standard Conductor scaffolding or when concurrent development workspaces need deliberate allocation of ports and Redis resources. Review the existing scripts, lockfiles, and dependency behavior before running installation or startup commands. Tool and context hints do not authorize delegation, secret changes, or broader permissions.

This is development setup guidance, not automatic isolation. Shared secret symlinks expose the same sensitive values across workspaces, so only approved development credentials belong in that arrangement. Preserve owner-only source permissions and exclude secrets from Git. Required inputs, permissions, boundaries, and success criteria need clarification if they are missing.

Inputs include the selected Rails repository, approved secret source, reviewed dependency lockfiles, a workspace port reservation, and a dedicated disposable Redis instance or explicitly assigned namespace. Output consists of the missing configuration and executable scripts plus narrowly scoped Redis configuration updates. Existing conductor.json, bin/conductor-setup, and script/server files are skipped and reported rather than overwritten.

The startup script validates CONDUCTOR_PORT, defaults to 3000, restricts the base port to 1024 through 64535, and derives VITE_RUBY_PORT by adding 1000. Reservation still belongs to the workspace manager: arithmetic alone does not establish uniqueness. Startup requires an approved REDIS_URL and runs bin/dev.

The Redis configuration review covers existing Sidekiq, Action Cable, Rails cache, and Rack::Attack settings only where those files already use Redis. An environment-driven Ruby setting is:

redis_url = ENV.fetch('REDIS_URL', 'redis://localhost:6379/0')

Sharing one Redis URL between services can still require service namespaces. Hashing workspace names modulo 16 is not isolation, and shared Redis must never be flushed as cleanup. Dependency installation and bin/dev execute project code; explicitly required lifecycle steps need individual review and approval.

Verification checks file presence, executable permissions, script syntax, and environment references, then observes the owned development server within a bounded window and a defined shutdown method. Actual port and Redis separation across workspaces must be checked before treating setup as successful.