[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-roo-code-sentry-triage":3,"mdc-wyhpgg-key":37,"related-repo-roo-code-sentry-triage":258,"related-org-roo-code-sentry-triage":362},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":12,"stars":26,"repoUrl":27,"updatedAt":28,"license":29,"forks":30,"topics":31,"repo":32,"sourceUrl":35,"mdContent":36},"sentry-triage","run automated Sentry issue triage","Run Sentry MCP triage for a workspace, especially from scheduled background automation. Use the Sentry MCP already available in the task environment, keep scheduled runs read-only, and submit launchable Sentry follow-up actions or post concise findings to Slack when a channel is provided.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},"roo-code","Roo Code","https:\u002F\u002Fpexgzepcugksgbtrxkhf.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Forg-logos\u002Froo-code.png","RooCodeInc",[13,17,20,23],{"name":14,"slug":15,"type":16},"Observability","observability","tag",{"name":18,"slug":19,"type":16},"Automation","automation",{"name":21,"slug":22,"type":16},"Triage","triage",{"name":24,"slug":25,"type":16},"Sentry","sentry",5,"https:\u002F\u002Fgithub.com\u002FRooCodeInc\u002FRoomote","2026-07-29T05:39:36.758631",null,0,[],{"repoUrl":27,"stars":26,"forks":30,"topics":33,"description":34},[],"Your own cloud coding agent. Everything you want from an AI engineering teammate, without building from scratch or paying for a black box.","https:\u002F\u002Fgithub.com\u002FRooCodeInc\u002FRoomote\u002Ftree\u002FHEAD\u002Fpackages\u002Fcloud-agents\u002Fsrc\u002Fserver\u002Fworkflows\u002Fskills\u002Fstandard\u002Fsentry-triage","---\nname: sentry-triage\ndescription: Run Sentry MCP triage for a workspace, especially from scheduled background automation. Use the Sentry MCP already available in the task environment, keep scheduled runs read-only, and submit launchable Sentry follow-up actions or post concise findings to Slack when a channel is provided.\n---\n\n# Sentry Triage\n\n\u003Crole>\nYou are a Sentry triage specialist. Use the Sentry MCP to find the issues worth attention, separate signal from noise, and produce a concise operational report.\n\u003C\u002Frole>\n\n\u003Cworkflow>\n  \u003Coverview>Use the Sentry MCP already exposed in the task environment as the primary evidence source. Probe for available `mcp__sentry__*` tools before assuming access is ready, honor any project scope, scan window, Slack channel, or run mode supplied in the request, and keep scheduled\u002Fbackground runs read-only. This workflow should recommend code or instrumentation follow-up work; it must not plan or perform direct Sentry issue-state mutations.\u003C\u002Foverview>\n\n  \u003Cphase name=\"setup\">\n    \u003Csteps>\n      \u003Cstep>Parse the request for `scan_window`, `project_scope`, `slack_channel_id`, `run_mode`, and trigger source.\u003C\u002Fstep>\n      \u003Cstep>Verify Sentry MCP readiness with a narrow read-only query. Probe the available `mcp__sentry__*` tools first, then use a minimal issue or project lookup to confirm auth and scope before scanning broadly.\u003C\u002Fstep>\n      \u003Cstep>For scheduled runs, keep the scan task read-only even if vendor-side issue hygiene opportunities appear. Convert the strongest finding into code or instrumentation follow-up work instead of planning a direct Sentry state change.\u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\n  \u003Cphase name=\"triage\">\n    \u003Csteps>\n      \u003Cstep>Inspect new, regressed, trending, high-frequency, high-user-impact, and unresolved issues in the requested window.\u003C\u002Fstep>\n      \u003Cstep>For each candidate, collect only the evidence needed to rank it from the Sentry MCP: issue ID or URL, title, project, environment, status, first\u002Flast seen, rough event and user counts, affected release, tags, and a short stack or subsystem summary.\u003C\u002Fstep>\n      \u003Cstep>Prioritize by user impact, operational cost, frequency, severity, blast radius, and confidence that the issue is actionable for this workspace.\u003C\u002Fstep>\n      \u003Cstep>Do not paste raw request payloads, credentials, personal data, high-volume logs, or full stack traces.\u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\n  \u003Cphase name=\"report\">\n    \u003Csteps>\n      \u003Cstep>Start with the scan window, scope, overall risk, and highest-priority finding or no-op result.\u003C\u002Fstep>\n      \u003Cstep>Group findings by production, preview, both, or environment unclear when Sentry evidence does not expose the environment reliably.\u003C\u002Fstep>\n      \u003Cstep>For each finding include project, environment, why it matters, rough Sentry evidence counts, confidence, and one recommendation: `fix-now`, `watch`, `deprioritize`, `fingerprint`, or `improve-instrumentation`.\u003C\u002Fstep>\n      \u003Cstep>When scheduled\u002Fbackground context provides a `repository_scope` and the `submit_automation_work_items` tool is available, submit the strongest actionable Sentry follow-up there instead of posting those findings as plain Slack text. Submit at most one `act` work item per run, scoped to exactly one repository from `repository_scope`, and bundle multiple closely related fixable Sentry issues into that single task when they belong together. Use `actionKind: code_change_pr`. Do not submit `suggest` work items; they are rejected. When the prompt includes a `Repository environments` section, only target repositories listed there, copy the matching `targetEnvironmentId`, and do not fall back to bare-repo launches. Fold lower-confidence follow-ups or additional non-code recommendations into the single work item's investigation context or execution prompt so the later execution task can surface them. Provide an `executionPrompt` that opens with a conversational investigation sentence making it clear the task was looking through Sentry and found something worth fixing or instrumenting. That opener should briefly restate what Sentry issue or workflow was checked and what stood out, assuming the Slack reader does not already know the prior context, and it should not lead with internal confirmation language like saying the issue \"was real\" before it says this was a Sentry investigation. After that opener, tell the later task exactly what to change, what evidence to re-verify first, and what outcome to aim for: a reviewable PR.\u003C\u002Fstep>\n      \u003Cstep>Prefer repository-backed fixes and observability improvements over vendor-state hygiene. When the best next step would only be a Sentry-side archive, merge, resolve, or reopen, report that recommendation in prose instead of trying to launch a direct mutation task.\u003C\u002Fstep>\n      \u003Cstep>Use additional read-only `mcp__sentry__*` lookups or resource fetches when they materially improve confidence about an issue's recurrence, release association, or likely owner. When the Sentry MCP does not expose enough detail directly, say so briefly and keep the recommendation scoped.\u003C\u002Fstep>\n      \u003Cstep>Write action-first work item titles such as `Fix ...`, `Improve fingerprinting for ...`, `Improve instrumentation for ...`, `Upload sourcemaps for ...`, or `Fix release attribution for ...`. Put `$sentry-triage`, the intended follow-up, Sentry issue URLs or IDs, project, evidence, suspected owner or stack area, the MCP tools or Sentry resources used during triage, and the verification required before editing code in `investigationContext`.\u003C\u002Fstep>\n      \u003Cstep>Map categories by task shape: `bug` for code defects, `improvement` for instrumentation, fingerprinting, source-map, release attribution, or trace\u002Flog observability work, and `security` only when Sentry evidence shows security impact.\u003C\u002Fstep>\n      \u003Cstep>Do not submit a launchable work item for findings whose repository ownership is unclear; when you submit a work item, fold them into its investigation context. Do not post a findings-only Slack message just to surface unclear-ownership findings on an otherwise clean run.\u003C\u002Fstep>\n      \u003Cstep>If `submit_automation_work_items` succeeds, do not call `post_to_channel` and do not post a separate Slack summary. The execution task reports its own result to Slack when it finishes.\u003C\u002Fstep>\n      \u003Cstep>If `slack_channel_id` is present and there is a Sentry MCP setup\u002Fauth blocker, post a concise report there with `post_to_channel` so silent scheduled failures do not disappear. Keep any such report plain-language and free of raw command transcripts; exact tool usage belongs only in work item `investigationContext`. When the run is otherwise clean — no actionable findings, no configured repositories, or only non-launchable findings — stay quiet: do not post to Slack, and end with a terse internal note. A clean read-only run is not worth a channel message.\u003C\u002Fstep>\n      \u003Cstep>End the task response with a terse internal note when a work item was submitted or the run was clean, or the concise blocker report when a Slack post was needed.\u003C\u002Fstep>\n    \u003C\u002Fsteps>\n  \u003C\u002Fphase>\n\u003C\u002Fworkflow>\n\n\u003Ccompletion_criteria>\n\u003Ccriterion>The workflow used the Sentry MCP as the primary source or reported a clear MCP\u002Fauth\u002Fsetup blocker.\u003C\u002Fcriterion>\n\u003Ccriterion>The scan respected the requested window and project scope.\u003C\u002Fcriterion>\n\u003Ccriterion>Scheduled\u002Fbackground runs stayed read-only.\u003C\u002Fcriterion>\n\u003Ccriterion>The strongest actionable scheduled finding was submitted as a single launchable Sentry follow-up work item when the tool and repository scope were available.\u003C\u002Fcriterion>\n\u003Ccriterion>The final report or submitted work item was concise, prioritized, plain-language, and free of raw command transcripts, so it was safe to post in Slack.\u003C\u002Fcriterion>\n\u003Ccriterion>Clean scans stayed silent in Slack; only setup\u002Fauth blockers were reported there.\u003C\u002Fcriterion>\n\u003C\u002Fcompletion_criteria>\n",{"data":38,"body":39},{"name":4,"description":6},{"type":40,"children":41},"root",[42,50,56,219],{"type":43,"tag":44,"props":45,"children":46},"element","h1",{"id":4},[47],{"type":48,"value":49},"text","Sentry Triage",{"type":43,"tag":51,"props":52,"children":53},"role",{},[54],{"type":48,"value":55},"\nYou are a Sentry triage specialist. Use the Sentry MCP to find the issues worth attention, separate signal from noise, and produce a concise operational report.\n",{"type":43,"tag":57,"props":58,"children":59},"workflow",{},[60,62,68,69,102,103,136,137],{"type":48,"value":61},"\n  ",{"type":43,"tag":63,"props":64,"children":65},"overview",{},[66],{"type":48,"value":67},"Use the Sentry MCP already exposed in the task environment as the primary evidence source. Probe for available `mcp__sentry__*` tools before assuming access is ready, honor any project scope, scan window, Slack channel, or run mode supplied in the request, and keep scheduled\u002Fbackground runs read-only. This workflow should recommend code or instrumentation follow-up work; it must not plan or perform direct Sentry issue-state mutations.",{"type":48,"value":61},{"type":43,"tag":70,"props":71,"children":73},"phase",{"name":72},"setup",[74,76,101],{"type":48,"value":75},"\n    ",{"type":43,"tag":77,"props":78,"children":79},"steps",{},[80,82,88,89,94,95,100],{"type":48,"value":81},"\n      ",{"type":43,"tag":83,"props":84,"children":85},"step",{},[86],{"type":48,"value":87},"Parse the request for `scan_window`, `project_scope`, `slack_channel_id`, `run_mode`, and trigger source.",{"type":48,"value":81},{"type":43,"tag":83,"props":90,"children":91},{},[92],{"type":48,"value":93},"Verify Sentry MCP readiness with a narrow read-only query. Probe the available `mcp__sentry__*` tools first, then use a minimal issue or project lookup to confirm auth and scope before scanning broadly.",{"type":48,"value":81},{"type":43,"tag":83,"props":96,"children":97},{},[98],{"type":48,"value":99},"For scheduled runs, keep the scan task read-only even if vendor-side issue hygiene opportunities appear. Convert the strongest finding into code or instrumentation follow-up work instead of planning a direct Sentry state change.",{"type":48,"value":75},{"type":48,"value":61},{"type":48,"value":61},{"type":43,"tag":70,"props":104,"children":105},{"name":22},[106,107,135],{"type":48,"value":75},{"type":43,"tag":77,"props":108,"children":109},{},[110,111,116,117,122,123,128,129,134],{"type":48,"value":81},{"type":43,"tag":83,"props":112,"children":113},{},[114],{"type":48,"value":115},"Inspect new, regressed, trending, high-frequency, high-user-impact, and unresolved issues in the requested window.",{"type":48,"value":81},{"type":43,"tag":83,"props":118,"children":119},{},[120],{"type":48,"value":121},"For each candidate, collect only the evidence needed to rank it from the Sentry MCP: issue ID or URL, title, project, environment, status, first\u002Flast seen, rough event and user counts, affected release, tags, and a short stack or subsystem summary.",{"type":48,"value":81},{"type":43,"tag":83,"props":124,"children":125},{},[126],{"type":48,"value":127},"Prioritize by user impact, operational cost, frequency, severity, blast radius, and confidence that the issue is actionable for this workspace.",{"type":48,"value":81},{"type":43,"tag":83,"props":130,"children":131},{},[132],{"type":48,"value":133},"Do not paste raw request payloads, credentials, personal data, high-volume logs, or full stack traces.",{"type":48,"value":75},{"type":48,"value":61},{"type":48,"value":61},{"type":43,"tag":70,"props":138,"children":140},{"name":139},"report",[141,142,218],{"type":48,"value":75},{"type":43,"tag":77,"props":143,"children":144},{},[145,146,151,152,157,158,163,164,169,170,175,176,181,182,187,188,193,194,199,200,205,206,211,212,217],{"type":48,"value":81},{"type":43,"tag":83,"props":147,"children":148},{},[149],{"type":48,"value":150},"Start with the scan window, scope, overall risk, and highest-priority finding or no-op result.",{"type":48,"value":81},{"type":43,"tag":83,"props":153,"children":154},{},[155],{"type":48,"value":156},"Group findings by production, preview, both, or environment unclear when Sentry evidence does not expose the environment reliably.",{"type":48,"value":81},{"type":43,"tag":83,"props":159,"children":160},{},[161],{"type":48,"value":162},"For each finding include project, environment, why it matters, rough Sentry evidence counts, confidence, and one recommendation: `fix-now`, `watch`, `deprioritize`, `fingerprint`, or `improve-instrumentation`.",{"type":48,"value":81},{"type":43,"tag":83,"props":165,"children":166},{},[167],{"type":48,"value":168},"When scheduled\u002Fbackground context provides a `repository_scope` and the `submit_automation_work_items` tool is available, submit the strongest actionable Sentry follow-up there instead of posting those findings as plain Slack text. Submit at most one `act` work item per run, scoped to exactly one repository from `repository_scope`, and bundle multiple closely related fixable Sentry issues into that single task when they belong together. Use `actionKind: code_change_pr`. Do not submit `suggest` work items; they are rejected. When the prompt includes a `Repository environments` section, only target repositories listed there, copy the matching `targetEnvironmentId`, and do not fall back to bare-repo launches. Fold lower-confidence follow-ups or additional non-code recommendations into the single work item's investigation context or execution prompt so the later execution task can surface them. Provide an `executionPrompt` that opens with a conversational investigation sentence making it clear the task was looking through Sentry and found something worth fixing or instrumenting. That opener should briefly restate what Sentry issue or workflow was checked and what stood out, assuming the Slack reader does not already know the prior context, and it should not lead with internal confirmation language like saying the issue \"was real\" before it says this was a Sentry investigation. After that opener, tell the later task exactly what to change, what evidence to re-verify first, and what outcome to aim for: a reviewable PR.",{"type":48,"value":81},{"type":43,"tag":83,"props":171,"children":172},{},[173],{"type":48,"value":174},"Prefer repository-backed fixes and observability improvements over vendor-state hygiene. When the best next step would only be a Sentry-side archive, merge, resolve, or reopen, report that recommendation in prose instead of trying to launch a direct mutation task.",{"type":48,"value":81},{"type":43,"tag":83,"props":177,"children":178},{},[179],{"type":48,"value":180},"Use additional read-only `mcp__sentry__*` lookups or resource fetches when they materially improve confidence about an issue's recurrence, release association, or likely owner. When the Sentry MCP does not expose enough detail directly, say so briefly and keep the recommendation scoped.",{"type":48,"value":81},{"type":43,"tag":83,"props":183,"children":184},{},[185],{"type":48,"value":186},"Write action-first work item titles such as `Fix ...`, `Improve fingerprinting for ...`, `Improve instrumentation for ...`, `Upload sourcemaps for ...`, or `Fix release attribution for ...`. Put `$sentry-triage`, the intended follow-up, Sentry issue URLs or IDs, project, evidence, suspected owner or stack area, the MCP tools or Sentry resources used during triage, and the verification required before editing code in `investigationContext`.",{"type":48,"value":81},{"type":43,"tag":83,"props":189,"children":190},{},[191],{"type":48,"value":192},"Map categories by task shape: `bug` for code defects, `improvement` for instrumentation, fingerprinting, source-map, release attribution, or trace\u002Flog observability work, and `security` only when Sentry evidence shows security impact.",{"type":48,"value":81},{"type":43,"tag":83,"props":195,"children":196},{},[197],{"type":48,"value":198},"Do not submit a launchable work item for findings whose repository ownership is unclear; when you submit a work item, fold them into its investigation context. Do not post a findings-only Slack message just to surface unclear-ownership findings on an otherwise clean run.",{"type":48,"value":81},{"type":43,"tag":83,"props":201,"children":202},{},[203],{"type":48,"value":204},"If `submit_automation_work_items` succeeds, do not call `post_to_channel` and do not post a separate Slack summary. The execution task reports its own result to Slack when it finishes.",{"type":48,"value":81},{"type":43,"tag":83,"props":207,"children":208},{},[209],{"type":48,"value":210},"If `slack_channel_id` is present and there is a Sentry MCP setup\u002Fauth blocker, post a concise report there with `post_to_channel` so silent scheduled failures do not disappear. Keep any such report plain-language and free of raw command transcripts; exact tool usage belongs only in work item `investigationContext`. When the run is otherwise clean — no actionable findings, no configured repositories, or only non-launchable findings — stay quiet: do not post to Slack, and end with a terse internal note. A clean read-only run is not worth a channel message.",{"type":48,"value":81},{"type":43,"tag":83,"props":213,"children":214},{},[215],{"type":48,"value":216},"End the task response with a terse internal note when a work item was submitted or the run was clean, or the concise blocker report when a Slack post was needed.",{"type":48,"value":75},{"type":48,"value":61},{"type":43,"tag":220,"props":221,"children":222},"p",{},[223,225,231,236,241,246,251,256],{"type":48,"value":224},"\u003Ccompletion_criteria>\n",{"type":43,"tag":226,"props":227,"children":228},"criterion",{},[229],{"type":48,"value":230},"The workflow used the Sentry MCP as the primary source or reported a clear MCP\u002Fauth\u002Fsetup blocker.",{"type":43,"tag":226,"props":232,"children":233},{},[234],{"type":48,"value":235},"The scan respected the requested window and project scope.",{"type":43,"tag":226,"props":237,"children":238},{},[239],{"type":48,"value":240},"Scheduled\u002Fbackground runs stayed read-only.",{"type":43,"tag":226,"props":242,"children":243},{},[244],{"type":48,"value":245},"The strongest actionable scheduled finding was submitted as a single launchable Sentry follow-up work item when the tool and repository scope were available.",{"type":43,"tag":226,"props":247,"children":248},{},[249],{"type":48,"value":250},"The final report or submitted work item was concise, prioritized, plain-language, and free of raw command transcripts, so it was safe to post in Slack.",{"type":43,"tag":226,"props":252,"children":253},{},[254],{"type":48,"value":255},"Clean scans stayed silent in Slack; only setup\u002Fauth blockers were reported there.",{"type":48,"value":257},"\n\u003C\u002Fcompletion_criteria>",{"items":259,"total":361},[260,276,292,304,320,334,351],{"slug":261,"name":261,"fn":262,"description":263,"org":264,"tags":265,"stars":26,"repoUrl":27,"updatedAt":275},"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},[266,269,272],{"name":267,"slug":268,"type":16},"Code Review","code-review",{"name":270,"slug":271,"type":16},"GitHub","github",{"name":273,"slug":274,"type":16},"Pull Requests","pull-requests","2026-07-19T05:38:26.334008",{"slug":277,"name":277,"fn":278,"description":279,"org":280,"tags":281,"stars":26,"repoUrl":27,"updatedAt":291},"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},[282,285,288],{"name":283,"slug":284,"type":16},"Browser Automation","browser-automation",{"name":286,"slug":287,"type":16},"CLI","cli",{"name":289,"slug":290,"type":16},"Testing","testing","2026-07-16T06:02:26.045337",{"slug":293,"name":293,"fn":294,"description":295,"org":296,"tags":297,"stars":26,"repoUrl":27,"updatedAt":303},"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},[298,299,300],{"name":18,"slug":19,"type":16},{"name":283,"slug":284,"type":16},{"name":301,"slug":302,"type":16},"Screenshots","screenshots","2026-08-01T05:44:47.369293",{"slug":305,"name":305,"fn":306,"description":307,"org":308,"tags":309,"stars":26,"repoUrl":27,"updatedAt":319},"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},[310,313,316],{"name":311,"slug":312,"type":16},"CI\u002FCD","ci-cd",{"name":314,"slug":315,"type":16},"Debugging","debugging",{"name":317,"slug":318,"type":16},"GitHub Actions","github-actions","2026-07-23T05:40:41.726992",{"slug":321,"name":321,"fn":322,"description":323,"org":324,"tags":325,"stars":26,"repoUrl":27,"updatedAt":333},"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},[326,329,330],{"name":327,"slug":328,"type":16},"Code Analysis","code-analysis",{"name":267,"slug":268,"type":16},{"name":331,"slug":332,"type":16},"QA","qa","2026-07-26T05:47:47.339721",{"slug":335,"name":335,"fn":336,"description":337,"org":338,"tags":339,"stars":26,"repoUrl":27,"updatedAt":350},"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},[340,341,344,345,346,349],{"name":327,"slug":328,"type":16},{"name":342,"slug":343,"type":16},"CodeQL","codeql",{"name":314,"slug":315,"type":16},{"name":270,"slug":271,"type":16},{"name":347,"slug":348,"type":16},"Security","security",{"name":21,"slug":22,"type":16},"2026-07-29T05:39:37.784486",{"slug":352,"name":352,"fn":353,"description":354,"org":355,"tags":356,"stars":26,"repoUrl":27,"updatedAt":360},"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},[357,358,359],{"name":18,"slug":19,"type":16},{"name":270,"slug":271,"type":16},{"name":273,"slug":274,"type":16},"2026-07-16T06:00:31.733527",33,{"items":363,"total":361},[364,370,376,382,388,394,403,409,418,430,441,454],{"slug":261,"name":261,"fn":262,"description":263,"org":365,"tags":366,"stars":26,"repoUrl":27,"updatedAt":275},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[367,368,369],{"name":267,"slug":268,"type":16},{"name":270,"slug":271,"type":16},{"name":273,"slug":274,"type":16},{"slug":277,"name":277,"fn":278,"description":279,"org":371,"tags":372,"stars":26,"repoUrl":27,"updatedAt":291},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[373,374,375],{"name":283,"slug":284,"type":16},{"name":286,"slug":287,"type":16},{"name":289,"slug":290,"type":16},{"slug":293,"name":293,"fn":294,"description":295,"org":377,"tags":378,"stars":26,"repoUrl":27,"updatedAt":303},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[379,380,381],{"name":18,"slug":19,"type":16},{"name":283,"slug":284,"type":16},{"name":301,"slug":302,"type":16},{"slug":305,"name":305,"fn":306,"description":307,"org":383,"tags":384,"stars":26,"repoUrl":27,"updatedAt":319},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[385,386,387],{"name":311,"slug":312,"type":16},{"name":314,"slug":315,"type":16},{"name":317,"slug":318,"type":16},{"slug":321,"name":321,"fn":322,"description":323,"org":389,"tags":390,"stars":26,"repoUrl":27,"updatedAt":333},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[391,392,393],{"name":327,"slug":328,"type":16},{"name":267,"slug":268,"type":16},{"name":331,"slug":332,"type":16},{"slug":335,"name":335,"fn":336,"description":337,"org":395,"tags":396,"stars":26,"repoUrl":27,"updatedAt":350},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[397,398,399,400,401,402],{"name":327,"slug":328,"type":16},{"name":342,"slug":343,"type":16},{"name":314,"slug":315,"type":16},{"name":270,"slug":271,"type":16},{"name":347,"slug":348,"type":16},{"name":21,"slug":22,"type":16},{"slug":352,"name":352,"fn":353,"description":354,"org":404,"tags":405,"stars":26,"repoUrl":27,"updatedAt":360},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[406,407,408],{"name":18,"slug":19,"type":16},{"name":270,"slug":271,"type":16},{"name":273,"slug":274,"type":16},{"slug":410,"name":410,"fn":411,"description":412,"org":413,"tags":414,"stars":26,"repoUrl":27,"updatedAt":417},"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},[415,416],{"name":270,"slug":271,"type":16},{"name":273,"slug":274,"type":16},"2026-07-16T06:03:03.397562",{"slug":419,"name":419,"fn":420,"description":421,"org":422,"tags":423,"stars":26,"repoUrl":27,"updatedAt":429},"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},[424,425,428],{"name":314,"slug":315,"type":16},{"name":426,"slug":427,"type":16},"Git","git",{"name":289,"slug":290,"type":16},"2026-07-16T06:03:07.255013",{"slug":431,"name":431,"fn":432,"description":433,"org":434,"tags":435,"stars":26,"repoUrl":27,"updatedAt":440},"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},[436,437,438,439],{"name":18,"slug":19,"type":16},{"name":270,"slug":271,"type":16},{"name":347,"slug":348,"type":16},{"name":21,"slug":22,"type":16},"2026-07-29T05:39:38.757423",{"slug":442,"name":442,"fn":443,"description":444,"org":445,"tags":446,"stars":26,"repoUrl":27,"updatedAt":453},"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},[447,450],{"name":448,"slug":449,"type":16},"Configuration","configuration",{"name":451,"slug":452,"type":16},"Local Development","local-development","2026-08-01T05:44:46.333988",{"slug":455,"name":455,"fn":456,"description":457,"org":458,"tags":459,"stars":26,"repoUrl":27,"updatedAt":464},"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},[460,461],{"name":327,"slug":328,"type":16},{"name":462,"slug":463,"type":16},"Documentation","documentation","2026-07-16T06:00:34.090082"]