[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C28BAS22GYF4Q7N3D71SHG":3,"skill-same:01M6C28BAS22GYF4Q7N3D71SHG":110},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":30,"publishedAt":58,"linkOnly":59,"markdownContent":60,"markdownBody":61,"frontMatter":62,"refName":69,"commitSha":70,"skillDirectory":71,"forksCount":72,"repositoryHtmlUrl":73,"repositoryHomepageUrl":6,"ownerHtmlUrl":74,"ownerBlogUrl":75,"ownerDescription":6,"updatedAt":76,"install":77,"resources":90},"01M6C28BAS22GYF4Q7N3D71SHG","pr-design-doc",null,"For a non-trivial pull request, write a self-contained HTML design doc under the temporary `.pr\u002F` directory and link a visibility-appropriate preview in the PR description, so maintainers grasp the proposal at a glance - code\u002FAPI design, and the before\u002Fafter of the change, grounded to real code. Use when opening or updating a non-trivial PR, or when the user says \"add a design doc\", \"document this PR for reviewers\", \"show the before\u002Fafter\", \"make the design reviewable\", or \"write the .pr\u002F page\".","OpenHands\u002Fsoftware-agent-sdk","OpenHands","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F225919603?v=4","01M6C27VE6SQ4X635GVG804BRN","01M6C27VJK3R57C2Z3AVJ03NQS",1387,"MIT","https:\u002F\u002Fgithub.com\u002FOpenHands\u002Fsoftware-agent-sdk\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fpr-design-doc\u002FSKILL.md",[17,22,25],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":26,"categoryName":27,"taxonomyType":28,"taxonomyTypeDesc":29},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57],"pr","doc","pr design doc","design doc","design","page","when","for","proposal","self","preview","glance","show","document","html","use","user","write","api","pull","pr description","code","api design","pull request","change","review","directory","2026-11-10 10:12:30",false,"---\nname: pr-design-doc\ndescription: >\n  For a non-trivial pull request, write a self-contained HTML design doc under the\n  temporary `.pr\u002F` directory and link a visibility-appropriate preview in the PR\n  description, so maintainers grasp the proposal at a glance - code\u002FAPI design, and the\n  before\u002Fafter of the change, grounded to real code. Use when opening or updating a\n  non-trivial PR, or when the user says \"add a design doc\", \"document this PR for\n  reviewers\", \"show the before\u002Fafter\", \"make the design reviewable\", or \"write the .pr\u002F\n  page\".\ntriggers:\n- \u002Fpr-design-doc\n- \u002Fdesign-doc\nlicense: MIT\nmetadata:\n  tags: pull-request, design-doc, html, review, before-after, htmlpreview\n---\n\n# pr-design-doc - a reviewable design doc for a non-trivial PR\n\nA diff shows *what changed line by line*. It does not show *the design*: the shape of the\nchange, the API before and after, and why this approach. Reviewers reconstruct that by\nhand, slowly. The scarce resource is the maintainer's attention and trust budget - not the\nagent's effort. Spend extra effort to hand them **one self-contained HTML page** that\nconveys the **big picture** and the **before → after core difference**, with every claim\n**clickable back to the real code**, then link it from the PR description.\n\nThis is the same craft as a \"show me this change\" explainer, aimed at one job: making a\nnon-trivial PR easy to review.\n\n## When to use it\n\n- Opening or updating a **non-trivial** PR: new\u002Fchanged public API, a new module or\n  subsystem, a behavior change in core logic, a migration, or anything a reviewer can't\n  fully judge from the diff in a couple of minutes.\n- **Skip it** for trivial PRs - a typo, a one-line guard, a dependency bump, a docs tweak, a simple bug fix.\n  A design doc adds more to review. Use judgment; if the diff *is* the explanation, don't add a\n  page.\n\n## The `.pr\u002F` workflow\n\nUse the temporary **`.pr\u002F`** directory for PR-only artifacts. Before relying on automatic\ncleanup, verify how the target repository removes `.pr\u002F` from `main`.\n\n- This repository: `.pr\u002F` stays on `main` after merge until the next release PR removes it\n  (`.github\u002Fworkflows\u002Fprepare-release.yml`). Do not open a separate cleanup PR.\n- Repository without verified cleanup automation: remove `.pr\u002F` manually before merge.\n\nThe design doc is a temporary review aid, not project documentation. Keep the essential\ndesign summary in the PR description: intent, important before\u002Fafter behavior or API shape, compatibility, risk,\nand code references. Use commit-pinned document links so cleanup does not break access.\n\n## Workflow\n\n1. **Check out and verify the PR head.** Do not write or commit the design doc from the base\n   branch or an unrelated checkout. Start with a clean worktree, then inspect and check out\n   the PR:\n   ```bash\n   gh pr view \u003Cn> --json title,body,url,baseRefName,baseRefOid,headRefName,headRefOid,headRepository,headRepositoryOwner,isCrossRepository,files,additions,deletions\n   gh pr checkout \u003Cn>\n   git rev-parse HEAD\n   gh pr view \u003Cn> --json headRefOid --jq .headRefOid\n   ```\n   The final two SHAs must match before you continue. If they do not, stop and fix the\n   checkout. Compute the merge-base SHA with\n   `git merge-base \u003CbaseRefOid> \u003CheadRefOid>`. Group changed files by area and keep both the\n   merge-base SHA and head SHA for source links.\n\n2. **Read both sides of each logical file.** Compare\n   `git show \u003Cmerge-base-sha>:\u003Cpath>` with the verified head. Capture the\n   **function-level** behavioral difference - what the code *did* vs *does now*.\n   - new file → no \"before\"; one \"after\" diagram + a line on the role it adds.\n   - deleted file → \"before\" diagram + who\u002Fwhat takes over.\n   - edited file → a before\u002Fafter pair, with the delta highlighted.\n\n3. **Classify each file.** *Logic* change (behavior moved) → draw before\u002Fafter. *Mechanical*\n   change (rename, constant, config, import move) → a one-line `before → after` row, no\n   diagram. Don't dilute the signal by drawing mechanical edits.\n\n4. **If the change is an API change, lead with the API.** Show the signature\u002Fschema\u002Ftype\n   **before and after** side by side (function signature, endpoint + payload, config field,\n   event shape). Name the compatibility impact plainly: additive, breaking, or behind a flag.\n\n5. **Find the cross-file story.** If one call chain threads several files, draw a single\n   **overview** before\u002Fafter at the top; per-file cards drill in.\n\n6. **Build the page** per [`references\u002Fhtml-craft.md`](references\u002Fhtml-craft.md) - one\n   self-contained, offline, editorial HTML file with hand-drawn SVG figures. Save it to\n   the repo's `.pr\u002F` directory, e.g. `.pr\u002Fdesign.html` (or `.pr\u002F\u003Ctopic>.html`). Before\n   writing, reject a symlink at `.pr` or at the exact output path; never follow a\n   branch-controlled symlink outside the worktree.\n   ```bash\n   test ! -L .pr && test ! -L .pr\u002Fdesign.html\n   mkdir -p .pr\n   ```\n\n7. **Commit under `.pr\u002F`, push to the verified PR head, and link it.** Confirm that the push\n   remote resolves to `headRepository.nameWithOwner`; never push the artifact to the base\n   repository's default branch.\n   ```bash\n   git add .pr\u002Fdesign.html\n   git commit -m \"docs(.pr): design doc for \u003CPR topic>\"\n   git push \u003Chead-repo-remote> HEAD:\u003CheadRefName>\n   git rev-parse HEAD\n   ```\n   Use the resulting full SHA as `\u003Cdoc-commit-sha>` in document links. Refresh the document\n   and its link when substantive changes affect the design; a cleanup-only commit does not\n   need a new link. Query the base repository's visibility before choosing the link:\n   ```bash\n   gh repo view \u003Cbase-owner>\u002F\u003Cbase-repo> --json visibility,url\n   ```\n   - **Public repository:** add an htmlpreview link near the top of the PR description,\n     pointing at the **PR head repository and commit containing the document**:\n     ```\n     ? Design doc: https:\u002F\u002Fhtmlpreview.github.io\u002F?https:\u002F\u002Fgithub.com\u002F\u003Cfork-owner>\u002F\u003Crepo>\u002Fblob\u002F\u003Cdoc-commit-sha>\u002F.pr\u002Fdesign.html\n     ```\n   - **Private or internal repository:** link the access-controlled GitHub blob at the same\n     document commit and include\n     local download\u002Fopen instructions, or use an existing access-controlled artifact\n     service. Never send the document through htmlpreview or another public host.\n\n## What the page contains\n\n1. **What changed (decision first)** - one paragraph: the intent, net effect, and why the\n   reviewer should care. Put the highest-impact conclusion, risk, or API-compat note in a\n   `★` callout, with the most important changed `path:line` nearby. Stats (`N files ·\n   +A \u002F −D`) are context, not the lead. If there's a cross-file flow, the **overview\n   before\u002Fafter SVG** goes here.\n2. **API before → after** (when the PR changes an interface) - signatures\u002Fschemas\u002Ftypes side\n   by side, with the compatibility verdict stated.\n3. **Left rail \u002F index** - changed files grouped by area, each tagged (? added · ? removed ·\n   ✏️ changed · ⚙️ mechanical) with +\u002F− counts; click to jump.\n4. **Per-file cards** - for each logical file: a claim-carrying title, a one-line summary of\n   how its behavior changed, **before\u002Fafter** diagrams with real symbol names + `file:line`\n   (changed nodes in orange), and the diff in a collapsed `\u003Cdetails>`. Mechanical files get a\n   small `before → after` table, no diagram.\n5. **(optional) Risk \u002F follow-ups** - only if grounded in what you read.\n\n## Non-negotiable principles\n\n1. **Optimize for scarce reviewer attention.** The first screen answers, in ~15 seconds:\n   what this PR does, whether it's risky, where to look first, and what evidence backs the\n   claim. Lead with the conclusion, not your process.\n2. **Show the difference, not just the after.** For any logic or API change, draw **before**\n   and **after** and make the *delta* visually loud (color + line style). The contrast is\n   the product.\n3. **Ground everything to code, beside the claim.** Every box, node, and sentence names a\n   real symbol + `path:line`, and links to the correct source revision where possible: the\n   merge-base SHA for before-state evidence and the verified head SHA for after-state\n   evidence. One click from \"this changed\" to the exact code.\n4. **Hand-draw the carrying diagrams.** Prefer bespoke inline SVG for the before\u002Fafter that\n   makes the argument; Mermaid is fine only for quick auxiliary graphs.\n5. **Self-contained & offline.** One HTML file, inline CSS\u002FSVG, no external scripts or\n   assets, opens by double-click, and survives being copied to another machine.\n6. **`.pr\u002F` only, and temporary.** The doc is a review aid, not project docs. Keep it in\n   `.pr\u002F` and rely on automatic cleanup only when the repository's mechanism has been\n   verified; otherwise remove it manually before merge. Do not move design HTML into\n   `docs\u002F` or keep it permanently on `main`.\n\n## Anti-patterns\n\n- ❌ Dumping the raw diff \u002F file tree and calling it a \"design doc\" - adds nothing over the\n  PR page.\n- ❌ Empty nodes (\"process data\", \"handle request\") - every node is a real symbol +\n  location.\n- ❌ Only the after-state when something changed - reviewers want the *contrast*.\n- ❌ A design doc on a trivial PR - noise. Skip it.\n- ❌ Committing the HTML outside `.pr\u002F` (e.g. `docs\u002F`), where it would merge into `main`.\n- ❌ Publishing a private-repository design doc through htmlpreview, GitHub Pages, or another\n  public host. Use the private\u002Flocal preview path in the craft reference. Use GitHub Pages\n  only with explicit user authorization after verifying private Pages access control.\n","# pr-design-doc - a reviewable design doc for a non-trivial PR\n\nA diff shows *what changed line by line*. It does not show *the design*: the shape of the\nchange, the API before and after, and why this approach. Reviewers reconstruct that by\nhand, slowly. The scarce resource is the maintainer's attention and trust budget - not the\nagent's effort. Spend extra effort to hand them **one self-contained HTML page** that\nconveys the **big picture** and the **before → after core difference**, with every claim\n**clickable back to the real code**, then link it from the PR description.\n\nThis is the same craft as a \"show me this change\" explainer, aimed at one job: making a\nnon-trivial PR easy to review.\n\n## When to use it\n\n- Opening or updating a **non-trivial** PR: new\u002Fchanged public API, a new module or\n  subsystem, a behavior change in core logic, a migration, or anything a reviewer can't\n  fully judge from the diff in a couple of minutes.\n- **Skip it** for trivial PRs - a typo, a one-line guard, a dependency bump, a docs tweak, a simple bug fix.\n  A design doc adds more to review. Use judgment; if the diff *is* the explanation, don't add a\n  page.\n\n## The `.pr\u002F` workflow\n\nUse the temporary **`.pr\u002F`** directory for PR-only artifacts. Before relying on automatic\ncleanup, verify how the target repository removes `.pr\u002F` from `main`.\n\n- This repository: `.pr\u002F` stays on `main` after merge until the next release PR removes it\n  (`.github\u002Fworkflows\u002Fprepare-release.yml`). Do not open a separate cleanup PR.\n- Repository without verified cleanup automation: remove `.pr\u002F` manually before merge.\n\nThe design doc is a temporary review aid, not project documentation. Keep the essential\ndesign summary in the PR description: intent, important before\u002Fafter behavior or API shape, compatibility, risk,\nand code references. Use commit-pinned document links so cleanup does not break access.\n\n## Workflow\n\n1. **Check out and verify the PR head.** Do not write or commit the design doc from the base\n   branch or an unrelated checkout. Start with a clean worktree, then inspect and check out\n   the PR:\n   ```bash\n   gh pr view \u003Cn> --json title,body,url,baseRefName,baseRefOid,headRefName,headRefOid,headRepository,headRepositoryOwner,isCrossRepository,files,additions,deletions\n   gh pr checkout \u003Cn>\n   git rev-parse HEAD\n   gh pr view \u003Cn> --json headRefOid --jq .headRefOid\n   ```\n   The final two SHAs must match before you continue. If they do not, stop and fix the\n   checkout. Compute the merge-base SHA with\n   `git merge-base \u003CbaseRefOid> \u003CheadRefOid>`. Group changed files by area and keep both the\n   merge-base SHA and head SHA for source links.\n\n2. **Read both sides of each logical file.** Compare\n   `git show \u003Cmerge-base-sha>:\u003Cpath>` with the verified head. Capture the\n   **function-level** behavioral difference - what the code *did* vs *does now*.\n   - new file → no \"before\"; one \"after\" diagram + a line on the role it adds.\n   - deleted file → \"before\" diagram + who\u002Fwhat takes over.\n   - edited file → a before\u002Fafter pair, with the delta highlighted.\n\n3. **Classify each file.** *Logic* change (behavior moved) → draw before\u002Fafter. *Mechanical*\n   change (rename, constant, config, import move) → a one-line `before → after` row, no\n   diagram. Don't dilute the signal by drawing mechanical edits.\n\n4. **If the change is an API change, lead with the API.** Show the signature\u002Fschema\u002Ftype\n   **before and after** side by side (function signature, endpoint + payload, config field,\n   event shape). Name the compatibility impact plainly: additive, breaking, or behind a flag.\n\n5. **Find the cross-file story.** If one call chain threads several files, draw a single\n   **overview** before\u002Fafter at the top; per-file cards drill in.\n\n6. **Build the page** per [`references\u002Fhtml-craft.md`](references\u002Fhtml-craft.md) - one\n   self-contained, offline, editorial HTML file with hand-drawn SVG figures. Save it to\n   the repo's `.pr\u002F` directory, e.g. `.pr\u002Fdesign.html` (or `.pr\u002F\u003Ctopic>.html`). Before\n   writing, reject a symlink at `.pr` or at the exact output path; never follow a\n   branch-controlled symlink outside the worktree.\n   ```bash\n   test ! -L .pr && test ! -L .pr\u002Fdesign.html\n   mkdir -p .pr\n   ```\n\n7. **Commit under `.pr\u002F`, push to the verified PR head, and link it.** Confirm that the push\n   remote resolves to `headRepository.nameWithOwner`; never push the artifact to the base\n   repository's default branch.\n   ```bash\n   git add .pr\u002Fdesign.html\n   git commit -m \"docs(.pr): design doc for \u003CPR topic>\"\n   git push \u003Chead-repo-remote> HEAD:\u003CheadRefName>\n   git rev-parse HEAD\n   ```\n   Use the resulting full SHA as `\u003Cdoc-commit-sha>` in document links. Refresh the document\n   and its link when substantive changes affect the design; a cleanup-only commit does not\n   need a new link. Query the base repository's visibility before choosing the link:\n   ```bash\n   gh repo view \u003Cbase-owner>\u002F\u003Cbase-repo> --json visibility,url\n   ```\n   - **Public repository:** add an htmlpreview link near the top of the PR description,\n     pointing at the **PR head repository and commit containing the document**:\n     ```\n     ? Design doc: https:\u002F\u002Fhtmlpreview.github.io\u002F?https:\u002F\u002Fgithub.com\u002F\u003Cfork-owner>\u002F\u003Crepo>\u002Fblob\u002F\u003Cdoc-commit-sha>\u002F.pr\u002Fdesign.html\n     ```\n   - **Private or internal repository:** link the access-controlled GitHub blob at the same\n     document commit and include\n     local download\u002Fopen instructions, or use an existing access-controlled artifact\n     service. Never send the document through htmlpreview or another public host.\n\n## What the page contains\n\n1. **What changed (decision first)** - one paragraph: the intent, net effect, and why the\n   reviewer should care. Put the highest-impact conclusion, risk, or API-compat note in a\n   `★` callout, with the most important changed `path:line` nearby. Stats (`N files ·\n   +A \u002F −D`) are context, not the lead. If there's a cross-file flow, the **overview\n   before\u002Fafter SVG** goes here.\n2. **API before → after** (when the PR changes an interface) - signatures\u002Fschemas\u002Ftypes side\n   by side, with the compatibility verdict stated.\n3. **Left rail \u002F index** - changed files grouped by area, each tagged (? added · ? removed ·\n   ✏️ changed · ⚙️ mechanical) with +\u002F− counts; click to jump.\n4. **Per-file cards** - for each logical file: a claim-carrying title, a one-line summary of\n   how its behavior changed, **before\u002Fafter** diagrams with real symbol names + `file:line`\n   (changed nodes in orange), and the diff in a collapsed `\u003Cdetails>`. Mechanical files get a\n   small `before → after` table, no diagram.\n5. **(optional) Risk \u002F follow-ups** - only if grounded in what you read.\n\n## Non-negotiable principles\n\n1. **Optimize for scarce reviewer attention.** The first screen answers, in ~15 seconds:\n   what this PR does, whether it's risky, where to look first, and what evidence backs the\n   claim. Lead with the conclusion, not your process.\n2. **Show the difference, not just the after.** For any logic or API change, draw **before**\n   and **after** and make the *delta* visually loud (color + line style). The contrast is\n   the product.\n3. **Ground everything to code, beside the claim.** Every box, node, and sentence names a\n   real symbol + `path:line`, and links to the correct source revision where possible: the\n   merge-base SHA for before-state evidence and the verified head SHA for after-state\n   evidence. One click from \"this changed\" to the exact code.\n4. **Hand-draw the carrying diagrams.** Prefer bespoke inline SVG for the before\u002Fafter that\n   makes the argument; Mermaid is fine only for quick auxiliary graphs.\n5. **Self-contained & offline.** One HTML file, inline CSS\u002FSVG, no external scripts or\n   assets, opens by double-click, and survives being copied to another machine.\n6. **`.pr\u002F` only, and temporary.** The doc is a review aid, not project docs. Keep it in\n   `.pr\u002F` and rely on automatic cleanup only when the repository's mechanism has been\n   verified; otherwise remove it manually before merge. Do not move design HTML into\n   `docs\u002F` or keep it permanently on `main`.\n\n## Anti-patterns\n\n- ❌ Dumping the raw diff \u002F file tree and calling it a \"design doc\" - adds nothing over the\n  PR page.\n- ❌ Empty nodes (\"process data\", \"handle request\") - every node is a real symbol +\n  location.\n- ❌ Only the after-state when something changed - reviewers want the *contrast*.\n- ❌ A design doc on a trivial PR - noise. Skip it.\n- ❌ Committing the HTML outside `.pr\u002F` (e.g. `docs\u002F`), where it would merge into `main`.\n- ❌ Publishing a private-repository design doc through htmlpreview, GitHub Pages, or another\n  public host. Use the private\u002Flocal preview path in the craft reference. Use GitHub Pages\n  only with explicit user authorization after verifying private Pages access control.\n",{"name":5,"license":14,"metadata":63,"triggers":65,"description":68},{"tags":64},"pull-request, design-doc, html, review, before-after, htmlpreview",[66,67],"\u002Fpr-design-doc","\u002Fdesign-doc","For a non-trivial pull request, write a self-contained HTML design doc under the temporary `.pr\u002F` directory and link a visibility-appropriate preview in the PR description, so maintainers grasp the proposal at a glance - code\u002FAPI design, and the before\u002Fafter of the change, grounded to real code. Use when opening or updating a non-trivial PR, or when the user says \"add a design doc\", \"document this PR for reviewers\", \"show the before\u002Fafter\", \"make the design reviewable\", or \"write the .pr\u002F page\".\n","main","98849457621881ae2414719b82b8bc1cf535b4ab",".agents\u002Fskills\u002Fpr-design-doc",775,"https:\u002F\u002Fgithub.com\u002FOpenHands\u002Fsoftware-agent-sdk","https:\u002F\u002Fgithub.com\u002FOpenHands","https:\u002F\u002Fopenhands.dev","2026-11-13 03:27:46",{"source":8,"skillName":5,"commands":78,"prompt":88,"zipAvailable":89},[79,82,85],{"tool":80,"command":81},"npx","npx skills add OpenHands\u002Fsoftware-agent-sdk --skill pr-design-doc",{"tool":83,"command":84},"bunx","bunx skills add OpenHands\u002Fsoftware-agent-sdk --skill pr-design-doc",{"tool":86,"command":87},"pnpm","pnpm dlx skills add OpenHands\u002Fsoftware-agent-sdk --skill pr-design-doc","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FOpenHands\u002Fsoftware-agent-sdk\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fpr-design-doc\u002FSKILL.md",true,[91,97,103,106],{"path":92,"resourceType":93,"resourceTypeDesc":94,"sizeBytes":95,"sourceHtmlUrl":96},"_sudowork_meta.json","REFERENCE","参考文档",985,"https:\u002F\u002Fgithub.com\u002Fsudoprivacy\u002Fsudowork\u002Fblob\u002Fdev\u002Fapps\u002Fdesktop\u002Fskills\u002F_builtin\u002Fcron\u002F_sudowork_meta.json",{"path":98,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":101,"sourceHtmlUrl":102},"icon_test.svg","ASSET","资产文件",296,"https:\u002F\u002Fgithub.com\u002Fsudoprivacy\u002Fsudowork\u002Fblob\u002Fdev\u002Fapps\u002Fdesktop\u002Fskills\u002F_builtin\u002Fcron\u002Ficon_test.svg",{"path":104,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":101,"sourceHtmlUrl":105},"icon.svg","https:\u002F\u002Fgithub.com\u002Fsudoprivacy\u002Fsudowork\u002Fblob\u002Fdev\u002Fapps\u002Fdesktop\u002Fskills\u002F_builtin\u002Fcron\u002Ficon.svg",{"path":107,"resourceType":93,"resourceTypeDesc":94,"sizeBytes":108,"sourceHtmlUrl":109},"references\u002Fhtml-craft.md",19793,"https:\u002F\u002Fgithub.com\u002FOpenHands\u002Fsoftware-agent-sdk\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fpr-design-doc\u002Freferences\u002Fhtml-craft.md",[111,139,149,158,167,172],{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":120,"publishedAt":58},"01M70N7TM3VRT2YVJWMFJB93R4","verify-sdk","This skill should be used to \"verify SDK behavior\", \"check an SDK change against the feature map\", \"run the SDK feature map\", \"maintain the SDK feature map\", or \"run the daily SDK map pass\". It holds the maintained map of what the OpenHands SDK does in-process (agent loop, LLMs, conversations, events, condensers, skills, plugins, MCP, hooks, sub-agents, critic, security, tools, workspaces, settings, observability, ACP), the control-sdk driver its recipes use, and sdk-map (check, owners, baseline, run, report).","https:\u002F\u002Fgithub.com\u002FOpenHands\u002Fsoftware-agent-sdk\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fverify-sdk\u002FSKILL.md",[117],{"categoryNo":118,"categoryName":119,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",[121,122,123,124,125,126,127,128,129,130,131,132,46,133,134,135,136,55,137,138],"verify sdk","verify","sdk","critic","conversations","feature","control","map","maintain","workspaces","daily","hooks","check","openhands","loop","observability","llms","MCP",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":145,"publishedAt":58},"01M6C29EG7KM3YYQK1TX747Q0X","only","The one component in a fixed location this format discovers.","https:\u002F\u002Fgithub.com\u002FOpenHands\u002Fsoftware-agent-sdk\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fplugins\u002Fagent_plugins\u002Fwrong-locations\u002Fskills\u002Fonly\u002FSKILL.md",[],[141,146,147,148],"location","format","component",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":155,"publishedAt":58},"01M6C29D0ZE9EAD0B72S5C7TYC","never","Must never be discovered; the manifest is rejected first.","https:\u002F\u002Fgithub.com\u002FOpenHands\u002Fsoftware-agent-sdk\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fplugins\u002Fagent_plugins\u002Funsupported-schema\u002Fskills\u002Fnever\u002FSKILL.md",[],[151,156,157],"first","manifest",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":164,"publishedAt":58},"01M6C29BSP5CJZ6T7A2HM18C35","good","Loads while its broken sibling is skipped.","https:\u002F\u002Fgithub.com\u002FOpenHands\u002Fsoftware-agent-sdk\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fplugins\u002Fagent_plugins\u002Fpartial-failures\u002Fskills\u002Fgood\u002FSKILL.md",[],[160,165,166],"loads","broken",{"skillNo":168,"name":166,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"publishedAt":58},"01M6C29ADJKMKDVYG57TSAZV7J","https:\u002F\u002Fgithub.com\u002FOpenHands\u002Fsoftware-agent-sdk\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fplugins\u002Fagent_plugins\u002Fpartial-failures\u002Fskills\u002Fbroken\u002FSKILL.md",[],[166],{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":178,"publishedAt":58},"01M6C2996Q7PX47VFV5P4KJ5F8","ok","Loads despite the two non-fatal manifest violations.","https:\u002F\u002Fgithub.com\u002FOpenHands\u002Fsoftware-agent-sdk\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fplugins\u002Fagent_plugins\u002Fnon-fatal-manifest\u002Fskills\u002Fok\u002FSKILL.md",[],[174,157,165]]