[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-roo-code-refactor-code":3,"mdc-jjgmk0-key":31,"related-org-roo-code-refactor-code":1202,"related-repo-roo-code-refactor-code":1362},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":12,"stars":20,"repoUrl":21,"updatedAt":22,"license":23,"forks":24,"topics":25,"repo":26,"sourceUrl":29,"mdContent":30},"refactor-code","survey and plan code refactoring","Automation skill: run a broad refactor survey across the codebase, rank candidates by leverage, and produce standalone plans for the top opportunities without auto-implementing them.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},"roo-code","Roo Code","https:\u002F\u002Fpexgzepcugksgbtrxkhf.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Forg-logos\u002Froo-code.png","RooCodeInc",[13,17],{"name":14,"slug":15,"type":16},"Architecture","architecture","tag",{"name":18,"slug":19,"type":16},"Code Analysis","code-analysis",5,"https:\u002F\u002Fgithub.com\u002FRooCodeInc\u002FRoomote","2026-07-26T05:47:49.367061",null,0,[],{"repoUrl":21,"stars":20,"forks":24,"topics":27,"description":28},[],"Your own cloud coding agent. Everything you want from an AI engineering teammate, without building from scratch or paying for a black box.","https:\u002F\u002Fgithub.com\u002FRooCodeInc\u002FRoomote\u002Ftree\u002FHEAD\u002Fpackages\u002Fcloud-agents\u002Fsrc\u002Fserver\u002Fworkflows\u002Fskills\u002Fstandard\u002Frefactor-code","---\nname: refactor-code\nversion: 0.5.0\ndescription: 'Automation skill: run a broad refactor survey across the codebase, rank candidates by leverage, and produce standalone plans for the top opportunities without auto-implementing them.'\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 refactor scout for Roomote. Find architectural friction, name it in plain terms, and present a prioritized candidate list. Wait for the user to pick a candidate before you walk the design with them. This skill never auto-implements a refactor. Implementation is a separate, explicit follow-up the user requests.\n\u003C\u002Frole>\n\n## Architecture vocabulary\n\nUse these terms exactly when describing candidates. Consistent language is the point. Do not drift into \"component,\" \"service,\" \"API,\" or \"boundary.\" Borrowed from John Ousterhout via Matt Pocock's _improve-codebase-architecture_ skill.\n\n- **Module** -- anything with an interface and an implementation (function, class, package, slice, route, queue handler, ...).\n- **Interface** -- everything a caller must know to use the module: types, invariants, error modes, ordering, configuration. Not just the type signature.\n- **Implementation** -- the code inside.\n- **Depth** -- leverage at the interface: a lot of behaviour behind a small interface. **Deep** = high leverage, **Shallow** = interface nearly as complex as the implementation.\n- **Seam** -- where an interface lives; a place behaviour can be altered without editing in place. Use this, not \"boundary.\"\n- **Adapter** -- a concrete thing satisfying an interface at a seam.\n- **Leverage** -- what callers get from depth.\n- **Locality** -- what maintainers get from depth: change, bugs, knowledge concentrated in one place.\n\nKey principles:\n\n- **Deletion test**: imagine deleting the module. If complexity vanishes, it was a pass-through. If complexity reappears across N callers, it was earning its keep.\n- **The interface is the test surface.**\n- **One adapter = hypothetical seam. Two adapters = real seam.**\n\n\u003Cworkflow>\n  \u003Coverview>Run a survey-rank-and-present refactor workflow. Read repository guidance and the relevant architecture docs, do a broad initial pass across the codebase to surface candidates from multiple areas, rank that candidate pool by expected leverage, create standalone implementation-plan artifacts for the top 5 candidates when artifact tooling is available, present the ranked list plus the top-5 linked plans, and, when the user picks one, walk the design via a grilling conversation. This skill does not implement candidates.\u003C\u002Foverview>\n\n  \u003Cphase name=\"setup\">\n    \u003Cdescription>Ground the scan in repository guidance and any explicit scope from the prompt.\u003C\u002Fdescription>\n    \u003Csteps>\n      \u003Cstep number=\"1\">\n        \u003Ctitle>Initialize task tracking\u003C\u002Ftitle>\n        \u003Cdescription>Create a focused todo list scoped to this scan.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Create a todo list covering guidance review, repo-survey scope selection, broad scan, candidate ranking, top-5 plan creation, presentation, and optional grilling.\u003C\u002Faction>\n          \u003Caction>This skill does not implement refactors. If the prompt asks for an implementation, present the candidate first and explicitly hand off to `implement-repo-change` or another delivery skill only after the user confirms which candidate to pursue.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>A todo list exists and reflects the scan-and-present lifecycle, not an implementation lifecycle.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n      \u003Cstep number=\"2\">\n        \u003Ctitle>Read repository guidance\u003C\u002Ftitle>\n        \u003Cdescription>Anchor the scan in Roomote's existing knowledge map.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Read `AGENTS.md` and package-level `AGENTS.md` files for surface-ownership notes and quick-start guidance.\u003C\u002Faction>\n          \u003Caction>If the prompt names a specific area (a package, an app, a workflow), inspect that area's owned source and nearby docs first. Treat existing domain language in code and docs as the project's vocabulary. Name candidates using the terms already in use, not invented synonyms.\u003C\u002Faction>\n          \u003Caction>When you find a load-bearing architectural decision embodied in current code or docs, do not propose a candidate that contradicts it unless friction is real enough to justify revisiting that decision, and say so explicitly when you do.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>The scan starts from documented surface ownership and the project's own vocabulary.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n      \u003Cstep number=\"3\">\n        \u003Ctitle>Set scan scope\u003C\u002Ftitle>\n        \u003Cdescription>Pick the right scan width for this run.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>If the prompt names a package, app, file glob, or subsystem, scan only that scope.\u003C\u002Faction>\n          \u003Caction>If the prompt is open-ended, treat the repository as the survey scope, but do a deliberate breadth-first pass instead of trying to read everything deeply. Sample several major apps and packages under `apps\u002F` and `packages\u002F`, and keep moving until you have candidate coverage across multiple areas of the codebase.\u003C\u002Faction>\n          \u003Caction>For broad scans, state both the survey scope and the sampling shape at the top of the report: which major surfaces you looked at, which ones only got a light pass, and any important exclusions. The goal is a repo-wide candidate pool, not repo-wide deep reading.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>The run either respects an explicit user-provided scope or performs a deliberate broad survey across multiple major surfaces confirmed in current source.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\n  \u003Cphase name=\"scan\">\n    \u003Cdescription>Walk the chosen scope and note where you experience friction.\u003C\u002Fdescription>\n    \u003Csteps>\n      \u003Cstep number=\"1\">\n        \u003Ctitle>Survey broadly first\u003C\u002Ftitle>\n        \u003Cdescription>Do a breadth-first pass before deepening any single area.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Walk the chosen scope inline by default. Read files directly with the harness's read or grep tools. This keeps the scan working in any harness Roomote runs in, including environments where subagent delegation is not enabled. Only delegate to a sub-agent (an `explorer` or `worker` in Roomote's task runtime, or `Explore` in harnesses that expose it) when the surrounding harness has explicitly enabled subagent delegation and the scope is genuinely large enough that context-window pressure justifies it. Default to local reads.\u003C\u002Faction>\n          \u003Caction>For open-ended scans, use `AGENTS.md` plus the major apps and packages under `apps\u002F` and `packages\u002F` as the route plan. Sample multiple major surfaces in current source before committing to any shortlist so the first noisy area does not crowd out the rest of the codebase.\u003C\u002Faction>\n          \u003Caction>While exploring, watch for: places where understanding one concept requires bouncing between many small modules; modules that are **shallow** (interface nearly as complex as the implementation); pure functions extracted only for testability where the real bugs live in the calling pattern (no **locality**); tightly-coupled modules whose seams leak; parts of the scope that are untested or hard to test through the current interface; and TODOs, lint patterns, or repeated review-feedback themes that point at structural friction rather than spot fixes.\u003C\u002Faction>\n          \u003Caction>Aim to surface a candidate pool from multiple areas of the codebase when the prompt is broad. Variety is not a quota, but it is a signal that the survey really was broad enough to support ranking.\u003C\u002Faction>\n          \u003Caction>Apply the **deletion test** to anything you suspect is shallow: would deleting it concentrate complexity (good module, leave it) or just move it (pass-through, candidate for removal or absorption)?\u003C\u002Faction>\n          \u003Caction>Confirm each candidate exists in current source with a quick read. If a candidate no longer matches reality, drop it and note why in the report.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>The scan produced a cross-area candidate pool with concrete file references and a friction description for each, using local reads unless the harness explicitly enabled subagent delegation.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n      \u003Cstep number=\"2\">\n        \u003Ctitle>Apply prior decisions from docs\u003C\u002Ftitle>\n        \u003Cdescription>Filter out anything guidance already settled.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Drop candidates that contradict a load-bearing decision embodied in current architecture or docs unless the friction is real enough to argue for revisiting it. In that case, mark the candidate as \"contradicts \u003Cdecision> - but worth reopening because...\"\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>The candidate list does not silently fight an existing architectural decision.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n      \u003Cstep number=\"3\">\n        \u003Ctitle>Rank the candidate pool\u003C\u002Ftitle>\n        \u003Cdescription>Turn the broad survey into an explicit priority order before writing plans.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Rank candidates by expected leverage-first value, not by discovery order. Make the ordering legible from the source evidence.\u003C\u002Faction>\n          \u003Caction>Use these factors explicitly when ordering the list: \u003Cstrong>Leverage\u002Flocality gain\u003C\u002Fstrong> (how much complexity the deeper module could hide), \u003Cstrong>Breadth of pain\u003C\u002Fstrong> (how many callers or workflows currently pay the cost), \u003Cstrong>Change frequency \u002F drag\u003C\u002Fstrong> (how often maintainers trip over it), \u003Cstrong>Confidence\u003C\u002Fstrong> (how clearly current source and docs support the diagnosis), and \u003Cstrong>Cost\u002Frisk\u003C\u002Fstrong> (cross-package reach, migration complexity, behavior risk, and test gaps).\u003C\u002Faction>\n          \u003Caction>Treat effort and risk as a penalty, not the main goal. The desired order is highest useful leverage first, with similar candidates broken by lower cost and clearer source evidence.\u003C\u002Faction>\n          \u003Caction>For broad scans, use variety across major surfaces as a tie-breaker only when the top candidates are otherwise close. Do not force false diversity if one area genuinely dominates the leverage ranking.\u003C\u002Faction>\n          \u003Caction>Keep the full ranked candidate pool for the summary report, but choose only the top 5 candidates for detailed plan artifacts.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>The workflow has a clearly ranked candidate list and a justified top 5 before any plan artifacts are created.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\n  \u003Cphase name=\"present\">\n    \u003Cdescription>Hand the candidates back as a numbered list and stop.\u003C\u002Fdescription>\n    \u003Csteps>\n      \u003Cstep number=\"1\">\n        \u003Ctitle>Create top-5 plan artifacts\u003C\u002Ftitle>\n        \u003Cdescription>Turn only the top-ranked candidates into standalone implementation briefs before writing the summary report.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>When artifact tooling is available, create one markdown plan artifact for each of the top 5 ranked candidates with `manage_artifacts` action `create_plan` before writing the summary reply.\u003C\u002Faction>\n          \u003Caction>Give each artifact a clear title that includes the candidate rank, area, and candidate name so the user can scan the task artifacts list without opening every file.\u003C\u002Faction>\n          \u003Caction>Make each artifact standalone enough that a user can review it and click `Build this` to launch a follow-up implementation task without rereading the whole scout report. Include the candidate title, rank, survey scope, relevant files or modules, problem, solution direction, expected leverage or locality gain, effort and risk drivers, suggested validation, docs to re-read, and open questions worth preserving.\u003C\u002Faction>\n          \u003Caction>Keep artifact content plan-level. Do not include patches, exact interface signatures, copy-paste code edits, or speculative file moves that have not been justified yet.\u003C\u002Faction>\n          \u003Caction>If artifact tooling is unavailable or artifact creation fails, note that and keep the full detail inline for the top 5 candidates in the summary report instead of inventing broken links.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>The top 5 candidates either have standalone plan artifacts ready for follow-up work or a clear inline fallback because artifact creation was unavailable.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n      \u003Cstep number=\"2\">\n        \u003Ctitle>Write the candidate report\u003C\u002Ftitle>\n        \u003Cdescription>One numbered entry per candidate. Keep the report scannable.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Lead with a one-line scope statement and a one-line summary of how many candidates surfaced across how many areas.\u003C\u002Faction>\n          \u003Caction>Present the full ranked candidate list first so the user can see the broader survey output, even when only the top 5 get detailed plans.\u003C\u002Faction>\n          \u003Caction>For each ranked candidate, include: \u003Cstrong>Files\u003C\u002Fstrong> (which files or modules are involved), \u003Cstrong>Problem\u003C\u002Fstrong> (what friction the current shape creates, in vocabulary the project already uses), \u003Cstrong>Solution sketch\u003C\u002Fstrong> (plain-English description of what would change, no implementation), \u003Cstrong>Benefits\u003C\u002Fstrong> (locality, leverage, and how the test surface would change), \u003Cstrong>Effort hint\u003C\u002Fstrong> (small \u002F medium \u002F large, with named cost drivers such as cross-package reach, test coverage gaps, behavior risk), and \u003Cstrong>Why this rank\u003C\u002Fstrong> (which leverage or risk factors drove its placement).\u003C\u002Faction>\n          \u003Caction>Do not propose interface signatures, file moves, or code edits in the candidate report. Those belong in the grilling phase, after the user picks one.\u003C\u002Faction>\n          \u003Caction>Order candidates by the ranking factors above. Mark any candidates that contradict an existing doc decision so the user is not surprised.\u003C\u002Faction>\n          \u003Caction>After the full ranked list, add a distinct \u003Cstrong>Top 5 plans\u003C\u002Fstrong> section that repeats only the top 5 with their plan links. When plan artifacts exist, keep the inline entries concise and use the artifact for the longer implementation brief rather than duplicating the entire plan in the reply.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>The report is a numbered ranked candidate list using project vocabulary and the architecture terms above, and the top 5 entries have working plan links when artifact tooling was available.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n      \u003Cstep number=\"3\">\n        \u003Ctitle>Hand off to the user\u003C\u002Ftitle>\n        \u003Cdescription>End the report with an explicit prompt and stop.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Ask the user: \"Which of these would you like to explore?\" When plan artifacts were created, tell them they can also open one of the top-5 linked plan artifacts and click `Build this` on the one they want to pursue.\u003C\u002Faction>\n          \u003Caction>For a scheduled scan with no human-in-loop, state that the report is the final artifact.\u003C\u002Faction>\n          \u003Caction>Do not begin implementing. Do not propose a PR. Do not transition into `create-draft-pr` or `push` based on the candidate list alone.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>The skill stops at the candidate report unless the user explicitly picks a candidate to grill.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\n  \u003Cphase name=\"grill\">\n    \u003Cdescription>Optional. Only runs when the user picks a candidate to walk further.\u003C\u002Fdescription>\n    \u003Csteps>\n      \u003Cstep number=\"1\">\n        \u003Ctitle>Walk the design tree\u003C\u002Ftitle>\n        \u003Cdescription>Drop into a grilling conversation about the picked candidate.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>If the candidate came from an earlier report with a linked plan artifact, read that artifact first so the grilling conversation starts from the same implementation brief the user reviewed.\u003C\u002Faction>\n          \u003Caction>Re-read the involved files and any neighbors that would shift if the deepening landed. Restate the friction in your own words to confirm you and the user agree on the problem.\u003C\u002Faction>\n          \u003Caction>Walk the design space: what sits behind the seam, what the interface should know about (types, invariants, error modes, ordering, config), which adapters exist or would need to exist, what tests survive or need to be added, and what behavior risk the change carries.\u003C\u002Faction>\n          \u003Caction>Sharpen vocabulary as needed. If the deepened module wants a name that does not exist in `AGENTS.md` or nearby docs, propose adding it there as part of the change. Do not invent a parallel glossary.\u003C\u002Faction>\n          \u003Caction>If the user rejects the candidate with a load-bearing reason that future scans should respect, call it out explicitly in the report instead of silently dropping it.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>The design conversation walks constraints, dependencies, the deepened shape, and the test surface without writing implementation code.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n      \u003Cstep number=\"2\">\n        \u003Ctitle>Hand off to implementation, do not implement\u003C\u002Ftitle>\n        \u003Cdescription>When the user is ready to ship the change, route to a real implementation skill.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>If the user explicitly says \"go implement this,\" summarize the agreed candidate (problem, solution, scope, validation expectations) and recommend they either use the existing plan artifact via `Build this` or kick off a separate `implement-repo-change` run with the same summary as the prompt. The chore lab refactor scout intentionally does not write the diff itself.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>Code edits, when they happen, happen in a separate skill run owned by the user, not silently appended to this scan.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\n  \u003Cphase name=\"reporting\">\n    \u003Cdescription>Report the outcome clearly.\u003C\u002Fdescription>\n    \u003Csteps>\n      \u003Cstep number=\"1\">\n        \u003Ctitle>Report the run outcome\u003C\u002Ftitle>\n        \u003Cdescription>Finish with a compact status that matches what actually happened.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Summarize the chosen scope, the number of areas sampled, the number of candidates presented, whether top-5 plan artifacts were created, whether the user picked one, whether grilling happened, and any docs or scope blockers.\u003C\u002Faction>\n          \u003Caction>Do not claim a refactor was implemented. This skill never edits source files; if the user wants implementation, that is a separate skill run.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>The final response matches the candidate list and any blockers.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\n\u003Ccompletion_criteria>\n\u003Ccriterion>The scan started from `AGENTS.md` and major repository surfaces and used the project's existing vocabulary.\u003C\u002Fcriterion>\n\u003Ccriterion>The candidate report was numbered, based on either an explicit user-provided scope or a broad multi-area survey, used the architecture vocabulary above for friction descriptions, and linked to plan artifacts for the top 5 candidates when artifact tooling was available.\u003C\u002Fcriterion>\n\u003Ccriterion>The skill did not edit source files. Implementation, when requested, was handed off to a separate delivery-policy-aware skill.\u003C\u002Fcriterion>\n\u003C\u002Fcompletion_criteria>\n\u003C\u002Fworkflow>\n\n\u003Cbest_practices>\n\u003Cguideline priority=\"high\">\n\u003Crule>Scout, do not implement.\u003C\u002Frule>\n\u003Crationale>The PRD value classes for chore lab include \"decision clarified\" and \"work discovered.\" A well-scoped candidate report is a high-value outcome on its own; auto-implementing skips the conversation that decides whether the deepening is correct.\u003C\u002Frationale>\n\u003Cexceptions>If the user explicitly asks for implementation in the same task and a candidate is already agreed, hand off to `implement-repo-change` with a summary. Do not write the diff inside this skill.\u003C\u002Fexceptions>\n\u003C\u002Fguideline>\n\u003Cguideline priority=\"high\">\n\u003Crule>Use the project's own vocabulary first, and the architecture vocabulary above for the meta-shape.\u003C\u002Frule>\n\u003Crationale>Consistent naming is the test for whether a candidate is real. Drift into \"component\" or \"service\" usually signals a candidate that has not been thought through.\u003C\u002Frationale>\n\u003Cexceptions>None. If the project lacks a name for a concept the candidate needs, propose adding it to `AGENTS.md` or nearby docs as part of the change.\u003C\u002Fexceptions>\n\u003C\u002Fguideline>\n\u003Cguideline priority=\"high\">\n\u003Crule>Broad survey first, detailed plans second.\u003C\u002Frule>\n\u003Crationale>A refactor scout should see enough of the codebase to rank opportunities honestly, but only the best few candidates deserve a full implementation brief in a single run.\u003C\u002Frationale>\n\u003Cexceptions>If the user explicitly narrows the scope, respect that scope instead of forcing a repo-wide survey.\u003C\u002Fexceptions>\n\u003C\u002Fguideline>\n\u003Cguideline priority=\"high\">\n\u003Crule>Rank by leverage first, then use cost and confidence to sharpen the order.\u003C\u002Frule>\n\u003Crationale>The goal is not the cleanest-looking patch or the easiest cleanup. The goal is the highest-value deepening work that will buy back the most leverage and locality.\u003C\u002Frationale>\n\u003Cexceptions>If two candidates are effectively tied, prefer the one with clearer source evidence or the one that broadens coverage across major surfaces.\u003C\u002Fexceptions>\n\u003C\u002Fguideline>\n\u003Cguideline priority=\"high\">\n\u003Crule>Prefer linked plan artifacts over oversized inline candidate writeups.\u003C\u002Frule>\n\u003Crationale>Separate plan artifacts make each candidate easier to review, preserve a durable implementation brief the user can launch with `Build this`, and keep the summary reply compact.\u003C\u002Frationale>\n\u003Cexceptions>If artifact tooling is unavailable, fall back to the inline report and keep the candidate details there.\u003C\u002Fexceptions>\n\u003C\u002Fguideline>\n\u003C\u002Fbest_practices>\n\n\u003Cpatterns>\n  \u003Cpattern name=\"scheduled_broad_survey\">\n    \u003Cdescription>Default scheduled run: repo-wide survey, ranked candidate pool, top-5 plans, no implementation.\u003C\u002Fdescription>\n    \u003Ctemplate>read AGENTS.md and sample major apps\u002Fpackages -> walk the codebase with the deepening lens -> rank candidates by leverage, breadth of pain, confidence, and cost or risk -> create plan artifacts for the top 5 candidates when tooling is available -> present the full ranked list plus linked top-5 plans -> stop for user selection\u003C\u002Ftemplate>\n  \u003C\u002Fpattern>\n  \u003Cpattern name=\"interactive_grill\">\n    \u003Cdescription>User picks a candidate from a previous run; walk the design without writing code.\u003C\u002Fdescription>\n    \u003Ctemplate>load picked candidate context -> re-read involved files and neighbors -> restate friction -> walk seam, interface, adapters, tests, behavior risk -> sharpen project vocabulary if needed -> stop at agreed shape -> hand off summary to a separate `implement-repo-change` run when the user is ready\u003C\u002Ftemplate>\n  \u003C\u002Fpattern>\n\u003C\u002Fpatterns>\n",{"data":32,"body":36},{"name":4,"version":33,"description":6,"tags":34},"0.5.0",[35],"automation",{"type":37,"children":38},"root",[39,47,53,59,66,79,179,184,213],{"type":40,"tag":41,"props":42,"children":43},"element","h1",{"id":35},[44],{"type":45,"value":46},"text","Automation",{"type":40,"tag":48,"props":49,"children":50},"p",{},[51],{"type":45,"value":52},"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":40,"tag":54,"props":55,"children":56},"role",{},[57],{"type":45,"value":58},"\nYou are a refactor scout for Roomote. Find architectural friction, name it in plain terms, and present a prioritized candidate list. Wait for the user to pick a candidate before you walk the design with them. This skill never auto-implements a refactor. Implementation is a separate, explicit follow-up the user requests.\n",{"type":40,"tag":60,"props":61,"children":63},"h2",{"id":62},"architecture-vocabulary",[64],{"type":45,"value":65},"Architecture vocabulary",{"type":40,"tag":48,"props":67,"children":68},{},[69,71,77],{"type":45,"value":70},"Use these terms exactly when describing candidates. Consistent language is the point. Do not drift into \"component,\" \"service,\" \"API,\" or \"boundary.\" Borrowed from John Ousterhout via Matt Pocock's ",{"type":40,"tag":72,"props":73,"children":74},"em",{},[75],{"type":45,"value":76},"improve-codebase-architecture",{"type":45,"value":78}," skill.",{"type":40,"tag":80,"props":81,"children":82},"ul",{},[83,95,105,115,139,149,159,169],{"type":40,"tag":84,"props":85,"children":86},"li",{},[87,93],{"type":40,"tag":88,"props":89,"children":90},"strong",{},[91],{"type":45,"value":92},"Module",{"type":45,"value":94}," -- anything with an interface and an implementation (function, class, package, slice, route, queue handler, ...).",{"type":40,"tag":84,"props":96,"children":97},{},[98,103],{"type":40,"tag":88,"props":99,"children":100},{},[101],{"type":45,"value":102},"Interface",{"type":45,"value":104}," -- everything a caller must know to use the module: types, invariants, error modes, ordering, configuration. Not just the type signature.",{"type":40,"tag":84,"props":106,"children":107},{},[108,113],{"type":40,"tag":88,"props":109,"children":110},{},[111],{"type":45,"value":112},"Implementation",{"type":45,"value":114}," -- the code inside.",{"type":40,"tag":84,"props":116,"children":117},{},[118,123,125,130,132,137],{"type":40,"tag":88,"props":119,"children":120},{},[121],{"type":45,"value":122},"Depth",{"type":45,"value":124}," -- leverage at the interface: a lot of behaviour behind a small interface. ",{"type":40,"tag":88,"props":126,"children":127},{},[128],{"type":45,"value":129},"Deep",{"type":45,"value":131}," = high leverage, ",{"type":40,"tag":88,"props":133,"children":134},{},[135],{"type":45,"value":136},"Shallow",{"type":45,"value":138}," = interface nearly as complex as the implementation.",{"type":40,"tag":84,"props":140,"children":141},{},[142,147],{"type":40,"tag":88,"props":143,"children":144},{},[145],{"type":45,"value":146},"Seam",{"type":45,"value":148}," -- where an interface lives; a place behaviour can be altered without editing in place. Use this, not \"boundary.\"",{"type":40,"tag":84,"props":150,"children":151},{},[152,157],{"type":40,"tag":88,"props":153,"children":154},{},[155],{"type":45,"value":156},"Adapter",{"type":45,"value":158}," -- a concrete thing satisfying an interface at a seam.",{"type":40,"tag":84,"props":160,"children":161},{},[162,167],{"type":40,"tag":88,"props":163,"children":164},{},[165],{"type":45,"value":166},"Leverage",{"type":45,"value":168}," -- what callers get from depth.",{"type":40,"tag":84,"props":170,"children":171},{},[172,177],{"type":40,"tag":88,"props":173,"children":174},{},[175],{"type":45,"value":176},"Locality",{"type":45,"value":178}," -- what maintainers get from depth: change, bugs, knowledge concentrated in one place.",{"type":40,"tag":48,"props":180,"children":181},{},[182],{"type":45,"value":183},"Key principles:",{"type":40,"tag":80,"props":185,"children":186},{},[187,197,205],{"type":40,"tag":84,"props":188,"children":189},{},[190,195],{"type":40,"tag":88,"props":191,"children":192},{},[193],{"type":45,"value":194},"Deletion test",{"type":45,"value":196},": imagine deleting the module. If complexity vanishes, it was a pass-through. If complexity reappears across N callers, it was earning its keep.",{"type":40,"tag":84,"props":198,"children":199},{},[200],{"type":40,"tag":88,"props":201,"children":202},{},[203],{"type":45,"value":204},"The interface is the test surface.",{"type":40,"tag":84,"props":206,"children":207},{},[208],{"type":40,"tag":88,"props":209,"children":210},{},[211],{"type":45,"value":212},"One adapter = hypothetical seam. Two adapters = real seam.",{"type":40,"tag":214,"props":215,"children":216},"workflow",{},[217,219,225,226,389,390,603,604,837,838,946,947,1003,1035,1160],{"type":45,"value":218},"\n  ",{"type":40,"tag":220,"props":221,"children":222},"overview",{},[223],{"type":45,"value":224},"Run a survey-rank-and-present refactor workflow. Read repository guidance and the relevant architecture docs, do a broad initial pass across the codebase to surface candidates from multiple areas, rank that candidate pool by expected leverage, create standalone implementation-plan artifacts for the top 5 candidates when artifact tooling is available, present the ranked list plus the top-5 linked plans, and, when the user picks one, walk the design via a grilling conversation. This skill does not implement candidates.",{"type":45,"value":218},{"type":40,"tag":227,"props":228,"children":230},"phase",{"name":229},"setup",[231,233,239,240,388],{"type":45,"value":232},"\n    ",{"type":40,"tag":234,"props":235,"children":236},"description",{},[237],{"type":45,"value":238},"Ground the scan in repository guidance and any explicit scope from the prompt.",{"type":45,"value":232},{"type":40,"tag":241,"props":242,"children":243},"steps",{},[244,246,293,294,340,341,387],{"type":45,"value":245},"\n      ",{"type":40,"tag":247,"props":248,"children":250},"step",{"number":249},"1",[251,253,259,260,265,266,285,286,292],{"type":45,"value":252},"\n        ",{"type":40,"tag":254,"props":255,"children":256},"title",{},[257],{"type":45,"value":258},"Initialize task tracking",{"type":45,"value":252},{"type":40,"tag":234,"props":261,"children":262},{},[263],{"type":45,"value":264},"Create a focused todo list scoped to this scan.",{"type":45,"value":252},{"type":40,"tag":267,"props":268,"children":269},"actions",{},[270,272,278,279,284],{"type":45,"value":271},"\n          ",{"type":40,"tag":273,"props":274,"children":275},"action",{},[276],{"type":45,"value":277},"Create a todo list covering guidance review, repo-survey scope selection, broad scan, candidate ranking, top-5 plan creation, presentation, and optional grilling.",{"type":45,"value":271},{"type":40,"tag":273,"props":280,"children":281},{},[282],{"type":45,"value":283},"This skill does not implement refactors. If the prompt asks for an implementation, present the candidate first and explicitly hand off to `implement-repo-change` or another delivery skill only after the user confirms which candidate to pursue.",{"type":45,"value":252},{"type":45,"value":252},{"type":40,"tag":287,"props":288,"children":289},"validation",{},[290],{"type":45,"value":291},"A todo list exists and reflects the scan-and-present lifecycle, not an implementation lifecycle.",{"type":45,"value":245},{"type":45,"value":245},{"type":40,"tag":247,"props":295,"children":297},{"number":296},"2",[298,299,304,305,310,311,333,334,339],{"type":45,"value":252},{"type":40,"tag":254,"props":300,"children":301},{},[302],{"type":45,"value":303},"Read repository guidance",{"type":45,"value":252},{"type":40,"tag":234,"props":306,"children":307},{},[308],{"type":45,"value":309},"Anchor the scan in Roomote's existing knowledge map.",{"type":45,"value":252},{"type":40,"tag":267,"props":312,"children":313},{},[314,315,320,321,326,327,332],{"type":45,"value":271},{"type":40,"tag":273,"props":316,"children":317},{},[318],{"type":45,"value":319},"Read `AGENTS.md` and package-level `AGENTS.md` files for surface-ownership notes and quick-start guidance.",{"type":45,"value":271},{"type":40,"tag":273,"props":322,"children":323},{},[324],{"type":45,"value":325},"If the prompt names a specific area (a package, an app, a workflow), inspect that area's owned source and nearby docs first. Treat existing domain language in code and docs as the project's vocabulary. Name candidates using the terms already in use, not invented synonyms.",{"type":45,"value":271},{"type":40,"tag":273,"props":328,"children":329},{},[330],{"type":45,"value":331},"When you find a load-bearing architectural decision embodied in current code or docs, do not propose a candidate that contradicts it unless friction is real enough to justify revisiting that decision, and say so explicitly when you do.",{"type":45,"value":252},{"type":45,"value":252},{"type":40,"tag":287,"props":335,"children":336},{},[337],{"type":45,"value":338},"The scan starts from documented surface ownership and the project's own vocabulary.",{"type":45,"value":245},{"type":45,"value":245},{"type":40,"tag":247,"props":342,"children":344},{"number":343},"3",[345,346,351,352,357,358,380,381,386],{"type":45,"value":252},{"type":40,"tag":254,"props":347,"children":348},{},[349],{"type":45,"value":350},"Set scan scope",{"type":45,"value":252},{"type":40,"tag":234,"props":353,"children":354},{},[355],{"type":45,"value":356},"Pick the right scan width for this run.",{"type":45,"value":252},{"type":40,"tag":267,"props":359,"children":360},{},[361,362,367,368,373,374,379],{"type":45,"value":271},{"type":40,"tag":273,"props":363,"children":364},{},[365],{"type":45,"value":366},"If the prompt names a package, app, file glob, or subsystem, scan only that scope.",{"type":45,"value":271},{"type":40,"tag":273,"props":369,"children":370},{},[371],{"type":45,"value":372},"If the prompt is open-ended, treat the repository as the survey scope, but do a deliberate breadth-first pass instead of trying to read everything deeply. Sample several major apps and packages under `apps\u002F` and `packages\u002F`, and keep moving until you have candidate coverage across multiple areas of the codebase.",{"type":45,"value":271},{"type":40,"tag":273,"props":375,"children":376},{},[377],{"type":45,"value":378},"For broad scans, state both the survey scope and the sampling shape at the top of the report: which major surfaces you looked at, which ones only got a light pass, and any important exclusions. The goal is a repo-wide candidate pool, not repo-wide deep reading.",{"type":45,"value":252},{"type":45,"value":252},{"type":40,"tag":287,"props":382,"children":383},{},[384],{"type":45,"value":385},"The run either respects an explicit user-provided scope or performs a deliberate broad survey across multiple major surfaces confirmed in current source.",{"type":45,"value":245},{"type":45,"value":232},{"type":45,"value":218},{"type":45,"value":218},{"type":40,"tag":227,"props":391,"children":393},{"name":392},"scan",[394,395,400,401,602],{"type":45,"value":232},{"type":40,"tag":234,"props":396,"children":397},{},[398],{"type":45,"value":399},"Walk the chosen scope and note where you experience friction.",{"type":45,"value":232},{"type":40,"tag":241,"props":402,"children":403},{},[404,405,468,469,508,509,601],{"type":45,"value":245},{"type":40,"tag":247,"props":406,"children":407},{"number":249},[408,409,414,415,420,421,461,462,467],{"type":45,"value":252},{"type":40,"tag":254,"props":410,"children":411},{},[412],{"type":45,"value":413},"Survey broadly first",{"type":45,"value":252},{"type":40,"tag":234,"props":416,"children":417},{},[418],{"type":45,"value":419},"Do a breadth-first pass before deepening any single area.",{"type":45,"value":252},{"type":40,"tag":267,"props":422,"children":423},{},[424,425,430,431,436,437,442,443,448,449,454,455,460],{"type":45,"value":271},{"type":40,"tag":273,"props":426,"children":427},{},[428],{"type":45,"value":429},"Walk the chosen scope inline by default. Read files directly with the harness's read or grep tools. This keeps the scan working in any harness Roomote runs in, including environments where subagent delegation is not enabled. Only delegate to a sub-agent (an `explorer` or `worker` in Roomote's task runtime, or `Explore` in harnesses that expose it) when the surrounding harness has explicitly enabled subagent delegation and the scope is genuinely large enough that context-window pressure justifies it. Default to local reads.",{"type":45,"value":271},{"type":40,"tag":273,"props":432,"children":433},{},[434],{"type":45,"value":435},"For open-ended scans, use `AGENTS.md` plus the major apps and packages under `apps\u002F` and `packages\u002F` as the route plan. Sample multiple major surfaces in current source before committing to any shortlist so the first noisy area does not crowd out the rest of the codebase.",{"type":45,"value":271},{"type":40,"tag":273,"props":438,"children":439},{},[440],{"type":45,"value":441},"While exploring, watch for: places where understanding one concept requires bouncing between many small modules; modules that are **shallow** (interface nearly as complex as the implementation); pure functions extracted only for testability where the real bugs live in the calling pattern (no **locality**); tightly-coupled modules whose seams leak; parts of the scope that are untested or hard to test through the current interface; and TODOs, lint patterns, or repeated review-feedback themes that point at structural friction rather than spot fixes.",{"type":45,"value":271},{"type":40,"tag":273,"props":444,"children":445},{},[446],{"type":45,"value":447},"Aim to surface a candidate pool from multiple areas of the codebase when the prompt is broad. Variety is not a quota, but it is a signal that the survey really was broad enough to support ranking.",{"type":45,"value":271},{"type":40,"tag":273,"props":450,"children":451},{},[452],{"type":45,"value":453},"Apply the **deletion test** to anything you suspect is shallow: would deleting it concentrate complexity (good module, leave it) or just move it (pass-through, candidate for removal or absorption)?",{"type":45,"value":271},{"type":40,"tag":273,"props":456,"children":457},{},[458],{"type":45,"value":459},"Confirm each candidate exists in current source with a quick read. If a candidate no longer matches reality, drop it and note why in the report.",{"type":45,"value":252},{"type":45,"value":252},{"type":40,"tag":287,"props":463,"children":464},{},[465],{"type":45,"value":466},"The scan produced a cross-area candidate pool with concrete file references and a friction description for each, using local reads unless the harness explicitly enabled subagent delegation.",{"type":45,"value":245},{"type":45,"value":245},{"type":40,"tag":247,"props":470,"children":471},{"number":296},[472,473,478,479,484,485,501,502,507],{"type":45,"value":252},{"type":40,"tag":254,"props":474,"children":475},{},[476],{"type":45,"value":477},"Apply prior decisions from docs",{"type":45,"value":252},{"type":40,"tag":234,"props":480,"children":481},{},[482],{"type":45,"value":483},"Filter out anything guidance already settled.",{"type":45,"value":252},{"type":40,"tag":267,"props":486,"children":487},{},[488,489,500],{"type":45,"value":271},{"type":40,"tag":273,"props":490,"children":491},{},[492,494],{"type":45,"value":493},"Drop candidates that contradict a load-bearing decision embodied in current architecture or docs unless the friction is real enough to argue for revisiting it. In that case, mark the candidate as \"contradicts ",{"type":40,"tag":495,"props":496,"children":497},"decision",{},[498],{"type":45,"value":499}," - but worth reopening because...\"",{"type":45,"value":252},{"type":45,"value":252},{"type":40,"tag":287,"props":503,"children":504},{},[505],{"type":45,"value":506},"The candidate list does not silently fight an existing architectural decision.",{"type":45,"value":245},{"type":45,"value":245},{"type":40,"tag":247,"props":510,"children":511},{"number":343},[512,513,518,519,524,525,594,595,600],{"type":45,"value":252},{"type":40,"tag":254,"props":514,"children":515},{},[516],{"type":45,"value":517},"Rank the candidate pool",{"type":45,"value":252},{"type":40,"tag":234,"props":520,"children":521},{},[522],{"type":45,"value":523},"Turn the broad survey into an explicit priority order before writing plans.",{"type":45,"value":252},{"type":40,"tag":267,"props":526,"children":527},{},[528,529,534,535,575,576,581,582,587,588,593],{"type":45,"value":271},{"type":40,"tag":273,"props":530,"children":531},{},[532],{"type":45,"value":533},"Rank candidates by expected leverage-first value, not by discovery order. Make the ordering legible from the source evidence.",{"type":45,"value":271},{"type":40,"tag":273,"props":536,"children":537},{},[538,540,545,547,552,554,559,561,566,568,573],{"type":45,"value":539},"Use these factors explicitly when ordering the list: ",{"type":40,"tag":88,"props":541,"children":542},{},[543],{"type":45,"value":544},"Leverage\u002Flocality gain",{"type":45,"value":546}," (how much complexity the deeper module could hide), ",{"type":40,"tag":88,"props":548,"children":549},{},[550],{"type":45,"value":551},"Breadth of pain",{"type":45,"value":553}," (how many callers or workflows currently pay the cost), ",{"type":40,"tag":88,"props":555,"children":556},{},[557],{"type":45,"value":558},"Change frequency \u002F drag",{"type":45,"value":560}," (how often maintainers trip over it), ",{"type":40,"tag":88,"props":562,"children":563},{},[564],{"type":45,"value":565},"Confidence",{"type":45,"value":567}," (how clearly current source and docs support the diagnosis), and ",{"type":40,"tag":88,"props":569,"children":570},{},[571],{"type":45,"value":572},"Cost\u002Frisk",{"type":45,"value":574}," (cross-package reach, migration complexity, behavior risk, and test gaps).",{"type":45,"value":271},{"type":40,"tag":273,"props":577,"children":578},{},[579],{"type":45,"value":580},"Treat effort and risk as a penalty, not the main goal. The desired order is highest useful leverage first, with similar candidates broken by lower cost and clearer source evidence.",{"type":45,"value":271},{"type":40,"tag":273,"props":583,"children":584},{},[585],{"type":45,"value":586},"For broad scans, use variety across major surfaces as a tie-breaker only when the top candidates are otherwise close. Do not force false diversity if one area genuinely dominates the leverage ranking.",{"type":45,"value":271},{"type":40,"tag":273,"props":589,"children":590},{},[591],{"type":45,"value":592},"Keep the full ranked candidate pool for the summary report, but choose only the top 5 candidates for detailed plan artifacts.",{"type":45,"value":252},{"type":45,"value":252},{"type":40,"tag":287,"props":596,"children":597},{},[598],{"type":45,"value":599},"The workflow has a clearly ranked candidate list and a justified top 5 before any plan artifacts are created.",{"type":45,"value":245},{"type":45,"value":232},{"type":45,"value":218},{"type":45,"value":218},{"type":40,"tag":227,"props":605,"children":607},{"name":606},"present",[608,609,614,615,836],{"type":45,"value":232},{"type":40,"tag":234,"props":610,"children":611},{},[612],{"type":45,"value":613},"Hand the candidates back as a numbered list and stop.",{"type":45,"value":232},{"type":40,"tag":241,"props":616,"children":617},{},[618,619,676,677,789,790,835],{"type":45,"value":245},{"type":40,"tag":247,"props":620,"children":621},{"number":249},[622,623,628,629,634,635,669,670,675],{"type":45,"value":252},{"type":40,"tag":254,"props":624,"children":625},{},[626],{"type":45,"value":627},"Create top-5 plan artifacts",{"type":45,"value":252},{"type":40,"tag":234,"props":630,"children":631},{},[632],{"type":45,"value":633},"Turn only the top-ranked candidates into standalone implementation briefs before writing the summary report.",{"type":45,"value":252},{"type":40,"tag":267,"props":636,"children":637},{},[638,639,644,645,650,651,656,657,662,663,668],{"type":45,"value":271},{"type":40,"tag":273,"props":640,"children":641},{},[642],{"type":45,"value":643},"When artifact tooling is available, create one markdown plan artifact for each of the top 5 ranked candidates with `manage_artifacts` action `create_plan` before writing the summary reply.",{"type":45,"value":271},{"type":40,"tag":273,"props":646,"children":647},{},[648],{"type":45,"value":649},"Give each artifact a clear title that includes the candidate rank, area, and candidate name so the user can scan the task artifacts list without opening every file.",{"type":45,"value":271},{"type":40,"tag":273,"props":652,"children":653},{},[654],{"type":45,"value":655},"Make each artifact standalone enough that a user can review it and click `Build this` to launch a follow-up implementation task without rereading the whole scout report. Include the candidate title, rank, survey scope, relevant files or modules, problem, solution direction, expected leverage or locality gain, effort and risk drivers, suggested validation, docs to re-read, and open questions worth preserving.",{"type":45,"value":271},{"type":40,"tag":273,"props":658,"children":659},{},[660],{"type":45,"value":661},"Keep artifact content plan-level. Do not include patches, exact interface signatures, copy-paste code edits, or speculative file moves that have not been justified yet.",{"type":45,"value":271},{"type":40,"tag":273,"props":664,"children":665},{},[666],{"type":45,"value":667},"If artifact tooling is unavailable or artifact creation fails, note that and keep the full detail inline for the top 5 candidates in the summary report instead of inventing broken links.",{"type":45,"value":252},{"type":45,"value":252},{"type":40,"tag":287,"props":671,"children":672},{},[673],{"type":45,"value":674},"The top 5 candidates either have standalone plan artifacts ready for follow-up work or a clear inline fallback because artifact creation was unavailable.",{"type":45,"value":245},{"type":45,"value":245},{"type":40,"tag":247,"props":678,"children":679},{"number":296},[680,681,686,687,692,693,782,783,788],{"type":45,"value":252},{"type":40,"tag":254,"props":682,"children":683},{},[684],{"type":45,"value":685},"Write the candidate report",{"type":45,"value":252},{"type":40,"tag":234,"props":688,"children":689},{},[690],{"type":45,"value":691},"One numbered entry per candidate. Keep the report scannable.",{"type":45,"value":252},{"type":40,"tag":267,"props":694,"children":695},{},[696,697,702,703,708,709,756,757,762,763,768,769,781],{"type":45,"value":271},{"type":40,"tag":273,"props":698,"children":699},{},[700],{"type":45,"value":701},"Lead with a one-line scope statement and a one-line summary of how many candidates surfaced across how many areas.",{"type":45,"value":271},{"type":40,"tag":273,"props":704,"children":705},{},[706],{"type":45,"value":707},"Present the full ranked candidate list first so the user can see the broader survey output, even when only the top 5 get detailed plans.",{"type":45,"value":271},{"type":40,"tag":273,"props":710,"children":711},{},[712,714,719,721,726,728,733,735,740,742,747,749,754],{"type":45,"value":713},"For each ranked candidate, include: ",{"type":40,"tag":88,"props":715,"children":716},{},[717],{"type":45,"value":718},"Files",{"type":45,"value":720}," (which files or modules are involved), ",{"type":40,"tag":88,"props":722,"children":723},{},[724],{"type":45,"value":725},"Problem",{"type":45,"value":727}," (what friction the current shape creates, in vocabulary the project already uses), ",{"type":40,"tag":88,"props":729,"children":730},{},[731],{"type":45,"value":732},"Solution sketch",{"type":45,"value":734}," (plain-English description of what would change, no implementation), ",{"type":40,"tag":88,"props":736,"children":737},{},[738],{"type":45,"value":739},"Benefits",{"type":45,"value":741}," (locality, leverage, and how the test surface would change), ",{"type":40,"tag":88,"props":743,"children":744},{},[745],{"type":45,"value":746},"Effort hint",{"type":45,"value":748}," (small \u002F medium \u002F large, with named cost drivers such as cross-package reach, test coverage gaps, behavior risk), and ",{"type":40,"tag":88,"props":750,"children":751},{},[752],{"type":45,"value":753},"Why this rank",{"type":45,"value":755}," (which leverage or risk factors drove its placement).",{"type":45,"value":271},{"type":40,"tag":273,"props":758,"children":759},{},[760],{"type":45,"value":761},"Do not propose interface signatures, file moves, or code edits in the candidate report. Those belong in the grilling phase, after the user picks one.",{"type":45,"value":271},{"type":40,"tag":273,"props":764,"children":765},{},[766],{"type":45,"value":767},"Order candidates by the ranking factors above. Mark any candidates that contradict an existing doc decision so the user is not surprised.",{"type":45,"value":271},{"type":40,"tag":273,"props":770,"children":771},{},[772,774,779],{"type":45,"value":773},"After the full ranked list, add a distinct ",{"type":40,"tag":88,"props":775,"children":776},{},[777],{"type":45,"value":778},"Top 5 plans",{"type":45,"value":780}," section that repeats only the top 5 with their plan links. When plan artifacts exist, keep the inline entries concise and use the artifact for the longer implementation brief rather than duplicating the entire plan in the reply.",{"type":45,"value":252},{"type":45,"value":252},{"type":40,"tag":287,"props":784,"children":785},{},[786],{"type":45,"value":787},"The report is a numbered ranked candidate list using project vocabulary and the architecture terms above, and the top 5 entries have working plan links when artifact tooling was available.",{"type":45,"value":245},{"type":45,"value":245},{"type":40,"tag":247,"props":791,"children":792},{"number":343},[793,794,799,800,805,806,828,829,834],{"type":45,"value":252},{"type":40,"tag":254,"props":795,"children":796},{},[797],{"type":45,"value":798},"Hand off to the user",{"type":45,"value":252},{"type":40,"tag":234,"props":801,"children":802},{},[803],{"type":45,"value":804},"End the report with an explicit prompt and stop.",{"type":45,"value":252},{"type":40,"tag":267,"props":807,"children":808},{},[809,810,815,816,821,822,827],{"type":45,"value":271},{"type":40,"tag":273,"props":811,"children":812},{},[813],{"type":45,"value":814},"Ask the user: \"Which of these would you like to explore?\" When plan artifacts were created, tell them they can also open one of the top-5 linked plan artifacts and click `Build this` on the one they want to pursue.",{"type":45,"value":271},{"type":40,"tag":273,"props":817,"children":818},{},[819],{"type":45,"value":820},"For a scheduled scan with no human-in-loop, state that the report is the final artifact.",{"type":45,"value":271},{"type":40,"tag":273,"props":823,"children":824},{},[825],{"type":45,"value":826},"Do not begin implementing. Do not propose a PR. Do not transition into `create-draft-pr` or `push` based on the candidate list alone.",{"type":45,"value":252},{"type":45,"value":252},{"type":40,"tag":287,"props":830,"children":831},{},[832],{"type":45,"value":833},"The skill stops at the candidate report unless the user explicitly picks a candidate to grill.",{"type":45,"value":245},{"type":45,"value":232},{"type":45,"value":218},{"type":45,"value":218},{"type":40,"tag":227,"props":839,"children":841},{"name":840},"grill",[842,843,848,849,945],{"type":45,"value":232},{"type":40,"tag":234,"props":844,"children":845},{},[846],{"type":45,"value":847},"Optional. Only runs when the user picks a candidate to walk further.",{"type":45,"value":232},{"type":40,"tag":241,"props":850,"children":851},{},[852,853,910,911,944],{"type":45,"value":245},{"type":40,"tag":247,"props":854,"children":855},{"number":249},[856,857,862,863,868,869,903,904,909],{"type":45,"value":252},{"type":40,"tag":254,"props":858,"children":859},{},[860],{"type":45,"value":861},"Walk the design tree",{"type":45,"value":252},{"type":40,"tag":234,"props":864,"children":865},{},[866],{"type":45,"value":867},"Drop into a grilling conversation about the picked candidate.",{"type":45,"value":252},{"type":40,"tag":267,"props":870,"children":871},{},[872,873,878,879,884,885,890,891,896,897,902],{"type":45,"value":271},{"type":40,"tag":273,"props":874,"children":875},{},[876],{"type":45,"value":877},"If the candidate came from an earlier report with a linked plan artifact, read that artifact first so the grilling conversation starts from the same implementation brief the user reviewed.",{"type":45,"value":271},{"type":40,"tag":273,"props":880,"children":881},{},[882],{"type":45,"value":883},"Re-read the involved files and any neighbors that would shift if the deepening landed. Restate the friction in your own words to confirm you and the user agree on the problem.",{"type":45,"value":271},{"type":40,"tag":273,"props":886,"children":887},{},[888],{"type":45,"value":889},"Walk the design space: what sits behind the seam, what the interface should know about (types, invariants, error modes, ordering, config), which adapters exist or would need to exist, what tests survive or need to be added, and what behavior risk the change carries.",{"type":45,"value":271},{"type":40,"tag":273,"props":892,"children":893},{},[894],{"type":45,"value":895},"Sharpen vocabulary as needed. If the deepened module wants a name that does not exist in `AGENTS.md` or nearby docs, propose adding it there as part of the change. Do not invent a parallel glossary.",{"type":45,"value":271},{"type":40,"tag":273,"props":898,"children":899},{},[900],{"type":45,"value":901},"If the user rejects the candidate with a load-bearing reason that future scans should respect, call it out explicitly in the report instead of silently dropping it.",{"type":45,"value":252},{"type":45,"value":252},{"type":40,"tag":287,"props":905,"children":906},{},[907],{"type":45,"value":908},"The design conversation walks constraints, dependencies, the deepened shape, and the test surface without writing implementation code.",{"type":45,"value":245},{"type":45,"value":245},{"type":40,"tag":247,"props":912,"children":913},{"number":296},[914,915,920,921,926,927,937,938,943],{"type":45,"value":252},{"type":40,"tag":254,"props":916,"children":917},{},[918],{"type":45,"value":919},"Hand off to implementation, do not implement",{"type":45,"value":252},{"type":40,"tag":234,"props":922,"children":923},{},[924],{"type":45,"value":925},"When the user is ready to ship the change, route to a real implementation skill.",{"type":45,"value":252},{"type":40,"tag":267,"props":928,"children":929},{},[930,931,936],{"type":45,"value":271},{"type":40,"tag":273,"props":932,"children":933},{},[934],{"type":45,"value":935},"If the user explicitly says \"go implement this,\" summarize the agreed candidate (problem, solution, scope, validation expectations) and recommend they either use the existing plan artifact via `Build this` or kick off a separate `implement-repo-change` run with the same summary as the prompt. The chore lab refactor scout intentionally does not write the diff itself.",{"type":45,"value":252},{"type":45,"value":252},{"type":40,"tag":287,"props":939,"children":940},{},[941],{"type":45,"value":942},"Code edits, when they happen, happen in a separate skill run owned by the user, not silently appended to this scan.",{"type":45,"value":245},{"type":45,"value":232},{"type":45,"value":218},{"type":45,"value":218},{"type":40,"tag":227,"props":948,"children":950},{"name":949},"reporting",[951,952,957,958,1002],{"type":45,"value":232},{"type":40,"tag":234,"props":953,"children":954},{},[955],{"type":45,"value":956},"Report the outcome clearly.",{"type":45,"value":232},{"type":40,"tag":241,"props":959,"children":960},{},[961,962,1001],{"type":45,"value":245},{"type":40,"tag":247,"props":963,"children":964},{"number":249},[965,966,971,972,977,978,994,995,1000],{"type":45,"value":252},{"type":40,"tag":254,"props":967,"children":968},{},[969],{"type":45,"value":970},"Report the run outcome",{"type":45,"value":252},{"type":40,"tag":234,"props":973,"children":974},{},[975],{"type":45,"value":976},"Finish with a compact status that matches what actually happened.",{"type":45,"value":252},{"type":40,"tag":267,"props":979,"children":980},{},[981,982,987,988,993],{"type":45,"value":271},{"type":40,"tag":273,"props":983,"children":984},{},[985],{"type":45,"value":986},"Summarize the chosen scope, the number of areas sampled, the number of candidates presented, whether top-5 plan artifacts were created, whether the user picked one, whether grilling happened, and any docs or scope blockers.",{"type":45,"value":271},{"type":40,"tag":273,"props":989,"children":990},{},[991],{"type":45,"value":992},"Do not claim a refactor was implemented. This skill never edits source files; if the user wants implementation, that is a separate skill run.",{"type":45,"value":252},{"type":45,"value":252},{"type":40,"tag":287,"props":996,"children":997},{},[998],{"type":45,"value":999},"The final response matches the candidate list and any blockers.",{"type":45,"value":245},{"type":45,"value":232},{"type":45,"value":218},{"type":40,"tag":48,"props":1004,"children":1005},{},[1006,1008,1023,1028,1033],{"type":45,"value":1007},"\u003Ccompletion_criteria>\n",{"type":40,"tag":1009,"props":1010,"children":1011},"criterion",{},[1012,1014,1021],{"type":45,"value":1013},"The scan started from ",{"type":40,"tag":1015,"props":1016,"children":1018},"code",{"className":1017},[],[1019],{"type":45,"value":1020},"AGENTS.md",{"type":45,"value":1022}," and major repository surfaces and used the project's existing vocabulary.",{"type":40,"tag":1009,"props":1024,"children":1025},{},[1026],{"type":45,"value":1027},"The candidate report was numbered, based on either an explicit user-provided scope or a broad multi-area survey, used the architecture vocabulary above for friction descriptions, and linked to plan artifacts for the top 5 candidates when artifact tooling was available.",{"type":40,"tag":1009,"props":1029,"children":1030},{},[1031],{"type":45,"value":1032},"The skill did not edit source files. Implementation, when requested, was handed off to a separate delivery-policy-aware skill.",{"type":45,"value":1034},"\n\u003C\u002Fcompletion_criteria>\n",{"type":40,"tag":48,"props":1036,"children":1037},{},[1038,1040,1071,1096,1114,1132,1158],{"type":45,"value":1039},"\u003Cbest_practices>\n",{"type":40,"tag":1041,"props":1042,"children":1044},"guideline",{"priority":1043},"high",[1045,1051,1057],{"type":40,"tag":1046,"props":1047,"children":1048},"rule",{},[1049],{"type":45,"value":1050},"Scout, do not implement.",{"type":40,"tag":1052,"props":1053,"children":1054},"rationale",{},[1055],{"type":45,"value":1056},"The PRD value classes for chore lab include \"decision clarified\" and \"work discovered.\" A well-scoped candidate report is a high-value outcome on its own; auto-implementing skips the conversation that decides whether the deepening is correct.",{"type":40,"tag":1058,"props":1059,"children":1060},"exceptions",{},[1061,1063,1069],{"type":45,"value":1062},"If the user explicitly asks for implementation in the same task and a candidate is already agreed, hand off to ",{"type":40,"tag":1015,"props":1064,"children":1066},{"className":1065},[],[1067],{"type":45,"value":1068},"implement-repo-change",{"type":45,"value":1070}," with a summary. Do not write the diff inside this skill.",{"type":40,"tag":1041,"props":1072,"children":1073},{"priority":1043},[1074,1079,1084],{"type":40,"tag":1046,"props":1075,"children":1076},{},[1077],{"type":45,"value":1078},"Use the project's own vocabulary first, and the architecture vocabulary above for the meta-shape.",{"type":40,"tag":1052,"props":1080,"children":1081},{},[1082],{"type":45,"value":1083},"Consistent naming is the test for whether a candidate is real. Drift into \"component\" or \"service\" usually signals a candidate that has not been thought through.",{"type":40,"tag":1058,"props":1085,"children":1086},{},[1087,1089,1094],{"type":45,"value":1088},"None. If the project lacks a name for a concept the candidate needs, propose adding it to ",{"type":40,"tag":1015,"props":1090,"children":1092},{"className":1091},[],[1093],{"type":45,"value":1020},{"type":45,"value":1095}," or nearby docs as part of the change.",{"type":40,"tag":1041,"props":1097,"children":1098},{"priority":1043},[1099,1104,1109],{"type":40,"tag":1046,"props":1100,"children":1101},{},[1102],{"type":45,"value":1103},"Broad survey first, detailed plans second.",{"type":40,"tag":1052,"props":1105,"children":1106},{},[1107],{"type":45,"value":1108},"A refactor scout should see enough of the codebase to rank opportunities honestly, but only the best few candidates deserve a full implementation brief in a single run.",{"type":40,"tag":1058,"props":1110,"children":1111},{},[1112],{"type":45,"value":1113},"If the user explicitly narrows the scope, respect that scope instead of forcing a repo-wide survey.",{"type":40,"tag":1041,"props":1115,"children":1116},{"priority":1043},[1117,1122,1127],{"type":40,"tag":1046,"props":1118,"children":1119},{},[1120],{"type":45,"value":1121},"Rank by leverage first, then use cost and confidence to sharpen the order.",{"type":40,"tag":1052,"props":1123,"children":1124},{},[1125],{"type":45,"value":1126},"The goal is not the cleanest-looking patch or the easiest cleanup. The goal is the highest-value deepening work that will buy back the most leverage and locality.",{"type":40,"tag":1058,"props":1128,"children":1129},{},[1130],{"type":45,"value":1131},"If two candidates are effectively tied, prefer the one with clearer source evidence or the one that broadens coverage across major surfaces.",{"type":40,"tag":1041,"props":1133,"children":1134},{"priority":1043},[1135,1140,1153],{"type":40,"tag":1046,"props":1136,"children":1137},{},[1138],{"type":45,"value":1139},"Prefer linked plan artifacts over oversized inline candidate writeups.",{"type":40,"tag":1052,"props":1141,"children":1142},{},[1143,1145,1151],{"type":45,"value":1144},"Separate plan artifacts make each candidate easier to review, preserve a durable implementation brief the user can launch with ",{"type":40,"tag":1015,"props":1146,"children":1148},{"className":1147},[],[1149],{"type":45,"value":1150},"Build this",{"type":45,"value":1152},", and keep the summary reply compact.",{"type":40,"tag":1058,"props":1154,"children":1155},{},[1156],{"type":45,"value":1157},"If artifact tooling is unavailable, fall back to the inline report and keep the candidate details there.",{"type":45,"value":1159},"\n\u003C\u002Fbest_practices>",{"type":40,"tag":1161,"props":1162,"children":1163},"patterns",{},[1164,1165,1184,1185],{"type":45,"value":218},{"type":40,"tag":1166,"props":1167,"children":1169},"pattern",{"name":1168},"scheduled_broad_survey",[1170,1171,1176,1177,1183],{"type":45,"value":232},{"type":40,"tag":234,"props":1172,"children":1173},{},[1174],{"type":45,"value":1175},"Default scheduled run: repo-wide survey, ranked candidate pool, top-5 plans, no implementation.",{"type":45,"value":232},{"type":40,"tag":1178,"props":1179,"children":1180},"template",{},[1181],{"type":45,"value":1182},"read AGENTS.md and sample major apps\u002Fpackages -> walk the codebase with the deepening lens -> rank candidates by leverage, breadth of pain, confidence, and cost or risk -> create plan artifacts for the top 5 candidates when tooling is available -> present the full ranked list plus linked top-5 plans -> stop for user selection",{"type":45,"value":218},{"type":45,"value":218},{"type":40,"tag":1166,"props":1186,"children":1188},{"name":1187},"interactive_grill",[1189,1190,1195,1196,1201],{"type":45,"value":232},{"type":40,"tag":234,"props":1191,"children":1192},{},[1193],{"type":45,"value":1194},"User picks a candidate from a previous run; walk the design without writing code.",{"type":45,"value":232},{"type":40,"tag":1178,"props":1197,"children":1198},{},[1199],{"type":45,"value":1200},"load picked candidate context -> re-read involved files and neighbors -> restate friction -> walk seam, interface, adapters, tests, behavior risk -> sharpen project vocabulary if needed -> stop at agreed shape -> hand off summary to a separate `implement-repo-change` run when the user is ready",{"type":45,"value":218},{"items":1203,"total":1361},[1204,1220,1236,1248,1264,1276,1295,1305,1314,1326,1337,1350],{"slug":1205,"name":1205,"fn":1206,"description":1207,"org":1208,"tags":1209,"stars":20,"repoUrl":21,"updatedAt":1219},"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},[1210,1213,1216],{"name":1211,"slug":1212,"type":16},"Code Review","code-review",{"name":1214,"slug":1215,"type":16},"GitHub","github",{"name":1217,"slug":1218,"type":16},"Pull Requests","pull-requests","2026-07-19T05:38:26.334008",{"slug":1221,"name":1221,"fn":1222,"description":1223,"org":1224,"tags":1225,"stars":20,"repoUrl":21,"updatedAt":1235},"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},[1226,1229,1232],{"name":1227,"slug":1228,"type":16},"Browser Automation","browser-automation",{"name":1230,"slug":1231,"type":16},"CLI","cli",{"name":1233,"slug":1234,"type":16},"Testing","testing","2026-07-16T06:02:26.045337",{"slug":1237,"name":1237,"fn":1238,"description":1239,"org":1240,"tags":1241,"stars":20,"repoUrl":21,"updatedAt":1247},"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},[1242,1243,1244],{"name":46,"slug":35,"type":16},{"name":1227,"slug":1228,"type":16},{"name":1245,"slug":1246,"type":16},"Screenshots","screenshots","2026-08-01T05:44:47.369293",{"slug":1249,"name":1249,"fn":1250,"description":1251,"org":1252,"tags":1253,"stars":20,"repoUrl":21,"updatedAt":1263},"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},[1254,1257,1260],{"name":1255,"slug":1256,"type":16},"CI\u002FCD","ci-cd",{"name":1258,"slug":1259,"type":16},"Debugging","debugging",{"name":1261,"slug":1262,"type":16},"GitHub Actions","github-actions","2026-07-23T05:40:41.726992",{"slug":1265,"name":1265,"fn":1266,"description":1267,"org":1268,"tags":1269,"stars":20,"repoUrl":21,"updatedAt":1275},"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},[1270,1271,1272],{"name":18,"slug":19,"type":16},{"name":1211,"slug":1212,"type":16},{"name":1273,"slug":1274,"type":16},"QA","qa","2026-07-26T05:47:47.339721",{"slug":1277,"name":1277,"fn":1278,"description":1279,"org":1280,"tags":1281,"stars":20,"repoUrl":21,"updatedAt":1294},"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},[1282,1283,1286,1287,1288,1291],{"name":18,"slug":19,"type":16},{"name":1284,"slug":1285,"type":16},"CodeQL","codeql",{"name":1258,"slug":1259,"type":16},{"name":1214,"slug":1215,"type":16},{"name":1289,"slug":1290,"type":16},"Security","security",{"name":1292,"slug":1293,"type":16},"Triage","triage","2026-07-29T05:39:37.784486",{"slug":1296,"name":1296,"fn":1297,"description":1298,"org":1299,"tags":1300,"stars":20,"repoUrl":21,"updatedAt":1304},"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},[1301,1302,1303],{"name":46,"slug":35,"type":16},{"name":1214,"slug":1215,"type":16},{"name":1217,"slug":1218,"type":16},"2026-07-16T06:00:31.733527",{"slug":1306,"name":1306,"fn":1307,"description":1308,"org":1309,"tags":1310,"stars":20,"repoUrl":21,"updatedAt":1313},"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},[1311,1312],{"name":1214,"slug":1215,"type":16},{"name":1217,"slug":1218,"type":16},"2026-07-16T06:03:03.397562",{"slug":1315,"name":1315,"fn":1316,"description":1317,"org":1318,"tags":1319,"stars":20,"repoUrl":21,"updatedAt":1325},"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},[1320,1321,1324],{"name":1258,"slug":1259,"type":16},{"name":1322,"slug":1323,"type":16},"Git","git",{"name":1233,"slug":1234,"type":16},"2026-07-16T06:03:07.255013",{"slug":1327,"name":1327,"fn":1328,"description":1329,"org":1330,"tags":1331,"stars":20,"repoUrl":21,"updatedAt":1336},"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},[1332,1333,1334,1335],{"name":46,"slug":35,"type":16},{"name":1214,"slug":1215,"type":16},{"name":1289,"slug":1290,"type":16},{"name":1292,"slug":1293,"type":16},"2026-07-29T05:39:38.757423",{"slug":1338,"name":1338,"fn":1339,"description":1340,"org":1341,"tags":1342,"stars":20,"repoUrl":21,"updatedAt":1349},"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},[1343,1346],{"name":1344,"slug":1345,"type":16},"Configuration","configuration",{"name":1347,"slug":1348,"type":16},"Local Development","local-development","2026-08-01T05:44:46.333988",{"slug":1351,"name":1351,"fn":1352,"description":1353,"org":1354,"tags":1355,"stars":20,"repoUrl":21,"updatedAt":1360},"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},[1356,1357],{"name":18,"slug":19,"type":16},{"name":1358,"slug":1359,"type":16},"Documentation","documentation","2026-07-16T06:00:34.090082",33,{"items":1363,"total":1361},[1364,1370,1376,1382,1388,1394,1403],{"slug":1205,"name":1205,"fn":1206,"description":1207,"org":1365,"tags":1366,"stars":20,"repoUrl":21,"updatedAt":1219},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[1367,1368,1369],{"name":1211,"slug":1212,"type":16},{"name":1214,"slug":1215,"type":16},{"name":1217,"slug":1218,"type":16},{"slug":1221,"name":1221,"fn":1222,"description":1223,"org":1371,"tags":1372,"stars":20,"repoUrl":21,"updatedAt":1235},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[1373,1374,1375],{"name":1227,"slug":1228,"type":16},{"name":1230,"slug":1231,"type":16},{"name":1233,"slug":1234,"type":16},{"slug":1237,"name":1237,"fn":1238,"description":1239,"org":1377,"tags":1378,"stars":20,"repoUrl":21,"updatedAt":1247},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[1379,1380,1381],{"name":46,"slug":35,"type":16},{"name":1227,"slug":1228,"type":16},{"name":1245,"slug":1246,"type":16},{"slug":1249,"name":1249,"fn":1250,"description":1251,"org":1383,"tags":1384,"stars":20,"repoUrl":21,"updatedAt":1263},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[1385,1386,1387],{"name":1255,"slug":1256,"type":16},{"name":1258,"slug":1259,"type":16},{"name":1261,"slug":1262,"type":16},{"slug":1265,"name":1265,"fn":1266,"description":1267,"org":1389,"tags":1390,"stars":20,"repoUrl":21,"updatedAt":1275},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[1391,1392,1393],{"name":18,"slug":19,"type":16},{"name":1211,"slug":1212,"type":16},{"name":1273,"slug":1274,"type":16},{"slug":1277,"name":1277,"fn":1278,"description":1279,"org":1395,"tags":1396,"stars":20,"repoUrl":21,"updatedAt":1294},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[1397,1398,1399,1400,1401,1402],{"name":18,"slug":19,"type":16},{"name":1284,"slug":1285,"type":16},{"name":1258,"slug":1259,"type":16},{"name":1214,"slug":1215,"type":16},{"name":1289,"slug":1290,"type":16},{"name":1292,"slug":1293,"type":16},{"slug":1296,"name":1296,"fn":1297,"description":1298,"org":1404,"tags":1405,"stars":20,"repoUrl":21,"updatedAt":1304},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[1406,1407,1408],{"name":46,"slug":35,"type":16},{"name":1214,"slug":1215,"type":16},{"name":1217,"slug":1218,"type":16}]