Configure

Client dispatch: In Codex, read codex-runtime and configure/codex.md, execute that native procedure, and do not continue into the Claude procedure below.

Interaction rule: Every question, confirmation, or approval directed at the user — anywhere in this skill, including error recovery — MUST be asked with the AskUserQuestion tool. Never ask in plain text. If an instruction says "ask the user" or "confirm", that means AskUserQuestion.

Task

Help the user set up this project for the cenci plugin.

Parse $ARGUMENTS

All of $ARGUMENTS is optional user context (additional instructions or focus areas). If empty, proceed normally with defaults.

Existing Config Detection

Resolve project configuration in this order:

1. .cenci/config.json is canonical. If present, read it as existingConfig.
2. Otherwise read .claude/config.json as legacyConfig. Treat this as a migration run.
3. If neither exists, set existingConfig to null.

On migration, preserve every unknown key from legacyConfig; new writes go only to .cenci/config.json. If both files exist, recursively merge them into one migrationBase with canonical values winning, then overlay managed answers. Use "${CLAUDE_PLUGIN_ROOT}/scripts/migrate-project-core.sh" <root> to preview the exact config/guidance diff:

bash "${CLAUDE_PLUGIN_ROOT}/scripts/migrate-project-core.sh" <root> [--apply]

Rerun it with --apply only after approval, with <root> set to <worktree-path> (see Create Worktree below — the worktree exists by the time any --apply can run). Never rewrite or delete .claude/config.json; it is a read-only compatibility artifact.

When existingConfig is present, tell the user before starting questions: "Found existing configuration. Each question will show your current setting as the default — select it to keep it unchanged."

Reconfiguration runs are how a project picks up configure features added since its config was written. The plugin's SessionStart hook (hooks/scripts/check-config-staleness.sh) compares existingConfig.configVersion against the installed flow plugin version and nudges the user to re-run this skill when the config is stale or unstamped; completing this run refreshes the stamp (step 6) and clears the nudge.

Create Worktree

/cenci:configure writes files into the repo (.cenci/config.json, AGENTS.md/CLAUDE.md, .mcp.json, .lsp.json, .gitignore, .claudeignore, .github/workflows/ci.yml, .cenci/Dockerfile, .lazyboards.yml, .codex/agents/) and updates .claude/settings.json. Like every other change in this repo, these ship as a PR — configure never writes directly to the main worktree (see cenci:worktrees and docs/git-workflow.md).

Create the worktree now, before any file is written (including a migration --apply above) and before the detection/question steps below, since none of them depend on it existing yet:

1. Verify at least one commit exists: git rev-parse HEAD 2>/dev/null. If the repository has no commits, create an initial commit as two standalone Bash calls (never compound && — shell-rules: every segment of a compound is evaluated independently by the approval system): git add -A, then git commit -m "chore: initial commit" --allow-empty.
2. Derive a slug: init when existingConfig is null (first-ever configure run), update for a plain reconfiguration, or a short kebab-case description of the user's focus when $ARGUMENTS names one (e.g. "refresh MCP servers" → mcp-refresh).
3. Create the worktree: git worktree add .worktrees/configure-<slug> -b chore/configure-<slug> main. If that branch/directory name is already taken by an unrelated prior run, append -2, -3, etc. until it's free.

From this point on, <worktree-path> is .worktrees/configure-<slug>. Every file this skill reads or writes below — .cenci/config.json, AGENTS.md, CLAUDE.md, .mcp.json, .lsp.json, .gitignore, .claudeignore, .claude/settings.json, .github/workflows/, .cenci/Dockerfile, .lazyboards.yml, .codex/, designs/ — and every "the repo root" / "the project root" reference in the steps below resolves against <worktree-path>, never the main checkout. Use absolute paths rooted at <worktree-path> for every Write/Edit; verify the CWD before Bash commands rather than relying on a single cd persisting across calls. gh label create / gh issue calls (step 3c) are GitHub API calls, not file writes, and run the same regardless of worktree.

Scripted Detection

The deterministic detections this skill needs (platform, container, package manager, MCP/LSP/dind/Playwright catalog triggers, plugin version) are scripted, not re-derived ad hoc. Run the bundled detector once, as its own Bash call (per cenci:shell-rules), from the repository root of the main checkout — it only reads, nothing is written:

bash "${CLAUDE_PLUGIN_ROOT}/skills/configure/scripts/detect-project.sh"

(the detector is scripts/detect-project.sh inside this skill; its tests live next to it). Parse its stdout as a JSON object and keep it as detection for the rest of this run:

• detection.pluginVersion — installed flow plugin version; stamped into config as configVersion (step 6)
• detection.platform — {name, owner, repo} parsed from the git remote, or null
• detection.inContainer — cenci-sandbox container detection result
• detection.packageManager — pnpm / yarn / npm from lockfiles, or null
• detection.mcpServers — MCP catalog triggers found in the dependency scan (e.g. angular, primeng)
• detection.lspServers — LSP catalog triggers found (e.g. typescript, gopls)
• detection.dindDetected — Testcontainers/Docker-SDK trigger found (question 9b default)
• detection.playwrightTest — @playwright/test in root devDependencies
• detection.warnings — non-fatal detection notes; relay them to the user as informational messages

If the script exits non-zero or its output is not valid JSON, fall back to the manual fallback procedure kept in each consuming section below — a detection either comes from detection or from its manual fallback, never silently skipped. The script only detects: every question, catalog decision, and user choice stays in this skill.

Platform Detection

Use detection.platform: when non-null it carries the platform name plus extracted owner/repo; when null, fall back to manual questions.

Manual fallback (only if Scripted Detection failed): run git remote get-url origin 2>/dev/null and parse the result:

Strip trailing .git suffix from repo names.

If user context was provided, use it to steer the configuration (e.g., skip certain questions, pre-select options, focus on specific areas).

Container Detection

cenci runs inside sandbox's cenci-sandbox container with --dangerously-skip-permissions. The container is the security boundary — there is no host profile. Claude Code's own host sandbox stays disabled, and permissions.allow/deny are kept only as defense-in-depth for plain claude runs inside the container (e.g. cenci open --shell).

Use detection.inContainer (the detector checks CENCI_SANDBOX, then /.dockerenv).

Manual fallback (only if Scripted Detection failed) — detect the container (stop at the first match; run each check as its own Bash call, per cenci:shell-rules — never compound them):

1. CENCI_SANDBOX env var (works for both Docker and Podman): run test "${CENCI_SANDBOX:-}" = "1" as its own Bash call. Exit 0 → in container.
2. Docker fallback: run test -f /.dockerenv as its own Bash call. Exit 0 → in container.

This detection is a non-blocking advisory — it never gates configuration and never uses AskUserQuestion:

• In container: emit an informational message: "Detected the cenci-sandbox container — the container is the security boundary. Claude Code's host sandbox stays disabled." Then continue normally.
• Not in container: emit an advisory and continue anyway: "cenci is designed to run inside the cenci-sandbox container (the security boundary). You appear to be running on the host — continuing, but running outside the container is unsupported." Proceed with the same container-shaped output.

Default values from existing config: When existingConfig is not null, each question below MUST present the existing value as the pre-selected default (list it first, marked "(current)"). The user can accept with one click or change it. New fields not in existingConfig (e.g., lspServers when upgrading from a pre-LSP config) have no default and are asked normally.

AskUserQuestion cannot pre-check multiSelect options — its options only carry label/description/preview, no "selected by default" field. So for the two multi-select questions (5. MCP Servers, 6. LSP Servers), "pre-select" cannot mean a pre-ticked checkbox — re-asking the full multi-select on every reconfigure would force re-clicking every already-enabled server one at a time. Instead, gate behind a single Keep/Change confirmation first (see Keep-or-change gate under each question below): when existingConfig already has a value for that field, ask one Yes/No question summarizing the current selections; only "No — let me change them" drops into the full multi-select. This is a single click to keep everything unchanged, instead of one click per server.

Ask these questions one at a time using the AskUserQuestion tool:

1. Tech stack: "What's your tech stack?" (capture for stack pack selection)

   • Backend framework + version
   • Frontend framework + version
   • Test frameworks
   • Any other key technologies

2. Project structure: "Is this a monorepo or single project?"

If monorepo, continue with Steps 2a and 2b below. Otherwise skip to question 3.

Step 2a — Auto-detect projects

Scan the repo for project directories using these strategies (try all, deduplicate):

1. Node workspaces: Read package.json workspaces field and pnpm-workspace.yaml packages field
2. Lerna: Read lerna.json packages field
3. .NET solutions: Find *.sln files and parse Project(...) references for .csproj paths
4. Convention directories: Scan packages/*/, apps/*/, projects/*/, src/*/ for directories containing package.json or *.csproj

For each discovered project, detect:

• Path: relative directory (e.g., packages/api)
• Stack: auto-detect from dependencies:
  • @angular/core in package.json → Angular
  • react in package.json → React
  • next in package.json → Next.js
  • vue in package.json → Vue
  • .csproj with Microsoft.NET.Sdk.Web → .NET API
  • .csproj with Microsoft.NET.Sdk → .NET library
  • Fallback: read package.json name or directory name
• Build command: auto-detect (dotnet build for .NET, npm run build for Node, etc.)
• Test command: auto-detect (dotnet test for .NET, npm test for Node, etc.)
• Lint command: derive from the Stack-to-CI mapping table's Lint column (see the table under question 8 below); omit lintCommand entirely when the detected stack has no Lint row (e.g. markdown-shell, docker-shell)

Present discovered projects for confirmation using AskUserQuestion: "Found these projects in the monorepo:

1. <path> —
2. <path> — ... Are these correct? (You can add or remove projects)"

Step 2b — Per-project details

For each confirmed project, ask for a one-line description using AskUserQuestion: "Provide a short description for each project:"

• <path> (): ___

Generate a slug for each project from its directory name (e.g., packages/api → api, apps/web-client → web-client).

3. Branching strategy: "What's your branch naming convention?"
   • Default suggestion: feature/<id>-<description>

(There is no question 4 — sandboxing is not asked. The cenci-sandbox container is the security boundary and Claude Code's host sandbox is always disabled; numbering of the remaining questions is kept for stability.)

Dependency Detection

The dependency scan is scripted: detection.mcpServers carries the MCP catalog triggers found, and detection.dindDetected is the dindDetected value question 9b uses below.

Manual fallback (only if Scripted Detection failed) — scan the project for framework dependencies:

1. If package.json exists in the repo root, read dependencies and devDependencies
2. If .csproj files exist, read PackageReference entries
3. Store the detected package names for matching against the MCP catalog below
4. Testcontainers/Docker-SDK detection (for question 9b below — nested Docker/dind): scan for these triggers and store the result as dindDetected (true if any match, false otherwise):
   • npm: testcontainers, @testcontainers/*, or dockerode in dependencies/devDependencies
   • NuGet: Testcontainers* or Docker.DotNet in .csproj PackageReference entries
   • Python: testcontainers in the dependency list (requirements.txt, pyproject.toml) — dep list only, no source scan
   • Go: github.com/testcontainers/testcontainers-go in go.mod

MCP Server Catalog

Scope:

• project: Add to the project's root .mcp.json.
• editor: Provided by the Pencil editor over its own connection — nothing is written to .mcp.json; enablement is driven by pencil.enabled in .cenci/config.json.

LSP Server Catalog

5. MCP Servers: Match detected dependencies against the MCP catalog above. Build a suggestion list:

   • Always include Context7 (general-purpose docs lookup)
   • Add each MCP whose trigger package was found in the dependency scan

   Keep-or-change gate: if existingConfig.mcpServers is present, do not jump straight into the multi-select — AskUserQuestion can't pre-check boxes, so re-asking it fresh would force re-clicking every already-enabled server. Instead present the current state and ask a plain Yes/No:

   "Current MCP servers: <name> ✓ enabled, <name> ✗ disabled, … . Keep these settings?" Options: "Yes — keep current settings (Recommended)", "No — let me change them"

   • Yes: carry existingConfig.mcpServers forward unchanged, skip the multi-select below entirely.
   • No: continue to the multi-select below.

   If existingConfig.mcpServers is absent (first-ever configure run, or a newly-detected MCP not previously offered), skip the gate and ask the multi-select directly.

   Present using AskUserQuestion with multiSelect=true (sort currently-enabled servers first when existingConfig.mcpServers exists, so they're easiest to re-tick):

   "Based on your project dependencies, these MCP servers can enhance AI assistance. Which would you like to enable?"

   Options (only show those whose trigger was detected, plus Context7 always):

   • "Context7 — Live documentation lookup for any library (requires free API key from context7.com/dashboard)"
   • "Angular — Official Angular AI tutor, best practices, and documentation search"
   • "PrimeNG — Component documentation, props, events, theming, and examples"

   If only Context7 is available (no framework-specific MCPs detected), still present it: "Do you want to enable Context7 for live documentation lookup? (Requires a free API key from context7.com/dashboard)"

Pencil Design Workflows

Condition: Only ask question 5b when a frontend framework is detected in the stack from question 1. Frontend frameworks include: Angular, React, Next.js, Vue, Svelte, or any UI framework.

If no frontend framework is detected, skip this section entirely (do not set pencil in config).

5b. Pencil design workflows: Present using AskUserQuestion:

"Your project includes <detected-frontend-framework>. Do you want to enable Pencil design workflows? (Visual designs, auto-generated design specs with component mappings and tokens. Requires the Pencil editor.)"

Options: "Yes — enable Pencil design workflows", "No — skip"

If Yes AND monorepo with multiple frontend projects (i.e., isMonorepo is true and more than one project in the projects array has a frontend stack):

"Should frontend projects share one design file, or have separate design files?"

Options: "Shared (single designs/ at repo root)", "Separate (per-project designs/)"

• Shared: pencil.designPath = "designs/", pencil.shared = true
• Separate: each frontend project entry in the projects array gets its own designPath (e.g., "<project-path>/designs/")

If Yes AND single project (or monorepo with only one frontend project):

• pencil.designPath = "designs/", pencil.shared is omitted

After the user confirms Yes (regardless of monorepo choice), detect pen interactive support:

Run pen interactive --help 2>/dev/null and check both the exit code and the output: require exit 0 and the output containing --app. The --app flag is specific to the npm CLI's (@pen.dev/cli) interactive subcommand help — a desktop-app-installed pen symlink instead launches the GUI application on any unrecognized argument, including --help, and can also exit 0 without ever printing --app. Checking the exit code alone would misdetect that desktop-symlink host as cli-app mode; the combined check is how cli-app vs. editor mode is auto-detected without that false positive.

• Both conditions hold → Write pencil.mode: "cli-app" to the config. Inform the user: "Pencil interactive mode detected. Design skills will use pen interactive to communicate with the Pencil editor — this is more token-efficient than the MCP server. For maximum token savings, you can disable the Pencil MCP server in your editor settings (Pencil → Preferences → MCP Server). cenci uses the CLI directly and does not need the MCP server."
• Either condition fails, or the command is not found → Write pencil.mode: "editor" to the config. Inform the user: "Pencil interactive mode not available. Design skills will use the Pencil MCP server (requires the MCP connection to be active in your editor). For better token efficiency, install the pen command (npm install -g @pen.dev/cli, or from within the Pencil app: File → Install pen command into PATH) and re-run /cenci:configure — this switches to cli-app mode which avoids loading MCP tool schemas into every conversation."

Sandbox note (no extra config value needed): inside the cenci sandbox neither the desktop editor nor its MCP server is reachable, so with either mode above the pipeline's availability probe (implement's Design Context Loading) falls back at runtime to pen interactive headless mode — the CLI's own editor engine, no GUI — using the pen binary baked into the sandbox image by sandbox/fragments/pencil.dockerfile (included when pencil.enabled is true; see question 9). Headless auth comes from the host's ~/.pencil/session-cli.json (created by pen login, staged into the container automatically) or a PEN_CLI_KEY set in the host environment (forwarded per agent session, never baked into the image). This headless fallback covers the pipeline's reads only: design itself is host-only and refuses to run in-container — /cenci:design fails fast with host-session guidance (see design/SKILL.md Phase 0.5). cenci run design {number} --no-sandbox is how the generated board dispatches it (see the D action below).

Playwright CLI Setup

Condition: Only ask this when a frontend framework is detected in the stack from question 1 AND detection.playwrightTest is true (manual fallback: @playwright/test found in root devDependencies).

If both conditions are met, present using AskUserQuestion:

"Your project uses Playwright Test. Do you want to set up Playwright CLI (@playwright/cli) for interactive browser automation during development? (Screenshots, snapshots, form filling, network inspection — more token-efficient than Chrome MCP for agents.)"

Options: "Yes — install and configure Playwright CLI", "No — skip"

If Yes:

1. Check if playwright-cli is already installed: which playwright-cli 2>/dev/null
   • Found → "✓ playwright-cli found at <path>"
   • Not found → "Run npm i -g @playwright/cli to install, then playwright-cli install --skills to set up agent skills."
2. Set playwrightCli: true in .cenci/config.json

If No: Set playwrightCli: false in .cenci/config.json (or omit the field)

If the conditions are not met, skip this section entirely (do not set playwrightCli in config).

LSP Detection

detection.lspServers carries the detected LSP catalog triggers directly.

Manual fallback (only if Scripted Detection failed) — reuse the dependency detection results from earlier and add file-type detection to match against the LSP Server Catalog:

• typescript, @angular/core, react, next, or vue in package.json dependencies → typescript
• *.py files present, or pyproject.toml, or requirements.txt → pyright
• Cargo.toml present → rust-analyzer
• *.csproj present → csharp-ls
• go.mod present → gopls

If no LSP servers are detected, skip question 6 entirely.

6. LSP Servers: If two or more LSP servers were detected above:

   Keep-or-change gate: if existingConfig.lspServers is present, do not jump straight into the multi-select — AskUserQuestion can't pre-check boxes, so re-asking it fresh would force re-clicking every already-enabled server. Instead present the current state and ask a plain Yes/No:

   "Current LSP servers: <name> ✓ enabled, <name> ✗ disabled, … . Keep these settings?" Options: "Yes — keep current settings (Recommended)", "No — let me change them"

   • Yes: carry existingConfig.lspServers forward unchanged, skip the multi-select below entirely.
   • No: continue to the multi-select below.

   If existingConfig.lspServers is absent (first-ever configure run, or a newly-detected LSP server not previously offered), skip the gate and ask the multi-select directly.

   Present using AskUserQuestion with multiSelect=true (sort currently-enabled servers first when existingConfig.lspServers exists, so they're easiest to re-tick):

   "LSP servers provide real-time diagnostics (type errors, unused variables, dead code) during implementation. Based on your project, which would you like to enable?"

   Options (only show those whose trigger was detected):

   • "typescript — TypeScript/JavaScript type checking and diagnostics"
   • "pyright — Python type checking and diagnostics"
   • "rust-analyzer — Rust type checking and diagnostics"
   • "csharp-ls — C# type checking and diagnostics"
   • "gopls — Go type checking and diagnostics"

   If exactly one LSP server was detected, ask a plain Yes/No instead — a multi-select checkbox with a single option has no sensible "none" choice:

   "Your project uses <detected-language>. Do you want to enable <server-name> for real-time diagnostics (type errors, unused variables, dead code) during implementation?"

   Options: "Yes — enable <server-name>", "No — skip"

Binary Verification

For each LSP server the user selected, verify the binary is installed:

which <command>

• Found: Confirm with a checkmark: "✓ <command> found at <path>"
• Not found: Warn with install command: "⚠ <command> not found. Install with: <install-command>. Server will activate once installed."

Include the server in .lsp.json regardless — it activates once the binary is installed.

7. Disable auto-compact: "Do you want to disable Claude Code's auto-compact feature? Auto-compact compresses conversation history as the context window fills, which can lose important context during long sessions. (Recommended: Yes — disable it)"
   • Default: Yes
   • If Yes: set "autoCompactEnabled": false in ~/.claude/settings.json using jq (see step 5c for the exact jq/mv sequence, and its Write-then-mv variant when the file doesn't exist yet)
   • If No: remove the autoCompactEnabled key from ~/.claude/settings.json (if present)
   • Either way, also remove any CLAUDE_AUTOCOMPACT_PCT_OVERRIDE key from the env object in ~/.claude/settings.json. Earlier versions of this skill set it to "1" believing that meant manual-only compaction; Claude Code interprets it as "compact once 1% of the context window is used", so any leftover value causes constant compaction and must be purged.

7b. Pin subagents to 200K context: "Do you want to pin cenci's subagents to a 200K-context model? cenci delegates reviews to subagents, and on 1M-context sessions that delegation can be gated — every subagent inherits the session's 1M flag but not its extra-usage entitlement, so reviews fail with 'Usage credits required for 1M context' (Claude Code bug #51060). Pinning subagents to Sonnet 200K keeps reviews working while your main session keeps its 1M context. (Recommended: Yes if you run a 1M-context session; No otherwise — see the tiering caveat below)"

• Default: Yes when the session plausibly runs a 1M model; No otherwise
• If Yes: merge {"env": {"CLAUDE_CODE_SUBAGENT_MODEL": "claude-sonnet-5"}} into ~/.claude/settings.json using jq (see step 5c-bis for the exact jq/mv sequence, and its Write-then-mv variant when the file doesn't exist yet). This runs all Task subagents on Sonnet 200K regardless of the main session model. (Pin Sonnet, not Opus — Opus is auto-upgraded to 1M on Max/Team/Enterprise plans and would re-trigger the gate.)
• If No: remove the CLAUDE_CODE_SUBAGENT_MODEL key from the env object in ~/.claude/settings.json (if present)
• Tiering caveat (state regardless of answer): the pin overrides every agent's model: frontmatter — cenci's model tiering (opus refiner/planner/security-reviewer, haiku context-gatherer/structure-analyzer/lessons-collector) is flattened onto the pinned model while it is set. On a standard 200K session the 1M gate never fires, so answer No there to keep the tiering active.
• Caveat (state regardless of answer): this only affects new sessions — restart after configuring. If subagent reviews still fail with the 1M gate even after pinning (the pin didn't strip [1m]), run /model sonnet for the current session, which always yields 200K.

8. CI/CD pipeline: "Do you want to generate a CI/CD pipeline?"

   • Options: "Yes — generate a CI workflow", "No — skip"
   • Default: No
   • Platform: GitHub Actions

   Conflict check: If the user selects Yes, scan for existing CI configuration:

   • Use the Glob tool with patterns .github/workflows/*.yml and .github/workflows/*.yaml

   If any files are found, present them and ask:

   • Single file: "Found existing CI configuration at <path>. What would you like to do?"
   • Multiple files: "Found existing CI workflows:\n - <path1>\n - <path2>\n ...\nWhat would you like to do?"

   Options: "Overwrite — generate ci.yml (existing files are not deleted)", "Skip — keep existing files", "Show existing — display the current file contents"

   • If Skip: still record cicd in config.json, don't write the file
   • If Show existing: read and display each file, then re-ask Overwrite/Skip

   Stack-to-CI mapping: Use the detected stack from question 1 to select the appropriate lint, build, and test commands:

   Stack	Lint	Build	Test
   dotnet*	dotnet format --verify-no-changes	dotnet build --no-restore	dotnet test --no-build --collect:"XPlat Code Coverage"
   go	golangci-lint run ./...	go build ./...	go test ./... -coverprofile=coverage.out
   python	ruff check .	(none)	pytest --cov=. --cov-report=xml
   rust	cargo clippy -- -D warnings	cargo build	cargo test
   angular*	ng lint	ng build --configuration production	ng test --watch=false --code-coverage
   react / next	npx eslint .	npm run build	npm test -- --coverage --watchAll=false
   vue	npx eslint .	npm run build	npm run test:unit -- --coverage

   Package manager detection (for Node-based stacks): use detection.packageManager. Manual fallback:

   • pnpm-lock.yaml → pnpm
   • yarn.lock → yarn
   • package-lock.json → npm
   • .NET → NuGet cache on **/*.csproj
   • Go → built-in cache in actions/setup-go@v5

   Version pinning:

   • Node: engines.node from package.json, fallback "20"
   • .NET: extract from stack token (dotnet10 → "10.x")
   • Go: first line of go.mod
   • Python: python-requires from pyproject.toml, fallback "3.12"
   • Rust: rust-toolchain.toml or "stable"

9. Sandbox Dockerfile: "Generate a sandbox Dockerfile for this repo? (Tailors the sandbox image to your stack; committed so your team shares it.)"

   • Options: "Yes — generate .cenci/Dockerfile", "No — skip"
   • Default: Yes

   Mandatory agent runtime: Always include node.dockerfile, regardless of the detected project stack. Claude Code and Codex are npm-distributed launchers installed by the isolated shared-volume updater, so generated images need Node.js but must not bake either agent CLI.

   Stack-to-fragment mapping: In addition to the mandatory Node runtime fragment, use the detected stack from question 1 (or, for monorepos, the union of every projects[].stack.framework value) to select which sandbox/fragments/*.dockerfile blocks to include:

   Detected stack	Fragment
   dotnet*	.NET SDK block (version from the token)
   angular* / react / next / vue / node	Node block
   angular* / react / next / vue	Playwright block (Chromium, for verify-ui screenshot capture)
   go	Go block
   python	Python + uv block
   rust	Rust block
   (none — config-selected)	Docker block, when sandbox.dind: true (question 9b)
   (none — config-selected)	Azure block, when sandbox.azure: true (question 9c)

   Playwright is scoped to the frontend-framework tokens, not plain node — a Node-based backend/API project gets the Node block without paying Chromium's image-size cost for a visual-verification step it will never run.

   Pencil fragment (config-selected, not stack-token-selected): when the config being written enables Pencil design workflows (pencil.enabled: true, question 5b), additionally include sandbox/fragments/pencil.dockerfile — it bakes the @pen.dev/cli npm package into the image so implement/verify-ui can run their design reads in the CLI's headless mode inside the sandbox, where the host's desktop editor and its MCP server are unreachable. Like Playwright, it is scoped to repos that actually need it rather than every Node image.

   Docker fragment (config-selected, not stack-token-selected): when the config being written enables nested Docker (sandbox.dind: true, question 9b), additionally include sandbox/fragments/docker.dockerfile — it installs the Docker CLI, the docker-ce engine and containerd.io so entrypoint.sh can start an inner daemon under sysbox-runc. This block used to live in Dockerfile.base and so shipped in every image; since #831 it is selected only for repos that actually run nested Docker. A dind: true repo whose .cenci/Dockerfile omits this fragment builds an image with no dockerd — the sandbox still boots and stays usable, but nested Docker is unavailable and ~/.cenci-dockerd-startup-error explains why. So when Q9 is answered No (no .cenci/Dockerfile generated) and Q9b is answered Yes, tell the user their repo will use the shared cenci-sandbox:latest monolith, which carries the Docker block already — no action needed.

   Azure fragment (config-selected, not stack-token-selected): when the config being written enables the Azure CLI (sandbox.azure: true, question 9c), additionally include sandbox/fragments/azure.dockerfile — it installs az from Microsoft's apt repo so an agent can check real command syntax with az <group> <cmd> --help instead of guessing it. There is no stack token for this: an Azure repo can be written in any language, so the opt-in is the only signal. Unlike the Docker fragment there is no monolith fallback — cenci-sandbox:latest carries no az either — so a repo that answers Yes to Q9c but No to Q9 gets no Azure CLI at all; tell the user Q9 must also be Yes for the CLI to reach their sandbox.

   Monorepo: take the union of all projects[].stack.framework values, deduplicated — e.g. a repo with a Go API project and a React web client project selects both the Go and Node fragments. Node is still emitted only once because the mandatory runtime set and stack-selected set are deduplicated.

   A stack token that matches no row above (e.g. markdown-shell, docker-shell) contributes no additional project fragment. This is not an error — the generated Dockerfile still contains the mandatory Node runtime fragment.

   .NET version substitution (the only row with a version-from-token adjustment): sandbox/fragments/dotnet.dockerfile ships with ARG DOTNET_SDK_VERSION=10.0.100 as its own default. When including this fragment, replace that default's version with <major>.0.100, where <major> is extracted from the stack token using the same extraction as the CI mapping's version-pinning table above (dotnet10 → 10) — e.g. a dotnet8 stack writes ARG DOTNET_SDK_VERSION=8.0.100. Monorepo tie-break: when multiple projects map to the dotnet fragment with different major versions (e.g. one project on dotnet8, another on dotnet10), use the highest major version found across all matching projects. If no major version can be extracted from the token, leave the fragment's own default (10.0.100) unmodified — and add an inline comment immediately after the ARG DOTNET_SDK_VERSION line noting the version could not be auto-detected from the stack token and the fragment's default was used instead, e.g. # .NET version could not be auto-detected from the stack token — using fragment default. See sandbox/README.md to pin manually. (mirrors the unresolved-baseVersion comment pattern in the baseVersion resolution above). The other fragments (node, playwright, go, python, rust, pencil, docker, azure) are included verbatim with their own ARG defaults unmodified — every fragment ARG (including DOTNET_SDK_VERSION and BASE_VERSION) remains overridable at build time via --build-arg, so an unmodified default is never a hard lock-in.

   Sync obligation: sandbox/fragments/*.dockerfile is the source of truth for these blocks; the mapping table above mirrors their content and existence, not their byte contents (generation reads the fragment files directly — see step 5e). If a fragment is added, removed, or renamed, this table needs a matching manual update. Low risk in practice — both live in the same monorepo and are maintained together — but currently unenforced by tooling.

   Trust / security note: .cenci/Dockerfile is committed to the repo, so it is reviewed like any other file in the PR that adds or changes it. It only runs docker build steps assembled from sandbox/fragments/*.dockerfile — no arbitrary runtime hooks execute during configure or during the build it produces.

9b. Nested Docker (dind): "Does this repo need Docker inside the sandbox — Testcontainers, docker build/docker run in tests, or a Docker SDK client?"

• Options: "Yes — enable nested Docker (sandbox.dind)", "No — skip"
• Default: Yes when dindDetected is true (a Testcontainers/Docker-SDK trigger was found above), otherwise No
• This question is independent of question 9 (Sandbox Dockerfile) — ask it regardless of how Q9 was answered, and record its answer separately (see the sandbox.dind schema note below).
• If Yes: inform the user that nested Docker requires the host to have Docker (not Podman) with the sysbox-runc container runtime registered — cenci doctor reports this — and point at sandbox/README.md#nested-docker-sysbox for host install instructions per distro.
• If Yes and question 9 generated a .cenci/Dockerfile: that Dockerfile must include sandbox/fragments/docker.dockerfile (see the mapping table's Docker rule under question 9). Because Q9b is asked after Q9, generate the Dockerfile only once this answer is known — or regenerate it here — so a dind: true repo never ends up with

…(truncated)