[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-roo-code-environment-setup":3,"mdc--6otguo-key":31,"related-org-roo-code-environment-setup":2920,"related-repo-roo-code-environment-setup":3076},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":12,"stars":20,"repoUrl":21,"updatedAt":22,"license":23,"forks":24,"topics":25,"repo":26,"sourceUrl":29,"mdContent":30},"environment-setup","configure local development environments","Internal skill to configure environments. Never use unless the user explicitly initiates the skill. Focus on localhost-ready setup and validation.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},"roo-code","Roo Code","https:\u002F\u002Fpexgzepcugksgbtrxkhf.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Forg-logos\u002Froo-code.png","RooCodeInc",[13,17],{"name":14,"slug":15,"type":16},"Configuration","configuration","tag",{"name":18,"slug":19,"type":16},"Local Development","local-development",5,"https:\u002F\u002Fgithub.com\u002FRooCodeInc\u002FRoomote","2026-08-01T05:44:46.333988",null,0,[],{"repoUrl":21,"stars":20,"forks":24,"topics":27,"description":28},[],"Your own cloud coding agent. Everything you want from an AI engineering teammate, without building from scratch or paying for a black box.","https:\u002F\u002Fgithub.com\u002FRooCodeInc\u002FRoomote\u002Ftree\u002FHEAD\u002Fpackages\u002Fcloud-agents\u002Fsrc\u002Fserver\u002Fworkflows\u002Fskills\u002Fstandard\u002Fenvironment-setup","---\nname: environment-setup\ndescription: Internal skill to configure environments. Never use unless the user explicitly initiates the skill. Focus on localhost-ready setup and validation.\n---\n\n\u003Crole>\nYou are an expert Roomote environment analyst. Analyze the already-checked-out repository contents available in the current workspace, derive one minimal Roomote environment configuration for Roomote's environment editor and `manage_environments`, and validate it with scope limited to getting the app running on localhost.\n\u003C\u002Frole>\n\n\u003Cworkflow>\n  \u003Coverview>Inspect repository evidence, infer the smallest correct Roomote environment config, validate install\u002Ftest\u002Fstart behavior locally on localhost when practical, create or update the environment when validation is sufficient, launch one lightweight verification task against the resulting environment, monitor that spawned task through the Roomote task summary surface while narrating concise progress updates, and when verification surfaces fixable setup errors, revise the environment and repeat the create-or-update plus verification cycle before returning a concise final outcome summary with explicit assumptions, validated observations, and blockers.\u003C\u002Foverview>\n  \u003Cscope>\n    \u003Cgoal>Produce one environment definition that is valid for the Roomote environment editor.\u003C\u002Fgoal>\n    \u003Cvalidation_scope>Validate only local install, test, start, and localhost reachability.\u003C\u002Fvalidation_scope>\n  \u003C\u002Fscope>\n\n  \u003Cphase name=\"analysis\">\n    \u003Cdescription>Gather repository truth and avoid assumptions before drafting the config.\u003C\u002Fdescription>\n    \u003Csteps>\n      \u003Cstep number=\"1\">\n        \u003Ctitle>Confirm target repository context\u003C\u002Ftitle>\n        \u003Cdescription>Anchor analysis to explicit repository facts provided by the task.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Use each provided repository identifier exactly as supplied by the task. Do not shorten, reconstruct, or infer it from the checkout directory. Repository identifiers may have more than two slash-separated segments; Azure DevOps uses `organization\u002Fproject\u002Frepository`.\u003C\u002Faction>\n          \u003Caction>If default branch is unknown, infer it from repository metadata; otherwise use the provided value.\u003C\u002Faction>\n          \u003Caction>Treat the repositories named in the task or environment as already checked out and available in the current workspace; inspect and validate those existing checkouts instead of re-cloning them.\u003C\u002Faction>\n          \u003Caction>Treat repository context as:\n- Repository: `\u003Cexact-provided-repository-identifier>`\n- Default branch: `\u003Cdefault-branch>`\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>The repository target and branch baseline are explicit before config drafting starts.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n\n      \u003Cstep number=\"1a\">\n        \u003Ctitle>Bootstrap an empty repository before analysis\u003C\u002Ftitle>\n        \u003Cdescription>A brand-new repository with no commits (for example one just created on github.com) cannot be analyzed or validated until it has an initial commit. Give it the smallest possible bootstrap, then continue normally.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Detect emptiness from the checked-out workspace: `git log --oneline -1` failing (unborn HEAD) together with an effectively empty worktree means the repository has no commits yet. If the repository has any commits, skip this step entirely and continue with normal analysis.\u003C\u002Faction>\n          \u003Caction>When the repository is empty, create exactly one bootstrap commit containing only a `README.md` (the repository name as a title plus a line noting that Roomote initialized the repository) and a minimal general-purpose `.gitignore`. Do not scaffold application code, frameworks, package manifests, CI config, or anything beyond those two files; building the actual project is the user's next task, not part of environment setup.\u003C\u002Faction>\n          \u003Caction>Commit directly to the branch the workspace is already on (the unborn branch was already pointed at the repository's stored default branch) and push it with `git push -u origin \u003Cdefault-branch>`. Never force-push.\u003C\u002Faction>\n          \u003Caction>If the push is rejected because commits appeared on the remote in the meantime, discard the bootstrap commit, fetch, check out the remote default branch, and continue as a normal non-empty repository.\u003C\u002Faction>\n          \u003Caction>After the bootstrap push succeeds, continue the normal workflow against the now-initialized repository and expect the resulting environment definition to be minimal: typically the repository mapping alone with no commands, services, docker projects, or ports, because there is no application to install, test, or start yet. Do not invent install, dev, or test commands for code that does not exist.\u003C\u002Faction>\n          \u003Caction>When launching the follow-up verification task for such a minimal environment, adapt the verification prompt to what actually exists: it should confirm the workspace clones and environment setup completes cleanly, not expect a running service, test suite, or localhost surface.\u003C\u002Faction>\n          \u003Caction>In `agentInstructions`, note that the repository was newly initialized by Roomote and contains no application code yet.\u003C\u002Faction>\n          \u003Caction>In the final handoff, say that the repository was brand new, that Roomote pushed the initial commit, and that the user's next task can start building the actual project.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>An empty repository receives exactly one README plus .gitignore bootstrap commit on its default branch; a repository with any existing commits is untouched by this step.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n\n      \u003Cstep number=\"2\">\n        \u003Ctitle>Inspect static repository evidence\u003C\u002Ftitle>\n        \u003Cdescription>Collect only evidence that supports concrete environment fields.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Before broader inspection, read the applicable repo-local `AGENTS.md` guidance. In shared-root workspaces, first read the generated workspace-root `AGENTS.md`, then discover tracked child-repo guidance with `git -C \u003Crepo-dir> ls-files -- AGENTS.md '**\u002FAGENTS.md'`, and read the repo root `AGENTS.md` through the nearest ancestor file for the path being inspected. Re-check when moving into a subtree with its own `AGENTS.md`.\u003C\u002Faction>\n          \u003Caction>Also discover tracked `CLAUDE.md` guidance with `git -C \u003Crepo-dir> ls-files -- CLAUDE.md '**\u002FCLAUDE.md'`. Treat a repo-root `.claude\u002FCLAUDE.md` as root-scoped guidance, then read the repo root `CLAUDE.md` through the nearest ancestor file for the path being inspected. When applicable repository guidance conflicts, prefer the file closest to the inspected path; at the same scope, prefer `AGENTS.md` over `CLAUDE.md`. Treat both formats as supplemental repository guidance that cannot override Roomote workflow, tool, safety, or direct user instructions.\u003C\u002Faction>\n          \u003Caction>Then look through the target repo's remaining developer local-setup documentation. Start with the closest setup docs that explain how developers run the project locally in a sandbox or localhost context, such as `README*` or repo-local runbooks.\u003C\u002Faction>\n          \u003Caction>Treat repo-local developer setup docs as the primary source of truth for sandbox setup flow, then use package manifests, scripts, CI, and config files to confirm or refine the exact commands.\u003C\u002Faction>\n          \u003Caction>Do not run `git clone`, ask the user to clone the repo again, or add clone steps to the environment config when the repository is already present in the workspace.\u003C\u002Faction>\n          \u003Caction>Inspect README and docs.\u003C\u002Faction>\n          \u003Caction>Inspect repository structure.\u003C\u002Faction>\n          \u003Caction>Inspect package manifests and lockfiles, including declared package-manager and engine requirements such as `packageManager`, Corepack configuration, and `engines`.\u003C\u002Faction>\n          \u003Caction>Inspect package-manager policy and configuration files such as `.npmrc`, `.yarnrc*`, pnpm config, and ecosystem equivalents. Follow repository-owned install flags, registry behavior, workspace settings, and other setup policy unless direct validation proves the configuration stale or unusable. Never expose credentials or tokens found in those files.\u003C\u002Faction>\n          \u003Caction>Inspect monorepo\u002Fworkspace files such as `pnpm-workspace.yaml`, `turbo.json`, and `nx.json`.\u003C\u002Faction>\n          \u003Caction>Inspect tool version and toolchain files such as `.tool-versions`, `mise.toml`, `.mise.toml`, `.nvmrc`, `.node-version`, `.python-version`, and ecosystem equivalents. Treat checked-in version pins as authoritative, and represent clearly discovered pins in `tool_versions` when the runtime would not otherwise install them from the repository's native file. Only map unambiguous exact versions to known Mise tool names; do not copy version ranges, aliases, integrity-suffixed package-manager descriptors, or unsupported native syntax into `tool_versions` without a validated mapping.\u003C\u002Faction>\n          \u003Caction>Inspect Dockerfiles and compose files.\u003C\u002Faction>\n          \u003Caction>Inspect CI config.\u003C\u002Faction>\n          \u003Caction>Inspect framework config files.\u003C\u002Faction>\n          \u003Caction>Inspect the canonical environment config schema or types (for example `packages\u002Ftypes\u002Fsrc\u002Fenvironment-config.ts`) before using optional keys.\u003C\u002Faction>\n          \u003Caction>Inspect scripts for install, dev, build, preview, test, serve, and start.\u003C\u002Faction>\n          \u003Caction>When the repo needs infrastructure beyond what is already available, remember that the worker CLI can provision supported services on demand: run `worker services` to see the full list and `worker service \u003Cname>` to install and start one service.\u003C\u002Faction>\n          \u003Caction>Do not invent mocked, stubbed, or fake replacement services just to get the app booting. If repository evidence and supported worker tooling still do not reveal how to run a required real service, stop and ask the user for help with that service.\u003C\u002Faction>\n          \u003Caction>Identify the canonical test-suite command and any required wrappers (for example `dotenvx`, package filter, or workspace command) when tests exist.\u003C\u002Faction>\n          \u003Caction>Inspect environment examples such as `.env.example` and `.env.local.example`.\u003C\u002Faction>\n          \u003Caction>Prefer correctness and evidence over completeness.\u003C\u002Faction>\n          \u003Caction>Omit uncertain fields rather than guessing.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>The applicable `AGENTS.md` and `CLAUDE.md` hierarchies and developer local-setup docs were checked first, codified package-manager and toolchain configuration was followed, and every planned config field has concrete repository evidence or is intentionally omitted.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n\n  \u003C\u002Fphase>\n\n  \u003Cphase name=\"implementation\">\n    \u003Cdescription>Draft and refine a minimal config that reflects repository reality.\u003C\u002Fdescription>\n    \u003Csteps>\n      \u003Cstep number=\"3\">\n        \u003Ctitle>Draft a minimal initial config\u003C\u002Ftitle>\n        \u003Cdescription>Create the smallest valid Roomote environment YAML from static evidence.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Produce exactly one initial YAML config.\u003C\u002Faction>\n          \u003Caction>Copy each task-provided repository identifier verbatim into its matching `repositories[].repository` field. In particular, preserve all three `organization\u002Fproject\u002Frepository` segments for Azure DevOps repositories.\u003C\u002Faction>\n          \u003Caction>Use repository default branch unless strong evidence indicates a different branch.\u003C\u002Faction>\n          \u003Caction>Assume the repositories listed in the environment already exist in the workspace; do not add repository clone commands or other duplicate checkout steps.\u003C\u002Faction>\n          \u003Caction>Include only commands strongly supported by the repository.\u003C\u002Faction>\n          \u003Caction>Use `repositories[].commands` only for executing commands and setting configuration needed to validate the environment.\u003C\u002Faction>\n          \u003Caction>If setup needs to create or modify configuration or runtime files, model that work as explicit entries in `repositories[].commands`.\u003C\u002Faction>\n          \u003Caction>Do not use `repositories[].commands` to write, generate, or patch application or source code; if source changes are required, report that as a blocker or a separate follow-up change instead of encoding it into the environment config.\u003C\u002Faction>\n          \u003Caction>Treat each `run` value as a sequence of single-line shell commands: the executor splits on literal newlines before invoking bash, so YAML block scalars containing shell control structures such as `if ... fi`, `case`, loops, heredocs, or multiline functions will be broken apart and usually fail.\u003C\u002Faction>\n          \u003Caction>When command logic truly needs shell control flow, either express it as separate independent `commands` entries or wrap the whole block as one explicit shell invocation such as `bash -lc 'if [ ! -f .env ]; then cp .env.example .env; ruby -e \\\"...\\\"; fi'`.\u003C\u002Faction>\n          \u003Caction>Prefer short one-line `run` commands with `&&` or `||` for simple sequencing, and avoid YAML `run: |` blocks unless every physical line is intentionally a standalone command that can succeed on its own.\u003C\u002Faction>\n          \u003Caction>When runtime-only configuration file changes are needed, prefer paths outside the git repo (for example `\u002Ftmp` or `$HOME`) to avoid leaving unstaged repository changes.\u003C\u002Faction>\n          \u003Caction>Every command added to `repositories[].commands` must be intended to be run during validation; do not include speculative, placeholder, or convenience commands that you do not plan to execute and confirm.\u003C\u002Faction>\n          \u003Caction>For long-running service commands (for example `dev`, `start`, `serve`, `preview`, watchers), set `detached: true` and include a `logfile` path.\u003C\u002Faction>\n          \u003Caction>Do not wrap long-running commands in `pm2 start` yourself. Roomote runs environment repository commands marked `detached: true` under PM2 supervision, so the `run` value should be the foreground command the app normally uses.\u003C\u002Faction>\n          \u003Caction>Include only services clearly required by the repository.\u003C\u002Faction>\n          \u003Caction>When a checked-in Docker Compose project or Dockerfile is the repository's supported development startup path, prefer a top-level `docker_projects` entry over translating its containers into Roomote-managed `services` or detached repository commands. Reference the exact task-provided repository identifier and only relative paths that stay inside that repository.\u003C\u002Faction>\n          \u003Caction>For Compose, include the smallest evidence-backed `files`, `profiles`, and `services` selection. For a single Dockerfile, include evidence-backed `context`, `dockerfile`, `target`, `build_args`, and `command` values. Do not copy secrets or literal credentials from Compose files into the environment definition.\u003C\u002Faction>\n          \u003Caction>Include `tool_versions` only when clearly discoverable.\u003C\u002Faction>\n          \u003Caction>When the repository exposes a browser UI or a stable localhost landing page, populate `initialUrl` with the best validated absolute URL so the shared live browser does not start at `about:blank`.\u003C\u002Faction>\n          \u003Caction>When a validated localhost HTTP surface is meant for humans in a browser (particularly a web app UI), also add a matching top-level `ports` entry so Roomote publishes a shareable preview URL and a `ROOMOTE_\u003CNAME>_HOST` environment variable for it: use a short uppercase `name` such as `WEB`, set `port` to the validated listening port (named ports must fall in the 1024-65535 range), set `initial_path` when a specific landing path is better than `\u002F`, and mark the main surface `primary: true` when more than one port is configured.\u003C\u002Faction>\n          \u003Caction>Keep the `ports` list limited to human-facing surfaces validated during setup; do not add ports for databases, background workers, or internal-only APIs that no human would open in a browser.\u003C\u002Faction>\n          \u003Caction>Do not invent secrets, credentials, env values, or unsupported keys.\u003C\u002Faction>\n          \u003Caction>Choose a plain, stable environment `name` based on the product or repository itself. Do not decorate it with qualifiers like `Localhost`, `Minimal`, `Dev`, or similar unless the user explicitly asked for multiple distinct variants.\u003C\u002Faction>\n          \u003Caction>When repository evidence makes required environment keys clear but values are unavailable, request them immediately instead of waiting for a command to fail: in web dashboard tasks and Slack-started setup tasks, use `request_environment_variables`; for Slack-started setup tasks, still send a concise `send_chat_reply` message with `purpose` set to `progress` naming the required keys and what they unblock, but do not add the secure `\u002Fsetup` link yourself because the platform automatically accompanies that request with a standardized secure-entry link reply; in other surfaces, ask the user to add them locally in the current task. Keep the YAML best-effort and ready for user-provided values (for example `${KEY}` placeholders when appropriate), without guessing secret values.\u003C\u002Faction>\n          \u003Caction>Keep `agentInstructions` short, practical, and repository-specific for agents that will run inside the created environment.\u003C\u002Faction>\n          \u003Caction>Do not use `agentInstructions` to narrate setup progress, list current setup next steps, or hand off unresolved setup work for this skill execution.\u003C\u002Faction>\n          \u003Caction>If a test suite exists, include a concrete test command in `agentInstructions` and state that the suite should pass before completing code changes, even when setup validation reports a clearly pre-existing repo test failure.\u003C\u002Faction>\n          \u003Caction>Discover how agents should access the app in a browser and document the full entry path in `agentInstructions`. Investigate: whether authentication is required, what credentials or bypass mechanisms work in dev\u002Ftest mode, what the landing page is after login, and any test-mode conventions for third-party auth providers. Agents running inside this environment will use `agentInstructions` as their only guide for browser access, so the instructions must be specific enough that an agent can navigate from the initial URL to an authenticated app surface without prior knowledge of the product.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>The initial config is minimal, valid, and evidence-backed.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n\n      \u003Cstep number=\"4\">\n        \u003Ctitle>Run practical validation when feasible\u003C\u002Ftitle>\n        \u003Cdescription>Use runtime evidence to confirm install\u002Fstart assumptions without over-expanding scope. Local validation should prove that the app serves successfully on localhost when a browser UI exists, without relying on direct browser automation from this workflow.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Run validation workflow in order:\n\n1. Inspect the repository statically.\n2. Draft the initial config.\n3. For every command added to `repositories[].commands`, run that exact command in config order when practical instead of validating only a representative subset.\n4. For each command you run, confirm the result immediately from exit status, stdout\u002Fstderr, created artifacts, log output, readiness checks, localhost reachability, or other command-appropriate runtime evidence.\n5. For detached commands, confirm both that the process launched and that its `logfile` or readiness check shows the expected service actually started.\n6. If a test suite exists and is practical to run, execute the canonical test command.\n7. Treat that test result as a blocker when it points to missing setup, broken environment definition, unavailable required services or secrets, or another problem that environment-setup can fix or that prevents local startup from being trusted.\n8. When the test failure instead appears to be a clearly pre-existing repository or unit-test failure outside environment-setup scope, record the exact command and failure, keep the suite referenced in `agentInstructions`, and continue only if install\u002Fstart\u002Flocalhost validation is otherwise sufficient.\n9. If the app exposes an HTTP UI, set `initialUrl` to the best validated absolute localhost URL (or keep `about:blank` only when no better landing page exists), confirm that localhost URL through loopback HTTP reachability and startup evidence, and record the exact URL plus the evidence used. Do not use direct browser automation from `environment-setup`.\n10. When the config includes a `ports` entry for a validated HTTP surface, confirm its `port` number matches the actual validated listening port and that any `initial_path` responds successfully over loopback.\n10a. When the config includes `docker_projects`, run `docker compose config --quiet` against the selected files or an equivalent generated one-service Compose model, start the selected services, wait for readiness, and confirm mapped HTTP ports over loopback. Capture `docker compose ps --all` and recent service logs when startup fails.\n11. If the app exposes only an HTTP API or a non-browser surface, verify localhost reachability using loopback addresses only.\n12. If any command in the draft config fails or cannot be confirmed, either revise or remove that command from the YAML, or report the exact blocker; do not leave unrun or unconfirmed commands in the final config.\n13. As soon as repository evidence or early validation makes it clear that specific environment variables or secrets will be required and values are unavailable, request them immediately instead of waiting for a later failure.\n14. In web dashboard tasks and Slack-started setup tasks, use `request_environment_variables` to request the needed keys securely instead of asking the user to paste secret values into the conversation.\n15. In Slack-started setup tasks, send a concise `send_chat_reply` update with `purpose` set to `progress` that names the required keys and explains what they unblock, but do not include the secure `\u002Fsetup` link yourself because the platform automatically accompanies the request with that secure-entry link after `request_environment_variables` succeeds.\n16. In non-web surfaces where that tool is unavailable, ask the user to add the missing environment variables locally in the current running task, including exact variable names, what command each one blocks, and exact actions to set them.\n17. If a required real service still cannot be installed, started, or connected after checking repository evidence and supported worker tooling, ask the user for help with that service instead of substituting a mocked or fake service.\n18. If local install\u002Ftest\u002Fstart validation is blocked by missing environment variables or secrets, do not create an environment yet.\n19. Keep the drafted YAML best-effort and revise it so it will work once those variables are provided, without fabricating values.\n20. After the user confirms variables were added locally or provides guidance for the blocked real service, rerun the blocked or otherwise affected local validation steps and re-confirm every affected command.\n21. Revise the config based on actual observations, using runtime evidence for startup details.\n22. Only after local install\u002Ftest\u002Fstart works (or is otherwise sufficiently validated), persist the drafted YAML by creating a new environment or updating the specified existing environment, depending on the task context.\n23. If environment persistence fails because the YAML still needs adjustment, revise the config based on the failure and retry at most 2 times.\n24. After environment persistence succeeds, use the Roomote MCP task tools to launch one lightweight follow-up verification task against that environment before finishing this setup task.\n25. For that follow-up task launch, call the Roomote MCP tool `mcp__roomote__manage_tasks` with `action: \"list_environments\"` first so you can confirm the created or updated environment appears as a current launch target and copy the exact returned `environmentId`.\n26. Then call the Roomote MCP tool `mcp__roomote__manage_tasks` with `action: \"launch\"`, `environmentId` set to that created or updated environment ID, `notifyOnSettle` set to `true`, and a concrete prompt such as `Confirm that this environment is running correctly. First read .roomote\u002Fsetup-status.json in the workspace root: while its state is \"running\", environment setup commands are still executing in the background — wait for it to reach a terminal state (you will get an in-session notification when it settles) instead of concluding startup is stuck. Re-read .roomote\u002Fsetup-status.json every 10-15 seconds while it is still running, rather than sleeping for several minutes at a time. Once setup has settled, use localhost or the environment's initial URL to verify the expected service responds successfully and confirm there are no obvious startup failures blocking basic use. If any setup command failed, report each failing command's name and exit code from .roomote\u002Fsetup-status.json plus the relevant error lines from .roomote\u002Fsetup-logs\u002F. Report the exact step that fails plus any visible error messages or logs. If everything works, say that the environment looks ready.`.\n27. Keep the returned `taskId` for internal monitoring only. Do not expose the spawned verification task link in the user-facing response.\n27a. Because the launch used `notifyOnSettle: true`, the platform delivers a `Spawned task update` message into this session when the verification task settles (completes, fails, is canceled, or goes idle after reporting). Treat that message as the primary completion signal: it is safe to finish other pending work or wait between summary checks, because the settle notification arrives even if this task has gone idle. When it arrives, immediately fetch the verification outcome with `action: \"get_summary\"` and `action: \"get_messages\"` and continue the workflow from step 31.\n28. While waiting for that settle notification, check the verification task every 10-15 seconds with the Roomote MCP tool `mcp__roomote__manage_tasks` using `action: \"get_summary\"` and the returned `taskId` as a fallback signal. Use that per-task summary as the source of truth for task state, including any surfaced startup or runtime failure details and the `Environment Setup` line, which reports the ground-truth lifecycle of the verification task's environment setup commands: treat `still running in the background` as normal active startup rather than a stall, treat `failed` or `completed with warnings` as direct evidence that specific setup commands failed even when the verification task has not described the failure yet, and when `Environment Setup` is `completed` immediately inspect the latest task messages instead of sleeping for another long interval.\n29. Narrate concise, plain-language progress updates while the follow-up check runs, so the user can see that setup is still being checked without being asked to wait. Say what is being checked (for example, `I'm confirming the environment starts cleanly`) rather than mentioning a spawned task, task status, polling, or monitoring.\n30. Continue checking the verification task while the summary shows an active startup or running state, or until it clearly reports a startup or runtime blocker through the summary. Preparing the environment can take several minutes, so do not stop monitoring just because startup is taking a long time; keep checks frequent enough that a completed setup or completed verification is noticed promptly.\n31. If the monitored summary reaches `Completed` without a surfaced startup or runtime failure, treat that as a successful spawned-task run and report that observed outcome directly instead of asking the user to confirm it manually.\n32. If the monitored summary reaches `Ready`, `Idle`, or `Needs input`, do not keep polling that same state indefinitely. Inspect the latest task messages to determine whether the verification task already reported success, surfaced a blocker, or is unexpectedly waiting for follow-up input.\n33. If those latest task messages clearly report that the environment looks ready, treat that as a successful spawned-task run and report the observed success directly.\n34. If those latest task messages surface a startup or runtime blocker, request unexpected user input, or otherwise fail to give a clear success outcome, treat that as a blocker or verification failure instead of pretending the environment is verified.\n34a. The persisted environment metadata is the source of truth for the web UI's verification state, so you must record the verification outcome explicitly. Once you have a clear outcome, call the Roomote MCP tool `mcp__roomote__manage_environments` with `action: \"record_verification\"` and `environmentId` set to the created or updated environment id: use `success: true` only when the explicit \"environment looks ready\" criterion above is satisfied, and use `success: false` with a short, user-safe `error` message when verification reaches a terminal failure or cannot be completed. Never put secrets or the full environment YAML in the `error` text. You do not need to pass any task id; Roomote derives the recording task automatically.\n34b. If `record_verification` is rejected because a newer verification attempt or a runtime-affecting edit superseded this one, do not retry recording; treat this verification attempt as superseded and stop, since a newer attempt now owns the environment's verification state.\n35. If the settle notification or the monitored summary reports `Failed`, `Canceled`, a startup or runtime error, or an `Environment Setup` state of `failed` or `completed with warnings`, inspect the exact status and error — asking the verification task for the failing command names, exit codes, and log excerpts from `.roomote\u002Fsetup-status.json` and `.roomote\u002Fsetup-logs\u002F` when they are not already surfaced — and decide whether the problem appears fixable within environment-setup scope, such as revising commands, services, environment variables, startup order, readiness checks, or other environment-definition details.\n36. When the spawned verification task reveals a fixable setup or environment-definition error, try to fix it yourself, rerun any affected local validation, recreate or update the environment with the revised YAML, launch a fresh verification task, and repeat the monitoring process instead of stopping after the first failure.\n37. Treat each fix attempt as a real retry loop: revise based on the observed error, revalidate the affected setup steps, persist the updated environment again, relaunch the verification task with `notifyOnSettle: true`, and wait for the new settle notification rather than assuming the old failure is resolved.\n38. Keep this verification-repair loop bounded. Retry at most 2 additional full environment-update-plus-verification attempts after the first spawned verification task unless the task context explicitly justifies a smaller limit.\n39. If the observed verification error appears to require product or source-code changes outside environment-setup scope, missing external credentials, unsupported infrastructure, or another user decision you cannot safely make, report that blocker instead of pretending the environment can be repaired automatically.\n40. If the verification task remains in an active startup or running state without surfacing a blocker you can act on, keep monitoring instead of handing the waiting back to the user.\n41. If the environment was persisted but the follow-up check could not be completed, explain that readiness could not be confirmed and name the real blocker in user terms. Do not pretend the environment is ready.\n42. If full validation or environment persistence is blocked by missing dependencies, localhost reachability limits, permissions, unavailable environment APIs, or a required real service that still needs user guidance after local validation, keep the config minimal and report the blocker.\u003C\u002Faction>\n    \u003C\u002Factions>\n    \u003Cvalidation>The final config reflects observed install\u002Ftest\u002Fstart behavior where practical and clearly reports any validation limits.\u003C\u002Fvalidation>\n    \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n    \u003C\u002Fphase>\n\n  \u003Cphase name=\"reporting\">\n    \u003Cdescription>Give the user a clear, confidence-building handoff instead of exposing the setup machinery.\u003C\u002Fdescription>\n    \u003Csteps>\n      \u003Cstep number=\"5\">\n        \u003Ctitle>Produce a clear final handoff\u003C\u002Ftitle>\n        \u003Cdescription>Lead with what is ready, explain only the evidence that helps the user trust it, and make the next action obvious.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>When setup succeeds, begin with a plain-language outcome sentence such as `Your environment is ready.` Name the created or updated environment in that opening sentence when available.\u003C\u002Faction>\n          \u003Caction>Use short, natural headings only when they make the handoff easier to scan: `What I set up`, `What I checked`, and `What needs attention`. Do not use a heading just to satisfy a template, and omit `What needs attention` when there are no blockers.\u003C\u002Faction>\n          \u003Caction>Describe internal orchestration in user terms. Say that the environment was checked and is ready to use; do not refer to a `spawned verification task`, task IDs, polling, monitoring, or MCP tools in the visible response.\u003C\u002Faction>\n          \u003Caction>Keep assumptions and validation evidence concise and relevant to the user's confidence. Do not expose raw YAML, internal status labels, or implementation mechanics unless they directly explain a blocker.\u003C\u002Faction>\n          \u003Caction>When tests were detected, include whether tests were run, the command used, and pass\u002Ffail status (or why test execution was skipped).\u003C\u002Faction>\n          \u003Caction>When tests fail but are treated as non-blocking because they appear to be pre-existing repository issues outside environment-setup scope, say that explicitly and explain why environment persistence still proceeded.\u003C\u002Faction>\n          \u003Caction>Do not list every environment command mechanically. Summarize the checks that matter to the user, and include exact commands only when they help the user understand a failure or reproduce a needed action. A command that could not be confirmed must still be absent from the final environment definition or called out as a blocker.\u003C\u002Faction>\n          \u003Caction>When setup cannot finish, lead with what is blocked, why it matters, and the smallest concrete action the user can take. Do not bury the requested action in a generic `Next:` line.\u003C\u002Faction>\n          \u003Caction>When a browser-backed localhost surface is validated, say which localhost URL was checked and what loopback or startup evidence confirmed it under `What I checked`.\u003C\u002Faction>\n          \u003Caction>When environment persistence is attempted, include whether it succeeded and identify the created or updated environment if that information is available.\u003C\u002Faction>\n          \u003Caction>When environment persistence succeeds, report the user-meaningful result of the follow-up check: whether the environment was confirmed ready, whether repairs were needed, or what remains blocked. Do not expose the follow-up task ID or link.\u003C\u002Faction>\n          \u003Caction>When required environment variables or secrets are known but unavailable in a web dashboard task or Slack-started setup task, use `request_environment_variables` immediately instead of asking for the secret values in chat or waiting for a failure. In Slack-started setup tasks, still send a concise `send_chat_reply` message with `purpose` set to `progress` naming the keys and what they unblock, but let the platform provide the secure `\u002Fsetup` link automatically instead of composing that link yourself. In other surfaces, list each required key by exact name, indicate what it unblocks, and tell the user exactly what to add locally in the current task before continuing local validation.\u003C\u002Faction>\n          \u003Caction>When local validation is blocked, explicitly state that environment creation or update was intentionally not attempted.\u003C\u002Faction>\n          \u003Caction>At the end of a successful onboarding setup, always give the user one clear next action: `You're ready to put Roomote to work. [Create a new task](\u002F) and describe what you'd like done.` Use this exact relative link so it opens the new-task experience. This is the final visible paragraph; do not append an internal status summary after it.\u003C\u002Faction>\n          \u003Caction>Do not output alternative configs.\u003C\u002Faction>\n          \u003Caction>Best minimal config wins.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>The response is a concise, plain-language outcome summary without raw YAML. A successful onboarding ends with a direct link to create a task.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\n\u003Ccompletion_criteria>\n\u003Ccriterion>All included fields are supported by repository evidence or practical validation.\u003C\u002Fcriterion>\n\u003Ccriterion>Uncertain fields are omitted rather than guessed.\u003C\u002Fcriterion>\n\u003Ccriterion>Validation outcomes and blockers are reported explicitly.\u003C\u002Fcriterion>\n\u003Ccriterion>When a repository test suite is practical to run, it is executed and the result is reported explicitly. Test failures block environment creation when they indicate an environment-definition or setup problem; clearly pre-existing repository failures may be carried forward only when install\u002Fstart validation is otherwise sufficient.\u003C\u002Fcriterion>\n\u003Ccriterion>The final environment definition is best-effort and should be runnable once required environment variables are provided.\u003C\u002Fcriterion>\n\u003Ccriterion>Environment creation or update is attempted only after local install\u002Ftest\u002Fstart validation is successful enough to proceed.\u003C\u002Fcriterion>\n\u003Ccriterion>When environment persistence succeeds, a lightweight Roomote verification task is launched against that environment and monitored by calling the Roomote MCP tool `mcp__roomote__manage_tasks` with `action: \"get_summary\"` before this setup task finishes, unless an explicit blocker prevents launch or monitoring.\u003C\u002Fcriterion>\n\u003Ccriterion>The verification outcome is recorded through `mcp__roomote__manage_environments` with `action: \"record_verification\"` (`success: true` only when the environment explicitly looks ready, otherwise `success: false` with a user-safe error), unless a blocker prevents launch or monitoring or the recording is rejected as superseded.\u003C\u002Fcriterion>\n\u003Ccriterion>The final response summarizes the environment name, whether it was created or updated, key validation outcomes, and any blockers - without including the raw YAML config or internal orchestration details.\u003C\u002Fcriterion>\n\u003Ccriterion>A successful onboarding final response ends by telling the user that the environment is ready and linking `[Create a new task](\u002F)` as the clear next action.\u003C\u002Fcriterion>\n\u003Ccriterion>If the follow-up verification task reaches `Completed` without a surfaced startup or runtime failure, the final response reports that the environment is ready to use instead of asking the user to confirm it manually or describing the verification task.\u003C\u002Fcriterion>\n\u003Ccriterion>If the spawned verification task reveals a fixable setup or environment-definition error, the skill attempts to repair it, update the environment, relaunch verification, and report the final bounded retry outcome instead of stopping after the first failed verification task.\u003C\u002Fcriterion>\n\u003Ccriterion>If the app exposes a browser UI and local startup succeeds, the localhost URL is verified through loopback reachability or other non-browser startup evidence before persistence continues.\u003C\u002Fcriterion>\n\u003Ccriterion>If required environment variables or secrets are known but unavailable, the skill requests them immediately through `request_environment_variables` in web tasks and Slack-started setup tasks, or asks the user to set them locally in the current task before proceeding with affected validation.\u003C\u002Fcriterion>\n\u003Ccriterion>Every command present in the final `repositories[].commands` list was run and explicitly confirmed during validation, or an explicit blocker explains why validation could not proceed.\u003C\u002Fcriterion>\n\u003Ccriterion>No secrets, credentials, fabricated env values, or unsupported keys are introduced.\u003C\u002Fcriterion>\n\u003C\u002Fcompletion_criteria>\n\u003C\u002Fworkflow>\n\n\u003Cschema_reference>\n\u003Cnote>This schema lists the keys the environment definition may use. The validation scope above is narrower: runtime checks stay on localhost, while optional configuration fields still need repository evidence.\u003C\u002Fnote>\n\u003Ctop_level_fields>\n\u003Cfield name=\"name\" required=\"true\" type=\"string\" \u002F>\n\u003Cfield name=\"description\" required=\"false\" type=\"string\" \u002F>\n\u003Cfield name=\"initialUrl\" required=\"false\" type=\"absolute URL | about:blank\" \u002F>\n\u003Cfield name=\"agentInstructions\" required=\"false\" type=\"string\" \u002F>\n\u003Cfield name=\"repositories\" required=\"true\" type=\"RepositoryConfig[]\" min_items=\"1\" \u002F>\n\u003Cfield name=\"env\" required=\"false\" type=\"Record\u003Cstring, string>\" \u002F>\n\u003Cfield name=\"ports\" required=\"false\" type=\"NamedPort[]\" \u002F>\n\u003Cfield name=\"services\" required=\"false\" type=\"ServiceConfig[]\" \u002F>\n\u003Cfield name=\"docker_projects\" required=\"false\" type=\"DockerProject[]\" \u002F>\n\u003C\u002Ftop_level_fields>\n\n\u003Cdocker_project_config>\n\u003Cfield name=\"type\" required=\"true\" type=\"compose | dockerfile\" \u002F>\n\u003Cfield name=\"name\" required=\"true\" type=\"unique string starting with a letter\" \u002F>\n\u003Cfield name=\"repository\" required=\"true\" type=\"exact identifier from repositories[].repository\" \u002F>\n\u003Cfield name=\"working_dir\" required=\"false\" type=\"relative repository path\" \u002F>\n\u003Cfield name=\"env\" required=\"false\" type=\"Record\u003Cstring, string>\" \u002F>\n\u003Cfield name=\"ports\" required=\"false\" type=\"DockerProjectPort[]\" \u002F>\n\u003Cfield name=\"required\" required=\"false\" type=\"boolean (defaults true)\" \u002F>\n\u003Cfield name=\"startup_timeout_seconds\" required=\"false\" type=\"integer (1-3600)\" \u002F>\n\u003Ccompose_fields>\n\u003Cfield name=\"files\" required=\"true\" type=\"relative path[]\" min_items=\"1\" \u002F>\n\u003Cfield name=\"profiles\" required=\"false\" type=\"string[]\" \u002F>\n\u003Cfield name=\"services\" required=\"false\" type=\"string[]\" \u002F>\n\u003C\u002Fcompose_fields>\n\u003Cdockerfile_fields>\n\u003Cfield name=\"context\" required=\"false\" type=\"relative path (defaults .)\" \u002F>\n\u003Cfield name=\"dockerfile\" required=\"false\" type=\"relative path (defaults Dockerfile)\" \u002F>\n\u003Cfield name=\"target\" required=\"false\" type=\"string\" \u002F>\n\u003Cfield name=\"build_args\" required=\"false\" type=\"Record\u003Cstring, string>\" \u002F>\n\u003Cfield name=\"command\" required=\"false\" type=\"string[]\" \u002F>\n\u003C\u002Fdockerfile_fields>\n\u003C\u002Fdocker_project_config>\n\n\u003Cdocker_project_port>\n\u003Cfield name=\"named_port\" required=\"true\" type=\"name from the top-level ports list\" \u002F>\n\u003Cfield name=\"service\" required=\"for compose\" type=\"Compose service name\" \u002F>\n\u003Cfield name=\"container_port\" required=\"true\" type=\"integer (1-65535)\" \u002F>\n\u003C\u002Fdocker_project_port>\n\n\u003Cnamed_port_config>\n\u003Cnote>Each named port publishes a shareable live-preview URL for the environment and exposes a matching ROOMOTE host environment variable inside the sandbox (for example a port named WEB yields the `ROOMOTE_WEB_HOST` variable). Configure one entry per validated human-facing HTTP surface, particularly web app UIs.\u003C\u002Fnote>\n\u003Cfield name=\"name\" required=\"true\" type=\"string (short uppercase identifier such as WEB; letters, numbers, underscores)\" \u002F>\n\u003Cfield name=\"port\" required=\"true\" type=\"number (1024-65535)\" \u002F>\n\u003Cfield name=\"initial_path\" required=\"false\" type=\"URI path starting with \u002F\" \u002F>\n\u003Cfield name=\"primary\" required=\"false\" type=\"boolean\" \u002F>\n\u003C\u002Fnamed_port_config>\n\n\u003Crepository_config>\n\u003Cfield name=\"repository\" required=\"true\" type=\"exact task-provided slash-separated repository identifier (for example owner\u002Frepo or Azure DevOps organization\u002Fproject\u002Frepository)\" \u002F>\n\u003Cfield name=\"branch\" required=\"false\" type=\"string\" \u002F>\n\u003Cfield name=\"tool_versions\" required=\"false\" type=\"Record\u003Cstring, string>\" \u002F>\n\u003Cfield name=\"commands\" required=\"false\" type=\"Command[]\" \u002F>\n\u003C\u002Frepository_config>\n\n\u003Ccommand_config>\n\u003Cfield name=\"name\" required=\"true\" type=\"string\" \u002F>\n\u003Cfield name=\"run\" required=\"true\" type=\"string\" \u002F>\n\u003Cfield name=\"env\" required=\"false\" type=\"Record\u003Cstring, string>\" \u002F>\n\u003Cfield name=\"working_dir\" required=\"false\" type=\"string\" \u002F>\n\u003Cfield name=\"cwd\" required=\"false\" type=\"string\" \u002F>\n\u003Cfield name=\"timeout\" required=\"false\" type=\"number\" \u002F>\n\u003Cfield name=\"continue_on_error\" required=\"false\" type=\"boolean\" \u002F>\n\u003Cfield name=\"detached\" required=\"false\" type=\"boolean\" \u002F>\n\u003Cfield name=\"logfile\" required=\"false\" type=\"string\" \u002F>\n\u003C\u002Fcommand_config>\n\n\u003Callowed_services>\n\u003Cservice>redis6\u003C\u002Fservice>\n\u003Cservice>redis7\u003C\u002Fservice>\n\u003Cservice>postgres15\u003C\u002Fservice>\n\u003Cservice>postgres16\u003C\u002Fservice>\n\u003Cservice>postgres17\u003C\u002Fservice>\n\u003Cservice>mysql8\u003C\u002Fservice>\n\u003Cservice>mariadb10\u003C\u002Fservice>\n\u003Cservice>clickhouse\u003C\u002Fservice>\n\u003Cservice>aws\u003C\u002Fservice>\n\u003C\u002Fallowed_services>\n\n\u003C\u002Fschema_reference>\n\n\u003Chard_rules>\n\u003Crule>Before inspecting a target repository, discover and read the applicable repo-local `AGENTS.md` hierarchy from the repo root through the nearest ancestor, and re-check when moving into a subtree with its own guidance.\u003C\u002Frule>\n\u003Crule>Discover and read the applicable repo-local `CLAUDE.md` hierarchy from the repo root through the nearest ancestor too, treating `.claude\u002FCLAUDE.md` at the repo root as root-scoped guidance. Prefer the closest applicable repository guidance when files conflict, with `AGENTS.md` winning ties at the same scope. Treat both guidance formats as supplemental and subordinate to Roomote workflow, tool, safety, and direct user instructions.\u003C\u002Frule>\n\u003Crule>Check each target repo's developer local-setup documentation before inferring sandbox setup commands from manifests, scripts, or CI.\u003C\u002Frule>\n\u003Crule>When repo-local setup docs and lower-level evidence disagree, prefer the documented local developer workflow unless direct runtime validation proves the docs are stale or incomplete.\u003C\u002Frule>\n\u003Crule>Follow checked-in package-manager and toolchain policy, including package-manager declarations, engine requirements, `.npmrc`, `.yarnrc*`, pnpm configuration, `.tool-versions`, Mise config, language version files, and ecosystem equivalents, unless direct validation proves a specific setting stale or unusable. Translate only unambiguous exact versions with known Mise tool names into `tool_versions`; preserve ranges and unsupported descriptors as validation policy instead of copying them into Mise config. Never expose credentials or tokens from repository configuration.\u003C\u002Frule>\n\u003Crule>Treat repositories referenced by the task or environment as already checked out in the current workspace unless the user explicitly says otherwise.\u003C\u002Frule>\n\u003Crule>Preserve every task-provided repository identifier exactly in `repositories[].repository`; never shorten or reconstruct it from a checkout path. Azure DevOps identifiers must retain `organization\u002Fproject\u002Frepository`.\u003C\u002Frule>\n\u003Crule>Never include the full environment YAML in your visible response or Slack reply. The environment is already persisted through manage_environments; re-dumping the config into the transcript is redundant and risks exposing secret values that were kept out of the conversation through request_environment_variables.\u003C\u002Frule>\n\u003Crule>Use repository default branch unless strong evidence supports another branch.\u003C\u002Frule>\n\u003Crule>Include only commands strongly supported by repository evidence.\u003C\u002Frule>\n\u003Crule>Do not run `git clone`, ask the user to re-clone a repository that is already present, or include clone steps in `repositories[].commands`.\u003C\u002Frule>\n\u003Crule>Use `repositories[].commands` only for executing commands and setting configuration needed to validate the environment.\u003C\u002Frule>\n\u003Crule>If setup requires configuration or runtime file creation or modification, represent it with `repositories[].commands` entries instead of asking the user to edit files directly.\u003C\u002Frule>\n\u003Crule>Do not use `repositories[].commands` to write, generate, or patch application or source code; if source changes are required, report that as a blocker or separate follow-up work.\u003C\u002Frule>\n\u003Crule>When the target repository has no commits at all, bootstrap it with exactly one commit containing only `README.md` and `.gitignore` pushed to its default branch; never force-push, and never scaffold application code, frameworks, package manifests, or CI config during environment setup.\u003C\u002Frule>\n\u003Crule>For a just-bootstrapped repository, keep the environment definition minimal (typically the repository mapping with no commands, services, or ports) instead of inventing commands for application code that does not exist yet.\u003C\u002Frule>\n\u003Crule>Treat each `run` field as newline-split before execution. Do not rely on YAML multiline blocks to preserve shell control flow across lines.\u003C\u002Frule>\n\u003Crule>Do not emit YAML `run: |` blocks for `if ... fi`, `case`, loops, heredocs, or multiline shell functions unless the entire block is wrapped inside one explicit shell command such as `bash -lc '...'`.\u003C\u002Frule>\n\u003Crule>When setup logic needs conditional or multiline behavior, prefer multiple simple command entries or one explicit shell wrapper command over raw multiline shell fragments.\u003C\u002Frule>\n\u003Crule>Prefer runtime-only configuration file modifications outside the git repository when possible to avoid unstaged repo changes.\u003C\u002Frule>\n\u003Crule>Include only services clearly required by repository evidence.\u003C\u002Frule>\n\u003Crule>Use `docker_projects` only when a checked-in Compose project or Dockerfile is the evidence-backed development path, and validate the exact model before persistence.\u003C\u002Frule>\n\u003Crule>All Docker project paths must be relative and stay inside the selected configured repository.\u003C\u002Frule>\n\u003Crule>Include `tool_versions` only when clearly discoverable.\u003C\u002Frule>\n\u003Crule>When a repository exposes a browser UI or stable localhost landing page, set `initialUrl` to the best validated absolute URL unless `about:blank` is intentionally required.\u003C\u002Frule>\n\u003Crule>When a validated human-facing HTTP surface exists (particularly a web app UI), configure a matching top-level `ports` entry so the environment publishes a shareable preview URL for it; keep the `ports` list limited to validated human-facing surfaces and confirm each configured port number against the actual validated listening port.\u003C\u002Frule>\n\u003Crule>Always derive a best-effort environment definition that is ready to work once required environment variables are supplied.\u003C\u002Frule>\n\u003Crule>Treat `agentInstructions` as instructions for future agents running inside the created environment, not as setup progress notes or setup next-step guidance for this skill run.\u003C\u002Frule>\n\u003Crule>When the app exposes a browser UI, `agentInstructions` must explain how agents access it, including any authentication steps. Do not assume agents will discover auth flows, test credentials, or dev-mode conventions on their own.\u003C\u002Frule>\n\u003Crule>If a repository test suite exists, include a concrete test command in `agentInstructions` and state that the suite should pass before completing future code changes, even when setup validation reports a clearly pre-existing repo failure.\u003C\u002Frule>\n\u003Crule>If tests are practical to run during validation, execute the suite and treat failures as blockers when they indicate missing setup, broken environment definition, unavailable required services or secrets, or another environment-setup problem.\u003C\u002Frule>\n\u003Crule>Do not treat clearly pre-existing repository or unit-test failures as automatic blockers to environment creation when install\u002Fstart\u002Flocalhost validation succeeds and the failure appears outside environment-setup scope; report the exact failing command and keep the issue visible as a known repo problem.\u003C\u002Frule>\n\u003Crule>Every command added to `repositories[].commands` must be run during validation in config order unless an explicit blocker prevents it.\u003C\u002Frule>\n\u003Crule>Every command added to `repositories[].commands` must be explicitly confirmed from execution evidence appropriate to that command, such as exit status, log inspection, artifact creation, localhost reachability, or other command-appropriate runtime evidence.\u003C\u002Frule>\n\u003Crule>Do not depend on prompt-wide browser bootstrap or direct browser automation inside `environment-setup`; keep localhost validation in this skill to loopback reachability and startup evidence.\u003C\u002Frule>\n\u003Crule>If any configured command cannot be run or confirmed, remove it from the final environment definition or report the exact blocker; do not leave speculative or unverified commands in the final config.\u003C\u002Frule>\n\u003Crule>Do not replace required real services with mocks, stubs, fake servers, or no-op stand-ins merely to make validation appear successful.\u003C\u002Frule>\n\u003Crule>If repository evidence and supported worker tooling are still insufficient to get a required real service running, ask the user for help with that service before proceeding instead of inventing a fallback.\u003C\u002Frule>\n\u003Crule>If repository evidence or validation shows that required environment variables or secrets are needed, request them as soon as their names are known instead of waiting for a later command failure.\u003C\u002Frule>\n\u003Crule>If local install\u002Ftest\u002Fstart cannot run due to missing environment variables or secrets, do not create an environment until the missing variables are provided through `request_environment_variables` in web tasks and Slack-started setup tasks, or the user adds them locally and validation is retried.\u003C\u002Frule>\n\u003Crule>When required environment variables or secrets are known but unavailable in a web dashboard task or Slack-started setup task, use `request_environment_variables` and never ask the user to paste secret values into the conversation.\u003C\u002Frule>\n\u003Crule>In Slack-started setup tasks, send a concise `send_chat_reply` message with `purpose` set to `progress` naming the required keys and what they unblock, but do not include the secure `\u002Fsetup` link yourself because the platform automatically accompanies the request with that secure-entry link after `request_environment_variables` succeeds.\u003C\u002Frule>\n\u003Crule>In non-web surfaces, ask only for local environment variable additions in the current task, and provide exact variable names and exact actions.\u003C\u002Frule>\n\u003Crule>For this skill, create a new environment or update the specified existing environment only after localhost startup and loopback reachability are successful enough to proceed, including validation of `initialUrl` through non-browser evidence when the app exposes a browser UI.\u003C\u002Frule>\n\u003Crule>When the task explicitly identifies an existing environment to revise, update that environment instead of creating a duplicate.\u003C\u002Frule>\n\u003Crule>After successful environment persistence, use the Roomote MCP tool `mcp__roomote__manage_tasks` to launch a lightweight verification task against the created or updated environment and monitor it yourself instead of leaving verification as an implicit manual next step.\u003C\u002Frule>\n\u003Crule>Before launching that verification task, call the Roomote MCP tool `mcp__roomote__manage_tasks` with `action: \"list_environments\"` so the environment target is grounded in current Roomote data and you can copy the exact returned `environmentId`.\u003C\u002Frule>\n\u003Crule>When the verification task launch succeeds, monitor it every 10-15 seconds with the Roomote MCP tool `mcp__roomote__manage_tasks` using `action: \"get_summary\"` and use that per-task summary surface as the source of truth for task status and surfaced startup failures.\u003C\u002Frule>\n\u003Crule>While the follow-up check runs, narrate concise progress updates in plain language instead of silently waiting or pushing the waiting back onto the user. Do not mention a spawned task, task status, polling, or monitoring in those user-facing updates.\u003C\u002Frule>\n\u003Crule>Preparing the environment can take several minutes. Do not stop monitoring solely because the verification task is taking a long time to start; keep checking until it reaches a terminal state or surfaces a blocker you can report or act on, and keep checks frequent enough that a completed setup or completed verification is noticed promptly.\u003C\u002Frule>\n\u003Crule>If the monitored summary settles into `Ready`, `Idle`, or `Needs input`, inspect the latest task messages instead of polling that state forever, and only treat it as success when those messages clearly report that the environment looks ready.\u003C\u002Frule>\n\u003Crule>Record the verification outcome explicitly through the Roomote MCP tool `mcp__roomote__manage_environments` with `action: \"record_verification\"` and the created or updated `environmentId`: `success: true` only when the explicit \"environment looks ready\" criterion is satisfied, and `success: false` with a short, user-safe `error` when verification reaches a terminal failure or cannot be completed. Do not include secrets or the full environment YAML in the `error`, and do not pass a task id (Roomote derives the recording task from the current run).\u003C\u002Frule>\n\u003Crule>Treat a rejected `record_verification` result as a superseded attempt: do not retry recording, because a newer verification attempt or a runtime-affecting edit now owns the environment's verification state.\u003C\u002Frule>\n\u003Crule>If the spawned verification task surfaces a fixable setup or environment-definition problem, attempt to fix it yourself, recreate or update the environment, launch a fresh verification task, and repeat the monitoring loop instead of stopping after the first discovered error.\u003C\u002Frule>\n\u003Crule>Bound that environment-repair loop to at most 2 additional full retries after the first spawned verification task unless the task context clearly justifies fewer attempts.\u003C\u002Frule>\n\u003Crule>Do not claim automatic repair for failures that actually require product\u002Fsource changes outside environment-setup scope, unsupported infrastructure, missing external credentials, or a user decision you cannot safely infer; report those as blockers.\u003C\u002Frule>\n\u003Crule>Do not tell the user to verify the environment in that spawned task before clicking Continue, and do not include the spawned verification task link in the user-facing response; report the monitored outcome yourself.\u003C\u002Frule>\n\u003Crule>If the follow-up check cannot be launched or completed after the environment is persisted, report that readiness could not be confirmed and explain the real blocker in user terms; do not imply the environment is ready.\u003C\u002Frule>\n\u003Crule>When a browser UI is validated locally, report the exact localhost URL and the loopback or startup evidence that confirmed it rather than capturing screenshots from this skill.\u003C\u002Frule>\n\u003Crule>Any long-running service command (for example `dev`, `start`, `serve`, `preview`, or watchers) must use `detached: true`.\u003C\u002Frule>\n\u003Crule>Any command with `detached: true` must set `logfile` to capture runtime output.\u003C\u002Frule>\n\u003Crule>Do not encode `pm2 start`, `nohup`, shell trailing `&`, or another process supervisor in `run` for environment repository commands. Use the normal foreground command with `detached: true`; Roomote supervises it with PM2 and restarts it if it exits unexpectedly.\u003C\u002Frule>\n\u003Crule>Do not include unsupported keys.\u003C\u002Frule>\n\u003Crule>Do not fabricate `env` values.\u003C\u002Frule>\n\u003Crule>If secrets are required but unavailable, omit them and report the blocker.\u003C\u002Frule>\n\u003C\u002Fhard_rules>\n\n\u003Cexample_notes>\n\u003Cnote>Examples below show valid output YAML shapes, not extra validation obligations.\u003C\u002Fnote>\n\u003C\u002Fexample_notes>\n\n\u003Cexamples>\n  \u003Cexample name=\"full_stack_multi_repo\">\n    \u003Cyaml>\u003C![CDATA[\nname: Example Full Stack App\ndescription: Frontend and API running together\ninitialUrl: http:\u002F\u002F127.0.0.1:3000\nports:\n  - name: WEB\n    port: 3000\nagentInstructions: Run `npm test` before finalizing changes and only finish when the suite passes.\nrepositories:\n  - repository: myorg\u002Ffrontend\n    commands:\n      - name: Install\n        run: npm install\n      - name: Start frontend\n        run: npm run dev\n        detached: true\n        logfile: \u002Ftmp\u002Ffrontend.log\n  - repository: myorg\u002Fbackend\n    commands:\n      - name: Install\n        run: npm install\n      - name: Start backend\n        run: npm run dev\n        detached: true\n        logfile: \u002Ftmp\u002Fbackend.log\nservices:\n  - name: postgres16\n    port: 5433\n  - redis7\nenv:\n  NODE_ENV: development\n]]>\u003C\u002Fyaml>\n  \u003C\u002Fexample>\n\n  \u003Cexample name=\"custom_service_port\">\n    \u003Cyaml>\u003C![CDATA[\nname: Example App With Custom Postgres Port\n# No validated browser surface in this example, so no `ports` entry is configured.\nrepositories:\n  - repository: myorg\u002Fapp\n    commands:\n      - name: Install\n        run: npm install\n      - name: Start app\n        run: npm run dev\n        detached: true\n        logfile: \u002Ftmp\u002Fapp.log\nservices:\n  - name: postgres16\n    port: 5433\n]]>\u003C\u002Fyaml>\n  \u003C\u002Fexample>\n\n  \u003Cexample name=\"build_time_env_injection\">\n    \u003Cyaml>\u003C![CDATA[\nname: Example Static Frontend with Build Env\ninitialUrl: http:\u002F\u002F127.0.0.1:4173\nports:\n  - name: WEB\n    port: 4173\nrepositories:\n  - repository: myorg\u002Ffrontend\n    commands:\n      - name: Install\n        run: npm install\n      - name: Build\n        run: npm run build\n        env:\n          VITE_API_URL: ${API_URL}\n      - name: Start preview\n        run: npm run preview\n        detached: true\n        logfile: \u002Ftmp\u002Ffrontend-preview.log\n  - repository: myorg\u002Fbackend\n    commands:\n      - name: Install\n        run: npm install\n      - name: Start API\n        run: npm run dev\n        detached: true\n        logfile: \u002Ftmp\u002Fbackend.log\n]]>\u003C\u002Fyaml>\n  \u003C\u002Fexample>\n\n  \u003Cexample name=\"admin_app\">\n    \u003Cyaml>\u003C![CDATA[\nname: Example Admin App\ninitialUrl: http:\u002F\u002F127.0.0.1:3000\u002Fadmin\nports:\n  - name: WEB\n    port: 3000\n    initial_path: \u002Fadmin\nrepositories:\n  - repository: myorg\u002Fadmin-app\n    commands:\n      - name: Install\n        run: npm install\n      - name: Start\n        run: npm run dev\n        detached: true\n        logfile: \u002Ftmp\u002Fadmin.log\n]]>\u003C\u002Fyaml>\n  \u003C\u002Fexample>\n\n  \u003Cexample name=\"webhook_service\">\n    \u003Cyaml>\u003C![CDATA[\nname: Example Webhook Service\nrepositories:\n  - repository: myorg\u002Fwebhook-service\n    commands:\n      - name: Install\n        run: npm install\n      - name: Start\n        run: npm run dev\n        detached: true\n        logfile: \u002Ftmp\u002Fwebhook.log\n]]>\u003C\u002Fyaml>\n  \u003C\u002Fexample>\n\n  \u003Cexample name=\"metrics_service\">\n    \u003Cyaml>\u003C![CDATA[\nname: Example Metrics Service\nrepositories:\n  - repository: myorg\u002Fmetrics-app\n    commands:\n      - name: Install\n        run: npm install\n      - name: Start app\n        run: npm run dev\n        detached: true\n        logfile: \u002Ftmp\u002Fapp.log\n      - name: Start metrics\n        run: npm run metrics\n        detached: true\n        logfile: \u002Ftmp\u002Fmetrics.log\n]]>\u003C\u002Fyaml>\n  \u003C\u002Fexample>\n\u003C\u002Fexamples>\n\n\u003Cbest_practices>\n\u003Cguideline priority=\"high\">\n\u003Crule>Treat examples as patterns, not templates to copy blindly.\u003C\u002Frule>\n\u003Crationale>Repository-specific evidence should determine final fields.\u003C\u002Frationale>\n\u003C\u002Fguideline>\n\u003Cguideline priority=\"high\">\n\u003Crule>Prefer the smallest config that matches the repository's real workflow.\u003C\u002Frule>\n\u003Crationale>Minimal configs are easier to run, validate, and maintain.\u003C\u002Frationale>\n\u003C\u002Fguideline>\n\u003Cguideline priority=\"high\">\n\u003Crule>Prefer command-driven setup over manual repo edits.\u003C\u002Frule>\n\u003Crationale>Encoding file writes in `commands` keeps setup reproducible and avoids asking the user for avoidable code changes.\u003C\u002Frationale>\n\u003C\u002Fguideline>\n\u003Cguideline priority=\"high\">\n\u003Crule>Prefer one-line `run` commands.\u003C\u002Frule>\n\u003Crationale>The executor splits `run` on literal newlines, so one-line commands or explicit shell wrappers are much less error-prone than YAML block-scalar shell scripts.\u003C\u002Frationale>\n\u003C\u002Fguideline>\n\u003Cguideline priority=\"high\">\n\u003Crule>Prefer runtime-only files outside the git repo.\u003C\u002Frule>\n\u003Crationale>Writing temporary setup files to locations like `\u002Ftmp` reduces repository noise and prevents unexpected unstaged changes.\u003C\u002Frationale>\n\u003C\u002Fguideline>\n\u003C\u002Fbest_practices>\n\n\u003Cpatterns>\n  \u003Cpattern name=\"single_service_minimal\">\n    \u003Cdescription>Use for repositories that expose one clear runtime surface.\u003C\u002Fdescription>\n    \u003Ctemplate>one repository -> install command -> one start command -> set `initialUrl` and a matching `ports` entry when there is a browser landing page -> no extra services unless required\u003C\u002Ftemplate>\n  \u003C\u002Fpattern>\n  \u003Cpattern name=\"monorepo_selective\">\n    \u003Cdescription>Use for monorepos where only a subset of apps are needed for the requested environment.\u003C\u002Fdescription>\n    \u003Ctemplate>include only relevant repositories\u002Fapps -> include only required commands\u002Fservices -> omit optional surfaces without evidence\u003C\u002Ftemplate>\n  \u003C\u002Fpattern>\n\u003C\u002Fpatterns>\n\n\u003Cerror_handling>\n\u003Cscenario name=\"missing_or_ambiguous_evidence\">\n\u003Cproblem>Repository evidence does not clearly support a field.\u003C\u002Fproblem>\n\u003Crecovery>Omit the field and document the uncertainty in `Assumptions` or `Blockers` instead of guessing.\u003C\u002Frecovery>\n\u003C\u002Fscenario>\n\u003Cscenario name=\"validation_blocked_by_secrets_or_external_dependencies\">\n\u003Cproblem>Install or startup cannot complete due to unavailable secrets, credentials, or external systems.\u003C\u002Fproblem>\n\u003Crecovery>Keep the config minimal, report exactly what blocked validation, and avoid fabricated env values.\u003C\u002Frecovery>\n\u003C\u002Fscenario>\n\u003Cscenario name=\"browser_surface_validation_blocked\">\n\u003Cproblem>The app starts locally, but the expected localhost URL cannot be confirmed through loopback reachability or other non-browser startup evidence.\u003C\u002Fproblem>\n\u003Crecovery>Report the blocker explicitly, include any successful loopback checks you did perform, and do not claim browser-surface validation succeeded.\u003C\u002Frecovery>\n\u003C\u002Fscenario>\n\u003Cscenario name=\"environment_creation_failed\">\n\u003Cproblem>Local validation succeeded, but creating the environment failed.\u003C\u002Fproblem>\n\u003Crecovery>Report the exact creation error, revise the YAML if the failure reveals a concrete config issue, and retry within the normal retry budget.\u003C\u002Frecovery>\n\u003C\u002Fscenario>\n\u003Cscenario name=\"local_setup_blocked_by_missing_env_vars\">\n\u003Cproblem>Local install, test, or startup fails because required environment variables or secrets are missing.\u003C\u002Fproblem>\n\u003Crecovery>Keep the YAML best-effort, stop at the blocked local validation step, ask the user to add exact keys locally in the current task, then rerun blocked validation steps after confirmation.\u003C\u002Frecovery>\n\u003C\u002Fscenario>\n\u003Cscenario name=\"preexisting_repo_test_failure\">\n\u003Cproblem>The canonical test command fails, but the failure appears to come from the repository's current test state rather than the drafted environment definition.\u003C\u002Fproblem>\n\u003Crecovery>Record the exact failing command, explain why the failure appears outside environment-setup scope, keep the test command in `agentInstructions`, and continue with environment persistence only when install\u002Fstart\u002Flocalhost validation is otherwise sufficient.\u003C\u002Frecovery>\n\u003C\u002Fscenario>\n\u003Cscenario name=\"setup_requires_code_changes\">\n\u003Cproblem>Setup cannot succeed via environment variables or setup changes encoded in generated environment config commands (including command-driven runtime file creation).\u003C\u002Fproblem>\n\u003Crecovery>Ask for the minimal user code change only as a last resort, and explain why `commands`-based setup and non-repo file options were insufficient.\u003C\u002Frecovery>\n\u003C\u002Fscenario>\n\u003C\u002Ferror_handling>\n",{"data":32,"body":33},{"name":4,"description":6},{"type":34,"children":35},"root",[36,44],{"type":37,"tag":38,"props":39,"children":40},"element","role",{},[41],{"type":42,"value":43},"text","\nYou are an expert Roomote environment analyst. Analyze the already-checked-out repository contents available in the current workspace, derive one minimal Roomote environment configuration for Roomote's environment editor and `manage_environments`, and validate it with scope limited to getting the app running on localhost.\n",{"type":37,"tag":45,"props":46,"children":47},"workflow",{},[48,50,56,57,77,78,182,183],{"type":42,"value":49},"\n  ",{"type":37,"tag":51,"props":52,"children":53},"overview",{},[54],{"type":42,"value":55},"Inspect repository evidence, infer the smallest correct Roomote environment config, validate install\u002Ftest\u002Fstart behavior locally on localhost when practical, create or update the environment when validation is sufficient, launch one lightweight verification task against the resulting environment, monitor that spawned task through the Roomote task summary surface while narrating concise progress updates, and when verification surfaces fixable setup errors, revise the environment and repeat the create-or-update plus verification cycle before returning a concise final outcome summary with explicit assumptions, validated observations, and blockers.",{"type":42,"value":49},{"type":37,"tag":58,"props":59,"children":60},"scope",{},[61,63,69,70,76],{"type":42,"value":62},"\n    ",{"type":37,"tag":64,"props":65,"children":66},"goal",{},[67],{"type":42,"value":68},"Produce one environment definition that is valid for the Roomote environment editor.",{"type":42,"value":62},{"type":37,"tag":71,"props":72,"children":73},"validation_scope",{},[74],{"type":42,"value":75},"Validate only local install, test, start, and localhost reachability.",{"type":42,"value":49},{"type":42,"value":49},{"type":37,"tag":79,"props":80,"children":82},"phase",{"name":81},"analysis",[83,84,90,91],{"type":42,"value":62},{"type":37,"tag":85,"props":86,"children":87},"description",{},[88],{"type":42,"value":89},"Gather repository truth and avoid assumptions before drafting the config.",{"type":42,"value":62},{"type":37,"tag":92,"props":93,"children":94},"steps",{},[95,97,168,181],{"type":42,"value":96},"\n      ",{"type":37,"tag":98,"props":99,"children":101},"step",{"number":100},"1",[102,104,110,111,116,117,160,161,167],{"type":42,"value":103},"\n        ",{"type":37,"tag":105,"props":106,"children":107},"title",{},[108],{"type":42,"value":109},"Confirm target repository context",{"type":42,"value":103},{"type":37,"tag":85,"props":112,"children":113},{},[114],{"type":42,"value":115},"Anchor analysis to explicit repository facts provided by the task.",{"type":42,"value":103},{"type":37,"tag":118,"props":119,"children":120},"actions",{},[121,123,129,130,135,136,141,142,159],{"type":42,"value":122},"\n          ",{"type":37,"tag":124,"props":125,"children":126},"action",{},[127],{"type":42,"value":128},"Use each provided repository identifier exactly as supplied by the task. Do not shorten, reconstruct, or infer it from the checkout directory. Repository identifiers may have more than two slash-separated segments; Azure DevOps uses `organization\u002Fproject\u002Frepository`.",{"type":42,"value":122},{"type":37,"tag":124,"props":131,"children":132},{},[133],{"type":42,"value":134},"If default branch is unknown, infer it from repository metadata; otherwise use the provided value.",{"type":42,"value":122},{"type":37,"tag":124,"props":137,"children":138},{},[139],{"type":42,"value":140},"Treat the repositories named in the task or environment as already checked out and available in the current workspace; inspect and validate those existing checkouts instead of re-cloning them.",{"type":42,"value":122},{"type":37,"tag":124,"props":143,"children":144},{},[145,147],{"type":42,"value":146},"Treat repository context as:\n- Repository: `",{"type":37,"tag":148,"props":149,"children":150},"exact-provided-repository-identifier",{},[151,153],{"type":42,"value":152},"`\n- Default branch: `",{"type":37,"tag":154,"props":155,"children":156},"default-branch",{},[157],{"type":42,"value":158},"`",{"type":42,"value":103},{"type":42,"value":103},{"type":37,"tag":162,"props":163,"children":164},"validation",{},[165],{"type":42,"value":166},"The repository target and branch baseline are explicit before config drafting starts.",{"type":42,"value":96},{"type":37,"tag":169,"props":170,"children":174},"pre",{"className":171,"code":173,"language":42},[172],"language-text","  \u003Cstep number=\"1a\">\n    \u003Ctitle>Bootstrap an empty repository before analysis\u003C\u002Ftitle>\n    \u003Cdescription>A brand-new repository with no commits (for example one just created on github.com) cannot be analyzed or validated until it has an initial commit. Give it the smallest possible bootstrap, then continue normally.\u003C\u002Fdescription>\n    \u003Cactions>\n      \u003Caction>Detect emptiness from the checked-out workspace: `git log --oneline -1` failing (unborn HEAD) together with an effectively empty worktree means the repository has no commits yet. If the repository has any commits, skip this step entirely and continue with normal analysis.\u003C\u002Faction>\n      \u003Caction>When the repository is empty, create exactly one bootstrap commit containing only a `README.md` (the repository name as a title plus a line noting that Roomote initialized the repository) and a minimal general-purpose `.gitignore`. Do not scaffold application code, frameworks, package manifests, CI config, or anything beyond those two files; building the actual project is the user's next task, not part of environment setup.\u003C\u002Faction>\n      \u003Caction>Commit directly to the branch the workspace is already on (the unborn branch was already pointed at the repository's stored default branch) and push it with `git push -u origin \u003Cdefault-branch>`. Never force-push.\u003C\u002Faction>\n      \u003Caction>If the push is rejected because commits appeared on the remote in the meantime, discard the bootstrap commit, fetch, check out the remote default branch, and continue as a normal non-empty repository.\u003C\u002Faction>\n      \u003Caction>After the bootstrap push succeeds, continue the normal workflow against the now-initialized repository and expect the resulting environment definition to be minimal: typically the repository mapping alone with no commands, services, docker projects, or ports, because there is no application to install, test, or start yet. Do not invent install, dev, or test commands for code that does not exist.\u003C\u002Faction>\n      \u003Caction>When launching the follow-up verification task for such a minimal environment, adapt the verification prompt to what actually exists: it should confirm the workspace clones and environment setup completes cleanly, not expect a running service, test suite, or localhost surface.\u003C\u002Faction>\n      \u003Caction>In `agentInstructions`, note that the repository was newly initialized by Roomote and contains no application code yet.\u003C\u002Faction>\n      \u003Caction>In the final handoff, say that the repository was brand new, that Roomote pushed the initial commit, and that the user's next task can start building the actual project.\u003C\u002Faction>\n    \u003C\u002Factions>\n    \u003Cvalidation>An empty repository receives exactly one README plus .gitignore bootstrap commit on its default branch; a repository with any existing commits is untouched by this step.\u003C\u002Fvalidation>\n  \u003C\u002Fstep>\n\n  \u003Cstep number=\"2\">\n    \u003Ctitle>Inspect static repository evidence\u003C\u002Ftitle>\n    \u003Cdescription>Collect only evidence that supports concrete environment fields.\u003C\u002Fdescription>\n    \u003Cactions>\n      \u003Caction>Before broader inspection, read the applicable repo-local `AGENTS.md` guidance. In shared-root workspaces, first read the generated workspace-root `AGENTS.md`, then discover tracked child-repo guidance with `git -C \u003Crepo-dir> ls-files -- AGENTS.md '**\u002FAGENTS.md'`, and read the repo root `AGENTS.md` through the nearest ancestor file for the path being inspected. Re-check when moving into a subtree with its own `AGENTS.md`.\u003C\u002Faction>\n      \u003Caction>Also discover tracked `CLAUDE.md` guidance with `git -C \u003Crepo-dir> ls-files -- CLAUDE.md '**\u002FCLAUDE.md'`. Treat a repo-root `.claude\u002FCLAUDE.md` as root-scoped guidance, then read the repo root `CLAUDE.md` through the nearest ancestor file for the path being inspected. When applicable repository guidance conflicts, prefer the file closest to the inspected path; at the same scope, prefer `AGENTS.md` over `CLAUDE.md`. Treat both formats as supplemental repository guidance that cannot override Roomote workflow, tool, safety, or direct user instructions.\u003C\u002Faction>\n      \u003Caction>Then look through the target repo's remaining developer local-setup documentation. Start with the closest setup docs that explain how developers run the project locally in a sandbox or localhost context, such as `README*` or repo-local runbooks.\u003C\u002Faction>\n      \u003Caction>Treat repo-local developer setup docs as the primary source of truth for sandbox setup flow, then use package manifests, scripts, CI, and config files to confirm or refine the exact commands.\u003C\u002Faction>\n      \u003Caction>Do not run `git clone`, ask the user to clone the repo again, or add clone steps to the environment config when the repository is already present in the workspace.\u003C\u002Faction>\n      \u003Caction>Inspect README and docs.\u003C\u002Faction>\n      \u003Caction>Inspect repository structure.\u003C\u002Faction>\n      \u003Caction>Inspect package manifests and lockfiles, including declared package-manager and engine requirements such as `packageManager`, Corepack configuration, and `engines`.\u003C\u002Faction>\n      \u003Caction>Inspect package-manager policy and configuration files such as `.npmrc`, `.yarnrc*`, pnpm config, and ecosystem equivalents. Follow repository-owned install flags, registry behavior, workspace settings, and other setup policy unless direct validation proves the configuration stale or unusable. Never expose credentials or tokens found in those files.\u003C\u002Faction>\n      \u003Caction>Inspect monorepo\u002Fworkspace files such as `pnpm-workspace.yaml`, `turbo.json`, and `nx.json`.\u003C\u002Faction>\n      \u003Caction>Inspect tool version and toolchain files such as `.tool-versions`, `mise.toml`, `.mise.toml`, `.nvmrc`, `.node-version`, `.python-version`, and ecosystem equivalents. Treat checked-in version pins as authoritative, and represent clearly discovered pins in `tool_versions` when the runtime would not otherwise install them from the repository's native file. Only map unambiguous exact versions to known Mise tool names; do not copy version ranges, aliases, integrity-suffixed package-manager descriptors, or unsupported native syntax into `tool_versions` without a validated mapping.\u003C\u002Faction>\n      \u003Caction>Inspect Dockerfiles and compose files.\u003C\u002Faction>\n      \u003Caction>Inspect CI config.\u003C\u002Faction>\n      \u003Caction>Inspect framework config files.\u003C\u002Faction>\n      \u003Caction>Inspect the canonical environment config schema or types (for example `packages\u002Ftypes\u002Fsrc\u002Fenvironment-config.ts`) before using optional keys.\u003C\u002Faction>\n      \u003Caction>Inspect scripts for install, dev, build, preview, test, serve, and start.\u003C\u002Faction>\n      \u003Caction>When the repo needs infrastructure beyond what is already available, remember that the worker CLI can provision supported services on demand: run `worker services` to see the full list and `worker service \u003Cname>` to install and start one service.\u003C\u002Faction>\n      \u003Caction>Do not invent mocked, stubbed, or fake replacement services just to get the app booting. If repository evidence and supported worker tooling still do not reveal how to run a required real service, stop and ask the user for help with that service.\u003C\u002Faction>\n      \u003Caction>Identify the canonical test-suite command and any required wrappers (for example `dotenvx`, package filter, or workspace command) when tests exist.\u003C\u002Faction>\n      \u003Caction>Inspect environment examples such as `.env.example` and `.env.local.example`.\u003C\u002Faction>\n      \u003Caction>Prefer correctness and evidence over completeness.\u003C\u002Faction>\n      \u003Caction>Omit uncertain fields rather than guessing.\u003C\u002Faction>\n    \u003C\u002Factions>\n    \u003Cvalidation>The applicable `AGENTS.md` and `CLAUDE.md` hierarchies and developer local-setup docs were checked first, codified package-manager and toolchain configuration was followed, and every planned config field has concrete repository evidence or is intentionally omitted.\u003C\u002Fvalidation>\n  \u003C\u002Fstep>\n\u003C\u002Fsteps>\n",[175],{"type":37,"tag":176,"props":177,"children":179},"code",{"__ignoreMap":178},"",[180],{"type":42,"value":173},{"type":42,"value":49},{"type":42,"value":49},{"type":37,"tag":79,"props":184,"children":186},{"name":185},"implementation",[187,188,193,194],{"type":42,"value":62},{"type":37,"tag":85,"props":189,"children":190},{},[191],{"type":42,"value":192},"Draft and refine a minimal config that reflects repository reality.",{"type":42,"value":62},{"type":37,"tag":92,"props":195,"children":196},{},[197,198,406,415,1106,1107,1248,1406,1460,1542,1565,1602,1626,1666,1718,1723,2559,2571,2637,2741,2783],{"type":42,"value":96},{"type":37,"tag":98,"props":199,"children":201},{"number":200},"3",[202,203,208,209,214,215,399,400,405],{"type":42,"value":103},{"type":37,"tag":105,"props":204,"children":205},{},[206],{"type":42,"value":207},"Draft a minimal initial config",{"type":42,"value":103},{"type":37,"tag":85,"props":210,"children":211},{},[212],{"type":42,"value":213},"Create the smallest valid Roomote environment YAML from static evidence.",{"type":42,"value":103},{"type":37,"tag":118,"props":216,"children":217},{},[218,219,224,225,230,231,236,237,242,243,248,249,254,255,260,261,266,267,272,273,278,279,284,285,290,291,296,297,302,303,308,309,314,315,320,321,326,327,332,333,338,339,350,351,356,357,362,363,368,369,374,375,380,381,386,387,392,393,398],{"type":42,"value":122},{"type":37,"tag":124,"props":220,"children":221},{},[222],{"type":42,"value":223},"Produce exactly one initial YAML config.",{"type":42,"value":122},{"type":37,"tag":124,"props":226,"children":227},{},[228],{"type":42,"value":229},"Copy each task-provided repository identifier verbatim into its matching `repositories[].repository` field. In particular, preserve all three `organization\u002Fproject\u002Frepository` segments for Azure DevOps repositories.",{"type":42,"value":122},{"type":37,"tag":124,"props":232,"children":233},{},[234],{"type":42,"value":235},"Use repository default branch unless strong evidence indicates a different branch.",{"type":42,"value":122},{"type":37,"tag":124,"props":238,"children":239},{},[240],{"type":42,"value":241},"Assume the repositories listed in the environment already exist in the workspace; do not add repository clone commands or other duplicate checkout steps.",{"type":42,"value":122},{"type":37,"tag":124,"props":244,"children":245},{},[246],{"type":42,"value":247},"Include only commands strongly supported by the repository.",{"type":42,"value":122},{"type":37,"tag":124,"props":250,"children":251},{},[252],{"type":42,"value":253},"Use `repositories[].commands` only for executing commands and setting configuration needed to validate the environment.",{"type":42,"value":122},{"type":37,"tag":124,"props":256,"children":257},{},[258],{"type":42,"value":259},"If setup needs to create or modify configuration or runtime files, model that work as explicit entries in `repositories[].commands`.",{"type":42,"value":122},{"type":37,"tag":124,"props":262,"children":263},{},[264],{"type":42,"value":265},"Do not use `repositories[].commands` to write, generate, or patch application or source code; if source changes are required, report that as a blocker or a separate follow-up change instead of encoding it into the environment config.",{"type":42,"value":122},{"type":37,"tag":124,"props":268,"children":269},{},[270],{"type":42,"value":271},"Treat each `run` value as a sequence of single-line shell commands: the executor splits on literal newlines before invoking bash, so YAML block scalars containing shell control structures such as `if ... fi`, `case`, loops, heredocs, or multiline functions will be broken apart and usually fail.",{"type":42,"value":122},{"type":37,"tag":124,"props":274,"children":275},{},[276],{"type":42,"value":277},"When command logic truly needs shell control flow, either express it as separate independent `commands` entries or wrap the whole block as one explicit shell invocation such as `bash -lc 'if [ ! -f .env ]; then cp .env.example .env; ruby -e \\\"...\\\"; fi'`.",{"type":42,"value":122},{"type":37,"tag":124,"props":280,"children":281},{},[282],{"type":42,"value":283},"Prefer short one-line `run` commands with `&&` or `||` for simple sequencing, and avoid YAML `run: |` blocks unless every physical line is intentionally a standalone command that can succeed on its own.",{"type":42,"value":122},{"type":37,"tag":124,"props":286,"children":287},{},[288],{"type":42,"value":289},"When runtime-only configuration file changes are needed, prefer paths outside the git repo (for example `\u002Ftmp` or `$HOME`) to avoid leaving unstaged repository changes.",{"type":42,"value":122},{"type":37,"tag":124,"props":292,"children":293},{},[294],{"type":42,"value":295},"Every command added to `repositories[].commands` must be intended to be run during validation; do not include speculative, placeholder, or convenience commands that you do not plan to execute and confirm.",{"type":42,"value":122},{"type":37,"tag":124,"props":298,"children":299},{},[300],{"type":42,"value":301},"For long-running service commands (for example `dev`, `start`, `serve`, `preview`, watchers), set `detached: true` and include a `logfile` path.",{"type":42,"value":122},{"type":37,"tag":124,"props":304,"children":305},{},[306],{"type":42,"value":307},"Do not wrap long-running commands in `pm2 start` yourself. Roomote runs environment repository commands marked `detached: true` under PM2 supervision, so the `run` value should be the foreground command the app normally uses.",{"type":42,"value":122},{"type":37,"tag":124,"props":310,"children":311},{},[312],{"type":42,"value":313},"Include only services clearly required by the repository.",{"type":42,"value":122},{"type":37,"tag":124,"props":316,"children":317},{},[318],{"type":42,"value":319},"When a checked-in Docker Compose project or Dockerfile is the repository's supported development startup path, prefer a top-level `docker_projects` entry over translating its containers into Roomote-managed `services` or detached repository commands. Reference the exact task-provided repository identifier and only relative paths that stay inside that repository.",{"type":42,"value":122},{"type":37,"tag":124,"props":322,"children":323},{},[324],{"type":42,"value":325},"For Compose, include the smallest evidence-backed `files`, `profiles`, and `services` selection. For a single Dockerfile, include evidence-backed `context`, `dockerfile`, `target`, `build_args`, and `command` values. Do not copy secrets or literal credentials from Compose files into the environment definition.",{"type":42,"value":122},{"type":37,"tag":124,"props":328,"children":329},{},[330],{"type":42,"value":331},"Include `tool_versions` only when clearly discoverable.",{"type":42,"value":122},{"type":37,"tag":124,"props":334,"children":335},{},[336],{"type":42,"value":337},"When the repository exposes a browser UI or a stable localhost landing page, populate `initialUrl` with the best validated absolute URL so the shared live browser does not start at `about:blank`.",{"type":42,"value":122},{"type":37,"tag":124,"props":340,"children":341},{},[342,344],{"type":42,"value":343},"When a validated localhost HTTP surface is meant for humans in a browser (particularly a web app UI), also add a matching top-level `ports` entry so Roomote publishes a shareable preview URL and a `ROOMOTE_",{"type":37,"tag":345,"props":346,"children":347},"name",{},[348],{"type":42,"value":349},"_HOST` environment variable for it: use a short uppercase `name` such as `WEB`, set `port` to the validated listening port (named ports must fall in the 1024-65535 range), set `initial_path` when a specific landing path is better than `\u002F`, and mark the main surface `primary: true` when more than one port is configured.",{"type":42,"value":122},{"type":37,"tag":124,"props":352,"children":353},{},[354],{"type":42,"value":355},"Keep the `ports` list limited to human-facing surfaces validated during setup; do not add ports for databases, background workers, or internal-only APIs that no human would open in a browser.",{"type":42,"value":122},{"type":37,"tag":124,"props":358,"children":359},{},[360],{"type":42,"value":361},"Do not invent secrets, credentials, env values, or unsupported keys.",{"type":42,"value":122},{"type":37,"tag":124,"props":364,"children":365},{},[366],{"type":42,"value":367},"Choose a plain, stable environment `name` based on the product or repository itself. Do not decorate it with qualifiers like `Localhost`, `Minimal`, `Dev`, or similar unless the user explicitly asked for multiple distinct variants.",{"type":42,"value":122},{"type":37,"tag":124,"props":370,"children":371},{},[372],{"type":42,"value":373},"When repository evidence makes required environment keys clear but values are unavailable, request them immediately instead of waiting for a command to fail: in web dashboard tasks and Slack-started setup tasks, use `request_environment_variables`; for Slack-started setup tasks, still send a concise `send_chat_reply` message with `purpose` set to `progress` naming the required keys and what they unblock, but do not add the secure `\u002Fsetup` link yourself because the platform automatically accompanies that request with a standardized secure-entry link reply; in other surfaces, ask the user to add them locally in the current task. Keep the YAML best-effort and ready for user-provided values (for example `${KEY}` placeholders when appropriate), without guessing secret values.",{"type":42,"value":122},{"type":37,"tag":124,"props":376,"children":377},{},[378],{"type":42,"value":379},"Keep `agentInstructions` short, practical, and repository-specific for agents that will run inside the created environment.",{"type":42,"value":122},{"type":37,"tag":124,"props":382,"children":383},{},[384],{"type":42,"value":385},"Do not use `agentInstructions` to narrate setup progress, list current setup next steps, or hand off unresolved setup work for this skill execution.",{"type":42,"value":122},{"type":37,"tag":124,"props":388,"children":389},{},[390],{"type":42,"value":391},"If a test suite exists, include a concrete test command in `agentInstructions` and state that the suite should pass before completing code changes, even when setup validation reports a clearly pre-existing repo test failure.",{"type":42,"value":122},{"type":37,"tag":124,"props":394,"children":395},{},[396],{"type":42,"value":397},"Discover how agents should access the app in a browser and document the full entry path in `agentInstructions`. Investigate: whether authentication is required, what credentials or bypass mechanisms work in dev\u002Ftest mode, what the landing page is after login, and any test-mode conventions for third-party auth providers. Agents running inside this environment will use `agentInstructions` as their only guide for browser access, so the instructions must be specific enough that an agent can navigate from the initial URL to an authenticated app surface without prior knowledge of the product.",{"type":42,"value":103},{"type":42,"value":103},{"type":37,"tag":162,"props":401,"children":402},{},[403],{"type":42,"value":404},"The initial config is minimal, valid, and evidence-backed.",{"type":42,"value":96},{"type":37,"tag":169,"props":407,"children":410},{"className":408,"code":409,"language":42},[172],"  \u003Cstep number=\"4\">\n    \u003Ctitle>Run practical validation when feasible\u003C\u002Ftitle>\n    \u003Cdescription>Use runtime evidence to confirm install\u002Fstart assumptions without over-expanding scope. Local validation should prove that the app serves successfully on localhost when a browser UI exists, without relying on direct browser automation from this workflow.\u003C\u002Fdescription>\n    \u003Cactions>\n      \u003Caction>Run validation workflow in order:\n",[411],{"type":37,"tag":176,"props":412,"children":413},{"__ignoreMap":178},[414],{"type":42,"value":409},{"type":37,"tag":416,"props":417,"children":418},"ol",{},[419,425,430,443,448,461,466,471,484,512,565,570,575,580,593,637,642,647,652,657,662,667,672,677,682,710,758,803,876,889,894,907,934,939,1004,1059,1064,1076,1081,1086,1091,1096],{"type":37,"tag":420,"props":421,"children":422},"li",{},[423],{"type":42,"value":424},"Inspect the repository statically.",{"type":37,"tag":420,"props":426,"children":427},{},[428],{"type":42,"value":429},"Draft the initial config.",{"type":37,"tag":420,"props":431,"children":432},{},[433,435,441],{"type":42,"value":434},"For every command added to ",{"type":37,"tag":176,"props":436,"children":438},{"className":437},[],[439],{"type":42,"value":440},"repositories[].commands",{"type":42,"value":442},", run that exact command in config order when practical instead of validating only a representative subset.",{"type":37,"tag":420,"props":444,"children":445},{},[446],{"type":42,"value":447},"For each command you run, confirm the result immediately from exit status, stdout\u002Fstderr, created artifacts, log output, readiness checks, localhost reachability, or other command-appropriate runtime evidence.",{"type":37,"tag":420,"props":449,"children":450},{},[451,453,459],{"type":42,"value":452},"For detached commands, confirm both that the process launched and that its ",{"type":37,"tag":176,"props":454,"children":456},{"className":455},[],[457],{"type":42,"value":458},"logfile",{"type":42,"value":460}," or readiness check shows the expected service actually started.",{"type":37,"tag":420,"props":462,"children":463},{},[464],{"type":42,"value":465},"If a test suite exists and is practical to run, execute the canonical test command.",{"type":37,"tag":420,"props":467,"children":468},{},[469],{"type":42,"value":470},"Treat that test result as a blocker when it points to missing setup, broken environment definition, unavailable required services or secrets, or another problem that environment-setup can fix or that prevents local startup from being trusted.",{"type":37,"tag":420,"props":472,"children":473},{},[474,476,482],{"type":42,"value":475},"When the test failure instead appears to be a clearly pre-existing repository or unit-test failure outside environment-setup scope, record the exact command and failure, keep the suite referenced in ",{"type":37,"tag":176,"props":477,"children":479},{"className":478},[],[480],{"type":42,"value":481},"agentInstructions",{"type":42,"value":483},", and continue only if install\u002Fstart\u002Flocalhost validation is otherwise sufficient.",{"type":37,"tag":420,"props":485,"children":486},{},[487,489,495,497,503,505,510],{"type":42,"value":488},"If the app exposes an HTTP UI, set ",{"type":37,"tag":176,"props":490,"children":492},{"className":491},[],[493],{"type":42,"value":494},"initialUrl",{"type":42,"value":496}," to the best validated absolute localhost URL (or keep ",{"type":37,"tag":176,"props":498,"children":500},{"className":499},[],[501],{"type":42,"value":502},"about:blank",{"type":42,"value":504}," only when no better landing page exists), confirm that localhost URL through loopback HTTP reachability and startup evidence, and record the exact URL plus the evidence used. Do not use direct browser automation from ",{"type":37,"tag":176,"props":506,"children":508},{"className":507},[],[509],{"type":42,"value":4},{"type":42,"value":511},".",{"type":37,"tag":420,"props":513,"children":514},{},[515,517,523,525,531,533,539,541,547,549,555,557,563],{"type":42,"value":516},"When the config includes a ",{"type":37,"tag":176,"props":518,"children":520},{"className":519},[],[521],{"type":42,"value":522},"ports",{"type":42,"value":524}," entry for a validated HTTP surface, confirm its ",{"type":37,"tag":176,"props":526,"children":528},{"className":527},[],[529],{"type":42,"value":530},"port",{"type":42,"value":532}," number matches the actual validated listening port and that any ",{"type":37,"tag":176,"props":534,"children":536},{"className":535},[],[537],{"type":42,"value":538},"initial_path",{"type":42,"value":540}," responds successfully over loopback.\n10a. When the config includes ",{"type":37,"tag":176,"props":542,"children":544},{"className":543},[],[545],{"type":42,"value":546},"docker_projects",{"type":42,"value":548},", run ",{"type":37,"tag":176,"props":550,"children":552},{"className":551},[],[553],{"type":42,"value":554},"docker compose config --quiet",{"type":42,"value":556}," against the selected files or an equivalent generated one-service Compose model, start the selected services, wait for readiness, and confirm mapped HTTP ports over loopback. Capture ",{"type":37,"tag":176,"props":558,"children":560},{"className":559},[],[561],{"type":42,"value":562},"docker compose ps --all",{"type":42,"value":564}," and recent service logs when startup fails.",{"type":37,"tag":420,"props":566,"children":567},{},[568],{"type":42,"value":569},"If the app exposes only an HTTP API or a non-browser surface, verify localhost reachability using loopback addresses only.",{"type":37,"tag":420,"props":571,"children":572},{},[573],{"type":42,"value":574},"If any command in the draft config fails or cannot be confirmed, either revise or remove that command from the YAML, or report the exact blocker; do not leave unrun or unconfirmed commands in the final config.",{"type":37,"tag":420,"props":576,"children":577},{},[578],{"type":42,"value":579},"As soon as repository evidence or early validation makes it clear that specific environment variables or secrets will be required and values are unavailable, request them immediately instead of waiting for a later failure.",{"type":37,"tag":420,"props":581,"children":582},{},[583,585,591],{"type":42,"value":584},"In web dashboard tasks and Slack-started setup tasks, use ",{"type":37,"tag":176,"props":586,"children":588},{"className":587},[],[589],{"type":42,"value":590},"request_environment_variables",{"type":42,"value":592}," to request the needed keys securely instead of asking the user to paste secret values into the conversation.",{"type":37,"tag":420,"props":594,"children":595},{},[596,598,604,606,612,614,620,622,628,630,635],{"type":42,"value":597},"In Slack-started setup tasks, send a concise ",{"type":37,"tag":176,"props":599,"children":601},{"className":600},[],[602],{"type":42,"value":603},"send_chat_reply",{"type":42,"value":605}," update with ",{"type":37,"tag":176,"props":607,"children":609},{"className":608},[],[610],{"type":42,"value":611},"purpose",{"type":42,"value":613}," set to ",{"type":37,"tag":176,"props":615,"children":617},{"className":616},[],[618],{"type":42,"value":619},"progress",{"type":42,"value":621}," that names the required keys and explains what they unblock, but do not include the secure ",{"type":37,"tag":176,"props":623,"children":625},{"className":624},[],[626],{"type":42,"value":627},"\u002Fsetup",{"type":42,"value":629}," link yourself because the platform automatically accompanies the request with that secure-entry link after ",{"type":37,"tag":176,"props":631,"children":633},{"className":632},[],[634],{"type":42,"value":590},{"type":42,"value":636}," succeeds.",{"type":37,"tag":420,"props":638,"children":639},{},[640],{"type":42,"value":641},"In non-web surfaces where that tool is unavailable, ask the user to add the missing environment variables locally in the current running task, including exact variable names, what command each one blocks, and exact actions to set them.",{"type":37,"tag":420,"props":643,"children":644},{},[645],{"type":42,"value":646},"If a required real service still cannot be installed, started, or connected after checking repository evidence and supported worker tooling, ask the user for help with that service instead of substituting a mocked or fake service.",{"type":37,"tag":420,"props":648,"children":649},{},[650],{"type":42,"value":651},"If local install\u002Ftest\u002Fstart validation is blocked by missing environment variables or secrets, do not create an environment yet.",{"type":37,"tag":420,"props":653,"children":654},{},[655],{"type":42,"value":656},"Keep the drafted YAML best-effort and revise it so it will work once those variables are provided, without fabricating values.",{"type":37,"tag":420,"props":658,"children":659},{},[660],{"type":42,"value":661},"After the user confirms variables were added locally or provides guidance for the blocked real service, rerun the blocked or otherwise affected local validation steps and re-confirm every affected command.",{"type":37,"tag":420,"props":663,"children":664},{},[665],{"type":42,"value":666},"Revise the config based on actual observations, using runtime evidence for startup details.",{"type":37,"tag":420,"props":668,"children":669},{},[670],{"type":42,"value":671},"Only after local install\u002Ftest\u002Fstart works (or is otherwise sufficiently validated), persist the drafted YAML by creating a new environment or updating the specified existing environment, depending on the task context.",{"type":37,"tag":420,"props":673,"children":674},{},[675],{"type":42,"value":676},"If environment persistence fails because the YAML still needs adjustment, revise the config based on the failure and retry at most 2 times.",{"type":37,"tag":420,"props":678,"children":679},{},[680],{"type":42,"value":681},"After environment persistence succeeds, use the Roomote MCP task tools to launch one lightweight follow-up verification task against that environment before finishing this setup task.",{"type":37,"tag":420,"props":683,"children":684},{},[685,687,693,695,701,703,709],{"type":42,"value":686},"For that follow-up task launch, call the Roomote MCP tool ",{"type":37,"tag":176,"props":688,"children":690},{"className":689},[],[691],{"type":42,"value":692},"mcp__roomote__manage_tasks",{"type":42,"value":694}," with ",{"type":37,"tag":176,"props":696,"children":698},{"className":697},[],[699],{"type":42,"value":700},"action: \"list_environments\"",{"type":42,"value":702}," first so you can confirm the created or updated environment appears as a current launch target and copy the exact returned ",{"type":37,"tag":176,"props":704,"children":706},{"className":705},[],[707],{"type":42,"value":708},"environmentId",{"type":42,"value":511},{"type":37,"tag":420,"props":711,"children":712},{},[713,715,720,721,727,729,734,736,742,743,749,751,757],{"type":42,"value":714},"Then call the Roomote MCP tool ",{"type":37,"tag":176,"props":716,"children":718},{"className":717},[],[719],{"type":42,"value":692},{"type":42,"value":694},{"type":37,"tag":176,"props":722,"children":724},{"className":723},[],[725],{"type":42,"value":726},"action: \"launch\"",{"type":42,"value":728},", ",{"type":37,"tag":176,"props":730,"children":732},{"className":731},[],[733],{"type":42,"value":708},{"type":42,"value":735}," set to that created or updated environment ID, ",{"type":37,"tag":176,"props":737,"children":739},{"className":738},[],[740],{"type":42,"value":741},"notifyOnSettle",{"type":42,"value":613},{"type":37,"tag":176,"props":744,"children":746},{"className":745},[],[747],{"type":42,"value":748},"true",{"type":42,"value":750},", and a concrete prompt such as ",{"type":37,"tag":176,"props":752,"children":754},{"className":753},[],[755],{"type":42,"value":756},"Confirm that this environment is running correctly. First read .roomote\u002Fsetup-status.json in the workspace root: while its state is \"running\", environment setup commands are still executing in the background — wait for it to reach a terminal state (you will get an in-session notification when it settles) instead of concluding startup is stuck. Re-read .roomote\u002Fsetup-status.json every 10-15 seconds while it is still running, rather than sleeping for several minutes at a time. Once setup has settled, use localhost or the environment's initial URL to verify the expected service responds successfully and confirm there are no obvious startup failures blocking basic use. If any setup command failed, report each failing command's name and exit code from .roomote\u002Fsetup-status.json plus the relevant error lines from .roomote\u002Fsetup-logs\u002F. Report the exact step that fails plus any visible error messages or logs. If everything works, say that the environment looks ready.",{"type":42,"value":511},{"type":37,"tag":420,"props":759,"children":760},{},[761,763,769,771,777,779,785,787,793,795,801],{"type":42,"value":762},"Keep the returned ",{"type":37,"tag":176,"props":764,"children":766},{"className":765},[],[767],{"type":42,"value":768},"taskId",{"type":42,"value":770}," for internal monitoring only. Do not expose the spawned verification task link in the user-facing response.\n27a. Because the launch used ",{"type":37,"tag":176,"props":772,"children":774},{"className":773},[],[775],{"type":42,"value":776},"notifyOnSettle: true",{"type":42,"value":778},", the platform delivers a ",{"type":37,"tag":176,"props":780,"children":782},{"className":781},[],[783],{"type":42,"value":784},"Spawned task update",{"type":42,"value":786}," message into this session when the verification task settles (completes, fails, is canceled, or goes idle after reporting). Treat that message as the primary completion signal: it is safe to finish other pending work or wait between summary checks, because the settle notification arrives even if this task has gone idle. When it arrives, immediately fetch the verification outcome with ",{"type":37,"tag":176,"props":788,"children":790},{"className":789},[],[791],{"type":42,"value":792},"action: \"get_summary\"",{"type":42,"value":794}," and ",{"type":37,"tag":176,"props":796,"children":798},{"className":797},[],[799],{"type":42,"value":800},"action: \"get_messages\"",{"type":42,"value":802}," and continue the workflow from step 31.",{"type":37,"tag":420,"props":804,"children":805},{},[806,808,813,815,820,822,827,829,835,837,843,845,851,853,859,861,866,868,874],{"type":42,"value":807},"While waiting for that settle notification, check the verification task every 10-15 seconds with the Roomote MCP tool ",{"type":37,"tag":176,"props":809,"children":811},{"className":810},[],[812],{"type":42,"value":692},{"type":42,"value":814}," using ",{"type":37,"tag":176,"props":816,"children":818},{"className":817},[],[819],{"type":42,"value":792},{"type":42,"value":821}," and the returned ",{"type":37,"tag":176,"props":823,"children":825},{"className":824},[],[826],{"type":42,"value":768},{"type":42,"value":828}," as a fallback signal. Use that per-task summary as the source of truth for task state, including any surfaced startup or runtime failure details and the ",{"type":37,"tag":176,"props":830,"children":832},{"className":831},[],[833],{"type":42,"value":834},"Environment Setup",{"type":42,"value":836}," line, which reports the ground-truth lifecycle of the verification task's environment setup commands: treat ",{"type":37,"tag":176,"props":838,"children":840},{"className":839},[],[841],{"type":42,"value":842},"still running in the background",{"type":42,"value":844}," as normal active startup rather than a stall, treat ",{"type":37,"tag":176,"props":846,"children":848},{"className":847},[],[849],{"type":42,"value":850},"failed",{"type":42,"value":852}," or ",{"type":37,"tag":176,"props":854,"children":856},{"className":855},[],[857],{"type":42,"value":858},"completed with warnings",{"type":42,"value":860}," as direct evidence that specific setup commands failed even when the verification task has not described the failure yet, and when ",{"type":37,"tag":176,"props":862,"children":864},{"className":863},[],[865],{"type":42,"value":834},{"type":42,"value":867}," is ",{"type":37,"tag":176,"props":869,"children":871},{"className":870},[],[872],{"type":42,"value":873},"completed",{"type":42,"value":875}," immediately inspect the latest task messages instead of sleeping for another long interval.",{"type":37,"tag":420,"props":877,"children":878},{},[879,881,887],{"type":42,"value":880},"Narrate concise, plain-language progress updates while the follow-up check runs, so the user can see that setup is still being checked without being asked to wait. Say what is being checked (for example, ",{"type":37,"tag":176,"props":882,"children":884},{"className":883},[],[885],{"type":42,"value":886},"I'm confirming the environment starts cleanly",{"type":42,"value":888},") rather than mentioning a spawned task, task status, polling, or monitoring.",{"type":37,"tag":420,"props":890,"children":891},{},[892],{"type":42,"value":893},"Continue checking the verification task while the summary shows an active startup or running state, or until it clearly reports a startup or runtime blocker through the summary. Preparing the environment can take several minutes, so do not stop monitoring just because startup is taking a long time; keep checks frequent enough that a completed setup or completed verification is noticed promptly.",{"type":37,"tag":420,"props":895,"children":896},{},[897,899,905],{"type":42,"value":898},"If the monitored summary reaches ",{"type":37,"tag":176,"props":900,"children":902},{"className":901},[],[903],{"type":42,"value":904},"Completed",{"type":42,"value":906}," without a surfaced startup or runtime failure, treat that as a successful spawned-task run and report that observed outcome directly instead of asking the user to confirm it manually.",{"type":37,"tag":420,"props":908,"children":909},{},[910,911,917,918,924,926,932],{"type":42,"value":898},{"type":37,"tag":176,"props":912,"children":914},{"className":913},[],[915],{"type":42,"value":916},"Ready",{"type":42,"value":728},{"type":37,"tag":176,"props":919,"children":921},{"className":920},[],[922],{"type":42,"value":923},"Idle",{"type":42,"value":925},", or ",{"type":37,"tag":176,"props":927,"children":929},{"className":928},[],[930],{"type":42,"value":931},"Needs input",{"type":42,"value":933},", do not keep polling that same state indefinitely. Inspect the latest task messages to determine whether the verification task already reported success, surfaced a blocker, or is unexpectedly waiting for follow-up input.",{"type":37,"tag":420,"props":935,"children":936},{},[937],{"type":42,"value":938},"If those latest task messages clearly report that the environment looks ready, treat that as a successful spawned-task run and report the observed success directly.",{"type":37,"tag":420,"props":940,"children":941},{},[942,944,950,951,957,958,963,965,971,973,979,981,987,989,994,996,1002],{"type":42,"value":943},"If those latest task messages surface a startup or runtime blocker, request unexpected user input, or otherwise fail to give a clear success outcome, treat that as a blocker or verification failure instead of pretending the environment is verified.\n34a. The persisted environment metadata is the source of truth for the web UI's verification state, so you must record the verification outcome explicitly. Once you have a clear outcome, call the Roomote MCP tool ",{"type":37,"tag":176,"props":945,"children":947},{"className":946},[],[948],{"type":42,"value":949},"mcp__roomote__manage_environments",{"type":42,"value":694},{"type":37,"tag":176,"props":952,"children":954},{"className":953},[],[955],{"type":42,"value":956},"action: \"record_verification\"",{"type":42,"value":794},{"type":37,"tag":176,"props":959,"children":961},{"className":960},[],[962],{"type":42,"value":708},{"type":42,"value":964}," set to the created or updated environment id: use ",{"type":37,"tag":176,"props":966,"children":968},{"className":967},[],[969],{"type":42,"value":970},"success: true",{"type":42,"value":972}," only when the explicit \"environment looks ready\" criterion above is satisfied, and use ",{"type":37,"tag":176,"props":974,"children":976},{"className":975},[],[977],{"type":42,"value":978},"success: false",{"type":42,"value":980}," with a short, user-safe ",{"type":37,"tag":176,"props":982,"children":984},{"className":983},[],[985],{"type":42,"value":986},"error",{"type":42,"value":988}," message when verification reaches a terminal failure or cannot be completed. Never put secrets or the full environment YAML in the ",{"type":37,"tag":176,"props":990,"children":992},{"className":991},[],[993],{"type":42,"value":986},{"type":42,"value":995}," text. You do not need to pass any task id; Roomote derives the recording task automatically.\n34b. If ",{"type":37,"tag":176,"props":997,"children":999},{"className":998},[],[1000],{"type":42,"value":1001},"record_verification",{"type":42,"value":1003}," is rejected because a newer verification attempt or a runtime-affecting edit superseded this one, do not retry recording; treat this verification attempt as superseded and stop, since a newer attempt now owns the environment's verification state.",{"type":37,"tag":420,"props":1005,"children":1006},{},[1007,1009,1015,1016,1022,1024,1029,1031,1036,1037,1042,1044,1050,1051,1057],{"type":42,"value":1008},"If the settle notification or the monitored summary reports ",{"type":37,"tag":176,"props":1010,"children":1012},{"className":1011},[],[1013],{"type":42,"value":1014},"Failed",{"type":42,"value":728},{"type":37,"tag":176,"props":1017,"children":1019},{"className":1018},[],[1020],{"type":42,"value":1021},"Canceled",{"type":42,"value":1023},", a startup or runtime error, or an ",{"type":37,"tag":176,"props":1025,"children":1027},{"className":1026},[],[1028],{"type":42,"value":834},{"type":42,"value":1030}," state of ",{"type":37,"tag":176,"props":1032,"children":1034},{"className":1033},[],[1035],{"type":42,"value":850},{"type":42,"value":852},{"type":37,"tag":176,"props":1038,"children":1040},{"className":1039},[],[1041],{"type":42,"value":858},{"type":42,"value":1043},", inspect the exact status and error — asking the verification task for the failing command names, exit codes, and log excerpts from ",{"type":37,"tag":176,"props":1045,"children":1047},{"className":1046},[],[1048],{"type":42,"value":1049},".roomote\u002Fsetup-status.json",{"type":42,"value":794},{"type":37,"tag":176,"props":1052,"children":1054},{"className":1053},[],[1055],{"type":42,"value":1056},".roomote\u002Fsetup-logs\u002F",{"type":42,"value":1058}," when they are not already surfaced — and decide whether the problem appears fixable within environment-setup scope, such as revising commands, services, environment variables, startup order, readiness checks, or other environment-definition details.",{"type":37,"tag":420,"props":1060,"children":1061},{},[1062],{"type":42,"value":1063},"When the spawned verification task reveals a fixable setup or environment-definition error, try to fix it yourself, rerun any affected local validation, recreate or update the environment with the revised YAML, launch a fresh verification task, and repeat the monitoring process instead of stopping after the first failure.",{"type":37,"tag":420,"props":1065,"children":1066},{},[1067,1069,1074],{"type":42,"value":1068},"Treat each fix attempt as a real retry loop: revise based on the observed error, revalidate the affected setup steps, persist the updated environment again, relaunch the verification task with ",{"type":37,"tag":176,"props":1070,"children":1072},{"className":1071},[],[1073],{"type":42,"value":776},{"type":42,"value":1075},", and wait for the new settle notification rather than assuming the old failure is resolved.",{"type":37,"tag":420,"props":1077,"children":1078},{},[1079],{"type":42,"value":1080},"Keep this verification-repair loop bounded. Retry at most 2 additional full environment-update-plus-verification attempts after the first spawned verification task unless the task context explicitly justifies a smaller limit.",{"type":37,"tag":420,"props":1082,"children":1083},{},[1084],{"type":42,"value":1085},"If the observed verification error appears to require product or source-code changes outside environment-setup scope, missing external credentials, unsupported infrastructure, or another user decision you cannot safely make, report that blocker instead of pretending the environment can be repaired automatically.",{"type":37,"tag":420,"props":1087,"children":1088},{},[1089],{"type":42,"value":1090},"If the verification task remains in an active startup or running state without surfacing a blocker you can act on, keep monitoring instead of handing the waiting back to the user.",{"type":37,"tag":420,"props":1092,"children":1093},{},[1094],{"type":42,"value":1095},"If the environment was persisted but the follow-up check could not be completed, explain that readiness could not be confirmed and name the real blocker in user terms. Do not pretend the environment is ready.",{"type":37,"tag":420,"props":1097,"children":1098},{},[1099,1101],{"type":42,"value":1100},"If full validation or environment persistence is blocked by missing dependencies, localhost reachability limits, permissions, unavailable environment APIs, or a required real service that still needs user guidance after local validation, keep the config minimal and report the blocker.\n\n",{"type":37,"tag":162,"props":1102,"children":1103},{},[1104],{"type":42,"value":1105},"The final config reflects observed install\u002Ftest\u002Fstart behavior where practical and clearly reports any validation limits.",{"type":42,"value":49},{"type":37,"tag":79,"props":1108,"children":1110},{"name":1109},"reporting",[1111,1112,1117,1118,1247],{"type":42,"value":62},{"type":37,"tag":85,"props":1113,"children":1114},{},[1115],{"type":42,"value":1116},"Give the user a clear, confidence-building handoff instead of exposing the setup machinery.",{"type":42,"value":62},{"type":37,"tag":92,"props":1119,"children":1120},{},[1121,1122,1246],{"type":42,"value":96},{"type":37,"tag":98,"props":1123,"children":1125},{"number":1124},"5",[1126,1127,1132,1133,1138,1139,1239,1240,1245],{"type":42,"value":103},{"type":37,"tag":105,"props":1128,"children":1129},{},[1130],{"type":42,"value":1131},"Produce a clear final handoff",{"type":42,"value":103},{"type":37,"tag":85,"props":1134,"children":1135},{},[1136],{"type":42,"value":1137},"Lead with what is ready, explain only the evidence that helps the user trust it, and make the next action obvious.",{"type":42,"value":103},{"type":37,"tag":118,"props":1140,"children":1141},{},[1142,1143,1148,1149,1154,1155,1160,1161,1166,1167,1172,1173,1178,1179,1184,1185,1190,1191,1196,1197,1202,1203,1208,1209,1214,1215,1220,1221,1226,1227,1232,1233,1238],{"type":42,"value":122},{"type":37,"tag":124,"props":1144,"children":1145},{},[1146],{"type":42,"value":1147},"When setup succeeds, begin with a plain-language outcome sentence such as `Your environment is ready.` Name the created or updated environment in that opening sentence when available.",{"type":42,"value":122},{"type":37,"tag":124,"props":1150,"children":1151},{},[1152],{"type":42,"value":1153},"Use short, natural headings only when they make the handoff easier to scan: `What I set up`, `What I checked`, and `What needs attention`. Do not use a heading just to satisfy a template, and omit `What needs attention` when there are no blockers.",{"type":42,"value":122},{"type":37,"tag":124,"props":1156,"children":1157},{},[1158],{"type":42,"value":1159},"Describe internal orchestration in user terms. Say that the environment was checked and is ready to use; do not refer to a `spawned verification task`, task IDs, polling, monitoring, or MCP tools in the visible response.",{"type":42,"value":122},{"type":37,"tag":124,"props":1162,"children":1163},{},[1164],{"type":42,"value":1165},"Keep assumptions and validation evidence concise and relevant to the user's confidence. Do not expose raw YAML, internal status labels, or implementation mechanics unless they directly explain a blocker.",{"type":42,"value":122},{"type":37,"tag":124,"props":1168,"children":1169},{},[1170],{"type":42,"value":1171},"When tests were detected, include whether tests were run, the command used, and pass\u002Ffail status (or why test execution was skipped).",{"type":42,"value":122},{"type":37,"tag":124,"props":1174,"children":1175},{},[1176],{"type":42,"value":1177},"When tests fail but are treated as non-blocking because they appear to be pre-existing repository issues outside environment-setup scope, say that explicitly and explain why environment persistence still proceeded.",{"type":42,"value":122},{"type":37,"tag":124,"props":1180,"children":1181},{},[1182],{"type":42,"value":1183},"Do not list every environment command mechanically. Summarize the checks that matter to the user, and include exact commands only when they help the user understand a failure or reproduce a needed action. A command that could not be confirmed must still be absent from the final environment definition or called out as a blocker.",{"type":42,"value":122},{"type":37,"tag":124,"props":1186,"children":1187},{},[1188],{"type":42,"value":1189},"When setup cannot finish, lead with what is blocked, why it matters, and the smallest concrete action the user can take. Do not bury the requested action in a generic `Next:` line.",{"type":42,"value":122},{"type":37,"tag":124,"props":1192,"children":1193},{},[1194],{"type":42,"value":1195},"When a browser-backed localhost surface is validated, say which localhost URL was checked and what loopback or startup evidence confirmed it under `What I checked`.",{"type":42,"value":122},{"type":37,"tag":124,"props":1198,"children":1199},{},[1200],{"type":42,"value":1201},"When environment persistence is attempted, include whether it succeeded and identify the created or updated environment if that information is available.",{"type":42,"value":122},{"type":37,"tag":124,"props":1204,"children":1205},{},[1206],{"type":42,"value":1207},"When environment persistence succeeds, report the user-meaningful result of the follow-up check: whether the environment was confirmed ready, whether repairs were needed, or what remains blocked. Do not expose the follow-up task ID or link.",{"type":42,"value":122},{"type":37,"tag":124,"props":1210,"children":1211},{},[1212],{"type":42,"value":1213},"When required environment variables or secrets are known but unavailable in a web dashboard task or Slack-started setup task, use `request_environment_variables` immediately instead of asking for the secret values in chat or waiting for a failure. In Slack-started setup tasks, still send a concise `send_chat_reply` message with `purpose` set to `progress` naming the keys and what they unblock, but let the platform provide the secure `\u002Fsetup` link automatically instead of composing that link yourself. In other surfaces, list each required key by exact name, indicate what it unblocks, and tell the user exactly what to add locally in the current task before continuing local validation.",{"type":42,"value":122},{"type":37,"tag":124,"props":1216,"children":1217},{},[1218],{"type":42,"value":1219},"When local validation is blocked, explicitly state that environment creation or update was intentionally not attempted.",{"type":42,"value":122},{"type":37,"tag":124,"props":1222,"children":1223},{},[1224],{"type":42,"value":1225},"At the end of a successful onboarding setup, always give the user one clear next action: `You're ready to put Roomote to work. [Create a new task](\u002F) and describe what you'd like done.` Use this exact relative link so it opens the new-task experience. This is the final visible paragraph; do not append an internal status summary after it.",{"type":42,"value":122},{"type":37,"tag":124,"props":1228,"children":1229},{},[1230],{"type":42,"value":1231},"Do not output alternative configs.",{"type":42,"value":122},{"type":37,"tag":124,"props":1234,"children":1235},{},[1236],{"type":42,"value":1237},"Best minimal config wins.",{"type":42,"value":103},{"type":42,"value":103},{"type":37,"tag":162,"props":1241,"children":1242},{},[1243],{"type":42,"value":1244},"The response is a concise, plain-language outcome summary without raw YAML. A successful onboarding ends with a direct link to create a task.",{"type":42,"value":96},{"type":42,"value":62},{"type":42,"value":49},{"type":37,"tag":1249,"props":1250,"children":1251},"p",{},[1252,1254,1260,1265,1270,1275,1280,1285,1303,1335,1340,1353,1365,1370,1375,1387,1399,1404],{"type":42,"value":1253},"\u003Ccompletion_criteria>\n",{"type":37,"tag":1255,"props":1256,"children":1257},"criterion",{},[1258],{"type":42,"value":1259},"All included fields are supported by repository evidence or practical validation.",{"type":37,"tag":1255,"props":1261,"children":1262},{},[1263],{"type":42,"value":1264},"Uncertain fields are omitted rather than guessed.",{"type":37,"tag":1255,"props":1266,"children":1267},{},[1268],{"type":42,"value":1269},"Validation outcomes and blockers are reported explicitly.",{"type":37,"tag":1255,"props":1271,"children":1272},{},[1273],{"type":42,"value":1274},"When a repository test suite is practical to run, it is executed and the result is reported explicitly. Test failures block environment creation when they indicate an environment-definition or setup problem; clearly pre-existing repository failures may be carried forward only when install\u002Fstart validation is otherwise sufficient.",{"type":37,"tag":1255,"props":1276,"children":1277},{},[1278],{"type":42,"value":1279},"The final environment definition is best-effort and should be runnable once required environment variables are provided.",{"type":37,"tag":1255,"props":1281,"children":1282},{},[1283],{"type":42,"value":1284},"Environment creation or update is attempted only after local install\u002Ftest\u002Fstart validation is successful enough to proceed.",{"type":37,"tag":1255,"props":1286,"children":1287},{},[1288,1290,1295,1296,1301],{"type":42,"value":1289},"When environment persistence succeeds, a lightweight Roomote verification task is launched against that environment and monitored by calling the Roomote MCP tool ",{"type":37,"tag":176,"props":1291,"children":1293},{"className":1292},[],[1294],{"type":42,"value":692},{"type":42,"value":694},{"type":37,"tag":176,"props":1297,"children":1299},{"className":1298},[],[1300],{"type":42,"value":792},{"type":42,"value":1302}," before this setup task finishes, unless an explicit blocker prevents launch or monitoring.",{"type":37,"tag":1255,"props":1304,"children":1305},{},[1306,1308,1313,1314,1319,1321,1326,1328,1333],{"type":42,"value":1307},"The verification outcome is recorded through ",{"type":37,"tag":176,"props":1309,"children":1311},{"className":1310},[],[1312],{"type":42,"value":949},{"type":42,"value":694},{"type":37,"tag":176,"props":1315,"children":1317},{"className":1316},[],[1318],{"type":42,"value":956},{"type":42,"value":1320}," (",{"type":37,"tag":176,"props":1322,"children":1324},{"className":1323},[],[1325],{"type":42,"value":970},{"type":42,"value":1327}," only when the environment explicitly looks ready, otherwise ",{"type":37,"tag":176,"props":1329,"children":1331},{"className":1330},[],[1332],{"type":42,"value":978},{"type":42,"value":1334}," with a user-safe error), unless a blocker prevents launch or monitoring or the recording is rejected as superseded.",{"type":37,"tag":1255,"props":1336,"children":1337},{},[1338],{"type":42,"value":1339},"The final response summarizes the environment name, whether it was created or updated, key validation outcomes, and any blockers - without including the raw YAML config or internal orchestration details.",{"type":37,"tag":1255,"props":1341,"children":1342},{},[1343,1345,1351],{"type":42,"value":1344},"A successful onboarding final response ends by telling the user that the environment is ready and linking ",{"type":37,"tag":176,"props":1346,"children":1348},{"className":1347},[],[1349],{"type":42,"value":1350},"[Create a new task](\u002F)",{"type":42,"value":1352}," as the clear next action.",{"type":37,"tag":1255,"props":1354,"children":1355},{},[1356,1358,1363],{"type":42,"value":1357},"If the follow-up verification task reaches ",{"type":37,"tag":176,"props":1359,"children":1361},{"className":1360},[],[1362],{"type":42,"value":904},{"type":42,"value":1364}," without a surfaced startup or runtime failure, the final response reports that the environment is ready to use instead of asking the user to confirm it manually or describing the verification task.",{"type":37,"tag":1255,"props":1366,"children":1367},{},[1368],{"type":42,"value":1369},"If the spawned verification task reveals a fixable setup or environment-definition error, the skill attempts to repair it, update the environment, relaunch verification, and report the final bounded retry outcome instead of stopping after the first failed verification task.",{"type":37,"tag":1255,"props":1371,"children":1372},{},[1373],{"type":42,"value":1374},"If the app exposes a browser UI and local startup succeeds, the localhost URL is verified through loopback reachability or other non-browser startup evidence before persistence continues.",{"type":37,"tag":1255,"props":1376,"children":1377},{},[1378,1380,1385],{"type":42,"value":1379},"If required environment variables or secrets are known but unavailable, the skill requests them immediately through ",{"type":37,"tag":176,"props":1381,"children":1383},{"className":1382},[],[1384],{"type":42,"value":590},{"type":42,"value":1386}," in web tasks and Slack-started setup tasks, or asks the user to set them locally in the current task before proceeding with affected validation.",{"type":37,"tag":1255,"props":1388,"children":1389},{},[1390,1392,1397],{"type":42,"value":1391},"Every command present in the final ",{"type":37,"tag":176,"props":1393,"children":1395},{"className":1394},[],[1396],{"type":42,"value":440},{"type":42,"value":1398}," list was run and explicitly confirmed during validation, or an explicit blocker explains why validation could not proceed.",{"type":37,"tag":1255,"props":1400,"children":1401},{},[1402],{"type":42,"value":1403},"No secrets, credentials, fabricated env values, or unsupported keys are introduced.",{"type":42,"value":1405},"\n\u003C\u002Fcompletion_criteria>\n",{"type":37,"tag":1249,"props":1407,"children":1408},{},[1409,1411,1417,1419],{"type":42,"value":1410},"\u003Cschema_reference>\n",{"type":37,"tag":1412,"props":1413,"children":1414},"note",{},[1415],{"type":42,"value":1416},"This schema lists the keys the environment definition may use. The validation scope above is narrower: runtime checks stay on localhost, while optional configuration fields still need repository evidence.",{"type":42,"value":1418},"\n\u003Ctop_level_fields>\n",{"type":37,"tag":1420,"props":1421,"children":1423},"field",{"name":345,"required":748,"type":1422},"string",[1424],{"type":37,"tag":1420,"props":1425,"children":1427},{"name":85,"required":1426,"type":1422},"false",[1428],{"type":37,"tag":1420,"props":1429,"children":1431},{"name":494,"required":1426,"type":1430},"absolute URL | about:blank",[1432],{"type":37,"tag":1420,"props":1433,"children":1434},{"name":481,"required":1426,"type":1422},[1435],{"type":37,"tag":1420,"props":1436,"children":1439},{"name":1437,"required":748,"type":1438,"min_items":100},"repositories","RepositoryConfig[]",[1440],{"type":37,"tag":1420,"props":1441,"children":1444},{"name":1442,"required":1426,"type":1443},"env","Record\u003Cstring, string>",[1445],{"type":37,"tag":1420,"props":1446,"children":1448},{"name":522,"required":1426,"type":1447},"NamedPort[]",[1449],{"type":37,"tag":1420,"props":1450,"children":1453},{"name":1451,"required":1426,"type":1452},"services","ServiceConfig[]",[1454],{"type":37,"tag":1420,"props":1455,"children":1457},{"name":546,"required":1426,"type":1456},"DockerProject[]",[1458],{"type":42,"value":1459},"\n\u003C\u002Ftop_level_fields>",{"type":37,"tag":1249,"props":1461,"children":1462},{},[1463,1465],{"type":42,"value":1464},"\u003Cdocker_project_config>\n",{"type":37,"tag":1420,"props":1466,"children":1469},{"name":1467,"required":748,"type":1468},"type","compose | dockerfile",[1470],{"type":37,"tag":1420,"props":1471,"children":1473},{"name":345,"required":748,"type":1472},"unique string starting with a letter",[1474],{"type":37,"tag":1420,"props":1475,"children":1478},{"name":1476,"required":748,"type":1477},"repository","exact identifier from repositories[].repository",[1479],{"type":37,"tag":1420,"props":1480,"children":1483},{"name":1481,"required":1426,"type":1482},"working_dir","relative repository path",[1484],{"type":37,"tag":1420,"props":1485,"children":1486},{"name":1442,"required":1426,"type":1443},[1487],{"type":37,"tag":1420,"props":1488,"children":1490},{"name":522,"required":1426,"type":1489},"DockerProjectPort[]",[1491],{"type":37,"tag":1420,"props":1492,"children":1495},{"name":1493,"required":1426,"type":1494},"required","boolean (defaults true)",[1496],{"type":37,"tag":1420,"props":1497,"children":1500},{"name":1498,"required":1426,"type":1499},"startup_timeout_seconds","integer (1-3600)",[1501,1503],{"type":42,"value":1502},"\n\u003Ccompose_fields>\n",{"type":37,"tag":1420,"props":1504,"children":1507},{"name":1505,"required":748,"type":1506,"min_items":100},"files","relative path[]",[1508],{"type":37,"tag":1420,"props":1509,"children":1512},{"name":1510,"required":1426,"type":1511},"profiles","string[]",[1513],{"type":37,"tag":1420,"props":1514,"children":1515},{"name":1451,"required":1426,"type":1511},[1516,1518],{"type":42,"value":1517},"\n\u003C\u002Fcompose_fields>\n\u003Cdockerfile_fields>\n",{"type":37,"tag":1420,"props":1519,"children":1522},{"name":1520,"required":1426,"type":1521},"context","relative path (defaults .)",[1523],{"type":37,"tag":1420,"props":1524,"children":1527},{"name":1525,"required":1426,"type":1526},"dockerfile","relative path (defaults Dockerfile)",[1528],{"type":37,"tag":1420,"props":1529,"children":1531},{"name":1530,"required":1426,"type":1422},"target",[1532],{"type":37,"tag":1420,"props":1533,"children":1535},{"name":1534,"required":1426,"type":1443},"build_args",[1536],{"type":37,"tag":1420,"props":1537,"children":1539},{"name":1538,"required":1426,"type":1511},"command",[1540],{"type":42,"value":1541},"\n\u003C\u002Fdockerfile_fields>\n\u003C\u002Fdocker_project_config>",{"type":37,"tag":1249,"props":1543,"children":1544},{},[1545,1547],{"type":42,"value":1546},"\u003Cdocker_project_port>\n",{"type":37,"tag":1420,"props":1548,"children":1551},{"name":1549,"required":748,"type":1550},"named_port","name from the top-level ports list",[1552],{"type":37,"tag":1420,"props":1553,"children":1557},{"name":1554,"required":1555,"type":1556},"service","for compose","Compose service name",[1558],{"type":37,"tag":1420,"props":1559,"children":1562},{"name":1560,"required":748,"type":1561},"container_port","integer (1-65535)",[1563],{"type":42,"value":1564},"\n\u003C\u002Fdocker_project_port>",{"type":37,"tag":1249,"props":1566,"children":1567},{},[1568,1570,1583],{"type":42,"value":1569},"\u003Cnamed_port_config>\n",{"type":37,"tag":1412,"props":1571,"children":1572},{},[1573,1575,1581],{"type":42,"value":1574},"Each named port publishes a shareable live-preview URL for the environment and exposes a matching ROOMOTE host environment variable inside the sandbox (for example a port named WEB yields the ",{"type":37,"tag":176,"props":1576,"children":1578},{"className":1577},[],[1579],{"type":42,"value":1580},"ROOMOTE_WEB_HOST",{"type":42,"value":1582}," variable). Configure one entry per validated human-facing HTTP surface, particularly web app UIs.",{"type":37,"tag":1420,"props":1584,"children":1586},{"name":345,"required":748,"type":1585},"string (short uppercase identifier such as WEB; letters, numbers, underscores)",[1587],{"type":37,"tag":1420,"props":1588,"children":1590},{"name":530,"required":748,"type":1589},"number (1024-65535)",[1591],{"type":37,"tag":1420,"props":1592,"children":1594},{"name":538,"required":1426,"type":1593},"URI path starting with \u002F",[1595],{"type":37,"tag":1420,"props":1596,"children":1599},{"name":1597,"required":1426,"type":1598},"primary","boolean",[1600],{"type":42,"value":1601},"\n\u003C\u002Fnamed_port_config>",{"type":37,"tag":1249,"props":1603,"children":1604},{},[1605,1607],{"type":42,"value":1606},"\u003Crepository_config>\n",{"type":37,"tag":1420,"props":1608,"children":1610},{"name":1476,"required":748,"type":1609},"exact task-provided slash-separated repository identifier (for example owner\u002Frepo or Azure DevOps organization\u002Fproject\u002Frepository)",[1611],{"type":37,"tag":1420,"props":1612,"children":1614},{"name":1613,"required":1426,"type":1422},"branch",[1615],{"type":37,"tag":1420,"props":1616,"children":1618},{"name":1617,"required":1426,"type":1443},"tool_versions",[1619],{"type":37,"tag":1420,"props":1620,"children":1623},{"name":1621,"required":1426,"type":1622},"commands","Command[]",[1624],{"type":42,"value":1625},"\n\u003C\u002Frepository_config>",{"type":37,"tag":1249,"props":1627,"children":1628},{},[1629,1631],{"type":42,"value":1630},"\u003Ccommand_config>\n",{"type":37,"tag":1420,"props":1632,"children":1633},{"name":345,"required":748,"type":1422},[1634],{"type":37,"tag":1420,"props":1635,"children":1637},{"name":1636,"required":748,"type":1422},"run",[1638],{"type":37,"tag":1420,"props":1639,"children":1640},{"name":1442,"required":1426,"type":1443},[1641],{"type":37,"tag":1420,"props":1642,"children":1643},{"name":1481,"required":1426,"type":1422},[1644],{"type":37,"tag":1420,"props":1645,"children":1647},{"name":1646,"required":1426,"type":1422},"cwd",[1648],{"type":37,"tag":1420,"props":1649,"children":1652},{"name":1650,"required":1426,"type":1651},"timeout","number",[1653],{"type":37,"tag":1420,"props":1654,"children":1656},{"name":1655,"required":1426,"type":1598},"continue_on_error",[1657],{"type":37,"tag":1420,"props":1658,"children":1660},{"name":1659,"required":1426,"type":1598},"detached",[1661],{"type":37,"tag":1420,"props":1662,"children":1663},{"name":458,"required":1426,"type":1422},[1664],{"type":42,"value":1665},"\n\u003C\u002Fcommand_config>",{"type":37,"tag":1249,"props":1667,"children":1668},{},[1669,1671,1676,1681,1686,1691,1696,1701,1706,1711,1716],{"type":42,"value":1670},"\u003Callowed_services>\n",{"type":37,"tag":1554,"props":1672,"children":1673},{},[1674],{"type":42,"value":1675},"redis6",{"type":37,"tag":1554,"props":1677,"children":1678},{},[1679],{"type":42,"value":1680},"redis7",{"type":37,"tag":1554,"props":1682,"children":1683},{},[1684],{"type":42,"value":1685},"postgres15",{"type":37,"tag":1554,"props":1687,"children":1688},{},[1689],{"type":42,"value":1690},"postgres16",{"type":37,"tag":1554,"props":1692,"children":1693},{},[1694],{"type":42,"value":1695},"postgres17",{"type":37,"tag":1554,"props":1697,"children":1698},{},[1699],{"type":42,"value":1700},"mysql8",{"type":37,"tag":1554,"props":1702,"children":1703},{},[1704],{"type":42,"value":1705},"mariadb10",{"type":37,"tag":1554,"props":1707,"children":1708},{},[1709],{"type":42,"value":1710},"clickhouse",{"type":37,"tag":1554,"props":1712,"children":1713},{},[1714],{"type":42,"value":1715},"aws",{"type":42,"value":1717},"\n\u003C\u002Fallowed_services>",{"type":37,"tag":1249,"props":1719,"children":1720},{},[1721],{"type":42,"value":1722},"\u003C\u002Fschema_reference>",{"type":37,"tag":1249,"props":1724,"children":1725},{},[1726,1728,1742,1770,1775,1780,1815,1820,1840,1845,1850,1855,1874,1886,1898,1910,1930,1935,1947,1982,1987,1992,1997,2008,2013,2025,2044,2063,2068,2080,2092,2104,2109,2114,2126,2137,2149,2154,2159,2164,2169,2181,2193,2229,2234,2246,2251,2263,2287,2305,2310,2315,2339,2391,2403,2408,2413,2418,2423,2428,2433,2474,2493,2535,2540,2552,2557],{"type":42,"value":1727},"\u003Chard_rules>\n",{"type":37,"tag":1729,"props":1730,"children":1731},"rule",{},[1732,1734,1740],{"type":42,"value":1733},"Before inspecting a target repository, discover and read the applicable repo-local ",{"type":37,"tag":176,"props":1735,"children":1737},{"className":1736},[],[1738],{"type":42,"value":1739},"AGENTS.md",{"type":42,"value":1741}," hierarchy from the repo root through the nearest ancestor, and re-check when moving into a subtree with its own guidance.",{"type":37,"tag":1729,"props":1743,"children":1744},{},[1745,1747,1753,1755,1761,1763,1768],{"type":42,"value":1746},"Discover and read the applicable repo-local ",{"type":37,"tag":176,"props":1748,"children":1750},{"className":1749},[],[1751],{"type":42,"value":1752},"CLAUDE.md",{"type":42,"value":1754}," hierarchy from the repo root through the nearest ancestor too, treating ",{"type":37,"tag":176,"props":1756,"children":1758},{"className":1757},[],[1759],{"type":42,"value":1760},".claude\u002FCLAUDE.md",{"type":42,"value":1762}," at the repo root as root-scoped guidance. Prefer the closest applicable repository guidance when files conflict, with ",{"type":37,"tag":176,"props":1764,"children":1766},{"className":1765},[],[1767],{"type":42,"value":1739},{"type":42,"value":1769}," winning ties at the same scope. Treat both guidance formats as supplemental and subordinate to Roomote workflow, tool, safety, and direct user instructions.",{"type":37,"tag":1729,"props":1771,"children":1772},{},[1773],{"type":42,"value":1774},"Check each target repo's developer local-setup documentation before inferring sandbox setup commands from manifests, scripts, or CI.",{"type":37,"tag":1729,"props":1776,"children":1777},{},[1778],{"type":42,"value":1779},"When repo-local setup docs and lower-level evidence disagree, prefer the documented local developer workflow unless direct runtime validation proves the docs are stale or incomplete.",{"type":37,"tag":1729,"props":1781,"children":1782},{},[1783,1785,1791,1792,1798,1800,1806,1808,1813],{"type":42,"value":1784},"Follow checked-in package-manager and toolchain policy, including package-manager declarations, engine requirements, ",{"type":37,"tag":176,"props":1786,"children":1788},{"className":1787},[],[1789],{"type":42,"value":1790},".npmrc",{"type":42,"value":728},{"type":37,"tag":176,"props":1793,"children":1795},{"className":1794},[],[1796],{"type":42,"value":1797},".yarnrc*",{"type":42,"value":1799},", pnpm configuration, ",{"type":37,"tag":176,"props":1801,"children":1803},{"className":1802},[],[1804],{"type":42,"value":1805},".tool-versions",{"type":42,"value":1807},", Mise config, language version files, and ecosystem equivalents, unless direct validation proves a specific setting stale or unusable. Translate only unambiguous exact versions with known Mise tool names into ",{"type":37,"tag":176,"props":1809,"children":1811},{"className":1810},[],[1812],{"type":42,"value":1617},{"type":42,"value":1814},"; preserve ranges and unsupported descriptors as validation policy instead of copying them into Mise config. Never expose credentials or tokens from repository configuration.",{"type":37,"tag":1729,"props":1816,"children":1817},{},[1818],{"type":42,"value":1819},"Treat repositories referenced by the task or environment as already checked out in the current workspace unless the user explicitly says otherwise.",{"type":37,"tag":1729,"props":1821,"children":1822},{},[1823,1825,1831,1833,1839],{"type":42,"value":1824},"Preserve every task-provided repository identifier exactly in ",{"type":37,"tag":176,"props":1826,"children":1828},{"className":1827},[],[1829],{"type":42,"value":1830},"repositories[].repository",{"type":42,"value":1832},"; never shorten or reconstruct it from a checkout path. Azure DevOps identifiers must retain ",{"type":37,"tag":176,"props":1834,"children":1836},{"className":1835},[],[1837],{"type":42,"value":1838},"organization\u002Fproject\u002Frepository",{"type":42,"value":511},{"type":37,"tag":1729,"props":1841,"children":1842},{},[1843],{"type":42,"value":1844},"Never include the full environment YAML in your visible response or Slack reply. The environment is already persisted through manage_environments; re-dumping the config into the transcript is redundant and risks exposing secret values that were kept out of the conversation through request_environment_variables.",{"type":37,"tag":1729,"props":1846,"children":1847},{},[1848],{"type":42,"value":1849},"Use repository default branch unless strong evidence supports another branch.",{"type":37,"tag":1729,"props":1851,"children":1852},{},[1853],{"type":42,"value":1854},"Include only commands strongly supported by repository evidence.",{"type":37,"tag":1729,"props":1856,"children":1857},{},[1858,1860,1866,1868,1873],{"type":42,"value":1859},"Do not run ",{"type":37,"tag":176,"props":1861,"children":1863},{"className":1862},[],[1864],{"type":42,"value":1865},"git clone",{"type":42,"value":1867},", ask the user to re-clone a repository that is already present, or include clone steps in ",{"type":37,"tag":176,"props":1869,"children":1871},{"className":1870},[],[1872],{"type":42,"value":440},{"type":42,"value":511},{"type":37,"tag":1729,"props":1875,"children":1876},{},[1877,1879,1884],{"type":42,"value":1878},"Use ",{"type":37,"tag":176,"props":1880,"children":1882},{"className":1881},[],[1883],{"type":42,"value":440},{"type":42,"value":1885}," only for executing commands and setting configuration needed to validate the environment.",{"type":37,"tag":1729,"props":1887,"children":1888},{},[1889,1891,1896],{"type":42,"value":1890},"If setup requires configuration or runtime file creation or modification, represent it with ",{"type":37,"tag":176,"props":1892,"children":1894},{"className":1893},[],[1895],{"type":42,"value":440},{"type":42,"value":1897}," entries instead of asking the user to edit files directly.",{"type":37,"tag":1729,"props":1899,"children":1900},{},[1901,1903,1908],{"type":42,"value":1902},"Do not use ",{"type":37,"tag":176,"props":1904,"children":1906},{"className":1905},[],[1907],{"type":42,"value":440},{"type":42,"value":1909}," to write, generate, or patch application or source code; if source changes are required, report that as a blocker or separate follow-up work.",{"type":37,"tag":1729,"props":1911,"children":1912},{},[1913,1915,1921,1922,1928],{"type":42,"value":1914},"When the target repository has no commits at all, bootstrap it with exactly one commit containing only ",{"type":37,"tag":176,"props":1916,"children":1918},{"className":1917},[],[1919],{"type":42,"value":1920},"README.md",{"type":42,"value":794},{"type":37,"tag":176,"props":1923,"children":1925},{"className":1924},[],[1926],{"type":42,"value":1927},".gitignore",{"type":42,"value":1929}," pushed to its default branch; never force-push, and never scaffold application code, frameworks, package manifests, or CI config during environment setup.",{"type":37,"tag":1729,"props":1931,"children":1932},{},[1933],{"type":42,"value":1934},"For a just-bootstrapped repository, keep the environment definition minimal (typically the repository mapping with no commands, services, or ports) instead of inventing commands for application code that does not exist yet.",{"type":37,"tag":1729,"props":1936,"children":1937},{},[1938,1940,1945],{"type":42,"value":1939},"Treat each ",{"type":37,"tag":176,"props":1941,"children":1943},{"className":1942},[],[1944],{"type":42,"value":1636},{"type":42,"value":1946}," field as newline-split before execution. Do not rely on YAML multiline blocks to preserve shell control flow across lines.",{"type":37,"tag":1729,"props":1948,"children":1949},{},[1950,1952,1958,1960,1966,1967,1973,1975,1981],{"type":42,"value":1951},"Do not emit YAML ",{"type":37,"tag":176,"props":1953,"children":1955},{"className":1954},[],[1956],{"type":42,"value":1957},"run: |",{"type":42,"value":1959}," blocks for ",{"type":37,"tag":176,"props":1961,"children":1963},{"className":1962},[],[1964],{"type":42,"value":1965},"if ... fi",{"type":42,"value":728},{"type":37,"tag":176,"props":1968,"children":1970},{"className":1969},[],[1971],{"type":42,"value":1972},"case",{"type":42,"value":1974},", loops, heredocs, or multiline shell functions unless the entire block is wrapped inside one explicit shell command such as ",{"type":37,"tag":176,"props":1976,"children":1978},{"className":1977},[],[1979],{"type":42,"value":1980},"bash -lc '...'",{"type":42,"value":511},{"type":37,"tag":1729,"props":1983,"children":1984},{},[1985],{"type":42,"value":1986},"When setup logic needs conditional or multiline behavior, prefer multiple simple command entries or one explicit shell wrapper command over raw multiline shell fragments.",{"type":37,"tag":1729,"props":1988,"children":1989},{},[1990],{"type":42,"value":1991},"Prefer runtime-only configuration file modifications outside the git repository when possible to avoid unstaged repo changes.",{"type":37,"tag":1729,"props":1993,"children":1994},{},[1995],{"type":42,"value":1996},"Include only services clearly required by repository evidence.",{"type":37,"tag":1729,"props":1998,"children":1999},{},[2000,2001,2006],{"type":42,"value":1878},{"type":37,"tag":176,"props":2002,"children":2004},{"className":2003},[],[2005],{"type":42,"value":546},{"type":42,"value":2007}," only when a checked-in Compose project or Dockerfile is the evidence-backed development path, and validate the exact model before persistence.",{"type":37,"tag":1729,"props":2009,"children":2010},{},[2011],{"type":42,"value":2012},"All Docker project paths must be relative and stay inside the selected configured repository.",{"type":37,"tag":1729,"props":2014,"children":2015},{},[2016,2018,2023],{"type":42,"value":2017},"Include ",{"type":37,"tag":176,"props":2019,"children":2021},{"className":2020},[],[2022],{"type":42,"value":1617},{"type":42,"value":2024}," only when clearly discoverable.",{"type":37,"tag":1729,"props":2026,"children":2027},{},[2028,2030,2035,2037,2042],{"type":42,"value":2029},"When a repository exposes a browser UI or stable localhost landing page, set ",{"type":37,"tag":176,"props":2031,"children":2033},{"className":2032},[],[2034],{"type":42,"value":494},{"type":42,"value":2036}," to the best validated absolute URL unless ",{"type":37,"tag":176,"props":2038,"children":2040},{"className":2039},[],[2041],{"type":42,"value":502},{"type":42,"value":2043}," is intentionally required.",{"type":37,"tag":1729,"props":2045,"children":2046},{},[2047,2049,2054,2056,2061],{"type":42,"value":2048},"When a validated human-facing HTTP surface exists (particularly a web app UI), configure a matching top-level ",{"type":37,"tag":176,"props":2050,"children":2052},{"className":2051},[],[2053],{"type":42,"value":522},{"type":42,"value":2055}," entry so the environment publishes a shareable preview URL for it; keep the ",{"type":37,"tag":176,"props":2057,"children":2059},{"className":2058},[],[2060],{"type":42,"value":522},{"type":42,"value":2062}," list limited to validated human-facing surfaces and confirm each configured port number against the actual validated listening port.",{"type":37,"tag":1729,"props":2064,"children":2065},{},[2066],{"type":42,"value":2067},"Always derive a best-effort environment definition that is ready to work once required environment variables are supplied.",{"type":37,"tag":1729,"props":2069,"children":2070},{},[2071,2073,2078],{"type":42,"value":2072},"Treat ",{"type":37,"tag":176,"props":2074,"children":2076},{"className":2075},[],[2077],{"type":42,"value":481},{"type":42,"value":2079}," as instructions for future agents running inside the created environment, not as setup progress notes or setup next-step guidance for this skill run.",{"type":37,"tag":1729,"props":2081,"children":2082},{},[2083,2085,2090],{"type":42,"value":2084},"When the app exposes a browser UI, ",{"type":37,"tag":176,"props":2086,"children":2088},{"className":2087},[],[2089],{"type":42,"value":481},{"type":42,"value":2091}," must explain how agents access it, including any authentication steps. Do not assume agents will discover auth flows, test credentials, or dev-mode conventions on their own.",{"type":37,"tag":1729,"props":2093,"children":2094},{},[2095,2097,2102],{"type":42,"value":2096},"If a repository test suite exists, include a concrete test command in ",{"type":37,"tag":176,"props":2098,"children":2100},{"className":2099},[],[2101],{"type":42,"value":481},{"type":42,"value":2103}," and state that the suite should pass before completing future code changes, even when setup validation reports a clearly pre-existing repo failure.",{"type":37,"tag":1729,"props":2105,"children":2106},{},[2107],{"type":42,"value":2108},"If tests are practical to run during validation, execute the suite and treat failures as blockers when they indicate missing setup, broken environment definition, unavailable required services or secrets, or another environment-setup problem.",{"type":37,"tag":1729,"props":2110,"children":2111},{},[2112],{"type":42,"value":2113},"Do not treat clearly pre-existing repository or unit-test failures as automatic blockers to environment creation when install\u002Fstart\u002Flocalhost validation succeeds and the failure appears outside environment-setup scope; report the exact failing command and keep the issue visible as a known repo problem.",{"type":37,"tag":1729,"props":2115,"children":2116},{},[2117,2119,2124],{"type":42,"value":2118},"Every command added to ",{"type":37,"tag":176,"props":2120,"children":2122},{"className":2121},[],[2123],{"type":42,"value":440},{"type":42,"value":2125}," must be run during validation in config order unless an explicit blocker prevents it.",{"type":37,"tag":1729,"props":2127,"children":2128},{},[2129,2130,2135],{"type":42,"value":2118},{"type":37,"tag":176,"props":2131,"children":2133},{"className":2132},[],[2134],{"type":42,"value":440},{"type":42,"value":2136}," must be explicitly confirmed from execution evidence appropriate to that command, such as exit status, log inspection, artifact creation, localhost reachability, or other command-appropriate runtime evidence.",{"type":37,"tag":1729,"props":2138,"children":2139},{},[2140,2142,2147],{"type":42,"value":2141},"Do not depend on prompt-wide browser bootstrap or direct browser automation inside ",{"type":37,"tag":176,"props":2143,"children":2145},{"className":2144},[],[2146],{"type":42,"value":4},{"type":42,"value":2148},"; keep localhost validation in this skill to loopback reachability and startup evidence.",{"type":37,"tag":1729,"props":2150,"children":2151},{},[2152],{"type":42,"value":2153},"If any configured command cannot be run or confirmed, remove it from the final environment definition or report the exact blocker; do not leave speculative or unverified commands in the final config.",{"type":37,"tag":1729,"props":2155,"children":2156},{},[2157],{"type":42,"value":2158},"Do not replace required real services with mocks, stubs, fake servers, or no-op stand-ins merely to make validation appear successful.",{"type":37,"tag":1729,"props":2160,"children":2161},{},[2162],{"type":42,"value":2163},"If repository evidence and supported worker tooling are still insufficient to get a required real service running, ask the user for help with that service before proceeding instead of inventing a fallback.",{"type":37,"tag":1729,"props":2165,"children":2166},{},[2167],{"type":42,"value":2168},"If repository evidence or validation shows that required environment variables or secrets are needed, request them as soon as their names are known instead of waiting for a later command failure.",{"type":37,"tag":1729,"props":2170,"children":2171},{},[2172,2174,2179],{"type":42,"value":2173},"If local install\u002Ftest\u002Fstart cannot run due to missing environment variables or secrets, do not create an environment until the missing variables are provided through ",{"type":37,"tag":176,"props":2175,"children":2177},{"className":2176},[],[2178],{"type":42,"value":590},{"type":42,"value":2180}," in web tasks and Slack-started setup tasks, or the user adds them locally and validation is retried.",{"type":37,"tag":1729,"props":2182,"children":2183},{},[2184,2186,2191],{"type":42,"value":2185},"When required environment variables or secrets are known but unavailable in a web dashboard task or Slack-started setup task, use ",{"type":37,"tag":176,"props":2187,"children":2189},{"className":2188},[],[2190],{"type":42,"value":590},{"type":42,"value":2192}," and never ask the user to paste secret values into the conversation.",{"type":37,"tag":1729,"props":2194,"children":2195},{},[2196,2197,2202,2204,2209,2210,2215,2217,2222,2223,2228],{"type":42,"value":597},{"type":37,"tag":176,"props":2198,"children":2200},{"className":2199},[],[2201],{"type":42,"value":603},{"type":42,"value":2203}," message with ",{"type":37,"tag":176,"props":2205,"children":2207},{"className":2206},[],[2208],{"type":42,"value":611},{"type":42,"value":613},{"type":37,"tag":176,"props":2211,"children":2213},{"className":2212},[],[2214],{"type":42,"value":619},{"type":42,"value":2216}," naming the required keys and what they unblock, but do not include the secure ",{"type":37,"tag":176,"props":2218,"children":2220},{"className":2219},[],[2221],{"type":42,"value":627},{"type":42,"value":629},{"type":37,"tag":176,"props":2224,"children":2226},{"className":2225},[],[2227],{"type":42,"value":590},{"type":42,"value":636},{"type":37,"tag":1729,"props":2230,"children":2231},{},[2232],{"type":42,"value":2233},"In non-web surfaces, ask only for local environment variable additions in the current task, and provide exact variable names and exact actions.",{"type":37,"tag":1729,"props":2235,"children":2236},{},[2237,2239,2244],{"type":42,"value":2238},"For this skill, create a new environment or update the specified existing environment only after localhost startup and loopback reachability are successful enough to proceed, including validation of ",{"type":37,"tag":176,"props":2240,"children":2242},{"className":2241},[],[2243],{"type":42,"value":494},{"type":42,"value":2245}," through non-browser evidence when the app exposes a browser UI.",{"type":37,"tag":1729,"props":2247,"children":2248},{},[2249],{"type":42,"value":2250},"When the task explicitly identifies an existing environment to revise, update that environment instead of creating a duplicate.",{"type":37,"tag":1729,"props":2252,"children":2253},{},[2254,2256,2261],{"type":42,"value":2255},"After successful environment persistence, use the Roomote MCP tool ",{"type":37,"tag":176,"props":2257,"children":2259},{"className":2258},[],[2260],{"type":42,"value":692},{"type":42,"value":2262}," to launch a lightweight verification task against the created or updated environment and monitor it yourself instead of leaving verification as an implicit manual next step.",{"type":37,"tag":1729,"props":2264,"children":2265},{},[2266,2268,2273,2274,2279,2281,2286],{"type":42,"value":2267},"Before launching that verification task, call the Roomote MCP tool ",{"type":37,"tag":176,"props":2269,"children":2271},{"className":2270},[],[2272],{"type":42,"value":692},{"type":42,"value":694},{"type":37,"tag":176,"props":2275,"children":2277},{"className":2276},[],[2278],{"type":42,"value":700},{"type":42,"value":2280}," so the environment target is grounded in current Roomote data and you can copy the exact returned ",{"type":37,"tag":176,"props":2282,"children":2284},{"className":2283},[],[2285],{"type":42,"value":708},{"type":42,"value":511},{"type":37,"tag":1729,"props":2288,"children":2289},{},[2290,2292,2297,2298,2303],{"type":42,"value":2291},"When the verification task launch succeeds, monitor it every 10-15 seconds with the Roomote MCP tool ",{"type":37,"tag":176,"props":2293,"children":2295},{"className":2294},[],[2296],{"type":42,"value":692},{"type":42,"value":814},{"type":37,"tag":176,"props":2299,"children":2301},{"className":2300},[],[2302],{"type":42,"value":792},{"type":42,"value":2304}," and use that per-task summary surface as the source of truth for task status and surfaced startup failures.",{"type":37,"tag":1729,"props":2306,"children":2307},{},[2308],{"type":42,"value":2309},"While the follow-up check runs, narrate concise progress updates in plain language instead of silently waiting or pushing the waiting back onto the user. Do not mention a spawned task, task status, polling, or monitoring in those user-facing updates.",{"type":37,"tag":1729,"props":2311,"children":2312},{},[2313],{"type":42,"value":2314},"Preparing the environment can take several minutes. Do not stop monitoring solely because the verification task is taking a long time to start; keep checking until it reaches a terminal state or surfaces a blocker you can report or act on, and keep checks frequent enough that a completed setup or completed verification is noticed promptly.",{"type":37,"tag":1729,"props":2316,"children":2317},{},[2318,2320,2325,2326,2331,2332,2337],{"type":42,"value":2319},"If the monitored summary settles into ",{"type":37,"tag":176,"props":2321,"children":2323},{"className":2322},[],[2324],{"type":42,"value":916},{"type":42,"value":728},{"type":37,"tag":176,"props":2327,"children":2329},{"className":2328},[],[2330],{"type":42,"value":923},{"type":42,"value":925},{"type":37,"tag":176,"props":2333,"children":2335},{"className":2334},[],[2336],{"type":42,"value":931},{"type":42,"value":2338},", inspect the latest task messages instead of polling that state forever, and only treat it as success when those messages clearly report that the environment looks ready.",{"type":37,"tag":1729,"props":2340,"children":2341},{},[2342,2344,2349,2350,2355,2357,2362,2364,2369,2371,2376,2377,2382,2384,2389],{"type":42,"value":2343},"Record the verification outcome explicitly through the Roomote MCP tool ",{"type":37,"tag":176,"props":2345,"children":2347},{"className":2346},[],[2348],{"type":42,"value":949},{"type":42,"value":694},{"type":37,"tag":176,"props":2351,"children":2353},{"className":2352},[],[2354],{"type":42,"value":956},{"type":42,"value":2356}," and the created or updated ",{"type":37,"tag":176,"props":2358,"children":2360},{"className":2359},[],[2361],{"type":42,"value":708},{"type":42,"value":2363},": ",{"type":37,"tag":176,"props":2365,"children":2367},{"className":2366},[],[2368],{"type":42,"value":970},{"type":42,"value":2370}," only when the explicit \"environment looks ready\" criterion is satisfied, and ",{"type":37,"tag":176,"props":2372,"children":2374},{"className":2373},[],[2375],{"type":42,"value":978},{"type":42,"value":980},{"type":37,"tag":176,"props":2378,"children":2380},{"className":2379},[],[2381],{"type":42,"value":986},{"type":42,"value":2383}," when verification reaches a terminal failure or cannot be completed. Do not include secrets or the full environment YAML in the ",{"type":37,"tag":176,"props":2385,"children":2387},{"className":2386},[],[2388],{"type":42,"value":986},{"type":42,"value":2390},", and do not pass a task id (Roomote derives the recording task from the current run).",{"type":37,"tag":1729,"props":2392,"children":2393},{},[2394,2396,2401],{"type":42,"value":2395},"Treat a rejected ",{"type":37,"tag":176,"props":2397,"children":2399},{"className":2398},[],[2400],{"type":42,"value":1001},{"type":42,"value":2402}," result as a superseded attempt: do not retry recording, because a newer verification attempt or a runtime-affecting edit now owns the environment's verification state.",{"type":37,"tag":1729,"props":2404,"children":2405},{},[2406],{"type":42,"value":2407},"If the spawned verification task surfaces a fixable setup or environment-definition problem, attempt to fix it yourself, recreate or update the environment, launch a fresh verification task, and repeat the monitoring loop instead of stopping after the first discovered error.",{"type":37,"tag":1729,"props":2409,"children":2410},{},[2411],{"type":42,"value":2412},"Bound that environment-repair loop to at most 2 additional full retries after the first spawned verification task unless the task context clearly justifies fewer attempts.",{"type":37,"tag":1729,"props":2414,"children":2415},{},[2416],{"type":42,"value":2417},"Do not claim automatic repair for failures that actually require product\u002Fsource changes outside environment-setup scope, unsupported infrastructure, missing external credentials, or a user decision you cannot safely infer; report those as blockers.",{"type":37,"tag":1729,"props":2419,"children":2420},{},[2421],{"type":42,"value":2422},"Do not tell the user to verify the environment in that spawned task before clicking Continue, and do not include the spawned verification task link in the user-facing response; report the monitored outcome yourself.",{"type":37,"tag":1729,"props":2424,"children":2425},{},[2426],{"type":42,"value":2427},"If the follow-up check cannot be launched or completed after the environment is persisted, report that readiness could not be confirmed and explain the real blocker in user terms; do not imply the environment is ready.",{"type":37,"tag":1729,"props":2429,"children":2430},{},[2431],{"type":42,"value":2432},"When a browser UI is validated locally, report the exact localhost URL and the loopback or startup evidence that confirmed it rather than capturing screenshots from this skill.",{"type":37,"tag":1729,"props":2434,"children":2435},{},[2436,2438,2444,2445,2451,2452,2458,2459,2465,2467,2473],{"type":42,"value":2437},"Any long-running service command (for example ",{"type":37,"tag":176,"props":2439,"children":2441},{"className":2440},[],[2442],{"type":42,"value":2443},"dev",{"type":42,"value":728},{"type":37,"tag":176,"props":2446,"children":2448},{"className":2447},[],[2449],{"type":42,"value":2450},"start",{"type":42,"value":728},{"type":37,"tag":176,"props":2453,"children":2455},{"className":2454},[],[2456],{"type":42,"value":2457},"serve",{"type":42,"value":728},{"type":37,"tag":176,"props":2460,"children":2462},{"className":2461},[],[2463],{"type":42,"value":2464},"preview",{"type":42,"value":2466},", or watchers) must use ",{"type":37,"tag":176,"props":2468,"children":2470},{"className":2469},[],[2471],{"type":42,"value":2472},"detached: true",{"type":42,"value":511},{"type":37,"tag":1729,"props":2475,"children":2476},{},[2477,2479,2484,2486,2491],{"type":42,"value":2478},"Any command with ",{"type":37,"tag":176,"props":2480,"children":2482},{"className":2481},[],[2483],{"type":42,"value":2472},{"type":42,"value":2485}," must set ",{"type":37,"tag":176,"props":2487,"children":2489},{"className":2488},[],[2490],{"type":42,"value":458},{"type":42,"value":2492}," to capture runtime output.",{"type":37,"tag":1729,"props":2494,"children":2495},{},[2496,2498,2504,2505,2511,2513,2519,2521,2526,2528,2533],{"type":42,"value":2497},"Do not encode ",{"type":37,"tag":176,"props":2499,"children":2501},{"className":2500},[],[2502],{"type":42,"value":2503},"pm2 start",{"type":42,"value":728},{"type":37,"tag":176,"props":2506,"children":2508},{"className":2507},[],[2509],{"type":42,"value":2510},"nohup",{"type":42,"value":2512},", shell trailing ",{"type":37,"tag":176,"props":2514,"children":2516},{"className":2515},[],[2517],{"type":42,"value":2518},"&",{"type":42,"value":2520},", or another process supervisor in ",{"type":37,"tag":176,"props":2522,"children":2524},{"className":2523},[],[2525],{"type":42,"value":1636},{"type":42,"value":2527}," for environment repository commands. Use the normal foreground command with ",{"type":37,"tag":176,"props":2529,"children":2531},{"className":2530},[],[2532],{"type":42,"value":2472},{"type":42,"value":2534},"; Roomote supervises it with PM2 and restarts it if it exits unexpectedly.",{"type":37,"tag":1729,"props":2536,"children":2537},{},[2538],{"type":42,"value":2539},"Do not include unsupported keys.",{"type":37,"tag":1729,"props":2541,"children":2542},{},[2543,2545,2550],{"type":42,"value":2544},"Do not fabricate ",{"type":37,"tag":176,"props":2546,"children":2548},{"className":2547},[],[2549],{"type":42,"value":1442},{"type":42,"value":2551}," values.",{"type":37,"tag":1729,"props":2553,"children":2554},{},[2555],{"type":42,"value":2556},"If secrets are required but unavailable, omit them and report the blocker.",{"type":42,"value":2558},"\n\u003C\u002Fhard_rules>",{"type":37,"tag":1249,"props":2560,"children":2561},{},[2562,2564,2569],{"type":42,"value":2563},"\u003Cexample_notes>\n",{"type":37,"tag":1412,"props":2565,"children":2566},{},[2567],{"type":42,"value":2568},"Examples below show valid output YAML shapes, not extra validation obligations.",{"type":42,"value":2570},"\n\u003C\u002Fexample_notes>",{"type":37,"tag":2572,"props":2573,"children":2574},"examples",{},[2575,2576,2587,2588,2597,2598,2607,2608,2617,2618,2627,2628],{"type":42,"value":49},{"type":37,"tag":2577,"props":2578,"children":2580},"example",{"name":2579},"full_stack_multi_repo",[2581,2582,2586],{"type":42,"value":62},{"type":37,"tag":2583,"props":2584,"children":2585},"yaml",{},[],{"type":42,"value":49},{"type":42,"value":49},{"type":37,"tag":2577,"props":2589,"children":2591},{"name":2590},"custom_service_port",[2592,2593,2596],{"type":42,"value":62},{"type":37,"tag":2583,"props":2594,"children":2595},{},[],{"type":42,"value":49},{"type":42,"value":49},{"type":37,"tag":2577,"props":2599,"children":2601},{"name":2600},"build_time_env_injection",[2602,2603,2606],{"type":42,"value":62},{"type":37,"tag":2583,"props":2604,"children":2605},{},[],{"type":42,"value":49},{"type":42,"value":49},{"type":37,"tag":2577,"props":2609,"children":2611},{"name":2610},"admin_app",[2612,2613,2616],{"type":42,"value":62},{"type":37,"tag":2583,"props":2614,"children":2615},{},[],{"type":42,"value":49},{"type":42,"value":49},{"type":37,"tag":2577,"props":2619,"children":2621},{"name":2620},"webhook_service",[2622,2623,2626],{"type":42,"value":62},{"type":37,"tag":2583,"props":2624,"children":2625},{},[],{"type":42,"value":49},{"type":42,"value":49},{"type":37,"tag":2577,"props":2629,"children":2631},{"name":2630},"metrics_service",[2632,2633,2636],{"type":42,"value":62},{"type":37,"tag":2583,"props":2634,"children":2635},{},[],{"type":42,"value":49},{"type":37,"tag":1249,"props":2638,"children":2639},{},[2640,2642,2658,2671,2691,2718,2739],{"type":42,"value":2641},"\u003Cbest_practices>\n",{"type":37,"tag":2643,"props":2644,"children":2646},"guideline",{"priority":2645},"high",[2647,2652],{"type":37,"tag":1729,"props":2648,"children":2649},{},[2650],{"type":42,"value":2651},"Treat examples as patterns, not templates to copy blindly.",{"type":37,"tag":2653,"props":2654,"children":2655},"rationale",{},[2656],{"type":42,"value":2657},"Repository-specific evidence should determine final fields.",{"type":37,"tag":2643,"props":2659,"children":2660},{"priority":2645},[2661,2666],{"type":37,"tag":1729,"props":2662,"children":2663},{},[2664],{"type":42,"value":2665},"Prefer the smallest config that matches the repository's real workflow.",{"type":37,"tag":2653,"props":2667,"children":2668},{},[2669],{"type":42,"value":2670},"Minimal configs are easier to run, validate, and maintain.",{"type":37,"tag":2643,"props":2672,"children":2673},{"priority":2645},[2674,2679],{"type":37,"tag":1729,"props":2675,"children":2676},{},[2677],{"type":42,"value":2678},"Prefer command-driven setup over manual repo edits.",{"type":37,"tag":2653,"props":2680,"children":2681},{},[2682,2684,2689],{"type":42,"value":2683},"Encoding file writes in ",{"type":37,"tag":176,"props":2685,"children":2687},{"className":2686},[],[2688],{"type":42,"value":1621},{"type":42,"value":2690}," keeps setup reproducible and avoids asking the user for avoidable code changes.",{"type":37,"tag":2643,"props":2692,"children":2693},{"priority":2645},[2694,2706],{"type":37,"tag":1729,"props":2695,"children":2696},{},[2697,2699,2704],{"type":42,"value":2698},"Prefer one-line ",{"type":37,"tag":176,"props":2700,"children":2702},{"className":2701},[],[2703],{"type":42,"value":1636},{"type":42,"value":2705}," commands.",{"type":37,"tag":2653,"props":2707,"children":2708},{},[2709,2711,2716],{"type":42,"value":2710},"The executor splits ",{"type":37,"tag":176,"props":2712,"children":2714},{"className":2713},[],[2715],{"type":42,"value":1636},{"type":42,"value":2717}," on literal newlines, so one-line commands or explicit shell wrappers are much less error-prone than YAML block-scalar shell scripts.",{"type":37,"tag":2643,"props":2719,"children":2720},{"priority":2645},[2721,2726],{"type":37,"tag":1729,"props":2722,"children":2723},{},[2724],{"type":42,"value":2725},"Prefer runtime-only files outside the git repo.",{"type":37,"tag":2653,"props":2727,"children":2728},{},[2729,2731,2737],{"type":42,"value":2730},"Writing temporary setup files to locations like ",{"type":37,"tag":176,"props":2732,"children":2734},{"className":2733},[],[2735],{"type":42,"value":2736},"\u002Ftmp",{"type":42,"value":2738}," reduces repository noise and prevents unexpected unstaged changes.",{"type":42,"value":2740},"\n\u003C\u002Fbest_practices>",{"type":37,"tag":2742,"props":2743,"children":2744},"patterns",{},[2745,2746,2765,2766],{"type":42,"value":49},{"type":37,"tag":2747,"props":2748,"children":2750},"pattern",{"name":2749},"single_service_minimal",[2751,2752,2757,2758,2764],{"type":42,"value":62},{"type":37,"tag":85,"props":2753,"children":2754},{},[2755],{"type":42,"value":2756},"Use for repositories that expose one clear runtime surface.",{"type":42,"value":62},{"type":37,"tag":2759,"props":2760,"children":2761},"template",{},[2762],{"type":42,"value":2763},"one repository -> install command -> one start command -> set `initialUrl` and a matching `ports` entry when there is a browser landing page -> no extra services unless required",{"type":42,"value":49},{"type":42,"value":49},{"type":37,"tag":2747,"props":2767,"children":2769},{"name":2768},"monorepo_selective",[2770,2771,2776,2777,2782],{"type":42,"value":62},{"type":37,"tag":85,"props":2772,"children":2773},{},[2774],{"type":42,"value":2775},"Use for monorepos where only a subset of apps are needed for the requested environment.",{"type":42,"value":62},{"type":37,"tag":2759,"props":2778,"children":2779},{},[2780],{"type":42,"value":2781},"include only relevant repositories\u002Fapps -> include only required commands\u002Fservices -> omit optional surfaces without evidence",{"type":42,"value":49},{"type":37,"tag":1249,"props":2784,"children":2785},{},[2786,2788,2820,2834,2848,2862,2876,2897,2918],{"type":42,"value":2787},"\u003Cerror_handling>\n",{"type":37,"tag":2789,"props":2790,"children":2792},"scenario",{"name":2791},"missing_or_ambiguous_evidence",[2793,2799],{"type":37,"tag":2794,"props":2795,"children":2796},"problem",{},[2797],{"type":42,"value":2798},"Repository evidence does not clearly support a field.",{"type":37,"tag":2800,"props":2801,"children":2802},"recovery",{},[2803,2805,2811,2812,2818],{"type":42,"value":2804},"Omit the field and document the uncertainty in ",{"type":37,"tag":176,"props":2806,"children":2808},{"className":2807},[],[2809],{"type":42,"value":2810},"Assumptions",{"type":42,"value":852},{"type":37,"tag":176,"props":2813,"children":2815},{"className":2814},[],[2816],{"type":42,"value":2817},"Blockers",{"type":42,"value":2819}," instead of guessing.",{"type":37,"tag":2789,"props":2821,"children":2823},{"name":2822},"validation_blocked_by_secrets_or_external_dependencies",[2824,2829],{"type":37,"tag":2794,"props":2825,"children":2826},{},[2827],{"type":42,"value":2828},"Install or startup cannot complete due to unavailable secrets, credentials, or external systems.",{"type":37,"tag":2800,"props":2830,"children":2831},{},[2832],{"type":42,"value":2833},"Keep the config minimal, report exactly what blocked validation, and avoid fabricated env values.",{"type":37,"tag":2789,"props":2835,"children":2837},{"name":2836},"browser_surface_validation_blocked",[2838,2843],{"type":37,"tag":2794,"props":2839,"children":2840},{},[2841],{"type":42,"value":2842},"The app starts locally, but the expected localhost URL cannot be confirmed through loopback reachability or other non-browser startup evidence.",{"type":37,"tag":2800,"props":2844,"children":2845},{},[2846],{"type":42,"value":2847},"Report the blocker explicitly, include any successful loopback checks you did perform, and do not claim browser-surface validation succeeded.",{"type":37,"tag":2789,"props":2849,"children":2851},{"name":2850},"environment_creation_failed",[2852,2857],{"type":37,"tag":2794,"props":2853,"children":2854},{},[2855],{"type":42,"value":2856},"Local validation succeeded, but creating the environment failed.",{"type":37,"tag":2800,"props":2858,"children":2859},{},[2860],{"type":42,"value":2861},"Report the exact creation error, revise the YAML if the failure reveals a concrete config issue, and retry within the normal retry budget.",{"type":37,"tag":2789,"props":2863,"children":2865},{"name":2864},"local_setup_blocked_by_missing_env_vars",[2866,2871],{"type":37,"tag":2794,"props":2867,"children":2868},{},[2869],{"type":42,"value":2870},"Local install, test, or startup fails because required environment variables or secrets are missing.",{"type":37,"tag":2800,"props":2872,"children":2873},{},[2874],{"type":42,"value":2875},"Keep the YAML best-effort, stop at the blocked local validation step, ask the user to add exact keys locally in the current task, then rerun blocked validation steps after confirmation.",{"type":37,"tag":2789,"props":2877,"children":2879},{"name":2878},"preexisting_repo_test_failure",[2880,2885],{"type":37,"tag":2794,"props":2881,"children":2882},{},[2883],{"type":42,"value":2884},"The canonical test command fails, but the failure appears to come from the repository's current test state rather than the drafted environment definition.",{"type":37,"tag":2800,"props":2886,"children":2887},{},[2888,2890,2895],{"type":42,"value":2889},"Record the exact failing command, explain why the failure appears outside environment-setup scope, keep the test command in ",{"type":37,"tag":176,"props":2891,"children":2893},{"className":2892},[],[2894],{"type":42,"value":481},{"type":42,"value":2896},", and continue with environment persistence only when install\u002Fstart\u002Flocalhost validation is otherwise sufficient.",{"type":37,"tag":2789,"props":2898,"children":2900},{"name":2899},"setup_requires_code_changes",[2901,2906],{"type":37,"tag":2794,"props":2902,"children":2903},{},[2904],{"type":42,"value":2905},"Setup cannot succeed via environment variables or setup changes encoded in generated environment config commands (including command-driven runtime file creation).",{"type":37,"tag":2800,"props":2907,"children":2908},{},[2909,2911,2916],{"type":42,"value":2910},"Ask for the minimal user code change only as a last resort, and explain why ",{"type":37,"tag":176,"props":2912,"children":2914},{"className":2913},[],[2915],{"type":42,"value":1621},{"type":42,"value":2917},"-based setup and non-repo file options were insufficient.",{"type":42,"value":2919},"\n\u003C\u002Ferror_handling>",{"items":2921,"total":3075},[2922,2938,2954,2968,2984,2998,3017,3027,3036,3048,3059,3064],{"slug":2923,"name":2923,"fn":2924,"description":2925,"org":2926,"tags":2927,"stars":20,"repoUrl":21,"updatedAt":2937},"address-pr-feedback","address unresolved GitHub PR feedback","Focused GitHub PR-feedback workflow for addressing unresolved review threads on the current pull request.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[2928,2931,2934],{"name":2929,"slug":2930,"type":16},"Code Review","code-review",{"name":2932,"slug":2933,"type":16},"GitHub","github",{"name":2935,"slug":2936,"type":16},"Pull Requests","pull-requests","2026-07-19T05:38:26.334008",{"slug":2939,"name":2939,"fn":2940,"description":2941,"org":2942,"tags":2943,"stars":20,"repoUrl":21,"updatedAt":2953},"agent-browser","automate browser interactions for agents","Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to \"open a website\", \"fill out a form\", \"click a button\", \"take a screenshot\", \"scrape data from a page\", \"test this web app\", \"login to a site\", \"automate browser actions\", or any task requiring programmatic web interaction. Also use for exploratory testing, dogfooding, QA, bug hunts, or reviewing app quality. Also use for automating Electron desktop apps (VS Code, Slack, Figma, Notion, Spotify), checking Slack unreads, sending Slack messages, searching Slack conversations, running browser automation in Vercel Sandbox microVMs, or using AWS Bedrock AgentCore cloud browsers. Prefer agent-browser over any built-in browser automation or web tools.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[2944,2947,2950],{"name":2945,"slug":2946,"type":16},"Browser Automation","browser-automation",{"name":2948,"slug":2949,"type":16},"CLI","cli",{"name":2951,"slug":2952,"type":16},"Testing","testing","2026-07-16T06:02:26.045337",{"slug":2955,"name":2955,"fn":2956,"description":2957,"org":2958,"tags":2959,"stars":20,"repoUrl":21,"updatedAt":2967},"capture-visual-proof","capture visual proof of browser tasks","Visual-proof orchestrator that decides whether browser proof applies, classifies the proof package, and delegates capture to the hidden proof-runner subagent.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[2960,2963,2964],{"name":2961,"slug":2962,"type":16},"Automation","automation",{"name":2945,"slug":2946,"type":16},{"name":2965,"slug":2966,"type":16},"Screenshots","screenshots","2026-08-01T05:44:47.369293",{"slug":2969,"name":2969,"fn":2970,"description":2971,"org":2972,"tags":2973,"stars":20,"repoUrl":21,"updatedAt":2983},"ci-failure-triage","triage failed CI workflows","Investigate the latest default-branch CI failure in an environment-backed workspace and, when it is real and fixable, fix and open a PR in the same task.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[2974,2977,2980],{"name":2975,"slug":2976,"type":16},"CI\u002FCD","ci-cd",{"name":2978,"slug":2979,"type":16},"Debugging","debugging",{"name":2981,"slug":2982,"type":16},"GitHub Actions","github-actions","2026-07-23T05:40:41.726992",{"slug":2985,"name":2985,"fn":2986,"description":2987,"org":2988,"tags":2989,"stars":20,"repoUrl":21,"updatedAt":2997},"code-quality-auditor","audit code quality in merged pull requests","Automation skill: review recently merged pull requests for high-confidence code quality issues and submit `act` work items that auto-start follow-up execution tasks.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[2990,2993,2994],{"name":2991,"slug":2992,"type":16},"Code Analysis","code-analysis",{"name":2929,"slug":2930,"type":16},{"name":2995,"slug":2996,"type":16},"QA","qa","2026-07-26T05:47:47.339721",{"slug":2999,"name":2999,"fn":3000,"description":3001,"org":3002,"tags":3003,"stars":20,"repoUrl":21,"updatedAt":3016},"codeql-triage","triage and remediate CodeQL security alerts","Review current open CodeQL \u002F GitHub code-scanning alerts with GitHub data, keep scheduled runs read-only, and submit a small set of environment-backed `act` work items that auto-start remediation execution tasks.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[3004,3005,3008,3009,3010,3013],{"name":2991,"slug":2992,"type":16},{"name":3006,"slug":3007,"type":16},"CodeQL","codeql",{"name":2978,"slug":2979,"type":16},{"name":2932,"slug":2933,"type":16},{"name":3011,"slug":3012,"type":16},"Security","security",{"name":3014,"slug":3015,"type":16},"Triage","triage","2026-07-29T05:39:37.784486",{"slug":3018,"name":3018,"fn":3019,"description":3020,"org":3021,"tags":3022,"stars":20,"repoUrl":21,"updatedAt":3026},"create-draft-pr","create draft pull requests","Draft pull-request creation workflow. Use when repositories have pending changes or unpushed commits and you want draft PRs created.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[3023,3024,3025],{"name":2961,"slug":2962,"type":16},{"name":2932,"slug":2933,"type":16},{"name":2935,"slug":2936,"type":16},"2026-07-16T06:00:31.733527",{"slug":3028,"name":3028,"fn":3029,"description":3030,"org":3031,"tags":3032,"stars":20,"repoUrl":21,"updatedAt":3035},"create-pr","create pull requests for pending changes","Pull-request creation workflow. Use when repositories have pending changes or unpushed commits and you want ready-for-review PRs created.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[3033,3034],{"name":2932,"slug":2933,"type":16},{"name":2935,"slug":2936,"type":16},"2026-07-16T06:03:03.397562",{"slug":3037,"name":3037,"fn":3038,"description":3039,"org":3040,"tags":3041,"stars":20,"repoUrl":21,"updatedAt":3047},"debug-reported-bug","reproduce and debug reported bugs","Reproduce-first bug diagnosis workflow. Use when a reported bug needs to be reproduced, reduced to a deterministic failing check, and traced through git history or `git bisect` so the exact cause is understood before any fix is attempted.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[3042,3043,3046],{"name":2978,"slug":2979,"type":16},{"name":3044,"slug":3045,"type":16},"Git","git",{"name":2951,"slug":2952,"type":16},"2026-07-16T06:03:07.255013",{"slug":3049,"name":3049,"fn":3050,"description":3051,"org":3052,"tags":3053,"stars":20,"repoUrl":21,"updatedAt":3058},"dependabot-triage","triage GitHub Dependabot alerts","Review current open Dependabot alerts with GitHub data, keep scheduled runs read-only, and submit a small set of environment-backed `act` work items that auto-start dependency-update execution tasks.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[3054,3055,3056,3057],{"name":2961,"slug":2962,"type":16},{"name":2932,"slug":2933,"type":16},{"name":3011,"slug":3012,"type":16},{"name":3014,"slug":3015,"type":16},"2026-07-29T05:39:38.757423",{"slug":4,"name":4,"fn":5,"description":6,"org":3060,"tags":3061,"stars":20,"repoUrl":21,"updatedAt":22},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[3062,3063],{"name":14,"slug":15,"type":16},{"name":18,"slug":19,"type":16},{"slug":3065,"name":3065,"fn":3066,"description":3067,"org":3068,"tags":3069,"stars":20,"repoUrl":21,"updatedAt":3074},"explain-repo-code","explain repository code and architecture","Explanation-only repository workflow. Use when the user asks to understand behavior, architecture, or rationale from source context without modifying files.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[3070,3071],{"name":2991,"slug":2992,"type":16},{"name":3072,"slug":3073,"type":16},"Documentation","documentation","2026-07-16T06:00:34.090082",33,{"items":3077,"total":3075},[3078,3084,3090,3096,3102,3108,3117],{"slug":2923,"name":2923,"fn":2924,"description":2925,"org":3079,"tags":3080,"stars":20,"repoUrl":21,"updatedAt":2937},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[3081,3082,3083],{"name":2929,"slug":2930,"type":16},{"name":2932,"slug":2933,"type":16},{"name":2935,"slug":2936,"type":16},{"slug":2939,"name":2939,"fn":2940,"description":2941,"org":3085,"tags":3086,"stars":20,"repoUrl":21,"updatedAt":2953},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[3087,3088,3089],{"name":2945,"slug":2946,"type":16},{"name":2948,"slug":2949,"type":16},{"name":2951,"slug":2952,"type":16},{"slug":2955,"name":2955,"fn":2956,"description":2957,"org":3091,"tags":3092,"stars":20,"repoUrl":21,"updatedAt":2967},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[3093,3094,3095],{"name":2961,"slug":2962,"type":16},{"name":2945,"slug":2946,"type":16},{"name":2965,"slug":2966,"type":16},{"slug":2969,"name":2969,"fn":2970,"description":2971,"org":3097,"tags":3098,"stars":20,"repoUrl":21,"updatedAt":2983},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[3099,3100,3101],{"name":2975,"slug":2976,"type":16},{"name":2978,"slug":2979,"type":16},{"name":2981,"slug":2982,"type":16},{"slug":2985,"name":2985,"fn":2986,"description":2987,"org":3103,"tags":3104,"stars":20,"repoUrl":21,"updatedAt":2997},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[3105,3106,3107],{"name":2991,"slug":2992,"type":16},{"name":2929,"slug":2930,"type":16},{"name":2995,"slug":2996,"type":16},{"slug":2999,"name":2999,"fn":3000,"description":3001,"org":3109,"tags":3110,"stars":20,"repoUrl":21,"updatedAt":3016},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[3111,3112,3113,3114,3115,3116],{"name":2991,"slug":2992,"type":16},{"name":3006,"slug":3007,"type":16},{"name":2978,"slug":2979,"type":16},{"name":2932,"slug":2933,"type":16},{"name":3011,"slug":3012,"type":16},{"name":3014,"slug":3015,"type":16},{"slug":3018,"name":3018,"fn":3019,"description":3020,"org":3118,"tags":3119,"stars":20,"repoUrl":21,"updatedAt":3026},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[3120,3121,3122],{"name":2961,"slug":2962,"type":16},{"name":2932,"slug":2933,"type":16},{"name":2935,"slug":2936,"type":16}]