Generate Devcontainer Configuration

Devcontainer Setup describes how to design a development container with Claude Code and tooling matched to a project's languages. It begins with project reconnaissance, derives a project name and volume slug, detects the stack, and assembles configuration for the detected languages. For mixed projects, the documented priority is Python, Node/TypeScript, Rust, then Go, with extensions and editor settings merged across the stack.

A crucial prerequisite limits the automation: the tracked bundle contains two reference documents and their CC-BY-SA-4.0 notice/license, but no resources directory, Dockerfile, devcontainer.json, post_install.py, .zshrc, or install.sh. The template workflow is an upstream design, not runnable bundled setup. Missing-template and helper paths must stop. A minimal configuration can instead be drafted from project requirements, or based on a separately reviewed immutable upstream source.

Use this skill when adding development-container support to a project that does not already have it, especially when language tooling and persistent configuration need to be planned together. It does not cover modifying an existing devcontainer, general Docker questions, or production container deployment. Existing configuration and lockfiles must be preserved.

A devcontainer executes image, feature, build, and lifecycle code and mounts host files. It is not a strong default boundary for a hostile repository. Avoid exposing Docker socket access, host credentials, privileged mode, and NET_ADMIN; writable firewall rules are not an independent network boundary. Validate from a disposable trusted checkout before opening an untrusted project. Installation, marketplace, and configuration changes require authorization rather than automatic plugin activation.

Inputs include project manifests, language requirements, package-manager lockfiles, intended development tools, and reviewed persistent mounts. Project naming checks package.json, pyproject.toml, Cargo.toml, and go.mod before falling back to the directory name. The resulting slug uses lowercase letters and hyphens.

The upstream output design places build, container, shell, and setup files under .devcontainer/. Those file names describe intended artifacts, not files delivered in this bundle. Configuration review checks placeholder replacement, valid JSON, all detected-language extensions, and the required setup sequence. The documented startup alternative is:

devcontainer up --workspace-folder .

The absent devc helper must not be run or described as installed.

The design uses Python through uv, Node through fnm, and devcontainer features for Rust and Go. Python interpreter and Ruff settings, ESLint and Prettier, rust-analyzer, and Go language-server settings are examples of language-specific configuration. Python versions should follow project requirements rather than blindly retaining the upstream Python 3.13 default; Node 22 is also a documented design choice, not a universal requirement.

Package-manager selection follows existing lockfiles, with locked installation or build forms where supplied. Several historical postCreateCommand examples depend on the missing post_install.py, so they are not ready-to-run instructions. Persistent Cargo and Go volumes illustrate project-scoped naming, but mounts must also be scoped by user and account for retained credentials. The included references discuss Dockerfile practices and choosing features versus custom build instructions.