[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-roo-code-doctor":3,"mdc--c9z6p8-key":37,"related-org-roo-code-doctor":603,"related-repo-roo-code-doctor":761},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":12,"stars":26,"repoUrl":27,"updatedAt":28,"license":29,"forks":30,"topics":31,"repo":32,"sourceUrl":35,"mdContent":36},"doctor","orchestrate environment health checks","Explicit environment-health orchestration workflow. Launch a fresh Roomote task against the target environment, assess its real startup and requested journey, classify ownership, delegate only authorized repairs, and verify again.",{"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,20,23],{"name":14,"slug":15,"type":16},"Operations","operations","tag",{"name":18,"slug":19,"type":16},"Monitoring","monitoring",{"name":21,"slug":22,"type":16},"Engineering","engineering",{"name":24,"slug":25,"type":16},"Debugging","debugging",5,"https:\u002F\u002Fgithub.com\u002FRooCodeInc\u002FRoomote","2026-08-14T04:52:03.207983",null,0,[],{"repoUrl":27,"stars":26,"forks":30,"topics":33,"description":34},[],"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\u002Fdoctor","---\nname: doctor\ndescription: Explicit environment-health orchestration workflow. Launch a fresh Roomote task against the target environment, assess its real startup and requested journey, classify ownership, delegate only authorized repairs, and verify again.\n---\n\n\u003Crole>\nYou are the Roomote Doctor. Doctor is an explicitly invoked workflow, not a diagnostic tool or a persistent agent identity. Use Roomote's existing task runtime as the end-to-end health check: a fresh task must prove that the target environment can be selected, scheduled, prepared, and used for the outcome the user actually needs.\n\u003C\u002Frole>\n\n\u003Cworkflow>\n  \u003Coverview>Resolve the intended environment and task-specific success criterion, launch one ordinary read-only verification task against that environment through the Roomote MCP, monitor its real setup and task outcome, classify the failing ownership boundary, delegate only an explicitly authorized repair, and verify any repair with fresh-task evidence.\u003C\u002Foverview>\n\n  \u003Cphase name=\"target\">\n    \u003Csteps>\n      \u003Cstep number=\"1\">\n        \u003Ctitle>Resolve the target and goal\u003C\u002Ftitle>\n        \u003Cactions>\n          \u003Caction>Derive the requested health goal from the user's words, available failure context, and repository evidence. There is no universal Doctor checklist. Do not invent a startup, service, preview, browser, port, test, build, migration, performance, clean-tree, container, process-supervisor, or database requirement.\u003C\u002Faction>\n          \u003Caction>Use a concise task-specific goal such as command execution, dependency installation, artifact production, background-job processing, migration execution, service behavior, test execution, or browser interaction. These are examples, not a closed taxonomy.\u003C\u002Faction>\n          \u003Caction>Establish the context task before resolving omitted details. Use an exact Roomote task ID or URL supplied by the user; otherwise read only `ROOMOTE_TASK_ID` from the current runtime and use the current task. Never dump the full process environment.\u003C\u002Faction>\n          \u003Caction>When the request is broad or symptom-only, such as \"the environment is not working,\" recover the failed capability from that context task before falling back to general readiness.\u003C\u002Faction>\n          \u003Caction>When failure-context recovery is required, call `mcp__roomote__manage_tasks` with `action: \"get_summary\"` and `action: \"get_messages\"` for the context task. From the user's requests and the task's latest relevant evidence, identify the last concrete attempted journey, any surfaced setup or runtime failure, and the user-visible symptom. If the task failed before it could report useful evidence and compute logs are available, call `action: \"get_compute_logs\"` and inspect only the relevant secret-safe lines.\u003C\u002Faction>\n          \u003Caction>Use recovered context only to choose what the fresh task must reproduce. Do not accept a previous task's diagnosis, ownership classification, apparent success, or suggested repair as proof. Do not copy environment-variable values, credentials, cookies, authorization material, complete request or response bodies, or secret-bearing URLs into the verification prompt or report.\u003C\u002Faction>\n          \u003Caction>If the recovered evidence identifies one concrete capability, use it as the requested health goal. If it identifies multiple materially different capabilities and the choice changes what must be launched or exercised, ask one focused question instead of choosing arbitrarily. If no concrete capability can be recovered, use the general environment-readiness fallback below and state in the final report exactly what that fallback did and did not prove.\u003C\u002Faction>\n          \u003Caction>Resolve the exact target environment before launching verification. If the user supplied an environment ID or unambiguous name, call the Roomote MCP tool `mcp__roomote__manage_tasks` with `action: \"list_environments\"` and match it to the current returned data.\u003C\u002Faction>\n          \u003Caction>If the target was not explicit, call `action: \"get_summary\"` for the context task if its current summary was not already fetched, then use its linked environment ID. Cross-check that exact ID and name against an immediate `list_environments` result. The `__all_repositories__` organization-wide target is not a named environment and is never a fallback for a missing linked environment. If the context task has no linked environment or the target remains ambiguous, ask the user instead of guessing.\u003C\u002Faction>\n          \u003Caction>Do not treat the current Doctor task's sandbox as proof that a new task can use the environment. The required baseline is a fresh Roomote task launched after the target and goal are known.\u003C\u002Faction>\n        \u003C\u002Factions>\n      \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\n  \u003Cphase name=\"verification_launch\">\n    \u003Csteps>\n      \u003Cstep number=\"2\">\n        \u003Ctitle>Launch the end-to-end verification task\u003C\u002Ftitle>\n        \u003Cactions>\n          \u003Caction>Immediately before every verification launch, call `mcp__roomote__manage_tasks` with `action: \"list_environments\"` and copy the exact current environment ID.\u003C\u002Faction>\n          \u003Caction>Call `mcp__roomote__manage_tasks` with `action: \"launch\"`, that `environmentId`, and `notifyOnSettle: true`. Preserve an exact branch or ref supplied by the user or current task evidence. Otherwise leave the branch unset. If the launch API requires a branch, resolve the repository's current or default branch from task or repository evidence and retry once; never guess a branch name.\u003C\u002Faction>\n          \u003Caction>The launched task is an ordinary verification task. Its prompt must not invoke Doctor or another workflow skill, delegate another task, repair anything, update the environment, edit repository files, create commits, or open a pull request. It may use an installed operational skill when needed to operate an applicable tool, such as browser instructions for a discovered web journey.\u003C\u002Faction>\n          \u003Caction>Give the launched task one concrete success criterion matching the requested goal. Require it to wait for `.roomote\u002Fsetup-status.json` to reach a terminal state when that file exists, reproduce the requested developer or user journey using the repository's own instructions and available tools, and report `ready`, `not_ready`, or `blocked` with the exact attempted steps and secret-safe evidence.\u003C\u002Faction>\n          \u003Caction>Only when no concrete failed capability was requested or recovered, use the general environment-readiness fallback: require the launched task to discover the repository's intended developer entrypoint and prove that it starts and performs its basic documented function. If the repository has no runnable application, it must say so and verify the nearest evidence-backed workflow instead of inventing an app or server.\u003C\u002Faction>\n          \u003Caction>Require the launched task to report failed setup command names and exit codes plus only the relevant sanitized setup-log lines when setup fails. It must never print environment-variable values, credentials, cookies, authorization headers, bypass headers, complete request or response bodies, or secret-bearing URLs.\u003C\u002Faction>\n          \u003Caction>The launched task must not assume the repository is a web app. It must choose evidence appropriate to the actual goal: command exit and output, produced artifacts, a completed job and observable effect, migration result, protocol behavior, test result, measured operation, or a completed browser interaction.\u003C\u002Faction>\n          \u003Caction>Only when the requested goal includes a Roomote browser preview, require the launched task to verify both the applicable local service boundary and the authenticated external `ROOMOTE_\u003CNAME>_PREVIEW_URL` with the installed `agent-browser` wrapper. It must inspect page errors, console errors, and failed or blocked journey-critical network requests; document HTTP 2xx\u002F3xx alone is insufficient.\u003C\u002Faction>\n          \u003Caction>For an applicable browser journey, optional analytics, telemetry, favicon, development-only HMR, or other irrelevant noise is non-blocking only when the task explains why it cannot affect the requested journey.\u003C\u002Faction>\n        \u003C\u002Factions>\n      \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\n  \u003Cphase name=\"monitoring\">\n    \u003Csteps>\n      \u003Cstep number=\"3\">\n        \u003Ctitle>Monitor Roomote's real result\u003C\u002Ftitle>\n        \u003Cactions>\n          \u003Caction>Keep the returned task ID for monitoring. The `notifyOnSettle: true` message is the primary completion signal. While waiting, call `mcp__roomote__manage_tasks` with `action: \"get_summary\"` every 10-15 seconds only to report progress or surface an early failure.\u003C\u002Faction>\n          \u003Caction>Do not return the final Doctor outcome merely because polling finds a settled summary or the child has posted its result. Wait for the `Spawned task update` notification, then inspect the final summary and messages and return exactly once. Only if the notification is still absent 60 seconds after polling first observes a settled task may the polled result become the fallback completion signal.\u003C\u002Faction>\n          \u003Caction>If an automated settle notification arrives after an outcome has already been reported, consume it silently as confirmation. Never emit a second user-facing outcome or confirmation for the same verification task.\u003C\u002Faction>\n          \u003Caction>Use the summary's `Environment Setup` line as the platform source of truth. Setup still running is normal startup, `completed` means only that preparation finished, and `failed` or `completed with warnings` is direct evidence of setup trouble.\u003C\u002Faction>\n          \u003Caction>When the task completes, fails, becomes idle, or asks for input, call `mcp__roomote__manage_tasks` with `action: \"get_messages\"`. A completed task state is not proof that the goal passed; inspect the task's explicit `ready`, `not_ready`, or `blocked` result and evidence.\u003C\u002Faction>\n          \u003Caction>Use `action: \"get_compute_logs\"` when the task failed before it could report enough evidence and the compute provider exposes logs. Do not expose secrets from those logs.\u003C\u002Faction>\n          \u003Caction>The fresh task itself verifies Roomote scheduling, provider selection, sandbox creation, repository preparation, environment setup, and agent execution up to the exact point observed. Do not replace that end-to-end evidence with a parallel collection of technology-specific probes.\u003C\u002Faction>\n        \u003C\u002Factions>\n      \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\n  \u003Cphase name=\"assessment\">\n    \u003Csteps>\n      \u003Cstep number=\"4\">\n        \u003Ctitle>Classify the failing boundary\u003C\u002Ftitle>\n        \u003Cactions>\n          \u003Caction>Classify ownership by the smallest boundary where a durable correction belongs: `environment_configuration`, `repository`, `roomote_platform`, `external_dependency`, or `undetermined`.\u003C\u002Faction>\n          \u003Caction>Use `environment_configuration` when the persisted Roomote environment definition or its wiring differs from the repository's real requirements.\u003C\u002Faction>\n          \u003Caction>Use `repository` when the required runtime inputs are correctly supplied and the durable correction belongs in application code, tests, or checked-in configuration.\u003C\u002Faction>\n          \u003Caction>Use `roomote_platform` only when fresh-task evidence points to Roomote-owned scheduling, compute-provider selection, sandbox lifecycle, repository preparation, proxying, task completion, or communication delivery.\u003C\u002Faction>\n          \u003Caction>Use `external_dependency` for unavailable credentials, third-party outages, unsupported infrastructure, or resources Roomote does not control. Use `undetermined` when the fresh task cannot distinguish the boundary.\u003C\u002Faction>\n          \u003Caction>Never classify ownership from a symptom or technology name alone. A timeout, connection refusal, authentication failure, CORS error, or host rejection can belong to any boundary.\u003C\u002Faction>\n          \u003Caction>For CORS or allowed-host failures, identify the expected origin or host, reproduce it through the actual route, and locate the rejecting boundary. Do not assume the application is wrong merely because the browser reports the symptom.\u003C\u002Faction>\n        \u003C\u002Factions>\n      \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\n  \u003Cphase name=\"repair\">\n    \u003Csteps>\n      \u003Cstep number=\"5\">\n        \u003Ctitle>Delegate only authorized repair\u003C\u002Ftitle>\n        \u003Cactions>\n          \u003Caction>Doctor is read-only by default. Launching and monitoring a verification task does not authorize environment edits, source changes, restarts, retries that mutate state, commits, or pull requests.\u003C\u002Faction>\n          \u003Caction>If the user explicitly requested repair and ownership is `environment_configuration`, transition to the packaged `environment-setup` workflow for the identified existing environment.\u003C\u002Faction>\n          \u003Caction>If the user explicitly requested repair and ownership is `repository`, transition to `implement-changes` and use its normal validation and draft-pull-request delivery path.\u003C\u002Faction>\n          \u003Caction>If required variable names are known but values are unavailable, use the secure environment-variable request flow. Never ask for secret values in chat.\u003C\u002Faction>\n          \u003Caction>Never repair an origin or host-policy failure with a wildcard, disabled host checking, reflective origin behavior, or broadly permissive CORS. Authorize only the narrow host, origin, method, and headers established by evidence. If the trust boundary is ambiguous, do not weaken it.\u003C\u002Faction>\n          \u003Caction>Do not repair `roomote_platform`, `external_dependency`, or `undetermined` failures. Report the observed boundary and the smallest action or decision needed.\u003C\u002Faction>\n          \u003Caction>Classifying an outcome as `roomote_platform` or `platform_issue` does not authorize filing or sending a platform report. Do not call `report_platform_issue`, create an issue, or claim that a report was filed unless the user explicitly requested that write.\u003C\u002Faction>\n        \u003C\u002Factions>\n      \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\n  \u003Cphase name=\"post_repair_verification\">\n    \u003Csteps>\n      \u003Cstep number=\"6\">\n        \u003Ctitle>Verify a repair from a fresh task\u003C\u002Ftitle>\n        \u003Cactions>\n          \u003Caction>After an authorized repair, require another task launched against the newly persisted environment and repeat the original goal. Never use the pre-repair task, the repair workflow's successful return, or the current sandbox as proof.\u003C\u002Faction>\n          \u003Caction>A fresh verification task launched and monitored by `environment-setup` may satisfy this requirement only when it used the repaired persisted environment and the same Doctor goal. Otherwise launch and monitor a new ordinary verification task through `manage_tasks`.\u003C\u002Faction>\n          \u003Caction>Do not claim `healthy` or `repaired` unless the latest fresh task explicitly completed the requested journey and Roomote's summary shows no setup or runtime failure that invalidates it.\u003C\u002Faction>\n          \u003Caction>Call `manage_environments` with `action: \"record_verification\"` only when the current task is explicitly the authorized environment-verification attempt. Otherwise leave persisted verification state unchanged.\u003C\u002Faction>\n        \u003C\u002Factions>\n      \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\n  \u003Cphase name=\"reporting\">\n    \u003Csteps>\n      \u003Cstep number=\"7\">\n        \u003Ctitle>Report the outcome\u003C\u002Ftitle>\n        \u003Cactions>\n          \u003Caction>Lead with one outcome: `healthy`, `repaired`, `unresolved`, `needs_user`, or `platform_issue`.\u003C\u002Faction>\n          \u003Caction>State the target environment, requested goal, fresh-task result, ownership classification and confidence, whether repair was authorized and performed, latest verification result, and any remaining blocker.\u003C\u002Faction>\n          \u003Caction>Keep evidence concrete and secret-safe. Distinguish Roomote-observed setup\u002Ftask state from conclusions reported by the verification task, and never claim a repair, verification, persisted status update, or platform report that did not occur.\u003C\u002Faction>\n        \u003C\u002Factions>\n      \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\u003C\u002Fworkflow>\n\n\u003Ccompletion_criteria>\n\u003Ccriterion>The exact target environment and task-specific health goal were established from the request or recovered failure context without inventing a technology or interface; general readiness was used only when no concrete failed capability could be recovered.\u003C\u002Fcriterion>\n\u003Ccriterion>An ordinary non-Doctor Roomote task was freshly launched against the target environment and monitored through `manage_tasks`.\u003C\u002Fcriterion>\n\u003Ccriterion>The assessment used the fresh task's actual setup state and requested-journey evidence rather than a bespoke diagnostic checklist.\u003C\u002Fcriterion>\n\u003Ccriterion>Any repair was explicitly authorized and delegated through an existing workflow.\u003C\u002Fcriterion>\n\u003Ccriterion>Any repaired outcome was verified by a fresh post-repair task repeating the original goal.\u003C\u002Fcriterion>\n\u003Ccriterion>The final outcome is concrete, secret-safe, and does not overclaim what the observed task proved.\u003C\u002Fcriterion>\n\u003C\u002Fcompletion_criteria>\n",{"data":38,"body":39},{"name":4,"description":6},{"type":40,"children":41},"root",[42,50,555],{"type":43,"tag":44,"props":45,"children":46},"element","role",{},[47],{"type":48,"value":49},"text","\nYou are the Roomote Doctor. Doctor is an explicitly invoked workflow, not a diagnostic tool or a persistent agent identity. Use Roomote's existing task runtime as the end-to-end health check: a fresh task must prove that the target environment can be selected, scheduled, prepared, and used for the outcome the user actually needs.\n",{"type":43,"tag":51,"props":52,"children":53},"workflow",{},[54,56,62,63,160,161,248,249,317,318,387,388,457,458,509,510],{"type":48,"value":55},"\n  ",{"type":43,"tag":57,"props":58,"children":59},"overview",{},[60],{"type":48,"value":61},"Resolve the intended environment and task-specific success criterion, launch one ordinary read-only verification task against that environment through the Roomote MCP, monitor its real setup and task outcome, classify the failing ownership boundary, delegate only an explicitly authorized repair, and verify any repair with fresh-task evidence.",{"type":48,"value":55},{"type":43,"tag":64,"props":65,"children":67},"phase",{"name":66},"target",[68,70,159],{"type":48,"value":69},"\n    ",{"type":43,"tag":71,"props":72,"children":73},"steps",{},[74,76,158],{"type":48,"value":75},"\n      ",{"type":43,"tag":77,"props":78,"children":80},"step",{"number":79},"1",[81,83,89,90,157],{"type":48,"value":82},"\n        ",{"type":43,"tag":84,"props":85,"children":86},"title",{},[87],{"type":48,"value":88},"Resolve the target and goal",{"type":48,"value":82},{"type":43,"tag":91,"props":92,"children":93},"actions",{},[94,96,102,103,108,109,114,115,120,121,126,127,132,133,138,139,144,145,150,151,156],{"type":48,"value":95},"\n          ",{"type":43,"tag":97,"props":98,"children":99},"action",{},[100],{"type":48,"value":101},"Derive the requested health goal from the user's words, available failure context, and repository evidence. There is no universal Doctor checklist. Do not invent a startup, service, preview, browser, port, test, build, migration, performance, clean-tree, container, process-supervisor, or database requirement.",{"type":48,"value":95},{"type":43,"tag":97,"props":104,"children":105},{},[106],{"type":48,"value":107},"Use a concise task-specific goal such as command execution, dependency installation, artifact production, background-job processing, migration execution, service behavior, test execution, or browser interaction. These are examples, not a closed taxonomy.",{"type":48,"value":95},{"type":43,"tag":97,"props":110,"children":111},{},[112],{"type":48,"value":113},"Establish the context task before resolving omitted details. Use an exact Roomote task ID or URL supplied by the user; otherwise read only `ROOMOTE_TASK_ID` from the current runtime and use the current task. Never dump the full process environment.",{"type":48,"value":95},{"type":43,"tag":97,"props":116,"children":117},{},[118],{"type":48,"value":119},"When the request is broad or symptom-only, such as \"the environment is not working,\" recover the failed capability from that context task before falling back to general readiness.",{"type":48,"value":95},{"type":43,"tag":97,"props":122,"children":123},{},[124],{"type":48,"value":125},"When failure-context recovery is required, call `mcp__roomote__manage_tasks` with `action: \"get_summary\"` and `action: \"get_messages\"` for the context task. From the user's requests and the task's latest relevant evidence, identify the last concrete attempted journey, any surfaced setup or runtime failure, and the user-visible symptom. If the task failed before it could report useful evidence and compute logs are available, call `action: \"get_compute_logs\"` and inspect only the relevant secret-safe lines.",{"type":48,"value":95},{"type":43,"tag":97,"props":128,"children":129},{},[130],{"type":48,"value":131},"Use recovered context only to choose what the fresh task must reproduce. Do not accept a previous task's diagnosis, ownership classification, apparent success, or suggested repair as proof. Do not copy environment-variable values, credentials, cookies, authorization material, complete request or response bodies, or secret-bearing URLs into the verification prompt or report.",{"type":48,"value":95},{"type":43,"tag":97,"props":134,"children":135},{},[136],{"type":48,"value":137},"If the recovered evidence identifies one concrete capability, use it as the requested health goal. If it identifies multiple materially different capabilities and the choice changes what must be launched or exercised, ask one focused question instead of choosing arbitrarily. If no concrete capability can be recovered, use the general environment-readiness fallback below and state in the final report exactly what that fallback did and did not prove.",{"type":48,"value":95},{"type":43,"tag":97,"props":140,"children":141},{},[142],{"type":48,"value":143},"Resolve the exact target environment before launching verification. If the user supplied an environment ID or unambiguous name, call the Roomote MCP tool `mcp__roomote__manage_tasks` with `action: \"list_environments\"` and match it to the current returned data.",{"type":48,"value":95},{"type":43,"tag":97,"props":146,"children":147},{},[148],{"type":48,"value":149},"If the target was not explicit, call `action: \"get_summary\"` for the context task if its current summary was not already fetched, then use its linked environment ID. Cross-check that exact ID and name against an immediate `list_environments` result. The `__all_repositories__` organization-wide target is not a named environment and is never a fallback for a missing linked environment. If the context task has no linked environment or the target remains ambiguous, ask the user instead of guessing.",{"type":48,"value":95},{"type":43,"tag":97,"props":152,"children":153},{},[154],{"type":48,"value":155},"Do not treat the current Doctor task's sandbox as proof that a new task can use the environment. The required baseline is a fresh Roomote task launched after the target and goal are known.",{"type":48,"value":82},{"type":48,"value":75},{"type":48,"value":69},{"type":48,"value":55},{"type":48,"value":55},{"type":43,"tag":64,"props":162,"children":164},{"name":163},"verification_launch",[165,166,247],{"type":48,"value":69},{"type":43,"tag":71,"props":167,"children":168},{},[169,170,246],{"type":48,"value":75},{"type":43,"tag":77,"props":171,"children":173},{"number":172},"2",[174,175,180,181,245],{"type":48,"value":82},{"type":43,"tag":84,"props":176,"children":177},{},[178],{"type":48,"value":179},"Launch the end-to-end verification task",{"type":48,"value":82},{"type":43,"tag":91,"props":182,"children":183},{},[184,185,190,191,196,197,202,203,208,209,214,215,220,221,226,227,238,239,244],{"type":48,"value":95},{"type":43,"tag":97,"props":186,"children":187},{},[188],{"type":48,"value":189},"Immediately before every verification launch, call `mcp__roomote__manage_tasks` with `action: \"list_environments\"` and copy the exact current environment ID.",{"type":48,"value":95},{"type":43,"tag":97,"props":192,"children":193},{},[194],{"type":48,"value":195},"Call `mcp__roomote__manage_tasks` with `action: \"launch\"`, that `environmentId`, and `notifyOnSettle: true`. Preserve an exact branch or ref supplied by the user or current task evidence. Otherwise leave the branch unset. If the launch API requires a branch, resolve the repository's current or default branch from task or repository evidence and retry once; never guess a branch name.",{"type":48,"value":95},{"type":43,"tag":97,"props":198,"children":199},{},[200],{"type":48,"value":201},"The launched task is an ordinary verification task. Its prompt must not invoke Doctor or another workflow skill, delegate another task, repair anything, update the environment, edit repository files, create commits, or open a pull request. It may use an installed operational skill when needed to operate an applicable tool, such as browser instructions for a discovered web journey.",{"type":48,"value":95},{"type":43,"tag":97,"props":204,"children":205},{},[206],{"type":48,"value":207},"Give the launched task one concrete success criterion matching the requested goal. Require it to wait for `.roomote\u002Fsetup-status.json` to reach a terminal state when that file exists, reproduce the requested developer or user journey using the repository's own instructions and available tools, and report `ready`, `not_ready`, or `blocked` with the exact attempted steps and secret-safe evidence.",{"type":48,"value":95},{"type":43,"tag":97,"props":210,"children":211},{},[212],{"type":48,"value":213},"Only when no concrete failed capability was requested or recovered, use the general environment-readiness fallback: require the launched task to discover the repository's intended developer entrypoint and prove that it starts and performs its basic documented function. If the repository has no runnable application, it must say so and verify the nearest evidence-backed workflow instead of inventing an app or server.",{"type":48,"value":95},{"type":43,"tag":97,"props":216,"children":217},{},[218],{"type":48,"value":219},"Require the launched task to report failed setup command names and exit codes plus only the relevant sanitized setup-log lines when setup fails. It must never print environment-variable values, credentials, cookies, authorization headers, bypass headers, complete request or response bodies, or secret-bearing URLs.",{"type":48,"value":95},{"type":43,"tag":97,"props":222,"children":223},{},[224],{"type":48,"value":225},"The launched task must not assume the repository is a web app. It must choose evidence appropriate to the actual goal: command exit and output, produced artifacts, a completed job and observable effect, migration result, protocol behavior, test result, measured operation, or a completed browser interaction.",{"type":48,"value":95},{"type":43,"tag":97,"props":228,"children":229},{},[230,232],{"type":48,"value":231},"Only when the requested goal includes a Roomote browser preview, require the launched task to verify both the applicable local service boundary and the authenticated external `ROOMOTE_",{"type":43,"tag":233,"props":234,"children":235},"name",{},[236],{"type":48,"value":237},"_PREVIEW_URL` with the installed `agent-browser` wrapper. It must inspect page errors, console errors, and failed or blocked journey-critical network requests; document HTTP 2xx\u002F3xx alone is insufficient.",{"type":48,"value":95},{"type":43,"tag":97,"props":240,"children":241},{},[242],{"type":48,"value":243},"For an applicable browser journey, optional analytics, telemetry, favicon, development-only HMR, or other irrelevant noise is non-blocking only when the task explains why it cannot affect the requested journey.",{"type":48,"value":82},{"type":48,"value":75},{"type":48,"value":69},{"type":48,"value":55},{"type":48,"value":55},{"type":43,"tag":64,"props":250,"children":251},{"name":19},[252,253,316],{"type":48,"value":69},{"type":43,"tag":71,"props":254,"children":255},{},[256,257,315],{"type":48,"value":75},{"type":43,"tag":77,"props":258,"children":260},{"number":259},"3",[261,262,267,268,314],{"type":48,"value":82},{"type":43,"tag":84,"props":263,"children":264},{},[265],{"type":48,"value":266},"Monitor Roomote's real result",{"type":48,"value":82},{"type":43,"tag":91,"props":269,"children":270},{},[271,272,277,278,283,284,289,290,295,296,301,302,307,308,313],{"type":48,"value":95},{"type":43,"tag":97,"props":273,"children":274},{},[275],{"type":48,"value":276},"Keep the returned task ID for monitoring. The `notifyOnSettle: true` message is the primary completion signal. While waiting, call `mcp__roomote__manage_tasks` with `action: \"get_summary\"` every 10-15 seconds only to report progress or surface an early failure.",{"type":48,"value":95},{"type":43,"tag":97,"props":279,"children":280},{},[281],{"type":48,"value":282},"Do not return the final Doctor outcome merely because polling finds a settled summary or the child has posted its result. Wait for the `Spawned task update` notification, then inspect the final summary and messages and return exactly once. Only if the notification is still absent 60 seconds after polling first observes a settled task may the polled result become the fallback completion signal.",{"type":48,"value":95},{"type":43,"tag":97,"props":285,"children":286},{},[287],{"type":48,"value":288},"If an automated settle notification arrives after an outcome has already been reported, consume it silently as confirmation. Never emit a second user-facing outcome or confirmation for the same verification task.",{"type":48,"value":95},{"type":43,"tag":97,"props":291,"children":292},{},[293],{"type":48,"value":294},"Use the summary's `Environment Setup` line as the platform source of truth. Setup still running is normal startup, `completed` means only that preparation finished, and `failed` or `completed with warnings` is direct evidence of setup trouble.",{"type":48,"value":95},{"type":43,"tag":97,"props":297,"children":298},{},[299],{"type":48,"value":300},"When the task completes, fails, becomes idle, or asks for input, call `mcp__roomote__manage_tasks` with `action: \"get_messages\"`. A completed task state is not proof that the goal passed; inspect the task's explicit `ready`, `not_ready`, or `blocked` result and evidence.",{"type":48,"value":95},{"type":43,"tag":97,"props":303,"children":304},{},[305],{"type":48,"value":306},"Use `action: \"get_compute_logs\"` when the task failed before it could report enough evidence and the compute provider exposes logs. Do not expose secrets from those logs.",{"type":48,"value":95},{"type":43,"tag":97,"props":309,"children":310},{},[311],{"type":48,"value":312},"The fresh task itself verifies Roomote scheduling, provider selection, sandbox creation, repository preparation, environment setup, and agent execution up to the exact point observed. Do not replace that end-to-end evidence with a parallel collection of technology-specific probes.",{"type":48,"value":82},{"type":48,"value":75},{"type":48,"value":69},{"type":48,"value":55},{"type":48,"value":55},{"type":43,"tag":64,"props":319,"children":321},{"name":320},"assessment",[322,323,386],{"type":48,"value":69},{"type":43,"tag":71,"props":324,"children":325},{},[326,327,385],{"type":48,"value":75},{"type":43,"tag":77,"props":328,"children":330},{"number":329},"4",[331,332,337,338,384],{"type":48,"value":82},{"type":43,"tag":84,"props":333,"children":334},{},[335],{"type":48,"value":336},"Classify the failing boundary",{"type":48,"value":82},{"type":43,"tag":91,"props":339,"children":340},{},[341,342,347,348,353,354,359,360,365,366,371,372,377,378,383],{"type":48,"value":95},{"type":43,"tag":97,"props":343,"children":344},{},[345],{"type":48,"value":346},"Classify ownership by the smallest boundary where a durable correction belongs: `environment_configuration`, `repository`, `roomote_platform`, `external_dependency`, or `undetermined`.",{"type":48,"value":95},{"type":43,"tag":97,"props":349,"children":350},{},[351],{"type":48,"value":352},"Use `environment_configuration` when the persisted Roomote environment definition or its wiring differs from the repository's real requirements.",{"type":48,"value":95},{"type":43,"tag":97,"props":355,"children":356},{},[357],{"type":48,"value":358},"Use `repository` when the required runtime inputs are correctly supplied and the durable correction belongs in application code, tests, or checked-in configuration.",{"type":48,"value":95},{"type":43,"tag":97,"props":361,"children":362},{},[363],{"type":48,"value":364},"Use `roomote_platform` only when fresh-task evidence points to Roomote-owned scheduling, compute-provider selection, sandbox lifecycle, repository preparation, proxying, task completion, or communication delivery.",{"type":48,"value":95},{"type":43,"tag":97,"props":367,"children":368},{},[369],{"type":48,"value":370},"Use `external_dependency` for unavailable credentials, third-party outages, unsupported infrastructure, or resources Roomote does not control. Use `undetermined` when the fresh task cannot distinguish the boundary.",{"type":48,"value":95},{"type":43,"tag":97,"props":373,"children":374},{},[375],{"type":48,"value":376},"Never classify ownership from a symptom or technology name alone. A timeout, connection refusal, authentication failure, CORS error, or host rejection can belong to any boundary.",{"type":48,"value":95},{"type":43,"tag":97,"props":379,"children":380},{},[381],{"type":48,"value":382},"For CORS or allowed-host failures, identify the expected origin or host, reproduce it through the actual route, and locate the rejecting boundary. Do not assume the application is wrong merely because the browser reports the symptom.",{"type":48,"value":82},{"type":48,"value":75},{"type":48,"value":69},{"type":48,"value":55},{"type":48,"value":55},{"type":43,"tag":64,"props":389,"children":391},{"name":390},"repair",[392,393,456],{"type":48,"value":69},{"type":43,"tag":71,"props":394,"children":395},{},[396,397,455],{"type":48,"value":75},{"type":43,"tag":77,"props":398,"children":400},{"number":399},"5",[401,402,407,408,454],{"type":48,"value":82},{"type":43,"tag":84,"props":403,"children":404},{},[405],{"type":48,"value":406},"Delegate only authorized repair",{"type":48,"value":82},{"type":43,"tag":91,"props":409,"children":410},{},[411,412,417,418,423,424,429,430,435,436,441,442,447,448,453],{"type":48,"value":95},{"type":43,"tag":97,"props":413,"children":414},{},[415],{"type":48,"value":416},"Doctor is read-only by default. Launching and monitoring a verification task does not authorize environment edits, source changes, restarts, retries that mutate state, commits, or pull requests.",{"type":48,"value":95},{"type":43,"tag":97,"props":419,"children":420},{},[421],{"type":48,"value":422},"If the user explicitly requested repair and ownership is `environment_configuration`, transition to the packaged `environment-setup` workflow for the identified existing environment.",{"type":48,"value":95},{"type":43,"tag":97,"props":425,"children":426},{},[427],{"type":48,"value":428},"If the user explicitly requested repair and ownership is `repository`, transition to `implement-changes` and use its normal validation and draft-pull-request delivery path.",{"type":48,"value":95},{"type":43,"tag":97,"props":431,"children":432},{},[433],{"type":48,"value":434},"If required variable names are known but values are unavailable, use the secure environment-variable request flow. Never ask for secret values in chat.",{"type":48,"value":95},{"type":43,"tag":97,"props":437,"children":438},{},[439],{"type":48,"value":440},"Never repair an origin or host-policy failure with a wildcard, disabled host checking, reflective origin behavior, or broadly permissive CORS. Authorize only the narrow host, origin, method, and headers established by evidence. If the trust boundary is ambiguous, do not weaken it.",{"type":48,"value":95},{"type":43,"tag":97,"props":443,"children":444},{},[445],{"type":48,"value":446},"Do not repair `roomote_platform`, `external_dependency`, or `undetermined` failures. Report the observed boundary and the smallest action or decision needed.",{"type":48,"value":95},{"type":43,"tag":97,"props":449,"children":450},{},[451],{"type":48,"value":452},"Classifying an outcome as `roomote_platform` or `platform_issue` does not authorize filing or sending a platform report. Do not call `report_platform_issue`, create an issue, or claim that a report was filed unless the user explicitly requested that write.",{"type":48,"value":82},{"type":48,"value":75},{"type":48,"value":69},{"type":48,"value":55},{"type":48,"value":55},{"type":43,"tag":64,"props":459,"children":461},{"name":460},"post_repair_verification",[462,463,508],{"type":48,"value":69},{"type":43,"tag":71,"props":464,"children":465},{},[466,467,507],{"type":48,"value":75},{"type":43,"tag":77,"props":468,"children":470},{"number":469},"6",[471,472,477,478,506],{"type":48,"value":82},{"type":43,"tag":84,"props":473,"children":474},{},[475],{"type":48,"value":476},"Verify a repair from a fresh task",{"type":48,"value":82},{"type":43,"tag":91,"props":479,"children":480},{},[481,482,487,488,493,494,499,500,505],{"type":48,"value":95},{"type":43,"tag":97,"props":483,"children":484},{},[485],{"type":48,"value":486},"After an authorized repair, require another task launched against the newly persisted environment and repeat the original goal. Never use the pre-repair task, the repair workflow's successful return, or the current sandbox as proof.",{"type":48,"value":95},{"type":43,"tag":97,"props":489,"children":490},{},[491],{"type":48,"value":492},"A fresh verification task launched and monitored by `environment-setup` may satisfy this requirement only when it used the repaired persisted environment and the same Doctor goal. Otherwise launch and monitor a new ordinary verification task through `manage_tasks`.",{"type":48,"value":95},{"type":43,"tag":97,"props":495,"children":496},{},[497],{"type":48,"value":498},"Do not claim `healthy` or `repaired` unless the latest fresh task explicitly completed the requested journey and Roomote's summary shows no setup or runtime failure that invalidates it.",{"type":48,"value":95},{"type":43,"tag":97,"props":501,"children":502},{},[503],{"type":48,"value":504},"Call `manage_environments` with `action: \"record_verification\"` only when the current task is explicitly the authorized environment-verification attempt. Otherwise leave persisted verification state unchanged.",{"type":48,"value":82},{"type":48,"value":75},{"type":48,"value":69},{"type":48,"value":55},{"type":48,"value":55},{"type":43,"tag":64,"props":511,"children":513},{"name":512},"reporting",[514,515,554],{"type":48,"value":69},{"type":43,"tag":71,"props":516,"children":517},{},[518,519,553],{"type":48,"value":75},{"type":43,"tag":77,"props":520,"children":522},{"number":521},"7",[523,524,529,530,552],{"type":48,"value":82},{"type":43,"tag":84,"props":525,"children":526},{},[527],{"type":48,"value":528},"Report the outcome",{"type":48,"value":82},{"type":43,"tag":91,"props":531,"children":532},{},[533,534,539,540,545,546,551],{"type":48,"value":95},{"type":43,"tag":97,"props":535,"children":536},{},[537],{"type":48,"value":538},"Lead with one outcome: `healthy`, `repaired`, `unresolved`, `needs_user`, or `platform_issue`.",{"type":48,"value":95},{"type":43,"tag":97,"props":541,"children":542},{},[543],{"type":48,"value":544},"State the target environment, requested goal, fresh-task result, ownership classification and confidence, whether repair was authorized and performed, latest verification result, and any remaining blocker.",{"type":48,"value":95},{"type":43,"tag":97,"props":547,"children":548},{},[549],{"type":48,"value":550},"Keep evidence concrete and secret-safe. Distinguish Roomote-observed setup\u002Ftask state from conclusions reported by the verification task, and never claim a repair, verification, persisted status update, or platform report that did not occur.",{"type":48,"value":82},{"type":48,"value":75},{"type":48,"value":69},{"type":48,"value":55},{"type":43,"tag":556,"props":557,"children":558},"p",{},[559,561,567,581,586,591,596,601],{"type":48,"value":560},"\u003Ccompletion_criteria>\n",{"type":43,"tag":562,"props":563,"children":564},"criterion",{},[565],{"type":48,"value":566},"The exact target environment and task-specific health goal were established from the request or recovered failure context without inventing a technology or interface; general readiness was used only when no concrete failed capability could be recovered.",{"type":43,"tag":562,"props":568,"children":569},{},[570,572,579],{"type":48,"value":571},"An ordinary non-Doctor Roomote task was freshly launched against the target environment and monitored through ",{"type":43,"tag":573,"props":574,"children":576},"code",{"className":575},[],[577],{"type":48,"value":578},"manage_tasks",{"type":48,"value":580},".",{"type":43,"tag":562,"props":582,"children":583},{},[584],{"type":48,"value":585},"The assessment used the fresh task's actual setup state and requested-journey evidence rather than a bespoke diagnostic checklist.",{"type":43,"tag":562,"props":587,"children":588},{},[589],{"type":48,"value":590},"Any repair was explicitly authorized and delegated through an existing workflow.",{"type":43,"tag":562,"props":592,"children":593},{},[594],{"type":48,"value":595},"Any repaired outcome was verified by a fresh post-repair task repeating the original goal.",{"type":43,"tag":562,"props":597,"children":598},{},[599],{"type":48,"value":600},"The final outcome is concrete, secret-safe, and does not overclaim what the observed task proved.",{"type":48,"value":602},"\n\u003C\u002Fcompletion_criteria>",{"items":604,"total":760},[605,621,637,651,665,679,698,708,717,729,740,747],{"slug":606,"name":606,"fn":607,"description":608,"org":609,"tags":610,"stars":26,"repoUrl":27,"updatedAt":620},"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},[611,614,617],{"name":612,"slug":613,"type":16},"Code Review","code-review",{"name":615,"slug":616,"type":16},"GitHub","github",{"name":618,"slug":619,"type":16},"Pull Requests","pull-requests","2026-07-19T05:38:26.334008",{"slug":622,"name":622,"fn":623,"description":624,"org":625,"tags":626,"stars":26,"repoUrl":27,"updatedAt":636},"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},[627,630,633],{"name":628,"slug":629,"type":16},"Browser Automation","browser-automation",{"name":631,"slug":632,"type":16},"CLI","cli",{"name":634,"slug":635,"type":16},"Testing","testing","2026-07-16T06:02:26.045337",{"slug":638,"name":638,"fn":639,"description":640,"org":641,"tags":642,"stars":26,"repoUrl":27,"updatedAt":650},"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},[643,646,647],{"name":644,"slug":645,"type":16},"Automation","automation",{"name":628,"slug":629,"type":16},{"name":648,"slug":649,"type":16},"Screenshots","screenshots","2026-08-01T05:44:47.369293",{"slug":652,"name":652,"fn":653,"description":654,"org":655,"tags":656,"stars":26,"repoUrl":27,"updatedAt":664},"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},[657,660,661],{"name":658,"slug":659,"type":16},"CI\u002FCD","ci-cd",{"name":24,"slug":25,"type":16},{"name":662,"slug":663,"type":16},"GitHub Actions","github-actions","2026-07-23T05:40:41.726992",{"slug":666,"name":666,"fn":667,"description":668,"org":669,"tags":670,"stars":26,"repoUrl":27,"updatedAt":678},"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},[671,674,675],{"name":672,"slug":673,"type":16},"Code Analysis","code-analysis",{"name":612,"slug":613,"type":16},{"name":676,"slug":677,"type":16},"QA","qa","2026-07-26T05:47:47.339721",{"slug":680,"name":680,"fn":681,"description":682,"org":683,"tags":684,"stars":26,"repoUrl":27,"updatedAt":697},"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},[685,686,689,690,691,694],{"name":672,"slug":673,"type":16},{"name":687,"slug":688,"type":16},"CodeQL","codeql",{"name":24,"slug":25,"type":16},{"name":615,"slug":616,"type":16},{"name":692,"slug":693,"type":16},"Security","security",{"name":695,"slug":696,"type":16},"Triage","triage","2026-07-29T05:39:37.784486",{"slug":699,"name":699,"fn":700,"description":701,"org":702,"tags":703,"stars":26,"repoUrl":27,"updatedAt":707},"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},[704,705,706],{"name":644,"slug":645,"type":16},{"name":615,"slug":616,"type":16},{"name":618,"slug":619,"type":16},"2026-07-16T06:00:31.733527",{"slug":709,"name":709,"fn":710,"description":711,"org":712,"tags":713,"stars":26,"repoUrl":27,"updatedAt":716},"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},[714,715],{"name":615,"slug":616,"type":16},{"name":618,"slug":619,"type":16},"2026-07-16T06:03:03.397562",{"slug":718,"name":718,"fn":719,"description":720,"org":721,"tags":722,"stars":26,"repoUrl":27,"updatedAt":728},"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},[723,724,727],{"name":24,"slug":25,"type":16},{"name":725,"slug":726,"type":16},"Git","git",{"name":634,"slug":635,"type":16},"2026-07-16T06:03:07.255013",{"slug":730,"name":730,"fn":731,"description":732,"org":733,"tags":734,"stars":26,"repoUrl":27,"updatedAt":739},"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},[735,736,737,738],{"name":644,"slug":645,"type":16},{"name":615,"slug":616,"type":16},{"name":692,"slug":693,"type":16},{"name":695,"slug":696,"type":16},"2026-07-29T05:39:38.757423",{"slug":4,"name":4,"fn":5,"description":6,"org":741,"tags":742,"stars":26,"repoUrl":27,"updatedAt":28},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[743,744,745,746],{"name":24,"slug":25,"type":16},{"name":21,"slug":22,"type":16},{"name":18,"slug":19,"type":16},{"name":14,"slug":15,"type":16},{"slug":748,"name":748,"fn":749,"description":750,"org":751,"tags":752,"stars":26,"repoUrl":27,"updatedAt":759},"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},[753,756],{"name":754,"slug":755,"type":16},"Configuration","configuration",{"name":757,"slug":758,"type":16},"Local Development","local-development","2026-08-14T04:28:23.23408",36,{"items":762,"total":760},[763,769,775,781,787,793,802],{"slug":606,"name":606,"fn":607,"description":608,"org":764,"tags":765,"stars":26,"repoUrl":27,"updatedAt":620},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[766,767,768],{"name":612,"slug":613,"type":16},{"name":615,"slug":616,"type":16},{"name":618,"slug":619,"type":16},{"slug":622,"name":622,"fn":623,"description":624,"org":770,"tags":771,"stars":26,"repoUrl":27,"updatedAt":636},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[772,773,774],{"name":628,"slug":629,"type":16},{"name":631,"slug":632,"type":16},{"name":634,"slug":635,"type":16},{"slug":638,"name":638,"fn":639,"description":640,"org":776,"tags":777,"stars":26,"repoUrl":27,"updatedAt":650},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[778,779,780],{"name":644,"slug":645,"type":16},{"name":628,"slug":629,"type":16},{"name":648,"slug":649,"type":16},{"slug":652,"name":652,"fn":653,"description":654,"org":782,"tags":783,"stars":26,"repoUrl":27,"updatedAt":664},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[784,785,786],{"name":658,"slug":659,"type":16},{"name":24,"slug":25,"type":16},{"name":662,"slug":663,"type":16},{"slug":666,"name":666,"fn":667,"description":668,"org":788,"tags":789,"stars":26,"repoUrl":27,"updatedAt":678},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[790,791,792],{"name":672,"slug":673,"type":16},{"name":612,"slug":613,"type":16},{"name":676,"slug":677,"type":16},{"slug":680,"name":680,"fn":681,"description":682,"org":794,"tags":795,"stars":26,"repoUrl":27,"updatedAt":697},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[796,797,798,799,800,801],{"name":672,"slug":673,"type":16},{"name":687,"slug":688,"type":16},{"name":24,"slug":25,"type":16},{"name":615,"slug":616,"type":16},{"name":692,"slug":693,"type":16},{"name":695,"slug":696,"type":16},{"slug":699,"name":699,"fn":700,"description":701,"org":803,"tags":804,"stars":26,"repoUrl":27,"updatedAt":707},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[805,806,807],{"name":644,"slug":645,"type":16},{"name":615,"slug":616,"type":16},{"name":618,"slug":619,"type":16}]