[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DTPQPMC15P230FTTSB46AW":3,"skill-same:01M6DTPQPMC15P230FTTSB46AW":83},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":30,"linkOnly":31,"markdownContent":32,"markdownBody":33,"frontMatter":34,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":49,"install":50,"resources":63},"01M6DTPQPMC15P230FTTSB46AW","cron",null,"Scheduled task management - create, query, delete scheduled tasks to automatically execute operations at specified times.","sudoprivacy\u002Fsudowork","sudoprivacy","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F115790070?v=4","01M6DTPA1KMM1JSSJBNE9FGG5Q","01M6DTPA5PQ2F3S9CVXH1TQ4RT",10,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fsudoprivacy\u002Fsudowork\u002Fblob\u002Fdev\u002Fapps\u002Fdesktop\u002Fskills\u002F_builtin\u002Fcron\u002FSKILL.md",[],[5,18,19,20,21,22,23,24,25,26,27,28,29],"tasks","create","delete","task management","management","execute","operations","task","query","scheduled","at","scheduled tasks","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":35,"license":36,"metadata":37,"triggers":39,"description":42},"pr-design-doc","MIT",{"tags":38},"pull-request, design-doc, html, review, before-after, htmlpreview",[40,41],"\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","apps\u002Fdesktop\u002Fskills\u002F_builtin\u002Fcron",2,"https:\u002F\u002Fgithub.com\u002Fsudoprivacy\u002Fsudowork","https:\u002F\u002Fgithub.com\u002Fsudoprivacy","2026-11-11 10:56:31",{"source":8,"skillName":35,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add sudoprivacy\u002Fsudowork --skill pr-design-doc",{"tool":56,"command":57},"bunx","bunx skills add sudoprivacy\u002Fsudowork --skill pr-design-doc",{"tool":59,"command":60},"pnpm","pnpm dlx skills add sudoprivacy\u002Fsudowork --skill pr-design-doc","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fsudoprivacy\u002Fsudowork\u002Fblob\u002Fdev\u002Fapps\u002Fdesktop\u002Fskills\u002F_builtin\u002Fcron\u002FSKILL.md",true,[64,70,76,79],{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"_sudowork_meta.json","REFERENCE","参考文档",985,"https:\u002F\u002Fgithub.com\u002Fsudoprivacy\u002Fsudowork\u002Fblob\u002Fdev\u002Fapps\u002Fdesktop\u002Fskills\u002F_builtin\u002Fcron\u002F_sudowork_meta.json",{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"icon_test.svg","ASSET","资产文件",296,"https:\u002F\u002Fgithub.com\u002Fsudoprivacy\u002Fsudowork\u002Fblob\u002Fdev\u002Fapps\u002Fdesktop\u002Fskills\u002F_builtin\u002Fcron\u002Ficon_test.svg",{"path":77,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":78},"icon.svg","https:\u002F\u002Fgithub.com\u002Fsudoprivacy\u002Fsudowork\u002Fblob\u002Fdev\u002Fapps\u002Fdesktop\u002Fskills\u002F_builtin\u002Fcron\u002Ficon.svg",{"path":80,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":81,"sourceHtmlUrl":82},"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",[84,106,148,174,200,228],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":88,"sourceHtmlUrl":89,"categories":90,"keywords":99,"publishedAt":30},"01M6DTQM16M8ZCQSVW6GYYB9GM","skill-creator","创建或更新 Sudowork 自定义技能，同时保留核心 skill creation \u002F skill-design 最佳实践。用于用户要求创建新技能、优化已有技能、打包导入 Sudowork，或让技能展示在我的技能自定义技能中。","https:\u002F\u002Fgithub.com\u002Fsudoprivacy\u002Fsudowork\u002Fblob\u002Fdev\u002Fapps\u002Fdesktop\u002Fskills\u002Fskill-creator\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fsudoprivacy\u002Fsudowork\u002Fblob\u002Fdev\u002Fapps\u002Fdesktop\u002Fskills\u002Fskill-creator\u002FSKILL.md",[91,96],{"categoryNo":92,"categoryName":93,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":97,"categoryName":98,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000023","Skill与智能体开发",[100,101,102,103,104,105],"skill creator","creator","design","creation","skill-design","skill creation",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":36,"licenseFileUrl":110,"sourceHtmlUrl":111,"categories":112,"keywords":122,"publishedAt":30},"01M6DTQEH8DMDYG9ET2PSB381S","shareone","Host HTML\u002FMarkdown pages and share PDF, Word, or PowerPoint docs as ShareOne short links. Use when publishing pages\u002Fdocs, adding passwords\u002Fwatermarks, comments, downloads, or updates.","https:\u002F\u002Fgithub.com\u002Fsudoprivacy\u002Fsudowork\u002Fblob\u002Fdev\u002Fapps\u002Fdesktop\u002Fskills\u002Fshareone\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fsudoprivacy\u002Fsudowork\u002Fblob\u002Fdev\u002Fapps\u002Fdesktop\u002Fskills\u002Fshareone\u002FSKILL.md",[113,116,119],{"categoryNo":114,"categoryName":115,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000002","文档处理",{"categoryNo":117,"categoryName":118,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000003","演示文稿",{"categoryNo":120,"categoryName":121,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000009","前端开发",[108,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147],"PDF","pptx","docs","powerpoint","share","downloads","publish","sharing","markdown","Word","short","use","html","publishing","hosting","upload","pages","as","host","with","comments","links","passwords","updates","when",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":157,"publishedAt":30},"01M6DTQB7MRE9C1ETCRF8KCMY4","image-generation","Generate new images or edit existing images using AI. Use this skill when the user wants to create, generate, draw, design, or produce an image from a text description, OR when they want to modify, edit, alter, or transform an existing image (e.g. 'generate a picture of...', 'create an image', 'draw me a...', 'edit this image', 'change the background', 'modify the above picture', '生成图片', '画一张', '修改图片', '编辑上面的图').","https:\u002F\u002Fgithub.com\u002Fsudoprivacy\u002Fsudowork\u002Fblob\u002Fdev\u002Fapps\u002Fdesktop\u002Fskills\u002Fimage-generation\u002FSKILL.md",[154],{"categoryNo":155,"categoryName":156,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000016","图像与多媒体",[158,159,160,102,161,19,162,163,164,165,166,167,134,168,169,170,171,172,147,173],"image","Image Generation","generation","change","generate","produce","生成","text","edit","user","images","draw","me","transform","Existing","new",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":181,"publishedAt":30},"01M6DTQ7Y4CZRXENW8272CNFGD","image-analysis","Analyze, describe, or answer questions about image content using vision AI. Use this skill when the user asks anything about an image — what it shows, what's in it, reading text\u002Fdiagrams, identifying objects, or any question referencing a previous image (e.g. 'what is in this image', 'read the text in this screenshot', 'explain this diagram', 'tell me about the image above', '识别图片', '分析图片内容').","https:\u002F\u002Fgithub.com\u002Fsudoprivacy\u002Fsudowork\u002Fblob\u002Fdev\u002Fapps\u002Fdesktop\u002Fskills\u002Fimage-analysis\u002FSKILL.md",[180],{"categoryNo":155,"categoryName":156,"taxonomyType":94,"taxonomyTypeDesc":95},[158,182,183,184,185,186,187,165,188,189,190,167,134,191,192,193,194,170,195,196,197,198,199,147],"analysis","image analysis","diagram","screenshot","content","analyze","explain","question","read","vision","diagrams","vision ai","objects","about","questions","reading","answer","describe",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":204,"categories":205,"keywords":206,"publishedAt":30},"01M6DTQ4MFX1843KSW940WHB3R","auto-login","Log in to a website automatically using credentials saved in the local key store. Use when the user wants unattended\u002Frepeat login to a site (no re-scanning QR, no re-typing passwords), e.g. '帮我自动登录这个网站', 'set up auto-login for X', '记住这个网站的登录'. The plaintext password is NEVER seen by you — the user fills it in 秘钥管理 and sudowork fills the form itself.","https:\u002F\u002Fgithub.com\u002Fsudoprivacy\u002Fsudowork\u002Fblob\u002Fdev\u002Fapps\u002Fdesktop\u002Fskills\u002Fauto-login\u002FSKILL.md",[],[207,208,209,210,211,212,213,214,167,134,215,216,217,218,219,220,221,222,223,224,145,225,226,227,147],"auto","auto login","login","website","SET","credentials","password","site","never","scanning","up","log","local","form","typing","you","re","qr","saved","for","log in",{"skillNo":229,"name":230,"nameZh":6,"description":231,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":232,"categories":233,"keywords":235,"publishedAt":30},"01M6DTQ1TAD7RHXQ65RRKW468N","video-subtitles","Generate timed subtitles from video or audio, translate their text, and burn subtitles into a new video. Use for captions, SRT, video subtitles, or adding translated subtitles in Sudowork desktop or WebUI cloud conversations.","https:\u002F\u002Fgithub.com\u002Fsudoprivacy\u002Fsudowork\u002Fblob\u002Fdev\u002Fapps\u002Fdesktop\u002Fskills\u002F_builtin\u002Fvideo-subtitles\u002FSKILL.md",[234],{"categoryNo":155,"categoryName":156,"taxonomyType":94,"taxonomyTypeDesc":95},[236,237,238,239,162,240,241,242,243,165,134,244,245,246,247,226,173],"subtitles","Video","video subtitles","translate","desktop","cloud","Audio","Captions","webui","burn","conversations","srt"]