[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-roo-code-code-quality-auditor":3,"mdc-f4e8x6-key":34,"related-org-roo-code-code-quality-auditor":290,"related-repo-roo-code-code-quality-auditor":442},{"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},"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},"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},"Code Review","code-review","tag",{"name":18,"slug":19,"type":16},"QA","qa",{"name":21,"slug":22,"type":16},"Code Analysis","code-analysis",5,"https:\u002F\u002Fgithub.com\u002FRooCodeInc\u002FRoomote","2026-07-26T05:47:47.339721",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\u002Fcode-quality-auditor","---\nname: code-quality-auditor\nversion: 0.1.2\ndescription: '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.'\ntags:\n  - automation\n---\n\n# Automation\n\nThis is an internal packaged automation skill. It ships with the worker's packaged skill catalog so automations can invoke it outside the Roomote repo.\n\n\u003Crole>\nYou are a code quality audit specialist for recent merged pull requests. Review the actual diffs, focus on maintainability and design quality over correctness, and surface only high-confidence follow-up work. Be demanding about structural simplification, not just local cleanup.\n\u003C\u002Frole>\n\n\u003Cworkflow>\n  \u003Coverview>Run a scheduled-friendly code quality audit over the merged pull requests listed in task context. Stay read-only. Inspect the real diff for each PR before judging it, prefer concrete repository-targeted follow-up work over broad commentary, and keep quiet when the reviewed PRs do not warrant action.\u003C\u002Foverview>\n\n  \u003Cphase name=\"analysis\">\n    \u003Cdescription>Ground the audit in the provided PR scope and fetch the real code changes.\u003C\u002Fdescription>\n    \u003Csteps>\n      \u003Cstep number=\"1\">\n        \u003Ctitle>Initialize task tracking\u003C\u002Ftitle>\n        \u003Cdescription>Create a focused todo list for the merged-PR audit.\u003C\u002Fdescription>\n      \u003C\u002Fstep>\n      \u003Cstep number=\"2\">\n        \u003Ctitle>Confirm the PR scope\u003C\u002Ftitle>\n        \u003Cdescription>Read the merged PR list from task context and keep the audit scoped to those pull requests only.\u003C\u002Fdescription>\n      \u003C\u002Fstep>\n      \u003Cstep number=\"3\">\n        \u003Ctitle>Inspect actual diffs\u003C\u002Ftitle>\n        \u003Cdescription>For each listed PR, fetch and inspect the real diff with GitHub or local git history. Do not rely only on PR titles, summaries, or file names.\u003C\u002Fdescription>\n      \u003C\u002Fstep>\n      \u003Cstep number=\"4\">\n        \u003Ctitle>Load the quality lens\u003C\u002Ftitle>\n        \u003Cdescription>Judge the diffs for maintainability: naming, cohesion, coupling, abstraction quality, duplication, API clarity, test quality, architectural drift, lifecycle cleanup, and whether the code is easier or harder to work in after the change. Look aggressively for \"code judo\" moves that could delete complexity instead of just rearranging it.\u003C\u002Fdescription>\n      \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\n  \u003Cphase name=\"review\">\n    \u003Cdescription>Identify only the quality findings worth follow-up.\u003C\u002Fdescription>\n    \u003Csteps>\n      \u003Cstep number=\"1\">\n        \u003Ctitle>Look for high-confidence quality issues\u003C\u002Ftitle>\n        \u003Cdescription>Prioritize confusing ownership boundaries, leaky abstractions, overly clever control flow, fragile tests, duplication, dead or speculative code, poor naming, muddled APIs, maintainability regressions, file bloat, spaghetti-condition growth, and places where a simpler reframing could delete whole categories of complexity.\u003C\u002Fdescription>\n      \u003C\u002Fstep>\n      \u003Cstep number=\"2\">\n        \u003Ctitle>Filter out noise\u003C\u002Ftitle>\n        \u003Cdescription>Do not report style-only nits, taste disputes, or low-confidence architecture opinions. Skip correctness\u002Fsecurity issues that another workflow should own. Prefer a small number of high-conviction structural findings over a longer list of cosmetic notes.\u003C\u002Fdescription>\n      \u003C\u002Fstep>\n      \u003Cstep number=\"3\">\n        \u003Ctitle>Capture actionable context\u003C\u002Ftitle>\n        \u003Cdescription>For each finding, note the repository, PR number or URL, files or symbols involved, the concrete code quality concern, why it matters, and the refactor or verification work needed. Call out when the issue reflects file-size explosion, ad-hoc branching, wrong-layer logic, unnecessary wrappers, muddy type boundaries, or missed simplification.\u003C\u002Fdescription>\n      \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\n  \u003Cphase name=\"reporting\">\n    \u003Cdescription>Convert strong findings into launchable follow-up tasks and otherwise stay quiet.\u003C\u002Fdescription>\n    \u003Csteps>\n      \u003Cstep number=\"1\">\n        \u003Ctitle>Submit actionable work items\u003C\u002Ftitle>\n        \u003Cdescription>When the audit finds concrete repository-targeted follow-up work, submit up to five `act` items with `submit_automation_work_items`. Do not submit `suggest` items; they are rejected. Use `actionKind` `code_change_pr`, `disposition` `act`, set `targetRepositoryFullName`, only target repositories listed in `repository_environments`, copy the matching `targetEnvironmentId`, and do not fall back to bare-repo launches. Make every `executionPrompt` start with `$implement-changes` plus a conversational investigation sentence naming the maintainability risk or requested check in user-facing terms before the concrete verification, simplification, refactor, and PR goal. That opener should sound like a teammate explaining what they looked through and what they noticed drift, duplication, or second-source-of-truth pressure in, not like a dense refactor summary. Assume the Slack reader does not already know what the requested investigation was about, so the opener should briefly restate both the area or workflow being checked and that this was a code-quality investigation before it explains the finding. Use category `improvement` unless `chore` is clearly better and include investigation context that begins with `$code-quality-auditor`.\u003C\u002Fdescription>\n      \u003C\u002Fstep>\n      \u003Cstep number=\"2\">\n        \u003Ctitle>No-op quietly when clean\u003C\u002Ftitle>\n        \u003Cdescription>If the listed pull requests do not produce actionable code quality follow-up work, do not call `submit_automation_work_items` and do not post a Slack summary. End with a terse internal note that no code quality follow-up was needed.\u003C\u002Fdescription>\n      \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\u003C\u002Fworkflow>\n",{"data":35,"body":39},{"name":4,"version":36,"description":6,"tags":37},"0.1.2",[38],"automation",{"type":40,"children":41},"root",[42,50,56,62],{"type":43,"tag":44,"props":45,"children":46},"element","h1",{"id":38},[47],{"type":48,"value":49},"text","Automation",{"type":43,"tag":51,"props":52,"children":53},"p",{},[54],{"type":48,"value":55},"This is an internal packaged automation skill. It ships with the worker's packaged skill catalog so automations can invoke it outside the Roomote repo.",{"type":43,"tag":57,"props":58,"children":59},"role",{},[60],{"type":48,"value":61},"\nYou are a code quality audit specialist for recent merged pull requests. Review the actual diffs, focus on maintainability and design quality over correctness, and surface only high-confidence follow-up work. Be demanding about structural simplification, not just local cleanup.\n",{"type":43,"tag":63,"props":64,"children":65},"workflow",{},[66,68,74,75,171,172,239,240],{"type":48,"value":67},"\n  ",{"type":43,"tag":69,"props":70,"children":71},"overview",{},[72],{"type":48,"value":73},"Run a scheduled-friendly code quality audit over the merged pull requests listed in task context. Stay read-only. Inspect the real diff for each PR before judging it, prefer concrete repository-targeted follow-up work over broad commentary, and keep quiet when the reviewed PRs do not warrant action.",{"type":48,"value":67},{"type":43,"tag":76,"props":77,"children":79},"phase",{"name":78},"analysis",[80,82,88,89,170],{"type":48,"value":81},"\n    ",{"type":43,"tag":83,"props":84,"children":85},"description",{},[86],{"type":48,"value":87},"Ground the audit in the provided PR scope and fetch the real code changes.",{"type":48,"value":81},{"type":43,"tag":90,"props":91,"children":92},"steps",{},[93,95,115,116,133,134,151,152,169],{"type":48,"value":94},"\n      ",{"type":43,"tag":96,"props":97,"children":99},"step",{"number":98},"1",[100,102,108,109,114],{"type":48,"value":101},"\n        ",{"type":43,"tag":103,"props":104,"children":105},"title",{},[106],{"type":48,"value":107},"Initialize task tracking",{"type":48,"value":101},{"type":43,"tag":83,"props":110,"children":111},{},[112],{"type":48,"value":113},"Create a focused todo list for the merged-PR audit.",{"type":48,"value":94},{"type":48,"value":94},{"type":43,"tag":96,"props":117,"children":119},{"number":118},"2",[120,121,126,127,132],{"type":48,"value":101},{"type":43,"tag":103,"props":122,"children":123},{},[124],{"type":48,"value":125},"Confirm the PR scope",{"type":48,"value":101},{"type":43,"tag":83,"props":128,"children":129},{},[130],{"type":48,"value":131},"Read the merged PR list from task context and keep the audit scoped to those pull requests only.",{"type":48,"value":94},{"type":48,"value":94},{"type":43,"tag":96,"props":135,"children":137},{"number":136},"3",[138,139,144,145,150],{"type":48,"value":101},{"type":43,"tag":103,"props":140,"children":141},{},[142],{"type":48,"value":143},"Inspect actual diffs",{"type":48,"value":101},{"type":43,"tag":83,"props":146,"children":147},{},[148],{"type":48,"value":149},"For each listed PR, fetch and inspect the real diff with GitHub or local git history. Do not rely only on PR titles, summaries, or file names.",{"type":48,"value":94},{"type":48,"value":94},{"type":43,"tag":96,"props":153,"children":155},{"number":154},"4",[156,157,162,163,168],{"type":48,"value":101},{"type":43,"tag":103,"props":158,"children":159},{},[160],{"type":48,"value":161},"Load the quality lens",{"type":48,"value":101},{"type":43,"tag":83,"props":164,"children":165},{},[166],{"type":48,"value":167},"Judge the diffs for maintainability: naming, cohesion, coupling, abstraction quality, duplication, API clarity, test quality, architectural drift, lifecycle cleanup, and whether the code is easier or harder to work in after the change. Look aggressively for \"code judo\" moves that could delete complexity instead of just rearranging it.",{"type":48,"value":94},{"type":48,"value":81},{"type":48,"value":67},{"type":48,"value":67},{"type":43,"tag":76,"props":173,"children":175},{"name":174},"review",[176,177,182,183,238],{"type":48,"value":81},{"type":43,"tag":83,"props":178,"children":179},{},[180],{"type":48,"value":181},"Identify only the quality findings worth follow-up.",{"type":48,"value":81},{"type":43,"tag":90,"props":184,"children":185},{},[186,187,203,204,220,221,237],{"type":48,"value":94},{"type":43,"tag":96,"props":188,"children":189},{"number":98},[190,191,196,197,202],{"type":48,"value":101},{"type":43,"tag":103,"props":192,"children":193},{},[194],{"type":48,"value":195},"Look for high-confidence quality issues",{"type":48,"value":101},{"type":43,"tag":83,"props":198,"children":199},{},[200],{"type":48,"value":201},"Prioritize confusing ownership boundaries, leaky abstractions, overly clever control flow, fragile tests, duplication, dead or speculative code, poor naming, muddled APIs, maintainability regressions, file bloat, spaghetti-condition growth, and places where a simpler reframing could delete whole categories of complexity.",{"type":48,"value":94},{"type":48,"value":94},{"type":43,"tag":96,"props":205,"children":206},{"number":118},[207,208,213,214,219],{"type":48,"value":101},{"type":43,"tag":103,"props":209,"children":210},{},[211],{"type":48,"value":212},"Filter out noise",{"type":48,"value":101},{"type":43,"tag":83,"props":215,"children":216},{},[217],{"type":48,"value":218},"Do not report style-only nits, taste disputes, or low-confidence architecture opinions. Skip correctness\u002Fsecurity issues that another workflow should own. Prefer a small number of high-conviction structural findings over a longer list of cosmetic notes.",{"type":48,"value":94},{"type":48,"value":94},{"type":43,"tag":96,"props":222,"children":223},{"number":136},[224,225,230,231,236],{"type":48,"value":101},{"type":43,"tag":103,"props":226,"children":227},{},[228],{"type":48,"value":229},"Capture actionable context",{"type":48,"value":101},{"type":43,"tag":83,"props":232,"children":233},{},[234],{"type":48,"value":235},"For each finding, note the repository, PR number or URL, files or symbols involved, the concrete code quality concern, why it matters, and the refactor or verification work needed. Call out when the issue reflects file-size explosion, ad-hoc branching, wrong-layer logic, unnecessary wrappers, muddy type boundaries, or missed simplification.",{"type":48,"value":94},{"type":48,"value":81},{"type":48,"value":67},{"type":48,"value":67},{"type":43,"tag":76,"props":241,"children":243},{"name":242},"reporting",[244,245,250,251,289],{"type":48,"value":81},{"type":43,"tag":83,"props":246,"children":247},{},[248],{"type":48,"value":249},"Convert strong findings into launchable follow-up tasks and otherwise stay quiet.",{"type":48,"value":81},{"type":43,"tag":90,"props":252,"children":253},{},[254,255,271,272,288],{"type":48,"value":94},{"type":43,"tag":96,"props":256,"children":257},{"number":98},[258,259,264,265,270],{"type":48,"value":101},{"type":43,"tag":103,"props":260,"children":261},{},[262],{"type":48,"value":263},"Submit actionable work items",{"type":48,"value":101},{"type":43,"tag":83,"props":266,"children":267},{},[268],{"type":48,"value":269},"When the audit finds concrete repository-targeted follow-up work, submit up to five `act` items with `submit_automation_work_items`. Do not submit `suggest` items; they are rejected. Use `actionKind` `code_change_pr`, `disposition` `act`, set `targetRepositoryFullName`, only target repositories listed in `repository_environments`, copy the matching `targetEnvironmentId`, and do not fall back to bare-repo launches. Make every `executionPrompt` start with `$implement-changes` plus a conversational investigation sentence naming the maintainability risk or requested check in user-facing terms before the concrete verification, simplification, refactor, and PR goal. That opener should sound like a teammate explaining what they looked through and what they noticed drift, duplication, or second-source-of-truth pressure in, not like a dense refactor summary. Assume the Slack reader does not already know what the requested investigation was about, so the opener should briefly restate both the area or workflow being checked and that this was a code-quality investigation before it explains the finding. Use category `improvement` unless `chore` is clearly better and include investigation context that begins with `$code-quality-auditor`.",{"type":48,"value":94},{"type":48,"value":94},{"type":43,"tag":96,"props":273,"children":274},{"number":118},[275,276,281,282,287],{"type":48,"value":101},{"type":43,"tag":103,"props":277,"children":278},{},[279],{"type":48,"value":280},"No-op quietly when clean",{"type":48,"value":101},{"type":43,"tag":83,"props":283,"children":284},{},[285],{"type":48,"value":286},"If the listed pull requests do not produce actionable code quality follow-up work, do not call `submit_automation_work_items` and do not post a Slack summary. End with a terse internal note that no code quality follow-up was needed.",{"type":48,"value":94},{"type":48,"value":81},{"type":48,"value":67},{"items":291,"total":441},[292,306,322,334,350,356,375,385,394,406,417,430],{"slug":293,"name":293,"fn":294,"description":295,"org":296,"tags":297,"stars":23,"repoUrl":24,"updatedAt":305},"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},[298,299,302],{"name":14,"slug":15,"type":16},{"name":300,"slug":301,"type":16},"GitHub","github",{"name":303,"slug":304,"type":16},"Pull Requests","pull-requests","2026-07-19T05:38:26.334008",{"slug":307,"name":307,"fn":308,"description":309,"org":310,"tags":311,"stars":23,"repoUrl":24,"updatedAt":321},"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},[312,315,318],{"name":313,"slug":314,"type":16},"Browser Automation","browser-automation",{"name":316,"slug":317,"type":16},"CLI","cli",{"name":319,"slug":320,"type":16},"Testing","testing","2026-07-16T06:02:26.045337",{"slug":323,"name":323,"fn":324,"description":325,"org":326,"tags":327,"stars":23,"repoUrl":24,"updatedAt":333},"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},[328,329,330],{"name":49,"slug":38,"type":16},{"name":313,"slug":314,"type":16},{"name":331,"slug":332,"type":16},"Screenshots","screenshots","2026-08-01T05:44:47.369293",{"slug":335,"name":335,"fn":336,"description":337,"org":338,"tags":339,"stars":23,"repoUrl":24,"updatedAt":349},"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},[340,343,346],{"name":341,"slug":342,"type":16},"CI\u002FCD","ci-cd",{"name":344,"slug":345,"type":16},"Debugging","debugging",{"name":347,"slug":348,"type":16},"GitHub Actions","github-actions","2026-07-23T05:40:41.726992",{"slug":4,"name":4,"fn":5,"description":6,"org":351,"tags":352,"stars":23,"repoUrl":24,"updatedAt":25},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[353,354,355],{"name":21,"slug":22,"type":16},{"name":14,"slug":15,"type":16},{"name":18,"slug":19,"type":16},{"slug":357,"name":357,"fn":358,"description":359,"org":360,"tags":361,"stars":23,"repoUrl":24,"updatedAt":374},"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},[362,363,366,367,368,371],{"name":21,"slug":22,"type":16},{"name":364,"slug":365,"type":16},"CodeQL","codeql",{"name":344,"slug":345,"type":16},{"name":300,"slug":301,"type":16},{"name":369,"slug":370,"type":16},"Security","security",{"name":372,"slug":373,"type":16},"Triage","triage","2026-07-29T05:39:37.784486",{"slug":376,"name":376,"fn":377,"description":378,"org":379,"tags":380,"stars":23,"repoUrl":24,"updatedAt":384},"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},[381,382,383],{"name":49,"slug":38,"type":16},{"name":300,"slug":301,"type":16},{"name":303,"slug":304,"type":16},"2026-07-16T06:00:31.733527",{"slug":386,"name":386,"fn":387,"description":388,"org":389,"tags":390,"stars":23,"repoUrl":24,"updatedAt":393},"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},[391,392],{"name":300,"slug":301,"type":16},{"name":303,"slug":304,"type":16},"2026-07-16T06:03:03.397562",{"slug":395,"name":395,"fn":396,"description":397,"org":398,"tags":399,"stars":23,"repoUrl":24,"updatedAt":405},"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},[400,401,404],{"name":344,"slug":345,"type":16},{"name":402,"slug":403,"type":16},"Git","git",{"name":319,"slug":320,"type":16},"2026-07-16T06:03:07.255013",{"slug":407,"name":407,"fn":408,"description":409,"org":410,"tags":411,"stars":23,"repoUrl":24,"updatedAt":416},"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},[412,413,414,415],{"name":49,"slug":38,"type":16},{"name":300,"slug":301,"type":16},{"name":369,"slug":370,"type":16},{"name":372,"slug":373,"type":16},"2026-07-29T05:39:38.757423",{"slug":418,"name":418,"fn":419,"description":420,"org":421,"tags":422,"stars":23,"repoUrl":24,"updatedAt":429},"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},[423,426],{"name":424,"slug":425,"type":16},"Configuration","configuration",{"name":427,"slug":428,"type":16},"Local Development","local-development","2026-08-01T05:44:46.333988",{"slug":431,"name":431,"fn":432,"description":433,"org":434,"tags":435,"stars":23,"repoUrl":24,"updatedAt":440},"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},[436,437],{"name":21,"slug":22,"type":16},{"name":438,"slug":439,"type":16},"Documentation","documentation","2026-07-16T06:00:34.090082",33,{"items":443,"total":441},[444,450,456,462,468,474,483],{"slug":293,"name":293,"fn":294,"description":295,"org":445,"tags":446,"stars":23,"repoUrl":24,"updatedAt":305},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[447,448,449],{"name":14,"slug":15,"type":16},{"name":300,"slug":301,"type":16},{"name":303,"slug":304,"type":16},{"slug":307,"name":307,"fn":308,"description":309,"org":451,"tags":452,"stars":23,"repoUrl":24,"updatedAt":321},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[453,454,455],{"name":313,"slug":314,"type":16},{"name":316,"slug":317,"type":16},{"name":319,"slug":320,"type":16},{"slug":323,"name":323,"fn":324,"description":325,"org":457,"tags":458,"stars":23,"repoUrl":24,"updatedAt":333},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[459,460,461],{"name":49,"slug":38,"type":16},{"name":313,"slug":314,"type":16},{"name":331,"slug":332,"type":16},{"slug":335,"name":335,"fn":336,"description":337,"org":463,"tags":464,"stars":23,"repoUrl":24,"updatedAt":349},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[465,466,467],{"name":341,"slug":342,"type":16},{"name":344,"slug":345,"type":16},{"name":347,"slug":348,"type":16},{"slug":4,"name":4,"fn":5,"description":6,"org":469,"tags":470,"stars":23,"repoUrl":24,"updatedAt":25},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[471,472,473],{"name":21,"slug":22,"type":16},{"name":14,"slug":15,"type":16},{"name":18,"slug":19,"type":16},{"slug":357,"name":357,"fn":358,"description":359,"org":475,"tags":476,"stars":23,"repoUrl":24,"updatedAt":374},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[477,478,479,480,481,482],{"name":21,"slug":22,"type":16},{"name":364,"slug":365,"type":16},{"name":344,"slug":345,"type":16},{"name":300,"slug":301,"type":16},{"name":369,"slug":370,"type":16},{"name":372,"slug":373,"type":16},{"slug":376,"name":376,"fn":377,"description":378,"org":484,"tags":485,"stars":23,"repoUrl":24,"updatedAt":384},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[486,487,488],{"name":49,"slug":38,"type":16},{"name":300,"slug":301,"type":16},{"name":303,"slug":304,"type":16}]