[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6P6TYGZKSDKAQBGKBY94S17":3,"skill-same:01M6P6TYGZKSDKAQBGKBY94S17":63},{"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":35,"linkOnly":36,"markdownContent":37,"markdownBody":38,"frontMatter":39,"refName":40,"commitSha":41,"skillDirectory":42,"forksCount":43,"repositoryHtmlUrl":44,"repositoryHomepageUrl":6,"ownerHtmlUrl":45,"ownerBlogUrl":46,"ownerDescription":47,"updatedAt":48,"install":49,"resources":62},"01M6P6TYGZKSDKAQBGKBY94S17","github-actions",null,"GitHub Actions best practices for writing and reviewing workflows. Use when creating or modifying .github\u002Fworkflows\u002F files.","ippontech\u002Fterraform-provider-anthropic","ippontech","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F503415?v=4","01M6P6SZRB0W85F9JQ867Q61WQ","Ippon Technologies","01M6P6SZWCQBBDYPAECGFWSBTF",19,"MPL-2.0","https:\u002F\u002Fgithub.com\u002Fippontech\u002Fterraform-provider-anthropic\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fgithub-actions\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34],"actions","github actions","github","for","files","writing","use","workflows","best practices","sonnet","when","2026-11-10 10:12:30",false,"---\nname: github-actions\ndescription: GitHub Actions best practices for writing and reviewing workflows. Use when creating or modifying .github\u002Fworkflows\u002F files.\nmodel: sonnet\n---\n\n# Workflow syntax\n\nRefer to the [GitHub Actions workflow syntax](https:\u002F\u002Fdocs.github.com\u002Fen\u002Factions\u002Freference\u002Fworkflows-and-actions\u002Fworkflow-syntax) guide to find details about how to implement certain actions in workflows or actions.\n\n# Action pinning\n\nEvery `uses:` reference **must** be pinned to a full commit SHA. Tags and branches are mutable and can be silently redirected (supply chain attack vector). Add the version tag as a trailing comment so humans know what version is in use.\n\n```yaml\n# Bad — mutable tag\nuses: hashicorp\u002Fsetup-terraform@v3\n\n# Good — immutable SHA + human-readable comment\nuses: hashicorp\u002Fsetup-terraform@b9cd54a3c349d3f38e8881555d616ced269ef032 # v3.1.2\n```\n\nThis applies to all third-party actions including `actions\u002F` official actions.\n\n# Permissions\n\nAlways set a zero-permission block at the **workflow level** to disable all permissions by default:\n\n```yaml\npermissions: {}\n```\n\nThen set an explicit `permissions:` block on **every job**, granting only what that job needs:\n\n- Read-only jobs (lint, test, build): `contents: read`\n- Jobs that push or tag: `contents: write`\n- Jobs that authenticate to OIDC providers: `id-token: write`\n- Jobs that comment on PRs or issues: `pull-requests: write`, `issues: write`\n\nNever leave a job without a `permissions:` block.\n\n# Command injection prevention\n\n`${{ }}` expressions are expanded **before** the shell executes — no escaping occurs. Any attacker-controlled value in a `run:` step is an arbitrary code execution risk.\n\nNever interpolate these directly in `run:` steps:\n\n| Source | Variable |\n|--------|----------|\n| PR title | `github.event.pull_request.title` |\n| PR body | `github.event.pull_request.body` |\n| Issue title | `github.event.issue.title` |\n| Comment body | `github.event.comment.body` |\n| Branch name | `github.event.pull_request.head.ref` |\n| Commit message | `github.event.head_commit.message` |\n| Dispatch input | `github.event.inputs.*` |\n\n```yaml\n# Bad — injection risk\n- run: echo \"PR: ${{ github.event.pull_request.title }}\"\n\n# Good — pass through env var\n- run: echo \"PR: $PR_TITLE\"\n  env:\n    PR_TITLE: ${{ github.event.pull_request.title }}\n```\n\n# Harden runner\n\nEvery job's **first** step must be `step-security\u002Fharden-runner`, SHA-pinned, with `egress-policy: audit`. This intercepts all outbound network calls and logs unexpected egress (e.g., a compromised action exfiltrating secrets).\n\n```yaml\nsteps:\n  - name: Harden runner\n    uses: step-security\u002Fharden-runner@\u003Cfull-sha> # \u003Cversion tag>\n    with:\n      egress-policy: audit\n```\n\n# Secret handling\n\n- Secrets must only be passed via `env:` or `with:` — never interpolated directly into `run:` shell commands with `${{ secrets.FOO }}` (log injection risk).\n- Never print, echo, or write secrets to files or stdout.\n\n```yaml\n# Bad — log injection risk\n- run: curl -H \"Authorization: ${{ secrets.API_KEY }}\" https:\u002F\u002Fexample.com\n\n# Good\n- run: curl -H \"Authorization: $API_KEY\" https:\u002F\u002Fexample.com\n  env:\n    API_KEY: ${{ secrets.API_KEY }}\n```\n\n# Fork PR security\n\nJobs that use repository secrets must not be triggerable from fork pull requests. Fork PRs run with no access to secrets under a plain `pull_request` trigger — but this protection is bypassed by `pull_request_target`, which runs in the base branch context and exposes secrets.\n\n- Never use `pull_request_target` for jobs that access secrets unless forked code is never checked out.\n- Jobs needing secrets must be triggered by `push` to a protected branch, `workflow_dispatch`, a GitHub Environment with required reviewers, or `workflow_call` from a workflow that meets one of these conditions.\n- A called workflow receives a secret only if the caller passes it, by name or with `secrets: inherit`, even a secret that exists only in the environment of the called job. That job then gets the environment's value. Keep such secrets `required: false`: `required` only checks that the caller passes the secret, not its value.\n\n```yaml\n# Correct pattern for jobs needing secrets: testacc.yml, called by semantic-release.yml on push to main\non:\n  workflow_call:\n    secrets:\n      ANTHROPIC_API_KEY:\n        required: false\n  workflow_dispatch:\n\njobs:\n  testacc:\n    environment: acctest  # holds the secret\n    env:\n      ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}\n\n# semantic-release.yml, the caller: passes the secret by name\njobs:\n  acceptance-tests:\n    uses: .\u002F.github\u002Fworkflows\u002Ftestacc.yml\n    secrets:\n      ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}\n```\n\n# Privileged jobs (release, publication)\n\nA job that signs artifacts or writes to `main` holds credentials that every user of the provider ends up trusting: the GPG key signs the Registry checksums, and the semantic-release App bypasses the `main` ruleset. Write access to the repository must not be enough to reach them. `RELEASE.md` (\"Protect the release credentials\") has the GitHub settings; when writing or reviewing `goreleaser-release.yml`, `semantic-release.yml` or a new privileged workflow, check these six rules:\n\n1. **Credentials live in an environment, never at repository or organization level.** The job declares `environment:` (`release` for signing, deployable from `v*` tags only, with required reviewers; `semantic-release` for publishing, deployable from `main` only), and the secrets are environment secrets. A repository secret is readable by a workflow pushed on any branch.\n2. **Release tags are protected.** A tag ruleset on `v*` restricts creation, update and deletion, with the semantic-release App as the only bypass, because any `v*` tag starts the signed release.\n3. **No shared cache in a job that holds a secret.** That covers the jobs that sign or publish and the acceptance-test jobs of `testacc.yml`. `actions\u002Fsetup-go` gets `cache: false` and the job uses no `actions\u002Fcache`: a cache restored there may have been saved by any job that ran on `main`, including one whose actions Renovate automerges, and Go does not re-hash extracted module sources on restore. A release job runs `go mod download && go mod verify` instead; the test jobs download the modules as they build (`RELEASE.md`, \"Caches\").\n4. **Installs come from a committed lockfile, without scripts.** `npm ci --ignore-scripts` from `.github\u002Fsemantic-release\u002Fpackage-lock.json` (also enforced by its `.npmrc`), never `npm install` with inline versions: every transitive package would otherwise be resolved at release time and could run code next to the credentials.\n5. **Credentials enter the job after the install, with only the permissions they need.** `actions\u002Fcheckout` sets `persist-credentials: false`, the App token is minted after `npm ci` and passed only to the step that publishes, and the job token keeps `contents: read`. The App token lists its permissions (`permission-contents`, `permission-issues`, `permission-pull-requests`, all `write`): without them it inherits every permission the App holds, including any granted later.\n6. **Release tooling updates get a human review.** In `renovate.json`, the `release tooling` group (matched by file: both release workflows and `.github\u002Fsemantic-release\u002Fpackage.json`) keeps `automerge: false` whatever the update type. Do not add these files to an automerged group.\n   The group also matches `testacc.yml`, whose jobs hold the `acctest` keys. Add to it any new workflow whose jobs read a secret other than `GITHUB_TOKEN` or run in a protected environment, and give those jobs no cache (rule 3). Root `go.mod` updates are never automerged either, because the acceptance tests compile them, and a tool that such a job downloads is pinned, never `latest` (`terraform_version` in `testacc.yml`). The approval of the signing job checks those updates again before they ship signed, so keep the `dependency-changes` job of `goreleaser-release.yml`, which lists them on the run page, as a `needs` of the signing job.\n\n```yaml\njobs:\n  release:\n    environment: semantic-release        # secrets scoped to main\n    permissions:\n      contents: read                     # writes go through the App token\n    steps:\n      - uses: actions\u002Fcheckout@\u003Cfull-sha> # \u003Cversion tag>\n        with:\n          persist-credentials: false\n      - name: Install semantic-release\n        working-directory: .github\u002Fsemantic-release\n        run: npm ci --ignore-scripts --no-audit --no-fund\n      - name: Generate app token         # minted after the install\n        id: app-token\n        uses: actions\u002Fcreate-github-app-token@\u003Cfull-sha> # \u003Cversion tag>\n        with:\n          app-id: ${{ secrets.SEMREL_APP_ID }}\n          private-key: ${{ secrets.SEMREL_APP_PRIVATE_KEY }}\n          permission-contents: write     # only what semantic-release uses\n          permission-issues: write\n          permission-pull-requests: write\n```\n\n# Security tooling\n\n## `security.yml` workflow\n\nThe project must have `.github\u002Fworkflows\u002Fsecurity.yml` with four jobs, all SHA-pinned, triggered on `pull_request` and `merge_group`:\n\n| Job | Tool | What it checks |\n|-----|------|----------------|\n| `actionlint` | `rhysd\u002Factionlint` | Syntax errors and hazardous patterns in workflow YAML |\n| `poutine` | Binary from GitHub releases | Supply-chain vulnerabilities (unpinned actions, script injections) |\n| `semgrep` | `semgrep\u002Fsemgrep-action` | Anti-patterns including `pull_request_target` misuse |\n| `checkov` | `bridgecrewio\u002Fcheckov-action` | Bad practices (write-all permissions, unsecure commands) |\n\n## Pre-commit hooks\n\n`.pre-commit-config.yaml` must include hooks for all four tools: `actionlint`, `poutine`, `semgrep`, `checkov`.\n\n## Tool configuration files\n\n- **`tools\u002Fsemgrep.yml`** — custom semgrep rules scoped to `.github\u002F`. Add new workflow anti-pattern rules here.\n- **`tools\u002F.poutine.yml`** — skip list for known-safe unverified-creator actions. Uses PURL format `pkg:githubactions\u002F\u003Cowner>\u002F\u003Crepo>` (no SHA). When intentionally using an unverified-creator action, add it here with a comment explaining why it is trusted.\n\n# CI coverage\n\nQuality-gate Makefile targets must each have a corresponding CI job. Reference `make \u003Ctarget>` in CI steps rather than reimplementing the logic inline — this avoids drift between local and CI behavior.\n\nTargets that must be covered: `fmt`, `lint`, `test`, `testacc`, `generate`, `terraform-test`.\n\nThe `install` target writes to a local path and does not need its own CI job, but is typically a prerequisite step.\n","# Workflow syntax\n\nRefer to the [GitHub Actions workflow syntax](https:\u002F\u002Fdocs.github.com\u002Fen\u002Factions\u002Freference\u002Fworkflows-and-actions\u002Fworkflow-syntax) guide to find details about how to implement certain actions in workflows or actions.\n\n# Action pinning\n\nEvery `uses:` reference **must** be pinned to a full commit SHA. Tags and branches are mutable and can be silently redirected (supply chain attack vector). Add the version tag as a trailing comment so humans know what version is in use.\n\n```yaml\n# Bad — mutable tag\nuses: hashicorp\u002Fsetup-terraform@v3\n\n# Good — immutable SHA + human-readable comment\nuses: hashicorp\u002Fsetup-terraform@b9cd54a3c349d3f38e8881555d616ced269ef032 # v3.1.2\n```\n\nThis applies to all third-party actions including `actions\u002F` official actions.\n\n# Permissions\n\nAlways set a zero-permission block at the **workflow level** to disable all permissions by default:\n\n```yaml\npermissions: {}\n```\n\nThen set an explicit `permissions:` block on **every job**, granting only what that job needs:\n\n- Read-only jobs (lint, test, build): `contents: read`\n- Jobs that push or tag: `contents: write`\n- Jobs that authenticate to OIDC providers: `id-token: write`\n- Jobs that comment on PRs or issues: `pull-requests: write`, `issues: write`\n\nNever leave a job without a `permissions:` block.\n\n# Command injection prevention\n\n`${{ }}` expressions are expanded **before** the shell executes — no escaping occurs. Any attacker-controlled value in a `run:` step is an arbitrary code execution risk.\n\nNever interpolate these directly in `run:` steps:\n\n| Source | Variable |\n|--------|----------|\n| PR title | `github.event.pull_request.title` |\n| PR body | `github.event.pull_request.body` |\n| Issue title | `github.event.issue.title` |\n| Comment body | `github.event.comment.body` |\n| Branch name | `github.event.pull_request.head.ref` |\n| Commit message | `github.event.head_commit.message` |\n| Dispatch input | `github.event.inputs.*` |\n\n```yaml\n# Bad — injection risk\n- run: echo \"PR: ${{ github.event.pull_request.title }}\"\n\n# Good — pass through env var\n- run: echo \"PR: $PR_TITLE\"\n  env:\n    PR_TITLE: ${{ github.event.pull_request.title }}\n```\n\n# Harden runner\n\nEvery job's **first** step must be `step-security\u002Fharden-runner`, SHA-pinned, with `egress-policy: audit`. This intercepts all outbound network calls and logs unexpected egress (e.g., a compromised action exfiltrating secrets).\n\n```yaml\nsteps:\n  - name: Harden runner\n    uses: step-security\u002Fharden-runner@\u003Cfull-sha> # \u003Cversion tag>\n    with:\n      egress-policy: audit\n```\n\n# Secret handling\n\n- Secrets must only be passed via `env:` or `with:` — never interpolated directly into `run:` shell commands with `${{ secrets.FOO }}` (log injection risk).\n- Never print, echo, or write secrets to files or stdout.\n\n```yaml\n# Bad — log injection risk\n- run: curl -H \"Authorization: ${{ secrets.API_KEY }}\" https:\u002F\u002Fexample.com\n\n# Good\n- run: curl -H \"Authorization: $API_KEY\" https:\u002F\u002Fexample.com\n  env:\n    API_KEY: ${{ secrets.API_KEY }}\n```\n\n# Fork PR security\n\nJobs that use repository secrets must not be triggerable from fork pull requests. Fork PRs run with no access to secrets under a plain `pull_request` trigger — but this protection is bypassed by `pull_request_target`, which runs in the base branch context and exposes secrets.\n\n- Never use `pull_request_target` for jobs that access secrets unless forked code is never checked out.\n- Jobs needing secrets must be triggered by `push` to a protected branch, `workflow_dispatch`, a GitHub Environment with required reviewers, or `workflow_call` from a workflow that meets one of these conditions.\n- A called workflow receives a secret only if the caller passes it, by name or with `secrets: inherit`, even a secret that exists only in the environment of the called job. That job then gets the environment's value. Keep such secrets `required: false`: `required` only checks that the caller passes the secret, not its value.\n\n```yaml\n# Correct pattern for jobs needing secrets: testacc.yml, called by semantic-release.yml on push to main\non:\n  workflow_call:\n    secrets:\n      ANTHROPIC_API_KEY:\n        required: false\n  workflow_dispatch:\n\njobs:\n  testacc:\n    environment: acctest  # holds the secret\n    env:\n      ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}\n\n# semantic-release.yml, the caller: passes the secret by name\njobs:\n  acceptance-tests:\n    uses: .\u002F.github\u002Fworkflows\u002Ftestacc.yml\n    secrets:\n      ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}\n```\n\n# Privileged jobs (release, publication)\n\nA job that signs artifacts or writes to `main` holds credentials that every user of the provider ends up trusting: the GPG key signs the Registry checksums, and the semantic-release App bypasses the `main` ruleset. Write access to the repository must not be enough to reach them. `RELEASE.md` (\"Protect the release credentials\") has the GitHub settings; when writing or reviewing `goreleaser-release.yml`, `semantic-release.yml` or a new privileged workflow, check these six rules:\n\n1. **Credentials live in an environment, never at repository or organization level.** The job declares `environment:` (`release` for signing, deployable from `v*` tags only, with required reviewers; `semantic-release` for publishing, deployable from `main` only), and the secrets are environment secrets. A repository secret is readable by a workflow pushed on any branch.\n2. **Release tags are protected.** A tag ruleset on `v*` restricts creation, update and deletion, with the semantic-release App as the only bypass, because any `v*` tag starts the signed release.\n3. **No shared cache in a job that holds a secret.** That covers the jobs that sign or publish and the acceptance-test jobs of `testacc.yml`. `actions\u002Fsetup-go` gets `cache: false` and the job uses no `actions\u002Fcache`: a cache restored there may have been saved by any job that ran on `main`, including one whose actions Renovate automerges, and Go does not re-hash extracted module sources on restore. A release job runs `go mod download && go mod verify` instead; the test jobs download the modules as they build (`RELEASE.md`, \"Caches\").\n4. **Installs come from a committed lockfile, without scripts.** `npm ci --ignore-scripts` from `.github\u002Fsemantic-release\u002Fpackage-lock.json` (also enforced by its `.npmrc`), never `npm install` with inline versions: every transitive package would otherwise be resolved at release time and could run code next to the credentials.\n5. **Credentials enter the job after the install, with only the permissions they need.** `actions\u002Fcheckout` sets `persist-credentials: false`, the App token is minted after `npm ci` and passed only to the step that publishes, and the job token keeps `contents: read`. The App token lists its permissions (`permission-contents`, `permission-issues`, `permission-pull-requests`, all `write`): without them it inherits every permission the App holds, including any granted later.\n6. **Release tooling updates get a human review.** In `renovate.json`, the `release tooling` group (matched by file: both release workflows and `.github\u002Fsemantic-release\u002Fpackage.json`) keeps `automerge: false` whatever the update type. Do not add these files to an automerged group.\n   The group also matches `testacc.yml`, whose jobs hold the `acctest` keys. Add to it any new workflow whose jobs read a secret other than `GITHUB_TOKEN` or run in a protected environment, and give those jobs no cache (rule 3). Root `go.mod` updates are never automerged either, because the acceptance tests compile them, and a tool that such a job downloads is pinned, never `latest` (`terraform_version` in `testacc.yml`). The approval of the signing job checks those updates again before they ship signed, so keep the `dependency-changes` job of `goreleaser-release.yml`, which lists them on the run page, as a `needs` of the signing job.\n\n```yaml\njobs:\n  release:\n    environment: semantic-release        # secrets scoped to main\n    permissions:\n      contents: read                     # writes go through the App token\n    steps:\n      - uses: actions\u002Fcheckout@\u003Cfull-sha> # \u003Cversion tag>\n        with:\n          persist-credentials: false\n      - name: Install semantic-release\n        working-directory: .github\u002Fsemantic-release\n        run: npm ci --ignore-scripts --no-audit --no-fund\n      - name: Generate app token         # minted after the install\n        id: app-token\n        uses: actions\u002Fcreate-github-app-token@\u003Cfull-sha> # \u003Cversion tag>\n        with:\n          app-id: ${{ secrets.SEMREL_APP_ID }}\n          private-key: ${{ secrets.SEMREL_APP_PRIVATE_KEY }}\n          permission-contents: write     # only what semantic-release uses\n          permission-issues: write\n          permission-pull-requests: write\n```\n\n# Security tooling\n\n## `security.yml` workflow\n\nThe project must have `.github\u002Fworkflows\u002Fsecurity.yml` with four jobs, all SHA-pinned, triggered on `pull_request` and `merge_group`:\n\n| Job | Tool | What it checks |\n|-----|------|----------------|\n| `actionlint` | `rhysd\u002Factionlint` | Syntax errors and hazardous patterns in workflow YAML |\n| `poutine` | Binary from GitHub releases | Supply-chain vulnerabilities (unpinned actions, script injections) |\n| `semgrep` | `semgrep\u002Fsemgrep-action` | Anti-patterns including `pull_request_target` misuse |\n| `checkov` | `bridgecrewio\u002Fcheckov-action` | Bad practices (write-all permissions, unsecure commands) |\n\n## Pre-commit hooks\n\n`.pre-commit-config.yaml` must include hooks for all four tools: `actionlint`, `poutine`, `semgrep`, `checkov`.\n\n## Tool configuration files\n\n- **`tools\u002Fsemgrep.yml`** — custom semgrep rules scoped to `.github\u002F`. Add new workflow anti-pattern rules here.\n- **`tools\u002F.poutine.yml`** — skip list for known-safe unverified-creator actions. Uses PURL format `pkg:githubactions\u002F\u003Cowner>\u002F\u003Crepo>` (no SHA). When intentionally using an unverified-creator action, add it here with a comment explaining why it is trusted.\n\n# CI coverage\n\nQuality-gate Makefile targets must each have a corresponding CI job. Reference `make \u003Ctarget>` in CI steps rather than reimplementing the logic inline — this avoids drift between local and CI behavior.\n\nTargets that must be covered: `fmt`, `lint`, `test`, `testacc`, `generate`, `terraform-test`.\n\nThe `install` target writes to a local path and does not need its own CI job, but is typically a prerequisite step.\n",{"name":5,"model":33,"description":7},"main","fc6281c8f668b5580da9ad43a9c87058260dc10e",".claude\u002Fskills\u002Fgithub-actions",11,"https:\u002F\u002Fgithub.com\u002Fippontech\u002Fterraform-provider-anthropic","https:\u002F\u002Fgithub.com\u002Fippontech","blog.ippon.fr","We help orgs modernize their systems and scale with deep expertise across Cloud, DevOps, Data, AI, Software Engineering and Mobile.","2026-11-14 03:01:29",{"source":8,"skillName":5,"commands":50,"prompt":60,"zipAvailable":61},[51,54,57],{"tool":52,"command":53},"npx","npx skills add ippontech\u002Fterraform-provider-anthropic --skill github-actions",{"tool":55,"command":56},"bunx","bunx skills add ippontech\u002Fterraform-provider-anthropic --skill github-actions",{"tool":58,"command":59},"pnpm","pnpm dlx skills add ippontech\u002Fterraform-provider-anthropic --skill github-actions","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fippontech\u002Fterraform-provider-anthropic\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fgithub-actions\u002FSKILL.md",true,[],[64,79,87,101,107,113],{"skillNo":65,"name":66,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":73,"publishedAt":35},"01M6P6YNS89ESB3FGRKBNZPNWV","skill_version","An example custom skill version for demonstration.","https:\u002F\u002Fgithub.com\u002Fippontech\u002Fterraform-provider-anthropic\u002Fblob\u002Fmain\u002Fexamples\u002Fresources\u002Fskill_version\u002FSKILL.md",[70],{"categoryNo":71,"categoryName":72,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[74,75,76,27,77,78],"skill version","version","custom","custom skill","example",{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":86,"publishedAt":35},"01M6P6YM857X93M8MPMTZ2PKBT","skill","An example custom skill.","https:\u002F\u002Fgithub.com\u002Fippontech\u002Fterraform-provider-anthropic\u002Fblob\u002Fmain\u002Fexamples\u002Fresources\u002Fskill\u002FSKILL.md",[85],{"categoryNo":71,"categoryName":72,"taxonomyType":21,"taxonomyTypeDesc":22},[76,77,78],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":96,"publishedAt":35},"01M6P6YJCA570MSPXRD108XK8Y","account-research","Researches a customer account before a call.","https:\u002F\u002Fgithub.com\u002Fippontech\u002Fterraform-provider-anthropic\u002Fblob\u002Fmain\u002Fexamples\u002Fresources\u002Fplugin_version\u002Fsales-toolkit\u002Fskills\u002Faccount-research\u002FSKILL.md",[93],{"categoryNo":94,"categoryName":95,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",[97,98,99,100],"account research","research","call","customer",{"skillNo":102,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":106,"publishedAt":35},"01M6P6YGXTT15BQRPNBDT760TY","https:\u002F\u002Fgithub.com\u002Fippontech\u002Fterraform-provider-anthropic\u002Fblob\u002Fmain\u002Fexamples\u002Fresources\u002Fplugin\u002Fsales-toolkit\u002Fskills\u002Faccount-research\u002FSKILL.md",[105],{"categoryNo":94,"categoryName":95,"taxonomyType":21,"taxonomyTypeDesc":22},[97,98,99,100],{"skillNo":108,"name":109,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":35},"01M6P6YCC35DT5YRM8FXWXW4RD","skills","https:\u002F\u002Fgithub.com\u002Fippontech\u002Fterraform-provider-anthropic\u002Fblob\u002Fmain\u002Fexamples\u002Fdata-sources\u002Fskills\u002FSKILL.md",[],[76,77,78],{"skillNo":114,"name":115,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":119,"publishedAt":35},"01M6P6XT6P3P8CYK7D3ECM08QK","skill_versions","https:\u002F\u002Fgithub.com\u002Fippontech\u002Fterraform-provider-anthropic\u002Fblob\u002Fmain\u002Fexamples\u002Fdata-sources\u002Fskill_versions\u002FSKILL.md",[118],{"categoryNo":71,"categoryName":72,"taxonomyType":21,"taxonomyTypeDesc":22},[120,78,77,27,76,75,74],"skill versions"]