[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-roo-code-update-dependencies":3,"mdc--8snr3p-key":34,"related-org-roo-code-update-dependencies":1007,"related-repo-roo-code-update-dependencies":1168},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":12,"stars":23,"repoUrl":24,"updatedAt":25,"license":26,"forks":27,"topics":28,"repo":29,"sourceUrl":32,"mdContent":33},"update-dependencies","maintain and upgrade project dependencies","Repository-agnostic dependency maintenance workflow. Use when a task should check for dependency updates, apply safe upgrades, validate the target repository with its own tooling and runtime surfaces, and deliver the result through review-friendly automation.",{"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],{"name":14,"slug":15,"type":16},"Maintenance","maintenance","tag",{"name":18,"slug":19,"type":16},"Automation","automation",{"name":21,"slug":22,"type":16},"Engineering","engineering",5,"https:\u002F\u002Fgithub.com\u002FRooCodeInc\u002FRoomote","2026-07-26T05:47:50.360258",null,0,[],{"repoUrl":24,"stars":23,"forks":27,"topics":30,"description":31},[],"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\u002Fupdate-dependencies","---\nname: update-dependencies\nversion: 1.2.0\ndescription: 'Repository-agnostic dependency maintenance workflow. Use when a task should check for dependency updates, apply safe upgrades, validate the target repository with its own tooling and runtime surfaces, and deliver the result through review-friendly automation.'\n---\n\n# Update Dependencies\n\nThis checked-in skill is the shared source-of-truth copy for dependency-update workflow behavior. It is packaged with the worker so customer-repo Dependabot follow-up tasks can invoke `$update-dependencies` without depending on a repo-local skill checkout.\n\n\u003Crole>\nYou are a dependency maintenance specialist. Keep dependency upgrades small, safe, validated, and repeatable. Derive package manager, validation commands, runtime proof, and workspace scope from the target repository instead of assuming Roomote-specific tooling.\n\u003C\u002Frole>\n\n\u003Cworkflow>\n  \u003Coverview>Execute a dependency update workflow with two first-class modes: recurring maintenance and Dependabot alert follow-up. Inspect manifests and lockfiles, choose a narrow safe update scope, apply compatible updates, run the strongest practical repository-defined validation, and deliver the result through a review-friendly path. Maintenance runs should stay scheduled-friendly, while Dependabot follow-ups should start with alert re-verification, stay scoped to the named package or manifest slice, and widen only to the smallest cohesive remediation that actually clears the alert instead of defaulting to deferral. When an updated dependency can affect a running service, prove the service still works at runtime instead of stopping at manifest or lockfile hygiene.\u003C\u002Foverview>\n\n  \u003Cphase name=\"analysis\">\n    \u003Cdescription>Understand the repository and the safest update scope before changing manifests or lockfiles.\u003C\u002Fdescription>\n    \u003Csteps>\n      \u003Cstep number=\"1\">\n        \u003Ctitle>Classify the run mode\u003C\u002Ftitle>\n        \u003Cdescription>Decide whether this is a recurring maintenance run or an explicit Dependabot alert follow-up before doing broader dependency discovery.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Read the task context for explicit run-mode clues such as `alert_follow_up`, Dependabot alert URLs or numbers, requested package names, manifest paths, or triage investigation context.\u003C\u002Faction>\n          \u003Caction>If the run is a Dependabot alert follow-up, branch immediately into the alert-first path for the rest of analysis: re-verify the cited alert before any generic outdated-report logic, keep the working scope limited to the named package, manifest, or tightly related workspace slice, and do not broaden into repository-wide maintenance unless the user explicitly asks.\u003C\u002Faction>\n          \u003Caction>If the run is ordinary maintenance, continue with the scheduled-friendly discovery path and use non-mutating outdated reports to pick a safe narrow update set.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>You know whether this run should behave like maintenance or like a Dependabot remediation task, and the rest of analysis is scoped accordingly.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n      \u003Cstep number=\"2\">\n        \u003Ctitle>Initialize task tracking\u003C\u002Ftitle>\n        \u003Cdescription>Create an explicit todo list that matches a dependency-maintenance run.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Create a todo list covering dependency surface discovery, update selection, implementation, validation, and delivery or no-op reporting.\u003C\u002Faction>\n          \u003Caction>For Dependabot alert follow-up runs, reflect the narrower alert-driven sequence in the todo list: re-verify alert -> resolve the named package or manifest slice -> validate -> deliver or report no-op or deferred.\u003C\u002Faction>\n          \u003Caction>Keep the visible plan scoped to dependency maintenance; do not add unrelated refactoring or feature work.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>A todo list exists and reflects the dependency-maintenance lifecycle.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n      \u003Cstep number=\"3\">\n        \u003Ctitle>Discover dependency surfaces\u003C\u002Ftitle>\n        \u003Cdescription>Identify package managers, manifests, lockfiles, workspace structure, and existing update policy.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Inspect dependency manifests and lockfiles such as `package.json`, `pnpm-lock.yaml`, `package-lock.json`, `yarn.lock`, `bun.lock`, `Cargo.toml`, `Cargo.lock`, `pyproject.toml`, `uv.lock`, `poetry.lock`, `requirements*.txt`, `go.mod`, `go.sum`, `Gemfile`, and `Gemfile.lock`.\u003C\u002Faction>\n          \u003Caction>Read repository guidance files, package-manager configuration, Renovate or Dependabot config, CI definitions, and docs that define supported update cadence or validation commands.\u003C\u002Faction>\n          \u003Caction>Infer the authoritative package manager from lockfiles and project tooling rather than mixing package managers.\u003C\u002Faction>\n          \u003Caction>For monorepos, identify the smallest workspace slice that can be updated and validated safely.\u003C\u002Faction>\n           \u003Caction>Map the selected package to the runtime surfaces it can affect: build-only tooling, shared libraries, backend services, CLIs, worker processes, or user-facing web apps. Use that impact map to decide which test suites and live-service checks are required later.\u003C\u002Faction>\n          \u003Caction>For Dependabot alert follow-up runs, stop discovery as soon as you have enough surface information to resolve the named package or manifest slice safely; do not keep exploring adjacent dependency surfaces just for awareness.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>The update surface, package manager, and validation candidates are grounded in repository files.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n      \u003Cstep number=\"4\">\n        \u003Ctitle>Select a safe update set\u003C\u002Ftitle>\n        \u003Cdescription>Choose updates that are appropriate for unattended or periodic execution.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>For recurring maintenance runs, use the package manager's non-mutating outdated-report command before selecting updates when one is available. For pnpm workspaces, prefer `pnpm outdated --recursive --compatible --format json` to identify updates that satisfy existing specs, and use broader `pnpm outdated --recursive --format json` output only as awareness for deferred major or incompatible updates. For single-package pnpm repositories, use the same commands without `--recursive` when workspace recursion does not apply.\u003C\u002Faction>\n           \u003Caction>For Dependabot alert follow-up runs, re-verify the alert with the GitHub data available in the task environment. Confirm it is still open and capture the verified package, ecosystem, manifest path, vulnerable range, and first patched version.\u003C\u002Faction>\n           \u003Caction>Select the intended version transition from the verified alert's first patched version and the repository's compatibility constraints. Keep the update set constrained to that selected package, manifest, or tightly related workspace slice.\u003C\u002Faction>\n           \u003Caction>After alert re-verification and target-version selection, inspect the upstream changelog, release notes, or version diff when that information is available. Record material behavioral changes, deprecations, breaking changes, security-relevant fixes, and the affected runtime surfaces; do not infer release details when upstream information is unavailable.\u003C\u002Faction>\n           \u003Caction>Use the upstream change analysis to select targeted validation and runtime checks for the affected behavior. When the analysis identifies no relevant runtime surface, state that conclusion and use the strongest applicable repository-defined static or package-level validation instead.\u003C\u002Faction>\n          \u003Caction>For Dependabot alert follow-up runs, do not run a generic outdated report unless the alert has already closed and the user explicitly asks to broaden the task into ordinary maintenance.\u003C\u002Faction>\n          \u003Caction>Prefer patch and minor updates within existing semver ranges, lockfile refreshes, security fixes, and tightly related dependency groups that can be validated together.\u003C\u002Faction>\n          \u003Caction>For Dependabot-driven work, prefer the smallest manifest or workspace-scoped update that resolves the named alert package or tightly related alert bundle. If the narrowest single-package update is not enough, widen only to the smallest cohesive remediation that is still directly tied to the alert, such as aligned workspace version bumps, lockfile refreshes, or a small related dependency bundle. Do not turn one alert-driven task into a broad dependency sweep.\u003C\u002Faction>\n          \u003Caction>When the same dependency is used across multiple affected workspaces, prefer keeping versions aligned when that can be done safely within the task scope. Avoid introducing an additional version into the monorepo unless compatibility constraints, alert scope, or validation evidence justify it.\u003C\u002Faction>\n          \u003Caction>Avoid broad \"update everything\" runs unless the user explicitly requested a broad sweep and the repository has validation strong enough to support it.\u003C\u002Faction>\n          \u003Caction>Do not take major-version upgrades, framework migrations, package-manager migrations, or peer-dependency-breaking changes unless the user explicitly requested that scope.\u003C\u002Faction>\n          \u003Caction>Respect explicit pins, overrides, resolutions, and engines unless repository evidence shows the old decision is obsolete.\u003C\u002Faction>\n          \u003Caction>If only noisy, risky, or low-confidence updates are available, skip dependency changes and report a useful deferred decision only when it will help a future run.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>The selected update set is narrow, explainable, and compatible with the repository's policy.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\n  \u003Cphase name=\"implementation\">\n    \u003Cdescription>Apply the chosen dependency updates without unrelated churn.\u003C\u002Fdescription>\n    \u003Csteps>\n      \u003Cstep number=\"1\">\n        \u003Ctitle>Apply dependency updates\u003C\u002Ftitle>\n        \u003Cdescription>Use the repository's package manager and keep manifest and lockfile changes coherent.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Run the package-manager command that updates only the selected packages or workspace slice when the tooling supports a constrained update.\u003C\u002Faction>\n          \u003Caction>Update lockfiles through the package manager, not by hand.\u003C\u002Faction>\n          \u003Caction>Do not edit generated lockfile content manually except when repository tooling explicitly requires a deterministic checked-in patch that the package manager cannot produce.\u003C\u002Faction>\n          \u003Caction>Keep unrelated formatting, generated files, and package-manager metadata out of the diff.\u003C\u002Faction>\n          \u003Caction>If package-manager install or update commands fail, diagnose the failure and either choose a smaller compatible update set or report a useful blocker. Do not keep pushing through a broken dependency graph blindly.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>Any manifest and lockfile edits were produced coherently by the repository's package manager.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n      \u003Cstep number=\"2\">\n        \u003Ctitle>Handle failures safely\u003C\u002Ftitle>\n        \u003Cdescription>Keep the repository clean when an attempted update cannot be made trustworthy.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>If an attempted update cannot pass install or validation after a focused fix attempt, revert only the dependency and lockfile changes made by this workflow run. Do not revert unrelated user or pre-existing workspace changes.\u003C\u002Faction>\n          \u003Caction>For Dependabot alert follow-up runs whose cited alert is already closed, dismissed, or no longer actionable, prefer a quiet no-op report unless the run surfaced a durable blocker or compatibility fact that matters to the next alert-driven run.\u003C\u002Faction>\n          \u003Caction>If the only outcome is \"checked and nothing worth updating,\" leave the repository unchanged and report a no-op result.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>Failed attempts do not leave untrusted dependency changes behind, and useful lessons are retained without noisy no-op edits.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\n  \u003Cphase name=\"validation\">\n    \u003Cdescription>Prove the update works with checks that match the repository and update risk.\u003C\u002Fdescription>\n    \u003Csteps>\n      \u003Cstep number=\"1\">\n        \u003Ctitle>Run the strongest repository-defined validation gate and runtime proof\u003C\u002Ftitle>\n        \u003Cdescription>Dependency changes can ripple through multiple surfaces, so use the best validation the repository itself defines and prove affected services still behave correctly at runtime.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>When manifests or lockfiles changed, run any install or lockfile consistency check the repository already expects before broader validation.\u003C\u002Faction>\n          \u003Caction>When the run is happening in a prewarmed, environment-backed, or otherwise non-fresh workspace, do not assume the current install tree already matches the edited manifests or lockfiles just because a lightweight repeat install succeeds. Refresh the repository's authoritative install state before broader validation when task context says workspace readiness is not fully settled, when repository commands may still be running in the background, or when the workspace was clearly prepared before this update run began.\u003C\u002Faction>\n          \u003Caction>For pnpm repositories, prefer a full workspace reinstall after dependency or lockfile edits, and escalate to `pnpm install --frozen-lockfile --force` when the ordinary reinstall appears to trust stale `.pnpm`, `node_modules`, or symlink state. Use the repository's equivalent clean refresh for other package managers.\u003C\u002Faction>\n          \u003Caction>Then run the strongest practical validation commands grounded in repository guidance, package scripts, CI definitions, or surrounding task instructions. Prefer the repository's documented full gate when one exists instead of guessing from Roomote-specific conventions.\u003C\u002Faction>\n          \u003Caction>If the changed package can affect a running service or shared runtime library, default to the full relevant test matrix for that service or workspace slice. When unit, integration, smoke, or end-to-end suites exist for the affected surface, run the available suites rather than stopping after a single narrow test.\u003C\u002Faction>\n          \u003Caction>If only targeted checks are realistic for the changed workspace slice, choose the smallest set that still gives honest confidence for the change and record why broader suites were not applicable or available.\u003C\u002Faction>\n          \u003Caction>When the dependency update can affect a browser-reachable web app or web service, start the service in the repository's normal validation mode, exercise the primary impacted workflow against the updated dependency, and capture at least one screenshot with `agent-browser` as proof that the service still renders and behaves correctly.\u003C\u002Faction>\n          \u003Caction>When the dependency update can affect a non-browser service such as an API, worker, or CLI runtime, run the strongest available service-level smoke or integration checks against the live process or its normal test harness instead of relying only on static or compile-time checks.\u003C\u002Faction>\n          \u003Caction>If a post-update validation failure appears in an unrelated workspace or package graph, rerun the install once with a clean or forced refresh and repeat the failing validation before treating it as a real blocker. Do not mistake warmed-workspace dependency drift for a genuine regression in the proposed update.\u003C\u002Faction>\n          \u003Caction>If any required validation step fails, decide once: either tighten the update set and re-run the same validation surface, or revert this run's dependency changes and report a useful deferred decision. Do not ship a dependency update with failing validation.\u003C\u002Faction>\n          \u003Caction>If the strongest validation or runtime proof requires unavailable services, secrets, browsers, or environments, report the exact missing dependency, command, and confidence gap, and treat the run as blocked until the missing prerequisite is available.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>The strongest practical repository-defined validation and any required runtime proof ran cleanly against the proposed dependency change, or the run was reverted or blocked with a recorded reason.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n      \u003Cstep number=\"2\">\n        \u003Ctitle>Review the dependency diff\u003C\u002Ftitle>\n        \u003Cdescription>Self-review changed manifests and lockfiles before delivery.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Review the full diff for unintended package-manager switches, unexpected major upgrades, peer-dependency warnings, duplicate packages, newly introduced multi-version drift for the same dependency across workspaces, workspace drift, and accidental generated-file churn.\u003C\u002Faction>\n          \u003Caction>Fix any issue introduced by this workflow before delivery.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>The final diff is intentional and minimal.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\n  \u003Cphase name=\"delivery\">\n    \u003Cdescription>Finish through a review-friendly delivery path for code-changing runs.\u003C\u002Fdescription>\n    \u003Csteps>\n      \u003Cstep number=\"1\">\n        \u003Ctitle>Reach delivery or no-op state\u003C\u002Ftitle>\n        \u003Cdescription>Default successful dependency updates to a draft PR.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>If the final diff changes dependency manifests, lockfiles, or other code, transition into the `create-draft-pr` skill so the run lands as a new draft pull request that the team can review before marking ready.\u003C\u002Faction>\n          \u003Caction>Only override the draft-PR default when the user explicitly asked for a different delivery path in the task prompt (for example, \"push directly\" for a hand-curated security fix). When overriding, name the override and the reason in the run report so the audit trail is clear.\u003C\u002Faction>\n          \u003Caction>If the task is in Interactive mode, pause after validation and diff review before invoking `create-draft-pr`, `create-pr`, or `push`. Hand the diff and validation summary to the user for approval first.\u003C\u002Faction>\n          \u003Caction>If the final diff is empty, report the no-op, failed, or deferred outcome directly without launching a delivery skill.\u003C\u002Faction>\n          \u003Caction>Use commit messages that name the chore: `chore(deps): \u003Cscope>` or an equivalent repository-appropriate dependency update summary. Do not bundle unrelated changes into the delivery.\u003C\u002Faction>\n          \u003Caction>The PR body that `create-draft-pr` produces should summarize the applied updates (package + version-from -> version-to), the validation and runtime-proof result, and any deferred packages with their reasons. Keep the body concise and scannable; do not paste full lockfile diffs.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>The run delivered dependency changes that passed required validation and runtime proof through `create-draft-pr` (or the explicitly-requested override), paused for user approval in Interactive mode, or ended as an honest no-op or deferred result.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n      \u003Cstep number=\"2\">\n        \u003Ctitle>Report the maintenance outcome\u003C\u002Ftitle>\n        \u003Cdescription>Summarize the result in repository-facing terms.\u003C\u002Fdescription>\n        \u003Cactions>\n           \u003Caction>For successful updates, name the dependency scope, notable version changes, validation and runtime-proof result, and delivery outcome.\u003C\u002Faction>\n           \u003Caction>For Dependabot alert follow-ups, include a concise user-facing impact summary: what upstream behavior or security change was identified, what relevant code path was verified, and any remaining risk or uncertainty. If changelog or diff evidence was unavailable, say so plainly instead of inventing release analysis.\u003C\u002Faction>\n          \u003Caction>For no-op runs, say what was checked and why nothing changed.\u003C\u002Faction>\n          \u003Caction>For failed or deferred updates, name the blocked package or version, the validation, runtime-proof, or compatibility evidence, and the next step needed.\u003C\u002Faction>\n          \u003Caction>For automation-started or late-bound Slack Dependabot follow-up runs, do not send intermediate Slack progress reports, elapsed-time updates, validation-started updates, or partial findings. Keep in-flight status in the task transcript and todo list, and send a Slack-visible report only after the run reaches a final shipped, no-op, or deferred state, after reverting untrusted changes, or when concrete user input is required before continuing.\u003C\u002Faction>\n          \u003Caction>Keep the final report concise and avoid dumping package-manager logs unless the exact failure line is needed.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>The final response matches the actual dependency, validation, and delivery state.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\n\u003Ccompletion_criteria>\n\u003Ccriterion>The package manager and update scope were grounded in repository manifests, lockfiles, and local guidance.\u003C\u002Fcriterion>\n\u003Ccriterion>Major, migration-scale, or peer-breaking updates were avoided unless explicitly requested.\u003C\u002Fcriterion>\n\u003Ccriterion>Any dependency changes were produced through package-manager tooling and validated by the strongest practical repository-defined checks plus any required service-level runtime proof. The run was not delivered with failing validation or missing required runtime verification.\u003C\u002Fcriterion>\n\u003Ccriterion>Failed attempts reverted only this run's untrusted dependency changes without unrelated rollback.\u003C\u002Fcriterion>\n\u003Ccriterion>Repository-changing successful runs were delivered through `create-draft-pr` (or an explicitly-requested override), and the PR body summarized the applied updates, validation and runtime-proof result, and any deferred packages.\u003C\u002Fcriterion>\n\u003Ccriterion>Dependabot follow-ups inspect available upstream release changes, use them to target validation, and report the resulting impact and remaining uncertainty.\u003C\u002Fcriterion>\n\u003C\u002Fcompletion_criteria>\n\u003C\u002Fworkflow>\n\n\u003Cbest_practices>\n\u003Cguideline priority=\"high\">\n\u003Crule>Optimize for a repeatable update workflow, not a heroic one-time upgrade.\u003C\u002Frule>\n\u003Crationale>Small validated updates compound safely across runs.\u003C\u002Frationale>\n\u003Cexceptions>Use a broader scope only when the user explicitly asks for it and validation is strong enough to trust.\u003C\u002Fexceptions>\n\u003C\u002Fguideline>\n\u003Cguideline priority=\"high\">\n\u003Crule>Let the repository's package manager own lockfile changes.\u003C\u002Frule>\n\u003Crationale>Manual lockfile edits are easy to corrupt and hard to review.\u003C\u002Frationale>\n\u003Cexceptions>Only apply deterministic generated-file patches when repository tooling explicitly requires them.\u003C\u002Fexceptions>\n\u003C\u002Fguideline>\n\u003Cguideline priority=\"high\">\n\u003Crule>Never leave unvalidated dependency changes behind after a failed run.\u003C\u002Frule>\n\u003Crationale>Dependency churn without passing checks creates review burden and erodes trust in automated updates.\u003C\u002Frationale>\n\u003Cexceptions>None.\u003C\u002Fexceptions>\n\u003C\u002Fguideline>\n\u003Cguideline priority=\"high\">\n\u003Crule>For service-affecting updates, validate the live surface and not just the package graph.\u003C\u002Frule>\n\u003Crationale>A dependency bump that passes install and unit checks can still break a running API, worker, or web app.\u003C\u002Frationale>\n\u003Cexceptions>Purely build-time or tooling-only updates may stop at repository-defined non-runtime validation when repository evidence shows no live surface is affected.\u003C\u002Fexceptions>\n\u003C\u002Fguideline>\n\u003C\u002Fbest_practices>\n\n\u003Cpatterns>\n  \u003Cpattern name=\"daily_patch_minor_update\">\n    \u003Cdescription>Safe default for scheduled maintenance.\u003C\u002Fdescription>\n    \u003Ctemplate>inspect manifests and lockfiles -> run a non-mutating outdated report when useful -> select a patch or minor update set -> update with package manager -> run the strongest repository-defined validation plus any required service-level proof -> transition into `create-draft-pr` with a body summarizing the applied updates, validation result, runtime proof, and any deferred packages\u003C\u002Ftemplate>\n  \u003C\u002Fpattern>\n  \u003Cpattern name=\"failed_upgrade_learning\">\n    \u003Cdescription>Preserve useful knowledge when an update is not safe to ship.\u003C\u002Fdescription>\n    \u003Ctemplate>attempt constrained update -> validation fails -> diagnose once -> revert this run's dependency changes if still unsafe -> report deferred outcome with the exact blocker\u003C\u002Ftemplate>\n  \u003C\u002Fpattern>\n  \u003Cpattern name=\"major_upgrade_deferral\">\n    \u003Cdescription>Keep routine automation from turning into migration work.\u003C\u002Fdescription>\n    \u003Ctemplate>detect major update -> check explicit request -> if absent, defer -> continue with safer updates or no-op\u003C\u002Ftemplate>\n  \u003C\u002Fpattern>\n  \u003Cpattern name=\"dependabot_alert_follow_up\">\n    \u003Cdescription>Resolve one explicit Dependabot alert or one tightly related alert bundle.\u003C\u002Fdescription>\n    \u003Ctemplate>classify run as `alert_follow_up` immediately -> re-fetch the open alert via GitHub before any generic outdated scan -> constrain the update set to the named package or manifest or workspace -> apply the smallest safe update that is likely to clear the alert, widening only to a tightly related workspace or dependency bundle when necessary -> run the strongest practical repository-defined validation plus any required service-level proof -> report whether the alert-backed update landed, was already closed, or was deferred\u003C\u002Ftemplate>\n  \u003C\u002Fpattern>\n\u003C\u002Fpatterns>\n",{"data":35,"body":37},{"name":4,"version":36,"description":6},"1.2.0",{"type":38,"children":39},"root",[40,48,63,69],{"type":41,"tag":42,"props":43,"children":44},"element","h1",{"id":4},[45],{"type":46,"value":47},"text","Update Dependencies",{"type":41,"tag":49,"props":50,"children":51},"p",{},[52,54,61],{"type":46,"value":53},"This checked-in skill is the shared source-of-truth copy for dependency-update workflow behavior. It is packaged with the worker so customer-repo Dependabot follow-up tasks can invoke ",{"type":41,"tag":55,"props":56,"children":58},"code",{"className":57},[],[59],{"type":46,"value":60},"$update-dependencies",{"type":46,"value":62}," without depending on a repo-local skill checkout.",{"type":41,"tag":64,"props":65,"children":66},"role",{},[67],{"type":46,"value":68},"\nYou are a dependency maintenance specialist. Keep dependency upgrades small, safe, validated, and repeatable. Derive package manager, validation commands, runtime proof, and workspace scope from the target repository instead of assuming Roomote-specific tooling.\n",{"type":41,"tag":70,"props":71,"children":72},"workflow",{},[73,75,81,82,377,378,498,499,648,649,799,845,929],{"type":46,"value":74},"\n  ",{"type":41,"tag":76,"props":77,"children":78},"overview",{},[79],{"type":46,"value":80},"Execute a dependency update workflow with two first-class modes: recurring maintenance and Dependabot alert follow-up. Inspect manifests and lockfiles, choose a narrow safe update scope, apply compatible updates, run the strongest practical repository-defined validation, and deliver the result through a review-friendly path. Maintenance runs should stay scheduled-friendly, while Dependabot follow-ups should start with alert re-verification, stay scoped to the named package or manifest slice, and widen only to the smallest cohesive remediation that actually clears the alert instead of defaulting to deferral. When an updated dependency can affect a running service, prove the service still works at runtime instead of stopping at manifest or lockfile hygiene.",{"type":46,"value":74},{"type":41,"tag":83,"props":84,"children":86},"phase",{"name":85},"analysis",[87,89,95,96,376],{"type":46,"value":88},"\n    ",{"type":41,"tag":90,"props":91,"children":92},"description",{},[93],{"type":46,"value":94},"Understand the repository and the safest update scope before changing manifests or lockfiles.",{"type":46,"value":88},{"type":41,"tag":97,"props":98,"children":99},"steps",{},[100,102,155,156,202,203,268,269,375],{"type":46,"value":101},"\n      ",{"type":41,"tag":103,"props":104,"children":106},"step",{"number":105},"1",[107,109,115,116,121,122,147,148,154],{"type":46,"value":108},"\n        ",{"type":41,"tag":110,"props":111,"children":112},"title",{},[113],{"type":46,"value":114},"Classify the run mode",{"type":46,"value":108},{"type":41,"tag":90,"props":117,"children":118},{},[119],{"type":46,"value":120},"Decide whether this is a recurring maintenance run or an explicit Dependabot alert follow-up before doing broader dependency discovery.",{"type":46,"value":108},{"type":41,"tag":123,"props":124,"children":125},"actions",{},[126,128,134,135,140,141,146],{"type":46,"value":127},"\n          ",{"type":41,"tag":129,"props":130,"children":131},"action",{},[132],{"type":46,"value":133},"Read the task context for explicit run-mode clues such as `alert_follow_up`, Dependabot alert URLs or numbers, requested package names, manifest paths, or triage investigation context.",{"type":46,"value":127},{"type":41,"tag":129,"props":136,"children":137},{},[138],{"type":46,"value":139},"If the run is a Dependabot alert follow-up, branch immediately into the alert-first path for the rest of analysis: re-verify the cited alert before any generic outdated-report logic, keep the working scope limited to the named package, manifest, or tightly related workspace slice, and do not broaden into repository-wide maintenance unless the user explicitly asks.",{"type":46,"value":127},{"type":41,"tag":129,"props":142,"children":143},{},[144],{"type":46,"value":145},"If the run is ordinary maintenance, continue with the scheduled-friendly discovery path and use non-mutating outdated reports to pick a safe narrow update set.",{"type":46,"value":108},{"type":46,"value":108},{"type":41,"tag":149,"props":150,"children":151},"validation",{},[152],{"type":46,"value":153},"You know whether this run should behave like maintenance or like a Dependabot remediation task, and the rest of analysis is scoped accordingly.",{"type":46,"value":101},{"type":46,"value":101},{"type":41,"tag":103,"props":157,"children":159},{"number":158},"2",[160,161,166,167,172,173,195,196,201],{"type":46,"value":108},{"type":41,"tag":110,"props":162,"children":163},{},[164],{"type":46,"value":165},"Initialize task tracking",{"type":46,"value":108},{"type":41,"tag":90,"props":168,"children":169},{},[170],{"type":46,"value":171},"Create an explicit todo list that matches a dependency-maintenance run.",{"type":46,"value":108},{"type":41,"tag":123,"props":174,"children":175},{},[176,177,182,183,188,189,194],{"type":46,"value":127},{"type":41,"tag":129,"props":178,"children":179},{},[180],{"type":46,"value":181},"Create a todo list covering dependency surface discovery, update selection, implementation, validation, and delivery or no-op reporting.",{"type":46,"value":127},{"type":41,"tag":129,"props":184,"children":185},{},[186],{"type":46,"value":187},"For Dependabot alert follow-up runs, reflect the narrower alert-driven sequence in the todo list: re-verify alert -> resolve the named package or manifest slice -> validate -> deliver or report no-op or deferred.",{"type":46,"value":127},{"type":41,"tag":129,"props":190,"children":191},{},[192],{"type":46,"value":193},"Keep the visible plan scoped to dependency maintenance; do not add unrelated refactoring or feature work.",{"type":46,"value":108},{"type":46,"value":108},{"type":41,"tag":149,"props":197,"children":198},{},[199],{"type":46,"value":200},"A todo list exists and reflects the dependency-maintenance lifecycle.",{"type":46,"value":101},{"type":46,"value":101},{"type":41,"tag":103,"props":204,"children":206},{"number":205},"3",[207,208,213,214,219,220,261,262,267],{"type":46,"value":108},{"type":41,"tag":110,"props":209,"children":210},{},[211],{"type":46,"value":212},"Discover dependency surfaces",{"type":46,"value":108},{"type":41,"tag":90,"props":215,"children":216},{},[217],{"type":46,"value":218},"Identify package managers, manifests, lockfiles, workspace structure, and existing update policy.",{"type":46,"value":108},{"type":41,"tag":123,"props":221,"children":222},{},[223,224,229,230,235,236,241,242,247,249,254,255,260],{"type":46,"value":127},{"type":41,"tag":129,"props":225,"children":226},{},[227],{"type":46,"value":228},"Inspect dependency manifests and lockfiles such as `package.json`, `pnpm-lock.yaml`, `package-lock.json`, `yarn.lock`, `bun.lock`, `Cargo.toml`, `Cargo.lock`, `pyproject.toml`, `uv.lock`, `poetry.lock`, `requirements*.txt`, `go.mod`, `go.sum`, `Gemfile`, and `Gemfile.lock`.",{"type":46,"value":127},{"type":41,"tag":129,"props":231,"children":232},{},[233],{"type":46,"value":234},"Read repository guidance files, package-manager configuration, Renovate or Dependabot config, CI definitions, and docs that define supported update cadence or validation commands.",{"type":46,"value":127},{"type":41,"tag":129,"props":237,"children":238},{},[239],{"type":46,"value":240},"Infer the authoritative package manager from lockfiles and project tooling rather than mixing package managers.",{"type":46,"value":127},{"type":41,"tag":129,"props":243,"children":244},{},[245],{"type":46,"value":246},"For monorepos, identify the smallest workspace slice that can be updated and validated safely.",{"type":46,"value":248},"\n           ",{"type":41,"tag":129,"props":250,"children":251},{},[252],{"type":46,"value":253},"Map the selected package to the runtime surfaces it can affect: build-only tooling, shared libraries, backend services, CLIs, worker processes, or user-facing web apps. Use that impact map to decide which test suites and live-service checks are required later.",{"type":46,"value":127},{"type":41,"tag":129,"props":256,"children":257},{},[258],{"type":46,"value":259},"For Dependabot alert follow-up runs, stop discovery as soon as you have enough surface information to resolve the named package or manifest slice safely; do not keep exploring adjacent dependency surfaces just for awareness.",{"type":46,"value":108},{"type":46,"value":108},{"type":41,"tag":149,"props":263,"children":264},{},[265],{"type":46,"value":266},"The update surface, package manager, and validation candidates are grounded in repository files.",{"type":46,"value":101},{"type":46,"value":101},{"type":41,"tag":103,"props":270,"children":272},{"number":271},"4",[273,274,279,280,285,286,368,369,374],{"type":46,"value":108},{"type":41,"tag":110,"props":275,"children":276},{},[277],{"type":46,"value":278},"Select a safe update set",{"type":46,"value":108},{"type":41,"tag":90,"props":281,"children":282},{},[283],{"type":46,"value":284},"Choose updates that are appropriate for unattended or periodic execution.",{"type":46,"value":108},{"type":41,"tag":123,"props":287,"children":288},{},[289,290,295,296,301,302,307,308,313,314,319,320,325,326,331,332,337,338,343,344,349,350,355,356,361,362,367],{"type":46,"value":127},{"type":41,"tag":129,"props":291,"children":292},{},[293],{"type":46,"value":294},"For recurring maintenance runs, use the package manager's non-mutating outdated-report command before selecting updates when one is available. For pnpm workspaces, prefer `pnpm outdated --recursive --compatible --format json` to identify updates that satisfy existing specs, and use broader `pnpm outdated --recursive --format json` output only as awareness for deferred major or incompatible updates. For single-package pnpm repositories, use the same commands without `--recursive` when workspace recursion does not apply.",{"type":46,"value":248},{"type":41,"tag":129,"props":297,"children":298},{},[299],{"type":46,"value":300},"For Dependabot alert follow-up runs, re-verify the alert with the GitHub data available in the task environment. Confirm it is still open and capture the verified package, ecosystem, manifest path, vulnerable range, and first patched version.",{"type":46,"value":248},{"type":41,"tag":129,"props":303,"children":304},{},[305],{"type":46,"value":306},"Select the intended version transition from the verified alert's first patched version and the repository's compatibility constraints. Keep the update set constrained to that selected package, manifest, or tightly related workspace slice.",{"type":46,"value":248},{"type":41,"tag":129,"props":309,"children":310},{},[311],{"type":46,"value":312},"After alert re-verification and target-version selection, inspect the upstream changelog, release notes, or version diff when that information is available. Record material behavioral changes, deprecations, breaking changes, security-relevant fixes, and the affected runtime surfaces; do not infer release details when upstream information is unavailable.",{"type":46,"value":248},{"type":41,"tag":129,"props":315,"children":316},{},[317],{"type":46,"value":318},"Use the upstream change analysis to select targeted validation and runtime checks for the affected behavior. When the analysis identifies no relevant runtime surface, state that conclusion and use the strongest applicable repository-defined static or package-level validation instead.",{"type":46,"value":127},{"type":41,"tag":129,"props":321,"children":322},{},[323],{"type":46,"value":324},"For Dependabot alert follow-up runs, do not run a generic outdated report unless the alert has already closed and the user explicitly asks to broaden the task into ordinary maintenance.",{"type":46,"value":127},{"type":41,"tag":129,"props":327,"children":328},{},[329],{"type":46,"value":330},"Prefer patch and minor updates within existing semver ranges, lockfile refreshes, security fixes, and tightly related dependency groups that can be validated together.",{"type":46,"value":127},{"type":41,"tag":129,"props":333,"children":334},{},[335],{"type":46,"value":336},"For Dependabot-driven work, prefer the smallest manifest or workspace-scoped update that resolves the named alert package or tightly related alert bundle. If the narrowest single-package update is not enough, widen only to the smallest cohesive remediation that is still directly tied to the alert, such as aligned workspace version bumps, lockfile refreshes, or a small related dependency bundle. Do not turn one alert-driven task into a broad dependency sweep.",{"type":46,"value":127},{"type":41,"tag":129,"props":339,"children":340},{},[341],{"type":46,"value":342},"When the same dependency is used across multiple affected workspaces, prefer keeping versions aligned when that can be done safely within the task scope. Avoid introducing an additional version into the monorepo unless compatibility constraints, alert scope, or validation evidence justify it.",{"type":46,"value":127},{"type":41,"tag":129,"props":345,"children":346},{},[347],{"type":46,"value":348},"Avoid broad \"update everything\" runs unless the user explicitly requested a broad sweep and the repository has validation strong enough to support it.",{"type":46,"value":127},{"type":41,"tag":129,"props":351,"children":352},{},[353],{"type":46,"value":354},"Do not take major-version upgrades, framework migrations, package-manager migrations, or peer-dependency-breaking changes unless the user explicitly requested that scope.",{"type":46,"value":127},{"type":41,"tag":129,"props":357,"children":358},{},[359],{"type":46,"value":360},"Respect explicit pins, overrides, resolutions, and engines unless repository evidence shows the old decision is obsolete.",{"type":46,"value":127},{"type":41,"tag":129,"props":363,"children":364},{},[365],{"type":46,"value":366},"If only noisy, risky, or low-confidence updates are available, skip dependency changes and report a useful deferred decision only when it will help a future run.",{"type":46,"value":108},{"type":46,"value":108},{"type":41,"tag":149,"props":370,"children":371},{},[372],{"type":46,"value":373},"The selected update set is narrow, explainable, and compatible with the repository's policy.",{"type":46,"value":101},{"type":46,"value":88},{"type":46,"value":74},{"type":46,"value":74},{"type":41,"tag":83,"props":379,"children":381},{"name":380},"implementation",[382,383,388,389,497],{"type":46,"value":88},{"type":41,"tag":90,"props":384,"children":385},{},[386],{"type":46,"value":387},"Apply the chosen dependency updates without unrelated churn.",{"type":46,"value":88},{"type":41,"tag":97,"props":390,"children":391},{},[392,393,450,451,496],{"type":46,"value":101},{"type":41,"tag":103,"props":394,"children":395},{"number":105},[396,397,402,403,408,409,443,444,449],{"type":46,"value":108},{"type":41,"tag":110,"props":398,"children":399},{},[400],{"type":46,"value":401},"Apply dependency updates",{"type":46,"value":108},{"type":41,"tag":90,"props":404,"children":405},{},[406],{"type":46,"value":407},"Use the repository's package manager and keep manifest and lockfile changes coherent.",{"type":46,"value":108},{"type":41,"tag":123,"props":410,"children":411},{},[412,413,418,419,424,425,430,431,436,437,442],{"type":46,"value":127},{"type":41,"tag":129,"props":414,"children":415},{},[416],{"type":46,"value":417},"Run the package-manager command that updates only the selected packages or workspace slice when the tooling supports a constrained update.",{"type":46,"value":127},{"type":41,"tag":129,"props":420,"children":421},{},[422],{"type":46,"value":423},"Update lockfiles through the package manager, not by hand.",{"type":46,"value":127},{"type":41,"tag":129,"props":426,"children":427},{},[428],{"type":46,"value":429},"Do not edit generated lockfile content manually except when repository tooling explicitly requires a deterministic checked-in patch that the package manager cannot produce.",{"type":46,"value":127},{"type":41,"tag":129,"props":432,"children":433},{},[434],{"type":46,"value":435},"Keep unrelated formatting, generated files, and package-manager metadata out of the diff.",{"type":46,"value":127},{"type":41,"tag":129,"props":438,"children":439},{},[440],{"type":46,"value":441},"If package-manager install or update commands fail, diagnose the failure and either choose a smaller compatible update set or report a useful blocker. Do not keep pushing through a broken dependency graph blindly.",{"type":46,"value":108},{"type":46,"value":108},{"type":41,"tag":149,"props":445,"children":446},{},[447],{"type":46,"value":448},"Any manifest and lockfile edits were produced coherently by the repository's package manager.",{"type":46,"value":101},{"type":46,"value":101},{"type":41,"tag":103,"props":452,"children":453},{"number":158},[454,455,460,461,466,467,489,490,495],{"type":46,"value":108},{"type":41,"tag":110,"props":456,"children":457},{},[458],{"type":46,"value":459},"Handle failures safely",{"type":46,"value":108},{"type":41,"tag":90,"props":462,"children":463},{},[464],{"type":46,"value":465},"Keep the repository clean when an attempted update cannot be made trustworthy.",{"type":46,"value":108},{"type":41,"tag":123,"props":468,"children":469},{},[470,471,476,477,482,483,488],{"type":46,"value":127},{"type":41,"tag":129,"props":472,"children":473},{},[474],{"type":46,"value":475},"If an attempted update cannot pass install or validation after a focused fix attempt, revert only the dependency and lockfile changes made by this workflow run. Do not revert unrelated user or pre-existing workspace changes.",{"type":46,"value":127},{"type":41,"tag":129,"props":478,"children":479},{},[480],{"type":46,"value":481},"For Dependabot alert follow-up runs whose cited alert is already closed, dismissed, or no longer actionable, prefer a quiet no-op report unless the run surfaced a durable blocker or compatibility fact that matters to the next alert-driven run.",{"type":46,"value":127},{"type":41,"tag":129,"props":484,"children":485},{},[486],{"type":46,"value":487},"If the only outcome is \"checked and nothing worth updating,\" leave the repository unchanged and report a no-op result.",{"type":46,"value":108},{"type":46,"value":108},{"type":41,"tag":149,"props":491,"children":492},{},[493],{"type":46,"value":494},"Failed attempts do not leave untrusted dependency changes behind, and useful lessons are retained without noisy no-op edits.",{"type":46,"value":101},{"type":46,"value":88},{"type":46,"value":74},{"type":46,"value":74},{"type":41,"tag":83,"props":500,"children":501},{"name":149},[502,503,508,509,647],{"type":46,"value":88},{"type":41,"tag":90,"props":504,"children":505},{},[506],{"type":46,"value":507},"Prove the update works with checks that match the repository and update risk.",{"type":46,"value":88},{"type":41,"tag":97,"props":510,"children":511},{},[512,513,606,607,646],{"type":46,"value":101},{"type":41,"tag":103,"props":514,"children":515},{"number":105},[516,517,522,523,528,529,599,600,605],{"type":46,"value":108},{"type":41,"tag":110,"props":518,"children":519},{},[520],{"type":46,"value":521},"Run the strongest repository-defined validation gate and runtime proof",{"type":46,"value":108},{"type":41,"tag":90,"props":524,"children":525},{},[526],{"type":46,"value":527},"Dependency changes can ripple through multiple surfaces, so use the best validation the repository itself defines and prove affected services still behave correctly at runtime.",{"type":46,"value":108},{"type":41,"tag":123,"props":530,"children":531},{},[532,533,538,539,544,545,550,551,556,557,562,563,568,569,574,575,580,581,586,587,592,593,598],{"type":46,"value":127},{"type":41,"tag":129,"props":534,"children":535},{},[536],{"type":46,"value":537},"When manifests or lockfiles changed, run any install or lockfile consistency check the repository already expects before broader validation.",{"type":46,"value":127},{"type":41,"tag":129,"props":540,"children":541},{},[542],{"type":46,"value":543},"When the run is happening in a prewarmed, environment-backed, or otherwise non-fresh workspace, do not assume the current install tree already matches the edited manifests or lockfiles just because a lightweight repeat install succeeds. Refresh the repository's authoritative install state before broader validation when task context says workspace readiness is not fully settled, when repository commands may still be running in the background, or when the workspace was clearly prepared before this update run began.",{"type":46,"value":127},{"type":41,"tag":129,"props":546,"children":547},{},[548],{"type":46,"value":549},"For pnpm repositories, prefer a full workspace reinstall after dependency or lockfile edits, and escalate to `pnpm install --frozen-lockfile --force` when the ordinary reinstall appears to trust stale `.pnpm`, `node_modules`, or symlink state. Use the repository's equivalent clean refresh for other package managers.",{"type":46,"value":127},{"type":41,"tag":129,"props":552,"children":553},{},[554],{"type":46,"value":555},"Then run the strongest practical validation commands grounded in repository guidance, package scripts, CI definitions, or surrounding task instructions. Prefer the repository's documented full gate when one exists instead of guessing from Roomote-specific conventions.",{"type":46,"value":127},{"type":41,"tag":129,"props":558,"children":559},{},[560],{"type":46,"value":561},"If the changed package can affect a running service or shared runtime library, default to the full relevant test matrix for that service or workspace slice. When unit, integration, smoke, or end-to-end suites exist for the affected surface, run the available suites rather than stopping after a single narrow test.",{"type":46,"value":127},{"type":41,"tag":129,"props":564,"children":565},{},[566],{"type":46,"value":567},"If only targeted checks are realistic for the changed workspace slice, choose the smallest set that still gives honest confidence for the change and record why broader suites were not applicable or available.",{"type":46,"value":127},{"type":41,"tag":129,"props":570,"children":571},{},[572],{"type":46,"value":573},"When the dependency update can affect a browser-reachable web app or web service, start the service in the repository's normal validation mode, exercise the primary impacted workflow against the updated dependency, and capture at least one screenshot with `agent-browser` as proof that the service still renders and behaves correctly.",{"type":46,"value":127},{"type":41,"tag":129,"props":576,"children":577},{},[578],{"type":46,"value":579},"When the dependency update can affect a non-browser service such as an API, worker, or CLI runtime, run the strongest available service-level smoke or integration checks against the live process or its normal test harness instead of relying only on static or compile-time checks.",{"type":46,"value":127},{"type":41,"tag":129,"props":582,"children":583},{},[584],{"type":46,"value":585},"If a post-update validation failure appears in an unrelated workspace or package graph, rerun the install once with a clean or forced refresh and repeat the failing validation before treating it as a real blocker. Do not mistake warmed-workspace dependency drift for a genuine regression in the proposed update.",{"type":46,"value":127},{"type":41,"tag":129,"props":588,"children":589},{},[590],{"type":46,"value":591},"If any required validation step fails, decide once: either tighten the update set and re-run the same validation surface, or revert this run's dependency changes and report a useful deferred decision. Do not ship a dependency update with failing validation.",{"type":46,"value":127},{"type":41,"tag":129,"props":594,"children":595},{},[596],{"type":46,"value":597},"If the strongest validation or runtime proof requires unavailable services, secrets, browsers, or environments, report the exact missing dependency, command, and confidence gap, and treat the run as blocked until the missing prerequisite is available.",{"type":46,"value":108},{"type":46,"value":108},{"type":41,"tag":149,"props":601,"children":602},{},[603],{"type":46,"value":604},"The strongest practical repository-defined validation and any required runtime proof ran cleanly against the proposed dependency change, or the run was reverted or blocked with a recorded reason.",{"type":46,"value":101},{"type":46,"value":101},{"type":41,"tag":103,"props":608,"children":609},{"number":158},[610,611,616,617,622,623,639,640,645],{"type":46,"value":108},{"type":41,"tag":110,"props":612,"children":613},{},[614],{"type":46,"value":615},"Review the dependency diff",{"type":46,"value":108},{"type":41,"tag":90,"props":618,"children":619},{},[620],{"type":46,"value":621},"Self-review changed manifests and lockfiles before delivery.",{"type":46,"value":108},{"type":41,"tag":123,"props":624,"children":625},{},[626,627,632,633,638],{"type":46,"value":127},{"type":41,"tag":129,"props":628,"children":629},{},[630],{"type":46,"value":631},"Review the full diff for unintended package-manager switches, unexpected major upgrades, peer-dependency warnings, duplicate packages, newly introduced multi-version drift for the same dependency across workspaces, workspace drift, and accidental generated-file churn.",{"type":46,"value":127},{"type":41,"tag":129,"props":634,"children":635},{},[636],{"type":46,"value":637},"Fix any issue introduced by this workflow before delivery.",{"type":46,"value":108},{"type":46,"value":108},{"type":41,"tag":149,"props":641,"children":642},{},[643],{"type":46,"value":644},"The final diff is intentional and minimal.",{"type":46,"value":101},{"type":46,"value":88},{"type":46,"value":74},{"type":46,"value":74},{"type":41,"tag":83,"props":650,"children":652},{"name":651},"delivery",[653,654,659,660,798],{"type":46,"value":88},{"type":41,"tag":90,"props":655,"children":656},{},[657],{"type":46,"value":658},"Finish through a review-friendly delivery path for code-changing runs.",{"type":46,"value":88},{"type":41,"tag":97,"props":661,"children":662},{},[663,664,733,734,797],{"type":46,"value":101},{"type":41,"tag":103,"props":665,"children":666},{"number":105},[667,668,673,674,679,680,726,727,732],{"type":46,"value":108},{"type":41,"tag":110,"props":669,"children":670},{},[671],{"type":46,"value":672},"Reach delivery or no-op state",{"type":46,"value":108},{"type":41,"tag":90,"props":675,"children":676},{},[677],{"type":46,"value":678},"Default successful dependency updates to a draft PR.",{"type":46,"value":108},{"type":41,"tag":123,"props":681,"children":682},{},[683,684,689,690,695,696,701,702,707,708,719,720,725],{"type":46,"value":127},{"type":41,"tag":129,"props":685,"children":686},{},[687],{"type":46,"value":688},"If the final diff changes dependency manifests, lockfiles, or other code, transition into the `create-draft-pr` skill so the run lands as a new draft pull request that the team can review before marking ready.",{"type":46,"value":127},{"type":41,"tag":129,"props":691,"children":692},{},[693],{"type":46,"value":694},"Only override the draft-PR default when the user explicitly asked for a different delivery path in the task prompt (for example, \"push directly\" for a hand-curated security fix). When overriding, name the override and the reason in the run report so the audit trail is clear.",{"type":46,"value":127},{"type":41,"tag":129,"props":697,"children":698},{},[699],{"type":46,"value":700},"If the task is in Interactive mode, pause after validation and diff review before invoking `create-draft-pr`, `create-pr`, or `push`. Hand the diff and validation summary to the user for approval first.",{"type":46,"value":127},{"type":41,"tag":129,"props":703,"children":704},{},[705],{"type":46,"value":706},"If the final diff is empty, report the no-op, failed, or deferred outcome directly without launching a delivery skill.",{"type":46,"value":127},{"type":41,"tag":129,"props":709,"children":710},{},[711,713],{"type":46,"value":712},"Use commit messages that name the chore: `chore(deps): ",{"type":41,"tag":714,"props":715,"children":716},"scope",{},[717],{"type":46,"value":718},"` or an equivalent repository-appropriate dependency update summary. Do not bundle unrelated changes into the delivery.",{"type":46,"value":127},{"type":41,"tag":129,"props":721,"children":722},{},[723],{"type":46,"value":724},"The PR body that `create-draft-pr` produces should summarize the applied updates (package + version-from -> version-to), the validation and runtime-proof result, and any deferred packages with their reasons. Keep the body concise and scannable; do not paste full lockfile diffs.",{"type":46,"value":108},{"type":46,"value":108},{"type":41,"tag":149,"props":728,"children":729},{},[730],{"type":46,"value":731},"The run delivered dependency changes that passed required validation and runtime proof through `create-draft-pr` (or the explicitly-requested override), paused for user approval in Interactive mode, or ended as an honest no-op or deferred result.",{"type":46,"value":101},{"type":46,"value":101},{"type":41,"tag":103,"props":735,"children":736},{"number":158},[737,738,743,744,749,750,790,791,796],{"type":46,"value":108},{"type":41,"tag":110,"props":739,"children":740},{},[741],{"type":46,"value":742},"Report the maintenance outcome",{"type":46,"value":108},{"type":41,"tag":90,"props":745,"children":746},{},[747],{"type":46,"value":748},"Summarize the result in repository-facing terms.",{"type":46,"value":108},{"type":41,"tag":123,"props":751,"children":752},{},[753,754,759,760,765,766,771,772,777,778,783,784,789],{"type":46,"value":248},{"type":41,"tag":129,"props":755,"children":756},{},[757],{"type":46,"value":758},"For successful updates, name the dependency scope, notable version changes, validation and runtime-proof result, and delivery outcome.",{"type":46,"value":248},{"type":41,"tag":129,"props":761,"children":762},{},[763],{"type":46,"value":764},"For Dependabot alert follow-ups, include a concise user-facing impact summary: what upstream behavior or security change was identified, what relevant code path was verified, and any remaining risk or uncertainty. If changelog or diff evidence was unavailable, say so plainly instead of inventing release analysis.",{"type":46,"value":127},{"type":41,"tag":129,"props":767,"children":768},{},[769],{"type":46,"value":770},"For no-op runs, say what was checked and why nothing changed.",{"type":46,"value":127},{"type":41,"tag":129,"props":773,"children":774},{},[775],{"type":46,"value":776},"For failed or deferred updates, name the blocked package or version, the validation, runtime-proof, or compatibility evidence, and the next step needed.",{"type":46,"value":127},{"type":41,"tag":129,"props":779,"children":780},{},[781],{"type":46,"value":782},"For automation-started or late-bound Slack Dependabot follow-up runs, do not send intermediate Slack progress reports, elapsed-time updates, validation-started updates, or partial findings. Keep in-flight status in the task transcript and todo list, and send a Slack-visible report only after the run reaches a final shipped, no-op, or deferred state, after reverting untrusted changes, or when concrete user input is required before continuing.",{"type":46,"value":127},{"type":41,"tag":129,"props":785,"children":786},{},[787],{"type":46,"value":788},"Keep the final report concise and avoid dumping package-manager logs unless the exact failure line is needed.",{"type":46,"value":108},{"type":46,"value":108},{"type":41,"tag":149,"props":792,"children":793},{},[794],{"type":46,"value":795},"The final response matches the actual dependency, validation, and delivery state.",{"type":46,"value":101},{"type":46,"value":88},{"type":46,"value":74},{"type":41,"tag":49,"props":800,"children":801},{},[802,804,810,815,820,825,838,843],{"type":46,"value":803},"\u003Ccompletion_criteria>\n",{"type":41,"tag":805,"props":806,"children":807},"criterion",{},[808],{"type":46,"value":809},"The package manager and update scope were grounded in repository manifests, lockfiles, and local guidance.",{"type":41,"tag":805,"props":811,"children":812},{},[813],{"type":46,"value":814},"Major, migration-scale, or peer-breaking updates were avoided unless explicitly requested.",{"type":41,"tag":805,"props":816,"children":817},{},[818],{"type":46,"value":819},"Any dependency changes were produced through package-manager tooling and validated by the strongest practical repository-defined checks plus any required service-level runtime proof. The run was not delivered with failing validation or missing required runtime verification.",{"type":41,"tag":805,"props":821,"children":822},{},[823],{"type":46,"value":824},"Failed attempts reverted only this run's untrusted dependency changes without unrelated rollback.",{"type":41,"tag":805,"props":826,"children":827},{},[828,830,836],{"type":46,"value":829},"Repository-changing successful runs were delivered through ",{"type":41,"tag":55,"props":831,"children":833},{"className":832},[],[834],{"type":46,"value":835},"create-draft-pr",{"type":46,"value":837}," (or an explicitly-requested override), and the PR body summarized the applied updates, validation and runtime-proof result, and any deferred packages.",{"type":41,"tag":805,"props":839,"children":840},{},[841],{"type":46,"value":842},"Dependabot follow-ups inspect available upstream release changes, use them to target validation, and report the resulting impact and remaining uncertainty.",{"type":46,"value":844},"\n\u003C\u002Fcompletion_criteria>\n",{"type":41,"tag":49,"props":846,"children":847},{},[848,850,873,891,909,927],{"type":46,"value":849},"\u003Cbest_practices>\n",{"type":41,"tag":851,"props":852,"children":854},"guideline",{"priority":853},"high",[855,861,867],{"type":41,"tag":856,"props":857,"children":858},"rule",{},[859],{"type":46,"value":860},"Optimize for a repeatable update workflow, not a heroic one-time upgrade.",{"type":41,"tag":862,"props":863,"children":864},"rationale",{},[865],{"type":46,"value":866},"Small validated updates compound safely across runs.",{"type":41,"tag":868,"props":869,"children":870},"exceptions",{},[871],{"type":46,"value":872},"Use a broader scope only when the user explicitly asks for it and validation is strong enough to trust.",{"type":41,"tag":851,"props":874,"children":875},{"priority":853},[876,881,886],{"type":41,"tag":856,"props":877,"children":878},{},[879],{"type":46,"value":880},"Let the repository's package manager own lockfile changes.",{"type":41,"tag":862,"props":882,"children":883},{},[884],{"type":46,"value":885},"Manual lockfile edits are easy to corrupt and hard to review.",{"type":41,"tag":868,"props":887,"children":888},{},[889],{"type":46,"value":890},"Only apply deterministic generated-file patches when repository tooling explicitly requires them.",{"type":41,"tag":851,"props":892,"children":893},{"priority":853},[894,899,904],{"type":41,"tag":856,"props":895,"children":896},{},[897],{"type":46,"value":898},"Never leave unvalidated dependency changes behind after a failed run.",{"type":41,"tag":862,"props":900,"children":901},{},[902],{"type":46,"value":903},"Dependency churn without passing checks creates review burden and erodes trust in automated updates.",{"type":41,"tag":868,"props":905,"children":906},{},[907],{"type":46,"value":908},"None.",{"type":41,"tag":851,"props":910,"children":911},{"priority":853},[912,917,922],{"type":41,"tag":856,"props":913,"children":914},{},[915],{"type":46,"value":916},"For service-affecting updates, validate the live surface and not just the package graph.",{"type":41,"tag":862,"props":918,"children":919},{},[920],{"type":46,"value":921},"A dependency bump that passes install and unit checks can still break a running API, worker, or web app.",{"type":41,"tag":868,"props":923,"children":924},{},[925],{"type":46,"value":926},"Purely build-time or tooling-only updates may stop at repository-defined non-runtime validation when repository evidence shows no live surface is affected.",{"type":46,"value":928},"\n\u003C\u002Fbest_practices>",{"type":41,"tag":930,"props":931,"children":932},"patterns",{},[933,934,953,954,971,972,989,990],{"type":46,"value":74},{"type":41,"tag":935,"props":936,"children":938},"pattern",{"name":937},"daily_patch_minor_update",[939,940,945,946,952],{"type":46,"value":88},{"type":41,"tag":90,"props":941,"children":942},{},[943],{"type":46,"value":944},"Safe default for scheduled maintenance.",{"type":46,"value":88},{"type":41,"tag":947,"props":948,"children":949},"template",{},[950],{"type":46,"value":951},"inspect manifests and lockfiles -> run a non-mutating outdated report when useful -> select a patch or minor update set -> update with package manager -> run the strongest repository-defined validation plus any required service-level proof -> transition into `create-draft-pr` with a body summarizing the applied updates, validation result, runtime proof, and any deferred packages",{"type":46,"value":74},{"type":46,"value":74},{"type":41,"tag":935,"props":955,"children":957},{"name":956},"failed_upgrade_learning",[958,959,964,965,970],{"type":46,"value":88},{"type":41,"tag":90,"props":960,"children":961},{},[962],{"type":46,"value":963},"Preserve useful knowledge when an update is not safe to ship.",{"type":46,"value":88},{"type":41,"tag":947,"props":966,"children":967},{},[968],{"type":46,"value":969},"attempt constrained update -> validation fails -> diagnose once -> revert this run's dependency changes if still unsafe -> report deferred outcome with the exact blocker",{"type":46,"value":74},{"type":46,"value":74},{"type":41,"tag":935,"props":973,"children":975},{"name":974},"major_upgrade_deferral",[976,977,982,983,988],{"type":46,"value":88},{"type":41,"tag":90,"props":978,"children":979},{},[980],{"type":46,"value":981},"Keep routine automation from turning into migration work.",{"type":46,"value":88},{"type":41,"tag":947,"props":984,"children":985},{},[986],{"type":46,"value":987},"detect major update -> check explicit request -> if absent, defer -> continue with safer updates or no-op",{"type":46,"value":74},{"type":46,"value":74},{"type":41,"tag":935,"props":991,"children":993},{"name":992},"dependabot_alert_follow_up",[994,995,1000,1001,1006],{"type":46,"value":88},{"type":41,"tag":90,"props":996,"children":997},{},[998],{"type":46,"value":999},"Resolve one explicit Dependabot alert or one tightly related alert bundle.",{"type":46,"value":88},{"type":41,"tag":947,"props":1002,"children":1003},{},[1004],{"type":46,"value":1005},"classify run as `alert_follow_up` immediately -> re-fetch the open alert via GitHub before any generic outdated scan -> constrain the update set to the named package or manifest or workspace -> apply the smallest safe update that is likely to clear the alert, widening only to a tightly related workspace or dependency bundle when necessary -> run the strongest practical repository-defined validation plus any required service-level proof -> report whether the alert-backed update landed, was already closed, or was deferred",{"type":46,"value":74},{"items":1008,"total":1167},[1009,1025,1041,1053,1069,1083,1102,1111,1120,1132,1143,1156],{"slug":1010,"name":1010,"fn":1011,"description":1012,"org":1013,"tags":1014,"stars":23,"repoUrl":24,"updatedAt":1024},"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},[1015,1018,1021],{"name":1016,"slug":1017,"type":16},"Code Review","code-review",{"name":1019,"slug":1020,"type":16},"GitHub","github",{"name":1022,"slug":1023,"type":16},"Pull Requests","pull-requests","2026-07-19T05:38:26.334008",{"slug":1026,"name":1026,"fn":1027,"description":1028,"org":1029,"tags":1030,"stars":23,"repoUrl":24,"updatedAt":1040},"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},[1031,1034,1037],{"name":1032,"slug":1033,"type":16},"Browser Automation","browser-automation",{"name":1035,"slug":1036,"type":16},"CLI","cli",{"name":1038,"slug":1039,"type":16},"Testing","testing","2026-07-16T06:02:26.045337",{"slug":1042,"name":1042,"fn":1043,"description":1044,"org":1045,"tags":1046,"stars":23,"repoUrl":24,"updatedAt":1052},"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},[1047,1048,1049],{"name":18,"slug":19,"type":16},{"name":1032,"slug":1033,"type":16},{"name":1050,"slug":1051,"type":16},"Screenshots","screenshots","2026-08-01T05:44:47.369293",{"slug":1054,"name":1054,"fn":1055,"description":1056,"org":1057,"tags":1058,"stars":23,"repoUrl":24,"updatedAt":1068},"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},[1059,1062,1065],{"name":1060,"slug":1061,"type":16},"CI\u002FCD","ci-cd",{"name":1063,"slug":1064,"type":16},"Debugging","debugging",{"name":1066,"slug":1067,"type":16},"GitHub Actions","github-actions","2026-07-23T05:40:41.726992",{"slug":1070,"name":1070,"fn":1071,"description":1072,"org":1073,"tags":1074,"stars":23,"repoUrl":24,"updatedAt":1082},"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},[1075,1078,1079],{"name":1076,"slug":1077,"type":16},"Code Analysis","code-analysis",{"name":1016,"slug":1017,"type":16},{"name":1080,"slug":1081,"type":16},"QA","qa","2026-07-26T05:47:47.339721",{"slug":1084,"name":1084,"fn":1085,"description":1086,"org":1087,"tags":1088,"stars":23,"repoUrl":24,"updatedAt":1101},"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},[1089,1090,1093,1094,1095,1098],{"name":1076,"slug":1077,"type":16},{"name":1091,"slug":1092,"type":16},"CodeQL","codeql",{"name":1063,"slug":1064,"type":16},{"name":1019,"slug":1020,"type":16},{"name":1096,"slug":1097,"type":16},"Security","security",{"name":1099,"slug":1100,"type":16},"Triage","triage","2026-07-29T05:39:37.784486",{"slug":835,"name":835,"fn":1103,"description":1104,"org":1105,"tags":1106,"stars":23,"repoUrl":24,"updatedAt":1110},"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},[1107,1108,1109],{"name":18,"slug":19,"type":16},{"name":1019,"slug":1020,"type":16},{"name":1022,"slug":1023,"type":16},"2026-07-16T06:00:31.733527",{"slug":1112,"name":1112,"fn":1113,"description":1114,"org":1115,"tags":1116,"stars":23,"repoUrl":24,"updatedAt":1119},"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},[1117,1118],{"name":1019,"slug":1020,"type":16},{"name":1022,"slug":1023,"type":16},"2026-07-16T06:03:03.397562",{"slug":1121,"name":1121,"fn":1122,"description":1123,"org":1124,"tags":1125,"stars":23,"repoUrl":24,"updatedAt":1131},"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},[1126,1127,1130],{"name":1063,"slug":1064,"type":16},{"name":1128,"slug":1129,"type":16},"Git","git",{"name":1038,"slug":1039,"type":16},"2026-07-16T06:03:07.255013",{"slug":1133,"name":1133,"fn":1134,"description":1135,"org":1136,"tags":1137,"stars":23,"repoUrl":24,"updatedAt":1142},"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},[1138,1139,1140,1141],{"name":18,"slug":19,"type":16},{"name":1019,"slug":1020,"type":16},{"name":1096,"slug":1097,"type":16},{"name":1099,"slug":1100,"type":16},"2026-07-29T05:39:38.757423",{"slug":1144,"name":1144,"fn":1145,"description":1146,"org":1147,"tags":1148,"stars":23,"repoUrl":24,"updatedAt":1155},"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},[1149,1152],{"name":1150,"slug":1151,"type":16},"Configuration","configuration",{"name":1153,"slug":1154,"type":16},"Local Development","local-development","2026-08-01T05:44:46.333988",{"slug":1157,"name":1157,"fn":1158,"description":1159,"org":1160,"tags":1161,"stars":23,"repoUrl":24,"updatedAt":1166},"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},[1162,1163],{"name":1076,"slug":1077,"type":16},{"name":1164,"slug":1165,"type":16},"Documentation","documentation","2026-07-16T06:00:34.090082",33,{"items":1169,"total":1167},[1170,1176,1182,1188,1194,1200,1209],{"slug":1010,"name":1010,"fn":1011,"description":1012,"org":1171,"tags":1172,"stars":23,"repoUrl":24,"updatedAt":1024},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[1173,1174,1175],{"name":1016,"slug":1017,"type":16},{"name":1019,"slug":1020,"type":16},{"name":1022,"slug":1023,"type":16},{"slug":1026,"name":1026,"fn":1027,"description":1028,"org":1177,"tags":1178,"stars":23,"repoUrl":24,"updatedAt":1040},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[1179,1180,1181],{"name":1032,"slug":1033,"type":16},{"name":1035,"slug":1036,"type":16},{"name":1038,"slug":1039,"type":16},{"slug":1042,"name":1042,"fn":1043,"description":1044,"org":1183,"tags":1184,"stars":23,"repoUrl":24,"updatedAt":1052},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[1185,1186,1187],{"name":18,"slug":19,"type":16},{"name":1032,"slug":1033,"type":16},{"name":1050,"slug":1051,"type":16},{"slug":1054,"name":1054,"fn":1055,"description":1056,"org":1189,"tags":1190,"stars":23,"repoUrl":24,"updatedAt":1068},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[1191,1192,1193],{"name":1060,"slug":1061,"type":16},{"name":1063,"slug":1064,"type":16},{"name":1066,"slug":1067,"type":16},{"slug":1070,"name":1070,"fn":1071,"description":1072,"org":1195,"tags":1196,"stars":23,"repoUrl":24,"updatedAt":1082},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[1197,1198,1199],{"name":1076,"slug":1077,"type":16},{"name":1016,"slug":1017,"type":16},{"name":1080,"slug":1081,"type":16},{"slug":1084,"name":1084,"fn":1085,"description":1086,"org":1201,"tags":1202,"stars":23,"repoUrl":24,"updatedAt":1101},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[1203,1204,1205,1206,1207,1208],{"name":1076,"slug":1077,"type":16},{"name":1091,"slug":1092,"type":16},{"name":1063,"slug":1064,"type":16},{"name":1019,"slug":1020,"type":16},{"name":1096,"slug":1097,"type":16},{"name":1099,"slug":1100,"type":16},{"slug":835,"name":835,"fn":1103,"description":1104,"org":1210,"tags":1211,"stars":23,"repoUrl":24,"updatedAt":1110},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[1212,1213,1214],{"name":18,"slug":19,"type":16},{"name":1019,"slug":1020,"type":16},{"name":1022,"slug":1023,"type":16}]