[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6D0DDS2YPNADEX29GA9KA6P":3,"skill-same:01M6D0DDS2YPNADEX29GA9KA6P":73},{"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":23,"publishedAt":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":48,"repositoryHtmlUrl":49,"repositoryHomepageUrl":50,"ownerHtmlUrl":51,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":52,"install":53,"resources":66},"01M6D0DDS2YPNADEX29GA9KA6P","developer_guide",null,"Guidance for using the Developer tools to inspect, edit, test, and review code folders safely.","siddsachar\u002Frow-bot","siddsachar","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F50956096?v=4","01M6D0AG8BTX8VNFY5N3F2Q36T","Siddharth Sachar","01M6D0AGD3C7BZ6NAW9PWVKM3A",1687,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fsiddsachar\u002Frow-bot\u002Fblob\u002Fmain\u002Ftool_guides\u002Fdeveloper_guide\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36],"developer","guide","developer guide","review","developer tools","test","code","Tools","review code","edit","guidance","inspect","for","2026-11-10 10:12:30",false,"---\nname: developer_guide\ndisplay_name: Developer Guide\nicon: \"code\"\ndescription: Guidance for using the Developer tools to inspect, edit, test, and review code folders safely.\ntools:\n  - developer\ntags:\n  - developer\n  - code\n---\n\n# Developer Tool Guide\n\nUse the Developer tools whenever the active conversation has a code folder. They are scoped to the selected workspace, follow the workspace approval mode, and keep the Developer Inspector in sync.\n\n## Default Workflow\n\n1. Start with `developer_workspace_info` for repo, branch, approval mode, execution mode, dirty state, and available context.\n2. Use `developer_update_todos` for multi-step coding work. Keep the todo list current as you inspect, edit, test, and review.\n3. Inspect with `developer_list_files`, `developer_read_file`, `developer_search`, `developer_git_status`, and `developer_get_diff` before changing code.\n4. Prefer `developer_write_file` for creating or replacing full files and `developer_apply_patch` for precise diffs. Both record agent-owned change sets for the Inspector.\n5. Use `developer_create_branch`, `developer_switch_branch`, `developer_commit_changes`, `developer_push_current_branch`, and `developer_fast_forward_merge` for common Git workflows instead of raw shell.\n6. Use `developer_run_detected_test` for known project test\u002Flint commands. Use `developer_run_command` for custom shell commands only when it is the right tool for the task.\n7. If a Developer edit\u002Ftest\u002Fcommand tool reports `execution_mode: \"docker\"` and a `sandbox_pending_change_id`, tell the user that the real repo has not changed yet. The Docker container persists for the workspace, but host files still change only through `developer_import_sandbox_changes`.\n8. Before finishing, check `developer_get_diff`, run the relevant tests, and summarize files changed, tests run, and any remaining risk.\n\n## Progress Narration\n\nFor longer work, narrate briefly in the chat before clusters of tool calls. Good examples:\n\n- \"I'll first map the repo and test surface.\"\n- \"I found the core module; now I'm adding focused tests.\"\n- \"The patch is in. I'm running the detected test command next.\"\n\nAvoid silent chains of tools when the user would otherwise have no sense of what is happening.\n\n## Shell Use\n\nShell is allowed in a code folder, but use it deliberately:\n\n- Prefer read\u002Fsearch\u002Fnative Developer tools for repo inspection.\n- Use shell for test runs, build commands, git commands, package-manager commands, generated artifacts, and repo-specific scripts.\n- For common Git operations, prefer the dedicated Developer Git tools first; use shell for unusual Git flows only.\n- Use `developer_run_command` instead of a generic shell tool when possible so Row-Bot can scope the command to the workspace and record file side effects.\n- Match the workspace shell. On Windows\u002FPowerShell, do not use POSIX heredocs such as `python - \u003C\u003C'PY'`; use PowerShell-safe commands or a Developer file tool.\n- Do not use shell writes as a workaround for ordinary file edits unless patch\u002Fwrite tools are unsuitable.\n- In Docker Sandbox mode, shell commands run in a persistent workspace container backed by a shadow copy. Review the pending sandbox patch before importing it into the real workspace.\n\n## Custom Tools\n\nUse Custom Tools when the user wants to turn a repo or local folder into a reusable Row-Bot tool.\n\n- Prefer the guided flow: inspect the source first, show the proposed commands, then create\u002Fregister only after the user accepts the shape.\n- If the user asks naturally, e.g. \"turn this repo into a tool\" or \"add this GitHub repo as a tool\", handle it with the same inspect -> review -> create -> test -> enable\u002Fpromote flow.\n- Use `custom_tool_builder` for the whole lifecycle when that utility is enabled: action `start` to create a draft, `show`\u002F`list` to inspect drafts, `refine` or `update` to adjust commands, `test` to smoke-test a command, `create` to register, `enable` for Developer use, `promote` for normal chat\u002Fplugin tools, and `delete` to remove draft\u002Ftool metadata.\n- Explain draft commands clearly before action `create`. Use action `refine` for natural-language adjustments instead of creating multiple one-off tools.\n- Public repo Custom Tools can be drafted from an explicit repo URL and clone destination; do not add hidden settings or edit internal JSON. Safety comes from command review, test approval\u002Fsandboxing, and separate enable\u002Fpromote steps.\n- Do not ask the user to hand-write internal config files. If a repo needs command metadata, inspect it and generate the first config for review.\n- Removing a Custom Tool should remove Row-Bot metadata\u002Fplugin registration only; do not delete the source folder unless the user explicitly asks.\n\n## Edit Hygiene\n\n- Make the smallest clear diff that solves the task.\n- Preserve unrelated formatting, encoding, notebook metadata, and generated file layout unless changing them is part of the task.\n- Avoid whole-file rewrites when a targeted patch will do.\n- Use repo-native tests, linters, type checks, or build commands when available.\n- For structured files, run cheap validation when practical. For notebooks, JSON parsing is the minimum; use `nbformat` validation if available. Do not execute full notebooks unless the user asks or the repo clearly supports a cheap safe run.\n- Do not add language-specific assumptions before inspecting the repo.\n\n## Safety\n\n- Never edit outside the active workspace.\n- Respect the workspace approval mode.\n- Respect the workspace execution mode. Local mode touches the selected repo directly; Docker Sandbox mode does not touch the selected repo until `developer_import_sandbox_changes` imports an approved patch.\n- Do not push, create pull requests, install dependencies, or delete files without explicit approval.\n- If the repo is dirty before your work, preserve user changes and mention what you touched.\n","# Developer Tool Guide\n\nUse the Developer tools whenever the active conversation has a code folder. They are scoped to the selected workspace, follow the workspace approval mode, and keep the Developer Inspector in sync.\n\n## Default Workflow\n\n1. Start with `developer_workspace_info` for repo, branch, approval mode, execution mode, dirty state, and available context.\n2. Use `developer_update_todos` for multi-step coding work. Keep the todo list current as you inspect, edit, test, and review.\n3. Inspect with `developer_list_files`, `developer_read_file`, `developer_search`, `developer_git_status`, and `developer_get_diff` before changing code.\n4. Prefer `developer_write_file` for creating or replacing full files and `developer_apply_patch` for precise diffs. Both record agent-owned change sets for the Inspector.\n5. Use `developer_create_branch`, `developer_switch_branch`, `developer_commit_changes`, `developer_push_current_branch`, and `developer_fast_forward_merge` for common Git workflows instead of raw shell.\n6. Use `developer_run_detected_test` for known project test\u002Flint commands. Use `developer_run_command` for custom shell commands only when it is the right tool for the task.\n7. If a Developer edit\u002Ftest\u002Fcommand tool reports `execution_mode: \"docker\"` and a `sandbox_pending_change_id`, tell the user that the real repo has not changed yet. The Docker container persists for the workspace, but host files still change only through `developer_import_sandbox_changes`.\n8. Before finishing, check `developer_get_diff`, run the relevant tests, and summarize files changed, tests run, and any remaining risk.\n\n## Progress Narration\n\nFor longer work, narrate briefly in the chat before clusters of tool calls. Good examples:\n\n- \"I'll first map the repo and test surface.\"\n- \"I found the core module; now I'm adding focused tests.\"\n- \"The patch is in. I'm running the detected test command next.\"\n\nAvoid silent chains of tools when the user would otherwise have no sense of what is happening.\n\n## Shell Use\n\nShell is allowed in a code folder, but use it deliberately:\n\n- Prefer read\u002Fsearch\u002Fnative Developer tools for repo inspection.\n- Use shell for test runs, build commands, git commands, package-manager commands, generated artifacts, and repo-specific scripts.\n- For common Git operations, prefer the dedicated Developer Git tools first; use shell for unusual Git flows only.\n- Use `developer_run_command` instead of a generic shell tool when possible so Row-Bot can scope the command to the workspace and record file side effects.\n- Match the workspace shell. On Windows\u002FPowerShell, do not use POSIX heredocs such as `python - \u003C\u003C'PY'`; use PowerShell-safe commands or a Developer file tool.\n- Do not use shell writes as a workaround for ordinary file edits unless patch\u002Fwrite tools are unsuitable.\n- In Docker Sandbox mode, shell commands run in a persistent workspace container backed by a shadow copy. Review the pending sandbox patch before importing it into the real workspace.\n\n## Custom Tools\n\nUse Custom Tools when the user wants to turn a repo or local folder into a reusable Row-Bot tool.\n\n- Prefer the guided flow: inspect the source first, show the proposed commands, then create\u002Fregister only after the user accepts the shape.\n- If the user asks naturally, e.g. \"turn this repo into a tool\" or \"add this GitHub repo as a tool\", handle it with the same inspect -> review -> create -> test -> enable\u002Fpromote flow.\n- Use `custom_tool_builder` for the whole lifecycle when that utility is enabled: action `start` to create a draft, `show`\u002F`list` to inspect drafts, `refine` or `update` to adjust commands, `test` to smoke-test a command, `create` to register, `enable` for Developer use, `promote` for normal chat\u002Fplugin tools, and `delete` to remove draft\u002Ftool metadata.\n- Explain draft commands clearly before action `create`. Use action `refine` for natural-language adjustments instead of creating multiple one-off tools.\n- Public repo Custom Tools can be drafted from an explicit repo URL and clone destination; do not add hidden settings or edit internal JSON. Safety comes from command review, test approval\u002Fsandboxing, and separate enable\u002Fpromote steps.\n- Do not ask the user to hand-write internal config files. If a repo needs command metadata, inspect it and generate the first config for review.\n- Removing a Custom Tool should remove Row-Bot metadata\u002Fplugin registration only; do not delete the source folder unless the user explicitly asks.\n\n## Edit Hygiene\n\n- Make the smallest clear diff that solves the task.\n- Preserve unrelated formatting, encoding, notebook metadata, and generated file layout unless changing them is part of the task.\n- Avoid whole-file rewrites when a targeted patch will do.\n- Use repo-native tests, linters, type checks, or build commands when available.\n- For structured files, run cheap validation when practical. For notebooks, JSON parsing is the minimum; use `nbformat` validation if available. Do not execute full notebooks unless the user asks or the repo clearly supports a cheap safe run.\n- Do not add language-specific assumptions before inspecting the repo.\n\n## Safety\n\n- Never edit outside the active workspace.\n- Respect the workspace approval mode.\n- Respect the workspace execution mode. Local mode touches the selected repo directly; Docker Sandbox mode does not touch the selected repo until `developer_import_sandbox_changes` imports an approved patch.\n- Do not push, create pull requests, install dependencies, or delete files without explicit approval.\n- If the repo is dirty before your work, preserve user changes and mention what you touched.\n",{"icon":30,"name":5,"tags":42,"tools":43,"description":7,"display_name":44},[24,30],[24],"Developer Guide","main","aea3219498f535052aba82436fc9612f548a086e","tool_guides\u002Fdeveloper_guide",204,"https:\u002F\u002Fgithub.com\u002Fsiddsachar\u002Frow-bot","https:\u002F\u002Frow-bot.ai","https:\u002F\u002Fgithub.com\u002Fsiddsachar","2026-11-13 03:26:39",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add siddsachar\u002Frow-bot --skill developer_guide",{"tool":59,"command":60},"bunx","bunx skills add siddsachar\u002Frow-bot --skill developer_guide",{"tool":62,"command":63},"pnpm","pnpm dlx skills add siddsachar\u002Frow-bot --skill developer_guide","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fsiddsachar\u002Frow-bot\u002Fblob\u002Fmain\u002Ftool_guides\u002Fdeveloper_guide\u002FSKILL.md",true,[67],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"agents\u002Fopenai.yaml","REFERENCE","参考文档",159,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fnyldn\u002Fclaude-octopus\u002Fskills\u002Foctopus-quick\u002Fagents\u002Fopenai.yaml",[74,92,117,128,138,153],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":37},"01M6D0EZEJNX7R2J8EXN3386BW","x_guide","Essential guidance for using X (Twitter) tools correctly — search syntax, time filtering, and engagement patterns.","https:\u002F\u002Fgithub.com\u002Fsiddsachar\u002Frow-bot\u002Fblob\u002Fmain\u002Ftool_guides\u002Fx_guide\u002FSKILL.md",[],[81,25,36,82,83,31,84,85,86,87,34,88,89,90,91],"x guide","bot","search","syntax","twitter","filtering","engagement","patterns","social","time","essential",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":103,"publishedAt":37},"01M6D0EWESTPTF4B1JZFVFQ49Y","workflow_guide","How workflows run (scheduled chats), how to write and change them, hand work between them, and check what a run did.","https:\u002F\u002Fgithub.com\u002Fsiddsachar\u002Frow-bot\u002Fblob\u002Fmain\u002Ftool_guides\u002Fworkflow_guide\u002FSKILL.md",[98],{"categoryNo":99,"categoryName":100,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[104,25,105,106,107,108,109,110,111,112,113,114,115,116],"workflow guide","workflow","write","task","how to","hand","scheduled","check","workflows","change","run","how","work",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":123,"publishedAt":37},"01M6D0ESS92MEV9V5EAHJ3N6VR","wiki_guide","Guidance for the Obsidian-compatible wiki vault.","https:\u002F\u002Fgithub.com\u002Fsiddsachar\u002Frow-bot\u002Fblob\u002Fmain\u002Ftool_guides\u002Fwiki_guide\u002FSKILL.md",[],[124,25,125,126,127,34,36],"wiki guide","wiki","obsidian","vault",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":37},"01M6D0EQDFABHZ27HMDKYSX6V4","weather_guide","Guidance for using weather tools effectively.","https:\u002F\u002Fgithub.com\u002Fsiddsachar\u002Frow-bot\u002Fblob\u002Fmain\u002Ftool_guides\u002Fweather_guide\u002FSKILL.md",[],[135,25,136,31,137,34,36],"weather guide","weather","weather tools",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":144,"publishedAt":37},"01M6D0EMVZ8MZHAVSTMMTMBWN0","vision_guide","Guidance for using webcam, screen capture, and image analysis.","https:\u002F\u002Fgithub.com\u002Fsiddsachar\u002Frow-bot\u002Fblob\u002Fmain\u002Ftool_guides\u002Fvision_guide\u002FSKILL.md",[],[145,146,25,34,147,148,149,36,150,151,152],"vision guide","vision","analysis","screen","image analysis","capture","screen capture","image",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":162,"publishedAt":37},"01M6D0EJF8QMGWNNKD38BK24G8","video_guide","Guidance for generating videos and animating images.","https:\u002F\u002Fgithub.com\u002Fsiddsachar\u002Frow-bot\u002Fblob\u002Fmain\u002Ftool_guides\u002Fvideo_guide\u002FSKILL.md",[159],{"categoryNo":160,"categoryName":161,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000016","图像与多媒体",[25,163,164,34,165,36,166],"Video","video guide","images","videos"]