[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M699178ZDFDXEZ11DG1Y9CTF":3,"skill-same:01M699178ZDFDXEZ11DG1Y9CTF":59},{"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":30,"linkOnly":31,"markdownContent":32,"markdownBody":33,"frontMatter":34,"refName":35,"commitSha":36,"skillDirectory":37,"forksCount":38,"repositoryHtmlUrl":39,"repositoryHomepageUrl":40,"ownerHtmlUrl":41,"ownerBlogUrl":42,"ownerDescription":43,"updatedAt":44,"install":45,"resources":58},"01M699178ZDFDXEZ11DG1Y9CTF","policy",null,"Inspect the per-workspace tool-policy overlay (.lha\u002Fpolicies.jsonl) that gates destructive or sensitive tool calls, and tell the user what to change if they want a rule added or removed.","google\u002Fadk-recipes","google","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1342004?v=4","01M698VYEFDM0VJBZDYYJ2T83S","Google","01M6990124CWS5627VKGSKJXRD",10603,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fadk-recipes\u002Fblob\u002Fmain\u002Fcore\u002Fpython\u002Flong-horizon-harness\u002Fhorizon\u002Fbuiltin_skills\u002Fpolicy\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29],"change","tool","workspace","user","gates","rule","jsonl","calls","inspect","tool calls","overlay","2026-11-10 10:12:30",false,"---\nname: policy\ndescription: Inspect the per-workspace tool-policy overlay (.lha\u002Fpolicies.jsonl) that gates destructive or sensitive tool calls, and tell the user what to change if they want a rule added or removed.\n---\n# Inspect per-workspace tool policies\n\nThe `policies_guard` callback consults a JSONL policy file on every tool\ncall. Policies live in two layers:\n\n- **Default seed** at `horizon\u002Fguardrails\u002Fdefault_policies.jsonl` (read-only,\n  ships with the agent). Provides baseline blocks for catastrophic operations\n  (literal `dd if=\u002Fdev\u002Fzero`, `mkfs`, fork bombs, `>\u002Fdev\u002Fsd*`, `nc -l\u002Fncat -l\u002Fsocat`\n  bind listeners) and credential reads (`cat ~\u002F.ssh\u002Fid_rsa`, `cat ~\u002F.aws\u002Fcredentials`).\n  The seed no longer carries brittle substring\u002Fregex rules for `rm -rf` or\n  `chmod -R` — those are now classified by an **argv-structural parser**\n  (`horizon\u002Fguardrails\u002Fcommand_safety.py`) that lexes the command into tokens and\n  inspects structure instead of pattern-matching raw strings.\n- **User overlay** at `.lha\u002Fpolicies.jsonl` under the workspace root. The\n  overlay is **appended** to the seed — new rules add restrictions on top of\n  the defaults. Mtime-cached, so edits take effect on the next tool call. You\n  can read this file, but **you cannot write it**: `.lha\u002F*` and `*\u002F.lha\u002F*`\n  are themselves hard-denied destructive-path patterns for `write` and\n  `edit`, and the same paths are hard-denied for `bash` (append, `sed -i`,\n  `cp`\u002F`mv`, `rm`, `chmod` into `.lha\u002F` all match a seed\n  `destructive_commands_regex` rule). This is by design — see\n  `docs\u002Fsecurity-model.md` — the agent cannot self-edit its own guard config.\n\n## When to use this skill\n\n- The user asks what policies are currently in force.\n- The user asks you to block a specific command or path pattern, or to\n  relax (remove) an overlay rule — in both cases you inspect the current\n  file and hand the user the exact change to make; you do not make it\n  yourself.\n\nIf the user is asking about a *one-time* approval for a call that was just\nblocked, tell them to type `\u002Fgrant \u003Ccommand>` themselves — that slash command\nis a user-only surface, not something you can invoke.\n\n## File format\n\nOne JSON object per line. Blank lines and `#` comments are skipped.\nEvery rule must include `canonical_tool_name`; that field gates which\ntool the rule applies to.\n\nA rule may carry one or more of these fields. They are evaluated\nindependently — set as many as you need on a single rule.\n\n| Field | Type | Effect |\n|---|---|---|\n| `destructive` | `true` | Always block the tool. |\n| `destructive_commands` | `{arg: [substring, ...]}` | Block when the string arg contains any substring (case-insensitive). |\n| `destructive_commands_regex` | `{arg: [regex, ...]}` | Block when any regex matches the string arg (case-insensitive). Use when substrings are too blunt. Tenant-authored regexes (overlay + grant rules) are validated for length and nested-quantifier patterns before compilation; malformed regexes are skipped with a warning. |\n| `destructive_paths` | `[prefix, ...]` | Block when a path-shaped arg (`path`, `file_path`, `target_path`) starts with any prefix. |\n| `destructive_path_patterns` | `[fnmatch-glob, ...]` | Block when a path-shaped arg matches any fnmatch glob. Use for per-user paths like `*\u002F.ssh\u002F*`. |\n\n## Demotable destructive commands (argv classification)\n\nBefore the overlay\u002Fseed rules run, `command_safety.py` lexes shell commands\ninto argv tokens (quote- and operator-aware via stdlib `shlex`) and inspects\nstructure. It returns a **verdict**: `\"deny\"` (catastrophic, always blocks),\n`\"ask\"` (risky, blocks children\u002Fheadless, **prompts** the root agent via an\ninteractive approval card), or `None` (no opinion). Examples:\n\n- **\"deny\"** — `rm -rf \u002F`, `rm -rf \u002Fetc`, `rm -rf $HOME`, `rm -rf \u002F*`, etc.\n  (recursive force-delete of system\u002Fhome roots or their subdirectories).\n- **\"ask\"** — `find . -delete`, `git push --force`, `chmod -R 777 .`,\n  `sudo apt install ...`, `curl \u003Curl> | bash`.\n\nOn an `\"ask\"` verdict, the **root agent** sees an interactive four-button\napproval card; the **child\u002Fheadless** chain treats it as a hard deny (no\nregression in unattended contexts). This replaces the fragile substring\u002Fregex\nrules that shipped in older seeds — the new seed (`default_policies.jsonl`)\nonly carries literal catastrophic commands + credential reads.\n\n## Approval modes\n\nThe root agent's interactive approval can be set to **auto-approve**\ndemotable-ask verdicts (ONLY) via `\u002Fyolo` (toggles between `default` and `yolo`\nmodes). YOLO mode auto-approves the Layer-D interactive ask; it does **not**\nbypass the exfil guard or Layer-C hard-deny rules (catastrophic\n+ credential reads + seed overlays). Use it when you trust the session and want\nfewer prompts for risky-but-non-catastrophic operations. Approval mode is\nper-session state, not persisted.\n\n## Tool-narrowing enforcement\n\nPermission rules in `.lha\u002Fpermissions.jsonl` or granted via the interactive\napproval card may include a `commandPrefix`, `commandRegex`, or `argsPattern`\nto narrow blanket `allow` rules. **Overlay and grant rules** (source =\n`\"overlay\"` or `\"grant\"`) that target `bash` or `process` but carry no\nsuch narrowing field are **rejected** at load time — you cannot grant a blanket\n\"always allow bash\" from the overlay or a session approval; only the\ndefault seed may carry that. This prevents accidental over-granting.\n\n## Integration with the permission layer\n\nA policy block returns `{\"error\": ..., \"confirmation_required\": True}`. Tell\nthe user why the call was blocked; if they want a one-time approval, they\ntype `\u002Fgrant \u003Ccommand>` themselves. To force a *prompt* (not a hard block) or\nblock a specific command for the user, use the permission layer instead: add\nan `ask_user` or `deny` rule to `.lha\u002Fpermissions.jsonl` (see\n`docs\u002Fpermission-model.md`). This overlay is hard-block only, and it lives\nunder the same `.lha\u002F` write restriction as the policy overlay — the user\nedits it directly, not you.\n\n## Workflow\n\n### List active rules\n\n```\nread(\".lha\u002Fpolicies.jsonl\")\n```\n\nIf the file does not exist, the user has no overlay rules yet — only the\nseed is active. The seed itself lives outside the workspace and is not\nreadable through your tools; describe its coverage from this skill's own\n\"Default seed\" section above instead of trying to read it.\n\n### The user wants a rule added\n\nRead the current overlay so your suggestion appends correctly, then give the\nuser the exact line to add themselves — you cannot write `.lha\u002Fpolicies.jsonl`.\n\n```\nexisting = read(\".lha\u002Fpolicies.jsonl\")   # may be missing → treat as \"\"\nnew_rule = {\"canonical_tool_name\": \"bash\",\n            \"destructive_commands\": {\"command\": [\"rm -rf node_modules\"]}}\n```\n\nTell the user: \"Add this line to `.lha\u002Fpolicies.jsonl` (create the file if it\ndoesn't exist yet, one JSON object per line):\" followed by\n`json.dumps(new_rule)`.\n\n### The user wants a rule removed\n\nRead the overlay, identify the line to drop (0-based index into the overlay,\nignoring blank\u002Fcomment lines), and tell the user which line number and\ncontent to delete from `.lha\u002Fpolicies.jsonl`. Confirm the target with them\nfirst — overlay rules typically exist because they (or you on their behalf)\nadded them to plug a gap.\n\n## Worked example\n\nUser: \"Block `npm publish` from the terminal.\"\n\n1. Read `.lha\u002Fpolicies.jsonl` (returns \"\" if missing).\n2. Build:\n   ```json\n   {\"canonical_tool_name\": \"bash\", \"destructive_commands\": {\"command\": [\"npm publish\"]}}\n   ```\n3. Tell the user: \"I can't edit `.lha\u002Fpolicies.jsonl` myself — add this line\n   to it (create the file if needed):\" followed by the JSON above. \"Once\n   saved, the next `npm publish` attempt will be blocked.\"\n\n## Notes\n\n- The default seed is read-only and out of your reach either way — you\n  cannot edit it, and it lives outside the workspace root so you cannot\n  read it through your tools.\n- Malformed JSONL fails closed at parse time (the bad line is skipped with\n  a warning) — tell the user to double-check a new rule parses by reading\n  the file back after they save it.\n","# Inspect per-workspace tool policies\n\nThe `policies_guard` callback consults a JSONL policy file on every tool\ncall. Policies live in two layers:\n\n- **Default seed** at `horizon\u002Fguardrails\u002Fdefault_policies.jsonl` (read-only,\n  ships with the agent). Provides baseline blocks for catastrophic operations\n  (literal `dd if=\u002Fdev\u002Fzero`, `mkfs`, fork bombs, `>\u002Fdev\u002Fsd*`, `nc -l\u002Fncat -l\u002Fsocat`\n  bind listeners) and credential reads (`cat ~\u002F.ssh\u002Fid_rsa`, `cat ~\u002F.aws\u002Fcredentials`).\n  The seed no longer carries brittle substring\u002Fregex rules for `rm -rf` or\n  `chmod -R` — those are now classified by an **argv-structural parser**\n  (`horizon\u002Fguardrails\u002Fcommand_safety.py`) that lexes the command into tokens and\n  inspects structure instead of pattern-matching raw strings.\n- **User overlay** at `.lha\u002Fpolicies.jsonl` under the workspace root. The\n  overlay is **appended** to the seed — new rules add restrictions on top of\n  the defaults. Mtime-cached, so edits take effect on the next tool call. You\n  can read this file, but **you cannot write it**: `.lha\u002F*` and `*\u002F.lha\u002F*`\n  are themselves hard-denied destructive-path patterns for `write` and\n  `edit`, and the same paths are hard-denied for `bash` (append, `sed -i`,\n  `cp`\u002F`mv`, `rm`, `chmod` into `.lha\u002F` all match a seed\n  `destructive_commands_regex` rule). This is by design — see\n  `docs\u002Fsecurity-model.md` — the agent cannot self-edit its own guard config.\n\n## When to use this skill\n\n- The user asks what policies are currently in force.\n- The user asks you to block a specific command or path pattern, or to\n  relax (remove) an overlay rule — in both cases you inspect the current\n  file and hand the user the exact change to make; you do not make it\n  yourself.\n\nIf the user is asking about a *one-time* approval for a call that was just\nblocked, tell them to type `\u002Fgrant \u003Ccommand>` themselves — that slash command\nis a user-only surface, not something you can invoke.\n\n## File format\n\nOne JSON object per line. Blank lines and `#` comments are skipped.\nEvery rule must include `canonical_tool_name`; that field gates which\ntool the rule applies to.\n\nA rule may carry one or more of these fields. They are evaluated\nindependently — set as many as you need on a single rule.\n\n| Field | Type | Effect |\n|---|---|---|\n| `destructive` | `true` | Always block the tool. |\n| `destructive_commands` | `{arg: [substring, ...]}` | Block when the string arg contains any substring (case-insensitive). |\n| `destructive_commands_regex` | `{arg: [regex, ...]}` | Block when any regex matches the string arg (case-insensitive). Use when substrings are too blunt. Tenant-authored regexes (overlay + grant rules) are validated for length and nested-quantifier patterns before compilation; malformed regexes are skipped with a warning. |\n| `destructive_paths` | `[prefix, ...]` | Block when a path-shaped arg (`path`, `file_path`, `target_path`) starts with any prefix. |\n| `destructive_path_patterns` | `[fnmatch-glob, ...]` | Block when a path-shaped arg matches any fnmatch glob. Use for per-user paths like `*\u002F.ssh\u002F*`. |\n\n## Demotable destructive commands (argv classification)\n\nBefore the overlay\u002Fseed rules run, `command_safety.py` lexes shell commands\ninto argv tokens (quote- and operator-aware via stdlib `shlex`) and inspects\nstructure. It returns a **verdict**: `\"deny\"` (catastrophic, always blocks),\n`\"ask\"` (risky, blocks children\u002Fheadless, **prompts** the root agent via an\ninteractive approval card), or `None` (no opinion). Examples:\n\n- **\"deny\"** — `rm -rf \u002F`, `rm -rf \u002Fetc`, `rm -rf $HOME`, `rm -rf \u002F*`, etc.\n  (recursive force-delete of system\u002Fhome roots or their subdirectories).\n- **\"ask\"** — `find . -delete`, `git push --force`, `chmod -R 777 .`,\n  `sudo apt install ...`, `curl \u003Curl> | bash`.\n\nOn an `\"ask\"` verdict, the **root agent** sees an interactive four-button\napproval card; the **child\u002Fheadless** chain treats it as a hard deny (no\nregression in unattended contexts). This replaces the fragile substring\u002Fregex\nrules that shipped in older seeds — the new seed (`default_policies.jsonl`)\nonly carries literal catastrophic commands + credential reads.\n\n## Approval modes\n\nThe root agent's interactive approval can be set to **auto-approve**\ndemotable-ask verdicts (ONLY) via `\u002Fyolo` (toggles between `default` and `yolo`\nmodes). YOLO mode auto-approves the Layer-D interactive ask; it does **not**\nbypass the exfil guard or Layer-C hard-deny rules (catastrophic\n+ credential reads + seed overlays). Use it when you trust the session and want\nfewer prompts for risky-but-non-catastrophic operations. Approval mode is\nper-session state, not persisted.\n\n## Tool-narrowing enforcement\n\nPermission rules in `.lha\u002Fpermissions.jsonl` or granted via the interactive\napproval card may include a `commandPrefix`, `commandRegex`, or `argsPattern`\nto narrow blanket `allow` rules. **Overlay and grant rules** (source =\n`\"overlay\"` or `\"grant\"`) that target `bash` or `process` but carry no\nsuch narrowing field are **rejected** at load time — you cannot grant a blanket\n\"always allow bash\" from the overlay or a session approval; only the\ndefault seed may carry that. This prevents accidental over-granting.\n\n## Integration with the permission layer\n\nA policy block returns `{\"error\": ..., \"confirmation_required\": True}`. Tell\nthe user why the call was blocked; if they want a one-time approval, they\ntype `\u002Fgrant \u003Ccommand>` themselves. To force a *prompt* (not a hard block) or\nblock a specific command for the user, use the permission layer instead: add\nan `ask_user` or `deny` rule to `.lha\u002Fpermissions.jsonl` (see\n`docs\u002Fpermission-model.md`). This overlay is hard-block only, and it lives\nunder the same `.lha\u002F` write restriction as the policy overlay — the user\nedits it directly, not you.\n\n## Workflow\n\n### List active rules\n\n```\nread(\".lha\u002Fpolicies.jsonl\")\n```\n\nIf the file does not exist, the user has no overlay rules yet — only the\nseed is active. The seed itself lives outside the workspace and is not\nreadable through your tools; describe its coverage from this skill's own\n\"Default seed\" section above instead of trying to read it.\n\n### The user wants a rule added\n\nRead the current overlay so your suggestion appends correctly, then give the\nuser the exact line to add themselves — you cannot write `.lha\u002Fpolicies.jsonl`.\n\n```\nexisting = read(\".lha\u002Fpolicies.jsonl\")   # may be missing → treat as \"\"\nnew_rule = {\"canonical_tool_name\": \"bash\",\n            \"destructive_commands\": {\"command\": [\"rm -rf node_modules\"]}}\n```\n\nTell the user: \"Add this line to `.lha\u002Fpolicies.jsonl` (create the file if it\ndoesn't exist yet, one JSON object per line):\" followed by\n`json.dumps(new_rule)`.\n\n### The user wants a rule removed\n\nRead the overlay, identify the line to drop (0-based index into the overlay,\nignoring blank\u002Fcomment lines), and tell the user which line number and\ncontent to delete from `.lha\u002Fpolicies.jsonl`. Confirm the target with them\nfirst — overlay rules typically exist because they (or you on their behalf)\nadded them to plug a gap.\n\n## Worked example\n\nUser: \"Block `npm publish` from the terminal.\"\n\n1. Read `.lha\u002Fpolicies.jsonl` (returns \"\" if missing).\n2. Build:\n   ```json\n   {\"canonical_tool_name\": \"bash\", \"destructive_commands\": {\"command\": [\"npm publish\"]}}\n   ```\n3. Tell the user: \"I can't edit `.lha\u002Fpolicies.jsonl` myself — add this line\n   to it (create the file if needed):\" followed by the JSON above. \"Once\n   saved, the next `npm publish` attempt will be blocked.\"\n\n## Notes\n\n- The default seed is read-only and out of your reach either way — you\n  cannot edit it, and it lives outside the workspace root so you cannot\n  read it through your tools.\n- Malformed JSONL fails closed at parse time (the bad line is skipped with\n  a warning) — tell the user to double-check a new rule parses by reading\n  the file back after they save it.\n",{"name":5,"description":7},"main","665f7b2a181686f2ba3c6c942e9b30a084b12ec3","core\u002Fpython\u002Flong-horizon-harness\u002Fhorizon\u002Fbuiltin_skills\u002Fpolicy",2956,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fadk-recipes","https:\u002F\u002Fadk.dev","https:\u002F\u002Fgithub.com\u002Fgoogle","https:\u002F\u002Fopensource.google\u002F","Google ❤️ Open Source","2026-11-11 03:19:25",{"source":8,"skillName":5,"commands":46,"prompt":56,"zipAvailable":57},[47,50,53],{"tool":48,"command":49},"npx","npx skills add google\u002Fadk-recipes --skill policy",{"tool":51,"command":52},"bunx","bunx skills add google\u002Fadk-recipes --skill policy",{"tool":54,"command":55},"pnpm","pnpm dlx skills add google\u002Fadk-recipes --skill policy","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fadk-recipes\u002Fblob\u002Fmain\u002Fcore\u002Fpython\u002Flong-horizon-harness\u002Fhorizon\u002Fbuiltin_skills\u002Fpolicy\u002FSKILL.md",true,[],[60,86,120,144,165,184],{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":77,"publishedAt":30},"01M6991EKEG8XEM3VWW4VGV0ZQ","retail-virtual-tryon","Creates virtual try-on agents supporting image and video (catwalk animation) try-ons on Google Cloud (Gemini image models and Veo on Gemini Enterprise Agent Platform). Handles resource setup, user photo uploading, image\u002Fvideo generation pipelines, local testing, and evaluation.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fadk-recipes\u002Fblob\u002Fmain\u002Fplugins\u002Fretail\u002Fskills\u002Fvirtual-tryon\u002FSKILL.md",[66,71,74],{"categoryNo":67,"categoryName":68,"taxonomyType":69,"taxonomyTypeDesc":70},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":72,"categoryName":73,"taxonomyType":69,"taxonomyTypeDesc":70},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":75,"categoryName":76,"taxonomyType":69,"taxonomyTypeDesc":70},"01JBSEEDCAT000000000000023","Skill与智能体开发",[78,79,80,9,81,82,83,84,85],"retail virtual tryon","testing","image","gemini","genai","adk","gemini enterprise agent platform","google cloud",{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":101,"publishedAt":30},"01M6991ABTZW7FCPREXY8GD4RG","retail-product-search","Creates product search agents with semantic search and RAG on Google Cloud (Vector Search on Gemini Enterprise Agent Platform, BigQuery, embeddings). Use when the user wants to \"build a product search agent\", \"create an e-commerce search\", \"make a shopping assistant\", \"set up semantic catalog discovery\", \"ingest products into Vector Search\", or \"deploy a retail RAG agent\". Handles the full pipeline: catalog data ingestion to BigQuery, Gemini Enterprise Agent Platform Vector Search collection setup, ADK agent scaffolding, evaluation, and Cloud Run deployment.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fadk-recipes\u002Fblob\u002Fmain\u002Fplugins\u002Fretail\u002Fskills\u002Fproduct-search\u002FSKILL.md",[92,95,96],{"categoryNo":93,"categoryName":94,"taxonomyType":69,"taxonomyTypeDesc":70},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":75,"categoryName":76,"taxonomyType":69,"taxonomyTypeDesc":70},{"categoryNo":97,"categoryName":98,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[102,103,104,9,105,81,83,84,85,106,107,108,109,110,111,112,113,114,115,116,117,118,119],"retail product search","product","search","assistant","rag","create","run","apache","vector","pipeline","SET","collection","ingestion","up","shopping","scaffolding","commerce","when",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":127,"publishedAt":30},"01M69918HZCYZHD7K9Y9ZSD287","routines","Use for a recurring unattended task (cron; pull data, open a PR, post a digest), or to test\u002Fdry-run a routine first. Explains authoring and testing via the routine tool.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fadk-recipes\u002Fblob\u002Fmain\u002Fcore\u002Fpython\u002Flong-horizon-harness\u002Fhorizon\u002Fbuiltin_skills\u002Froutines\u002FSKILL.md",[126],{"categoryNo":67,"categoryName":68,"taxonomyType":69,"taxonomyTypeDesc":70},[122,79,128,129,108,130,131,132,133,20,134,135,136,137,138,139,140,141,142,143],"test","pr","pull","data","first","open","recurring","use","task","digest","authoring","dry","via","post","for","routine",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":150,"publishedAt":30},"01M69915F8591SQBA1ZHK6NDA7","google-workspace","Read\u002Fwrite Google Drive, Docs, Sheets, Gmail, Calendar, Chat, Tasks, Slides via the `gws` CLI. Needs an OAuth client or service account configured first. Use for any Google Workspace task.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fadk-recipes\u002Fblob\u002Fmain\u002Fcore\u002Fpython\u002Flong-horizon-harness\u002Fhorizon\u002Fbuiltin_skills\u002Fgoogle-workspace\u002FSKILL.md",[],[9,151,21,152,153,154,155,156,132,157,158,159,135,160,136,161,162,140,163,164,142],"google workspace","gmail","cli","docs","tasks","OAuth","slides","read","write","calendar","gws","chat","client","sheets",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":172,"publishedAt":30},"01M69914416KTZ6Z0WD425YYJ0","find-skills","Discover\u002Finstall NEW agent skills from external sources (skills.sh). Use for capabilities you lack, e.g. \"find a skill for X\". Do NOT use to list skills you already have; see `\u003Cavailable_skills>`.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fadk-recipes\u002Fblob\u002Fmain\u002Fcore\u002Fpython\u002Flong-horizon-harness\u002Fhorizon\u002Fbuiltin_skills\u002Ffind-skills\u002FSKILL.md",[171],{"categoryNo":75,"categoryName":76,"taxonomyType":69,"taxonomyTypeDesc":70},[173,174,175,176,177,178,135,179,180,181,182,183,142],"find skills","find","capabilities","list skills","list","install","do","new agent","discover","sources","you",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":188,"categories":189,"keywords":191,"publishedAt":30},"01M6991292FVYS3XR3WE7VXZJD","bootstrap-google-tools","Install\u002Fauth CLIs the sandbox lacks - `gws` (Drive, Gmail, Sheets, Calendar), `gcloud`, `agents-cli`, `mcp-cli` (MCP servers). Use on \"command not found\" or before GCP\u002FWorkspace\u002FMCP work.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fadk-recipes\u002Fblob\u002Fmain\u002Fcore\u002Fpython\u002Flong-horizon-harness\u002Fhorizon\u002Fbuiltin_skills\u002Fbootstrap-google-tools\u002FSKILL.md",[190],{"categoryNo":75,"categoryName":76,"taxonomyType":69,"taxonomyTypeDesc":70},[9,192,193,194,195,152,153,196,197,198,199,21,200,201,178,135,160,161,164,202],"bootstrap google tools","bootstrap","Tools","MCP","gcloud","sandbox","auth","gcp","work","command","servers"]