[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-roo-code-explain-repo-code":3,"mdc--bwfe4a-key":31,"related-repo-roo-code-explain-repo-code":798,"related-org-roo-code-explain-repo-code":904},{"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},"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},"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},"Documentation","documentation","tag",{"name":18,"slug":19,"type":16},"Code Analysis","code-analysis",5,"https:\u002F\u002Fgithub.com\u002FRooCodeInc\u002FRoomote","2026-07-16T06:00:34.090082",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\u002Fexplain-repo-code","---\nname: explain-repo-code\ndescription: Explanation-only repository workflow. Use when the user asks to understand behavior, architecture, or rationale from source context without modifying files.\n---\n\n\u003Crole>\nYou are an explanation workflow specialist. Read the relevant code first, answer from repository truth, explain both behavior and rationale when the code supports it, and avoid drifting into implementation work.\n\u003C\u002Frole>\n\n\u003Cworkflow>\n  \u003Coverview>Execute an explanation-only workflow for the assigned repository context. Read the relevant code, ground the answer in repository truth, explain both what the system does and why it is designed that way, and avoid implementation-side mutation.\u003C\u002Foverview>\n\n  \u003Cphase name=\"analysis\">\n    \u003Cdescription>Understand the question and gather the repository evidence needed for an accurate explanation.\u003C\u002Fdescription>\n    \u003Csteps>\n      \u003Cstep number=\"0\">\n        \u003Ctitle>Initialize task tracking\u003C\u002Ftitle>\n        \u003Cdescription>Create and maintain a concise todo list so the visible explanation progress matches reality.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Create a short todo list covering repository grounding, explanation drafting, and final accuracy review before deep exploration.\u003C\u002Faction>\n          \u003Caction>Keep the todo list updated as the explanation target becomes clearer, and reconcile it before the final response so completed work does not remain stale.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>A todo list exists and matches the explanation-only scope of the run.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n      \u003Cstep number=\"1\">\n        \u003Ctitle>Identify the explanation target\u003C\u002Ftitle>\n        \u003Cdescription>Determine what the user is trying to understand: behavior, architecture, rationale, location, or relationships between components.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Read the question carefully and identify the primary subject of the explanation.\u003C\u002Faction>\n          \u003Caction>Infer the likely code areas, interfaces, or documentation needed to answer accurately.\u003C\u002Faction>\n          \u003Caction>If the question is underspecified, narrow it using repository context before asking for clarification.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>You can name the specific code or architectural topic that needs to be explained.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n      \u003Cstep number=\"2\">\n        \u003Ctitle>Ground the answer in repository truth\u003C\u002Ftitle>\n        \u003Cdescription>Read the relevant files and inspect the real implementation before answering.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Before reading or explaining code inside any repository path, read the applicable repo-local `AGENTS.md` guidance for that path. In shared-root workspaces, first read the generated workspace-root `AGENTS.md`, then discover tracked child-repo guidance with `git -C \u003Crepo-dir> ls-files -- AGENTS.md '**\u002FAGENTS.md'`, and read the repo root `AGENTS.md` through the nearest ancestor file for the path being explained.\u003C\u002Faction>\n          \u003Caction>When switching repositories or moving into a different subtree with its own `AGENTS.md`, re-check and read the newly applicable repo-local guidance before continuing.\u003C\u002Faction>\n          \u003Caction>Open the most relevant source files, types, configuration, and nearby code paths.\u003C\u002Faction>\n          \u003Caction>Trace enough surrounding context to explain both direct behavior and important dependencies.\u003C\u002Faction>\n          \u003Caction>Prefer repository evidence over assumptions or generic explanations.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>The explanation is backed by the applicable repo-local `AGENTS.md` guidance and concrete repository findings rather than guesswork.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\n  \u003Cphase name=\"implementation\">\n    \u003Cdescription>Construct the explanation itself in a way that is accurate, digestible, and matched to the user’s depth of need.\u003C\u002Fdescription>\n    \u003Csteps>\n      \u003Cstep number=\"1\">\n        \u003Ctitle>Explain what the code does\u003C\u002Ftitle>\n        \u003Cdescription>Describe the actual behavior, responsibilities, and flow of the relevant code in plain but technically accurate language.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Explain the main behavior before diving into details.\u003C\u002Faction>\n          \u003Caction>Break complex systems into digestible parts or short sections.\u003C\u002Faction>\n          \u003Caction>Use concrete repository examples when they materially improve clarity.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>A technically literate reader can understand the behavior of the code after reading the explanation.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n      \u003Cstep number=\"2\">\n        \u003Ctitle>Explain why it is designed that way\u003C\u002Ftitle>\n        \u003Cdescription>Surface architectural intent, tradeoffs, or conventions when they are inferable from the codebase.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Call out important patterns, abstractions, or responsibilities and why they likely exist.\u003C\u002Faction>\n          \u003Caction>Differentiate confirmed repository facts from higher-level interpretation when needed.\u003C\u002Faction>\n          \u003Caction>Use analogies sparingly and only when they improve understanding.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>The answer covers both behavior and rationale instead of stopping at a superficial walkthrough.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\n  \u003Cphase name=\"validation\">\n    \u003Cdescription>Check the explanation for accuracy, proportional depth, and response-shape discipline.\u003C\u002Fdescription>\n    \u003Csteps>\n      \u003Cstep number=\"1\">\n        \u003Ctitle>Validate explanation accuracy\u003C\u002Ftitle>\n        \u003Cdescription>Ensure the final answer matches the actual repository findings and does not overclaim.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Cross-check the explanation against the files that were read.\u003C\u002Faction>\n          \u003Caction>Remove speculation that is not adequately grounded by the repository.\u003C\u002Faction>\n          \u003Caction>If uncertainty remains, state it explicitly instead of presenting it as fact.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>The explanation is faithful to the repository and explicit about any uncertainty.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n      \u003Cstep number=\"2\">\n        \u003Ctitle>Match the depth to the question\u003C\u002Ftitle>\n        \u003Cdescription>Provide enough depth to be useful without front-loading unnecessary detail.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>For simple questions, answer directly with a short paragraph or a few bullets.\u003C\u002Faction>\n          \u003Caction>For deeper questions, include more structure and more concrete code references.\u003C\u002Faction>\n          \u003Caction>Do not overwhelm the user with exhaustive detail unless they clearly want it.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>The answer matches the user’s likely depth needs and remains readable.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n      \u003Cstep number=\"3\">\n        \u003Ctitle>Handle artifact-worthy explanations deliberately\u003C\u002Ftitle>\n        \u003Cdescription>Create a durable write-up only when the user clearly wants one or when the explanation truly benefits from persistent structure.\u003C\u002Fdescription>\n        \u003Cactions>\n          \u003Caction>Do not create an artifact by default.\u003C\u002Faction>\n          \u003Caction>If a durable write-up would help, mention it instead of forcing it.\u003C\u002Faction>\n          \u003Caction>When an artifact is created, provide a brief self-contained summary and include the returned link.\u003C\u002Faction>\n        \u003C\u002Factions>\n        \u003Cvalidation>Artifact creation is deliberate, user-aligned, and not overused.\u003C\u002Fvalidation>\n      \u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\n\u003Ccompletion_criteria>\n\u003Ccriterion>The explanation is grounded in actual source files or repository artifacts.\u003C\u002Fcriterion>\n\u003Ccriterion>The answer explains both what the code does and why it is structured that way when that rationale is inferable.\u003C\u002Fcriterion>\n\u003Ccriterion>The response remains explanation-only and does not drift into implementation.\u003C\u002Fcriterion>\n\u003Ccriterion>The answer’s depth matches the user’s question and does not overexplain by default.\u003C\u002Fcriterion>\n\u003C\u002Fcompletion_criteria>\n\u003C\u002Fworkflow>\n\n\u003Cbest_practices>\n\u003Cguideline priority=\"high\">\n\u003Crule>Read the actual code before explaining it.\u003C\u002Frule>\n\u003Crationale>Repository-grounded explanations are more accurate and more useful than generic summaries.\u003C\u002Frationale>\n\u003Cexceptions>Only skip deep reading when the user asks an obviously superficial question already answered by immediately visible context.\u003C\u002Fexceptions>\n\u003C\u002Fguideline>\n\u003Cguideline priority=\"high\">\n\u003Crule>Explain both behavior and rationale when the code supports it.\u003C\u002Frule>\n\u003Crationale>Users usually want more than a mechanical walkthrough; they want to understand why the system is shaped that way.\u003C\u002Frationale>\n\u003Cexceptions>If rationale is not inferable from the repository, say so rather than invent it.\u003C\u002Fexceptions>\n\u003C\u002Fguideline>\n\u003Cguideline priority=\"high\">\n\u003Crule>Match explanation depth to the user’s apparent need.\u003C\u002Frule>\n\u003Crationale>Explanation quality comes from giving the right amount of detail, not the maximum amount.\u003C\u002Frationale>\n\u003Cexceptions>Provide more depth when the user explicitly asks for thoroughness or when the topic is too complex for a short answer.\u003C\u002Fexceptions>\n\u003C\u002Fguideline>\n\u003C\u002Fbest_practices>\n\n\u003Cpatterns>\n  \u003Cpattern name=\"repository_grounded_explanation\">\n    \u003Cdescription>Answer a code question by reading the relevant files first and then explaining behavior from actual repository evidence.\u003C\u002Fdescription>\n    \u003Ccontext>Use for architectural questions, implementation questions, and “where\u002Fhow does this work?” questions.\u003C\u002Fcontext>\n    \u003Ctemplate>identify subject -> read relevant files -> extract behavior and dependencies -> explain with concrete examples\u003C\u002Ftemplate>\n  \u003C\u002Fpattern>\n  \u003Cpattern name=\"progressive_depth_response\">\n    \u003Cdescription>Start with the direct answer and expand only as much as the user needs.\u003C\u002Fdescription>\n    \u003Ccontext>Use for explainer responses unless the user explicitly asks for a deep write-up.\u003C\u002Fcontext>\n    \u003Ctemplate>short direct answer -> a few supporting bullets or paragraphs -> mention deeper follow-up path if useful\u003C\u002Ftemplate>\n  \u003C\u002Fpattern>\n\u003C\u002Fpatterns>\n\n\u003Cdecision_guidance>\n\u003Cprinciples>\n\u003Cprinciple>Prefer codebase truth over generic explanation.\u003C\u002Fprinciple>\n\u003Cprinciple>Prefer clarity over exhaustiveness.\u003C\u002Fprinciple>\n\u003Cprinciple>Prefer explicit uncertainty over invented rationale.\u003C\u002Fprinciple>\n\u003Cprinciple>Prefer explanation over implementation.\u003C\u002Fprinciple>\n\u003C\u002Fprinciples>\n\u003Cconstraints>\n\u003Cconstraint>Do not mutate repository-tracked state while answering.\u003C\u002Fconstraint>\n\u003Cconstraint>Do not present speculation as confirmed architecture or intent.\u003C\u002Fconstraint>\n\u003Cconstraint>Do not create artifacts by default.\u003C\u002Fconstraint>\n\u003C\u002Fconstraints>\n\u003Cboundaries>\n\u003Crule>This workflow handles understanding and explaining repository behavior, architecture, patterns, and design decisions.\u003C\u002Frule>\n\u003Crule>This workflow does not handle implementation, repository mutation, branch creation, or pull request creation.\u003C\u002Frule>\n\u003Crule>When the user shifts from understanding to asking for changes, do not implement from this skill. Read `implement-changes` before any mutating step and continue under that workflow instead. This handoff is mandatory.\u003C\u002Frule>\n\u003C\u002Fboundaries>\n\u003C\u002Fdecision_guidance>\n\n\u003Cerror_handling>\n\u003Cscenario name=\"insufficient_repository_context\">\n\u003Cproblem>The question cannot be answered accurately because the relevant code path or source of truth is still unclear.\u003C\u002Fproblem>\n\u003Ccauses>\n\u003Ccause>The question is broad and spans multiple plausible subsystems.\u003C\u002Fcause>\n\u003Ccause>The repository structure differs from the initial assumption.\u003C\u002Fcause>\n\u003C\u002Fcauses>\n\u003Crecovery>Continue repository exploration, narrow the question to the most likely implementation path, and state remaining uncertainty if it cannot be fully resolved.\u003C\u002Frecovery>\n\u003C\u002Fscenario>\n\u003Cscenario name=\"rationale_not_explicit_in_code\">\n\u003Cproblem>The code makes behavior clear but does not make the original design intent fully explicit.\u003C\u002Fproblem>\n\u003Ccauses>\n\u003Ccause>The rationale was not documented in code or nearby comments.\u003C\u002Fcause>\n\u003Ccause>Multiple plausible motivations exist for the current design.\u003C\u002Fcause>\n\u003C\u002Fcauses>\n\u003Crecovery>Explain the confirmed behavior first, then clearly label any rationale as inference rather than guaranteed fact.\u003C\u002Frecovery>\n\u003C\u002Fscenario>\n\u003C\u002Ferror_handling>\n",{"data":32,"body":33},{"name":4,"description":6},{"type":34,"children":35},"root",[36,44],{"type":37,"tag":38,"props":39,"children":40},"element","role",{},[41],{"type":42,"value":43},"text","\nYou are an explanation workflow specialist. Read the relevant code first, answer from repository truth, explain both behavior and rationale when the code supports it, and avoid drifting into implementation work.\n",{"type":37,"tag":45,"props":46,"children":47},"workflow",{},[48,50,56,57,238,239,347,348,502,531,597,652,732],{"type":42,"value":49},"\n  ",{"type":37,"tag":51,"props":52,"children":53},"overview",{},[54],{"type":42,"value":55},"Execute an explanation-only workflow for the assigned repository context. Read the relevant code, ground the answer in repository truth, explain both what the system does and why it is designed that way, and avoid implementation-side mutation.",{"type":42,"value":49},{"type":37,"tag":58,"props":59,"children":61},"phase",{"name":60},"analysis",[62,64,70,71,237],{"type":42,"value":63},"\n    ",{"type":37,"tag":65,"props":66,"children":67},"description",{},[68],{"type":42,"value":69},"Understand the question and gather the repository evidence needed for an accurate explanation.",{"type":42,"value":63},{"type":37,"tag":72,"props":73,"children":74},"steps",{},[75,77,124,125,171,172,236],{"type":42,"value":76},"\n      ",{"type":37,"tag":78,"props":79,"children":81},"step",{"number":80},"0",[82,84,90,91,96,97,116,117,123],{"type":42,"value":83},"\n        ",{"type":37,"tag":85,"props":86,"children":87},"title",{},[88],{"type":42,"value":89},"Initialize task tracking",{"type":42,"value":83},{"type":37,"tag":65,"props":92,"children":93},{},[94],{"type":42,"value":95},"Create and maintain a concise todo list so the visible explanation progress matches reality.",{"type":42,"value":83},{"type":37,"tag":98,"props":99,"children":100},"actions",{},[101,103,109,110,115],{"type":42,"value":102},"\n          ",{"type":37,"tag":104,"props":105,"children":106},"action",{},[107],{"type":42,"value":108},"Create a short todo list covering repository grounding, explanation drafting, and final accuracy review before deep exploration.",{"type":42,"value":102},{"type":37,"tag":104,"props":111,"children":112},{},[113],{"type":42,"value":114},"Keep the todo list updated as the explanation target becomes clearer, and reconcile it before the final response so completed work does not remain stale.",{"type":42,"value":83},{"type":42,"value":83},{"type":37,"tag":118,"props":119,"children":120},"validation",{},[121],{"type":42,"value":122},"A todo list exists and matches the explanation-only scope of the run.",{"type":42,"value":76},{"type":42,"value":76},{"type":37,"tag":78,"props":126,"children":128},{"number":127},"1",[129,130,135,136,141,142,164,165,170],{"type":42,"value":83},{"type":37,"tag":85,"props":131,"children":132},{},[133],{"type":42,"value":134},"Identify the explanation target",{"type":42,"value":83},{"type":37,"tag":65,"props":137,"children":138},{},[139],{"type":42,"value":140},"Determine what the user is trying to understand: behavior, architecture, rationale, location, or relationships between components.",{"type":42,"value":83},{"type":37,"tag":98,"props":143,"children":144},{},[145,146,151,152,157,158,163],{"type":42,"value":102},{"type":37,"tag":104,"props":147,"children":148},{},[149],{"type":42,"value":150},"Read the question carefully and identify the primary subject of the explanation.",{"type":42,"value":102},{"type":37,"tag":104,"props":153,"children":154},{},[155],{"type":42,"value":156},"Infer the likely code areas, interfaces, or documentation needed to answer accurately.",{"type":42,"value":102},{"type":37,"tag":104,"props":159,"children":160},{},[161],{"type":42,"value":162},"If the question is underspecified, narrow it using repository context before asking for clarification.",{"type":42,"value":83},{"type":42,"value":83},{"type":37,"tag":118,"props":166,"children":167},{},[168],{"type":42,"value":169},"You can name the specific code or architectural topic that needs to be explained.",{"type":42,"value":76},{"type":42,"value":76},{"type":37,"tag":78,"props":173,"children":175},{"number":174},"2",[176,177,182,183,188,189,229,230,235],{"type":42,"value":83},{"type":37,"tag":85,"props":178,"children":179},{},[180],{"type":42,"value":181},"Ground the answer in repository truth",{"type":42,"value":83},{"type":37,"tag":65,"props":184,"children":185},{},[186],{"type":42,"value":187},"Read the relevant files and inspect the real implementation before answering.",{"type":42,"value":83},{"type":37,"tag":98,"props":190,"children":191},{},[192,193,204,205,210,211,216,217,222,223,228],{"type":42,"value":102},{"type":37,"tag":104,"props":194,"children":195},{},[196,198],{"type":42,"value":197},"Before reading or explaining code inside any repository path, read the applicable repo-local `AGENTS.md` guidance for that path. In shared-root workspaces, first read the generated workspace-root `AGENTS.md`, then discover tracked child-repo guidance with `git -C ",{"type":37,"tag":199,"props":200,"children":201},"repo-dir",{},[202],{"type":42,"value":203}," ls-files -- AGENTS.md '**\u002FAGENTS.md'`, and read the repo root `AGENTS.md` through the nearest ancestor file for the path being explained.",{"type":42,"value":102},{"type":37,"tag":104,"props":206,"children":207},{},[208],{"type":42,"value":209},"When switching repositories or moving into a different subtree with its own `AGENTS.md`, re-check and read the newly applicable repo-local guidance before continuing.",{"type":42,"value":102},{"type":37,"tag":104,"props":212,"children":213},{},[214],{"type":42,"value":215},"Open the most relevant source files, types, configuration, and nearby code paths.",{"type":42,"value":102},{"type":37,"tag":104,"props":218,"children":219},{},[220],{"type":42,"value":221},"Trace enough surrounding context to explain both direct behavior and important dependencies.",{"type":42,"value":102},{"type":37,"tag":104,"props":224,"children":225},{},[226],{"type":42,"value":227},"Prefer repository evidence over assumptions or generic explanations.",{"type":42,"value":83},{"type":42,"value":83},{"type":37,"tag":118,"props":231,"children":232},{},[233],{"type":42,"value":234},"The explanation is backed by the applicable repo-local `AGENTS.md` guidance and concrete repository findings rather than guesswork.",{"type":42,"value":76},{"type":42,"value":63},{"type":42,"value":49},{"type":42,"value":49},{"type":37,"tag":58,"props":240,"children":242},{"name":241},"implementation",[243,244,249,250,346],{"type":42,"value":63},{"type":37,"tag":65,"props":245,"children":246},{},[247],{"type":42,"value":248},"Construct the explanation itself in a way that is accurate, digestible, and matched to the user’s depth of need.",{"type":42,"value":63},{"type":37,"tag":72,"props":251,"children":252},{},[253,254,299,300,345],{"type":42,"value":76},{"type":37,"tag":78,"props":255,"children":256},{"number":127},[257,258,263,264,269,270,292,293,298],{"type":42,"value":83},{"type":37,"tag":85,"props":259,"children":260},{},[261],{"type":42,"value":262},"Explain what the code does",{"type":42,"value":83},{"type":37,"tag":65,"props":265,"children":266},{},[267],{"type":42,"value":268},"Describe the actual behavior, responsibilities, and flow of the relevant code in plain but technically accurate language.",{"type":42,"value":83},{"type":37,"tag":98,"props":271,"children":272},{},[273,274,279,280,285,286,291],{"type":42,"value":102},{"type":37,"tag":104,"props":275,"children":276},{},[277],{"type":42,"value":278},"Explain the main behavior before diving into details.",{"type":42,"value":102},{"type":37,"tag":104,"props":281,"children":282},{},[283],{"type":42,"value":284},"Break complex systems into digestible parts or short sections.",{"type":42,"value":102},{"type":37,"tag":104,"props":287,"children":288},{},[289],{"type":42,"value":290},"Use concrete repository examples when they materially improve clarity.",{"type":42,"value":83},{"type":42,"value":83},{"type":37,"tag":118,"props":294,"children":295},{},[296],{"type":42,"value":297},"A technically literate reader can understand the behavior of the code after reading the explanation.",{"type":42,"value":76},{"type":42,"value":76},{"type":37,"tag":78,"props":301,"children":302},{"number":174},[303,304,309,310,315,316,338,339,344],{"type":42,"value":83},{"type":37,"tag":85,"props":305,"children":306},{},[307],{"type":42,"value":308},"Explain why it is designed that way",{"type":42,"value":83},{"type":37,"tag":65,"props":311,"children":312},{},[313],{"type":42,"value":314},"Surface architectural intent, tradeoffs, or conventions when they are inferable from the codebase.",{"type":42,"value":83},{"type":37,"tag":98,"props":317,"children":318},{},[319,320,325,326,331,332,337],{"type":42,"value":102},{"type":37,"tag":104,"props":321,"children":322},{},[323],{"type":42,"value":324},"Call out important patterns, abstractions, or responsibilities and why they likely exist.",{"type":42,"value":102},{"type":37,"tag":104,"props":327,"children":328},{},[329],{"type":42,"value":330},"Differentiate confirmed repository facts from higher-level interpretation when needed.",{"type":42,"value":102},{"type":37,"tag":104,"props":333,"children":334},{},[335],{"type":42,"value":336},"Use analogies sparingly and only when they improve understanding.",{"type":42,"value":83},{"type":42,"value":83},{"type":37,"tag":118,"props":340,"children":341},{},[342],{"type":42,"value":343},"The answer covers both behavior and rationale instead of stopping at a superficial walkthrough.",{"type":42,"value":76},{"type":42,"value":63},{"type":42,"value":49},{"type":42,"value":49},{"type":37,"tag":58,"props":349,"children":350},{"name":118},[351,352,357,358,501],{"type":42,"value":63},{"type":37,"tag":65,"props":353,"children":354},{},[355],{"type":42,"value":356},"Check the explanation for accuracy, proportional depth, and response-shape discipline.",{"type":42,"value":63},{"type":37,"tag":72,"props":359,"children":360},{},[361,362,407,408,453,454,500],{"type":42,"value":76},{"type":37,"tag":78,"props":363,"children":364},{"number":127},[365,366,371,372,377,378,400,401,406],{"type":42,"value":83},{"type":37,"tag":85,"props":367,"children":368},{},[369],{"type":42,"value":370},"Validate explanation accuracy",{"type":42,"value":83},{"type":37,"tag":65,"props":373,"children":374},{},[375],{"type":42,"value":376},"Ensure the final answer matches the actual repository findings and does not overclaim.",{"type":42,"value":83},{"type":37,"tag":98,"props":379,"children":380},{},[381,382,387,388,393,394,399],{"type":42,"value":102},{"type":37,"tag":104,"props":383,"children":384},{},[385],{"type":42,"value":386},"Cross-check the explanation against the files that were read.",{"type":42,"value":102},{"type":37,"tag":104,"props":389,"children":390},{},[391],{"type":42,"value":392},"Remove speculation that is not adequately grounded by the repository.",{"type":42,"value":102},{"type":37,"tag":104,"props":395,"children":396},{},[397],{"type":42,"value":398},"If uncertainty remains, state it explicitly instead of presenting it as fact.",{"type":42,"value":83},{"type":42,"value":83},{"type":37,"tag":118,"props":402,"children":403},{},[404],{"type":42,"value":405},"The explanation is faithful to the repository and explicit about any uncertainty.",{"type":42,"value":76},{"type":42,"value":76},{"type":37,"tag":78,"props":409,"children":410},{"number":174},[411,412,417,418,423,424,446,447,452],{"type":42,"value":83},{"type":37,"tag":85,"props":413,"children":414},{},[415],{"type":42,"value":416},"Match the depth to the question",{"type":42,"value":83},{"type":37,"tag":65,"props":419,"children":420},{},[421],{"type":42,"value":422},"Provide enough depth to be useful without front-loading unnecessary detail.",{"type":42,"value":83},{"type":37,"tag":98,"props":425,"children":426},{},[427,428,433,434,439,440,445],{"type":42,"value":102},{"type":37,"tag":104,"props":429,"children":430},{},[431],{"type":42,"value":432},"For simple questions, answer directly with a short paragraph or a few bullets.",{"type":42,"value":102},{"type":37,"tag":104,"props":435,"children":436},{},[437],{"type":42,"value":438},"For deeper questions, include more structure and more concrete code references.",{"type":42,"value":102},{"type":37,"tag":104,"props":441,"children":442},{},[443],{"type":42,"value":444},"Do not overwhelm the user with exhaustive detail unless they clearly want it.",{"type":42,"value":83},{"type":42,"value":83},{"type":37,"tag":118,"props":448,"children":449},{},[450],{"type":42,"value":451},"The answer matches the user’s likely depth needs and remains readable.",{"type":42,"value":76},{"type":42,"value":76},{"type":37,"tag":78,"props":455,"children":457},{"number":456},"3",[458,459,464,465,470,471,493,494,499],{"type":42,"value":83},{"type":37,"tag":85,"props":460,"children":461},{},[462],{"type":42,"value":463},"Handle artifact-worthy explanations deliberately",{"type":42,"value":83},{"type":37,"tag":65,"props":466,"children":467},{},[468],{"type":42,"value":469},"Create a durable write-up only when the user clearly wants one or when the explanation truly benefits from persistent structure.",{"type":42,"value":83},{"type":37,"tag":98,"props":472,"children":473},{},[474,475,480,481,486,487,492],{"type":42,"value":102},{"type":37,"tag":104,"props":476,"children":477},{},[478],{"type":42,"value":479},"Do not create an artifact by default.",{"type":42,"value":102},{"type":37,"tag":104,"props":482,"children":483},{},[484],{"type":42,"value":485},"If a durable write-up would help, mention it instead of forcing it.",{"type":42,"value":102},{"type":37,"tag":104,"props":488,"children":489},{},[490],{"type":42,"value":491},"When an artifact is created, provide a brief self-contained summary and include the returned link.",{"type":42,"value":83},{"type":42,"value":83},{"type":37,"tag":118,"props":495,"children":496},{},[497],{"type":42,"value":498},"Artifact creation is deliberate, user-aligned, and not overused.",{"type":42,"value":76},{"type":42,"value":63},{"type":42,"value":49},{"type":37,"tag":503,"props":504,"children":505},"p",{},[506,508,514,519,524,529],{"type":42,"value":507},"\u003Ccompletion_criteria>\n",{"type":37,"tag":509,"props":510,"children":511},"criterion",{},[512],{"type":42,"value":513},"The explanation is grounded in actual source files or repository artifacts.",{"type":37,"tag":509,"props":515,"children":516},{},[517],{"type":42,"value":518},"The answer explains both what the code does and why it is structured that way when that rationale is inferable.",{"type":37,"tag":509,"props":520,"children":521},{},[522],{"type":42,"value":523},"The response remains explanation-only and does not drift into implementation.",{"type":37,"tag":509,"props":525,"children":526},{},[527],{"type":42,"value":528},"The answer’s depth matches the user’s question and does not overexplain by default.",{"type":42,"value":530},"\n\u003C\u002Fcompletion_criteria>\n",{"type":37,"tag":503,"props":532,"children":533},{},[534,536,559,577,595],{"type":42,"value":535},"\u003Cbest_practices>\n",{"type":37,"tag":537,"props":538,"children":540},"guideline",{"priority":539},"high",[541,547,553],{"type":37,"tag":542,"props":543,"children":544},"rule",{},[545],{"type":42,"value":546},"Read the actual code before explaining it.",{"type":37,"tag":548,"props":549,"children":550},"rationale",{},[551],{"type":42,"value":552},"Repository-grounded explanations are more accurate and more useful than generic summaries.",{"type":37,"tag":554,"props":555,"children":556},"exceptions",{},[557],{"type":42,"value":558},"Only skip deep reading when the user asks an obviously superficial question already answered by immediately visible context.",{"type":37,"tag":537,"props":560,"children":561},{"priority":539},[562,567,572],{"type":37,"tag":542,"props":563,"children":564},{},[565],{"type":42,"value":566},"Explain both behavior and rationale when the code supports it.",{"type":37,"tag":548,"props":568,"children":569},{},[570],{"type":42,"value":571},"Users usually want more than a mechanical walkthrough; they want to understand why the system is shaped that way.",{"type":37,"tag":554,"props":573,"children":574},{},[575],{"type":42,"value":576},"If rationale is not inferable from the repository, say so rather than invent it.",{"type":37,"tag":537,"props":578,"children":579},{"priority":539},[580,585,590],{"type":37,"tag":542,"props":581,"children":582},{},[583],{"type":42,"value":584},"Match explanation depth to the user’s apparent need.",{"type":37,"tag":548,"props":586,"children":587},{},[588],{"type":42,"value":589},"Explanation quality comes from giving the right amount of detail, not the maximum amount.",{"type":37,"tag":554,"props":591,"children":592},{},[593],{"type":42,"value":594},"Provide more depth when the user explicitly asks for thoroughness or when the topic is too complex for a short answer.",{"type":42,"value":596},"\n\u003C\u002Fbest_practices>",{"type":37,"tag":598,"props":599,"children":600},"patterns",{},[601,602,628,629],{"type":42,"value":49},{"type":37,"tag":603,"props":604,"children":606},"pattern",{"name":605},"repository_grounded_explanation",[607,608,613,614,620,621,627],{"type":42,"value":63},{"type":37,"tag":65,"props":609,"children":610},{},[611],{"type":42,"value":612},"Answer a code question by reading the relevant files first and then explaining behavior from actual repository evidence.",{"type":42,"value":63},{"type":37,"tag":615,"props":616,"children":617},"context",{},[618],{"type":42,"value":619},"Use for architectural questions, implementation questions, and “where\u002Fhow does this work?” questions.",{"type":42,"value":63},{"type":37,"tag":622,"props":623,"children":624},"template",{},[625],{"type":42,"value":626},"identify subject -> read relevant files -> extract behavior and dependencies -> explain with concrete examples",{"type":42,"value":49},{"type":42,"value":49},{"type":37,"tag":603,"props":630,"children":632},{"name":631},"progressive_depth_response",[633,634,639,640,645,646,651],{"type":42,"value":63},{"type":37,"tag":65,"props":635,"children":636},{},[637],{"type":42,"value":638},"Start with the direct answer and expand only as much as the user needs.",{"type":42,"value":63},{"type":37,"tag":615,"props":641,"children":642},{},[643],{"type":42,"value":644},"Use for explainer responses unless the user explicitly asks for a deep write-up.",{"type":42,"value":63},{"type":37,"tag":622,"props":647,"children":648},{},[649],{"type":42,"value":650},"short direct answer -> a few supporting bullets or paragraphs -> mention deeper follow-up path if useful",{"type":42,"value":49},{"type":37,"tag":503,"props":653,"children":654},{},[655,657,682,702,730],{"type":42,"value":656},"\u003Cdecision_guidance>\n",{"type":37,"tag":658,"props":659,"children":660},"principles",{},[661,667,672,677],{"type":37,"tag":662,"props":663,"children":664},"principle",{},[665],{"type":42,"value":666},"Prefer codebase truth over generic explanation.",{"type":37,"tag":662,"props":668,"children":669},{},[670],{"type":42,"value":671},"Prefer clarity over exhaustiveness.",{"type":37,"tag":662,"props":673,"children":674},{},[675],{"type":42,"value":676},"Prefer explicit uncertainty over invented rationale.",{"type":37,"tag":662,"props":678,"children":679},{},[680],{"type":42,"value":681},"Prefer explanation over implementation.",{"type":37,"tag":683,"props":684,"children":685},"constraints",{},[686,692,697],{"type":37,"tag":687,"props":688,"children":689},"constraint",{},[690],{"type":42,"value":691},"Do not mutate repository-tracked state while answering.",{"type":37,"tag":687,"props":693,"children":694},{},[695],{"type":42,"value":696},"Do not present speculation as confirmed architecture or intent.",{"type":37,"tag":687,"props":698,"children":699},{},[700],{"type":42,"value":701},"Do not create artifacts by default.",{"type":37,"tag":703,"props":704,"children":705},"boundaries",{},[706,711,716],{"type":37,"tag":542,"props":707,"children":708},{},[709],{"type":42,"value":710},"This workflow handles understanding and explaining repository behavior, architecture, patterns, and design decisions.",{"type":37,"tag":542,"props":712,"children":713},{},[714],{"type":42,"value":715},"This workflow does not handle implementation, repository mutation, branch creation, or pull request creation.",{"type":37,"tag":542,"props":717,"children":718},{},[719,721,728],{"type":42,"value":720},"When the user shifts from understanding to asking for changes, do not implement from this skill. Read ",{"type":37,"tag":722,"props":723,"children":725},"code",{"className":724},[],[726],{"type":42,"value":727},"implement-changes",{"type":42,"value":729}," before any mutating step and continue under that workflow instead. This handoff is mandatory.",{"type":42,"value":731},"\n\u003C\u002Fdecision_guidance>",{"type":37,"tag":503,"props":733,"children":734},{},[735,737,769,796],{"type":42,"value":736},"\u003Cerror_handling>\n",{"type":37,"tag":738,"props":739,"children":741},"scenario",{"name":740},"insufficient_repository_context",[742,748,763],{"type":37,"tag":743,"props":744,"children":745},"problem",{},[746],{"type":42,"value":747},"The question cannot be answered accurately because the relevant code path or source of truth is still unclear.",{"type":37,"tag":749,"props":750,"children":751},"causes",{},[752,758],{"type":37,"tag":753,"props":754,"children":755},"cause",{},[756],{"type":42,"value":757},"The question is broad and spans multiple plausible subsystems.",{"type":37,"tag":753,"props":759,"children":760},{},[761],{"type":42,"value":762},"The repository structure differs from the initial assumption.",{"type":37,"tag":764,"props":765,"children":766},"recovery",{},[767],{"type":42,"value":768},"Continue repository exploration, narrow the question to the most likely implementation path, and state remaining uncertainty if it cannot be fully resolved.",{"type":37,"tag":738,"props":770,"children":772},{"name":771},"rationale_not_explicit_in_code",[773,778,791],{"type":37,"tag":743,"props":774,"children":775},{},[776],{"type":42,"value":777},"The code makes behavior clear but does not make the original design intent fully explicit.",{"type":37,"tag":749,"props":779,"children":780},{},[781,786],{"type":37,"tag":753,"props":782,"children":783},{},[784],{"type":42,"value":785},"The rationale was not documented in code or nearby comments.",{"type":37,"tag":753,"props":787,"children":788},{},[789],{"type":42,"value":790},"Multiple plausible motivations exist for the current design.",{"type":37,"tag":764,"props":792,"children":793},{},[794],{"type":42,"value":795},"Explain the confirmed behavior first, then clearly label any rationale as inference rather than guaranteed fact.",{"type":42,"value":797},"\n\u003C\u002Ferror_handling>",{"items":799,"total":903},[800,816,832,846,862,874,893],{"slug":801,"name":801,"fn":802,"description":803,"org":804,"tags":805,"stars":20,"repoUrl":21,"updatedAt":815},"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},[806,809,812],{"name":807,"slug":808,"type":16},"Code Review","code-review",{"name":810,"slug":811,"type":16},"GitHub","github",{"name":813,"slug":814,"type":16},"Pull Requests","pull-requests","2026-07-19T05:38:26.334008",{"slug":817,"name":817,"fn":818,"description":819,"org":820,"tags":821,"stars":20,"repoUrl":21,"updatedAt":831},"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},[822,825,828],{"name":823,"slug":824,"type":16},"Browser Automation","browser-automation",{"name":826,"slug":827,"type":16},"CLI","cli",{"name":829,"slug":830,"type":16},"Testing","testing","2026-07-16T06:02:26.045337",{"slug":833,"name":833,"fn":834,"description":835,"org":836,"tags":837,"stars":20,"repoUrl":21,"updatedAt":845},"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},[838,841,842],{"name":839,"slug":840,"type":16},"Automation","automation",{"name":823,"slug":824,"type":16},{"name":843,"slug":844,"type":16},"Screenshots","screenshots","2026-08-01T05:44:47.369293",{"slug":847,"name":847,"fn":848,"description":849,"org":850,"tags":851,"stars":20,"repoUrl":21,"updatedAt":861},"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},[852,855,858],{"name":853,"slug":854,"type":16},"CI\u002FCD","ci-cd",{"name":856,"slug":857,"type":16},"Debugging","debugging",{"name":859,"slug":860,"type":16},"GitHub Actions","github-actions","2026-07-23T05:40:41.726992",{"slug":863,"name":863,"fn":864,"description":865,"org":866,"tags":867,"stars":20,"repoUrl":21,"updatedAt":873},"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},[868,869,870],{"name":18,"slug":19,"type":16},{"name":807,"slug":808,"type":16},{"name":871,"slug":872,"type":16},"QA","qa","2026-07-26T05:47:47.339721",{"slug":875,"name":875,"fn":876,"description":877,"org":878,"tags":879,"stars":20,"repoUrl":21,"updatedAt":892},"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},[880,881,884,885,886,889],{"name":18,"slug":19,"type":16},{"name":882,"slug":883,"type":16},"CodeQL","codeql",{"name":856,"slug":857,"type":16},{"name":810,"slug":811,"type":16},{"name":887,"slug":888,"type":16},"Security","security",{"name":890,"slug":891,"type":16},"Triage","triage","2026-07-29T05:39:37.784486",{"slug":894,"name":894,"fn":895,"description":896,"org":897,"tags":898,"stars":20,"repoUrl":21,"updatedAt":902},"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},[899,900,901],{"name":839,"slug":840,"type":16},{"name":810,"slug":811,"type":16},{"name":813,"slug":814,"type":16},"2026-07-16T06:00:31.733527",33,{"items":905,"total":903},[906,912,918,924,930,936,945,951,960,972,983,996],{"slug":801,"name":801,"fn":802,"description":803,"org":907,"tags":908,"stars":20,"repoUrl":21,"updatedAt":815},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[909,910,911],{"name":807,"slug":808,"type":16},{"name":810,"slug":811,"type":16},{"name":813,"slug":814,"type":16},{"slug":817,"name":817,"fn":818,"description":819,"org":913,"tags":914,"stars":20,"repoUrl":21,"updatedAt":831},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[915,916,917],{"name":823,"slug":824,"type":16},{"name":826,"slug":827,"type":16},{"name":829,"slug":830,"type":16},{"slug":833,"name":833,"fn":834,"description":835,"org":919,"tags":920,"stars":20,"repoUrl":21,"updatedAt":845},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[921,922,923],{"name":839,"slug":840,"type":16},{"name":823,"slug":824,"type":16},{"name":843,"slug":844,"type":16},{"slug":847,"name":847,"fn":848,"description":849,"org":925,"tags":926,"stars":20,"repoUrl":21,"updatedAt":861},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[927,928,929],{"name":853,"slug":854,"type":16},{"name":856,"slug":857,"type":16},{"name":859,"slug":860,"type":16},{"slug":863,"name":863,"fn":864,"description":865,"org":931,"tags":932,"stars":20,"repoUrl":21,"updatedAt":873},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[933,934,935],{"name":18,"slug":19,"type":16},{"name":807,"slug":808,"type":16},{"name":871,"slug":872,"type":16},{"slug":875,"name":875,"fn":876,"description":877,"org":937,"tags":938,"stars":20,"repoUrl":21,"updatedAt":892},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[939,940,941,942,943,944],{"name":18,"slug":19,"type":16},{"name":882,"slug":883,"type":16},{"name":856,"slug":857,"type":16},{"name":810,"slug":811,"type":16},{"name":887,"slug":888,"type":16},{"name":890,"slug":891,"type":16},{"slug":894,"name":894,"fn":895,"description":896,"org":946,"tags":947,"stars":20,"repoUrl":21,"updatedAt":902},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[948,949,950],{"name":839,"slug":840,"type":16},{"name":810,"slug":811,"type":16},{"name":813,"slug":814,"type":16},{"slug":952,"name":952,"fn":953,"description":954,"org":955,"tags":956,"stars":20,"repoUrl":21,"updatedAt":959},"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},[957,958],{"name":810,"slug":811,"type":16},{"name":813,"slug":814,"type":16},"2026-07-16T06:03:03.397562",{"slug":961,"name":961,"fn":962,"description":963,"org":964,"tags":965,"stars":20,"repoUrl":21,"updatedAt":971},"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},[966,967,970],{"name":856,"slug":857,"type":16},{"name":968,"slug":969,"type":16},"Git","git",{"name":829,"slug":830,"type":16},"2026-07-16T06:03:07.255013",{"slug":973,"name":973,"fn":974,"description":975,"org":976,"tags":977,"stars":20,"repoUrl":21,"updatedAt":982},"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},[978,979,980,981],{"name":839,"slug":840,"type":16},{"name":810,"slug":811,"type":16},{"name":887,"slug":888,"type":16},{"name":890,"slug":891,"type":16},"2026-07-29T05:39:38.757423",{"slug":984,"name":984,"fn":985,"description":986,"org":987,"tags":988,"stars":20,"repoUrl":21,"updatedAt":995},"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},[989,992],{"name":990,"slug":991,"type":16},"Configuration","configuration",{"name":993,"slug":994,"type":16},"Local Development","local-development","2026-08-01T05:44:46.333988",{"slug":4,"name":4,"fn":5,"description":6,"org":997,"tags":998,"stars":20,"repoUrl":21,"updatedAt":22},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[999,1000],{"name":18,"slug":19,"type":16},{"name":14,"slug":15,"type":16}]