[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BXEHSMEV2Z1M75WGPZX0BV":3,"skill-same:01M6BXEHSMEV2Z1M75WGPZX0BV":82},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":32,"linkOnly":33,"markdownContent":34,"markdownBody":35,"frontMatter":36,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":49,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M6BXEHSMEV2Z1M75WGPZX0BV","bug-triage",null,"Triages one bug against the real codebase and renders a self-contained light-theme HTML report in a temp folder covering what the bug is, the files involved, a test that reproduces it, why it is bad, the minimal fix, the files to touch, whether it breaks the DB or a public contract, and whether the fix is safe. Use when the user runs \u002Fbug-triage or asks to triage, diagnose, investigate, or root-cause a bug from a branch, a Jira or Linear issue, a GitHub issue, a bug id, or a plain description.","diegopacheco\u002Fai-playground","diegopacheco","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F121278?v=4","01M6BXCP8P7GGSJ8M1W2MFDTGT","Diego Pacheco","01M6BXCPD3WM51H465XW9YM4BV",21,"Unlicense","https:\u002F\u002Fgithub.com\u002Fdiegopacheco\u002Fai-playground\u002Fblob\u002Fmain\u002Fpocs\u002Fagent-skill-bug-triage\u002Fskill\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31],"triage","bug triage","safe","github","test","diagnose","jira","report","linear","investigate","why","Bash","html report","2026-11-10 10:12:30",false,"---\nname: bug-triage\ndescription: Triages one bug against the real codebase and renders a self-contained light-theme HTML report in a temp folder covering what the bug is, the files involved, a test that reproduces it, why it is bad, the minimal fix, the files to touch, whether it breaks the DB or a public contract, and whether the fix is safe. Use when the user runs \u002Fbug-triage or asks to triage, diagnose, investigate, or root-cause a bug from a branch, a Jira or Linear issue, a GitHub issue, a bug id, or a plain description.\nallowed-tools: [Bash, Read, Grep, Glob, WebFetch, AskUserQuestion]\n---\n\n# Bug Triage\n\nWhen invoked, you take one bug from whatever the user gives you, read the actual code to find its cause, and write a light-theme report to a temp folder. Every claim in the report comes from a file you read. You do not fix the bug — you triage it.\n\n## Global Context\n- User request \u002F scope: $ARGUMENTS — empty, a branch name, a repo or PR URL, an issue URL, a Jira\u002FLinear\u002FGitHub issue id, or a plain description of the bug\n- Checkout: `scripts\u002Fcheckout.sh` (puts a repo, a PR, or another branch in a temp folder — never touches the working tree)\n- Renderer: `scripts\u002Frender.mjs` (Node, no dependencies)\n- Template: `assets\u002Ftemplate.html`\n- Output: `$TMPDIR\u002Fbug-triage-\u003Cslug>-\u003Ctimestamp>\u002Findex.html` plus the `triage.json` it was rendered from\n- Source read: the repo you are in, or `$TMPDIR\u002Fbug-triage-src-\u003Cslug>\u002F` when the bug came from a repo, a PR, or a branch you are not on\n\n## Rules\n- Read the code before you write anything. Never describe a file you have not opened.\n- Every file path in the report is absolute.\n- The reproduction test must run against the real code as it is today and fail because of this bug. No pseudo-code.\n- The fix is the smallest change that removes the cause. No refactors, no cleanups, no adjacent improvements.\n- If you cannot find the cause, say so in the report instead of guessing. A wrong triage costs more than an honest gap.\n- Do not modify the project. Everything you write goes under `$TMPDIR` — the report folder, the working `triage.json`, and any scratch copy of the test. The repo being triaged gains no files.\n- Do not add comments to any command or file you produce.\n\n## Step 1 — Work out what the bug is\nRead `$ARGUMENTS` and pick the case:\n\n- **Empty** — triage the branch you are on. Run `git status -sb`, `git log --oneline -15`, and `git diff main...HEAD` to find what changed, then ask the user which bug they mean if the branch shows more than one candidate.\n- **A branch name** — check it out into a temp folder (Step 1b), then `git diff main...\u003Cbranch>` and `git log --oneline main..\u003Cbranch>` to read what that branch changed.\n- **A repo URL or a GitHub PR URL** — clone it into a temp folder (Step 1b). For a PR, `git diff origin\u002FHEAD...HEAD` in that folder is what the PR changed.\n- **A Jira \u002F Linear \u002F GitHub issue URL** — fetch it with WebFetch and pull out the title, the description, and the reproduction steps. If the fetch is blocked by a login, say so in one line and ask the user to paste the bug text. Keep the URL either way — it goes in the report as `bug.url`. If the issue names a repo or a PR you do not have locally, take that url through Step 1b too.\n- **A bug id with no URL** (`PROJ-1234`, `ENG-88`) — search the repo for it (`git log --grep`, `grep -r`) and ask the user for the link or the description if nothing turns up.\n- **A plain description** — that is the bug. Use it as written, against the repo you are in.\n\n## Step 1b — Put the source in a temp folder\nOnly when the code you need is not the working tree you are standing in:\n\n```bash\n\"$HOME\u002F.claude\u002Fskills\u002Fbug-triage\u002Fscripts\u002Fcheckout.sh\" \u003Crepo url | pr url | branch>\n```\n\nIt prints `CHECKOUT \u003Cpath>` and the head commit. A branch becomes a detached `git worktree` under `$TMPDIR`, so the user's checked-out branch and uncommitted work are never touched. A repo or PR url becomes a shallow clone under `$TMPDIR`; a PR is fetched as `pull\u002F\u003Cn>\u002Fhead`. It exits 1 with a plain message when the url is unreachable or the branch does not exist — relay that instead of triaging the wrong tree.\n\nRead the code from the printed path, and use that path in `files` and `files_to_touch` so every path in the report is the one you actually read. Say in `solution.notes` that the paths are a temp checkout of `\u003Cref>` when they are.\n\n`checkout.sh --clean` prunes the worktrees and deletes every `bug-triage-src-*` folder. Run it when the user asks, not on your own — the report points at those paths.\n\n## Step 2 — Find the cause in the code\nSearch the codebase for the symptom: the error text, the endpoint, the function, the field. Follow the call path from the entry point to the line that is actually wrong. Read the tests around it — an existing test that passes while the bug is live tells you what the code believes it is doing.\n\nYou need to end this step with: the exact file and line where the behavior goes wrong, and the reason it goes wrong.\n\n## Step 3 — Write the reproduction test\nWrite a test in the project's own test framework (read `package.json`, `pom.xml`, `build.gradle`, `pyproject.toml`, `Cargo.toml` to find it). It must call the real code and fail today for this bug. Run it if you can, and use the real failure output as `repro.expectation`.\n\n## Step 4 — Build the triage json\nWrite `triage.json` under `$TMPDIR`, never inside the repo. Shape:\n\n```json\n{\n  \"bug\": {\n    \"name\": \"short factual title\",\n    \"id\": \"PROJ-1234\",\n    \"url\": \"https:\u002F\u002Fcompany.atlassian.net\u002Fbrowse\u002FPROJ-1234\",\n    \"tracker\": \"Jira\",\n    \"severity\": \"critical|high|medium|low\",\n    \"branch\": \"fix\u002Fcheckout-total\",\n    \"repo\": \"name of the repo\"\n  },\n  \"description\": [\"line 1\", \"line 2\", \"line 3\"],\n  \"files\": [{ \"path\": \"\u002Fabs\u002Fpath\u002FFile.java\", \"lines\": \"88-104\", \"role\": \"one line on why it is involved\" }],\n  \"repro\": {\n    \"path\": \"\u002Fabs\u002Fpath\u002Fto\u002Ftest file\",\n    \"run\": \"npm test -- cart.test.js\",\n    \"language\": \"javascript\",\n    \"start_line\": 1,\n    \"code\": \"the full test\",\n    \"expectation\": \"the failure it produces today\"\n  },\n  \"why_bad\": [\"impact on users\", \"impact on data\", \"impact on the team\"],\n  \"solution\": {\n    \"summary\": \"the smallest change that removes the cause\",\n    \"language\": \"diff\",\n    \"code\": \"unified diff or the replacement lines\",\n    \"notes\": [\"what you deliberately did not change\"]\n  },\n  \"files_to_touch\": [{ \"path\": \"\u002Fabs\u002Fpath\u002FFile.java\", \"change\": \"what changes there\" }],\n  \"breaking\": {\n    \"verdict\": \"No | Yes | Yes, for consumers of X\",\n    \"db\": false,\n    \"api\": false,\n    \"consumers\": false,\n    \"detail\": \"why, in plain words\"\n  },\n  \"safety\": {\n    \"verdict\": \"Safe | Safe with a caveat | Risky\",\n    \"detail\": \"why\",\n    \"risks\": [\"what could still go wrong\"],\n    \"verification\": [\"how to prove the fix worked\"]\n  }\n}\n```\n\nField rules:\n- `description` — 3 to 5 short lines, direct-skill style. First line says what breaks. No metaphors, no filler, no restating the title.\n- `files` — every file involved, full absolute path, with the line range when you know it.\n- `why_bad` — real consequences you can point at: wrong money, lost data, a 500, a security hole, a silent corruption. Not \"it is bad practice\".\n- `breaking` — set `db` true only for a schema or migration change, `api` true only for a change to a public endpoint, payload, or exported signature, `consumers` true only when a caller outside this repo has to change.\n- `safety` — \"Safe\" means: no schema change, no contract change, covered by the reproduction test, and reversible by a revert. Anything else is a caveat you name.\n- Leave `url` out when there is no tracker link. The report then shows the bug description as the source.\n\n## Step 5 — Render\n```bash\nnode \"$HOME\u002F.claude\u002Fskills\u002Fbug-triage\u002Fscripts\u002Frender.mjs\" \u003Ctriage.json>\n```\n\nIt validates the required fields, writes `index.html` and `triage.json` into a fresh `$TMPDIR\u002Fbug-triage-\u003Cslug>-\u003Ctimestamp>\u002F`, and prints `REPORT \u003Cpath>`. The folder is not configurable — the report never lands in the repo being triaged, and triage never leaves a file behind for the user to delete. Write your working `triage.json` to a temp path too. If the renderer exits with a missing-field error, fill the field in and run it again — never edit the HTML by hand.\n\n## Step 6 — Report back\nGive the user, in plain words: what the bug is, where it is (absolute path and line), the one-line fix, whether anything breaks, and whether it is safe. Then the report path exactly as the renderer printed it, and offer to open it:\n\n```bash\nopen \u003Cpath>\u002Findex.html\n```\n","# Bug Triage\n\nWhen invoked, you take one bug from whatever the user gives you, read the actual code to find its cause, and write a light-theme report to a temp folder. Every claim in the report comes from a file you read. You do not fix the bug — you triage it.\n\n## Global Context\n- User request \u002F scope: $ARGUMENTS — empty, a branch name, a repo or PR URL, an issue URL, a Jira\u002FLinear\u002FGitHub issue id, or a plain description of the bug\n- Checkout: `scripts\u002Fcheckout.sh` (puts a repo, a PR, or another branch in a temp folder — never touches the working tree)\n- Renderer: `scripts\u002Frender.mjs` (Node, no dependencies)\n- Template: `assets\u002Ftemplate.html`\n- Output: `$TMPDIR\u002Fbug-triage-\u003Cslug>-\u003Ctimestamp>\u002Findex.html` plus the `triage.json` it was rendered from\n- Source read: the repo you are in, or `$TMPDIR\u002Fbug-triage-src-\u003Cslug>\u002F` when the bug came from a repo, a PR, or a branch you are not on\n\n## Rules\n- Read the code before you write anything. Never describe a file you have not opened.\n- Every file path in the report is absolute.\n- The reproduction test must run against the real code as it is today and fail because of this bug. No pseudo-code.\n- The fix is the smallest change that removes the cause. No refactors, no cleanups, no adjacent improvements.\n- If you cannot find the cause, say so in the report instead of guessing. A wrong triage costs more than an honest gap.\n- Do not modify the project. Everything you write goes under `$TMPDIR` — the report folder, the working `triage.json`, and any scratch copy of the test. The repo being triaged gains no files.\n- Do not add comments to any command or file you produce.\n\n## Step 1 — Work out what the bug is\nRead `$ARGUMENTS` and pick the case:\n\n- **Empty** — triage the branch you are on. Run `git status -sb`, `git log --oneline -15`, and `git diff main...HEAD` to find what changed, then ask the user which bug they mean if the branch shows more than one candidate.\n- **A branch name** — check it out into a temp folder (Step 1b), then `git diff main...\u003Cbranch>` and `git log --oneline main..\u003Cbranch>` to read what that branch changed.\n- **A repo URL or a GitHub PR URL** — clone it into a temp folder (Step 1b). For a PR, `git diff origin\u002FHEAD...HEAD` in that folder is what the PR changed.\n- **A Jira \u002F Linear \u002F GitHub issue URL** — fetch it with WebFetch and pull out the title, the description, and the reproduction steps. If the fetch is blocked by a login, say so in one line and ask the user to paste the bug text. Keep the URL either way — it goes in the report as `bug.url`. If the issue names a repo or a PR you do not have locally, take that url through Step 1b too.\n- **A bug id with no URL** (`PROJ-1234`, `ENG-88`) — search the repo for it (`git log --grep`, `grep -r`) and ask the user for the link or the description if nothing turns up.\n- **A plain description** — that is the bug. Use it as written, against the repo you are in.\n\n## Step 1b — Put the source in a temp folder\nOnly when the code you need is not the working tree you are standing in:\n\n```bash\n\"$HOME\u002F.claude\u002Fskills\u002Fbug-triage\u002Fscripts\u002Fcheckout.sh\" \u003Crepo url | pr url | branch>\n```\n\nIt prints `CHECKOUT \u003Cpath>` and the head commit. A branch becomes a detached `git worktree` under `$TMPDIR`, so the user's checked-out branch and uncommitted work are never touched. A repo or PR url becomes a shallow clone under `$TMPDIR`; a PR is fetched as `pull\u002F\u003Cn>\u002Fhead`. It exits 1 with a plain message when the url is unreachable or the branch does not exist — relay that instead of triaging the wrong tree.\n\nRead the code from the printed path, and use that path in `files` and `files_to_touch` so every path in the report is the one you actually read. Say in `solution.notes` that the paths are a temp checkout of `\u003Cref>` when they are.\n\n`checkout.sh --clean` prunes the worktrees and deletes every `bug-triage-src-*` folder. Run it when the user asks, not on your own — the report points at those paths.\n\n## Step 2 — Find the cause in the code\nSearch the codebase for the symptom: the error text, the endpoint, the function, the field. Follow the call path from the entry point to the line that is actually wrong. Read the tests around it — an existing test that passes while the bug is live tells you what the code believes it is doing.\n\nYou need to end this step with: the exact file and line where the behavior goes wrong, and the reason it goes wrong.\n\n## Step 3 — Write the reproduction test\nWrite a test in the project's own test framework (read `package.json`, `pom.xml`, `build.gradle`, `pyproject.toml`, `Cargo.toml` to find it). It must call the real code and fail today for this bug. Run it if you can, and use the real failure output as `repro.expectation`.\n\n## Step 4 — Build the triage json\nWrite `triage.json` under `$TMPDIR`, never inside the repo. Shape:\n\n```json\n{\n  \"bug\": {\n    \"name\": \"short factual title\",\n    \"id\": \"PROJ-1234\",\n    \"url\": \"https:\u002F\u002Fcompany.atlassian.net\u002Fbrowse\u002FPROJ-1234\",\n    \"tracker\": \"Jira\",\n    \"severity\": \"critical|high|medium|low\",\n    \"branch\": \"fix\u002Fcheckout-total\",\n    \"repo\": \"name of the repo\"\n  },\n  \"description\": [\"line 1\", \"line 2\", \"line 3\"],\n  \"files\": [{ \"path\": \"\u002Fabs\u002Fpath\u002FFile.java\", \"lines\": \"88-104\", \"role\": \"one line on why it is involved\" }],\n  \"repro\": {\n    \"path\": \"\u002Fabs\u002Fpath\u002Fto\u002Ftest file\",\n    \"run\": \"npm test -- cart.test.js\",\n    \"language\": \"javascript\",\n    \"start_line\": 1,\n    \"code\": \"the full test\",\n    \"expectation\": \"the failure it produces today\"\n  },\n  \"why_bad\": [\"impact on users\", \"impact on data\", \"impact on the team\"],\n  \"solution\": {\n    \"summary\": \"the smallest change that removes the cause\",\n    \"language\": \"diff\",\n    \"code\": \"unified diff or the replacement lines\",\n    \"notes\": [\"what you deliberately did not change\"]\n  },\n  \"files_to_touch\": [{ \"path\": \"\u002Fabs\u002Fpath\u002FFile.java\", \"change\": \"what changes there\" }],\n  \"breaking\": {\n    \"verdict\": \"No | Yes | Yes, for consumers of X\",\n    \"db\": false,\n    \"api\": false,\n    \"consumers\": false,\n    \"detail\": \"why, in plain words\"\n  },\n  \"safety\": {\n    \"verdict\": \"Safe | Safe with a caveat | Risky\",\n    \"detail\": \"why\",\n    \"risks\": [\"what could still go wrong\"],\n    \"verification\": [\"how to prove the fix worked\"]\n  }\n}\n```\n\nField rules:\n- `description` — 3 to 5 short lines, direct-skill style. First line says what breaks. No metaphors, no filler, no restating the title.\n- `files` — every file involved, full absolute path, with the line range when you know it.\n- `why_bad` — real consequences you can point at: wrong money, lost data, a 500, a security hole, a silent corruption. Not \"it is bad practice\".\n- `breaking` — set `db` true only for a schema or migration change, `api` true only for a change to a public endpoint, payload, or exported signature, `consumers` true only when a caller outside this repo has to change.\n- `safety` — \"Safe\" means: no schema change, no contract change, covered by the reproduction test, and reversible by a revert. Anything else is a caveat you name.\n- Leave `url` out when there is no tracker link. The report then shows the bug description as the source.\n\n## Step 5 — Render\n```bash\nnode \"$HOME\u002F.claude\u002Fskills\u002Fbug-triage\u002Fscripts\u002Frender.mjs\" \u003Ctriage.json>\n```\n\nIt validates the required fields, writes `index.html` and `triage.json` into a fresh `$TMPDIR\u002Fbug-triage-\u003Cslug>-\u003Ctimestamp>\u002F`, and prints `REPORT \u003Cpath>`. The folder is not configurable — the report never lands in the repo being triaged, and triage never leaves a file behind for the user to delete. Write your working `triage.json` to a temp path too. If the renderer exits with a missing-field error, fill the field in and run it again — never edit the HTML by hand.\n\n## Step 6 — Report back\nGive the user, in plain words: what the bug is, where it is (absolute path and line), the one-line fix, whether anything breaks, and whether it is safe. Then the report path exactly as the renderer printed it, and offer to open it:\n\n```bash\nopen \u003Cpath>\u002Findex.html\n```\n",{"name":5,"description":7,"allowed-tools":37},[30,38,39,40,41,42],"Read","Grep","Glob","WebFetch","AskUserQuestion","main","90d379e95fcc23dd9759654c345424e1752b0f3a","pocs\u002Fagent-skill-bug-triage\u002Fskill",9,"https:\u002F\u002Fgithub.com\u002Fdiegopacheco\u002Fai-playground","https:\u002F\u002Fgithub.com\u002Fdiegopacheco","http:\u002F\u002Fdiego-pacheco.blogspot.com","Brazilian Hands-on Software Architect | 20+ years in Tech | Author | Father. Opinions are my own!","2026-11-07 09:01:46",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add diegopacheco\u002Fai-playground --skill bug-triage",{"tool":58,"command":59},"bunx","bunx skills add diegopacheco\u002Fai-playground --skill bug-triage",{"tool":61,"command":62},"pnpm","pnpm dlx skills add diegopacheco\u002Fai-playground --skill bug-triage","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdiegopacheco\u002Fai-playground\u002Fblob\u002Fmain\u002Fpocs\u002Fagent-skill-bug-triage\u002Fskill\u002FSKILL.md",true,[66,72,78],{"path":67,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":70,"sourceHtmlUrl":71},"assets\u002Ftemplate.html","ASSET","资产文件",7765,"https:\u002F\u002Fgithub.com\u002Fdiegopacheco\u002Fai-playground\u002Fblob\u002Fmain\u002Fpocs\u002Fagent-skill-bug-triage\u002Fskill\u002Fassets\u002Ftemplate.html",{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"scripts\u002Fcheckout.sh","SCRIPT","脚本",2768,"https:\u002F\u002Fgithub.com\u002Fdiegopacheco\u002Fai-playground\u002Fblob\u002Fmain\u002Fpocs\u002Fagent-skill-bug-triage\u002Fskill\u002Fscripts\u002Fcheckout.sh",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"scripts\u002Frender.mjs",8850,"https:\u002F\u002Fgithub.com\u002Fdiegopacheco\u002Fai-playground\u002Fblob\u002Fmain\u002Fpocs\u002Fagent-skill-bug-triage\u002Fskill\u002Fscripts\u002Frender.mjs",[83,101,111,124,140,158],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":94,"publishedAt":32},"01M6WJ537DN520XY8MSW9ZV0RP","word-count","Counts the words, lines and characters of a text or a file.","https:\u002F\u002Fgithub.com\u002Fdiegopacheco\u002Fai-playground\u002Fblob\u002Fmain\u002Fpocs\u002Fskills-gateway-router\u002Fupstream-skills\u002Ftext-skills\u002Fword-count\u002FSKILL.md",[89],{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",[95,96,97,98,99,100],"count","word count","Word","characters","text","file",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":107,"publishedAt":32},"01M6WJ4Y2GT5SECWAKKYHGES4F","slugify","Turns a title or a sentence into a URL slug, lowercase words joined by hyphens with accents removed.","https:\u002F\u002Fgithub.com\u002Fdiegopacheco\u002Fai-playground\u002Fblob\u002Fmain\u002Fpocs\u002Fskills-gateway-router\u002Fupstream-skills\u002Ftext-skills\u002Fslugify\u002FSKILL.md",[],[103,108,109,110],"title","with","URL",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":32},"01M6WJ4V9CWHT9NVCD441VK5MH","json-format","Validates a JSON file and pretty prints it with two space indentation, or reports where the JSON is invalid.","https:\u002F\u002Fgithub.com\u002Fdiegopacheco\u002Fai-playground\u002Fblob\u002Fmain\u002Fpocs\u002Fskills-gateway-router\u002Fupstream-skills\u002Fdev-skills\u002Fjson-format\u002FSKILL.md",[],[118,119,120,100,121,122,123,109],"json","format","json format","reports","invalid","it",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":32},"01M6WJ4QMRKW8EFP71F4KS2DHE","commit-message","Writes a conventional commit message for the staged git changes.","https:\u002F\u002Fgithub.com\u002Fdiegopacheco\u002Fai-playground\u002Fblob\u002Fmain\u002Fpocs\u002Fskills-gateway-router\u002Fupstream-skills\u002Fdev-skills\u002Fcommit-message\u002FSKILL.md",[],[131,132,133,134,135,136,137,138,139],"commit","commit message","message","git","conventional commit","for","changes","staged","conventional commit message",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":146,"publishedAt":32},"01M6WJ4MAM2CJH0GWYXFBB9GQC","skills-gateway","Gateway and router to a catalog of skills that are not registered directly. Use it before any task a specialized skill could handle, such as text, JSON or git chores. It finds the right skill and loads its instructions.","https:\u002F\u002Fgithub.com\u002Fdiegopacheco\u002Fai-playground\u002Fblob\u002Fmain\u002Fpocs\u002Fskills-gateway-router\u002F.claude\u002Fskills\u002Fskills-gateway\u002FSKILL.md",[],[147,148,123,149,150,134,30,118,99,151,152,153,154,155,156,157],"skills gateway","gateway","task","loads","node","specialized","instructions","catalog","use","router","as",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":164,"publishedAt":32},"01M6M2PYJJQKMWGX7XT7ZJK0H3","decision-log","Record, list, show and supersede architecture decisions that persist across sessions in the shared agent infra state store. Use when the user says \"record this decision\", \"log an ADR\", \"what did we decide about\", \"list decisions\", or \"supersede decision\".","https:\u002F\u002Fgithub.com\u002Fdiegopacheco\u002Fai-playground\u002Fblob\u002Fmain\u002Fpocs\u002Fagent-skills-infra-poc\u002Fskills\u002Fdecision-log\u002FSKILL.md",[],[165,166,167,168,169,170,171,172,173,174,155,175,176,177,178,179,180,181,182,183],"decision log","log","decision","persist","architecture","state","adr","decide","decisions","list","show","infra","record","across","shared","store","about","supersede","sessions"]